Claims and the cover pool
What happens when a sealed contract is exploited, who decides, and where the money comes from.
What a claim is
A challenge against a seal. It says: this sealed contract was exploited, through something a check should have caught, and here is the transaction.
A claim is about the checks. It is not about the review, which is an opinion, and not about anything outside the rule set. A sealed token that passed all eight and then rugged through something none of them look for is not a failed seal. It is a limit of the list, and the list is public. That line is what keeps auditors willing to sign, and it is also why the list has to grow.
Who decides
The stakers who are not the auditor in question. A claim opens a vote; the auditor whose seal is challenged cannot vote on it. The vote asks one thing: did the exploit go through a mechanism the checks cover, at the commit the seal names?
The evidence is public: the transaction, the seal, the rule set, the code hash. The code itself is not public, but the auditor can be compelled by the vote to disclose the source at the sealed commit to the voters, since the alternative is losing the stake by default.
What happens when a claim passes
- The auditor's stake behind that seal is taken.
- A share of the cover pool is added to it.
- The total is paid to the holders the exploit hit, in proportion to what they lost, as read from the exploit transaction and the token's balances before it.
- The seal is marked failed. It is not deleted; its history stays readable, so that a wallet checking the hash sees a failed seal and not an absence.
What happens when a claim fails
Nothing changes on the seal. The claimant's bond, posted when the claim was opened, goes to the cover pool. The bond exists so that claims cost something to open and nothing to win.
The cover pool
Twenty-five percent of every seal fee goes into it. It sits with the auditors' stakes and pays out on passed claims, on top of the stake. It exists because a single auditor's stake can be smaller than the damage, and because a pool funded by every seal spreads the cost of the one that fails across all the ones that did not.
What this cannot do
The pool and the stakes are the size they are. An exploit larger than both is larger than both. The vote can be lazy or captured; the bond and the auditor's exclusion are the guards, not guarantees. A claim can only be about the eight checks, and the eight checks are a floor.
Status. Designed, not deployed. The claim flow needs the registry and the staking, which are the next contracts. Until then, a failed seal is a matter of the auditor's word, and the auditor's word is the zkCheck key.