Skip to main content
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

​
Rejected transactions

Some transactions are rejected immediately when submitted. The eth_sendRawTransaction call returns an error and the transaction never reaches the pending state.

​
Runtime revert

If a transaction violates the blocklist during execution, 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. To detect a runtime revert, check receipt.status:
Handle reverted transactions in your wallet UI:
  • Show “Failed”: The transaction reached final state but didn’t take effect.
  • Treat consumed gas as non-refundable: A blocklist revert charges only the gas used up to the point of the check. Remaining gas is refunded.
  • Use a new nonce for any retry: The reverted transaction’s nonce is spent; a retry needs a new transaction.
  • Show a plain error message: “Transaction failed: the recipient or sender may be restricted” is more useful than a raw revert reason.

​
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 lower than the minimum. Transactions with maxFeePerGas lower than 20 Gwei are rejected with no error receipt and never appear in a block.
  • 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).