Operating doctrine
Plain-language rules for readers, builders, and auditors. This explains the shape of the system and the boundaries it tries to preserve.
Protocol boundary doctrine
Machine-facing constraints expressed publicly. These are not marketing slogans; they are the kinds of boundaries the runtime should enforce.
Treasury Law
Treasury custody is passive. Holding value is not permission to route it.
Routing Law
Value movement belongs in a designated routing surface with provenance preserved.
Action Discipline
If the facts do not justify action, the safe default is no action.
01 Passive custody
The treasury is a custody and accounting surface. It may expose admitted value, report state, and preserve principal boundaries. It should not become a router, policy engine, or trading desk.
custody is not control
02 Isolated routing
When value must move, the movement should pass through a clear routing layer. The routing layer carries source, reason, class, and destination context so value does not become ambiguous after it moves.
movement requires provenance
03 Audit without control
Audit is an observer. It should publish public summaries and status markers without becoming the thing that decides, routes, mints, burns, admits, or pays.
observation is not authority
04 Separate surfaces
Core, Bridge, Infra, and Liquid can coordinate, but they should not collapse into a single economic blob. Each page describes its own public role and what it must not claim.
- Core is the vault surface.
- Bridge is the boundary movement surface.
- Infra is the witness and memory surface.
- Liquid is the fast local-risk surface.
05 Public data boundary
The website should expose public condition, not private operating law. Public readers should be able to see whether the system is live, fresh, healthy, and coherent without seeing defensive thresholds or runtime tactics.
show condition, not the playbook