On the day a TON gaming infrastructure project opened its token sale, 8,400 wallets attempted to submit allocation claims within the first 90 seconds. The sale contract was deployed on TON mainnet. The whitelist — 3,200 addresses that had completed KYC and passed sybil scoring — had been committed to the contract 48 hours prior. What happened in those 90 seconds is worth examining in detail, because it illustrates exactly what whitelist contract design has to solve and where most platform architectures fail under real load.
Of the 8,400 claim attempts: 3,200 came from whitelisted addresses and were processed correctly. 5,200 came from non-whitelisted addresses and were rejected at the contract level — consuming gas, triggering a bounce message, and returning the sent TON to the sender. Network message queues on TON handled the throughput cleanly, given TON's sharded architecture and its asynchronous message model. The sale was fully subscribed within four minutes, with every valid allocation recorded on-chain and every invalid attempt rejected without manual intervention.
This outcome was not accidental. It is the result of specific contract design choices that differ meaningfully from how whitelist mechanics work on Ethereum, EVM L2s, or older launchpad architectures.
How the Whitelist Contract Works on TON
The Tonstarter whitelist contract is a FunC smart contract deployed on TON mainnet prior to sale day. Its core data structure is a mapping from TON address (256-bit) to allocation record — a struct containing the allocated amount in TON jetton units, the KYC tier that authorized the allocation, the sybil score tier, and a boolean flag indicating whether the allocation has been claimed.
Whitelist population happens before the sale opens. When a wallet completes KYC verification and passes sybil scoring, the platform's backend sends a signed transaction to the whitelist contract, adding the address and its allocation record. This transaction is on-chain and verifiable: any participant can check their own whitelist status by querying the contract state using TONviewer or any TON blockchain explorer. There is no off-chain database that is the authoritative source of whitelist status — the contract state is the authoritative source.
The TON Connect Binding Step
Before whitelist population, each participant must complete a wallet binding step via TON Connect — TON's wallet authentication protocol, supported by Tonkeeper, TONhub, and other compatible wallets. The binding step requests a signed message from the wallet's private key, establishing cryptographic proof that the person completing KYC controls the wallet address they are registering. This binding prevents a common attack: completing KYC with one identity and then claiming the allocation to a different wallet that was farmed or purchased.
The signed message contains: the participant's Tonstarter account identifier, the TON wallet address, a timestamp, and a nonce. The platform verifies the signature, binds the KYC approval to the specific wallet address, and only that address will be accepted during whitelist population. If a participant loses access to their original wallet, there is a re-binding flow — but it requires re-completing the KYC verification step, not just a new wallet connection, to prevent the binding mechanism from being circumvented.
Gas Economics on TON vs. Ethereum and L2s
The cost of participating in a whitelisted token sale is meaningfully lower on TON than on Ethereum mainnet or most EVM-equivalent chains. TON gas costs for a whitelist claim transaction run in the range of 0.01–0.05 TON (under $0.10 at typical TON prices). On Ethereum mainnet during congested periods, equivalent whitelist claim interactions have historically cost $20–$150 in gas. EVM L2s (Arbitrum, Base, Optimism) bring this down to $0.05–$2 per transaction but introduce bridging costs and latency that complicate the flow.
"TON's cell-based storage model and sharded architecture mean that a sale contract handling 8,000 simultaneous claim attempts is not competing with the rest of the network for gas — each shard processes its portion of the load independently."
This is not a trivial operational difference. A platform deploying on Ethereum in 2021 had to model sale-day gas cost spikes into the participation experience — a participant who expected to pay $30 in gas discovering they owed $200 on sale day was a predictable failure mode. TON's gas model is deterministic enough that the sale-day cost can be communicated to participants with meaningful precision, and low enough that it does not materially affect participation economics.
TON network gas fees and finality are governed by TON consensus, not by Tonstarter. The platform does not control or modify gas costs — they are a property of the network layer. What the platform designs is the contract's gas efficiency: how many operations are executed per claim transaction, whether gas is refunded for failed claims (it is, via TON's bounce mechanism), and whether the claim flow requires single or multiple on-chain transactions.
One-Shot vs. Continuous Claim Contract Design
There are two architectural patterns for sale contracts: one-shot and continuous. The distinction matters most for how the sale handles participants who miss the opening window or whose transactions fail.
A one-shot sale contract accepts claims only within a defined window (e.g., 24 hours from sale open). Once the window closes, the contract stops accepting new claims, and any unclaimed allocations are handled according to a predefined rule — either returned to the project treasury or redistributed to a pro-rata top-up pool. One-shot contracts are simpler to audit, easier to communicate to participants, and less vulnerable to gaming through delayed claiming strategies.
A continuous claim contract accepts claims until the total allocation is exhausted, regardless of timing. Participants can claim at any point after the sale opens. This design is more participant-friendly in theory — it removes the "be online at exactly the right second" pressure — but it creates a different problem: participants who wait to see early price action before claiming create an information asymmetry where later claimers have more data than earlier claimers, which is inconsistent with a pro-rata allocation model.
Tonstarter uses a one-shot window model with a claim period of 24–48 hours from sale open, depending on the project's participant geography and Telegram community time zone distribution. Unclaimed allocations at window close are handled according to the project's stated unclaim policy — documented in the sale terms before the sale opens, not decided unilaterally after.
What the Whitelist Contract Gates On
At claim time, the contract checks three conditions in sequence before executing the allocation transfer:
- Address presence: Is the sending address in the whitelist mapping? Rejected immediately if not.
- KYC status flag: Is the KYC tier flag for this address set to the required tier for the sale? A sale requiring Tier 2 KYC rejects any address that only completed Tier 1.
- Sybil score tier: Does the address's score tier qualify for the allocation amount it is claiming? An address in the low-score tier attempting to claim a Gold-tier allocation is rejected.
All three checks happen within a single contract execution, with no off-chain calls. The contract is self-contained: its whitelist state is populated before the sale, not maintained live with external API calls. This architecture is essential for sale-day resilience — a network or API outage on sale day cannot corrupt the whitelist state, because the whitelist state is entirely on-chain.
The full whitelist architecture, including the integration with KYC approval status and sybil scoring, is explained in the platform documentation. If you are a project evaluating how a Tonstarter-facilitated token sale would handle your participant base, the How It Works page covers the end-to-end technical flow, and the team is reachable at apply.html for project-specific discussions.
