Accumulation Logic (Buy-Side)

Accumulation exists to re-acquire supply at economically favourable prices, rebuild supply control after distribution, and preserve long-term Treasury strength. It explicitly does not exist to defend price, prevent declines, or chase momentum. The engine buys because the price is cheap relative to its anchors — never because the price is falling.

Activation

A call to accumulate() proceeds only if every one of these holds at the moment of the call:

1. The launch has happened and no shutdown has begun.
2. The post-launch delay has elapsed. Accumulation is time-locked until launchTime + launchSellDurationSec + accumulationBufferSec — structurally after the launch-phase sell program ends, with a buffer on top ($PURE: 600s + 1200s = 30 minutes). This keeps the Treasury out of the earliest price discovery entirely: the market leads, the engine follows.
3. The price is at or below P_accStart — the activation anchor defined in State Variables & Price Anchors.
4. The spacing gate has passed — at least minSecondsBetweenBuys since the last buy ($PURE: 45s).
5. Intensity clears the minimum. Intensity below the hardcoded 5% gate means conditions are only marginally attractive; the call returns without buying rather than spending budget at the shallow edge of the range.

If any condition fails, nothing happens. There is no queued intent and no catch-up.

Intensity — how hard the engine buys

Between the two accumulation anchors, intensity ramps quadratically:

I = ((P_accStart − P) / (P_accStart − P_accMax))²      clamped to [0, 1]

At P_accStart intensity is zero; at and below P_accMax it is 1.0. The quadratic shape concentrates capital where it is most effective — the engine is deliberately timid just below its activation threshold and decisive near the floor.

Intensity is computed once per call and applied on two independent axes simultaneously:

Buy size. Each individual buy scales linearly with intensity between the configured bounds:

buySize = minBuySize + I × (maxBuySize − minBuySize)

Effective budget. The daily budget ceiling itself scales with intensity:

effectiveDailyBudget = I × buyBudgetPerDayBps × treasuryETH

checked freshly against what has already been spent this period. This is the property that makes call frequency irrelevant: at low intensity, even unlimited calls cannot deploy more than the small intensity-scaled ceiling, and the full daily budget is reachable only at full intensity. Budget cannot be accumulated at low intensity and unloaded at unfavourable prices.

Caps

The buy amount that finally executes is the smallest of four values: the intensity-scaled buy size, the per-transaction treasury cap (maxBuyPerTxTreasuryBps of treasury capital), the per-transaction pool-impact cap (maxBuyPerTxPoolEthBps of pool reserves — no single buy moves the market meaningfully), and the remaining intensity-scaled budget for the period. On top of all of these sits the global daily deploy cap (maxNetTreasuryDeployPerDayBps), a backstop across the whole buy side; a buy that would breach it reverts.

The deploy cap counts buys only. Selling neither consumes nor refills it — the two sides of the engine are accounted separately by design.

Available capital

The capital available for market-making is simply the Treasury's own balance (native + WETH). Team, supporter, and ecosystem funds are never in it — they are forwarded out at the moment of each liquidation split and sit in their own contracts. There is no earmarked value inside the Treasury for the buy-side to accidentally spend.

All buys are exact-input swaps against the canonical pool. For $PURE's confirmed values ($PURE buys between 0.025 and 1.0 ETH per transaction, at most 2% of treasury capital per day at full intensity, no more often than every 45 seconds), and the enforced ranges every launch's configuration must satisfy, see Reference.