|
| 1 | +# Bitcode Spec V30 Delta |
| 2 | + |
| 3 | +## Status |
| 4 | + |
| 5 | +- Version: `V30` |
| 6 | +- V30 state: draft target delta opened for Protocol/BTD hardening |
| 7 | +- Current canonical/latest target: `V29` |
| 8 | +- Prior canonical anchor: `BITCODE_SPEC_V29.md` |
| 9 | +- Prior generated proof appendix: `BITCODE_SPEC_V29_PROVEN.md` |
| 10 | +- Generated structured artifact inventory: none for V30 yet; draft gates must create V30 reports and generated proof only as acceptance evidence |
| 11 | +- Source parity state: V30 source parity is draft-opened for Protocol/BTD package APIs, Bitcoin/Taproot/PSBT rigor, BTD receipts, testnet ledger projection, source-to-shares proof cleanup, bridge-readiness boundaries, telemetry hooks, and promotion automation |
| 12 | +- State: draft target delta opened |
| 13 | +- Active canonical pointer during draft opening: `BITCODE_SPEC.txt` -> `V29` |
| 14 | +- Scope: V30 draft delta for Protocol/BTD hardening over promoted V29 |
| 15 | +- Spec companion: `BITCODE_SPEC_V30.md` |
| 16 | +- Notes companion: `BITCODE_SPEC_V30_NOTES.md` |
| 17 | +- Parity companion: `BITCODE_SPEC_V30_PARITY_MATRIX.md` |
| 18 | +- Generated proof appendix: none until V30 promotion |
| 19 | + |
| 20 | +## Why V30 exists |
| 21 | + |
| 22 | +V29 canonically promoted Terminal transaction depth over the commercial Reading system. |
| 23 | +It made the operator cockpit more navigable, recoverable, source-safe, repairable, and promotion-proven. |
| 24 | + |
| 25 | +V30 exists because the protocol rails beneath that cockpit now need commercial hardening before Bitcode can responsibly expand into Auxillaries depth, proof depth, interface depth, deployment depth, documentation depth, Exchange, and Conversations. |
| 26 | +The focus is not a new product surface. |
| 27 | +The focus is making Protocol/BTD packages, Bitcoin/Taproot/PSBT flow, BTD receipts, ledger/database/object-storage projections, source-to-shares proofs, and bridge-readiness boundaries stable enough for enterprise shippability. |
| 28 | + |
| 29 | +## Accepted V30 decisions |
| 30 | + |
| 31 | +- V29 remains active canon during V30 drafting. |
| 32 | +- V30 gate branches are opened from `version/v30` and merged back only when their gate acceptance criteria are closed. |
| 33 | +- V30 owns Protocol/BTD hardening, not another Terminal redesign. |
| 34 | +- V30 preserves the V29 Reading journey: request Read, review synthesized Need, request Finding Fits, review source-safe AssetPack preview, buy/settle, and receive paid delivery. |
| 35 | +- V30 narrows shared package APIs before they become Exchange, Auxillaries, interface, deployment, or documentation dependencies. |
| 36 | +- V30 makes Bitcoin fee, Taproot, PSBT, signer, broadcast, replacement, reorg, blocked-readiness, and finality semantics typed and testable. |
| 37 | +- V30 binds BTD-AssetPack mint/read/right-transfer receipts to source-safe preview, paid unlock, delivery, and reconciliation. |
| 38 | +- V30 cleans source-to-shares contribution accounting, settlement conservation, zero-cell/refit tail posture, and no-overpayment/no-underpayment proof surfaces. |
| 39 | +- V30 records bridge-readiness research without treating any bridge as current `$BTD` chain-of-record truth. |
| 40 | +- V30 workflows and scripts must validate V29 active / V30 draft posture. |
| 41 | + |
| 42 | +## Explicitly deferred |
| 43 | + |
| 44 | +- V31 Auxillaries depth remains V31. |
| 45 | +- V32 proof-family/provation expansion remains V32. |
| 46 | +- V33 interface/MCP/ChatGPT/API depth remains V33 except for Protocol/BTD hooks needed by V30. |
| 47 | +- V34 deployment/runtime/storage depth remains V34 except for host-capability facts needed by V30. |
| 48 | +- V35 telemetry/documentation depth remains V35 except for Protocol/BTD telemetry hooks needed by V30. |
| 49 | +- Exchange product/market depth remains beyond V35. |
| 50 | +- Website Conversations product depth remains beyond V35. |
| 51 | +- New `$BTD` supply law remains out of scope. |
| 52 | +- Value-bearing mainnet launch remains separately approval-gated. |
| 53 | +- Bridge integrations remain research posture, not chain-of-record implementation. |
| 54 | + |
| 55 | +## Pre-Implementation Sequence |
| 56 | + |
| 57 | +1. Open `version/v30` from promoted `main`. |
| 58 | +2. Open `v30/gate-1-roadmap-and-gating` from `version/v30`. |
| 59 | +3. Create the V30 SPEC, DELTA, NOTES, and PARITY family while preserving `BITCODE_SPEC.txt -> V29`. |
| 60 | +4. Refresh `SPECIFICATIONS_ROADMAP.md` so V29 is active canon, V30 is draft target, and V31-V37 scopes remain coherent after recent V28/V29 work. |
| 61 | +5. Retarget gate-quality and canon-quality workflow posture checks to V29 active / V30 draft. |
| 62 | +6. Add `check:v30-gate1` and a V30 Gate 1 checker. |
| 63 | +7. Define V30 gates, acceptance criteria, carryforward parity rows, and post-V30 roadmap responsibilities. |
| 64 | +8. Validate spec family, canonical inputs, canon posture, workflows, roadmap truth, README/docs, and diff hygiene. |
| 65 | +9. Push the gate branch and open a pull request to `version/v30`. |
| 66 | + |
| 67 | +## Commit-Body Direction |
| 68 | + |
| 69 | +V30 gate commit bodies should describe the closed gate, specification changes, implementation surfaces, tests, proof commands, and accepted boundaries. |
| 70 | +The eventual V30 promotion commit body must name all closed V30 gates, generated proof artifacts, Protocol/BTD hardening surfaces, and the `BITCODE_SPEC.txt` pointer change from `V29` to `V30`. |
| 71 | +It must explicitly defer V31+ scopes, Exchange, Conversations, bridge chain-of-record implementation, and value-bearing mainnet launch. |
| 72 | + |
| 73 | +## Gate Delta |
| 74 | + |
| 75 | +### Gate 1: V30 Roadmap And Gating |
| 76 | + |
| 77 | +Gate 1 opens V30 correctly: |
| 78 | + |
| 79 | +- V30 SPEC, DELTA, NOTES, and PARITY files exist. |
| 80 | +- `BITCODE_SPEC.txt` remains `V29`. |
| 81 | +- README, roadmap, PR template, and workflows describe V29 active / V30 draft posture. |
| 82 | +- `check:v30-gate1` validates branch naming, spec family, notes, parity, roadmap truth, workflow posture, and promotion boundaries. |
| 83 | +- The V30 gate list is explicit before product implementation begins. |
| 84 | + |
| 85 | +### Gate 2: Protocol Package API Boundaries |
| 86 | + |
| 87 | +Gate 2 narrows the commercial Protocol/BTD package API surface. |
| 88 | + |
| 89 | +Closure acceptance: |
| 90 | + |
| 91 | +- shared Protocol/BTD objects used by multiple interfaces have package-owned builders, parsers, validators, tests, and JSON-safe serialization; |
| 92 | +- route code delegates policy and receipt derivation to packages rather than duplicating it; |
| 93 | +- no commercial runtime code imports `protocol-demonstration/src/*`; |
| 94 | +- package READMEs name ownership boundaries and accepted imports. |
| 95 | + |
| 96 | +### Gate 3: Bitcoin Taproot PSBT Fee Rigor |
| 97 | + |
| 98 | +Gate 3 hardens Bitcoin fee and signer semantics. |
| 99 | + |
| 100 | +Closure acceptance: |
| 101 | + |
| 102 | +- BTC fee quote, signer recovery, PSBT handoff, Taproot/script posture, broadcast, replacement, reorg, and finality states are typed; |
| 103 | +- server-custody rejection remains explicit; |
| 104 | +- testnet/mainnet distinction is policy-enforced and proof-rooted; |
| 105 | +- focused BTD/API tests prove fee lifecycle and blocked-readiness behavior. |
| 106 | + |
| 107 | +### Gate 4: BTD AssetPack Mint And Read Receipts |
| 108 | + |
| 109 | +Gate 4 creates typed BTD receipt boundaries. |
| 110 | + |
| 111 | +Closure acceptance: |
| 112 | + |
| 113 | +- `BtdAssetPackMintReceipt`, `BtdReadReceipt`, and `BtdRightsTransferReceipt` are package-owned; |
| 114 | +- receipts bind AssetPack ids, BTD ranges, Reader/Depositor identities, source-safe preview roots, paid unlock, delivery admission, and ledger projection roots; |
| 115 | +- protected source remains hidden before settlement; |
| 116 | +- receipts are stored, streamed, and rendered through existing execution and Terminal surfaces. |
| 117 | + |
| 118 | +### Gate 5: Testnet Ledger Projection Hardening |
| 119 | + |
| 120 | +Gate 5 hardens ledger/database/object-storage projection and repair. |
| 121 | + |
| 122 | +Closure acceptance: |
| 123 | + |
| 124 | +- ledger-observed facts, database projections, object-storage artifacts, and private metaphysical facts remain distinct; |
| 125 | +- projection repair classes and proof roots are deterministic; |
| 126 | +- Supabase staging-testnet readback can prove synchronized or blocked state without secrets in tracked files; |
| 127 | +- reconciliation tests cover drift, quarantine, retry, and unlock blocking. |
| 128 | + |
| 129 | +### Gate 6: Source-To-Shares Proof Cleanup |
| 130 | + |
| 131 | +Gate 6 cleans contribution measurement and settlement conservation. |
| 132 | + |
| 133 | +Closure acceptance: |
| 134 | + |
| 135 | +- source-to-shares proof surfaces bind measurements, fit deposits, range slices, fee quote, contribution weights, settlement conservation, zero-cell/refit tail posture, and ancestry evidence where available; |
| 136 | +- no-overpayment and no-underpayment invariants are testable; |
| 137 | +- later Exchange work can reuse the proof without reinterpreting V30 accounting. |
| 138 | + |
| 139 | +### Gate 7: Bridge Readiness Research Boundaries |
| 140 | + |
| 141 | +Gate 7 records bridge-readiness without false chain-of-record claims. |
| 142 | + |
| 143 | +Closure acceptance: |
| 144 | + |
| 145 | +- Taproot, BitVM, BSC/opBNB, Binance Web3 Wallet, and future distribution paths have research posture records; |
| 146 | +- each record names feasibility, risks, current non-admission, rereview triggers, and required proof before admission; |
| 147 | +- no bridge path is treated as current `$BTD` chain-of-record truth. |
| 148 | + |
| 149 | +### Gate 8: Protocol Telemetry And Proof Hooks |
| 150 | + |
| 151 | +Gate 8 adds Protocol/BTD telemetry and proof hooks. |
| 152 | + |
| 153 | +Closure acceptance: |
| 154 | + |
| 155 | +- BTD receipts, BTC fee states, ledger projection, source-to-shares proofs, and bridge-readiness posture emit typed telemetry; |
| 156 | +- telemetry avoids protected source and secrets; |
| 157 | +- proof hooks are compatible with V32 provation and V35 documentation/observability work. |
| 158 | + |
| 159 | +### Gate 9: Interface Integration And Regression Proof |
| 160 | + |
| 161 | +Gate 9 proves existing interfaces can consume the hardened Protocol/BTD rails. |
| 162 | + |
| 163 | +Closure acceptance: |
| 164 | + |
| 165 | +- Terminal, API, MCP, ChatGPT App, and future Auxillaries/Exchange hooks consume package-owned objects without route-local reinvention; |
| 166 | +- low-detail source-safe UX remains intact; |
| 167 | +- focused regression tests prove no V29 transaction cockpit behavior regresses. |
| 168 | + |
| 169 | +### Gate 10: V30 Promotion Readiness |
| 170 | + |
| 171 | +Gate 10 owns final local/staging proof, generated artifacts, and V30 promotion workflow support. |
| 172 | + |
| 173 | +Closure acceptance: |
| 174 | + |
| 175 | +- `check:v30-gate10` validates promoted-readiness posture; |
| 176 | +- V30 promotion workflow validates source branch, local proof commands, staging-testnet readback evidence, generated `.bitcode/v30-*` reports, and `BITCODE_SPEC_V30_PROVEN.md`; |
| 177 | +- promotion scripts support V30 and rewrite post-promotion active V30 / draft V31 posture; |
| 178 | +- `version/v30` can be requested into `main` only after all V30 gates close. |
0 commit comments