Concepts

Transaction lifecycle

Between "the node accepted it" and "it happened" there are two stages, and conflating them is the origin of the most expensive integration bug there is: crediting twice.

The six stages

From a TxSpec to a finalized block

Each stage carries its own guarantee. None of them implies the next, which is why there are six and not one.

Build the spec

Type, amount, destination, nonce and timestamp. The nonce comes from the node; the timestamp is outside consensus beyond having to be positive.

Rust · eav7-sdk

let spec = TxSpec::nova("TRANSFER", 5 * UNIT, nonce, agora_ms())
    .para("E7DEST…9A02");

// monta + assina + verifica LOCALMENTE (mesmo caminho que o nó aplicaria)
let tx = cliente.montar(spec)?;

2
Sign locally
The signature covers the canonical payload, which excludes the signatures themselves and the id. The id derives from the payload — re-signing does not produce a new id. The private key never leaves your machine.
3
Submit
POST /tx returns 200 with the verdict in the body. accepted: true means exactly one thing: this node's mempool took the transaction.
bash
```
curl -s -X POST https://eavscan.com/tx \
  -H 'Content-Type: application/json' \
  --data @tx.json

{ "accepted": true, "id": "0x8c1f…" }
```
4
Enter selection
The slot producer orders the mempool by (nonce, timestamp) and simulates execution. A transaction with a nonce gap waits; a permanently invalid one is dropped.
5
Confirm in a block
Once /tx/:id starts returning blockHeight, the transaction executed. A reorg can still undo it while the block is not finalized.
Rust
```
let bloco = cliente.aguardar_confirmacao(&id, Duration::from_secs(30))?;
println!("bloco {} · {}", bloco.block_height, bloco.block_hash);
```

Finalize

finalizedHeight ≥ blockHeight is the BFT guarantee: 2/3+1 of the validators have already produced on top. Nothing below that is reverted.

Rust

let estado = cliente.status()?;
let finalizada = estado["finalizedHeight"].as_i64().unwrap_or(-1);

if finalizada >= bloco.block_height as i64 {
    // irreversível por BFT: nenhum reorg pode desfazer daqui para trás
}

Guarantees

Accepted, included, final

Three states, three different guarantees. Pick the one that matches the decision your code makes.

accepted: true: The mempool took it. It has not executed, is not in a block, and may never land.
blockHeight: Executed inside a block. Reversible by reorg until finality.
finalizedHeight: Irreversible by consensus. This is the trigger for releasing credit or goods.

A timeout is not a verdict

aguardar_confirmacao returns TempoEsgotado when the deadline passes, and the transaction may still land afterwards. Re-read /tx/:id before resending — resending under another nonce creates a second transaction.

Mempool

What happens while it waits

The mempool is local to each node, bounded and time-limited. A transaction forgotten there is not pending forever.

MAX_MEMPOOL: 5 000Cap on resident transactions. When full, the node refuses new submissions.
MEMPOOL_TTL_MS: 21 600 000 · 6 hLifetime in the mempool. It reaches the nonce gap, which nonce-based pruning never would.
MAX_TXS_PER_BLOCK: 500Cap on transactions per block.
Selection order: (nonce, timestamp)Global, not per sender — but a single sender's nonce order is always respected.

Envelope

What goes in the body

The signed fields, the signature fields and the id.

The envelope field by field and all 58 protocol types live in Transactions.

Where to go next

From a TxSpec to a finalized block

Each stage carries its own guarantee. None of them implies the next, which is why there are six and not one.

Build the spec

Type, amount, destination, nonce and timestamp. The nonce comes from the node; the timestamp is outside consensus beyond having to be positive.

Rust · eav7-sdk

let spec = TxSpec::nova("TRANSFER", 5 * UNIT, nonce, agora_ms())
    .para("E7DEST…9A02");

// monta + assina + verifica LOCALMENTE (mesmo caminho que o nó aplicaria)
let tx = cliente.montar(spec)?;

2
Sign locally
The signature covers the canonical payload, which excludes the signatures themselves and the id. The id derives from the payload — re-signing does not produce a new id. The private key never leaves your machine.
3
Submit
POST /tx returns 200 with the verdict in the body. accepted: true means exactly one thing: this node's mempool took the transaction.
bash
```
curl -s -X POST https://eavscan.com/tx \
  -H 'Content-Type: application/json' \
  --data @tx.json

{ "accepted": true, "id": "0x8c1f…" }
```
4
Enter selection
The slot producer orders the mempool by (nonce, timestamp) and simulates execution. A transaction with a nonce gap waits; a permanently invalid one is dropped.
5
Confirm in a block
Once /tx/:id starts returning blockHeight, the transaction executed. A reorg can still undo it while the block is not finalized.
Rust
```
let bloco = cliente.aguardar_confirmacao(&id, Duration::from_secs(30))?;
println!("bloco {} · {}", bloco.block_height, bloco.block_hash);
```

Finalize

finalizedHeight ≥ blockHeight is the BFT guarantee: 2/3+1 of the validators have already produced on top. Nothing below that is reverted.

Rust

let estado = cliente.status()?;
let finalizada = estado["finalizedHeight"].as_i64().unwrap_or(-1);

if finalizada >= bloco.block_height as i64 {
    // irreversível por BFT: nenhum reorg pode desfazer daqui para trás
}

Accepted, included, final

Three states, three different guarantees. Pick the one that matches the decision your code makes.

accepted: true: The mempool took it. It has not executed, is not in a block, and may never land.
blockHeight: Executed inside a block. Reversible by reorg until finality.
finalizedHeight: Irreversible by consensus. This is the trigger for releasing credit or goods.

A timeout is not a verdict

What happens while it waits

The mempool is local to each node, bounded and time-limited. A transaction forgotten there is not pending forever.

MAX_MEMPOOL: 5 000Cap on resident transactions. When full, the node refuses new submissions.
MEMPOOL_TTL_MS: 21 600 000 · 6 hLifetime in the mempool. It reaches the nonce gap, which nonce-based pruning never would.
MAX_TXS_PER_BLOCK: 500Cap on transactions per block.
Selection order: (nonce, timestamp)Global, not per sender — but a single sender's nonce order is always respected.

From a TxSpec to a finalized block

Build the spec

Sign locally

Submit

Enter selection

Confirm in a block

Finalize

Accepted, included, final

What happens while it waits

What goes in the body

Where to go next

From a TxSpec to a finalized block

Build the spec

Sign locally

Submit

Enter selection

Confirm in a block

Finalize

Accepted, included, final

What happens while it waits

What goes in the body

Where to go next