Tacet · trust model

What you’re trusting, what breaks if it doesn’t hold, and the honest mitigation for each.

Carried over verbatim from PLAN-APPENDIX.md A.8 (the original Heirloom design), plus the rows the protocol escalation adds.

FDC data-provider set (>50% weight honest)Forged lapse or suppressed proofsEnshrined protocol; same trust as FAssets itself. Veto period is the human backstop.
FAssets agents pay redemptionsBeneficiary gets collateral + premium, not XRPDefault path automated by the keeper (executeRedemptionDefault); stated plainly.
SIMULATED_TEE, not hardwareScaffold operator can read sealed messagesDisclosed prominently. Funds never depend on the TEE — claimSealed pays the address in the revealed preimage, never the TEE operator or msg.sender.
Keeper liveness — proofs constructible only ~14 days after a windowMissed windows silently expire; lapse needs a fresh streakPermissionless: anyone can keep; we run one; /verify/pnpm verify:all shows window coverage.
Owner key (XRPL) stolenThief can heartbeat forever and the vault never releases. Not a will, not proof of death, not probate.Front-and-center disclaimer. Owner EVM key theft while ACTIVE = full withdrawal, same as any wallet.
XRPL close_time vs EVM clock skewBoundary racesskewMargin + beat at window midpoint + self-check in beat.ts (exactly one memo, exactly 32 bytes).
Consequence code is arbitraryA malicious/buggy consequence can only lose its own depositors' fundsThe registry never holds funds — obligations pointing at other consequences are untouchable because there is nothing shared to drain. Hook failure (revert/OOG) can't hold a proven lapse hostage: hookPending + permissionless retryHook. Garbage/unexpected hook return values default to TERMINATE, never a privileged write. See the hostile-consequence test family (ObligationRegistryHostileConsequence.t.sol).
SIMULATED_TEE is the only mode ever run in this repoNo hardware attestation ever backed a claim made hereDisclosed here and in RUNBOOK.md section 4 — the FCC scaffold's own deployment prerequisites (VPN to Flare's internal indexer DB, a GCP Confidential Space VM) are outside this environment's reach, so the sealed-reveal middleware was never deployed. The on-chain sealed-commitment mechanism itself (claimSealed) is real, tested, and live-demoable independent of the TEE.
Round-advance/redemption gas budgetingA consequence hook that does too much work (e.g. close()+register() inside a compliance hook) reverts under the registry's 300k-gas stipendCircleConsequence splits round-advance into a separate permissionless advanceRound() call outside any hook — a lesson learned live in this repo (see RUNBOOK.md gotchas), not a theoretical concern.

Range proven

Three consequences ship in this repo, each a different shape of money logic on the same proof rails:

  • VaultConsequence — 1-party, terminal, custody (inheritance-style release).
  • CircleConsequence — N-party mutual obligation with REARM-by-default-only (a defaulting member’s own obligation terminates; the circle continues).
  • GuardConsequence — 2-party, bidirectional, compliance-driven (release and refund are both first-class outcomes, not just a silence penalty).

A fourth, CharityConsequence, was built entirely from templates/consequence-template — proving the abstraction holds for someone who has never seen the registry’s internals before, not just the reference implementations.

What auditors should re-check themselves

Everything in pnpm verify:all’s output is independently reproducible from a Coston2 RPC alone: every stored proof is re-decoded from its original transaction calldata and re-submitted as a fresh view call against the live FdcVerification/Relay root, not against a cached or trusted intermediate result.