sofispecs

Instruction file imported from deterministicstatemachine/dsm (.github/instructions/sofispecs.instructions.md). Copyright stays with the author.

SoFi: Sovereign Deterministic Finance A Normative Specification for Deterministic Limbo Vaults, Encumbrance Accounting, Multi-Vault Routing, and Non-Authoritative Storage Infrastructure Brandon “Cryptskii” Ramsay Version 2.0 – August 20, 2026 Abstract SoFi extends DSM’s ordinary bilateral transaction model by making one counterparty state object executable while its owner is absent. A liquidity provider funds a Deterministic Limbo Vault (DLV) by moving value out of ordinary spendable owner balance and into encumbered DLV reserve state. The DLV therefore holds the liquidity mathematically; the LP does not retain a second spendable copy. The LP controls the DLV by committing the policies that govern its state transitions, but while value remains encumbered the LP is also bound by those policies. Market transitions may move DLV reserves only through successors permitted by the owner-committed DLV fulfillment policy, the applicable token policy, the remaining reserves, and the committed per-transition size bound. Returning reserves from the DLV to ordinary owner balance is a separate governed release transition and requires satisfaction of the vault’s committed release/close policy. This is the practical difference from an ordinary DSM transaction initiated online while the remote counterparty is absent. The present party may send its own value toward the absent party, but cannot cause value already controlled by the absent party to move outward without authority that was committed before the absent party left. A funded DLV is that authority embodied as encumbered executable state: the value is already inside the DLV, and the conditions under which the DLV may exchange it were fixed in advance. A live trader may therefore buy from the DLV while the LP is absent. The market transaction itself is online; only the LP may be absent. The DLV does not replace DSM bilateral state. The initiating trader still advances under ordinary DSM parent, signature, conservation, pending, and Tripwire rules. The LP still maintains its bilateral relationship state against an active DLV. While the LP is absent, that owner-side relationship state may lag the DLV’s realized market history; if the LP returns while the DLV remains active, it deterministically catches up and publishes a fresh authenticated baseline. Catch-up is synchronization of already-realized DLV state, not a new approval, veto, or value movement. If a terminal owner close has already become binding-final and folded, that close is itself the final owner/DLV state update and no separate catch-up step exists for the retired DLV. Because a public DLV may be targeted concurrently by unrelated traders, more than one constructor can derive a valid bounded fulfillment from the same DLV parent before either learns of the other. SoFi adds a scoped client-driven quorum-binding procedure for the DLV resource keys. A quorum COMMIT makes one candidate binding-final for those DLV parents: no competing candidate may consume them. What binding Finality means economically depends on the successor kind. For a market bundle, binding does not by itself move the DLV reserve cursor: the exact trader bilateral successor must also be accepted under ordinary DSM and produce a verifiable trader-acceptance witness carrying the ordinary accepted-successor commitment C+ T , its successor-state authentication σ+ T , and inclusion evidence under the root committed by C+ T . Only a binding-final market bundle with that witness is a realized DLV settlement eligible 1 SoFi: Sovereign Deterministic Finance Revision 15 for composition. A binding-final market bundle whose trader leg never completes can lock the DLV parent, but it cannot skew advertised reserves or create a half-completed exchange. Owner release/close is intentionally different after the same binding race: in the beta profile PR is owner-local by construction, and the exact owner-signed release successor plus every fact needed to verify it exist before binding begins. If that release/close candidate reaches binding Finality first, the release successor is realized immediately at the DLV, the released reserves are credited exactly once according to that successor, and a terminal close retires the vault. No owner-side acceptance artifact or post-binding materialization step exists. For any one unchanged DLV parent, at most one binding-final unresolved market candidate can occupy that parent at a time. Storage members do not form or announce the quorum and do not understand the trade. Class K contacts the owner-committed storage set, verifies canonical responses, and computes the fixed threshold locally. Storage members remain application-blind opaque-byte persistence plus generic conditional-storage machinery. Canonical protocol objects are immutable content-addressed bytes; logical paths are discovery indexes only. SoFi market settlement is online, no wall-clock timeout changes validity, and there is no global ledger, global mempool, validator ordering market, or shared global sequence. 2 SoFi: Sovereign Deterministic Finance Revision 15 The Core Mental Model A DLV Holds the Liquidity; the LP Commits the Rules The shortest correct way to think about SoFi is that a DLV is actual encumbered reserve state owned and controlled by the LP but no longer available as the LP’s ordinary spendable balance. Funding is a state move, not a promise: fund DLV BLP −−−−−−→ RDLV . ⏞ ⏟⏟ ⏞ ⏞ ⏟⏟ ⏞ ordinary spendable balance encumbered DLV reserves There is no second spendable copy on the LP side. Once funded, the market trades against the DLV’s reserves themselves. Ordinary DSM transaction with an absent counterparty. Suppose Alice is online and Bob is not presently participating. Alice may originate a transfer of Alice’s own value toward Bob under ordinary DSM bilateral machinery. What Alice cannot do is cause value already controlled by Bob to move outward toward Alice, because Bob is absent and has supplied no fresh authority for that outbound transition. A bilateral step requiring Bob to send value therefore waits under the ordinary pending/participation rules. DLV transaction with an absent LP. Now suppose Bob previously moved liquidity into a DLV. That value is already inside an executable state object whose market-transition rules Bob committed before Alice appeared. The DLV policy defines the admissible fulfillment family, the token policy constrains what the token permits, the remaining DLV reserves bound what exists to be exchanged, and BM supplies the committed per-transition size ceiling. Alice may provide the required consideration and receive the corresponding DLV reserve output while Bob is absent. Alice is not spending Bob’s ordinary balance and no storage node is granting permission; she is exercising a transition the funded DLV was already allowed to make. ordinary absent counterparty ⏞ ⏟⏟ ⏞ may receive; cannot newly send value out −→ funded DLV ⏞ ⏟⏟ ⏞ holds value and may exchange it under committed rules The owner controls the DLV but is also bound by it. Ownership does not mean the LP can directly spend the encumbered reserves. While the value remains inside the DLV, every market movement must satisfy the DLV market policy and token policy. Moving the remaining reserves back to ordinary owner balance is itself a DLV state transition. The vault birth state therefore commits a release/close policy PR; withdrawal or close is valid only when that condition and the ordinary parent, conservation, signature, and contention rules are satisfied. The reverse move is: valid release/close successor under PR −−−−−−−−−−−−−−−−−−−−−−−→BLP. RDLV The LP cannot bypass that transition merely because it owns the DLV. Release/close also contends for the current DLV parent, but it has no trader-like second leg. In the beta profile PR is owner-local by construction, and the exact owner-signed release successor is complete before the first mutating binding step. If the close candidate wins binding first, competing market candidates lose that parent and the same binding-final result makes the already-authorized release successor composable. The reserve debit from the DLV and credit to ordinary owner balance are one conservation-preserving owner/DLV state transition. A terminal close retires the DLV; there is no owner-side acceptance artifact, no post-binding owner action, and no owner-bound-but-unrealized state. 3 SoFi: Sovereign Deterministic Finance Revision 15 The LP still has bilateral state. The LP’s bilateral relationship state against an active DLV still exists. If the LP is absent while the DLV trades, that owner-side relationship state may lag the DLV’s realized market-successor history. If the LP returns while the DLV remains active, it catches up deterministically to those already-realized market successors and publishes a fresh authenticated DLV baseline. Catch-up is synchronization; it does not move value a second time and is not a new authorization step. If a terminal close has already folded, the DLV is retired and no separate catch-up transition is required for that closed vault. Why SoFi needs a quorum at all. The DLV is publicly executable under the policy the owner committed. Two unrelated traders can therefore read the same DLV parent and independently construct valid candidate successors before either observes the other. Tripwire protects each trader’s own bilateral history, but those unrelated traders do not share one trader history. The client-driven quorum procedure exists only to bind the shared DLV parent to at most one candidate bundle. That binding is deliberately not the economic reserve fold. A quorum COMMIT makes the selected bundle binding-final for the consumed DLV parent set. The DLV reserve successor becomes realized only after the initiating trader’s exact bilateral successor is accepted under ordinary DSM and a verifiable trader-acceptance witness proves that fact by authenticating the accepted post- advance root and the settlement inclusion under it. A binding-final but unaccepted trade blocks the DLV parent; it does not change the DLV’s reserves. This distinction prevents a trader from distorting the vault’s advertised reserves merely by winning the DLV contention race and then refusing to complete its own bilateral leg. What is and is not “offline.” A SoFi market trade is an online transaction. The LP may be absent. That is different from DSM’s separate offline/bearer transaction capability. Nothing in SoFi requires DLV market acquisition, quorum recovery, trader-acceptance verification, or independent binding-Finality verification to work while the device itself is disconnected. 4 SoFi: Sovereign Deterministic Finance Revision 15 Contents The Core Mental Model 3 1 Scope, Status, and Normative Language 8 1.1 1.2 1.3 1.4 Status and substantive changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Normative language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Conformance classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Clocklessness rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2 DSM Substrate Assumptions 11 3 Notation, Canonical Encoding, and Commit Bytes 12 3.1 Domain separation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2 Canonical commit bytes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.3 Transport and display encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.4 Fixed-point arithmetic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4 Deterministic Limbo Vaults 13 4.1 4.2 4.3 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Reserve ownership and custody . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Predicate bounds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5 Authority: Public Data Does Not Grant Reserve Control 15 5.1 5.2 Owner authority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Completion witness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6 DLV Bilateral Advancement and Quorum Settlement 16 6.1 Composed vault state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.2 History-bound parent anchors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.3 Stale construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.4 Committed storage set and fixed quorum . . . . . . . . . . . . . . . . . . . . . . . . 18 6.5 Complete SettlementBundle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 6.6 Settlement resource keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.7 Generic storage records and immutable bytes . . . . . . . . . . . . . . . . . . . . . . 20 6.8 Client-driven quorum binding transaction . . . . . . . . . . . . . . . . . . . . . . . . 21 6.9 DLV binding Finality, trader acceptance, realization, and evidence . . . . . . . . . . 22 6.10 Loser behavior and reroute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.11 Owner close . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7 Smart Commitments and Atomic Composition 26 7.1 Token conservation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.2 External commitments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 8 Deterministic Encumbrance Accounting 27 5 SoFi: Sovereign Deterministic Finance Revision 15 9 Trade Intent, Multi-Vault Routes, and SDK-Resident Routing 27 9.1 Trade intent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 9.2 Allocation bundles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 9.3 Routes and route sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 9.4 Select, verify, build, bind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 9.5 Deterministic reroute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 9.6 Partial execution is forbidden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 10 Trade Digests: Unordered Evidence 29 10.1 Reference windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 10.2 Bilateral agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 11 Admissibility Filters and Unilateral References 30 12 Perpetual Instruments 30 12.1 Activity-denominated funding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 12.2 Liquidation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 13 Clockless Liveness 31 14 Receipts 31 15 Storage Node Specification 32 15.1 Three separate storage concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 15.2 Hard constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 15.3 Canonical immutable objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 15.4 Discovery indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 15.5 Generic conditional-binding interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 15.6 Client-driven quorum transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 15.7 Query completeness and non-selective serving . . . . . . . . . . . . . . . . . . . . . . 36 15.8 Object and index classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 15.9 Ordinary publication and frozen exact bytes . . . . . . . . . . . . . . . . . . . . . . . 37 15.10Resource accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 16 SDK Conformance 37 16.1 Route-set construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 16.2 Verification, quorum binding, and materialization . . . . . . . . . . . . . . . . . . . . 38 16.3 Deterministic failure taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 16.4 User contract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 17 Online SoFi Market Boundary, LP Absence, and DSM Offline Transfers 40 18 Security Model 41 18.1 Storage member compromise and availability . . . . . . . . . . . . . . . . . . . . . . 41 18.2 Concurrent same-parent safety . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 18.3 Bilateral seam: trader Tripwire, DLV quorum, LP catch-up . . . . . . . . . . . . . . 42 18.4 Multi-vault atomicity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 18.5 Constructor crash and ambiguous outcomes . . . . . . . . . . . . . . . . . . . . . . . 42 18.6 Liveness, overlapping transactions, and the FLP boundary . . . . . . . . . . . . . . . 44 6 SoFi: Sovereign Deterministic Finance Revision 15 18.7 Front running and ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 18.8 Router compromise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 18.9 Vault owner compromise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 19 Economic Model 45 19.1 Liquidity providers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 19.2 Storage nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 19.3 Traders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 20 Architectural Comparison 45 21 Conformance Test Vectors 46 22 Implementation Rules for Beta 51 23 Security and Liveness Claims in Plain Language 53 24 Conclusion 55 7 SoFi: Sovereign Deterministic Finance Revision 15 1 Scope, Status, and Normative Language 1.1 Status and substantive changes This revision is a clean statement of the intended SoFi architecture and the storage boundary required to implement it without assigning financial authority to storage members. The substantive rules are:

1. SoFi remains DSM bilateral finance. A DLV is not a replacement transaction model. It is funded encumbered reserve state that can serve as the absent LP’s executable bilateral counterparty under rules committed before the trader exists.
2. The DLV actually holds the liquidity. Funding moves value out of ordinary spendable owner balance and into DLV reserve state. The LP owns and controls the DLV but does not retain a second spendable copy of those reserves.
3. The DLV is an exception to the ordinary absent-counterparty pending rule. In an ordinary DSM transaction initiated while the counterparty is absent, the present party can send its own value toward the absent party but cannot cause value controlled by that absent party to move outward without previously committed authority. A funded DLV already contains both the encumbered value and the committed market-transition rules, so a live trader may buy from the DLV while the LP is absent.
4. DLV reserve movement is policy-bounded. A market successor must satisfy the owner- committed market policy PM , the applicable token policy, the actual remaining reserves, the per-transition size ceiling committed in BM , conservation, and ordinary DSM validity. There is no separate economic quota variable in Vn.
5. Owner withdrawal is also a governed DLV transition, but beta close has no second acceptance leg. The vault birth state commits a release/close policy PR. The LP cannot directly reclaim encumbered reserves; a release, withdrawal, or close must consume the current DLV parent, satisfy owner-local PR, token policy, conservation, and exact owner authority, and win the same parent contention as a market transition. Because the complete owner-signed release successor is already verifiable before binding, a binding-final release/close folds that exact successor immediately. A terminal close returns the committed reserves exactly once and retires the DLV.
6. The LP still catches up bilaterally while the DLV remains active. The LP’s bilateral relationship state against an active DLV may lag while the LP is absent. On return to an active DLV, the LP deterministically folds the already-realized market history and produces a new authenticated baseline. Catch-up is synchronization, not authorization. A terminal close is already the final owner/DLV update and requires no separate catch-up step.
7. Stale-state rejection and concurrent DLV origination are different mechanisms. Parent binding rejects a constructor that learns the DLV has already advanced. It does not prevent two unrelated traders that both read the same DLV parent before either advancement is visible. The client-driven quorum binding transaction covers that shared-DLV contention case.
8. The trader side still uses ordinary DSM and Tripwire. The quorum does not finalize the trader’s sovereign chain. The exact trader bilateral parent/successor bound into the SettlementBundle remains subject to ordinary DSM parent, signature, conservation, pending, and Tripwire rules. 8 SoFi: Sovereign Deterministic Finance Revision 15
9. The owner fixes the storage domain. Vault creation commits both the storage-member set S and the settlement threshold q. Endpoints merely resolve committed member identities. Current reachability cannot change S or q.
10. The quorum is computed client-side. Class K contacts the members of S, authenticates distinct member responses, verifies returned canonical bytes, and locally evaluates whether at least q qualifying members agree. A Class N member does not know whether a quorum exists and does not count other members.
11. Storage nodes understand no SoFi economics. They store and serve opaque bytes and enforce only generic storage-engine rules such as content addressing, compare-and-exchange, monotonic transaction rounds, and atomic local multi-key updates. They do not parse a SettlementBundle, DLV, route, AMM invariant, fee, output, or user intent.
12. Canonical bytes and discovery aliases are different objects. Immutable protocol bytes live under deterministic content addresses. Logical paths are indexes from names to content addresses. A moving latest pointer is never canonical state and may not be used as a settlement or parent-authority input.
13. A client-driven quorum transaction may have recoverable intermediate state. An interrupted operation is not required to leave zero bytes everywhere. Intermediate generic bindingrecordsarenon-Final, protocol-recoverable, andmustconvergetooneterminalCOMMIT or ABORT under the stated liveness assumptions. A caller that loses the outcome treats it as INDETERMINATE, not as failure.
14. Multi-vault acquisition is one transaction. A route consuming several DLV parents binds all of those parents to one complete SettlementBundle. Per-vault acquisition followed by rollback is non-conforming.
15. The committed payload is complete. Before quorum binding begins, the SettlementBundle contains every DLV successor, exact initiating-trader bilateral transition, signature, proof, and recovery object needed to verify the selected route without fresh private material from the original constructor.
16. An unresolved settlement fences the initiating trader parent. Before the first mutating DLV quorum-binding step, Class K durably binds the attempt to the exact trader bilateral parent. While the DLV transaction is RECOVERING or INDETERMINATE, no different successor may advance from that parent, even under a new intent or nonce. Tripwire remains the underlying one-successor state rule.
17. Reroute requires a terminal prior outcome. A route that is explicitly ABORTED or conflicts with a previously binding-final DLV settlement may fall through to the next route already committed by the same intent. The broader trader-parent fence remains in force until the unresolved attempt becomes terminal.
18. SoFi market settlement is online. The LP may be absent; the market transaction itself is not an offline protocol. DSM may support separate offline/bearer execution, but SoFi does not require DLV market acquisition, recovery, or independent beta binding-Finality verification while disconnected. 9 SoFi: Sovereign Deterministic Finance Revision 15
19. Multi-vault horizontal allocation is first-class. One logical pair leg may allocate across several independent DLVs. The vaults remain independently owned; one route-wide Settlement- Bundle supplies all-or-none DLV-side settlement.
20. Binding Finality, realization, and availability are different. Once the quorum transaction chooses a candidate for the DLV resource keys, later node unavailability does not revoke that historical binding fact. For a market candidate, the DLV reserves still do not advance until the exact trader successor is proven accepted. For an owner-local beta release/close candidate, binding Finality satisfies the completion gate and the exact pre-authorized release successor folds immediately. A router that cannot obtain the binding evidence required to establish a discovered candidate DLV’s current composed state reports DLV_BINDING_EVIDENCE_UNAVAILABLE and excludes that candidate from the route set; it must not assume the advertised parent is still active or unchanged.
21. Permanent market unresolution has real liveness costs. An unresolved market binding can indefinitely fence the initiating trader parent and block owner close. Beta defines no timeout-based escape for that market-side seam. A binding-final owner release/close is not another unresolved state: under the beta owner-local PR profile it realizes and folds immediately. For any one current DLV parent, at most one binding-final unresolved market candidate can occupy that parent, although one multi-vault route may block several distinct DLVs.
22. Owner-offline composition depth is not magically bounded. While a DLV remains active, composition work between authenticated owner catch-up baselines grows with the number of realized market successors, and beta may also require live evidence for their underlying binding decisions. Owner catch-up collapses that active-market history into a new baseline; an LP absent indefinitely can leave a progressively more expensive active DLV to compose. A terminal close ends that lineage rather than creating another catch-up segment.
23. A double binding-Final DLV observation is catastrophic. If two distinct binding-final bundles consume one DLV parent, no tie-break is permitted. The affected lineage is quarantined and the deployment is treated as having violated its storage safety assumptions. 1.2 Normative language The key words must, must not, should, should not, and may are conformance requirements. A statement without one of these words is explanatory and carries no conformance weight. 1.3 Conformance classes Class C (Core). arithmetic. The deterministic state machine and predicate evaluator. It emits canonical commit bytes, verifies state transitions, evaluates bounded predicates, and performs deterministic Class K (SDK/STK). Discovery, route construction, route-set binding, complete settlement- bundle construction, client-driven quorum binding, local verification, deterministic materialization, publication, reroute, and user-facing execution semantics. Class K embeds Class C. 10 SoFi: Sovereign Deterministic Finance Revision 15 Class N (Node). Non-authoritative persistence, indexing, and generic conditional storage. Class N stores and serves opaque canonical bytes. It may enforce storage-generic rules required by a crash- recoverable quorum transaction—for example immutable content addressing, compare-and-exchange against a canonical key, monotonic transaction-round metadata, and one local atomic update over a sorted key set. It must not parse or validate SoFi economic payloads, determine q, count other members, select a route, or decide financial validity. 1.4 Clocklessness rule Requirement 1.1. No protocol object, predicate, commitment, settlement rule, or validity decision defined by SoFi may depend on wall-clock time, elapsed duration, a timestamp, a global height, or a shared sequence across independent parties. Local state counters scoped to one DSM chain or one DLV are permitted because they do not require a shared global ordering. Operational service measurements may use wall-clock units, but they have no effect on protocol validity. 2 DSM Substrate Assumptions SoFi does not restate DSM. It assumes the following substrate properties. Assumption 2.1 (Relationship-local state). Each participant maintains hash-adjacent state under its own authenticated state structure. A realized successor consumes an identified parent state and produces one local successor. Assumption 2.2 (Precommit). Before a conditional successor family is exercised, the relevant admissible branch family is committed. The commitment is consumed according to DSM rules. Assumption 2.3 (Whole-state consumption). Value represented by a DLV is moved only by a successor consuming the entire committed DLV state required by that transition. Partial hidden consumption is not representable. Assumption 2.4 (Tripwire). Within one DSM history, conflicting successors to one consumed parent are rejected by the local deterministic state machinery. Assumption 2.5 (Authenticated sparse state). DLV reserve leaves, encumbrance state, and related proofs are bound under authenticated sparse Merkle roots and verified locally. Assumption 2.6 (Single hash TCB). domain-separation tag. H denotes BLAKE3 with a 32-byte output and an explicit Assumption 2.7 (Signatures). DSM signatures are post-quantum EUF-CMA-secure signatures over Core-emitted canonical commit bytes. SoFi assumes SPHINCS+ as the shipping signature scheme. 11 SoFi: Sovereign Deterministic Finance Revision 15 Remark 2.8. The DLV does not weaken Tripwire. The initiating trader still advances one ordinary DSM bilateral history, so conflicting trader successors from one trader parent remain a Tripwire violation. The extra settlement rule exists because a funded public DLV holds encumbered reserves that are executable under a bounded market policy while its LP is absent, and multiple unrelated traders do not share one trader history with each other. Parent-state composition rejects a stale constructor after a DLV advancement is known, but it does not prevent two unrelated constructors that both read the same DLV parent before either advancement is visible. The client-driven quorum binding transaction supplies the missing consume-once decision for that shared DLV parent. 3 Notation, Canonical Encoding, and Commit Bytes 3.1 Domain separation Every commitment must be computed as H(tag ∥Canon(x)). The reserved tags in this revision are: Tag Purpose DSM/vault vault identity DSM/vault-state vault state DSM/precommit branch-family precommit DSM/fulfillment owner-committed fulfillment mechanism DSM/enc encumbrance set DSM/enc-claim encumbrance claim identifier DSM/intent trade intent DSM/route-set RETIRED by amendment 2c-F R1 — never reused DSM/allocation canonical same-pair allocation bundle DSM/ext external commitment X = H(DSM/ext ∥ RC*) (amendment 2c-F R1) DSM/digest trade digest DSM/ref-window reference window DSM/ref-rule unilateral reference rule DSM/receipt stitched receipt DSM/sofi-receipt/v1 Def 14.2 SofiReceipt identity ρ_B (amendment 2c-F R2) DSM/settlement-bundle complete signed settlement bundle DSM/trader-settlement-acceptance/v2 canonical trader post-advance acceptance artifact DSM/binding-tx client-driven opaque quorum transaction identifier DSM/binding-keyset sorted settlement-resource key-set commitment DSM/vault-state-anchor/v2 BURNED - deleted by the state-identity cut, never reused DSM/vault-state-anchor/v3 owner-signed baseline over the canonical state identity DSM/storage-object immutable content-addressed storage object DSM/storage-set committed storage-set identity DSM/unlock-tag receipt identifier only 3.2 Canonical commit bytes Requirement 3.1. Class C must emit canonical commit bytes (CCB) for every hashed or signed object. CCB is a Core format and is not protobuf serialization. CCB rules: 12 SoFi: Sovereign Deterministic Finance Revision 15
24. fixed-width integers, big-endian;
25. byte strings length-prefixed by a 4-byte big-endian length;
26. fields emitted in ascending declared field-number order;
27. absent optional fields emitted with an explicit absence marker;
28. sets sorted lexicographically by element CCB;
29. maps emitted as sorted key-value pairs;
30. floating point forbidden;
31. every CCB blob begins with an object-class discriminant and CCB schema version. Requirement 3.2. No two logical objects may map to one CCB encoding and no one logical object may map to two CCB encodings. 3.3 Transport and display encoding
32. Transport is protobuf only.
33. Production JSON is forbidden.
34. Binary identifiers remain binary in Core and SDK internals.
35. Base32 Crockford is the permitted human-display encoding at UI, QR, and log boundaries.
36. Hexadecimal is not a protocol or UI encoding. 3.4 Fixed-point arithmetic All prices, fees, ratios, and invariant calculations use checked integer arithmetic at scale 232 unless a token’s base-unit arithmetic is exact without fixed-point conversion. Division uses floor semantics with documented payer-adverse rounding. Overflow is predicate failure. Exact rational representations. A protocol object may instead define an exact versioned rational representation with a fixed denominator, where this specification states that denominator explicitly. Such a representation is not converted to scale 232 . Its products are evaluated in checked integer arithmetic wide enough not to overflow before any division, and the division floors exactly once, adverse to the party who would otherwise gain from the truncation. Beta FeePolicyV1 of §5.1 uses this allowance with denominator 10 000. The allowance exists because converting an exact rational such as f/10 000 to scale 232 introduces a rounding stage with no protocol meaning. Two implementations that rounded at different points would disagree on outputs while both claiming conformance. 4 Deterministic Limbo Vaults 4.1 Definition Definition 4.1 (DLV). A Deterministic Limbo Vault is an encumbered state object inside its owner’s DSM state that holds actual reserve value and acts as a precommitted executable bilateral endpoint. Funding the DLV moves value from ordinary spendable owner balance into the DLV reserve state. The LP retains ownership/control of the vault but not direct spendability of the encumbered reserves. Market reserve movement occurs only through a valid DLV successor satisfying the owner-committed market policy and applicable token policy. Returning reserve value to ordinary owner balance occurs only through a valid release/close successor satisfying the committed release policy. The DLV does not create a second copy of the reserves and does not replace DSM bilateral relationship semantics. A market DLV state is represented abstractly as Vn = (go,do,vault _ id,n,RA,RB ,PM ,PR,Φ,E,β,hn,ro,S,q), 13 SoFi: Sovereign Deterministic Finance Revision 15 wherego anddo bindowneridentity,nisthevault-localgeneration,RA,RB aretheactualencumbered reserves, PM is the bounded market-fulfillment policy, PR is the bounded release/withdraw/close policy, Φ the fee policy, E the encumbrance set, β an optional iteration budget, hn the local parent commitment, ro the committed owner-authority position, S the committed storage set, and q the fixed settlement threshold for that set. The owner-authority position ro is the digest of the exact DeviceTreeRootTransition under which the owner asserts the device authority that signs for this vault, tj = H(DSM/devtree-transition ∥ CCB(Tj )). It is INVARIANT across market successors - copied byte for byte, never advanced - because a market successor executes while the owner is absent and must not move the owner-authority reference. Changing it for a live vault requires an explicit owner-authorized successor family, which the beta profile does not define. The canonical state commitment, and the SOLE canonical identity of a DLV parent state, is cn = H(DSM/vault-state ∥CCB(Vn)), where CCB(Vn) is the canonical commitment encoding of the complete fifteen-member tuple, fixed by the CCB object registry. Every parent reference in this specification - allocations, settlement resource keys, SettlementBundle parent material and stale-parent checks - is exactly this value. The vault identity is fixed at creation and never changes. The local parent commitment hn is the lineage edge into Vn, and is defined by the recurrence h0 = H(DSM/vault-state-parent/genesis/v2 ∥vault _ id), hn = cn−1 for n > 0. The genesis value commits the vault identity and nothing else. Birth reserves, the committed storage set S, and the fixed threshold q are already fields of V0 , hence committed by c0 , and duplicating them into h0 would blur a field whose only role is the predecessor edge. An untyped all-zero sentinel is not used: a domain-separated genesis value is a value no other construction produces, and it makes "this is generation zero" a derivation rather than a magic-constant comparison. Because hn commits cn−1, and cn−1 commits the whole canonical prior state rather than its reserve amounts alone, two histories that arrive at identical reserves still differ in every later parent binding whenever any preceding canonical DLV state differed. This is the property Requirement 6.5 requires of the parent anchor, and Definition 6.4 carries hn as parent_ state _ commitment. 4.2 Reserve ownership and custody Requirement 4.2 (Reserve location and no duplicate custody). DLV reserves must not simultaneously remain available as ordinary spendable owner balance. Funding a DLV must debit the owner’s ordinary spendable state and credit the corresponding DLV reserve state in one valid conservation-preserving transition. After funding, the reserve value is represented by the DLV. A market trade never asks the LP to send from a separate balance; it consumes a DLV parent and derives a valid DLV successor. Owner absence therefore does not imply that the reserves themselves are absent. Consequence. The LP may be absent from the live market interaction while the funded DLV continues to trade. The LP’s absence changes availability only where an owner-specific transition is required, such as a policy-governed release/close or policy replacement. It does not make the market transaction offline and does not move the reserve value back into the LP’s ordinary balance. 4.3 Predicate bounds Requirement 4.3. Every predicate family must declare a static evaluation budget. Permitted operations are checked integer arithmetic, comparison, boolean composition, hashing, signature verification, sparse Merkle inclusion, membership over committed bounded sets, and iteration with compile-time bounded cardinality. Dynamic dispatch, recursion, and unbounded loops are forbidden. Requirement 4.4 (Precommitted executable market state). Consider an ordinary DSM transaction initiated online while the remote counterparty is absent. The present party may authorize movement of its own value toward that remote party, but it cannot cause value controlled by the absent party to move outward without authority committed by that absent party. A funded DLV supplies that authority by placing the value itself inside an encumbered executable state object before a particular trader exists. The owner commits PM and BM ; a later trader may exercise only a concrete DLV successor that satisfies those commitments, the applicable token policy, the actual remaining reserves, the per-transition size ceiling in BM , conservation, and ordinary DSM validity. Requirement 4.5 (DLV exception to pending and owner catch-up). The DLV is an exception only to the need for a fresh owner participation step before the DLV’s already-encumbered reserves may execute a permitted market transition. It is not an exception to parent binding, conservation, signatures required from the live trader, Tripwire, token policy, or DLV policy. The LP’s bilateral relationship state against an active DLV may lag while the LP is absent. If the LP returns while the DLV remains active, it must deterministically catch that relationship state up through the DLV market successors that were already realized. Catch-up records the DLV market history into a fresh owner-authenticated baseline; it neither moves the reserve value a second time nor constitutes a new approval, veto, rollback, or ordering step. If a terminal owner release/close 14 SoFi: Sovereign Deterministic Finance Revision 15 has already become binding-final and folded under Requirement 6.30, the DLV is retired and no separate catch-up step is required for that closed vault. Implementation (amendment 2c-G, rulings G1 + G2). Catch-up applies each certified market successor V_g → V_n in causal order as one admitted DlvOwnerApplyV2 per generation: a synchronization step that consumes certified history and never creates it — no authority, no second value move, no re-certification, no new realization boundary, no veto and no ordering step. Each apply's input-reserve credit is funded by the trader's own admitted payment (0x0027), whose evidence is projected from the exact receipt leaf and path the composition walk proved under the trader's validated root when it certified that fold; the terminal owner reserve state equals the composed frontier. One engine runs it — automatically on storage.sync and on an explicit owner request — and it gates no trader settlement, market realization, composition, future admission, QuorumBind, fence release or close finality. A failure is local to its vault, and an interrupted catch-up resumes idempotently after its last durable apply. Requirement 4.6 (Governed reverse encumbrance; owner-local beta profile). The LP must not be able to move DLV reserves directly back into ordinary spendable owner balance merely by virtue of ownership. The vault birth state commits a release/withdraw/close policy PR. Any transition that reverses the encumbrance must consume the current DLV parent, satisfy PR, satisfy the applicable token policy, preserve conservation, carry concrete owner authority over the exact release successor, and obey the same parent-contention rules as another transition competing for that DLV parent. Only the resulting valid successor may credit the released value back to ordinary owner balance. In the beta profile, PR is owner-local by construction. Its truth value must be decidable from the authenticated current DLV parent, the exact owner-signed release/close successor, the applicable token policy, and canonical proof/bundle bytes that are complete before the first mutating binding step. Beta PR must not require a post-binding owner action, an external counterparty or co- signature, a reference-window outcome, a liquidation/oracle branch, or any other external fact whose acceptance would have to be proved after DLV binding. Therefore the owner release/close path has no trader-like second completion leg. A future profile that admits externally conditioned release policies is outside this one-phase beta rule and must define its own completion evidence before such a successor may be folded. 5 Authority: Public Data Does Not Grant Reserve Control 5.1 Owner authority Authority is not a secret derived from public values. It is a signature over either a concrete successor or a bounded successor family. Definition 5.1 (Owner authority). A successor Vn+1 carries owner authority if either: (a) the witness contains Signowner(CCB(Vn+1)); or (b) the witness contains an owner-signed fulfillment mechanism committed before Vn+1 existed, plus a proof that Vn+1 satisfies every bound of that mechanism. Definition 5.2 (Market fulfillment mechanism). M= H(DSM/fulfillment ∥c0 ∥CCB(BM )), The vault identifier is NOT restated: c0 commits it, because vault _ id is a field of V0 . Supplying both would admit an encodable pair that disagrees, one generation earlier than the same pattern in allocations and resource keys. where BM commits the additional owner-committed bounds on market exercise that do not already have a home in the vault state or in the predicate family: the per-transition size ceiling and the authorized encumbrance purposes. Single value source. PM , the fee policy Φ, the committed storage set S, and the fixed threshold q are members of V0 under Definition 4.1, and c0 commits the complete canonical V0. The owner-signed mechanism therefore already commits their birth values transitively, and BM does not repeat them. This is a deliberate structural choice rather than an omission: two authoritative copies of one fact create states that encode validly while disagreeing internally, and no equality rule can be enforced by a verifier that holds only one of the two objects. Any future BM field concerning fees or storage must express a semantically distinct bound or profile constraint, never another copy of a V0 value. The layering is therefore: PM is which bounded predicate family may execute, BM is the additional owner-committed bounds on its exercise, the Smart Commitment C of Definition 7.1 is the concrete transaction-time instance over ∆in, ∆out, external commitments, encumbrances and intent bounds, and Vn is the actual reserve state being consumed. PM is committed at vault birth, before any trader exists, so it is not structurally equal to C. Shape of PM . PM is a birth-time, versioned predicate-family descriptor: PM = (family _ id,family _version,evaluation _budget,family _parameters), naming which bounded deterministic predicate family may execute and carrying only the static parameters needed to instantiate and evaluate it, together with the static evaluation budget Requirement 4.3 demands. It is not a predicate instance: ∆in, ∆out, the external commitments, the encumbrances and the intent bounds of Definition 7.1 are transaction-time values that do not exist when PM is committed, which Requirement 4.4 already implies by having the owner commit PM before any particular trader exists. Beta market family. Beta declares exactly one admissible family: family_id = CONSTANT_PRODUCT_EXACT_INPUT, family_version = 1, and family_parameters = (token_a_policy_commit, token_b_policy_commit), where both commitments are exactly 32 bytes and token_a_policy_commit is strictly less than token_b_policy_commit under unsigned lexicographic byte comparison. The canonical pair belongs to PM because the predicate must know which two reserve legs it governs. The fee does not belong here: Φ is the single authoritative fee policy, and it is a member of Vn . Pricing rule. Let a be the exact input amount, x the input-leg reserve and y the output-leg reserve of the parent Vn , let D = 10 000 be the fixed denominator of §3.4, and let f = fee_bps from Φ with 0 ≤ f < D. Then effective_num = a · (D − f), output = floor( (y · effective_num) / (x · D + effective_num) ). Every product is evaluated in checked integer arithmetic wide enough not to overflow, and the single floor division above is the only rounding in the rule. An implementation must not compute a rounded fee-adjusted input first: flooring a · (D − f)/D before applying the curve is a second rounding stage, and two implementations that disagree about whether it happens produce different outputs from identical inputs. The divergence is not a corner case that needs contrived values: at a = 1, x = 1, y = 3 and any fee_bps in the legal range, the fused rule yields 1 while the doubly-rounded variant yields 0, because flooring the fee-adjusted input first collapses a sub-unit input to zero and takes the whole output with it. Small reserves and small inputs are where the two rules part company most often, which is exactly the region a low-liquidity vault operates in. Reserve successor. The valid successor is R'_in = R_in + a and R'_out = R_out − output, crediting the FULL input to the reserve. The fee is not withheld, not routed elsewhere, and not represented anywhere in the successor: it remains inside the DLV reserves as liquidity-provider yield. That is precisely why R'_in is R_in + a and not R_in + floor(a · (D − f)/D). Admissibility. The transition is inadmissible, and no successor exists, if a = 0, if x = 0, if y = 0, if f ≥ D, if output = 0, if output > R_out, or if any checked product overflows. Acceptance predicate. A verifier recomputes output from the exact parent, direction, input, fee and bounds, and requires the proposed reserve successor to equal the values above exactly. The acceptance condition is equality with the recomputed successor. It is not an inequality over the product. Consequence, not predicate. Under a valid beta transition R'_in · R'_out ≥ R_in · R_out, with strict increase possible from the retained fee and from integer truncation. This is a theorem about the family and a useful sanity property, and it must never serve as the acceptance condition on its own: many successors far worse for the trader also satisfy it. Evaluation budget. evaluation_budget is a constant of the family version, not an owner-configurable field. A per-owner budget would let two implementations agree on every byte while disagreeing about whether evaluation exhausted its allowance, which is the same class of divergence canonical bytes exist to prevent. The beta family performs a fixed, bounded sequence of checked multiplications, one comparison chain and one division, with no iteration, so its budget is a constant declared by family_version = 1. Because family_id now names the invariant, BM carries no invariant field. The invariant is the semantics of the predicate family itself, and a second representation of it would be another alias. BM retains only the per-transition size ceiling and the authorized encumbrance purposes. Beta fee policy. Φ is FeePolicyV1, a single unsigned 32-bit field fee_bps with 0 ≤ fee_bps < 10 000, interpreted as the exact rational fee_bps/10 000 under the allowance of §3.4. A value of 10 000 or above is invalid rather than meaningful: it would make the fee at least the whole input and leave the pricing rule with a zero or negative effective numerator. The width is 32 bits because that is the representation already in use throughout, and widening or re-scaling it would change every committed fee without changing any fee. Beta release family. PR has the same descriptor shape as PM , and beta declares exactly one admissible family: family_id = OWNER_LOCAL_FULL_CLOSE, family_version = 1, with no family parameters. Its evaluation_budget is likewise a constant of the family version. The family admits exactly one successor shape. A valid release consumes the current DLV parent and drains BOTH reserve legs to zero in one transition, crediting each leg's exact remaining amount to ordinary owner balance and retiring the vault, so that no later successor may compose from the retired parent. There is no partial release in beta: a family that released part of a leg would need a released amount per leg, and that amount is exactly the parameter this family does not have. The family carries no parameters because there is nothing left to parameterise. The amounts are the parent's reserves, the destination is ordinary owner balance, the authority is the owner signature over the exact successor required by Definition 5.1(a), and the timing is governed by Requirement 6.30 rather than by the policy. A parameter here would be a value some verifier could read differently from the parent state, which is precisely what Requirement 4.6's decidability condition forbids. PR is therefore decidable exactly as Requirement 4.6 demands: from the authenticated current DLV parent, the exact owner-signed release successor, the applicable token policy, and canonical bytes complete before the first mutating binding step. It requires no post-binding owner action, no external counterparty or co-signature, no reference-window outcome, and no liquidation or oracle branch. The owner signs CCB(M) at vault creation. M commits a mechanism, not a preferred trader. Market size bound. The beta DLV state has no separate economic “quota” variable. The phrase market size bound means the per-transition size ceiling committed in BM together with the actual remaining reserves in Vn. A later profile may add a distinct cumulative quota only by committing it explicitly into the DLV state and its transition predicates. 15 SoFi: Sovereign Deterministic Finance Revision 15 5.2 Completion witness A market completion witness contains at minimum:
37. the advancing party signature over the concrete successor CCB;
38. owner authority per Definition 5.1;
39. the parent-state binding;
40. consumed encumbrance proofs;
41. route-set membership proof;
42. external-commitment binding;
43. sparse Merkle inclusion proofs required by the state transition. Theorem 5.3 (Authorization confinement). Producing a successor outside the owner- authorized concrete or fulfillment family requires forging owner authority. Producing a successor inside the fulfillment family still requires satisfying every committed bound, conservation, parent- state binding, and the advancing party’s signature. Theorem 5.4 (No general reserve release). A valid successor authorizes exactly the deltas committed in that successor. It does not create a general withdrawal capability over the vault. Interpretation. Definition 5.1(b) is authority over transitions of value that is already encumbered inside the DLV. It is not a standing instruction against a separate LP balance. The LP committed the executable successor family when funding the vault; the trader supplies the live side of the bilateral exchange, while PM , BM , the token policy, and the actual DLV reserves determine whether the concrete market successor is exercisable. A reverse transition from DLV reserves back to owner spendable balance is separately governed by PR under Requirement 4.6. 6 DLV Bilateral Advancement and Quorum Settlement 6.1 Composed vault state Definition 6.1 (Composed DLV state). The composed state of a DLV is the latest authenticated owner catch-up baseline followed by every verified DLV successor that names the current composed parent. The completion gate is successor-kind-specific: (a) a market successor is composable only when its complete SettlementBundle is binding-final under Definition 6.24 and the exact initiating trader successor has a verified acceptance artifact AB under Definition 6.26; (b) an owner release/close successor is composable when its exact release/close candidate is binding- final for the current DLV parent and the exact successor already verifies under Requirement 4.6, the applicable token policy, conservation, and concrete owner authority under Definition 5.1(a). It requires no trader-acceptance witness and no owner-side post-binding acceptance artifact. For either successor kind, Class K must verify the exact vault ID, parent generation, parent state commitment, parent reserves digest, storage-set identity, committed threshold, applicable encumbrance proofs, deterministic state arithmetic, conservation, and byte identity of the successor 16 SoFi: Sovereign Deterministic Finance Revision 15 and proof material selected by the binding decision. Market successors additionally require the route/allocation membership and X checks of the SettlementBundle and the live trader signatures required by ordinary DSM. Release/close successors additionally require owner-local PR and the concrete owner signature over the exact release successor. For a terminal close, the verified successor must credit the released DLV reserves to ordinary owner balance exactly once and mark the DLV terminal/retired so no later market successor may compose from the retired parent. This verified successor sequence is the same DLV history the LP’s bilateral relationship state must reflect. Composition is a local deterministic derivation. It is not an authority object, a second settlement decision, or an owner approval step. Requirement 6.2. A market DLV successor must not be folded unless the corresponding SettlementBundle is both binding-final and realized by a valid trader-acceptance witness. An owner release/close successor must not be folded unless the exact owner-authorized release candidate is binding-final and satisfies Requirement 4.6; no AB is required for that successor kind. An immutable object copy, a discovery-index entry, a locally prepared successor, a recovery-visible binding record, a market quorum COMMIT without trader acceptance, or an acceptance artifact without the matching market binding decision has no effect on the reserve cursor. Once a valid terminal close is binding-final, its exact release successor is folded and any advertisement that still presents the pre-close DLV as active is stale and must not be accepted for routing. Composition-depth boundary. Beta defines no synthetic checkpoint, timeout, or storage-node- created baseline. If the LP remains absent through d realized market DLV advances after its last authenticated owner baseline, fresh composition requires folding those d market successors in order, verifying their trader-acceptance witnesses, and establishing any beta binding-Finality evidence required for the underlying DLV decisions. The verification cost therefore grows with unanchored market activity. When the LP returns and catches its bilateral relationship state up through the realized market history, the resulting authenticated owner state is a fresh baseline from which later composition may begin. A binding-final terminal owner close instead folds its terminal successor directly and ends further market composition for that DLV. An LP absent indefinitely may therefore leave an active DLV progressively more expensive to compose; this is a stated beta liveness/performance property, not hidden constant-time behavior. Requirement 6.3 (Catastrophic duplicate binding Finality). At one DLV parent there must be zero or one binding-final bundle. If a verifier establishes two distinct binding-final SettlementBundles consuming the same DLV parent, it must:
44. report STORAGE_SAFETY_VIOLATION;
45. quarantine that parent and every descendant whose validity depends upon either continuation;
46. refuse new market execution involving the affected lineage;
47. preserve both conflicting evidence objects; and
48. never select one continuation by hash order, route rank, arrival order, node order, or another tie-break. SoFi defines no automatic rollback because either continuation may already have been used as an input to later sovereign state. Deployment repair after this event is an explicit operator/recovery action outside ordinary settlement. 17 SoFi: Sovereign Deterministic Finance Revision 15 6.2 History-bound parent identity Definition 6.4 (Parent identity). The parent identity carried by every route allocation is the canonical commitment of the exact DLV state being consumed: cn = H(DSM/vault-state ∥CCB(Vn )). The former pv anchor tuple is DELETED, together with the DSM/vault-state-anchor/v2 domain. Both are burned and never reused. No implementation may accept, emit, or fall back to either. Rationale. pv committed a selected PROJECTION of Vn - the vault identifier, the generation, the parent state commitment hn , the reserves digest, the storage set and q. cn comm

Truncated - read the full file at https://github.com/deterministicstatemachine/dsm/blob/9d81b7a43253d935b50898d999116d737d620268/.github/instructions/sofispecs.instructions.md.