Governance switches and risks

Owner-controlled parameters

Several of the mechanics described elsewhere in this section are owner-adjustable, not fixed at deploy time. Confirmed owner-gated setters include the tax hook's override flag and rate (see Trading tax hook), and the POL Manager's TWAP-deviation bound and burn-vs-transfer setting for collected fees (see Reserves, vaults, POL, and buybacks). GET /v1/governance/changes is the single route that surfaces this category of risk across the whole protocol: param-change history, anything queued but not yet applied, one-way switch states, and guardian pause state, all in one call.

One-way switches

Some parameters can only move in one direction once set. One example is whichever flag disables the launch-tax schedule outright rather than letting it be re-enabled. GET /v1/governance/changes reports the state of these switches explicitly, since a one-way change that already happened is a materially different risk from a two-way parameter that could be flipped back.

The address registry: who's allowed to point where

An AddressRegistry contract is the book every other Standard Reserve contract resolves the others' roles through (centralBank, taxHook, feeSplitter, contractionVault, expansionVault, polManager, genesisMinter, charterAuction, licenseAuction, plus the guardian, executor, and netFlowSource roles), keyed by name rather than by position. Two mechanisms govern how much that book can change after the fact:

• lock(key) is per-key and one-way. The owner can freeze any individual key's binding permanently; migration for that role then requires deploying a new contract entirely, not just re-pointing the registry. TAX_HOOK is the only key that is locked; every other key remains re-pointable by the owner.
• executionPermissionless is a single one-way switch for the whole registry, flipped by openExecution() and never reversible. It governs who may crank a buyback tick or a POL-pairing swap: while it reads false, only the registry's executor address may do either; once opened, anyone can. It does not affect ExpansionVault reserve purchases, which stay owner-only regardless. executionPermissionless reads false, so buyback ticks and POL pairing are restricted to the named executor.

GET /v1/governance/changes surfaces both of these under a registry object: execution_permissionless (with basis: measured), the per-key locked map, and the current executor and guardian addresses. GET /v1/buybacks/readiness reports the same executionPermissionless read as its permissionless field, with permissionless_source naming exactly which registry call produced it.

Guardian pause

A guardian role can pause protocol operation. GET /v1/governance/changes reports whether that pause is currently active. A caller building anything automated against this API (an exit bot, a license-buying script, anything that reacts to a quote) should check this before assuming a route's absence of an error means the protocol is operating normally. A paused protocol may still answer read routes while write paths are blocked at the contract level.

What's confirmed vs. genuinely unresolved

This is the honest-accounting section: several mechanics load-bearing enough to affect a real financial decision are not fully pinned down, and presenting them as settled would be worse than saying so plainly.

• The policy multiplier's first-settlement exemption. The rule (no cut fires at the bank's very first epoch settlement, regardless of signal) is pinned by fork execution of the real bytecode. Why the exemption exists in the contract's design is not visible from that method: the relevant code branch's body wasn't recoverable by static decompilation. Plausible explanations (e.g. requiring a full prior epoch before judging) are not confirmed.
• No mainnet epoch had settled as of the most recent bytecode analysis behind this documentation. Every policy-multiplier and step-rule conclusion above was validated by running the deployed contract against chosen inputs on a fork, which is the strongest evidence available without verified source. It hasn't yet been checked against a real, naturally-occurring EpochSettled event. Treat GET /v1/policy/outlook's projections as resting on a not-yet-confirmed rule until the first live settlement.
• The 70/15/15 regime-based ETH split described in the whitepaper is unverified against the deployed Central Bank contract. Its internal fee-routing logic isn't available to read, verified or otherwise.
• The contraction vault's rate-limit path (a supply-controller cap on how fast a contraction tick can burn) has an address configured to the zero address on mainnet. That limiting path has never actually been exercised, so its behavior if a supply controller were ever set is untested.
• Several POL Manager event and function names are inferred, not hash-confirmed. See Contracts and addresses. A descriptive name attached to an unconfirmed selector is a best guess at intent, not a confirmed account of what the function does.
• Which side pays the underlying Uniswap LP fee on a swap (separate from the tax hook's own tax) is still not established. The rate is known and reported live (lp_fee_bps on GET /v1/pool, cached from tsr.constants:pool_lp_fee_ppm, currently a static 1%), see Reserves, vaults, POL, and buybacks, but which party actually bears that fee on a given swap is called out as unresolved in docs/tsr/BYTECODE_SEMANTICS_2026-09-15.md in sre-services and hasn't been investigated further since. Don't read the rate being known as the payer question also being settled.

None of the above is flagged to suggest the protocol is broken. It's flagged because "inferred from the deployed bytecode by a careful third party" and "confirmed by the protocol's own verified source" are different strengths of claim, and this API's basis field exists precisely so a caller can tell which one they're looking at rather than have it presented as uniform certainty.

Where to look

Question	Route	MCP tool
What governance changes have happened, are queued, or are one-way?	GET /v1/governance/changes	1s_std_governance_changes
Is the guardian pause active right now?	GET /v1/governance/changes	1s_std_governance_changes
Is buyback/POL execution open to the public yet, and who's the executor/guardian?	GET /v1/governance/changes, GET /v1/buybacks/readiness	1s_std_governance_changes, 1s_std_buyback_readiness