network.crypsurance.io · preview
The Verifier Network.
Claims die or pay on one question: did the event really happen?This is where CrypSurance answers it — genuine event data from independent sources, oracle verification you can audit, and an escalation path to partners and the community when data alone can't decide.
Data first
A claim arrives. The oracle checks it against independent event feeds — flight status, weather, chain analytics, partner registries.
Verified → instant settlement
If the data confirms (or refutes) the event, the claim settles on-chain within minutes — payment and evidence recorded together.
No data → human network
If no feed covers the event, an on-chain verification request opens below — routed to data partners and, over time, staked community verifiers.
The oracle never sleeps.
A scheduled agent wakes every 30 minutes, pulls the latest event data, and settles every pending claim on-chain — pay, deny, or escalate to human verification. No one presses a button, and the timestamp below is the real last run, read from the public log rather than asserted.
- Last actual run
- checking…
- Scheduled every
- 30 min
- Network
- Solana devnet
- On no data
- → human network
Verification console
Every policy in the protocol and how it was settled — read directly from the program's own accounts. No database, no wallet needed, no trust required.
…
Policies written
…
Claims paid
…
Claims denied
…
Awaiting offline verification
Reading policies from the blockchain…
Event data registry
The feeds the network verifies against today — and the tie-ups that expand what can be covered. Every new data source unlocks a new insurance product.
| Source | Verifies | Status | Notes |
|---|---|---|---|
| Testnet simulation | TEST-DELAY / TEST-ONTIME flights | Live | Deterministic events so anyone can test the full claim loop. |
| Flight status data | Flight delays & cancellations (global) | Live | Live flight-data feed checked by the oracle operator for real flight numbers. |
| On-chain analytics | Depeg events, protocol exploits, wallet drains | In build | Crypto-native events verified from chain data itself — next products. |
| Weather & catastrophe feeds | Rainfall, storm, earthquake parameters | In build | Public meteorological agencies; enables parametric crop / travel / property covers. |
| Rail & road incident data | Train / bus accident records | Partner tie-up | Via transport-authority data partnerships (e.g. railway incident bulletins). |
| Hospital admission records | Hospitalization events for health cover | Partner tie-up | Requires healthcare data partners + consent flows; jurisdiction by jurisdiction. |
| Civil registries | Death & accident certification for life cover | Partner tie-up | The hardest and most regulated feed — licensed partners only (Phase 2). |
From one operator to a network
No single key can settle a claim any more. Operators stake SURETY to register, and a claim needs a threshold of them to agree before it pays. Verdicts are sealed first and opened afterwards, so no operator can see how the others voted before committing — otherwise copying the majority is free, and a consensus of copies is not a consensus. An operator whose verdict contradicts the settled outcome loses part of its stake; one that matches earns a share of the premium. Settlement itself is permissionless: once the threshold agrees, anyone can crank it.
What is nottrue yet: the registered operators are still ours, running from one place. The mechanism is permissionless — anyone can register and stake — but an operator set that isn't us is the next milestone, not a claim we get to make today. Offline verification requests remain partner handled, and become bounties any staked verifier can earn.
Own event data? Become a source.
Airlines, hospitals, transport authorities, data companies, analytics firms — every feed you bring makes a new kind of cover possible, and data partners earn from every verification.