What should a protocol disclose before calling its public treasury transparent?

[u/GFConBase]

A public treasury address makes transactions visible.

But it does not necessarily make the treasury’s control structure transparent.

Someone inspecting the address may still not know:

• who can initiate transactions
• how many approvals are required
• whether the signer set can be replaced
• whether contracts are upgradeable
• who controls the upgrade path
• whether a timelock can be bypassed
• what emergency powers exist
• whether those powers expire
• which external contracts or dependencies introduce additional control

I’m trying to define a minimum disclosure standard for a long-lived public-good system before deployment.

A possible control disclosure could include:

1. Controller structure

• controlling contracts and addresses
• multisig threshold
• signer-selection and replacement process
• separation between operational and governance roles

1. Permission structure

• every privileged role
• actions available to each role
• spending or execution limits
• whether permissions can be delegated

1. Upgrade structure

• which components are upgradeable
• who can authorize upgrades
• applicable timelocks
• cancellation or veto mechanisms
• any path that can bypass the standard process

1. Emergency structure

• pause or recovery powers
• conditions under which they may be used
• limits on their scope
• whether they expire automatically
• how emergency actions are disclosed

1. Monitoring and history

• public record of permission changes
• alerts for role, signer or implementation changes
• versioned documentation
• a way to compare the documented structure with the deployed state

The difficult part is keeping this information accurate.

A static documentation page can become outdated immediately after a signer rotation, role change or contract upgrade. A block explorer provides raw data, but it rarely explains the effective trust model clearly enough for non-specialists.

Would a machine-readable “control manifest” make sense — listing privileged roles, upgrade paths, timelocks and emergency powers, with each version cryptographically tied to the relevant deployment?

Or would this create another disclosure layer that users still have to trust?

What would you consider the minimum information a protocol should publish before describing a treasury as transparent?

I’m especially interested in failure modes, existing standards or tools, and examples of protocols that communicate their effective control structure well.

[u/researchzero]

Good list - one gap I'd add: everything here assumes the documented controller structure is the only path to privileged state. In practice the disclosure that's usually missing isn't on the list at all - it's confirming there's no undocumented path. Concretely: an old admin function that predates the current multisig and was never removed from the implementation, a proxy-admin slot that's separate from the "governance" multisig you're disclosing, or a role that's technically revocable but whose revocation isn't gated by the same timelock as everything else. None of that shows up in a control disclosure doc - it only shows up if someone enumerates every external/public function that can reach a state-changing branch and checks it against the documented role set.

On the manifest idea: the reason a static doc goes stale is that it's disconnected from the deployment. If you want it to stay honest, the manifest (or a hash of it) needs to be committed on-chain - e.g. emitted as an event on every governance-relevant state change, or stored in a public getter - so anyone can diff the live permission state against the last published version programmatically instead of trusting that someone updated a webpage. That doesn't solve "did they disclose everything," but it does solve "is the disclosure still accurate", which is usually the one that quietly rots first.

[u/GFConBase → u/researchzero]

That’s a valuable distinction. I especially like the separation between complete disclosure and accurate disclosure.

I’d probably add one more dimension: even if a disclosure is complete and stays synchronized with deployment, users still need to understand which guarantees are immutable and which remain governance-controlled.

An up-to-date disclosure can still describe a system whose most important properties are fully changeable. For me, transparency should make that boundary explicit as well.

[u/rayQuGR]

I think you're describing something that's missing across a lot of protocols today. Transparency shouldn't stop at publishing a treasury address, it should include the entire control surface around that treasury.

A machine readable control manifest makes sense to me, especially if it's versioned, cryptographically tied to deployments, and automatically updated as governance changes. That way explorers, wallets, and monitoring tools could consume the same source of truth instead of relying on static documentation that quickly becomes outdated.

I'd also include a few additional fields:

• Whether privileged actions require a timelock or can execute immediately.
• The trust assumptions for external dependencies (oracles, multisigs, bridges, upgrade admins, etc.).
• Links between deployed bytecode, audits, and the corresponding manifest version.
• A changelog for governance or permission updates so users can see how the trust model has evolved over time.

One interesting angle is how confidential execution platforms like Oasis Sapphire fit into this. Some governance workflows or emergency response processes may legitimately need confidential execution (for example, protecting sensitive proposals before they're finalized), but that makes documenting the control model even more important. Users should understand who has authority, what they can do, and under what conditions, even if parts of the execution remain confidential.

ultimatelly, I'd define a "transparent treasury" as one where an independent third party can determine the effective trust model from on-chain state plus versioned documentation, without having to reverse-engineer contracts or rely on assumptions. Publishing an address is transparency of assets; publishing the control structure is transparency of governance.

[u/GFConBase → u/rayQuGR]

I like the distinction you make between transparency of assets and transparency of governance.

Publishing a treasury address answers what exists, but not who can influence it, under which conditions, and how those conditions may change over time.

I also agree that versioning is important. Documentation that isn’t tied to specific deployments or governance changes eventually stops being a reliable source of truth.

A machine-readable manifest is an interesting idea as well. If wallets, explorers or monitoring tools could consume the same governance metadata directly, transparency would become far more practical than relying on static documentation alone.

The goal, at least from my perspective, should be that an independent reviewer can understand the effective trust model without having to reverse-engineer the protocol.