Build Plan
This build plan sketches how the bidirectional MAST engine would move from design to implementation if it were adopted. The phases are ordered by dependency, tooling is built alongside the contracts, and acceptance at every step is something a reviewer can operate directly. The direction is outside all funded milestones: no phase has dates or a budget, and the plan exists so that any future adoption starts from reviewed design rather than a blank page.
Phase 0: specification freeze
Implementation starts from a frozen specification rather than from code. Four things are fixed: the byte-exact memo layout for tickets, including the boundary with application content; the range of the start index and its validation against the 512-byte memo; the semantics of the per-leaf single-use flag, including the format of the spent-ticket key; and the MAST depth for version one, whether a single constraint or several leaves, with the upgrade path to the other.
Each frozen item gets conformance vectors, concrete byte strings with the expected accept or revert outcome, written before implementation so that builders test against the specification rather than against each other. The phase is complete when two independent readers implement the checking pseudocode identically from the text alone, a test that sounds modest and turns out to be stringent.
Phase 1: consensus contracts
The contracts add a parallel claim entry that reuses proven patterns. The request flag extends the blob following the existing convention for sibling flags, keeping the layout change small, and the MAST root is stored following the pattern used for the retained ciphertext head, which reviewers already understand.
The claim entry performs seven operations in a fixed order: inclusion, leaf membership, field constraints, commitment binding, ticket recovery, nullifier marking and disbursal. Each failure has its own error, so tests can target exact revert points.
The test matrix from design review becomes the test suite:
- honest claims settle with exact payouts;
- claims with a wrong field revert, distinguishing
pk_d,g_dand value failures; - invalid tickets revert at recovery, and out-of-range recovery identifiers at the boundary;
- double claims on the same action revert through nullifier marking;
- reusing a ticket across actions passes or fails according to the leaf’s single-use flag;
- multi-leaf locks settle exactly one revealed branch and leave the others hidden;
- start-index violations revert at the range check.
Wherever state is shared, each case runs against both claim directions.
Phase 2: tooling
Tooling is built in parallel so that tests exercise real binaries rather than fixtures. The ticket minter signs leaf constants with fresh randomness for each ticket, emits the family in the handoff format and refuses to reuse randomness, since nonce discipline can’t depend on an operator’s memory. The memo embedder places ticket bytes at the specified index, and the payment builder targets the exact recipients and values in a lock’s terms without manual field assembly.
The relayer gets full support rather than just documentation: the payer-to-relayer handoff carries the action reference, the ticket and the start index, private transport is the default, and public submission remains an explicit override for low-threat settings. The fill tooling records the encryption randomness and openings automatically, since reconstructing them after broadcast is forensic work that good defaults should prevent.
Phase 3: audit and testnet program
The audit covers the claim entry and its six gates, the ticket verification path, the interaction between the two directions through the nullifier set, and the MAST membership code. Auditors walk through the security analysis against the implementation line by line, covering frontrunning, replay, malleability and key compromise. Any gap between this design and the code counts as a finding whether or not it is exploitable, because undocumented divergence is itself a class of vulnerability.
On testnet, claims are manufactured across every dimension of the matrix: honest and dishonest tickets, exact and inexact fields, single- and multi-leaf locks, fresh and stale anchors, and cooperative and adversarial mempools. Frontrunning drills run scripted bots against honest claimants over both public and private relay, and replay drills attempt reuse against the same and different actions. The program passes when every outcome matches a prediction recorded before the drills began, so hindsight can’t grade the exercise.
Phase 4: documentation
The documentation would extend the lock-scripts page with the inverted direction, add glossary entries for the new terms, and place the direction on the roadmap once its scope is decided: next to the programmability milestones if framed as settlement power, or as an item of its own if framed as a liquidity primitive. The pages in this section would remain as design history, with their status updated to adopted or superseded, so the reasoning from idea to implementation stays inspectable.
Acceptance
Acceptance in every phase is reviewer-operable. A reviewer builds a qualifying payment with the documented tooling, watches a ticket being minted and handed off, submits through the relayer and sees settlement confirm, then attempts each attack in the matrix and sees it revert. Demonstration videos, proxy metrics and operation by developers alone are not accepted as substitutes.