FAQ

Direct answers, with links to the precise treatment. Every answer here is a property of deployed contract code, not policy.

Can the team rug?

No, and this is a checkable claim, not a promise. The team holds no tokens (there are no allocations), cannot access the treasury (its one path is a governed release: holder-voted, hard-capped at 20% of market-making WETH per proposal), cannot touch the LP (the Treasury owns it, and only shutdown, which requires a holder vote, unwinds it), and cannot mint, redirect a flow, or change any split, cap, or limit. The one parameter power the team holds is tuning the six market-making dials within immutable, contract-enforced ranges; every change is event-logged, and none of it can move funds or raise what the engine is allowed to spend or sell. The team's compensation is a vested share of realised liquidation proceeds, and abandoning the project forfeits it.

Can parameters change after deployment?

Mostly no, with one bounded exception. Every rate cap, budget, timing window, size bound, and distribution share is an immutable, validated once against protocol ranges at deployment, with no setter, no admin key, and no governance path, for anyone, ever. The exception is the six market-making dials (the accumulation and liquidation bands, the sell-fraction peak, and the avgSell discount): the team can retune them, but only all six atomically, only within immutable locked ranges hardcoded into the contract, only with the band-ordering invariants re-checked, and every change emits a public event. The envelope the engine operates in is fixed forever; the position of the dials inside it is not. See State Variables & Price Anchors.

Do supporters get tokens?

No. Supporters fund a launch and receive a locked pro-rata share of its supporter pool: 10% of liquidation proceeds, paid in the base asset, claimable continuously. No tokens, no ownership, no governance, and a return that may be zero if the market never generates liquidation proceeds. Until launch fires, every contribution is refundable at will. See Supporter Distributions.

What happens if demand stops?

The engine goes quiet, by construction. Steady-state selling draws only on fresh buying pressure: no inflow, nothing to sell. Accumulation continues only at value-justified prices. Capital sits preserved, indefinitely; there are no forced trades and no death spiral mechanics. If holders conclude the project is over, any 0.05% holder can propose shutdown, and a passed vote leads to a clean, pull-based resolution where remaining capital returns to participants. See Maturity, Decline & Shutdown.

Who operates the engine?

No one, in the sense that matters: the engine's entrypoints are permissionless, its decisions are pure functions of on-chain state, and no party can influence what it does. An off-chain keeper (a team responsibility) triggers it on a cadence; if the keeper dies, nothing breaks, but liquidation opportunities during the gap go unharvested. See Execution Model.

Is the floor price guaranteed?

No. P_floor is a computed reference (the most conservative valuation derivable from on-chain state) that the engine keys its behaviour on. It is not an enforced price, and the market can trade below any level. The engine buys near the floor because that is where its rules concentrate capital, not because it promises to hold a line. See State Variables & Price Anchors.

What does "verified PURITY launch" actually mean?

That the launch was deployed by the canonical factory and therefore genuinely runs the standard's mechanics (real fair launch, real non-extraction, real independent arbitration), verifiable on-chain via the provenance registry. It does not mean the project is good, the team competent, or the token worth buying. The standard guarantees mechanics, never merit.

Who is the arbitrator, and what can they do?

PURITY's multisig, wired identically into every launch. Its powers are narrow: execute a shutdown only after holders authorise one by vote, choose the shutdown mode (which decides whether the team is paid), cancel a proposal during its open voting window, and sweep unclaimed funds a year after shutdown (third-party launches only, routed to the ecosystem, never to itself). For third-party launches this is a trust feature: your launcher holds no shutdown power over you. For $PURE itself there is an acknowledged conflict (the team is the arbitrator), treated honestly in Risk & Limitations.

Why is there a 5% ecosystem fee on third-party launches?

Every third-party launch routes 500 bps of its liquidation proceeds (not of anyone's deposit) to the $PURE EcosystemReceiver. It is hardcoded, taken only from realised proceeds (never from buyers, never during weakness), and it is the standard's alignment mechanism: the ecosystem's anchor grows with the ecosystem's use. See Token Economy.

When does $PURE launch?

Parameters are confirmed and published (Token Economy); the launch date is not yet announced. Canonical addresses will be published at launch; treat anything earlier as fake.