Home

Deposit Transaction Handling (Type 0x7E)

4 min read

Deposit Transactions (Type 0x7E) are a specialized transaction type in the OP Stack used to transition state based on events occurring on Layer 1 (L1) or to execute protocol-mandated system updates. Unlike standard transactions, they are not signed by a user and are instead derived directly by the protocol.

1. Key Characteristics of Deposit Transactions

A deposit transaction contains unique fields that differentiate it from Legacy or EIP-1559 types:

  • SourceHash: A unique identifier that links the L2 transaction to its L1 source (e.g., a specific user deposit event on L1).
  • Mint: A field representing Ether that is minted on L2 (after being locked on L1). This is distinct from the Value field.
  • IsSystemTransaction: A flag indicating if the transaction is a System Transaction. These are executed in an unmetered environment and do not contribute to the block’s gas limit.
  • Unsigned: Deposits cannot be signed; attempting to generate a signature hash for one will result in a panic. They use dummy “zero” values for V, R, and S.

2. The Specialized Execution Lifecycle

The protocol handles these transactions with a specific priority and execution logic that overrides standard mempool rules.

Step 1: Force-Inclusion at Block Start

During block production, the miner receives a list of deposit transactions (genParam.txs) derived from L1. These are force-included at the very beginning of the block before any transactions from the L2 tx-pool are processed.

Step 2: Decoding the Envelope

When the EVM processes the block, it uses the EIP-2718 envelope approach. It identifies the 0x7E type byte and uses a specialized decoder to extract the deposit metadata. Because there is no signature, the From address is extracted directly through protocol rules rather than cryptographic recovery.

Step 3: Minting and Value Transfer

Before the contract code (if any) is executed, the state modifier performs specialized balance updates:

  1. Minting: If the Mint field is non-nil, that amount is added to the sender’s balance.
  2. Value Transfer: The Value is then transferred from the sender to the recipient.

Step 4: Unmetered Execution (System Txs)

If IsSystemTransaction is true, the EVM skips the standard gas charging for that execution frame. This allows the protocol to update system-level contracts (like the L1 block info oracle) regardless of the remaining gas in the block.

3. Code Representation of the Lifecycle

A. Miner Force-Inclusion (miner/worker.go)

// Inside generateWork: Deposit txs are processed first
for _, tx := range genParam.txs {
    // Set context for the specific deposit
    work.state.SetTxContext(tx.Hash(), work.tcount)

    // Commit the deposit before even looking at the tx-pool
    err = miner.commitTransaction(work, tx) //
    if err != nil {
        return &newPayloadResult{err: fmt.Errorf("failed to force-include deposit: %w", err)}
    }
}

B. Handling Mint and Value (core/types/deposit_tx.go)

The DepositTx struct is a specialized transaction type (0x7E) used in the OP Stack to handle L1-to-L2 state transitions and system-level updates. Below is the full representation of the struct as defined in the source code:.

type DepositTx struct {
    // SourceHash uniquely identifies the source of the deposit
    SourceHash common.Hash

    // From is exposed through the types.Signer, not through TxData
    From common.Address

    // nil means contract creation
    To *common.Address `rlp:"nil"`

    // Mint is minted on L2, locked on L1, nil if no minting.
    Mint *big.Int `rlp:"nil"`

    // Value is transferred from L2 balance, executed after Mint (if any)
    Value *big.Int

    // gas limit
    Gas uint64

    // Field indicating if this transaction is exempt from the L2 gas limit.
    IsSystemTransaction bool

    // Normal Tx data
    Data []byte
}

Key Components of DepositTx:

  • SourceHash: This uniquely identifies the source of the deposit, such as a specific L1 event or an L1 info deposit included at a specific L2 block height.
  • From: Unlike standard transactions where the sender is recovered from a signature, the sender of a deposit is provided directly via protocol rules.
  • Mint and Value: If the Mint field is populated, that amount is added to the account balance first; the Value is then transferred from the sender’s balance to the recipient.
  • IsSystemTransaction: When this boolean is true, the transaction is executed in an unmetered environment and does not count against the block’s gas limit.
  • Signature Handling: Deposit transactions are unsigned; the protocol explicitly panics if a signature hash is requested for this type because they are derived rather than signed by users.

C. Metering Logic (core/types/transaction.go)

func (tx *Transaction) IsSystemTx() bool {
    return tx.inner.isSystemTx() // Returns true for 0x7E system deposits
}

// In the EVM, if IsSystemTx() is true, gas consumption is bypassed

Graph View

Backlinks