How Ethereum Transactions Got More Expressive: An 11-Year Evolution

SOC 2 Type II 인증 · ISO 27001

In 2015, Ethereum transactions were simple: the user signs an instruction, pays the gas fee, submits it to the network, and waits for Ethereum to update its state.

That model still works.

But over 11 years, that same workflow has split into smaller, separately owned pieces: who authorizes, who pays, who executes, who orders, and who settles.

This piece traces the path Ethereum transactions have traveled: what has stayed the same, what has changed, and everything in between.

Block #0 of Ethereum Transactions

Initial Ethereum transactions were simple. The same account that authorized an action also initiated it, paid for its execution, and submitted it to the network.

This bundling of responsibilities is worth noting, because it makes the evolution that followed easier to see.

The Original Ethereum Transaction Model

Ethereum transactions start with externally owned accounts (EOAs). An EOA's private key signs and initiates the transaction, specifying the action: where to send it, how much ETH to transfer, or which contract function to call. The same EOA also supplies ETH for gas.

Execution is what happens once a miner includes the transaction in an Ethereum block. This is where the EVM takes over to execute the action and update the state.

Here are the six steps that make up an Ethereum transaction:

Why Ethereum Transactions Had to Unbundle to Evolve

The six-step model bundles several jobs into one transaction path.

1. The signer authorizes, pays, submits, and, more importantly, specifies what Ethereum should execute.

2. Ethereum then executes and settles the transaction.

Every responsibility traces back to one private key in one transaction. That simplicity worked at the time. Demand, however, didn't stay simple.

Users wanted to:

• Give apps limited authority

• Hide sensitive activity

• Pay with something other than ETH

Some apps wanted to:

• Sponsor a user's first transaction

• Batch ten actions into one

• Let a session key act for an hour without asking twice

None of that fits inside a single instruction. The format had to become extensible before new transaction types could exist at all.

This is where the unbundling of Ethereum transactions into independent parts started.

Ethereum Transactions Themselves Became More Expressive

The original transaction format was built for a simpler Ethereum. As transactions needed to carry new capabilities, the format itself had to become more flexible.

Extensibility of Transaction Formats

Ethereum's original transaction format was one fixed sentence structure: nine fields in the same order, every time.

Every Ethereum wallet, node, and explorer could only read this language. Anything outside it sounded alien.

EIP-2718 changed that by giving transactions a type byte.

The type tells Ethereum and its tooling how to interpret everything that follows. Old transactions could keep their existing format, while new transaction types could introduce their own fields and rules.

Here are some notable transaction types that would be impossible without EIP-2718:

This way, Ethereum transactions now had a set of languages that the network could recognize by their opening word.

At the same time, smart contracts were expanding how much execution one transaction could trigger.

Composable Execution Became the Norm

Imagine a user wants to execute a swap and deposit the swapped token into another protocol or vault.

Before, this meant three user signatures, each with its own gas fee:

• Sign > Approve

• Sign > Swap

• Sign > Deposit

Now, Ethereum transactions have evolved to:

• Sign > [Approve > Swap > Deposit]

The user signs once, and the steps execute in an all-or-nothing fashion. That all-or-nothing boundary is the very thing that made every single transaction trustworthy in the first place.

Now, more transactions and more expansive smart contracts mean each transaction touches more state, runs more code, and asks more of the network.

This is where the economics of Ethereum had to evolve.

How Ethereum's Gas Fees Evolved

Every transaction competes for the same scarce resource: block space. Ethereum had to decide, block by block, whose transaction got in and what they paid for it.

Over the past decade or so, Ethereum has had two major milestones in gas fees. But first, what was the original model?

The Original Gas Auction

Early Ethereum used a first-price auction. A transaction specified a gasPrice, and miners generally prioritized transactions offering more.

If the transaction used 50,000 gas at 20 gwei, the fee was:

50,000 × 20 gwei = 0.001 ETH

The problem was price discovery. Senders always had to choose between overpaying and waiting longer for inclusion.

This worked when demand was manageable. As Ethereum became congested, estimating the right bid became part of the transaction problem.

Enter fee splitting.

EIP-1559 and the Base Fee

EIP-1559 replaced the single gasPrice bid with two components:

• Base fee: Set by the protocol based on block demand and burned after payment.

• Priority fee: A tip paid to the block producer for including the transaction.

Transactions also specify a maximum fee, i.e., a ceiling on what the sender is willing to pay.

This way, EIP-1559 made fees more predictable and solved price discovery fairly effectively.

EIP-1559 improved how Ethereum priced execution. Rollups created a different problem: they pay to post data on Ethereum for verification.

Blob Transactions and a Separate Fee Market

EIP-4844 introduced blob transactions for rollup data.

Blobs carry large chunks of data that Ethereum makes temporarily available (~18 days) without storing them permanently in execution state.

More importantly, blobs have their own fee market.

A blob transaction therefore pays for two scarce resources separately:

• Normal EVM execution, through gas

• Blob data, through blob gas

With EIP-4844, Ethereum deliberately moved away from a single market pricing every transaction resource, toward pricing each resource according to its own demand.

Every gas fee model still assumed one thing: the account signing the transaction is the account funding it. That assumption was about to break.

Paying and Submitting Became Separate From Signing

Ethereum transactions originally assumed one account would authorize an action, broadcast it, and hold enough ETH to pay for execution.

Relayers, and later account abstraction, separated these responsibilities.

Relayers and Meta-Transactions

A user holding an ERC-20 token but no ETH couldn't transact at all. Although the token had value, paying gas required ETH, which the user didn't have.

Meta-transactions introduced a simple split:

User signs a message > Relayer submits the transaction > Relayer pays the gas

The user authorizes an action without submitting an Ethereum transaction directly. A relayer wraps that authorization inside its own transaction and sends it onchain.

This made transactions possible without requiring every user to hold ETH first.

Bundlers, Paymasters, and Sponsored Transactions

A relayer separated authorization from submission. ERC-4337 pushed the split further by introducing dedicated infrastructure for submitting operations and paying their gas.

ERC-4337 introduces two distinct roles:

• A bundler collects UserOperations and packages them into an Ethereum transaction.

• A paymaster can agree to cover the gas for a UserOperation.

The user can therefore authorize an action without submitting the final transaction or holding ETH for gas.

User signs > Bundler submits > Paymaster pays > Smart account executes

Both paymasters and relayers usually front the gas fee and then recover it from the user in some other way, for example, by accepting payment in an ERC-20 token instead of ETH.

Sometimes, dApps and protocols configure their paymaster to cover the gas entirely and offer a genuinely gasless transaction to the user. This is a very popular onboarding strategy.

The EntryPoint contract coordinates all of it:

• Verifying each UserOperation's signature

• Calling the paymaster to confirm payment

• Executing the user's intended action

Gas doesn't disappear in either model. Someone still pays the validator in ETH. What has changed is who that someone can be.

Every separation so far changed the transaction around the account. Account abstraction changed the account itself.

The Account Behind the Transaction Became Programmable

EOAs have one authorization rule: one private key signs, Ethereum verifies.

Smart accounts move that rule into contract code. This makes multisig approval, recovery, spending limits, batching, and other custom rules possible.

Two developments pushed this model further:

1. ERC-4337 standardized how smart accounts reach Ethereum.

   Users sign a UserOperation, and a bundler submits it through the EntryPoint contract, which validates the account's rules and triggers execution.

   The UserOperation itself is not an Ethereum transaction.

2. EIP-7702 brought programmable behavior to existing EOAs.

   A type-4 transaction lets an EOA delegate to contract code while keeping the same address, balance, and private key.

That last part matters. The private key still retains authority. Delegation adds programmable behavior on top without replacing the EOA's underlying control.

That's where things stand in 2026. What lies ahead pushes the boundaries of what Ethereum transactions can do even further.

What Comes Next for Ethereum Transactions

Ethereum has already loosened its original transaction model a lot over the years. Format, fee pricing, gas payment, submission, and account behavior can now change independently. Here's what's next for Ethereum transactions, based on the directions and proposals currently under discussion.

1. Frame Transactions

Frame transactions let one transaction contain multiple execution frames.

Today, chaining approve > swap > deposit into one transaction usually needs a smart contract to coordinate each step. That means more code to deploy, audit, and secure.

Frames move that coordination into the transaction itself. The transaction carries multiple execution steps without requiring a coordinator contract in the middle.

Before: Sign > Coordinator contract > Call A > Call B > Call C

With frames: Sign > [Frame A > Frame B > Frame C]

Frames make the transaction itself more capable. Delegation pushes the same idea toward the account: making authority more precise.

2. Deeper Account Configurations and Delegation

Delegation lets an account grant limited authority without giving away full control.

Instead of approving every action separately, an account can authorize another key, app, or agent to act within predefined limits.

For example:

• Permission: Trade on App X > Spend ≤ 50 USDC > Valid for 1 hour

• Without delegation: Sign > Action > Sign > Action > Sign > Action

• With delegation: Set permission once > Allowed actions execute > Permission expires or is revoked

The account keeps ultimate control. What changes is how narrowly that control can be shared.

Delegation changes who can act and under what limits. Privacy changes how much everyone else gets to see.

3. Private Transfers

Private transfers hide selected transaction details while still proving that the transfer is valid.

A normal Ethereum transfer leaves a public trail: sender, recipient, amount, and transaction history can often be linked together.

Privacy mechanisms use cryptography to break parts of that trail.

• Public transfer: Alice > 5 ETH > Bob

• Shielded transfer: Protected transaction details > Cryptographic proof > Verified without revealing protected data

Different systems hide different information. Some obscure the recipient. Others shield amounts or relationships between transactions.

The goal is simple: Ethereum can verify what happened without revealing every detail about it.

Ethereum Transactions Are Becoming Infrastructure

The most interesting Ethereum transaction may eventually be the one nobody thinks about.

An agent receives permission once. A wallet finds the execution path. Infrastructure handles gas. Ethereum verifies the result. The transaction still exists, but increasingly as machinery beneath the experience rather than the experience itself.

That changes the question for the next decade. Instead of asking what else transactions can do, the better question may be how much of the transaction users still need to see.