Skip to main content
Version: 0.7.0

Native Transfer Flow

Send XTZ from your tz1 account (through its EVM alias) to a 0x destination on the EVM runtime.

Sequence​

The hash returned to the dApp is a synthetic hash — the real kernel-synthesized EVM hash is resolved lazily. See EIP-1193 → synthetic hash.

Example​

await window.ethereum.request({
  method: 'eth_sendTransaction',
  params: [{
    from: '0x341af4de1e67241d8d2536b2ea47c7e9debf7cb2',
    to: '0xRecipientAlias...',
    value: '0xde0b6b3a7640000', // 1 tez
  }]
});
AliasForwarder — sending to an alias

EVM aliases of Tezos accounts cannot hold native XTZ. If the destination 0x address is the alias of a tz1 account, the kernel re-forwards the amount to the origin tz1 (the AliasForwarder mechanism) — the alias's EVM balance stays at ~0 and the XTZ lands on the underlying tz1. ERC-20 tokens are different: they live in contract mappings and the alias really holds them. See Send XTZ (wallet docs) for how the wallet surfaces this.

Value encoding​

Tezos uses mutez (1 tez = 1,000,000 mutez). The relayer converts wei → mutez internally:

Wei (hex)Tez
0xde0b6b3a76400001 tez
0x6f05b59d3b200000.5 tez
0x2386f26fc100000.01 tez

The conversion is exact, never floored: a wei value that is not divisible by 10¹² (1 mutez) is rejected with SubMutezPrecisionError (JSON-RPC -32602) before any signing popup opens, so no sub-mutez remainder can be silently lost.

See also​