loss events

A loss event is a specific, observable change in a token's onchain state that removes holders' ability to exit at a fair value. It is not a price movement.

The four categories

Liquidity removal

A material withdrawal of pooled liquidity that leaves holders unable to exit at a reasonable depth.

Detection compares pool depth against the pool's own trailing baseline rather than an absolute floor, because what counts as thin depends entirely on the token. A withdrawal that halves a deep pool and one that empties a shallow one are different events.

Supply manipulation after renouncement

New supply minted, or existing supply moved, from a contract that was represented as fixed or renounced at the time of purchase.

The relevant comparison is against the state at the holder's purchase, not against the state today. A token that was always openly mintable does not produce this event; a token that was renounced and then regained the ability to mint does.

Blocked transfers

Transfer or sell paths disabled for holders generally. This covers a blocklist applied broadly, a transfer tax raised to a level that makes selling uneconomic, and a paused transfer function.

A block applied to a single address for a specific reason is not this event. The condition is that holders in general cannot exit.

Abnormal collapse within a short window

A combined price and liquidity collapse steep enough, and fast enough, to fall outside normal market behaviour for that token's own trading history.

This is the hardest category to define and the one most likely to be set conservatively. It exists to catch events whose mechanism does not match the first three categories but whose effect on holders is the same. It is not a floor under the price.

Detection

Monitoring samples covered tokens continuously and evaluates each measure against its threshold. Thresholds are per-category and are calibrated to the token's own history, so the same absolute change can be an event for one token and ordinary behaviour for another.

Crossing a threshold does not by itself create a payable event. The crossing has to be attributable to a specific transaction and has to survive the dispute window below.

Declaration and evidence

When conditions are met, the event is declared onchain. A declaration records:

• the event block — the block at which the condition was met, and the block used for all balance snapshots,
• the causing transaction,
• the measured values before and after,
• the category of event.

The event block matters more than any other field: eligibility and loss are both computed against balances as of that block, so a declaration fixes who can be settled before any of them can react to the declaration itself.

The dispute window

Declaration opens a dispute window of 1 hour — a draft parameter, subject to change. No settlement executes while the window is open.

A challenge must present contrary onchain evidence: that the measured change did not occur, that it occurred at a different block, or that it falls outside the declared category. A challenge is not an appeal on fairness; it is an assertion that the record is wrong.

If a challenge succeeds, the declaration is voided and no settlement executes. If the window closes without a successful challenge, the event is verified and settlement proceeds as described in Claims & Settlement.

Where detection can fail

Detection is threshold-based, and thresholds are a compromise. Set them tight and ordinary volatility produces declarations that then have to be challenged; set them loose and real events pass unremarked.

A novel mechanism that harms holders without crossing any of the tracked measures will not be detected at all. An event spread deliberately across many small transactions may stay under every threshold. These are genuine failure modes, not hypotheticals, and they are covered further in Risks & Limitations.