Skip to main content

Compatibility with Tezos L1

The Michelson Interface is designed to behave as closely as possible to Tezos Layer 1.

Compatible features​

Most of the features, including the following ones work identically to Tezos Layer 1. Therefore, users may safely refer to the linked Tezos documentation for all these aspects.

Account types​

Among the types of accounts desscribed in the Tezos L1 documentation, the following are available in the Michelson interface:

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

You can find more details on Accounts in the Octez documentation.

Smart contracts​

Smart contracts can be developed using the same languages as in Tezos L1 (e.g., SmartPy and LIGO).

Refer to section Smart contracts in the Tezos documentation.

RPC reference​

Tezos X nodes provide the same RPCs as Tezos L1 nodes, on the Michelson endpoint (see Network parameters).

Refer to the RPC reference in the Octez documentation (also available as a set of OpenAPI descriptions).

warning

Note however that some of these RPCs are handled differently on Tezos X, due to the different context (e.g. no delegation possible), or are not implemented yet. The complete list of the differences will be compiled here.

Tokens​

Tokens defined and used in the Michelson interface generally adhere to different standards such as FA1.2, FA2, or FA2.1.

Refer to section Tokens in the Tezos documentation.

dApps​

For developping distributed applications (dApps) on the Michelson interface, refer to section Dapps in the Tezos documentation.

Tezos Unity SDK​

For developing games and other Unity applications on top of Tezos X you can use the Tezos Unity SDK as described in the Tezos documentation. Note that this kit can be used both with the Michelson interface and with the EVM interface on Tezos X.

Known differences​

The rest of this page documents the known differences between the Michelson interface and Tezos Layer 1.

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.

Inclusion fees are burnt (on the Michelson interface)​

Inclusion 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 hold 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​

As a consequence of the fact that "SOURCE returns the null address for cross-interface calls" (see above), 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.

Voting power​

The Michelson instructions VOTING_POWER and TOTAL_VOTING_POWER diverge from L1 at runtime as follows (but typecheck is identical):

  • In Tezos X, they return a hardcoded 0
  • In L1, they return the real staking weights.

The rationale is that Tezos X governance (covering the kernel and sequencer) is managed on Layer 1, by Tezos L1 bakers. There is no governance process directly on Tezos X, hence no voting power.

Unsupported features​

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

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

Not yet implemented features​

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
  • Address indexing (feature introduced in protocol T)