This requires a pre-requisite understanding of TON wallets and TON interactions with assets

TLDR:

  1. Wallet = Smart contracts + whitelisted public keys
  2. Assets = Tokens owned by wallets (Jettons, NFTs, etc)
  3. Interactions = User-signed raw messages (using a private key) are sent to the wallet, which then dispatches transactions to smart contracts

NOTE: The high level overview of Skate flow is discussed in this section

​
1. Intents on TON

Common non-custodial TON wallets, like Tonkeeper and TonHub, allow users to store their mnemonics (private keys) locally and create standard TON wallets (V4R2, V5) for blockchain interactions. These wallets implement the TON Connect protocol, enabling users to sign raw messages for wallet interactions using their locally stored private keys.

Skate uses 2 workflows to register user intent on TON:

  1. TON Connect’s signData (see request schema) for interaction that do not involve asset transfers.

  2. Skate’s TON Gateway for interaction that involves assets, using an external event emitted with custom payload. This is necessary because TON smart contracts do not support token approval mechanisms.

​
2. Intent registration

At the kernel level, a general intent consists of four fields. For TON, Skate currently supports only the main chain (workchainId=0), and the user’s address is represented as a raw 32-byte address.

Typically, a user either signs their intents via the frontend or sends staging assets to the SkateGateway contracts. These intents are then collected by the Skate Relayer and processed by the Skate Executor. The outcome of a processed intent is a set of executable tasks.

IMessageBox.sol
struct IntentData {
    address appAddress;
    bytes intentCalldata;
}

struct Intent {
    IntentData intentData;
    bytes32 user;
    bytes signature;
    uint256 vmType; // 1 = EVM | 2 = TON | 3 = SOLANA | etc..
}

​
3. Task creation

A task consists of the following structure: the task calldata on TON is a serialized raw message that will be executed on the TON kernel. To construct the message and validate the signed TON intent, Skate VM will implement precompiled op-codes at the chain level, ensuring that the message is correctly structured and the intent is valid for execution.

IMessageBox.sol
struct Task {
    bytes32 appAddress;
    bytes taskCalldata;
    bytes32 user;
    uint256 chainId;
    uint256 vmType; // 1 = EVM | 2 = TON | 3 = SOLANA | etc..
}

NOTE: As of 7 September 2024, the verification of TON messages and the creation of calldata are handled off-chain. This will remain the case until the next testnet upgrade is rolled out.

After the tasks are created, the serialized TON message is verified by Skate AVS and then scheduled for execution on TON periphery contracts.

Case StudiesTON Periphery