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. ~550 lines of Solidity, because Flare enshrines the hard parts.
Don't take our word for it — verify it
No user testimonials — just what the chain vouches for, including a real end-to-end claim that already paid out on-chain:
Straight answers
Is this actually live, or a mockup?
Live. Both contracts are deployed and source-verified on Coston2, this site reads their state on-chain with no wallet, and a full end-to-end claim has already paid out on-chain (guard #1 PAID, tx below).
Has an end-to-end claim run through the deployed contract yet?
Yes. A real FXRP redemption defaulted on Coston2, the keeper built the FDC ReferencedPaymentNonexistence proof from the live redemption ticket, and Backstop.claim paid the redeemer make-whole — guard #1 PAID, 111.55 C2FLR (claim tx 0x5fde024f…). Not synthetic: redeem → buyGuard → default → claim → payout, every leg on-chain.
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 — measured at 99.3s on-chain, set by Flare, not by us; payout lands within one voting round. We surface the wait in the UI instead of pretending it's instant.