See the trigger fire
The whole product hinges on one thing: that Flare's non-existence proof resolves on-chain. We front-loaded it as a go/no-go gate and ran it for real on Coston2. This is that run — labelled a spike, not an end-to-end claim.
$ npm run spike:all --ref …nonpayment
→ IFdcHub.requestAttestation(RPN) requested
→ DA-Layer proof fetched (Merkle path)
→ IFdcVerification.verifyReferencedPaymentNonexistence
✓ returned true · 99.3s · round 1,409,442
tx 0x5774a763…149c540a on Coston2 Explorer ↗The one flow
- 01
buyGuard
Bind a live FXRP redemption ticket, pay an FTSO-priced premium.
- 02
agent defaults
The assigned agent never delivers XRP by the deadline.
- 03
RPN proof
Flare's FDC ReferencedPaymentNonexistence proves non-payment.
- 04
verify on-chain
IFdcVerification checks the proof inside Backstop.claim.
- 05
make-whole
The pool pays the redeemer back — permissionless, automatic.
Why this needs Flare — and only Flare
Backstop is a thin, correct wrapper around the redemption-default mechanism that already lives inside FAssets. Six engine-class Flare methods, wired in code and proven on Coston2. Take Flare out and there is no product.
IFdcVerification.verifyReferencedPaymentNonexistence
The claim gate. Flare's own proof that the agent never paid — no oracle, no relayer, no light client of our own.
IFdcHub.requestAttestation (RPN)
The autonomous keeper requests the non-payment attestation the moment a deadline is breached.
IAssetManager.redemptionRequestInfo
Binds each guard to a real FAssets redemption ticket at buyGuard — the exact default the protocol recognizes.
FtsoV2.getFeedById (XRP/USD · FLR/USD)
Prices premiums and sizes make-whole payouts in real time from Flare's native oracle.
FDC DA-Layer proof fetch
Retrieves the finalized attestation plus its Merkle path before anything is submitted on-chain.
FlareContractRegistry.getContractAddressByName
Resolves every Flare address at runtime — nothing hardcoded, nothing to trust but the registry.
The claim path is permissionless — the keeper is a convenience, not a trust assumption. An autonomous watcher requests the proof the moment a deadline breaches, but the redeemer or anyone can submit it. ~600 lines of Solidity, because Flare enshrines the hard parts.
Don't take our word for it — verify it
No user testimonials, because no user has filed a claim through the deployed contract yet. Instead, the receipts the chain will vouch for:
Straight answers
Is this actually live, or a mockup?
Live. Both contracts are deployed and source-verified on Coston2, and this site reads their state on-chain with no wallet. The FDC non-payment proof has been exercised for real (tx below).
Has an end-to-end claim run through the deployed contract yet?
Not yet. What is proven today is the load-bearing leg — the FDC ReferencedPaymentNonexistence round-trip returning true on Coston2 in 99.3s, plus the deployed contracts and 91 tests at 100% unit coverage. The verify page shows a real Claimed event automatically the instant one occurs.
What actually triggers a payout?
Flare's Data Connector ReferencedPaymentNonexistence attestation — the same proof the FAssets protocol itself accepts for a redemption default. Backstop verifies it on-chain inside claim(), then pays make-whole. The claim path is permissionless: the redeemer, the keeper, or anyone can submit the proof.
Why does this need Flare — and only Flare?
Remove Flare and you'd need four separate systems: an XRPL light client, a decentralized 'payment-did-not-happen' attestation network, a price oracle, and a canonical FXRP redemption registry. Flare enshrines all four, and FDC's non-existence proof is something almost no other chain exposes natively.
What happens if many agents default at once?
Per-agent exposure caps are enforced on-chain and invariant-tested, so correlated defaults are bounded rather than unbounded. It's a mitigation, not a guarantee against every tail — and we say so plainly rather than hide it.
How fast is a payout, honestly?
Bounded by the FDC voting round — 99–129s measured across live runs (floor ~99s), set by Flare, not by us. We surface the wait in the UI instead of pretending it's instant.