Architecture
This section provides a high-level overview of the smart contract's architecture. Understanding how the smart contract is structured is essential for developers, administrators, and anyone who wants to customize or maintain the system.
High-Level Overview
The TokenTable TVM smart contract is designed as a scalable, secure, and efficient solution for token distribution on the TON blockchain. It leverages merkle proofs for wallet address verification, ensuring trustless and cost-effective token distribution. Here’s an overview:
Merkle Proof Architecture: The core of the contract uses merkle proofs to verify user wallets before token distribution. This enables efficient verification without exposing the entire user list on-chain, ensuring both privacy and reduced gas costs.
Token Distribution Logic: Once a user's wallet is verified through a merkle proof, the smart contract initiates the token distribution process, adhering to preset rules and conditions.
Blockchain Interaction: All interactions with the blockchain, including wallet address verification and token distribution, are handled on-chain through TON's secure, decentralized network.
Security: The contract is designed with strict validation mechanisms, leveraging cryptographic proofs to ensure only eligible users receive tokens, providing transparency and security.
Component Contracts
The TokenTable TVM smart contract solution is structured around key contract components, each designed to fulfill a specific role in the token distribution process using merkle proofs. Below is an overview of the core components:
Main Distributor Contract
Primary Role: The Main Distributor Contract manages the overall token distribution process. It holds the root hash of the Merkle tree, which is used to verify user wallets against a predefined list of eligible recipients.
Merkle Root Management: The merkle root is securely stored in this contract, acting as the reference point for wallet verification during token claims.
Token Distribution Logic: Upon receiving a valid merkle proof from a user (submitted through the leaf), the contract verifies the proof against the stored merkle root. If the verification is successful, the contract initiates token distribution to the user's wallet.
Leaf Contracts
Wallet Verification: Leaf Contracts are designed to validate individual wallets by processing merkle proofs generated off-chain. Each contract represents a "leaf" node in the merkle tree, corresponding to an individual user wallet.
Proof Submission: Users interact with their corresponding Leaf Contract by submitting a merkle proof, which the contract uses to confirm their eligibility based on the data in the merkle tree.
Security and Efficiency: By using merkle proofs, the Leaf Contracts efficiently verify large sets of users without requiring extensive on-chain data, reducing cost and execution time.
Token Claim Execution: Once a wallet address is verified, the Leaf Contract communicates with the Main Distributor Contract to trigger the actual token distribution.
Additional Features of the Contracts
Data Integrity: The use of cryptographic merkle trees ensures data integrity, allowing the contract to securely verify claims without revealing sensitive information.
Scalability: Both the Main Distributor and Leaf Contracts are designed to handle high volumes of users, ensuring scalable token distribution across a wide network.
Gas Optimization: The contracts minimize gas costs by processing wallet verification off-chain (via Merkle proofs) and only executing the necessary steps on-chain.
Sequence Diagram
For a more detailed understanding of how data flows within the application, we've prepared a data flow diagram:
Data flows from a user claim into the leaf contract, to the main contract, and then to the user wallet. Understanding this data flow is helpful for developers who need to work on integrations or customize the system.
Understanding the architecture and components of our web application is crucial for developers and administrators, as it forms the foundation for customization, troubleshooting, and scaling. In the following sections, we'll delve into specific aspects of usage.
Last updated