TAC accommodates two distinct categories of tokens in its ecosystem. The first category consists of 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. The second category comprises tokens bridged from TON, which operate under CCL control on the TAC side and are guaranteed to be ERC20-compliant. These bridged tokens typically maintain 9 decimals rather than the standard 18.

​
Token Implementation Requirements

All tokens within the system must implement the IERC20 interface standard. 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

An important consideration regarding metadata is its upgradeability. While all metadata fields except l1Address can be modified from the TON side, these changes are not currently reflected on the TAC side. The metadata remains static from the moment it first appears in the cross-chain environment.

​
Token Synchronization Process

Synchronization occurs automatically within the system. When a user attempts to execute any transaction with tokens, the sequencer automatically creates necessary tokens 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 Bridge Process

The process begins when a user initiates a cross-chain message transaction on the cross-chain contract, 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 CrossChainLayerTokenFactory. Upon deployment completion, the token’s address is recorded in a correspondence dictionary linking TONTokenAddress to Layer2TokenAddress.

​
TAC to TON Bridge Process

When bridging from TAC to TON, a user initiates a cross-chain operation on the cross-chain contract, 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

Liquidity flows from TON into TAC dApps through a structured process. For instance, when creating a Uniswap trading pair (TokenA/TokenB) on TAC, users first initiate two separate transactions to send each token from their wallet to CCL. If either token doesn’t exist on TAC, it’s automatically deployed. These bridged tokens then provide liquidity in the Uniswap pair.

​
Token Decimal Management

The system handles decimal precision differences between chains carefully. TON-origin tokens typically use 9 decimals and maintain this precision when bridged to TAC. The EVM-based TAC environment naturally accommodates these tokens alongside standard 18-decimal tokens. However, bridging back to TON presents challenges, particularly for 18-decimal tokens originating in TAC (such as LP tokens). To address this, strict limits are implemented on unbridging to TON to prevent potential numerical overflow issues.

​
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 Uniswap v2 scenarios, the system handles two transactions for TVM tokens. These are combined into a single Merkle message containing token deployment and transfer instructions. When Uniswap 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.

​
Cross-Chain Swaps

For TON-to-token swaps, users create TON transfer transactions with specific EVM parameters. The sequencer processes this into a Merkle 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.

ArchitectureWhat is TAC