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, one bounded lever, 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.
Tuning the market-making band: your one lever
The engine's rules are immutable, but six of its dials are not: the accumulation band (accMaxMultE18, accStartMultE18, alphaE18) and the liquidation band (liqStartMultE18, liqMaxMultE18, qMaxBps). From your team address you can retune them with a single call (setMMBand), which takes all six as one tuple, and it is worth being precise about how bounded this power is: each dial is confined within an immutable range hardcoded into the contract, the call reverts unless the band-ordering invariants hold across the whole tuple, and every successful change emits a public MMBandUpdated event your holders can watch. You are repositioning the engine's bands inside a committed envelope, nothing more; the rate caps, budgets, splits, and every other parameter have no setter, for you or anyone (the full mechanics).
Treat it accordingly. The defaults are the audited values, and a retune is a public act your market will read and react to: the dials' current values and full history are on-chain. Use it when market structure genuinely warrants it (a launch whose floor dynamics have outgrown its initial band), not as a steering wheel.
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 power beyond the six-dial band above (every cap, budget, split, and window is setterless), 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.