Safeguards & Invariants

The engine's protections are layered: hard structural constraints that make whole classes of misbehaviour impossible, invariants that hold across every state, and deployment-time validation that rejects a bad configuration before it can exist. None of these can be overridden after deployment — there is no emergency function, no admin key, and no manual intervention path anywhere in the engine.

Hard constraints

No overlapping buy and sell. Accumulation and liquidation cannot execute in the same transaction or block. The separation removes any possibility of the engine sandwiching itself and keeps each side's accounting clean.

Canonical pool only. Every price read and every swap references the one canonical pair. There is no alternate execution path that moves tokens or base asset.

The price bands cannot overlap. The ordering P_floor < P_accMax < P_accStart < P_liqStart < P_liqMax is enforced statically at deployment and re-enforced at runtime by the clamp on P_accStart. The engine can never be in its buy zone and its sell zone at once.

The global deploy backstop. Beyond the per-side budgets, maxNetTreasuryDeployPerDayBps caps total buy-side deployment per day ($PURE: 1.5% of treasury capital). It counts buys only — sells never consume or refill it — so a burst of selling can never unlock extra buying, or vice versa. This is the final bound that keeps treasury deployment gradual under any market condition.

Fixed-point arithmetic. All computation is integer fixed-point at 1e18 precision.

Invariants

• P_floor is always computable and unmanipulable by construction — derived entirely from live reserves and the Treasury's balance, with the degenerate zero-reserve case guarded by an explicit revert.
• avgSell reflects only real Treasury exits. Its accumulators are touched exclusively by the liquidation paths, which are themselves strength-gated. Neither the Treasury's own buying nor any external trader can move it.
• Selling requires fresh inflow. Mode 2's pool-delta source means sell volume is bounded by measured new buying pressure — there is no stored sell budget to drain and no way to sell into a flat or falling pool.
• Buying is intensity-gated at every level. Both per-buy size and the period budget scale with intensity, recomputed freshly at every call; call frequency cannot circumvent either.
• No value leaves the Treasury outside three paths: the liquidation split (immutable percentages, executed in the same transaction as the sale), a passed governance release (hard-capped, holder-voted), and shutdown claims (pull-based). There is nothing else.

Validation at deployment

Every parameter is validated in the Treasury constructor against protocol-enforced ranges — a launch with an out-of-range configuration cannot deploy at all. The validation covers the distribution shares (market-making 60–90%, team ≤ 25%, supporters ≤ 15%, with the exact sum enforced), every accumulation and liquidation parameter, the timing windows, the launch-capital floors (pool seeding ≥ 1 ETH, launch accumulation ≥ 1 ETH), and cross-parameter consistency — including the static band-ordering constraint above, a minimum 0.5× gap between the liquidation multipliers, and the requirement that the per-transaction buy cap not exceed the daily budget (a configuration that would silently disable buying).

The full range table is in Reference. Within those ranges, a launching team's configuration is its own call — the protocol enforces the envelope, and the deployed values are public and immutable, so every participant can read exactly what a launch will do before touching it.