> ## 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.

# Transaction Lifecycle

> Understand Arc's two-state transaction model, where transactions are either pending or final with no intermediate confirmation states.

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:

| State   | Location        | Finality     | Duration             |
| ------- | --------------- | ------------ | -------------------- |
| Pending | Mempool         | Not final    | Sub-second (typical) |
| Final   | Committed block | Irreversible | Permanent            |

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

```mermaid theme={null}
stateDiagram-v2
    [*] --> Pending: Submitted to mempool
    Pending --> Final: Included in committed block
    Pending --> Dropped: Nonce gap / underpriced
    [*] --> Rejected: Pre-mempool validation fails
    Final --> [*]
    Dropped --> [*]
    Rejected --> [*]
```

## Comparison to Ethereum

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

|                     | Ethereum                              | Arc                            |
| ------------------- | ------------------------------------- | ------------------------------ |
| Pending state       | In mempool, not yet included          | In mempool, not yet included   |
| Confirming state    | 1–64 slots (\~12 seconds to \~13 min) | None                           |
| Finality            | 64 slots (\~13 minutes)               | Immediate upon block inclusion |
| Reorganization risk | Possible before finalization          | Impossible                     |
| Block time          | \~12 seconds                          | Sub-second                     |
| Consensus           | Gasper (LMD-GHOST + Casper FFG)       | Malachite (Tendermint BFT)     |

## 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).