This page describes a durable deposit scanner for exchange and custody systems. It covers successful native CTM transfers, ERC-20 transfers, idempotent crediting, backfill, retries, and finality handling through node interfaces.

Data sources

For most exchange integrations, use EVM JSON-RPC as the primary source and keep a local scanner database with durable cursors.

Scanner workflow

  1. Maintain one cursor per chain and asset family: native CTM, each ERC-20 contract, and any Cosmos-native flow.
  2. Poll eth_blockNumber and compute a safe target height. c8ntinuum has 1-block finality under standard CometBFT; exchanges should use 60 confirmations plus an optional 1-2 block scanner buffer for RPC, log, or receipt lag.
  3. Scan bounded ranges. Keep range sizes below the current RPC provider’s documented limits; the eth_getLogs block range cap is 10000.
  4. For native CTM, fetch full blocks and inspect transactions whose to is a monitored deposit address and value is non-zero.
  5. Fetch the receipt for each candidate and require status == 1.
  6. For ERC-20 deposits, query eth_getLogs by token contract, Transfer topic, and indexed recipient topics when practical.
  7. Fetch receipts for log-bearing transactions when the RPC response does not already prove transaction success.
  8. Upsert deposits idempotently before crediting user balances.
  9. Advance the durable cursor only after all records in the scanned range are stored and reconciled.
  10. Reconcile credited deposits against balances and explorer or indexer data during operations.

Idempotency keys

Use deterministic keys so retries cannot double-credit. Store the raw block number, block hash, transaction hash, from address, to address, asset identifier, amount, receipt status, and credited account ID.

Finality and confirmations

c8ntinuum blocks have 1-block finality under standard CometBFT. Exchange integrations should require 60 confirmations before crediting deposits; at the expected 4s block time, that is about 240 seconds, or 4 minutes. Add an optional 1-2 block scanner buffer only to absorb RPC, log, or receipt lag. Even with BFT finality, scanners should handle:
  • RPC provider lag or inconsistent responses between endpoints.
  • Temporary null receipts immediately after block discovery.
  • Duplicate logs during retries.
  • Cursor rollback by operator action during backfills.
  • Contract-internal native transfers that are not visible without traces or an indexer.

JavaScript scanner excerpt

Java scanner excerpt

Go scanner excerpt

Rust scanner excerpt

Reconciliation checklist

  • Compare scanner height to eth_blockNumber and CometBFT /status.
  • Verify every credited transaction has a successful receipt.
  • Re-run the scanner over already-credited ranges and confirm idempotency prevents duplicate credits.
  • Reconcile hot-wallet, cold-wallet, and deposit-address balances with eth_getBalance and token balanceOf.
  • Alert on cursor stalls, receipt fetch failures, RPC 429 responses, unusually large block lag, and unmatched pending credits.