The Supporter Vault (First-Class Primitive)

The Supporter Vault is a core component of the PURITY system, not an auxiliary feature or a fundraising wrapper. It exists to let a launch be funded before it exists as a market — without introducing token dilution, discretionary control, or trust in anyone's promises. It is the mechanism that separates capital support from token ownership, which is the structural distinction the whole standard rests on.

What it is

The vault is a purpose-built contract deployed with the rest of the launch set, ahead of launch. It accepts base-asset contributions under caps fixed at deployment, holds them, and enforces one iron rule about where they can go: base asset held by the vault moves to exactly two destinations — back to the original contributor (a refund), or into the Treasury (finalization, at launch). There is no third path. The vault cannot pay team wallets, administrators, or any external address; it never holds tokens; it never touches the market.

Contributors are not buying anything. They receive no tokens, no discounted allocations, no governance rights, no ownership, and no preferential access — at launch, supporters buy on the open market on identical terms to everyone else, or not at all. What a contribution creates is a pro-rata share of the supporter bucket: a claim on 10% (as configured) of whatever liquidation proceeds the launch's market eventually generates. That claim may be substantial, may be small, and may be zero — it is a share of realised surplus, not a return, and no part of the system promises otherwise.

The lifecycle: open, then funded, then a record

While the raise is open, anyone (or, if the admin has enabled the whitelist, anyone approved) may contribute up to the per-wallet cap, until the overall cap. Every contributor holds a unilateral exit for the entire duration: claimRefund() returns their full contribution at any time before launch, and no one can block, delay, or condition it.

At launch, the Treasury — and only the Treasury, only from inside its launch() — calls finalize(). The vault forwards its entire balance to the Treasury, flips to finalized, and refunds close in the same atomic instant. Finalization is minimum-gated: it reverts unless the vault holds at least finalizeMinimum — the launch's committed pool-seeding plus committed accumulation plus a small surplus floor. Below that line, finalization is impossible, and refunds stay open.

After launch, the vault is a pure, immutable, read-only record. It retains contributions[supporter] and totalContributions — the pro-rata basis SupporterDistribution reads for every claim, forever — and does nothing else. It tracks no claims, executes no transfers, and rejects any base asset sent to it.

Why the launch binding matters

The vault and the launch are bound together atomically, and that binding removes the classic pre-launch failure modes outright:

• There is no "finalized but not launched" state. Finalization only happens inside the launch transaction itself. Supporter capital is never sitting committed in limbo, waiting on a team to act.
• An under-funded launch cannot happen. If the vault is below its minimum, finalize() reverts — and takes the whole launch() with it. The vault stays open and refundable.
• A never-launched raise never traps anyone. If the team simply never launches, refunds remain open indefinitely. The worst case for a supporter is getting their money back.
• The team cannot launch under-committed. The committed amounts are Treasury immutables and the vault's minimum is derived from them at deployment — the wiring verification checks the two agree, so the public commitment and the enforcement are the same numbers.

Contributions above the committed amounts — an over-subscribed raise — flow to the Treasury as additional market-making capital. Surplus is not a distribution and not team money; it makes the launch's autonomous engine stronger.

Admin powers, precisely bounded

The vault has an admin (for third-party launches, the launching team), whose powers are deliberately narrow: managing the optional whitelist (enable, disable, add, remove — only before finalization), and a batch refund — returning any set of contributors' funds, each payment going only to its original contributor. The batch refund exists to wind down a raise that will not reach its minimum without forcing every contributor to transact individually. It is worth stating plainly: the admin can return money early, and can gate participation — and can do nothing else. No admin power moves value anywhere except back where it came from.

Not a presale — structurally

The distinction between the vault and a presale is not framing; it is mechanical. In a presale, capital buys supply — creating insiders with a cost basis below the market's. In the vault, capital buys nothing: supply enters the market whole at launch, every buyer pays the market price, and supporters hold only a contingent base-asset claim that pays out if — and only as much as — the market actually delivers. No discounted supply exists to dump, and no supporter outcome is decoupled from the launch's real performance.

$PURE's own vault configuration (5 ETH per wallet, 100 ETH cap, 50.5 ETH minimum, open contribution) is listed with the rest of its parameters in The $PURE Token.