Transaction Lifecycle
This page traces a transaction's journey from creation to finality on Monolythium. Both Cosmos SDK transactions and EVM transactions follow distinct paths that converge at state commitment.
Cosmos Transaction Flow
┌──────────────────────────────────────────────────────────────┐
│ 1. CREATE & SIGN │
│ Client builds MsgSend/MsgDelegate/etc. │
│ Signs with EthSecp256k1 key │
│ Wraps in Tx with fee, gas limit, memo │
└──────────────────────┬───────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ 2. BROADCAST │
│ Submitted via Cosmos RPC (broadcast_tx_sync/async/commit)│
│ Node receives and runs CheckTx │
└──────────────────────┬───────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ 3. MEMPOOL │
│ Passes basic validation (signature, sequence, min fee) │
│ Sits in mempool until proposer includes it in a block │
└──────────────────────┬───────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ 4. ANTE HANDLERS (in order) │
│ ├── SetupContext Set gas meter │
│ ├── ValidateBasic Check message structure │
│ ├── ValidateMemo Enforce memo length limit │
│ ├── DeductFeeDecorator Deduct fee from sender │
│ ├── x/burn FeeHandler Split: 90% burn, 10% proposer │
│ ├── SigVerification Verify EthSecp256k1 signature │
│ ├── IncrementSequence Bump account sequence (nonce) │
│ └── x/validator Check (if MsgRegisterValidator) │
└──────────────────────┬───────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ 5. EXECUTION │
│ Message handler runs (bank.Send, staking.Delegate, etc.) │
│ State changes written to transient store │
│ Events emitted │
└──────────────────────┬───────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ 6. STATE COMMIT │
│ Block is proposed by the current proposer │
│ Other validators prevote and precommit │
│ 2/3+ validators sign → block committed │
│ State changes persisted to disk │
└──────────────────────┬───────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ 7. FINALITY (INSTANT) │
│ Block is final once committed. No reorgs, no rollbacks. │
└──────────────────────────────────────────────────────────────┘
Ante Handler Details
Ante handlers are middleware that run before message execution. They form a chain and each must pass for the transaction to proceed.
| Handler | Purpose | Failure Mode |
|---|---|---|
| SetupContext | Initialize gas meter with the tx gas limit | -- |
| ValidateBasic | Check message fields are well-formed | Reject malformed messages |
| ValidateMemo | Enforce max memo length (256 bytes) | Reject oversized memos |
| DeductFeeDecorator | Deduct the fee from the sender's balance | Reject if insufficient balance |
| x/burn FeeHandler | Route 90% of the deducted fee to the burn address, 10% to the block proposer | -- |
| SigVerification | Verify the EthSecp256k1 signature against the signing bytes | Reject invalid signatures |
| IncrementSequence | Bump the sender's account sequence (prevents replay) | -- |
| x/validator Check | For MsgRegisterValidator: verify 100K LYTH burn deposit + 100K self-delegation | Reject insufficient deposit |
EVM Transaction Flow
┌──────────────────────────────────────────────────────────────┐
│ 1. CREATE & SIGN │
│ Build EVM tx (to, value, data, gasLimit, gasPrice) │
│ Sign with ECDSA (same key, 0x-prefixed address) │
│ Encode as raw transaction bytes │
└──────────────────────┬───────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ 2. BROADCAST │
│ Submitted via eth_sendRawTransaction │
│ Node decodes and validates basic fields │
└──────────────────────┬───────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ 3. EVM MEMPOOL │
│ Nonce check, gas price check, balance check │
│ Queued until included in a block by the proposer │
└──────────────────────┬───────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ 4. EVM EXECUTION │
│ Wrapped as a Cosmos MsgEthereumTx │
│ EVM state transition: run bytecode, update storage │
│ Gas consumed, logs emitted │
│ Fees processed through x/burn (90/10 split) │
└──────────────────────┬───────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ 5. STATE COMMIT & FINALITY │
│ Same BFT consensus as Cosmos transactions │
│ EVM state root included in block header │
│ Instant finality once committed │
└──────────────────────────────────────────────────────────────┘
EVM-Cosmos Bridge
Internally, EVM transactions are wrapped in a Cosmos MsgEthereumTx message. This means:
- EVM transactions go through the same BFT consensus as native Cosmos transactions.
- Gas fees from EVM transactions are subject to the same x/burn 90/10 split.
- The EVM nonce and Cosmos account sequence are kept in sync.
- EVM state (contract storage, balances) and Cosmos state (staking, governance) share the same committed state.
Instant Finality
Monolythium uses LythiumBFT consensus, which provides instant finality. Once a block is committed (2/3+ validator signatures), it is permanent.
| Property | Value |
|---|---|
| Finality type | Instant (single-block) |
| Reorgs possible | No |
| Confirmation requirement | 1 block |
| Average block time | ~3 seconds |
This means:
- No confirmation waiting: Unlike Ethereum (12-15 confirmations) or Bitcoin (6 confirmations), a single committed block is final.
- No uncle/ommer blocks: Every committed block is canonical.
- Safe for exchanges: Deposits can be credited after 1 block confirmation.
Exchange Integration
Monolythium's instant finality means exchanges and services can safely credit deposits after a single block confirmation. See Exchange Integration.
Transaction Status
Cosmos
# Query transaction by hash
monod query tx <txhash> --output json
# Check if transaction was successful
monod query tx <txhash> --output json | jq '.code'
# code 0 = success, any other value = failure
EVM
const receipt = await provider.getTransactionReceipt(txHash);
if (receipt === null) {
console.log("Transaction pending or not found");
} else if (receipt.status === 1) {
console.log("Transaction succeeded, block:", receipt.blockNumber);
} else {
console.log("Transaction reverted");
}
Status Codes
| Cosmos Code | Meaning |
|---|---|
0 | Success |
2 | Tx parse error |
5 | Insufficient funds |
11 | Out of gas |
13 | Insufficient fee |
19 | Tx already in mempool |
32 | Account sequence mismatch |
Common Failure Modes
| Failure | Cause | Solution |
|---|---|---|
| Out of gas | Gas limit too low | Increase --gas-adjustment or set higher gas limit |
| Insufficient funds | Balance below fee + amount | Fund the account |
| Sequence mismatch | Stale nonce (concurrent txs) | Query latest sequence and retry |
| Signature verification failed | Wrong chain ID or key | Verify --chain-id matches the network |
| EVM execution reverted | Contract logic rejected the call | Check revert reason with debug_traceTransaction |
Related
- Gas & Fee Mechanics -- Fee calculation, estimation, and the x/burn module
- Account Model -- Key derivation and dual address system
- Events & Logs -- Querying events emitted during execution
- EVM RPC Endpoints --
eth_sendRawTransactionand related methods