Operations and governance
A system correct on paper still fails if it is run on impulse. This page covers two things that belong together: operational discipline — what must be green before anything is called done — and governance — who decides what, who holds the keys, and how the promise to withdraw is measured.
Operational discipline
The standard acceptance test
The five steps below are what proves the platform works. They can be re-run and give the same result.
Figure 19 — The blocked step must appear in the log too, otherwise the blocking is invisible.
The interoperability acceptance test adds three more steps: open a channel to a manually approved counterparty; send assets to an approved address and receive them; send to an unapproved address and watch the funds return to source rather than get stuck.
Four gates before anything is called done
| Gate | Content |
|---|---|
| 1 | Actually runs, verified end to end |
| 2 | Tests pass and the build is clean |
| 3 | Touching a live system requires a real person's approval |
| 4 | The status document is updated |
Two disciplines
Rehearse first, never perform live on the first take. The path to a network's birth is rehearsed on the real infrastructure: torn down and rebuilt from scratch, repeatedly, each time running the full set of gates. On the real day, the script has been run smoothly rather than improvised at midnight.
A red gate moves the date; nothing is hot-patched. If any gate is red: stop, preserve the scene, move the date to the 9th of the following month, and publish the reason. A date that can be moved publicly is a date that means something. A date that must be held at all costs is a date that invites hot-patching, and a hot-patched genesis cannot be undone.
In short: "it works" is not a feeling, it is a list of steps that can be re-run and give the same result.
Governance and who holds the keys
| Level | Who decides | By what means |
|---|---|---|
| Customer chain | Customer and platform, per contract | On-chain roles and the service agreement |
| Platform parameters | On-chain governance | Proposal and vote |
| LOVE9 economics | The community | Public on-chain vote |
The direction of a change decides the authority
This detail blocks a common kind of overreach. For protective parameters, what decides who may change them is not their importance but the direction of the change.
| Kind of change | Example | Who may do it |
|---|---|---|
| Weakens the system | Disabling anti-abuse, loosening limits, adding an exempt role | On-chain governance only |
| Strengthens the system | Enabling for the first time, tightening further | An administrator may act immediately |
This split avoids both extremes: forcing every change through a vote leaves the system unable to patch itself in an emergency, while giving administrators full authority means the door opens on a single decision.
Who holds the keys
Three separate signing groups, held by three different sets of people.
Figure 20 — Whoever approves compliance must not be whoever administers the system.
The invariant principle: one signature is never enough, and those two roles must sit with two different sets of people. If the same person both grants an address its permission and runs the system recording that permission, separation of duties is a formality.
Two things here are easily read as one, and this document separates them. The mechanism is enforced: without the signatures a transaction is rejected. But a period's genesis actually placing the two roles at two different addresses has not happened yet — in the running period both sit at one address, and you can read that in the genesis file. The actual key ceremony — each key share generated on and staying inside a different person's own device, rather than test keys generated in a single build — is a mandatory gate before the network holds real assets. A correct mechanism without the ceremony means three groups are still only three addresses.
The commitment to remove the scaffolding
The company and organisation behind this are scaffolding. The removal schedule is counted publicly on chain, until the network needs nobody to operate it. This commitment is verifiable because it is measured by something countable: how many tasks still require an administrative key.
But the unflattering part must be said in full: until the scaffolding is gone, the three key groups above are held by people the project appointed, not people the community elected — and voting power is still concentrated there too. Splitting authority across three groups stops one person deciding alone; it does not make governance the community's. That is exactly why Before you read makes distributing voting power a gate that stands before any ratification of anything permanent.
In short: good governance is not everyone voting on everything, it is the right decision in the right hands, and anyone being able to check that.