What Signet has actually proven

core lifecycle

unavailable coston2 testXRP

One Coston2 FAssets redemption was paid on XRPL Testnet and completed with FDC evidence.

What this does not prove

• Not executed yet. Owned by phase 10.

Evidence

unauthorized refused

unavailable coston2 testXRP

An arbitrary XRP payment request received no signature.

What this does not prove

• Not executed yet. Owned by phase 07 locally and phase 10 on the target chain.

Evidence

source lock

verified

Every external protocol dependency Signet uses is pinned to a specific upstream commit and verified by content hash on every build.

What this does not prove

• Content hashes bind the checked-out tree to the pinned commit. They do not attest that the upstream commit itself is honest.
• Six of the nine pinned repositories declare no license file; recorded as UNDECLARED_IN_REPO rather than guessed.

Evidence

• docs/source-lock.json
• scripts/fetch-upstream.mjs
• scripts/verify-source-lock.mjs
• docs/evidence/phase-00.md

coston2 addresses verified

verified coston2

Every Coston2 address Signet depends on was resolved from an authoritative source and proven by RPC, cross-checked against a second independent endpoint, to hold code that exposes the exact function selectors Signet depends on.

What this does not prove

• Read-only verification. No transaction was sent.
• Selectors are proven reachable through the live dispatcher, diamond loupe or EIP-1967 implementation. That proves the entry point exists, not that its behaviour matches the pinned interface. Behaviour is owned by phases 02 to 05.
• FCC addresses come from the pinned scaffold manifest, not from ContractRegistry. One live facet, the one serving getRandomTeeIds, is not named in that manifest.
• Runtime code hashes are cross-checked against two independent RPC operators; a disagreement halts resolution.

Evidence

• docs/source-lock.json#contracts
• deployments/coston2.json
• scripts/resolve-coston2.mjs
• docs/evidence/phase-00.md

fassets fxrp live

verified coston2

The Coston2 FXRP AssetManager is live, exposes both memo-mode and destination-tag redemption entry points, and has agents with free collateral.

What this does not prove

• Read-only. No redemption has been created.
• Signet is not a whitelisted FAssets agent on Coston2, so it cannot yet be the agent assigned to a redemption.

Evidence

• docs/protocol-seams/fassets-access-probe.json
• docs/source-lock.json#contracts
• docs/evidence/phase-00.md

tee hardware attested

unavailable

Signet's signing key was protected from the host by hardware attestation.

What this does not prove

• V0 runs a simulated TEE. Simulated execution is not hardware attestation and must be labelled as simulated wherever it is shown.
• Requires a real GCP Confidential Space deployment, which is out of scope for this run.

Evidence

reference model frozen

verified

Signet's authorization decision is specified by a network-free executable model whose canonical commitment encoding and decision fixtures are frozen and machine-checked on every build.

What this does not prove

• Local execution only. The model is a specification, not evidence that any deployed component implements it.
• The Go extension and the Solidity contracts do not yet consume the fixtures; that agreement is owned by phases 06 and 07.
• Rules were derived from FAssets source pinned at commit 6d5c103e4342f0fc7d3683a433a90349d544f774 and are only as current as that pin.

Evidence

• reference/src/decide.ts
• reference/test-vectors/decision-fixtures.json
• docs/adr/0001-canonical-encoding.md
• docs/adr/0002-policy-semantics.md
• docs/evidence/phase-01.md

fassets seam proven

verified coston2

Signet reads a real Coston2 FAssets redemption in both memo and destination-tag mode and reproduces its payment reference independently in TypeScript and Solidity, matching what the chain recorded.

What this does not prove

• Read-only verification against live Coston2 at pinned blocks. No transaction was sent and nothing was deployed.
• Every obligation read belongs to a third-party agent, because Signet is not a whitelisted FAssets agent on Coston2.
• The completion entry points are selector-verified but not exercised; the proof they consume is owned by phase 05.
• Behaviour is only as current as the pinned block and the pinned FAssets commit.

Evidence

• docs/protocol-seams/fassets.md
• docs/protocol-seams/fassets-seam-evidence.json
• contracts/test/fork/FAssetsSeam.t.sol
• contracts/src/adapters/FAssetsAdapter.sol
• docs/evidence/phase-02.md

upstream reproducible

verified

Every pinned upstream source reproduces byte-identically from an empty checkout, verified by content hash on every build.

What this does not prove

• Proven by deleting upstream/ entirely and re-running make bootstrap: 11 sources, all content hashes matched, 40 seconds.
• Reproducibility binds a checkout to a pinned commit. It is not an attestation that the upstream commit itself is trustworthy.
• Depends on GitHub remaining able to serve those commits.

Evidence

• docs/source-lock.json
• scripts/fetch-upstream.mjs
• scripts/verify-source-lock.mjs
• docs/evidence/phase-02.md

xrpl exact payment validated

verified testXRP

A 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 reference of a real Coston2 obligation.

What this does not prove

• XRPL Testnet only. Test-only key material throughout.
• The payment was not triggered by a real FAssets redemption assigned to a Signet-controlled agent; the obligation fields were taken from a real Coston2 redemption belonging to a third-party agent, and the payment itself is a seam proof rather than a settlement.
• Signing used the xrpl SDK in a local process, not the Go extension inside a TEE. The extension implementation is owned by phase 07 and hardware attestation is out of scope for this run.
• No FDC proof and no FAssets completion accompany this payment; those seams are owned by phase 05 and phase 10.

Evidence

• evidence/receipts/xrpl-payment-7500DA52CAB254DBD1B64BC88975B2D01C4DFDF309A6C78398C57142493759AF.json
• docs/protocol-seams/xrpl.md
• docs/evidence/phase-04.md

xrpl reliable submission

verified testXRP

Signet persists a signed XRPL transaction before first submission, never treats a provisional response as final, and reports a transaction definitively absent only when an endpoint that was itself asked for the transaction can prove it sees the entire payment window.

What this does not prove

• Ten adversarial cases on XRPL Testnet, including a real expiry allowed to pass its LastLedgerSequence, plus five stubbed-transport regression tests for cross-endpoint disagreement, which the live network cannot be made to produce on demand.
• An adversarial review reproduced a path where absence was inferred from an endpoint that had never been asked for the transaction. That is fixed and regression-tested; the claim above is worded to the fixed behaviour.
• Persistence uses writeFileSync without fsync or atomic rename, so durability under OS-level crash is not guaranteed. Recorded as a phase 08 hardening item.
• The reconciler is a script, not the durable coordinator; restart-safety under a real database is owned by phase 08.
• Both endpoints are public infrastructure rather than independently operated providers under Signet's control.

Evidence

• evidence/receipts/xrpl-adversarial.json
• scripts/xrpl/submit.mjs
• scripts/xrpl/reconcile.test.mjs
• docs/protocol-seams/xrpl.md
• docs/evidence/phase-04.md

xrpl key lifecycle

verified testXRP

The agent's XRPL account is controlled by a rotatable RegularKey while the master key stays offline as the recovery path.

What this does not prove

• SetRegularKey validated at ledger 19822182 and the configuration read back from a validated ledger.
• lsfDisableMaster is deliberately not set, so the master key retains authority and must be protected accordingly.
• The master key was used once, locally, on this machine. It has never been inside a TEE, a CI environment or a hosted service, but nor is it in the offline custody a production deployment requires.
• Rotation and emergency revocation are modelled but have not been exercised on chain.

Evidence

• evidence/receipts/xrpl-set-regular-key-03445ECA6C42EA46BDF2AA0CBAA348C0A889529334798126602BDC9477E3C82F.json
• docs/protocol-seams/xrpl.md
• docs/evidence/phase-04.md

fdc request and response proven

verified testXRP coston2

The FDC verifier confirms Signet's XRPL Testnet payment and reports source, destination, amount and memo that satisfy every rule FAssets applies when confirming a redemption.

What this does not prove

• Read-only verifier query. No attestation request has been submitted to FdcHub, which is payable and needs C2FLR, so no Merkle proof exists and nothing has been verified on chain.
• The ten cross-checks compare FDC's response against the FAssets confirmation rules read from pinned source. They are not a substitute for FAssets actually accepting a proof.
• The obligation whose payment reference this payment carries belongs to a third-party agent; no FAssets redemption has been settled.
• Proof replay, proof-owner mismatch and the payment-nonexistence path cannot be tested without a proof.

Evidence

• evidence/receipts/fdc-request-7500DA52CAB254DBD1B64BC88975B2D01C4DFDF309A6C78398C57142493759AF.json
• docs/protocol-seams/fdc.md
• docs/evidence/phase-05.md

contracts cannot authorize arbitrary fields

verified

Signet's contracts expose no path by which a caller supplies a payment field, the instruction sender is pinned so a binding cannot be detached from the FAssets adapter, and the on-chain obligation hash matches the reference model byte for byte for a real Coston2 obligation.

What this does not prove

• Local execution only. Nothing is deployed; deployment needs C2FLR.
• Governance can still approve a decision signer it controls. Nothing on chain distinguishes that from an enclave key without attestation-bound registration, which is phase 03's blocked half. Recorded as accepted residual risk and pinned by a passing test.
• Every governance function executes immediately with no timelock. FR-004's multisig and delay are assumed to live in the governance contract, which is outside this repository and not enforced here.
• recordFinalEvidence is governance-gated as a placeholder rather than gated on deterministic evidence checks, which needs the phase 05 proof path.
• Ordering across generations of one request is enforced by the decision, not by the contracts.
• Coverage is example-based; invariant and fuzz campaigns are owned by phase 13.

Evidence

• contracts/src/SignetInstructionSender.sol
• contracts/src/SignetRegistry.sol
• contracts/test/unit/SignetRegistry.t.sol
• contracts/test/unit/ObligationHashParity.t.sol
• docs/evidence/phase-06.md

go matches reference model

verified

The Go extension policy produces byte-identical decisions to the TypeScript reference model on all 62 frozen fixtures, including the authorization commitment and the transaction template.

What this does not prove

• Local execution only. The Go decision has never run inside a TEE, simulated or otherwise.
• Conformance proves the two implementations agree. Both could be wrong together about what FAssets requires; that is tested independently by phases 02 and 05.
• The extension does not yet sign an XRPL transaction, nor serve the FCC HTTP surface. The template is produced and proven identical; signing and serving remain.
• One genuine divergence was found and fixed on the first run: Go clamped a negative request generation where the reference model falls back to an unattributable hash.

Evidence

• extension/internal/conformance/fixtures_test.go
• extension/internal/policy/policy.go
• extension/internal/canonical/encoding.go
• reference/test-vectors/decision-fixtures.json
• docs/evidence/phase-07.md

coordinator durability

verified

Signet's coordinator state schema makes duplicate authority impossible by database constraint: a duplicate event, a concurrent worker, a stale fencing token and a restart between signing and submission were each attempted against a real PostgreSQL and each failed to create a second authority.

What this does not prove

• Local PostgreSQL 17 in Docker, not a managed deployment.
• The schema and its constraints are proven; the coordinator process that would use them is not written, because its observers consume deployed contract events and deployment is blocked on C2FLR.
• Crash injection is proven at the state layer rather than by killing running processes.
• The signed blob is stored in plain text; encryption at rest is a phase 13 hardening item.

Evidence

• coordinator/migrations/0001_initial.sql
• coordinator/test/durability.test.mjs
• docs/evidence/phase-08.md

composed lifecycle

verified xrpl-testnet coston2-fork

One command runs a Signet redemption end to end: real FAssets code on a Coston2 fork produces the obligation, the run asserts field by field that every obligation value reaching the decision is the one FAssets emitted, three independent implementations agree on the obligation hash, and the authorized payment is signed, persisted before submission, executed on XRPL Testnet, reconciled to validated, refused on replay by the ledger itself, and accepted by the FDC verifier. Twelve attack lifecycles produce the exact reason codes the specification requires, three malformed inputs are rejected identically by both deciders, and the Go and TypeScript implementations agree on every case.

What this does not prove

• The Flare half runs on a fork of Coston2, not on Coston2 itself. Target-chain deployment is phase 10 and is blocked on C2FLR.
• The extension ran as an ordinary process. There is no TEE and no attestation; the approved code hash binds the decision to a specific build but says nothing about where it executed.
• A coordinator that reports a real obligation with a destination or amount of its choosing obtains a real signature. PRD 22.3's 'coordinator cannot obtain arbitrary signature' is NOT satisfied by this phase. What exists is attributability after the fact via commitment recomputation, and the verifier that performs it is phase 11.
• Signing happens in the orchestrator process, which stands in for the untrusted coordinator and holds both the decision and the key. No code yet binds a signature to an authorized decision.
• Tag mode and ticket mode are covered by fixtures rather than end to end; this obligation used neither.
• The coordinator's PostgreSQL layer is not joined into this run.
• The 59/59 figure belongs to one run against live testnet state. A rerun picks a fresh head and request id.

Evidence

• scripts/lifecycle/run.mjs
• docs/evidence/phase-09.md
• docs/evidence/artifacts/lifecycle-run.json
• evidence/receipts/lifecycle-28B48DC36ACFDA1C22E97C033941355E4680B8F28964DB78F68AA44B41FBEFF4.json

independent verifier

verified xrpl-testnet coston2

An 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 agreement, reads the obligation from the Coston2 AssetManager over plain eth_call, recomputes the FAssets payment reference and the authorization commitment rather than believing the recorded ones, and reports UNVERIFIABLE with its own exit code for anything it cannot check. Ten deliberately corrupted bundles are each caught.

What this does not prove

• The FAssets half of every current receipt is UNVERIFIABLE, because every obligation this run produced was created on a fork. The verifier refusing to claim otherwise is what is proven, not that the comparison works against a public obligation.
• No FDC Merkle proof and no FAssets completion are verified, because neither exists without C2FLR.
• decisionContext is supplied by the receipt, so a receipt that lied about it would produce a self-consistent commitment. Binding it to the registry's on-chain record needs the registry deployed, which is phase 10.
• The evidence bundle is a directory of receipts rather than a signed, content-addressed archive.

Evidence

• verifier/src/verify.ts
• verifier/test/corruption.test.ts
• docs/evidence-schema.md
• docs/evidence/phase-11.md
• evidence/receipts/lifecycle-28B48DC36ACFDA1C22E97C033941355E4680B8F28964DB78F68AA44B41FBEFF4.json

proof surface

verified

A static proof page and operator view are generated from the repository's own evidence, with no server to trust. Build-failing checks assert that every claim and every limitation in the ledger is rendered, that unverified claims appear as prominently as verified ones, and that a receipt which only proves a seam is visibly labelled as one. Accessibility is checked structurally and by computed colour contrast.

What this does not prove

• The two-minute judge path was not timed by a third party.
• No screen-reader testing, no human keyboard walkthrough and no browser matrix. The checks are static analysis of the emitted HTML.
• design.md's Fog is 4.40:1 on Paper, below the 4.5 needed for normal text; the pages use Steel there instead.
• Deployed to Cloudflare Pages at https://signet-proof.pages.dev using an existing local Wrangler OAuth login; no new credentials were required.

Evidence

• web/src/build.mjs
• web/test/check.mjs
• docs/evidence/phase-12.md

hardening

verified coston2

The dependency scan is clean, the decision boundary survives 6.2 million fuzz executions without a panic or an untyped refusal, thirteen threats are closed with the mechanism and proof for each, five medium risks are accepted with stated reasons, and the whole suite passes from a fresh clone built only from the lockfile.

What this does not prove

• One threat is open and rated high: a coordinator can obtain a signature for a destination it chooses. PRD 22.3's mitigation is not implemented; what exists is detection after the fact.
• No container scan, because nothing is containerised.
• No process-level chaos testing; crash and concurrency behaviour is proven at the database and ledger layers instead.
• No external penetration test, no third-party audit, and no screen-reader testing.

Evidence

• docs/threat-model.md
• docs/runbooks/recovery.md
• docs/evidence/phase-13.md
• extension/internal/policy/fuzz_test.go
• extension/internal/wire/fuzz_test.go

coston2 deployment

verified coston2

The Signet registry and instruction sender are deployed on Flare Coston2 at 0x381bdE5961695914B28B16f405d51E8acB877f6e and 0xd6cF30B6411DB8465147FfDcF0e0418030B4b9CA, with the instruction sender pinned one-shot, the extension binary's measurement approved as the code hash, and a result signer that is provably not governance.

What this does not prove

• Testnet only, with a testnet-only governance key.
• The approved code hash is keccak256 of a locally built binary. It binds decisions to a specific build and says nothing about where that build executes; there is no TEE.

Evidence

• deployments/coston2.json
• scripts/deploy-coston2.mjs
• docs/evidence/phase-10.md

fdc proof on chain

verified coston2 xrpl-testnet

An 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 was retrieved from a DA Layer operator, and FdcVerification accepted that proof on Coston2 against the root Flare's validators signed.

What this does not prove

• Coston2 and XRPL Testnet only.
• An accepted proof establishes that the payment happened. It does not establish that the payment settled any FAssets obligation.
• The attestation is Flare's, over an XRPL payment. This is not hardware-attested execution: the extension that produced the payment ran as an ordinary local process rather than in a TEE, and no enclave measurement is involved.

Evidence

• scripts/fdc/prove.mjs
• docs/evidence/phase-10.md
• evidence/receipts/fdc-proof-28B48DC36ACFDA1C22E97C033941355E4680B8F28964DB78F68AA44B41FBEFF4.json
• evidence/receipts/target-chain-8A1492D15309AEBA34ABDE3D03D2FAD5B735165435A3C90F8C6CAFCB571AB51A.json

target chain lifecycle

verified coston2 xrpl-testnet

Against a genuine Coston2 redemption that anyone can read, Signet opened an action on its deployed instruction sender, produced a decision whose obligation hash matches the deployed contract and both independent implementations, signed and persisted a payment before submitting it, reached validated success on XRPL Testnet, was refused by the ledger on replay, and had the payment attested by FDC and accepted on chain. An independent verifier run from a fresh clone with no credentials confirms all of it, including recomputing the authorization commitment.

What this does not prove

• Signet did not settle this redemption. The agent paid it first from its own underlying address and confirmed it; Signet paid the same obligation again 36 ledgers later. See docs/adr/0003-underlying-payment-precheck.md.
• Signet has never settled a FAssets obligation. Settlement requires the payment to come from the agent's own underlying address, which requires the agent whitelist.
• The obligation was created by us acting as a minter, and the agent's vault was bound to our own XRPL account, which is what created a second payer.
• The extension ran as an ordinary process. No TEE and no attestation.
• This is not hardware-attested execution. The extension ran as an ordinary local process rather than in a TEE, and the approved code hash binds the decision to a build without saying where that build ran.

Evidence

• scripts/lifecycle/target-chain.mjs
• docs/evidence/phase-10.md
• evidence/receipts/target-chain-8A1492D15309AEBA34ABDE3D03D2FAD5B735165435A3C90F8C6CAFCB571AB51A.json

duplicate payment gap

verified coston2 xrpl-testnet

A FAssets redemption status of ACTIVE does not mean the obligation is unpaid; it means the underlying payment has not yet been confirmed on Flare. Signet paid a live Coston2 obligation that the agent had already paid 36 ledgers earlier, while FAssets still reported ACTIVE. None of Signet's duplicate-payment guards can see a payment made by another party.

What this does not prove

• This is a recorded defect, not a fixed one. The durable fix is a new decision input and a protocol version bump, proposed in ADR 0003 and deliberately not made during this run.
• An operational mitigation exists in scripts/lifecycle/target-chain.mjs, which scans the destination account for an existing payment carrying the obligation's reference and refuses to sign. It is one layer out from where the check belongs.
• In the deployment Signet is designed for it is the agent's only signer, so the second payer that triggered this should not exist. That narrows the exposure; it does not close it.

Evidence

• docs/adr/0003-underlying-payment-precheck.md
• docs/evidence/phase-10.md
• evidence/receipts/target-chain-8A1492D15309AEBA34ABDE3D03D2FAD5B735165435A3C90F8C6CAFCB571AB51A.json