Governance and parameter authority

No governance mechanism exists today. Not a weak one — none. There is no token vote, no multisig, no timelock, no admin role, and no documented change process anywhere in the contracts or the design.

That is worth stating in the first line because the product is defined by parameters that can change, and a reader could reasonably assume something constrains them. Nothing does.

The parameter register

Every value below changes what a holder receives or what risk they bear. The third column is the honest state, not the intended one.

Parameter	Current value	Who can change it today
Pass-through to sdrUSD	12.0% → 9.5% → 7.5% by reserve band	The issuer, unilaterally, off-chain
Protocol retained margin	0% → 2.5% → 4.5%	The same decision, inverted
Redemption queue length	30 days	The issuer; `cycleSeconds` is immutable in the deployed contract, so changing it means redeploying
Advance rate against collateral	7,500 bps at the optimum; well-formedness permits up to 9,000	The issuer, per facility
Liquidity buffer	2,500 bps	The issuer
Eligibility criteria for a facility	the four-part reserve test	The issuer
Concentration limits	none defined	—
Which facility the vehicle acquires	one at launch	The issuer
Contract logic	as deployed	Nobody — the contracts are non-upgradeable
`mint`, `accrue`, `absorbLoss`, `settle`	—	Anyone. There is no access control

The last row is not a governance gap; it is a security gap, and it is documented on the contracts page. It is listed here because from a holder's perspective the two are the same question: who can change my position, and what stops them?

The three decisions that have not been made

Who holds parameter authority. A named entity, a multisig, or a board. Today the answer is "the issuer, informally".

How a change is announced and when it takes effect. A pass-through step-down is an economic change to every holder's return. There is no notice period, no publication requirement, and no holder right attached to it.

Whether the contracts are upgradeable. They currently are not, by omission rather than by choice. Both paths are defensible — upgradeable behind a timelock with a named authority, or immutable with a published migration plan — and neither has been chosen. See contracts.

What a holder can rely on instead, today

Not nothing, but much less than governance would provide. Three things are genuinely binding without anyone's cooperation:

Contract logic is fixed. No proxy, no upgrade path, three immutable constructor bindings. Whatever the deployed code does, it will keep doing.

The regulatory obligations are external. COBS 19A duties — full backing at all times, daily valuation, monthly attestation, annual audit, holders first at par in liquidation — are owed to the regulator, not granted by the issuer, and cannot be amended by it. That is the strongest constraint currently in the structure, and it is why the legal route matters more than it might appear.

Loss absorption order is structural. The waterfall pays holders first, capped at par, and the routing that puts the yield leg ahead of the protocol is implemented rather than promised.

What would have to exist before this is investable at scale

An honest checklist, in the order it should be built:

A named parameter authority, with its powers enumerated.
A change process: notice period, publication, and what a holder may do in response — at minimum, redeem before it takes effect.
A concentration policy, capping any one obligor, commodity and jurisdiction.
Access control on every state-changing function, and removal of the bare accrue path.
An explicit upgradeability decision, with a timelock if upgradeable.
A conflicts policy — the protocol both originates the facilities and sets the pass-through, and the simulation shows one case where its own revenue line and the holder's interest point in opposite directions.

Item 6 is the one most easily overlooked and the one this project has already proved is real, rather than hypothetical.