How it works
On-chain insurance has never had a custody problem. It has a specification problem: a payout condition has to be encoded as a parametric trigger long before anyone knows what the failure will look like, so cover either fires on events that were not really losses or misses the loss that happened. Fixing that by importing judgment from off-chain puts back the thing on-chain insurance was meant to remove — a party who decides.
GenShield keeps the wording in natural language and makes the wording itself the settlement logic. There is no resolver key. Anyone can push a claim to its next stage, and the answer is whatever independent validators agree the wording and the evidence say.
The three rounds
Is the wording adjudicable?
run_nondet_unsafeOne round, before any capital stands behind the product, decides whether the coverage wording could be settled objectively from the evidence sources the underwriter nominated. A product that fails review can never sell a policy.
On its first live run this gate rejected two real draft wordings: one for resting on an unquantified threshold, one for turning on a trader's intent. Neither can be established from evidence, so neither could ever have settled a claim fairly.
What do the chain facts say?
strict_eqThe contract posts eth_getTransactionReceipt and eth_getBlockByNumber to the insured chain's own RPC, then strips each receipt to fields two honest nodes cannot disagree about — status, block number, from, to, log count, block timestamp.
Confirmation counts and gas-price fields are dropped rather than trusted. Leaving one in would make every claim fail consensus. The snapshot is frozen onto the claim before judgment, so the round that reads the wording cannot re-derive different facts alongside its verdict.
Does the wording cover it?
run_nondet_unsafeThe leader fetches the evidence and reads it against the wording. Every validator does the entire job again independently — its own fetch, its own reading — and never inspects the leader's answer for plausibility.
A validator that only checked the leader's JSON for a well-formed shape and an in-range severity would be letting the leader decide every payout alone while looking like consensus.
Why severity is bucketed
Two independent readings of the same incident will never produce the same raw loss percentage. Comparing raw severity would fail consensus on almost every genuine claim; comparing nothing would let the leader set the payout alone. Quantising to ten buckets before both comparison and storage is what makes a judged payout amount consensus-safe at all — and it is why the payout is computed from the agreed bucket’s midpoint rather than from either validator’s own number.
The cost is granularity: severity resolves in ten-point steps. That is a deliberate trade — finer buckets tighten payouts but raise the rate at which honest rounds fail to agree.
The evidence is chosen by someone with money at stake
Which makes prompt injection a direct path to the pool, not a theoretical concern. Two defences sit in the contract itself. The underwriter fixes the admissible evidence hosts when the product opens, so a claimant can cite the protocol’s own postmortem but not a page they control. And fetched content is delimited and labelled as untrusted data, under a standing instruction that text inside the fence is evidence to be weighed and never instructions to be followed, with per-source and total length caps so one huge page cannot crowd the wording out of the context.
Solvency
Enforced where the risk is taken. A product cannot write cover beyond its capital times a leverage cap, capital backing live policies cannot be withdrawn, and LP accounting is share-based — depositors mint shares against the pool’s current value, so a payout dilutes every LP proportionally at the moment it happens. Flat per-depositor balances look equivalent and quietly let whoever exits first take the remaining capital at par after a loss.