how protection works

Protection runs as a loop with four stages. Each stage produces an onchain artefact that the next stage reads, so the path from activity to settlement is auditable end to end.

1. Activity funds the reserve

Protocol fees are split at the point of collection. The reserve's share is transferred into the reserve contract in the same transaction that collects the fee, rather than accumulating in an intermediate account to be swept later.

Draft allocation — draft parameters, subject to change:

Destination	Share
Protection reserve	70%
$HERA buyback	20%
Operations	10%

Because the split happens at collection, the reserve's growth is a function of usage and nothing else. There is no step at which someone decides whether to fund it this month.

2. Monitoring runs across Arc

Covered tokens are sampled continuously. For each token the monitor tracks:

• Liquidity depth in each known pool, and the rate of change of that depth.
• Total supply, and any mint or burn event against it.
• Ownership and admin state — whether ownership is renounced, whether an admin key can still change transfer behaviour.
• Transfer permissions — blocklists, pause flags, and the effective tax on a sell.
• Price and volume, against the token's own trailing baseline rather than a global benchmark.

Each measure has a threshold. A threshold being crossed is necessary for a loss event, but not sufficient on its own — see Loss Events for how a crossing becomes a declaration.

3. Loss events are verified onchain

When the conditions for a loss event are met, the event is declared. Declaration writes the evidence onchain:

• the block at which the condition was met,
• the transaction that caused it,
• the measured before-and-after values,
• the category of event.

Declaration opens a dispute window, drafted at 1 hour — a draft parameter, subject to change. During the window the declaration can be challenged with contrary onchain evidence. Nothing is paid while the window is open.

4. Eligible holders are settled in USDC

When the window closes without a successful challenge, the event is verified and settlement executes.

The settlement set is computed from balances as they stood at the event block. Holders do not file anything; if an address is eligible, the settlement is sent to it.

Payouts are:

• pro-rata to $HERA holdings,
• capped at the holder's verified loss, so no address can receive more than it lost,
• bounded per event at a maximum of 10% of the reserve — a draft parameter, subject to change.

Where the total eligible loss exceeds the per-event cap, every eligible address is scaled down by the same factor. Nobody is settled in full while others are settled at zero.

What this loop guarantees, and what it does not

It guarantees that the reserve's balance, the evidence behind a declaration, and every settlement leaving the reserve are public and checkable.

It does not guarantee that detection fires for every event, that the reserve is large enough for any given event, or that the thresholds are set correctly for every token. Those are real limitations and they are set out in Risks & Limitations.