What Eden gives developers

Eden is fully Ethereum Virtual Machine (EVM) compatible. Your Solidity contracts, Hardhat and Foundry configs, and Ethers/Viem scripts work without changes. In addition, Eden adds exciting protocol-level features that standard EVM chains don't have.

Batch transactions

Eden supports Evolve's 0x76 transaction type that lets you execute multiple calls atomically in a single transaction, without deploying or relying on any contract.

Each transaction type 0x76 carries a list of Call structs. The EVM executes them in sequence, and the whole batch either succeeds or reverts. There is no partial execution and no need to handle intermediate failure states across separate transactions.

What this enables:

• Multi-step flows (approve + swap + stake, mint + list + transfer) collapse into one atomic unit instead of a sequence of transactions the user has to sign and the frontend has to track.
• Contracts don't need to defensively handle "was the prior step actually done?". The batch guarantees atomicity at the protocol level.
• Gas overhead per operation drops because you pay the base transaction cost once, not once per step.

Sponsored transactions

The same 0x76 transaction type supports a dual-signature scheme that separates the executor from the gas payer:

• The executor signs the calls (provides intent and value).
• The sponsor signs to pay gas (refunds route to the sponsor).

This is gasless UX at the protocol level without the need for ERC-4337 account abstraction, bundler infrastructure, paymaster contracts, or off-chain relayers. The user does not need TIA in their wallet to submit a transaction as the app or a third party can cover gas directly.

What this enables:

• Onboarding flows where users don't hold the native token yet become straightforward.
• Apps can abstract gas entirely from their UX without building or depending on a separate relayer stack.
• Sponsorship logic lives outside the contract, thus no modifications to your existing Solidity needed.

128 KB contract size limit

Ethereum's EIP-170 caps deployed bytecode at 24 KB. Eden's chainspec raises this to 128 KB via ev-reth's contractSizeLimit setting (131072 bytes), and the raised limit is active on mainnet.

The 24 KB limit is a real constraint on Ethereum and most EVM chains as complex protocols split logic across multiple contracts and use proxy patterns not because the architecture calls for it, but because the bytecode won't fit. That adds deployment complexity, increases surface area for proxy-related bugs, and forces indirection that makes contracts harder to audit.

On Eden, you can deploy contracts that would hit the ceiling on other chains without restructuring them. This is particularly relevant for:

• Game logic and state machines that encode a lot of behavior
• Large libraries where splitting introduces coordination overhead
• Protocols where a single-contract design is architecturally cleaner and safer

No public mempool, sequencer-controlled ordering

Eden has no p2p-gossiped public mempool. Transactions are submitted via eth_sendRawTransaction and enter the sequencer's private txpool before being included in blocks. Ordering is determined by the sequencer — there is no observable pending state for third parties to frontrun.

MEV is not eliminated; ordering authority is centralized in the sequencer, and trust in correct ordering rests with the sequencer operator.

What this means in practice:

• Contracts that assume fair ordering (AMMs, auctions, games) don't need to defend against public frontrunning at the contract level.
• Oracle updates, liquidations, and other time-sensitive operations are not displaced by priority gas auctions.
• Users aren't paying an implicit public MEV tax on swaps and other competitive operations.

Predictable gas costs

Eden's fee market parameters (base fee adjustment denominator, elasticity multiplier, and initial base fee) are configured for Eden's actual throughput rather than inherited from Ethereum mainnet (which was calibrated for much lower block targets).

In practice this means base fees move more gradually and stay more predictable for users. Gas estimation is more reliable, and apps don't need to pad estimates as aggressively to avoid failed transactions during brief congestion spikes.

Summary