How to Design a Tiered Sale Structure (Seed, Private, Public)

A tiered token sale segments investors into distinct groups based on their entry point, commitment, and risk profile. The primary phases are Seed, Private, and Public. Seed rounds involve early backers like founders' networks and receive the lowest price and longest vesting. Private sales target venture capital and strategic partners with moderate discounts. Public sales are open to the broader community, often at the highest price and with immediate liquidity. This structure allows projects to reward early supporters while gradually decentralizing ownership.

Designing each tier requires defining clear parameters: token price, allocation size, vesting schedule, and lock-up periods. For example, a typical structure might allocate 15% of the total supply to Seed at $0.10 per token with a 24-month linear vesting and a 12-month cliff. The Private sale could get 10% at $0.15 with an 18-month vesting. The Public sale, often conducted via a Liquidity Bootstrapping Pool (LBP) or Fair Launch, might sell 5% at a market-driven price with no lock-up. Smart contracts like OpenZeppelin's VestingWallet are commonly used to enforce these terms programmatically.

Key technical considerations include contract security and compliance. Each sale tier should be managed by separate, audited smart contracts to isolate risk. Use a mintable ERC-20 token controlled by a Ownable contract to release tokens according to the vesting schedule. Implement a whitelist mechanism for Seed and Private rounds using Merkle proofs for gas efficiency. For the public sale, consider a Dutch auction or fixed-price sale with a hard cap to prevent oversubscription and ensure fair distribution.

Strategic timing between tiers is critical. A minimum gap of 3-6 months between the closing of the Private sale and the Public sale is standard, allowing for product development milestones to be hit, which supports the token's valuation at launch. This tranched approach also helps manage regulatory scrutiny by clearly separating sophisticated investor rounds from public offerings. Always disclose vesting schedules and tokenomics transparently in the project's documentation to build trust.

Common pitfalls to avoid include over-allocating to early rounds, which can lead to excessive sell pressure at launch, and setting vesting periods that are too short. Use SAFT (Simple Agreement for Future Tokens) or similar legal frameworks for private sales to ensure regulatory compliance. Post-sale, the project's treasury—often funded by a separate allocation—should be managed via a multi-signature wallet or DAO to ensure funds are used according to the roadmap outlined during the sale.

A tiered sale structure segments a token distribution into distinct rounds—typically Seed, Private, and Public—each with different pricing, vesting schedules, and access rights. This model is standard for aligning investor incentives with project maturity and regulatory compliance. Before writing code, you must define the key parameters for each round: the token price (often in USD or a stablecoin equivalent), the allocation size (total tokens available), any individual caps, and the vesting schedule. These parameters are commonly stored in a SaleRound struct within your smart contract.

Smart contract security and access control are foundational. You will need a robust role-based access control system, such as OpenZeppelin's AccessControl, to manage permissions for starting rounds, pausing sales, and withdrawing funds. A pausable mechanism is critical for emergency stops. Furthermore, you must decide on the payment currency—whether you will accept only a specific stablecoin like USDC, native chain currency (e.g., ETH), or multiple tokens. Implementing a secure price oracle or a trusted price feed is necessary if your token price is pegged to a fiat value to prevent manipulation.

Vesting logic is a complex but essential prerequisite. You must implement a mechanism to lock purchased tokens and release them linearly over time. This often involves a separate VestingWallet contract or an internal schedule that tracks each investor's totalAllocated, claimed, and startTimestamp. The contract must calculate releasable amounts on-chain, which requires careful consideration of timestamp manipulation and safe math operations. Use established libraries like OpenZeppelin's SafeERC20 and SafeCast to handle token transfers and integer conversions securely.

You must also design your contract's state machine to manage the progression from one sale round to the next. Common states include NotStarted, SeedSale, PrivateSale, PublicSale, and Finished. Transitions between these states should be guarded functions, often triggered by the project admin. It's crucial to enforce that rounds occur in sequence and that parameters like the total supply of tokens for sale are not exceeded across all rounds, preventing inflation or allocation errors.

Finally, consider the user experience and integration requirements. Your contract will need view functions for users to check their eligibility, allocated amount, and vesting details. You should also plan for a claim mechanism that allows users to withdraw their vested tokens over time, which will be a frequent transaction. Thorough testing with tools like Foundry or Hardhat, simulating all sale rounds and edge cases, is a non-negotiable prerequisite before any deployment to a live network.

A tiered sale contract manages multiple investment rounds within a single system. The core design involves a primary sale contract that holds the token supply and defines separate sale tiers, each with its own configuration: a fixed token price (often in a stablecoin like USDC), a hard cap for total contributions, and individual purchase limits. Common tiers include a seed round for earliest backers, a private sale for strategic investors, and a public sale for the community. Using a single contract prevents fragmentation, ensures consistent logic for vesting and claims, and simplifies security audits.

The contract must enforce strict access control and state transitions. Typically, an admin role (often the project's multisig) can add participant addresses to whitelists for specific tiers before they are active. The contract should progress through phases: setup, active sale for each tier (which can be sequential or overlapping), and a final claim phase. Critical validations include checking the sender is whitelisted for the active tier, that the payment amount is within personal and tier caps, and that the sale has not reached its hard cap. Failed transactions should revert with clear reasons.

Vesting schedules are a key differentiator between tiers. Seed investors might have a 12-month cliff followed by 24-month linear vesting, while public sale participants could have immediate or short-term vesting. Instead of distributing tokens immediately, the contract should mint or allocate tokens to an internal ledger and allow users to claim vested amounts over time. A common pattern is to store for each user: totalAllocated, totalClaimed, and a vestingStart timestamp. A claim() function then calculates the releasable amount based on a linear formula: vestedAmount = (totalAllocated * (block.timestamp - vestingStart) / vestingDuration) - totalClaimed.

Here is a simplified code snippet for a tier structure and a purchase function in Solidity. This example uses a mapping to track tier configurations and user contributions.

solidityCopy
struct TierConfig {
    uint256 price; // price per token in wei
    uint256 hardCap;
    uint256 maxPerUser;
    bool isActive;
}

mapping(address => mapping(uint256 => uint256)) public userContribution; // user => tierId => amount
mapping(uint256 => TierConfig) public tiers;
mapping(address => mapping(uint256 => bool)) public isWhitelisted; // user => tierId

function purchaseTokens(uint256 tierId, uint256 paymentAmount) external payable {
    TierConfig storage tier = tiers[tierId];
    require(tier.isActive, "Tier not active");
    require(isWhitelisted[msg.sender][tierId], "Not whitelisted");
    require(paymentAmount <= tier.maxPerUser, "Exceeds personal cap");
    require(totalRaisedPerTier[tierId] + paymentAmount <= tier.hardCap, "Exceeds tier cap");
    // Process payment and record allocation
    userContribution[msg.sender][tierId] += paymentAmount;
    totalRaisedPerTier[tierId] += paymentAmount;
    // Calculate and record token allocation (logic omitted for brevity)
}

Security considerations are paramount. Use pull-over-push for withdrawals: let users claim tokens instead of sending them automatically to prevent gas wars and reentrancy risks. All funds (both the raised stablecoins and the undistributed tokens) should be withdrawable by a timelock-controlled admin after the sale concludes for safety. Thoroughly test the state machine to prevent a tier from being re-activated accidentally. For production use, consider integrating with audited vesting contract libraries like OpenZeppelin's VestingWallet or TokenVesting. Always conduct a professional audit before deploying a sale contract with real value.

The core of a tiered sale is a VestingWallet or LinearVesting contract that holds allocated tokens and releases them according to a predefined schedule. For each tier, you deploy a separate vesting contract or configure distinct schedules within a single contract. Seed and private round investors typically receive tokens at a lower price but with longer cliffs (e.g., 12 months) and linear vesting periods (e.g., 24 months). The public sale, often conducted via a bonding curve or fixed-price sale like a MerkleDistributor, usually has immediate liquidity or a short lock-up. Use OpenZeppelin's VestingWallet as a secure, audited base for these schedules.

Price differentiation is enforced in the sale contracts. A common pattern is to have separate SeedSale, PrivateSale, and PublicSale contracts that each accept a different currency (e.g., stablecoins for private, native token for public) at a fixed rate. The SeedSale contract would have the lowest tokenPrice, while the PublicSale contract has the highest. Each contract mints or transfers tokens from a central TokenSale treasury to the buyer's associated vesting contract. Critical security checks include hardcaps per tier, whitelisting via MerkleProof for seed/private rounds, and timestamp-based phase transitions to prevent overlap.

Smart contract architecture must manage state transitions between sale phases securely. A central SaleManager contract can orchestrate this, using onlyOwner functions to: 1) startSeedSale(), 2) startPrivateSale(), and 3) startPublicSale(). Each function would enable the corresponding sale contract and disable the previous one. This prevents investors from participating in the wrong round. Additionally, the Token contract itself should have a mint function restricted to the sale contracts, ensuring the total supply cap is respected. Always implement a finalizeSale function to burn unsold tokens or allocate them to a community treasury, which is a key trust signal for investors.

Beyond the code, economic design is crucial. Determine tier allocations as a percentage of the total supply (e.g., Seed: 10%, Private: 15%, Public: 5%). The price between tiers should have a clear discount gradient; a 50% discount for seed versus private, and a 20% discount for private versus public, is a common model. These discounts compensate early investors for higher risk and longer capital lock-up. Transparency is achieved by verifying the vesting contract addresses on-chain and publishing the detailed vesting schedule. Tools like Etherscan's "Read Contract" tab allow anyone to query an investor's vested and locked balances.

For a practical implementation, examine live examples. The Uniswap (UNI) airdrop used a MerkleDistributor for its community allocation, which is analogous to a public sale. More complex tiered sales, like those used by Liquity (LQTY) or Frax Finance (FXS), involve staged vesting contracts. When testing, use forked mainnet environments with tools like Foundry or Hardhat to simulate investor behavior across different tiers. Always conduct thorough audits on the vesting and sale contract logic, as bugs here can lead to irreversible token allocation errors or exploits.

Designing a tiered sale is a foundational step that sets the trajectory for your project's community and treasury. The core principles—transparent vesting schedules, clear eligibility criteria, and secure smart contract architecture—are non-negotiable for building trust. Your technical implementation, whether using a modular framework like OpenZeppelin's VestingWallet or a custom sale contract, must prioritize security audits and gas efficiency. Always test extensively on a testnet, simulating all user interactions from each round.

With your structure defined, the next steps are operational. First, finalize all legal documentation and KYC/AML procedures for private rounds. Second, prepare your technical infrastructure: deploy and verify the final contracts on the mainnet, set up a dedicated multisig wallet for raised funds, and configure your front-end dApp to interact with the sale contracts. Tools like Tenderly for monitoring and Blocknative for transaction management can be invaluable during the live sale event.

Finally, consider the long-term view. A successful sale is the beginning, not the end. Develop a clear plan for post-sale liquidity provisioning, typically involving a DEX pool with a portion of the raised capital. Establish transparent communication channels for investors regarding vesting unlocks and project milestones. The credibility earned from a well-executed, fair sale is a significant asset as you move into the next phase of development and growth.