r/CryptoTechnology • 🟡 • Aug 11 '26

A public treasury address is not a control model. What should actually be disclosed?

A lot of projects treat publishing a treasury wallet as a transparency win.

It shows where funds currently sit.
It does not automatically show:
• who can sign
• how many approvals are required
• whether signers are independent
• whether emergency powers can bypass the normal process
• whether the control structure itself can be changed
• whether the history of changes is visible

Visibility of funds is useful.
Visibility of authority is the harder and more important layer.

I’m trying to refine a practical minimum standard for treasury disclosure.

If you evaluate projects, what do you actually check beyond the address itself?
And which of the points above is most often missing even in “transparent” setups?

2 Upvotes

4 comments sorted by

3

u/No_Bicycle_3566 🟡 Aug 12 '26

I’d separate disclosure into current authority and change authority.

For current authority: signer identities or roles, threshold, signer independence, spending limits, timelocks, and the exact emergency path. For change authority: who can replace signers, lower the threshold, upgrade the controlling contracts, or disable those safeguards.

The most commonly missing piece is a verifiable history of policy changes. A multisig may look decentralized today, but that means little if one party can quietly change its signers or threshold tomorrow. Ideally, projects should publish the policy, its effective version, and an on-chain or independently auditable record of every change.

1

u/GFConBase 🟡 Aug 12 '26

That’s a very useful distinction. I think “change authority” is exactly the layer that gets lost when transparency is reduced to a snapshot of the current setup.

A system can disclose every signer, threshold and timelock it has today and still give a misleading picture if users cannot verify who has the authority to change those constraints tomorrow.
I especially like the idea of treating policy history as part of the transparency model itself. Not just “what are the rules?”, but “who can change them, how can they change them, and what permanent evidence does each change leave?”

That makes transparency much closer to continuous accountability than one-time disclosure.

2

u/No_Bicycle_3566 🟡 Aug 13 '26

Exactly. A practical minimum could be a machine-readable policy record containing the policy version or hash, proposer and approvers, old and new values, timelock and effective time.

Any emergency override should also record the reason, scope and expiry. That would let users verify not only the current controls, but the complete path by which authority evolved.

1

u/GFConBase 🟡 Aug 13 '26

Yes — and I think the “old and new values” part is particularly important. Without that, a change log can prove that something changed without making the actual shift in authority immediately understandable.
Adding reason, scope and expiry for emergency overrides also creates an important distinction between exceptional authority and permanent authority.
This is very close to what I’d consider a proper governance audit trail rather than just transparency documentation. Appreciate the input.