Operating Post-Launch
After launch, a PURITY launch mostly runs itself — that is the point. But "autonomous" does not mean "unattended," and a team's post-launch role, while narrow, is real. It consists of one operational duty, two recurring interactions, and a governance relationship worth understanding before it matters.
The keeper: your one operational duty
The engine is pull-based: it acts only when its permissionless entrypoints are called. Someone has to call them, and that someone is your responsibility — in practice, an automation service driving liquidate() on the launch's sampling cadence (120 seconds under default parameters) and accumulate() opportunistically.
Understand exactly what is at stake. If your keeper dies, nothing breaks: the contracts stay correct, no state corrupts, and anyone can call the entrypoints. What you lose is harvest — buying pressure that arrives and dissipates during an outage is never retroactively sold into, which is capital your treasury, your vesting, and your supporters' pool simply don't receive. A launch that wants its engine actually working keeps its keeper actually running, monitors it, and treats an outage as lost revenue rather than as an emergency.
Claiming compensation
Your team share of every liquidation accrues in your TeamDistribution contract and vests linearly over six months. Claim whenever you like, any vested amount, from your team address; the contract pays out native ETH. There is no schedule to manage — deposits vest on their own clocks, and your claimable balance is always readable on-chain (the mechanics).
The incentive structure is worth internalising rather than resenting: your compensation is a function of your market's realised demand and of time spent engaged. There is no accelerant available to you — and if you abandon the launch, an Abandonment shutdown forfeits everything you haven't claimed.
Proposing a treasury release
The one way capital can leave your launch's market-making treasury outside the engine is a governed release: you propose — only your team address can — with a destination and evidence attached; your holders decide. Caps are hardcoded (per proposal: 20% of live market-making WETH; 2% of total supply for tokens), and the framing is not yours to soften: it is a request to disburse the system's capital, decided by the people the system serves.
Living with holder governance
Your holders carry a real power: any 0.05% holder can propose shutdown, and a passed vote authorises the arbitrator — PURITY's multisig, not you — to wind the launch down. You cannot veto it, and you cannot trigger it either; you have no shutdown lever at all. For an engaged team this is an asset, not a threat — it is the reason your buyers can hold your token knowing the exit from a dead project doesn't depend on you, and the reason "the team can't rug" is a checkable claim rather than a promise. The best posture toward governance is the obvious one: stay active, keep building, and let the shutdown machinery stay bored.
What there is none of
No parameter tuning (nothing is tunable), no liquidity management (the Treasury owns the LP; adding more is the market's choice), no market-making decisions (the engine makes none either — it follows rules), no treasury operations beyond the release path above. If a task seems to require a power the contracts don't give you, that is by design — the absence is the product.