Transaction Lifecycle

Documentation Index

Fetch the complete documentation index at: https://docs.arc.io/llms.txt

Use this file to discover all available pages before exploring further.

Arc uses a two-state transaction model. A transaction is either pending (in the mempool) or final (included in a committed block). There is no intermediate “confirming” state and no concept of accumulating confirmations. Once a block is committed by the Malachite consensus protocol, every transaction in that block is immediately and irreversibly final. This simplicity stems from Arc’s BFT consensus. Validators pre-commit blocks with a two-thirds supermajority before production, which eliminates chain reorganizations, uncle blocks, and probabilistic finality entirely.

​

Transaction states

Arc transactions exist in exactly two states: There is no “1 of 12 confirmations” counter. There is no safe-but-not-finalized window. A transaction transitions directly from pending to final.

​

State diagram

​

Comparison to Ethereum

Ethereum uses probabilistic finality with multiple intermediate states. Arc eliminates all intermediate states through deterministic BFT consensus.

​

Implications for wallet UX

The two-state model simplifies wallet interfaces:

• No confirmation counter. Remove any “X/N confirmations” progress bar or percentage indicator.
• No “confirming” spinner. A transaction is either pending or done.
• Instant “Complete” status. Show “Complete” or “Success” immediately when the transaction appears in a block.
• Simple state display. Use two UI states: “Pending” while in the mempool, and “Complete” once included in a block.

A wallet integration only needs to distinguish between a transaction hash that has no receipt (pending) and one that has a receipt with a block number (final).

​

Edge cases

​

Pre-mempool rejection

If a sender address is on the protocol blocklist, the RPC node rejects the transaction before it enters the mempool. The eth_sendRawTransaction call returns an error immediately. The transaction never reaches the pending state.

​

Runtime revert

If a transaction passes mempool validation but violates the blocklist during execution (for example, interacting with a blocked contract), the transaction is included in a block but marked as failed. It consumes gas and appears onchain with a status: 0 receipt. From a lifecycle perspective, it still reaches the final state—it is irreversibly included—but the state changes it attempted are reverted.

​

High mempool load

During periods of high network activity, transactions may remain in the pending state longer than usual. This does not affect finality guarantees. Once a transaction is included in a committed block, it is final regardless of how long it waited in the mempool.

​

Dropped transactions

Transactions can leave the mempool without reaching finality:

• Nonce gaps. If a transaction has a nonce higher than expected, it waits for the gap to be filled. If the gap is never filled, the transaction remains pending indefinitely or is eventually evicted.
• Gas price below minimum. Transactions with a gas price below the 20 Gwei minimum are rejected or dropped from the mempool.
• Mempool eviction. Under sustained high load, the lowest-priced transactions may be evicted to make room for higher-priced ones.

Dropped transactions produce no onchain record. Wallets should implement timeout logic and allow users to retry or cancel (by submitting a replacement transaction with the same nonce).