Skip to main content

Compatibility with Tezos L1

The Michelson Interface is designed to behave as closely as possible to Tezos Layer 1. This page documents the known differences.

Fees​

Execution and storage fees are burnt​

On Tezos L1, transaction fees are credited to the baker who includes the operation. On Tezos X, execution and storage fees are burnt — there is no equivalent of a baker reward at the Michelson interface level.

DA fees are burnt (on the Michelson interface)​

Data availability fees are burned from the Michelson interface's perspective. The sequencer is compensated through the EVM runtime's sequencer pool instead. This means fee balance updates in Michelson receipts do not credit any address.

Accounts​

SOURCE returns the null address for cross-interface calls​

When a transaction is initiated via a cross-interface call (i.e., from the EVM interface), the Michelson SOURCE instruction returns the null address tz1Ke2h7sDdakHJQh8WX4Z372du1KChsksyU, not the originating EVM alias. This is because Michelson requires the source to be a user account.

Aliases cannot directly receive tez​

Michelson aliases (KT1 contracts created for EVM accounts) automatically forward any tez they receive to the originating EVM account via the gateway. You cannot send tez directly to an alias address and retain it there.

Blocks​

First block level may be greater than zero​

If the Michelson runtime was introduced after the chain genesis, its first block will be at a level greater than zero. This differs from a fresh Tezos L1 deployment where the first block is at level 1.

Cross-interface operations appear with null source​

Operations triggered by cross-runtime calls appear in Michelson runtime blocks with tz1Ke2h7sDdakHJQh8WX4Z372du1KChsksyU as the source. Indexers can cross-reference with the EVM runtime block using the cross-runtime call identifier emitted by the gateway.

Tez precision​

The Michelson Interface uses 6-decimal precision for tez (mutez), consistent with Tezos L1. When tez crosses to the EVM interface, it is expressed with 18-decimal precision. Values below 10⁻⁶ tez cannot be represented in mutez and will be truncated. See Accounts and Aliases for details.

Supported features​

The Michelson Interface supports most features of the Tezos Seoul protocol. This section lists what is supported, partially supported, or not available.

  • User account operations: reveals, transfers
  • Smart contract operations: originations, calls, views
  • Lazily-deserialized storage (big maps)
  • Internal operations and operation batching
  • Operation simulation (via the /helpers/scripts/simulate_operation RPC)

Not supported​

The following features do not apply in a layer 2 context and are intentionally excluded:

  • Baking, attestations, delegations
  • Smart Rollup operations
  • Consensus and governance operations

Not yet implemented​

The following features from Tezos layer 1 are not yet available in the Michelson Interface:

  • BLS addresses (tz4)
  • Ticket transfers
  • Events
  • Sapling
  • Timelocks
  • Global constants

Account types​

Address typeStatus
tz1 (ed25519)✅ Supported
tz2 (secp256k1)✅ Supported
tz3 (P-256)✅ Supported
tz4 (BLS)🔄 In progress
KT1 (smart contracts)✅ Supported
sr1 (smart rollup)❌ Not supported