Skip to main content

1. Working with Finality

1.1 Three Presets

A latest block is optimistic; a finalized block cannot be dropped. For the FINAL preset, poll the receipt and the finalized block until the receipt’s block number is no higher than the finalized block’s number, then check that the canonical block at that height is the receipt’s block. If it is not, the transaction was reorganized out of that block, so keep polling for a fresh receipt. Replace txHash with your submitted transaction hash:

1.2 Decision matrix

  • FAST (0 confirms, ~7 s): real-time UI updates and analytics. Roll back if a reorg shows up.
  • SAFE (7 authored blocks, ~50 s): ordinary user actions such as token transfers, approvals, and simple swaps. Rarely reorgs. The finalized tag usually arrives sooner (~40 s) and cannot be dropped, so prefer finalized over the 7-block wait when your provider supports it.
  • FINAL (finalized tag, ~40 s): anything that must be irreversible, such as treasury moves, bridge deposits, and high-value NFT mints.

2. Quick-Start Checklist

  1. RPC & chain-ID
    • Mainnet RPC https://quicknode1.peaq.xyz ID 3338
    • Testnet RPC https://peaq-agung.api.onfinality.io/public ID 9990
  2. Check your EVM version peaq runs the Cancun opcode set apart from the blob opcodes (BLOBHASH, BLOBBASEFEE). Newer targets are not supported: solc 0.8.30 and later default to prague or osaka, and the Osaka CLZ opcode fails on peaq. Set evmVersion to cancun:
  3. Estimate gas then add a 10 to 20 percent buffer (see estimate gas fees)
  4. Deploy as usual npx hardhat ignition deploy ./ignition/modules/SimpleStorage.js --network peaq (add a peaq network to hardhat.config.js with chainId: 3338, as for agung in Build Smart Contract)

3. Handling Reorgs & Using Finalized Blocks

Reorgs When two blocks land at almost the same time the chain briefly forks. The shorter fork is later dropped, so its last few blocks, and any transactions inside them, vanish and must be re-included. Why finalized blocks help Extra votes lock a block in permanently; once finalized, that block (and all earlier ones) can never be dropped, so reorgs can only touch the unfixed tip of the chain.
When monitoring blocks:

4. peaq-Specific Nuances


5. Tracing & Debugging

Add these flags to your node startup command (the Docker command on Connecting to peaq shows the rest):
Then:
Before enabling tracing RPCs, build the runtime with the evm-tracing feature and put the resulting .wasm file in an overrides folder. Then start the node with tracing RPCs enabled and point --wasm-runtime-overrides at that directory, not at the file. The override is not part of the Docker image, so mount your own folder. If the path is not a real directory, or the file does not end in .wasm, the override is ignored and tracing does not work. For the build scripts, see the peaq-node-builder repository.

6. Frequently Asked Questions

How many confirmations are really “safe”? Waiting for the finalized tag is the strongest guarantee. Seven authored blocks (≈ 50 s) is the community standard for ordinary user actions. Can a finalized block revert? Only if at least a third of the stake is slashed, which is economically irrational. My tx failed, how do I debug? Simulate with provider.call(tx) first; for deep dives use debug_traceTransaction on a tracing node.

7. Resources