Transaction Sequencing

How EVM transactions are sequenced on MANTRA Chain

Transaction Composition in Cosmos

In Cosmos, a transaction is composed of multiple messages (think of it as native multicall), with the caller deciding how they want to sequence their messages in the transaction. The signature is done on the entire Cosmos transaction.

This allows for atomic operations where multiple actions can be combined in a single transaction.

EVM Transactions

EVM Message Format

• Must be alone in a transaction
• Cannot be combined with other Cosmos message types
• This is due to the signature being done on the EVM message (equivalent to a normal EVM transaction in Ethereum) instead of the entire Cosmos transaction
• Signature follows Ethereum’s EIP-155 format

Example:

// EVM transaction structure
const evmTransaction = {
  from: "0x...",           // Sender address
  to: "0x...",             // Contract address (or null for contract creation)
  value: "0x0",            // Amount in wei
  data: "0x...",           // Contract call data
  gasLimit: "0x5208",      // Gas limit
  gasPrice: "0x3b9aca00",  // Gas price
  nonce: 0,                // Transaction nonce
  chainId: 0x1388,         // Chain ID (EIP-155)
  // Signature is applied to this transaction object
  // Cannot be combined with Cosmos messages in the same transaction
};

Why This Design?

EVM Transaction Format

EVM transactions use Ethereum’s transaction format:

• Signature is on the EVM transaction itself
• Follows EIP-155 signature scheme
• Compatible with Ethereum tooling and wallets
• Standard EVM transaction behavior

Transaction Sequencing

Transaction sequencing is solely dependent on the block proposer, but the default is FIFO (First In, First Out).

Block Proposer Role

The block proposer (validator) decides:

• Which transactions to include
• The order of transactions
• Transaction prioritization

Default Behavior

By default, transactions are processed in FIFO order:

1. Transactions are added to the mempool
2. Block proposer selects transactions in order
3. Transactions execute sequentially

EVM Transaction Isolation

EVM transactions are isolated:

• Each EVM transaction is independent
• Cannot combine with other message types
• Standard Ethereum transaction behavior
• Each transaction executes atomically (succeeds or reverts entirely)

Practical Implications

For Developers

EVM:

• One operation per transaction
• Standard Ethereum behavior
• Compatible with existing EVM tooling
• Use multicall contracts for batching multiple operations

For Users

EVM:

• One operation per transaction
• Familiar Ethereum experience
• Standard gas costs
• Predictable transaction behavior

Example Scenario

Swap and Stake (EVM)

// Requires two separate transactions
// Transaction 1: Swap
swap();

// Transaction 2: Stake
stake();
// Each transaction executes atomically

Using Multicall for Batching

For batching multiple operations, consider using a multicall contract:

// Multicall pattern for batching operations
multicall([
    swapCall,
    stakeCall
]);

Best Practices

For EVM Developers

• Design contracts to minimize transaction dependencies
• Use standard EVM patterns
• Consider using multicall contracts for batching operations
• Each transaction executes atomically (succeeds or reverts entirely)

Next Steps

• Learn about Cosmos precompiles
• Understand ERC-20 token creation
• Explore EVM development