Solana Governance Audits

Most Solana audits ask "can an attacker steal funds today?" Governance audits ask something subtler: can someone end up with more votes, more influence, or more control than they should? Sometimes that is an outright takeover, a subverted proposal handing an attacker upgrade authority over every program the DAO governs. Just as often it is quieter, a participant who found a nuance in the implementation that lets them tilt outcomes in their favour.

So we read governance as an incentive system, not just a state machine. Who is allowed to propose, who is allowed to vote, how voting weight is computed at each snapshot, and how a passing decision becomes an on-chain action. At each stage we ask what a self-interested participant could do that the designers did not intend: snapshot manipulation, double-voting, replayed proposals, execution-time argument tampering, or simply a rule that rewards behaviour the protocol never meant to reward.

On the execution side we read every CPI the governance program makes. The vote may be honest, but if the executed instruction lets the proposal author swap in their own account at execution time, the vote's integrity is meaningless. This is where most of the highest-severity governance findings we have disclosed have lived.

This applies well beyond classic DAOs. Token-weighted and trading-based governance, multisigs, and anywhere authority is shared all raise the same questions, including what happens when a member is compromised or simply acts in bad faith. Token-weighted systems are only as secure as the cost of acquiring enough weight at the snapshot, which is often far lower than teams expect once borrow-and-vote paths exist; a multisig is only as secure as its weakest signer. We flag these explicitly even when they are not strictly code bugs, because protocols routinely under-estimate them.