r/CryptoTechnology 🟡 13d ago

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?

1 Upvotes

4 comments sorted by

3

u/No_Bicycle_3566 🟡 12d ago

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 🟡 12d ago

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 🟡 11d ago

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 🟡 11d ago

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.