Token OPS

TAC’s EVM Layer is a permissionless layer 1 and it supports Native TAC-originated tokens, which includes liquidity provider tokens and tokens emitted by dApps, while these tokens are expected to follow the ERC20 standard, this isn’t directly enforced at the protocol level, and tokens bridged from TON, which operate under TON Adapter on the TAC side and are guaranteed to be ERC20-compliant. These tokens typically maintain 9 decimals.

​

Token Implementation Requirements

When deploying TON-origin tokens in TAC, the system validates several standard ERC20 parameters, including:

• name (string)
• symbol (string)
• decimals (uint8)
• description (string)
• image (string)
• l1Address (string) - A custom parameter specifically for TON jetton token address

​

Token Synchronization Process

Synchronization occurs automatically within the system. When a user attempts to execute any transaction with TON native tokens, the sequencer automatically creates wrapped version of the tokens on TAC if they don’t exist. This process involves the sequencer creating a token deployment operation and verifying the token’s existence at the blockchain level.

​

TON to TAC Transfer Process

The process begins when a user initiates a message transaction through the TON Adapter, specifying the token address in the TON network. After transaction execution, sequencers index a created log message. They then verify the token’s creation on TON, retrieve its metadata, and form a message for the Merkle tree. This message facilitates new token deployment via the TokenFactory. Upon deployment completion, the token’s address is recorded in a correspondence dictionary linking TONTokenAddress to Layer2TokenAddress.

​

TAC to TON Transfer Process

When transferring from TAC to TON, a user initiates an operation through the TON Adapter, indicating the token’s TAC network address. This creates an event that sequencers monitor. After verifying the token’s existence on TAC and retrieving its metadata, sequencers form a Merkle tree. The process concludes with a Mint operation, which includes StateInit in the message for automatic token deployment if needed.

​

Liquidity Management

When users provide liquidity to a Curve trading pair (TokenA/TokenB) on TAC using TON-origin tokens, the native tokens remain locked in the TAC bridge on the TON blockchain. The TAC system mints wrapped versions of these tokens on the TAC EVM chain, which are then supplied to the liquidity pool.

This design enables the original TON-native tokens to be directly accessible for use within TON dApps, while their wrapped EVM versions provide liquidity on TAC. Unifying the liquidity across both chains in this manner offers several advantages such as improved capital efficiency and a seamless user experience.

​

Token Decimal Management

TAC handles decimal differences between TON and EVM tokens smoothly. TON tokens usually have 9 decimals, and they keep this precision when bridged to TAC. The TAC EVM environment supports these tokens alongside the typical 18-decimal EVM tokens.

But if you’re thinking about bridging 18-decimal TAC tokens (like LP tokens) back to TON, there are some limitations in place. This is to avoid any potential issues with numerical overflow.

While the TAC EVM side allows 18-decimal tokens, the TON side isn’t really set up for that. So if you’re planning to use those kinds of tokens, it’s best to stick to the EVM environment for now.

​

Smart Contract Architecture

On the TAC network, the system implements a standard proxy upgrade pattern. Each contract consists of two key components: a proxy contract handling state storage, and an upgradeable implementation contract managing logic. This architecture enables secure contract upgrades while maintaining system stability.

​

Address Calculation and Pairing

Token address pairing follows a deterministic approach. For tokens originating from TVM, the wrapped token’s paired address is calculated based on the token’s TON metadata. Similarly, for EVM-originated tokens, the paired token address is calculated using the token’s EVM metadata. This system allows for pre-calculation of paired token addresses even before they exist in the target network.

​

Practical Implementation Examples

​

TON Token Deposits

Consider the process of transferring FNZ tokens from TON to TAC. The user sends FNZ tokens to the Jetton Proxy contract wallet, which handles all token transfer operations. Sequencers monitor these transfers and create a MerkleMsg containing metadata for token deployment, minting instructions, and any necessary unlock parameters. All operations occur within a single transaction.

​

LP Token Operations

In Curve scenarios, the system handles two transactions for TVM tokens. These are combined into a single Merkle message containing token deployment and transfer instructions. When Curve deploys a new LP token, the system records it and manages any necessary unlocking or burning events. The process concludes with liquidity transfer and new token appearance on TON.

​

Token Swaps

For TON-to-token swaps, users create TON transfer transactions with specific EVM parameters. The sequencer processes this into a message that includes wrapped TON deployment. After the DEX pool executes the swap and locks tokens on the EVM side, users receive their TVM version of the exchanged token.