Mainnet parameters, history and endpoints

Chain parameters

Animica is a single-chain proof-of-work network. There is no validator set, no staking and no checkpointing authority; the canonical chain is the heaviest valid chain under the PoIES acceptance rule, with a reorg depth bound enforced since block 75,000.

The 60-second target and the emission schedule are read from spec/params.yaml and consensus/rewards.py; the reward split is the one in force since block 75,000. See ANM tokenomics and emission for the full schedule and difficulty adjustment and Θ for the retarget maths.

Consensus forks

Rule changes are forward-only and height-gated: blocks below the activation height are validated under the old rules, so history is never rewritten, and a node that has not upgraded keeps peering until the first rule-violating block appears. Activation heights are pinned in core/network_params.py and are not folded into the params hash, which is why upgraded and legacy nodes can still talk during the upgrade runway.

Two things are worth stating explicitly. First, the emission-changing forks (42,001, 50,000, 75,000) are not reject rules: a node running old code stays on the same chain but mis-credits balances, so exchanges and explorers must upgrade even though peering continues. Second, the useful-work verification rule armed at 75,000 is presence-gated and runs in shadow mode on mainnet: blocks carry no proofs today, the rule logs rather than enforces, and it does not force a miner to run a model. The useful-work article explains what is designed versus what is live.

Confirmations without finality

Animica has no finality gadget. The RPC method tx.getStatus returns a finalized flag that becomes true after 12 confirmations (a node-side convention, not a consensus guarantee); what you should read is confirmations, the number of blocks built on top of the one containing your transaction. Each additional block makes a reorg that excludes the transaction exponentially less likely, and since block 75,000 the protocol refuses any reorg deeper than 100 blocks, so a transaction with more than 100 confirmations cannot be undone by consensus at all.

A practical rule: for small payments, 6 confirmations (about 6 to 7 minutes) is the figure the project's own payment services use; for large transfers or exchange deposits, wait longer, up to the 100-block bound (roughly 1 hour 50 minutes at the measured block time). Two signals in the head deserve a note. chain.getHead currently reports zeroed stateRoot and txsRoot values because sealed header roots are armed but not yet populated by the miner; this does not affect transaction validity. The explorer also exposes a canonicalHeight one block behind the head, which is the height it treats as settled for indexing.

Public endpoints

The RPC path /rpc is required and only POST is served; there is no public WebSocket. There is no chain.getHeight method; use chain.getHead. Full method list and error codes: JSON-RPC API guide. Rate limits apply to all public endpoints; for sustained load run your own node.

Live snapshot (2026-08-23)

As of 2026-08-23 the head was around block 81,200, network hashrate about 52 MH/s (pool summary), circulating supply about 110.8 million ANM (explorer /api/circulating-supply), and the explorer reported 4 connected peers on its node and an average block time of about 69 s over its sample window. These are dated observations, not constants; the ticker at the top of the page and the explorer show the current values.