> For the complete documentation index, see [llms.txt](https://whitepaper.virtuals.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://whitepaper.virtuals.io/builders-hub/genesis-launch/genesis-refund-policy.md). # Genesis Refund Policy **Genesis is built to reward maximum participation, with minimal risk.** The Genesis Launch mechanism is designed to enable high-conviction participation, while maintaining full protection of unused capital and pledged points through a deterministic refund logic. {% hint style="info" %} Pledge with confidence. All excess is returned, no matter how high you aim. {% endhint %} Commitments are never punitive. The protocol ensures that each participant receives a token allocation proportional to their inputs, with all unused values automatically returned.
**If the Genesis Launch is ****unsuccessful:** > **• All pledged points are fully refunded** > > **• All committed $VIRTUAL is fully returned** {% hint style="danger" %} A launch is considered unsuccessful if total committed $VIRTUAL **falls below 21,000 $VIRTUAL,** the minimum required to instantiate the bonding curve and trigger Sentient activation. {% endhint %} **If the Genesis Launch is ****successful:** > **• Any unused $VIRTUAL (beyond final allocation) is fully refunded** > > **• Any unused points (beyond final distribution logic) are fully returned** > > **• Refunds also occur if aggregate commitments overshoot the highest tier reached (e.g. if pledges land in the 42K tier but 62K $VIRTUAL was committed, the 20K excess is refunded).** Genesis Launches are dynamic by design. Allocations are influenced by total network participation across a 24-hour window. * As more participants pledge, the system may advance into higher tiers, expanding the raise size. * Your estimated allocation may decrease if new pledges dilute your share. * Participants can increase points and $VIRTUAL at any time before close. {% hint style="info" %} Estimate boldly. Overcommitting is safer than undercommitting. The system adjusts, then refunds. {% endhint %} This structure enables high-agency participation while preserving efficiency. Final allocations are determined strictly by onchain logic, and all unused commitments, whether in points or $VIRTUAL, are returned. The mechanism is designed to scale with conviction, without introducing excess risk. **Operational Guarantees:** > **• No funds are retained beyond what is used for successful allocation.** > > **• Refunds are automatic and executed at the smart contract level.** > > **• The system is built to favor upfront commitment while ensuring precision at final settlement.** The result: a fair, trustless coordination layer that enables maximum signaling—without irreversible cost. *** ## Claiming Genesis tokens are not automatically delivered. Users will claim their final token allocation through the UI once the launch concludes. | Snapshot Date | Epoch | Airdrop Week (Allocation Period) | $VIRTUAL Staking | Points | Ecosystem Activity (ACP / Butler) | | ------------- | ------- | -------------------------------- | ---------------- | ------ | --------------------------------- | | Oct 8, 2025 | Epoch 0 | Oct 9 – 12 (Week 1) | 2% | 3% | 0% | | Oct 12, 2025 | Epoch 1 | Oct 13 – 19 (Week 2) | 2% | 2% | 1% | | Oct 19, 2025 | Epoch 2 | Oct 20 – 26 (Week 3) | 2% | 1% | 2% | | Oct 26, 2025 | Epoch 3 | Oct 27 – Nov 2 (Week 4) | 2% | 0% | 3% | | Week | Airdrop Distribution | Notes | | ----------------- | -------------------------------------------------------------------------------- | ---------------------------------- | | Week 1 | 2% based on $VIRTUAL staking, 3% based on points | | | Week 2 | 2% based on $VIRTUAL staking, 2% based on points, 1% based on ecosystem activity | | | Week 3 | 2% based on $VIRTUAL staking, 1% based on points, 2% based on ecosystem activity | Final week of point-based airdrops | | Week 4 and onward | 2% based on $VIRTUAL staking, 3% based on ecosystem activity | Points fully phased out | | Category | Allocation | Notes | | ------------------ | ---------- | ---------------------------------------------------------------------------------------------------------- | | Ecosystem Airdrops | 5 % | 2 % $VIRTUAL Stakers, 3 % Virtuals Ecosystem Participants | | Open Market | 45 % | Public trading pool | | Team Allocation | 50 % | 25 % linear fundraising mechanism / 25 % 1-year lock (6 month linear vesting schedule) or 160 M FDV unlock | | Category | Genesis | Unicorn | | ----------------- | ----------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | | Access Mechanism | Points-based pledging and capped allocations | Fully open market participation, anyone can trade directly from Day 1 | | Fundraising Logic | No direct fundraising; founders relied on trading tax | Continuous linear fundraising from 2 M → 160 M FDV through limit-sell order mechanism | | Founder Alignment | No structured unlocks or growth milestones | 50 % team tokens locked through, 25 % linear funding starting at 2 M FDV, 25 % 1-year lock or 160 M FDV unlock | | Ecosystem Rewards | Points system and periodic Genesis bonuses | 5 % of every new launch automatically airdropped to $VIRTUAL stakers and Virtuals ecosystem participants | | Sniper Protection | Limited anti-bot systems | 99 % → 1 % decaying tax during launch | | Market Entry | Pre-sale pledging | Starts low and open, real market-driven discovery | | Fairness Model | Everyone gets a small piece | Conviction decides outcome, early believers capture the biggest upside | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://whitepaper.virtuals.io/builders-hub/genesis-launch/genesis-refund-policy.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.