Tokens

The native coin on Etherlink has the symbol XTZ, like the tez tokens on Tezos layer 1. You can get XTZ from many exchanges and applications including IguanaDEX.

Etherlink provides a wrapped version of XTZ named WXTZ that is an ERC-20-compliant token for ease of interacting with decentralized applications. For more information about WXTZ, see WXTZ.

Token addresses

These are some of the other tokens that are available on Etherlink. Click the address to go to the block explorer page for the token:

Name	Symbol	Mainnet address	Testnet address
Wrapped XTZ (see WXTZ below)	WXTZ	0xc9B...3EAb	0xB1E...51d8
Etherlink USD	eUSD	Coming soon	0x1A7...Ce4f
Tether USD	USDT	0x2C0...fE6a	0xD21...2d4F
USD Coin	USDC	0x796...00F9	0xa7c...B58a
Wrapped Ether	WETH	0xfc2...B401	0x8DE...88C1
Tezos BTC	tzBTC	Coming soon	0x6bD...Fb27
Wrapped BTC	WBTC	0xbFc...3d0F
Wrapped BNB	WBNB	0xaA4...0d8C
Wrapped AVAX	WAVAX	0xe82...B644
SHIBA INU	SHIB	0xBBD...5181

WXTZ

WXTZ is a token created to replicate the functionality of Wrapped Ether (WETH), but specifically for the XTZ native token on Etherlink. The goal of WXTZ is to facilitate the use of XTZ in decentralized applications (dApps) and protocols that require ERC-20-like tokens.

For more information and the code of the token, see the etherlinkcom/token-deployments repository.

Wrapping & Unwrapping

The token follows the WETH9 interface for compatibility:

• Wrapping XTZ: The deposit() method accepts XTZ and returns WXTZ
• Unwrapping XTZ: The withdraw(wad) method accepts WXTZ and returns XTZ

The original WETH9 contract developed with Solidity compiler version 0.4.x also supports the fallback() method, but WXTZ does not. Supporting this hook would cause function signatures that do not match the contract's to act as if they are supported and successfully executed.

Bridging with LayerZero OFT

WXTZ implements the Omnichain Fungible Token (OFT) standard from LayerZero. This standard allows WXTZ to be bridged in a secure and capital-efficient way across different chains through direct minting and burning of the supply.

Here are the chains the token is deployed on:

Chain	Mainnet address
Etherlink	0xc9B...3EAb
Ethereum	0xc9B...3EAb
Base	0x91F...f51D
BNB Chain	0x91F...f51D
Arbitrum One	0x742...4B2D

The bridging system is not available yet, which means that you cannot bridge WXTZ from one chain to another. You can still use the WXTZ on Etherlink as a classic wrapped token.

Gasless approval with ERC20Permit

The token also implements the ERC20Permit standard from Openzeppelin. This standard allows users to approve token transfers via gasless signatures instead of on-chain transactions.

This feature leverages the EIP-2612 standard to facilitate off-chain authorization for token transfers.

Audit & Security

The WXTZ contract was audited by Omniscia.io. The final report is here: https://omniscia.io/reports/etherlink-cross-chain-token-665c8ac479e20900180f383b

WXTZ supports OFT to simplify cross-chain compatibility. However, if the OFT bridge gets compromised, all the XTZ in the contract on Etherlink could be stolen by a malicious attacker with these steps:

1. Create and deploy a fake WXTZ contract on another EVM chain
2. Mint a maximum amount of WXTZ on the other chain
3. Connect to the contract on Etherlink using setPeer()
4. Transfer the WXTZ to Etherlink
5. Withdraw the XTZ locked in the WXTZ contract on Etherlink

The Etherlink team has taken measures to protect users native to Etherlink and bridged across EVM chains.

These are the measures to protect Etherlink users:

• We overrode the _credit method used by LayerZero to bridge tokens between chains. We added a condition checking that the receiving amount of WXTZ can't exceed the amount of XTZ stored in the contract. The result is that only the WXTZ supply bridged using the LayerZero protocol should be at risk, and not the local WXTZ on Etherlink. If an attacker succeeds in hacking the bridge, they will only be able to transfer the difference between the amount of XTZ stored in the contract and the local total supply of WXTZ on Etherlink. In this way, all Etherlink users who own their WXTZ locally will still have their WXTZ backed 1:1 by XTZ in the contract.

• To protect bridged users, the Etherlink team overrode the setPeer() method that connects and disconnects WXTZ contracts on different chains. By adding a 2 day timelock to the setPeer() method, there is a 2 day delay between initially creating a connection and the connection being executed. If a hacker takes ownership of the contracts and starts connecting or disconnecting, bridged users will have 2 days to bridge back all their funds on Etherlink and withdraw their XTZ.