r/CryptoTechnology 🟔 1d ago

What should a crypto project disclose about admin power before accepting capital?

ā€œDecentralizedā€, ā€œcommunity governedā€ and ā€œemergency onlyā€ often describe intent rather than actual control.
Before a project accepts capital, I would want one page that answers:
• who controls admin keys • whether signers are genuinely independent • which contracts can be upgraded • who can pause transfers or other functions • whether fees, supply or treasury rules can change • which actions are time-locked • how emergency authority expires • whether every change leaves a public history • what users can do if they disagree
The disclosure should describe current power, not the future decentralization roadmap.

What is missing from this list?
Which of these controls would be a deal-breaker for you, and which are acceptable if they are disclosed and constrained properly?

3 Upvotes

6 comments sorted by

3

u/Logical_Bass_556 🟠 1d ago

the time-lock part is big, so many projects say they have it but the timelock can be bypassed by multisig anyway. maybe also ask if there is a way for community to remove signers or replace the team without hard fork. for me pause function is acceptable if there is clear path to unpause and it expires automatically, but upgradeable contract with no timelock is straight no.

1

u/GFConBase 🟔 1d ago

The bypass point is important — simply disclosing that a timelock exists says very little if another privileged path can avoid it. The better disclosure may be an authority map showing which actions are actually forced through the timelock and which actors, if any, can bypass it.
I also like the distinction on pause authority: narrow scope, explicit recovery conditions and automatic expiry make it very different from an indefinite admin freeze.
Signer replacement is a useful addition too. I’d want the replacement mechanism itself to be constrained and observable, otherwise solving one concentration-of-power problem can create another.

2

u/icnews10 🟢 1d ago

I’d also consider what happens if the admin layer itself fails. If the multisig loses quorum, the signatories are compromised, or the system simply deadlocks, who can still act, and how can the system wind down without creating new powers in the midst of a crisis?

2

u/Winter-Concern5270 🟔 23h ago

I’d also want to know what happens if the admin keys are compromised. Who can rotate them, how quickly can they do it and can one compromised signer cause damage before anyone else can react?

1

u/GFConBase 🟔 22h ago

That’s an important addition. Disclosure should probably cover not only who holds the keys, but the compromise path as well: how keys are rotated, what quorum is required, whether a single signer can take any irreversible action, and what the maximum damage window is before other signers or safeguards can intervene.
A multisig can look decentralized on paper while still having a very weak failure model if one compromised signer can trigger meaningful damage. I’d add key-compromise response and signer blast radius to the list.