Skip to content

HERA is live on ArcContract: TBAFollow on X

Documentation

how protection works.

The reserve, the events it covers, who is eligible, and how settlement is computed. Numeric parameters throughout are draft and subject to change.

← Back to hera

eligibility

Which addresses are included in a settlement set, and which are excluded.

Eligibility is computed, not applied for. Every condition below is evaluated against onchain state at the event block.

Conditions on the address

Minimum holding period

The address must have held the position for at least 24 hours before the event block — a draft parameter, subject to change.

The holding period exists so that coverage cannot be bought after an event becomes foreseeable. Without it, the profitable strategy is to watch for a token in distress, buy it, and collect a settlement.

Pre-event purchases only

Only balances acquired strictly before the event block count toward a settlement. Anything acquired during or after the event is outside coverage, even if the address held a covered position beforehand.

An address that held 1,000 tokens before the event and bought 9,000 during it is settled on 1,000.

Deployer-linked addresses excluded

Addresses linked to the token's deployer, treasury or liquidity provider are removed from the settlement set. Linkage is assessed by funding path and by control — an address funded from the deployer, or controlled by the same key, is linked regardless of how many hops separate them.

This condition removes the most direct abuse: causing an event and then collecting coverage against it.

Conditions on the token

Minimum token age and volume

The token itself must clear a minimum age and a minimum traded volume before it can be covered.

This closes the loop where a token is created, briefly traded to establish a position, and then drained — a sequence that would otherwise let an attacker convert the reserve into a revenue stream.

How the settlement set is built

  1. Take the set of addresses holding the covered token at the event block.
  2. Remove addresses that fail the holding period.
  3. Reduce each remaining balance to the portion acquired before the event block.
  4. Remove deployer-linked addresses.
  5. Compute each address's verified loss from the pre-event and post-event values of its remaining balance.
  6. Allocate pro-rata to $HERA holdings, capped at each address's verified loss and at the per-event share of the reserve.

Things eligibility deliberately does not consider

Size. A small holder and a large holder are treated identically per unit of loss.

Intent. Whether a holder understood the risk they were taking has no bearing on eligibility.

Hardship. There is no discretionary uplift and no appeals process that produces a different answer for a sympathetic case. The conditions above are the whole of it.

This rigidity is the point. A protection layer that could be argued with would be a protection layer whose payouts depended on who was arguing.