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
- Maintain one cursor per chain and asset family: native CTM, each ERC-20 contract, and any Cosmos-native flow.
- Poll
eth_blockNumberand 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. - Scan bounded ranges. Keep range sizes below the current RPC provider’s documented limits; the
eth_getLogsblock range cap is10000. - For native CTM, fetch full blocks and inspect transactions whose
tois a monitored deposit address andvalueis non-zero. - Fetch the receipt for each candidate and require
status == 1. - For ERC-20 deposits, query
eth_getLogsby token contract,Transfertopic, and indexed recipient topics when practical. - Fetch receipts for log-bearing transactions when the RPC response does not already prove transaction success.
- Upsert deposits idempotently before crediting user balances.
- Advance the durable cursor only after all records in the scanned range are stored and reconciled.
- 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
nullreceipts 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_blockNumberand 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_getBalanceand tokenbalanceOf. - Alert on cursor stalls, receipt fetch failures, RPC
429responses, unusually large block lag, and unmatched pending credits.