Signet reads the redemption obligation from Flare, derives the payment instead of accepting caller-supplied fields, checks XRPL for a prior payment, and returns execution evidence through FDC.
Each step opens. Nothing here needs reading in order.
Destination, amount, reference, destination tag and the payment window all come from FAssets protocol state, read on chain. Nobody types them.
authorizeRedemption(uint256,uint32) has no parameter for a payment field. Signet also observes the XRP ledger itself, across independent endpoints that must agree, before it will authorize anything.
The signed transaction is persisted before submission, and the chain records at most one instruction dispatch per request and generation.
An XRPPayment attestation carries the memo and destination tag a generic payment proof would not, and FdcVerification accepted it on Coston2.
A representative obligation, and every way a caller might try to bend it. This runs from a committed fixture and makes no network call, so it is labelled a deterministic demo rather than live. The reason codes are the real ones the policy returns.
This is all a caller supplies.
Read-only. There is no parameter through which these could be supplied.
Pick a move. The outcome is what the deployed contract and the policy actually do.
Impossible through the deployed API
The entry point is authorizeRedemption(uint256 requestId, uint32 generation). There is no destination parameter to change. A 256-run fuzz over caller addresses asserts one request id yields one payload for every caller.
Impossible through the deployed API
Same reason. The amount is read from the FAssets obligation by the contract, so a caller has nothing to alter.
Impossible through the deployed API
The reference is the obligation's identity on the ledger and is resolved on chain, not accepted from a caller.
Refused · S021_PAYMENT_ALREADY_OBSERVED
This is not hypothetical. It happened on live Coston2 with request 44928272, and it is why schema V2 requires the signing boundary's own XRP ledger observation.
Refused · S022_UNDERLYING_STATE_UNAVAILABLE
Refusing is the default. There is no input that authorizes without an observation, and too few agreeing sources counts as no observation.
Refused · S023_UNDERLYING_STATE_DISAGREEMENT
Endpoints that disagree fail closed, and this one is deliberately never retried automatically.
Refused · S024_UNDERLYING_OBSERVATION_STALE
An observation too old to rely on is refused rather than accepted with a warning.
Refused by the XRP ledger itself
The identical signed blob resubmitted returns tefPAST_SEQ: the account sequence is already consumed. Signet does not have to be trusted for this one.
Reason codes: S021_PAYMENT_ALREADY_OBSERVED, S022_UNDERLYING_STATE_UNAVAILABLE, S023_UNDERLYING_STATE_DISAGREEMENT, S024_UNDERLYING_OBSERVATION_STALE.
What each one means.
The job: fulfil redemption obligations without leaving an unrestricted XRPL spending key available to a compromised operator host. Before Signet, a hot signer can authorize arbitrary XRP. With Signet, a request id goes in and a protocol-derived obligation comes out as the only admissible payment.
A wallet is optional and never implies agent status.
Read the canonical obligation from Coston2 by request id.
Independent endpoints must agree before a decision is possible.
Authorization or a typed refusal, with the reason code.
A live redemption was still ACTIVE on Flare after the assigned agent had already paid it on
XRPL. Signet read ACTIVE as unpaid and sent the same obligation again.
Three duplicate-payment guards, all watching Flare.
From its own underlying address, on XRPL.
36 ledgers later. No third party lost funds, which is luck about the test setup.
V2 requires the signing boundary's own XRPL observation, bound into the commitment.
Six of 34 claims. Each one links to its evidence and to everything it does not prove.
The only payment-bearing entry point on Signet's deployed FCC instruction sender is authorizeRedemption(uint256 requestId, uint32 generation).
View evidenceA transaction template produced by the Signet reference model was signed by a rotatable RegularKey and reached validated success on XRPL Testnet, unmodified, carrying the FAssets payment …
View evidenceAn XRPL Testnet payment made by Signet was attested by the Flare Data Connector end to end: the request was paid for and submitted to FdcHub, the voting round finalized, the Merkle proof …
View evidenceA FAssets redemption status of ACTIVE does not mean the obligation is unpaid; it means the underlying payment has not yet been confirmed on Flare.
View evidenceAn independent verifier runs from a fresh clone with no credentials and checks a Signet receipt against sources this repository does not control: it asks every XRPL endpoint and requires …
View evidenceNo machine is registered.
View evidenceFive FCC states, tracked separately, because collapsing any two of them is how a project ends up implying attestation it does not have.
No wallet, no funds, no Docker, no GCP, no secrets. One command from a fresh clone.
make judge
→ 13 PASS · 0 FAIL · 2 UNVERIFIABLE