​
RPC Optimization

​
Avoid Unnecessary Calls

Some values are static or change infrequently on c8ntinuum. Consider hardcoding:
ValueMethodRecommendation
Chain IDeth_chainIdHardcode 2184
CurrencyN/AHardcode CTM

​
Batch Calls

Use Multicall3 (pre-deployed at 0xcA11bde05977b3631167028862bE2a173976CA11) to aggregate multiple read calls into a single RPC request: 
// Instead of N separate eth_call requests, batch them
Multicall3.aggregate3(calls);

​
Use JSON-RPC Batching Carefully

The documented EVM JSON-RPC batch limit is 2000 requests, with a maximum batch response size of 50000000 bytes. Keep batches well below those limits and make them retryable: 
const results = await provider.send([
  { method: "eth_getBalance", params: [addr, "latest"] },
  { method: "eth_getTransactionCount", params: [addr, "latest"] },
]);

​
Gas Optimization

  • Use eth_estimateGas for complex transactions
  • For simple ETH/CTM transfers, gas is always 21000
  • Set reasonable maxFeePerGas — check current base fee via eth_gasPrice

​
Nonce Management

For applications submitting multiple transactions in rapid succession:
  • Track nonces locally rather than querying eth_getTransactionCount for each tx
  • Submit transactions concurrently with incrementing nonces
  • Handle nonce gaps — c8ntinuum supports nonce gap queuing, but sequential submission is more reliable

​
Indexing

For historical data queries, use an indexer rather than RPC:
  • On-chain event logs are available via eth_getLogs; keep each request within the 10000 block and 10000 log caps
  • For complex queries (token transfers, DEX trades, balances over time), use a dedicated indexer
  • See Indexers for SubQuery/The Graph guidance and current provider status

​
Smart Contract Best Practices

  • Use OpenZeppelin contracts for standard patterns
  • When interacting with c8ntinuum precompiles, use the native chain decimal precision, not 18 decimals
  • Test on a local node before deploying to mainnet — run ./local_node.sh for a local instance