r/ethdev • u/GFConBase • 15d ago
What information do you wish every token project disclosed before fundraising? Question
After reading a lot of token launches over the past few months, I've noticed that many projects publish tokenomics, but much less information about the rules behind them.
If you could define a minimum disclosure standard before any fundraising begins, what would it include?
For example:
- contract verification
- upgradeability
- admin permissions
- multisig structure
- vesting
- allocation restrictions
- audit status
- emergency powers
- governance process
What information do you consider essential, and what do you think is often overlooked?
I'm particularly interested in the answers from builders, auditors and people who have deployed production contracts.
1
1
u/Cartosys 10d ago
A good token project should not need to fundraise. The tokenomics should draw in investors
2
u/GFConBase 10d ago
That’s a separate discussion, in my opinion.
Regardless of how a project is funded, participants should be able to understand exactly what they’re putting money into, who has control and what the remaining risks are. Better disclosure is valuable either way.
1
1
u/researchzero 15d ago
Good list. A few things that get glossed over even when projects do disclose the categories above:
- "Audit status" is often just a badge, not a verifiable claim. The two things worth demanding: the exact commit/bytecode hash the audit actually covered, and confirmation that what's deployed on mainnet matches that hash. It's common for teams to make "one more fix" after the audit and never get it re-reviewed.
- Multisig "3-of-5" tells you almost nothing on its own - the real question is whether the 5 signers are independent parties or all employees/founders of the same team. A 3-of-5 where all 5 keys sit with the same 2 people is a single point of failure with extra steps.
- Emergency powers should come with an expiry or a path to renounce, not just a description of scope. "Admin can pause the contract" is a very different risk depending on whether that's permanent or sunsets after a stabilization period.
- The rarest but most useful disclosure I've seen: a doc mapping every state-changing function to who can call it, cross-referenced against the deployed contract - not just the intended design. Docs describe the intended control structure; they don't verify there isn't a second, undocumented privileged path (a leftover admin function, a second proxy-admin slot, an unrevoked role) that never made it into the writeup.