Transactions and events

A PressChain write starts with a user-authorized transaction and ends with observable protocol state. Applications should treat both sides as one workflow.

Signing boundary

User actions should be authorized through PressKey. A backend can prepare metadata, validate fields, resolve fees and encode calldata, but it should not receive the user private key. At the network layer, signed transactions use normal EVM transaction mechanics such as eth_sendRawTransaction.

Preflight before authorization

Immediately before asking the user to sign:

verify Chain ID
re-read the active account
resolve current role and bond state where required
check Capsule relationship authority
resolve current economic rule and amount
estimate gas
encode calldata from the correct ABI version
present a readable action summary

A gas estimate is not proof that execution will still succeed later. Shared state can change before inclusion.

Track the transaction

Persist the hash immediately after submission.

async function waitForReceipt(hash: string) {
  const deadline = Date.now() + 120_000;

  while (Date.now() < deadline) {
    const receipt = await rpc("eth_getTransactionReceipt", [hash]);
    if (receipt) return receipt;
    await new Promise((resolve) => setTimeout(resolve, 1500));
  }

  throw new Error("Receipt not observed before timeout");
}

A production application should allow the user to leave the page while the transaction tracker continues through a durable job or later reconciliation.

Event identity

Store enough coordinates to make projection writes idempotent:

type EventOrigin = {
  blockNumber: bigint;
  blockHash: string;
  transactionHash: string;
  logIndex: number;
};

The transaction hash and log index together are useful for detecting duplicate event application.

Reorganizations

Do not permanently finalize every observed event immediately. Track block hashes inside your reversible window. If an indexed block is replaced, roll back affected projections and replay from the last known canonical ancestor.

Evidence events

CapsuleEvidenceRegistryV3 emits events including:

EvidenceAdded
DisputeEvidenceSubmitted
EvidenceVoted
EvidenceFinalized
EvidenceActiveSet
AdminTransferred

An application can build an activity timeline from those logs, then reconcile current state through view calls.

Ambiguous submission failures

If a browser loses its network connection after a transaction was sent, do not immediately generate a second transaction. Query the original transaction hash or account nonce first. A timeout means the client did not receive a definitive answer. It does not automatically mean the network rejected the write.

Start Here

Build Your First App

Network

Identity & Roles

Capsules

Evidence

Verification

Provenance

PRESS Economy

Bounties

Data Model

API

RPC

PressKey

SDK & Integration

Operations & Security

Reference

Transactions & Events

Transactions and events

Signing boundary

Preflight before authorization

Track the transaction

Event identity

Reorganizations

Evidence events

Ambiguous submission failures

​Transactions and events

​Signing boundary

​Preflight before authorization

​Track the transaction

​Event identity

​Reorganizations

​Evidence events

​Ambiguous submission failures

Transactions and events

Signing boundary

Preflight before authorization

Track the transaction

Event identity

Reorganizations

Evidence events

Ambiguous submission failures