This page is a side-by-side EVM/Cosmos lifecycle walkthrough with operational guidance for senders. For the canonical reference on transaction types, ordering, and receipt fields, see Transactions.
c8ntinuum accepts both Ethereum-style EVM transactions and Cosmos SDK transactions. For EVM users, the normal path is familiar: sign, submit, wait for inclusion, read the receipt. The difference is that an EVM transaction can also call precompiles that execute native chain logic.

​
Lifecycle

StepEVM transactionCosmos SDK transaction
SigningWallet or signer creates an Ethereum transaction for the EVM chain ID.Cosmos signer creates a Protobuf-encoded transaction with one or more messages.
SubmissionJSON-RPC, usually eth_sendRawTransaction or wallet RPC.Cosmos transaction broadcast endpoint or CLI.
ValidationSignature, nonce, balance, fee, gas, and route checks.Signature, account, fee, gas, and message route checks.
MempoolValid transactions wait for ordering and block inclusion.Valid transactions wait for ordering and block inclusion.
ExecutionEVM bytecode runs; precompile calls may invoke native modules.Native module message handlers run.
OutputEthereum-compatible receipt, logs, status, and gas fields.Cosmos transaction response and indexed events.
FinalityFinal after one committed block under standard CometBFT assumptions.Final after one committed block under standard CometBFT assumptions.

​
Ordering and nonces

Transactions are ordered by effective tip while preserving nonce semantics for each EVM account. c8ntinuum supports nonce gap queuing, but applications should still manage nonces carefully for high-throughput senders.
ConcernGuidance
Sequential sendersTrack the latest pending nonce and serialize retries.
Parallel sendersAllocate nonces centrally or shard sender accounts.
Replacement transactionsUse current fee data and preserve the same nonce.
Custody creditingConfirm receipt status and logs; do not credit from pending transaction data.

​
Finality and confirmations

Protocol finality is one block under standard CometBFT assumptions. Business workflows may wait longer for operational reasons. For example, exchange deposit processing recommends 60 confirmations to absorb RPC, log, receipt, and scanner lag.