Whitepaper / Network and Trust

Governance and Upgrades

Governance, in this design, is how system-wide rules would change and who could exercise admin authority. It is not how one delivery gets judged. That stays in Challenges and Disputes. Ghast Protocol is in development: there is no mainnet, no vote, and no admin key to inspect. This chapter limits what a future rule change could touch, including a purchase that has already been made. It is not a launch plan, and it is not an offer of $GHAST.

Decision scope

Governance covers:

• Capability eligibility and claim standards;
• evidence and Verification requirements;
• Challenge, Settlement, bond, slash, burn, and reward parameters;
• protocol fees and ecosystem programs;
• Resolver and appeal frameworks; and
• upgrades, pauses, and emergency procedures.

The list is system-wide on purpose. A standard for what counts as a testable claim applies to every Capability. A parameter for the Challenge Bond applies to the dispute process, not to one Creator’s private workflow. Protocol fees and ecosystem programs are about the rails, not about the price a Creator sets on one service. Payments and Fees describes how buyer payment and proposed token roles stay apart. Governance might change a protocol fee parameter. It does not, by that act, become the seller of the service.

Resolver and appeal frameworks belong here because they are the structure of review, not the outcome of one dispute. Who may serve as a Resolver, how conflicts are handled, and how an appeal is shaped are system rules. Whether a particular delivery met its claim is an evidence question. That question stays in Challenges and Disputes, judged against the Defined Claim and the Delivery Evidence. Moving it into governance would let a rule change replace the record. The design does not do that.

Parameters and framework details are published before mainnet. “Before mainnet” means they are not in force, because there is no mainnet. This sentence is not a date. It does not say that publication has happened, and it does not invite anyone to fund a treasury. Token Allocation names a proposed protocol treasury as a share of a proposed supply. It is not a live balance under this chapter’s control.

Upgrades, pauses, and emergency procedures are on the list because a system that can hold funds or halt settlement has to say who may pull those levers. They are also the powers most likely to be abused if they are unnamed. The deployment section below is the constraint on those powers. Naming them is not the same as granting them to an anonymous operator.

Non-retroactivity

A purchase remains governed by the Capability version and the protocol rules in effect when it was made. Material Capability changes require a new version. Protocol changes receive a clear activation point and do not rewrite resolved transactions.

This is the same idea as versioned provenance, applied to the rules rather than to the claim text. Identity and Provenance binds a purchase to the claim version the buyer selected. Governance binds that purchase to the protocol rules then in effect. A later tightening of evidence standards can apply to later publications. It cannot reach back and fail a delivery that already resolved under the old standard. A later change to a bond parameter cannot reopen a slash that has already been applied, or invent a slash that the old rules did not allow.

Open transactions follow the migration or exception rules attached to the governing upgrade. The design does not pretend that every open purchase can ignore a safety fix. It requires the upgrade to state the migration. A silent change to an open settlement is not a migration rule. It is a rewrite, and the non-retroactivity rule forbids it. Resolved transactions are easier: they stay resolved. Capability Lifecycle is what “resolved” refers to. History in Reputation and Delivery History keeps the outcome that actually happened, including the rules it happened under.

Claim edits are not governance. A Creator who wants a stricter promise publishes a new Capability version. Buyers of the old version remain on the old promise. Treating a Creator’s edit as a protocol upgrade would confuse a private commercial change with a system rule. The chapters stay separate so that confusion has a place to be corrected.

Deployment requirements

Any component that can hold funds, change finality, select a Resolver, pause activity, or upgrade protocol logic must identify its controlling authority, its approval path, its key security model, and its emergency powers. Administrative actions follow least privilege and multi-party approval where the risk requires it, with durable records of changes and emergency intervention.

“Must identify” is a requirement on the design of those components, not a statement that the identifiers have been published. Security and Risk already lists contract and custody failure as a risk the protocol does not eliminate. Governance reduces the chance that those powers are invisible. It does not reduce the chance to zero. A durable record of an emergency pause is how later readers, and later buyers, can see that finality was interrupted and under which authority. It is the governance twin of the history rule that summaries must show their basis.

Least privilege means a key that can pause settlement is not also the key that rewrites a Creator’s claim, and a key that selects a Resolver is not also a quiet path around the conflict rules. Multi-party approval applies where the risk requires it. The chapter does not pick a number of signers. Inventing a threshold would be a false precision. The requirement is that the approval path exists and is identified before the component can do those things.

Workbench releases are not protocol upgrades. A new desktop version can change Chat, Coding, or Team behavior. It does not change Protocol rules, because Protocol is not live and a desktop changelog is not a governance action. Readers who want product changes should use the changelog. Readers who want the commercial design should stay in this book and remember the status on the whitepaper overview: Workbench is live, Protocol is in development.