Built around a second chapter.

Ponskit is a reserve and recovery layer for PONs token launches. It does not replace PONs launch infrastructure. A token still launches on PONs with an approved pairing asset and graduates into a permanently locked pool. Ponskit sits beside that: the vault is set as the launch's creatorFeeRecipient, so a defined share of creator fees accumulates in a treasury that belongs to the launch, not to the creator.

The product proposition

Every launch builds a recovery treasury. A sustained 90% drawdown after graduation activates proportional payouts to eligible traders. The trigger is called Recovery Mode, not "rug detected": a price collapse does not establish fraud, and the mechanism works the same whatever the cause.

Three things the creator cannot do

• Withdraw the committed treasury.
• Change the trigger after launch.
• Choose who receives recovery payments.

Two roles for one reserve

A liquid floor and a limited strategy sleeve. Liquid-first vaults hold only the quote asset. Balanced vaults keep at least 35% liquid and may invest the rest under a disclosed policy; the engine refuses any allocation that would breach the floor, and stops all new purchases the moment Recovery Mode is confirmed. Strategy value can fall, and the payout pool is whatever can actually be recovered after strategy losses, trading costs and disclosed settlement expenses.

A drawdown, not a rug accusation.

The condition is simple to state:

validatedTwap(now) ≤ validatedPeak × (1 − 0.90)   for the whole confirmation window

Both sides of the comparison are protected. Protecting only the current price is insufficient: someone could manufacture an extreme peak and make an ordinary price look like a 90% collapse.

State machine

PRE_GRADUATION → WARMUP → BUILDING ⇄ BREACH_PENDING → RECOVERY_CONFIRMED → UNWOUND → SETTLED
                                       (clears)         (6h below threshold)   (sleeve sold)  (root committed)

The TWAP uses interval semantics: each observation reports the price in force since the previous one, and the latest observation is held until the evaluation time. A time-weighted average smooths short-lived moves but does not make manipulation impossible; the confirmation window and liquidity floor are the other two legs.

Net losses. Proportional recovery.

Entitlement depends on a trader's net result on the token, not on a balance and not on any single losing trade. A trader who made 5 ETH earlier and lost 1 ETH later is still profitable; that losing trade alone does not qualify them.

eligibleNetLoss = max(0,
    coveredCost                      // quote paid for covered purchases
  − coveredProceeds                  // quote received selling covered tokens
  − coveredTokens × snapshotPrice    // remaining value at the settlement TWAP
  − priorRecovery)                   // earlier recovery payments

rate   = totalEligibleLosses === 0 ? 0 : min(1, availableReserve / totalEligibleLosses)
payout = eligibleNetLoss × rate

The published ledger rules (v1)

1. Covered venues only. Trades on the PONs curve and the graduated pool build cost basis. Anything else is unsupported activity.
2. Post-cutoff purchases are uncovered. They still affect balances but never create a claim, so post-crash buyers do not inherit earlier traders' losses.
3. Sales consume uncovered tokens first. Proceeds are attributed pro-rata to the tokens actually taken from each bucket, so proceeds cannot be routed away from a covered position to inflate its loss.
4. Transfers out are a deemed disposal at average cost. They neither create nor destroy a loss. Transferred-in tokens are always uncovered: an ERC-20 transfer records no purchase price and does not prove common control.
5. Excluded addresses (creator, vault, pool) never accrue a claim. Excluding the creator's known address does not prove other wallets are unrelated, which is why every unusual wallet carries review flags.
6. Same accounting asset throughout. Losses, drawdown and payouts are measured in the launch's quote asset. An ETH-denominated promise is different from a dollar-denominated one.

From allocation to claim

Settlement computes every wallet's eligible loss at the snapshot TWAP, allocates the available reserve pro-rata, and commits a Merkle root over leaves of keccak256(index ‖ wallet ‖ amountWei), sorted-pair hashed so OpenZeppelin's MerkleProof.verify accepts the proofs unchanged. A proof shows a claim belongs to the committed allocation; it does not show the allocation was computed correctly. That is what the published transaction-level ledger and a challenge period are for.

The specification, executable.

Each vault is an append-only event log. State is never stored; it is derived by folding the ordered log through a pure reducer, so any number on any screen can be recomputed from the events beneath it. Policy checks (no strategy purchases after confirmation, no settlement before unwind, one recovery event per vault, in-order events) run before an event is appended.

Event types

fee               { t, amount }                       creator fee received by the vault
graduation        { t, poolAddress }
price             { t, price, liquidity }            oracle observation
trade             { t, wallet, side, tokens, quote, venue: "curve" | "pool" }
transfer          { t, from, to, tokens }
strategy_allocate { t, amount }                      liquid → sleeve (balanced only, pre-confirmation)
strategy_mark     { t, investedValue }               mark-to-market
unwind            { t, realized, costs }             sleeve → liquid, after confirmation
settle            { t }                              compute allocation, commit root
claim             { t, wallet, amount }

The engine lives in src/lib/engine and has no framework dependencies; the test suite under tests/engine covers the TWAP, the state machine, every ledger rule above, allocation bounds and proof verification. A reference Solidity interface for the vault is in contracts/.

What turns this into a product?

1. Verify the upstream launch interface. Confirm chain, factory version, approved quote assets, creator-fee routing and upstream administrative controls. The published factory lets the launch choose a creatorFeeRecipient, and the current recipient can transfer that role. PONs' owner also holds a timelocked override over future fee routing; the vault cannot remove it. The strongest commitment is therefore about assets already received and locked in the vault, not an irrevocable promise about future fees.
2. Implement and review the reserve vault. Enforce recipient permissions, asset allowlists, allocation limits, loss controls, pause behaviour and the no-discretionary-withdrawal policy. Do not expose a creator-controlled redirection function.
3. Define and validate the strategy. Supported assets, swap routes, slippage limits, execution access and liquidation behaviour. Do not assume an investment asset is an approved PONs pairing asset.
4. Build price history and recovery logic on a real oracle. Replace the observation feed with verified on-chain data; test whether a large holder could profit by deliberately pushing the price into recovery. Longer windows, position-age requirements and liquidity checks are safeguards to test, not proof.
5. Build a complete accounting indexer. Trade universe, transfers, liquidity positions, multiple wallets, the cutoff, a review and challenge period, and anti-abuse rules. A balance snapshot must never masquerade as a verified trading loss.
6. Review claims, security and disclosures. Independent review before accepting funds. Never add a "live" badge, published returns or a working claim action until contracts and data support it.

Recommendation: make loss recovery the core product and the strategy a secondary feature. Start with a liquid reserve, tightly limited strategy permissions, transparent funding and auditable claims. The trigger is manageable; fair, manipulation-resistant loss accounting is the part that deserves the most engineering.

Back to the workspace