Ideas: Future Directions

The Ideas section collects design directions that go beyond the funded roadmap. Unlike the milestones, they have no dates, budgets or acceptance obligations. They are published so that reviewers can see where the architecture leads after the funded program ends, and so that the reasoning can be examined and corrected while correction is still cheap. The first direction documented here is the bidirectional MAST engine, which would let escrow be released by satisfying committed constraints rather than by executing a committed program.

Purpose

Finished documentation describes what exists, and the funded roadmap describes what is committed. This section covers the ground in between: reasoning developed enough to inspect, provisional enough to revise, and worth sharing before any commitment is made. Grant reviewers routinely ask where an architecture leads past its final milestone, and these pages answer that question openly.

Writing designs for publication also improves them. Reasoning written to be inspected has to state its assumptions, enumerate its threats instead of deferring them to implementation, and separate decided mechanics from open parameters, so a design that survives this process reaches implementation review already hardened.

Structure and status labels

Each direction begins with a design page that states the mechanism completely. Pages on authentication and security follow wherever credentials or new attack surfaces appear, and a build plan closes the direction with phases, tooling and the shape of its acceptance. Cross-references tie every claim to the mechanism pages it extends.

Every direction carries one of four status labels with fixed meanings: design direction (active reasoning, no commitment), under evaluation (open parameters awaiting decision), adopted (moved into the funded roadmap with milestones) or superseded (replaced, with the reasoning kept alongside its replacement).

The bidirectional MAST engine

Today’s lock-scripts release escrow by executing a committed program. The proposed mirror image would release escrow when a Zcash transaction satisfies committed constraints, verified without running any virtual machine. The direction is documented in four pages:

• The Bidirectional MAST Engine: the core design and the six-gate claim sequence;
• Ticket Authentication: how claims are bound to authorized parties, from minting tickets through carrying them to recovering them;
• Security Analysis: frontrunning, replay, malleability, key compromise and the other threats;
• Build Plan: phases, tooling and acceptance, should the direction be adopted.

It was chosen as the first direction for three reasons: it reuses patterns already proven in the codebase, which bounds implementation risk; it enables bounty-style locks that the current design can’t express; and its threat model can be analyzed completely in advance, which makes it a good test of whether this section’s process works.

Adoption

No direction in this section consumes resources without an explicit adoption decision recording its scope, budget and acceptance criteria. An adoption proposal would treat these pages as the design baseline and list any deviations, so reviewers could compare what was built against what was designed instead of reconstructing intent from code. Adopted directions would become new milestones with the usual budget, timeline and acceptance treatment.

The design record is kept whatever the outcome. Adopted directions keep their pages, with status updated and deviations noted; superseded directions keep theirs, with pointers to the replacement; nothing is deleted, because the trail of reasoning matters as much as where it leads. Until a direction is adopted, these pages are the complete position on it: interested, specific and uncommitted.