Skip to main content

​
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