EVM vs Stellar Comparison

This document provides a generalized overview of the differences between Ethereum Virtual Machine (EVM) chains and the Stellar Network. It’s meant to help EVM data analysts to understand Stellar chain data better by mapping the concepts.

A special thanks to Sydney Wiseman from the Stellar Development Foundation for making this available to the community!

Blockchain Purpose and Design

Stellar

The Stellar Network is designed to create digital asset products and services that improve access to the global financial system. With a focus on simplicity, speed, and cost-effectiveness in transferring assets, Stellar connects financial institutions, payment systems, and individuals. Due to its financial-centric design, Stellar includes built-in primitives for asset management, making it more secure and efficient for financial applications. However, Stellar’s original design was less flexible and had limited the types of financial applications built on Stellar. Since February 2024, Stellar has supported smart contracts written in Rust and compiled as WebAssembly (wasm).

EVM

EVM blockchains such as Ethereum allow developers to build decentralized applications (dApps) and deploy smart contracts. Unlike Stellar, EVM chains emphasize flexible programming at the cost of speed, leading to the need for layer-2 (L2) solutions to improve transaction throughput and cost efficiency. Smart contracts on EVM are written in Solidity.

Stellar Native Primitives

Asset Issuance
Claimable Balances (Airdrops)
Orderbook (Built-in DEX)
Automated Market Makers (AMMs)

Tokenization

Stellar allows native asset tokenization, where user balances are represented through trustlines. Standards for tokenization similar to ERC-20 and ERC-721 are available under SEP-41, implemented via the Stellar Asset Contract.

Consensus Mechanism

Stellar uses Stellar Consensus Protocol (SCP), a Proof of Agreement (PoA) mechanism derived from Federated Byzantine Agreement (FBA). Transactions are confirmed when overlapping quorums of nodes agree on validity. Stellar closes ledgers every 5 seconds. EVM chains like Ethereum use Proof of Stake (PoS) for consensus.

Time to Finality

Stellar: Deterministic finality, with ledgers closing every 5-6 seconds.
Ethereum: Probabilistic finality, requiring ~13 minutes (2 epochs) for finality.

Submitting Transactions

Stellar supports bundling up to 100 operations in a single transaction, improving developer experience. However, smart contract transactions (via Soroban) are capped at 1 operation per transaction, similar to EVM. Stellar allows fee bump transactions, where an account can pay fees on behalf of another account. Additionally, 26 operation types are natively supported on Stellar, in contrast to EVM’s 3 core transaction types (regular, contract deployment, execute contract).

Ledger State Comparison

Both Stellar and EVM use an account-based model. In Stellar, however, there are additional ledger state types:

Contracts: Persistent data and expiration details for smart contracts
Accounts: Externally owned accounts with lumen (XLM) balances
Trustlines: Balances of non-native tokens
Claimable Balances: Built-in airdrop feature
Liquidity Pools: AMM built-in mechanisms
Orderbook Offers: Stellar’s built-in decentralized exchange

EVM’s Accounts	Stellar’s Ledger Entry
nonce	No equivalent
balance	accounts
storageRoot	trustLines
codeHash	data, contractData
No native equivalent	contractCode
No native equivalent	claimableBalances
No native equivalent	liquidityPools
No native equivalent	offers
No native equivalent	configSetting
No native equivalent	ttl (State Archival)

Data Concept Mapping

Stellar’s data model is more complex than EVM due to its built-in primitives. The table below outlines equivalent data structures between EVM chains and Stellar, which serves to map the concepts between the two networks:

EVM’s Data Model	Stellar Data On Dune
blocks	history_ledgers
transactions	history_transactions
logs	history_contract_events
traces	history_operations, history_effects
contracts	contract_data
balances	accounts, trustlines, contract_data
token_transfers	history_operations

Data Model Details

Blocks

Stellar calls blocks, ledgers. A ledger represents the state of the Stellar network at a given point in time. EVM blockchains refer to state as a point in time as blocks, and the entire blockchain is “the ledger”. Ledgers on Stellar can refer to individual blocks or the full network history.

Size Limits

A transaction set within a ledger contains two transaction types: native and smart contracts. The ledger size has separate limits for each transaction type:

Native - the Stellar Network can apply up to 1,000 operations in a ledger. Transactions can bundle up to 100 operations in a single transaction.
Smart contracts - the Stellar Network dynamically limits the number of smart contract transactions based on network resources consumed (read/write bytes, CPU instructions, etc). See Smart Contract Settings for more details. See Fees and Metering for more information.

Ethereum limits block size by total gas spent.

Schema Mapping

Stellar Name	EVM Equivalent	Description
sequence	number	The sequence number of the ledger
ledger_hash	hash	The hash of this ledger
previous_ledger_hash	parent_hash	The hash of the previous ledger
closed_at	time	The timestamp when the ledger was written to the chain
protocol_version	version	Protocol version specified in the block header
total_coins		The total number of lumens in circulation
fee_pool	gas_used	The sum of all transaction fees
inflation_seq		Deprecated
base_fee	base_fee_per_gas	The minimum fee charged, per operation, to be included in the ledger
base_reserve		The minimum XLM balance to be held in an account to be considered valid
max_tx_set_size	gas_limit	The maximum number of non-Soroban operations allowed in a ledger. Note: Soroban transactions have a separate mechanism to limit resources utilization per ledger
ledger_header		The raw XDR representation of all the data stored in the Ledger Header
transaction_count	transaction_count	Number of transactions in the ledger
operation_count		The number of operations in the ledger. Note: Up to 100 operations can be bundled in a single transaction

Transactions

Actions are performed on the Stellar network through operations. Operations are bundled into transactions, with each account able to perform up to 100 operations in a single transaction. Accounts are limited to submitting one transaction per ledger. EVM networks do not have the concept of operations, the lowest level of action is a transaction. This limits accounts to one action per transaction in EVM L1 Layers, which is why L2 solutions and rollups are popular.

Transaction Types

Operation types on Stellar are analog to transaction types on EVM networks. The Stellar network natively supports 26 operation types, ranging from payments to orderbook offer management to smart contract invocation. EVM natively supports 3 transaction types: payment (regular), contract deployment, and execute contract, and does not support natively for Orderbook or AMMs.

Schema Mapping

Transactions

Stellar Name	EVM Equivalent	Description
transaction_hash	hash	A hex-encoded SHA-256 hash of this transaction’s XDR-encoded form
ledger_sequence	block_number	The sequence number of the ledger
closed_at	block_time	The timestamp when the ledger was written to the chain
inner_transaction_hash		A transaction hash of a transaction wrapped with its signatures for fee-bump transactions
account	from	The account address that originates the transaction
account_sequence	nonce	The source account’s sequence number that this transaction consumed. Sequence numbers can only be used once and help maintain atomicity and idempotency on the network
max_fee	max_fee_per_gas	The maximum fee (in stroops) that the account is willing to pay for the transaction to be included in a ledger
operation_count	Fixed at 1	The number of operations contained within this transaction
memo_type		Memos can be text, ids, or hashes
memo		Optional unstructured data field that can be used to differentiate between accounts (for pooled accounts)
time_bounds		Optional UNIX timestamp of a lower and upper bound of when a transaction will be valid
successful	success	Indicates if the transaction succeeded
fee_charged	gas_used
fee_account		An account that is not the originating source account for a transaction is allowed to pay transaction fees on behalf of the source account. These accounts are called fee accounts and incur all transaction costs for the source account
new_max_fee		The maximum fee (in stroops) an account is willing to pay for this account’s fees
account_muxed		If the user has defined multiplexed (muxed) accounts, the account exists “virtually” under a traditional Stellar account address. This address distinguishes between the virtual accounts
fee_account_muxed		If the fee account that sponsors fee is a multiplexed account, the virtual address will be listed here
preconditions		Validity checks the account can add when submitting a transaction to the network. If the conditions are not met, the transaction fails
transaction_envelope	input_data	The raw XDR that was submitted to the Stellar Network
transaction_result	receipt_root	The raw XDR that is returned from the network after applying the transaction
transaction_meta	input_data	Raw XDR of ledger state changes based on the application of the transaction
transaction_fee_meta	input_data
soroban_transaction_data	traces	Host env resource consumption by smart contract transactions
transaction_result_code	traces.error	Result code that includes error codes for failed transactions
inclusion_fee_charged	gas_price	The fee charged for the transaction to be included in the ledger. This is a fixed fee for the entire ledger and starts at a minimum of 100 stroops. The fee increases based on demand
signatures	signature

Operations

Stellar Name	EVM Equivalent	Description
id		Unique id for the operation
source_account	transaction.from	The account address that originates the transaction
transaction_id		Unique ID for the transaction. Bundled operation IDs will share the same Transaction ID
type	transaction.type	Operation type
details	Mix of input data and traces	Unstructured JSON that contains details based on the type of operation executed. Each operation will return its own relevant details
operation_result_code	traces
operation_trace_code	traces

Logs and Traces

Events are the mechanism that applications off-chain can use to monitor changes and events in contracts on-chain. Events are an amalgamation of both EVM logs and traces. Stellar has three types of smart contract events:

contract - events emitted by contracts to convey state changes
system - events emitted by the host environment itself
diagnostic - details transaction traces intended for debugging purposes

Schema Mapping

Stellar Name	EVM Equivalent	Description
type	trace.type	The type of event emission
ledger	block_number	The sequence number of the ledger
closed_at	block_time	The timestamp when the ledger was written to the chain
contract_id	contract_address	String key representation of the contract address
id	transaction_index	Unique ID for the event
in_successful_contract_call	trace.tx_success	Whether the event was emitted from a successful contract call
topic	logs.topic_list	Topic list of events
value	logs.data	The body values of the topic list
transaction_hash	trace.tx_hash	The transaction which triggered this event

Curated Data

Solana

Hyperliquid

Non-EVM Networks

Protocols

EVM Networks

Partner Data

Dune Index

EVM vs Stellar Comparison