Compile, deploy, call · ≈ 7 min

Inclusion is not execution

The single most expensive misunderstanding in blockchain integration work — and it is not specific to Animica.

A transaction being in a block does not mean it succeeded.

It means a miner included it. The transaction may have run and reverted, and it still occupies a block, still consumed gas, and still has a hash you can look up. If your code treats "I found it in a block" as "it worked", you will eventually credit somebody for a payment that never landed.

Always read the status from the receipt:

animica tx status <hash>
animica contract receipt <hash>

Look for a status of confirmed / included_block and a success flag — not merely the presence of a block height.

This is not theoretical. While building the Animica x402 marketplace, a settlement was recorded as FAILED because the code polled for confirmation for 30 seconds on a chain whose blocks average around two minutes. The payment had been accepted, sat in the pool, and landed normally — the software just was not looking long enough. The money moved; the ledger said it had not.

Two rules that follow:

1. Size your confirmation window to the chain's block time, not to your patience. Animica averages roughly two minutes per block. 2. "Accepted but not yet confirmed" is a third state, distinct from success and failure. Report it as itself. Collapsing it into "failed" under-reports real activity, and nobody complains about being under-billed — so the bug survives.

Stuck? Ask

Answered by Animica's own free inference network. It is donated GPU capacity, so give it 20-30 seconds.