How ClaimGuard works
From pooling GEN to an AI-approved payout — every step happens on-chain, in the open, with no human in the loop.
The claim lifecycle
1. Someone creates a pool
Anyone writes coverage terms in plain English — what's covered, what's excluded, what evidence is expected — plus a premium, a coverage period, and payout limits per claim and per period. These terms become the yardstick every future claim is measured against.
2. Members join by paying the premium
Paying the exact premium opens (or renews) a policy for one coverage period. Renewing before expiry extends from the current expiry date, so early renewals never waste paid-for time.
3. A member files a claim
One transaction: a description of what happened, a requested amount, and evidence — a photo, a URL (like a tracking or repair-quote page), or both. There's no separate upload step; the evidence travels with the transaction itself.
4. GenLayer validators adjudicate — atomically
In the same transaction, independent AI validators read the pool's terms alongside the claim's evidence — a vision-capable model inspects the photo, and the URL (if any) is rendered live as text — and reach consensus on whether it's covered and what percentage of the requested amount is justified.
5. Approved claims pay out instantly
If covered, GEN moves to the claimant immediately, capped by the requested amount, the pool's per-claim maximum, and whatever the pool actually has. If denied, the claimant gets exactly one appeal.
How AI validators reach consensus
GenLayer's validators don't just trust one model's output — they use a custom leader/validator pattern (gl.vm.run_nondet_unsafe) built specifically so independent reviewers can agree on a decision even when their free-text reasoning never matches word for word.
The leader proposes a verdict
One validator (the leader) runs the AI evaluation first: it reads the pool's terms, the claim description, the fetched URL text, and the photo (if any), and proposes { covered, payout_percent, reasoning, red_flags }.
Validators independently re-derive it
Other validators don't just check the leader's formatting — each one re-runs the same evaluation from scratch, independently, using the identical inputs.
Only the decision fields need to agree
Validators compare covered (must match exactly) and payout_percent (must be within 15 percentage points) — never the free-text reasoning, which two honest reviewers will always phrase differently even in full agreement.
Majority agreement → accepted
If enough validators agree within tolerance, the verdict is accepted and the payout executes. If not, the network rotates to a new leader and tries again.
covered
exact match
payout_percent
±15 points
reasoning
allowed to vary
red_flags
allowed to vary
Why it's safe to pool funds here
Per-pool balance isolation
Every pool tracks its own balance internally. A payout from one pool can never draw down another pool's funds, even though the contract holds all of them together.
No admin withdrawal, anywhere
There is no function in the contract — not for the creator, not for anyone — that moves pooled GEN except an AI-approved claim payout.
Structural spend limits
max_payout_per_claim and max_claims_per_member_per_period are enforced in contract code before the AI is asked anything — a bad verdict is capped in blast radius regardless.
One appeal, evidence-based
A denied claim gets exactly one re-review, with room for fresh evidence — enough to correct a genuine miss, not enough to spam the pool.
Frequently asked questions
Why can the claimant trigger their own claim's evaluation?
In a two-party escrow, letting the payee trigger their own payout is a real trust smell. But a mutual pool has no counterparty to favor — the verdict comes from independent AI-validator consensus, not from who called the method — so there's no self-approval vector to guard against, and filing can safely resolve atomically in the claimant's own transaction.
What stops someone from draining a pool with one claim?
Three independent caps, enforced in contract code before the AI is ever asked anything: the claim's own requested amount, the pool's max_payout_per_claim, and the pool's live balance. A payout is the minimum of all three, multiplied by the AI's payout percentage.
Can the pool creator withdraw the funds?
No — there is no withdrawal function anywhere in the contract, for anyone, including the creator. The only way GEN ever leaves a pool is through an AI-approved claim. Pausing a pool (creator-only) only blocks new joins and renewals; it can't touch existing funds or strip anyone's coverage.
What happens to a denied claim?
The claimant gets exactly one appeal, where they can add context and/or fresh evidence. The AI re-adjudicates with the combined description. A second appeal on the same claim is rejected by the contract.
Why doesn't the contract just store the photo permanently?
Storage is expensive and the photo is only needed transiently, at the moment of evaluation. It's included directly in the transaction's calldata (so every validator sees the exact same bytes) and used immediately — never persisted in contract state.