Two Ways to Steal a Vote Without Stealing a Wallet
You open the governance dashboard of a mid-size lending protocol. A proposal is passing that would drain the treasury into an address nobody recognizes. The vote count looks legitimate. Token holders apparently approved it. Nothing was hacked in the conventional sense: no private keys leaked, no smart contract exploited. The governance mechanism just did exactly what it was designed to do.
That should unsettle you.
The two most common ways this happens, vote buying and delegation exploitation, get lumped together as if they're the same problem. They are not. The mechanics differ, the attacker profiles differ, and the defenses that stop one can be completely useless against the other. Conflating them is how protocols end up building deadbolts on screen doors.
How Vote Buying Actually Works (It's Not a Bribe in a Brown Envelope)
Vote buying in on-chain governance usually runs through a vote-incentive layer sitting on top of a governance system. Convex Finance's influence over Curve's gauge-weight votes is the canonical real-world version: token holders deposited their voting power into Convex, and third parties paid them in external tokens to direct emissions toward specific liquidity pools. Gauge weights, for the uninitiated, are the percentage allocations that determine which Curve pools receive freshly minted CRV rewards.
That's the legal-ish version. The attack version runs the same mechanics, just with a malicious proposal at the center.
Here's how the numbers work. Imagine a protocol called ArborDAO with 10 million governance tokens in circulation. Quorum requires 20% participation: 2 million votes. An attacker identifies roughly 3 million tokens sitting in wallets that haven't voted in six months. They deploy a simple contract offering 0.05 USDC per governance token to anyone who delegates their vote to the attacker's address for 48 hours, framed as a "governance participation reward." Cost to the attacker: 150,000 USDC. Potential gain from the malicious proposal: a treasury holding 4 million USDC.
The math works. The attack works. Every wallet that participated technically made a free, informed choice.
The defining feature of vote buying: the attacker acquires voting power by compensating its current holders. Ownership of the underlying token never transfers. The attacker is renting influence, not buying it, which is precisely what makes it so hard to classify as theft.
How Delegation Exploitation Runs Differently
Delegation is a feature, not a bug. Most major governance systems, Compound, Uniswap, and ENS among them, let token holders assign their voting power to another address without moving the tokens themselves. The intent is sensible: passive holders delegate to active community members, participation rises, and nobody has to babysit every proposal.
The attack surface this creates is different in nature from vote buying. No payment involved. The attacker targets the existing delegation graph rather than trying to rent new votes.
Consider two token holders: Maya, who holds 800,000 governance tokens and delegated them two years ago to a prominent community delegate named delegate.eth, and Rafael, who did the same with 600,000 tokens. Delegate.eth has accumulated 4.2 million delegated tokens in total, one of the largest voting blocs in the protocol.
The attacker doesn't approach Maya or Rafael. They approach the delegate. If delegate.eth is a pseudonymous individual, the attacker might acquire that wallet's private key through social engineering, a phishing attack, or simply purchasing the account outright. Suddenly, 4.2 million votes move wherever the attacker points them. Maya and Rafael's tokens never moved. They have no idea anything happened until the proposal passes.
Alternatively, the attacker builds a fake delegate identity over months, accumulates delegation legitimately through good-faith participation, then executes the malicious vote when the moment is right. Slower, but it leaves no obvious bribery trail.
The defining feature of delegation exploitation: the attacker concentrates influence that was already voluntarily surrendered by token holders. No compensation changes hands. The attack targets trust, not wallets. It is, in a way, more elegant and more corrosive than simple vote buying.
Why the Fixes Don't Cross Over
This is where conflating the two attacks causes real damage to protocol design.
Against vote buying, the most effective mitigations target the economic equation directly. Time-locks on proposals, Compound's 48-hour voting delay being one example, force the attacker to hold rented votes longer, raising costs. Commit-reveal voting schemes hide individual vote choices until after the voting period closes, eliminating the attacker's ability to verify that purchased votes actually delivered. Snapshot-based eligibility, where only tokens held before a proposal was submitted count toward that vote, cuts off flash-loan amplified buying outright.
None of those fixes meaningfully address delegation exploitation.
A time-lock doesn't help Maya if delegate.eth's key was compromised a month before the proposal was even written. Commit-reveal is irrelevant if the attacker already controls the delegate's wallet. The attack has already succeeded before the vote begins, a fact that protocol designers routinely fail to internalize, because their threat models are built around the voting period itself rather than the delegation state that precedes it.
Against delegation exploitation, the mitigations are structural. Delegation caps, limiting any single address to say 5% of total supply in voting weight, reduce the prize worth targeting. Delegation expiry, where voting assignments reset after a fixed period and require active renewal, shrinks the pool of zombie delegations sitting untended. On-chain identity layers or multisig requirements for large delegates raise the cost of account takeover. Real-time delegation dashboards, like those Tally provides, at least let attentive token holders notice when their delegate's voting history suddenly changes character.
Those tools do almost nothing to stop a well-funded vote-buying campaign.
The Honest Caveat: Hybrid Attacks Exist
Real-world governance attacks rarely arrive in clean academic categories. The Beanstalk exploit used a flash loan, a type of uncollateralized loan borrowed and repaid within a single transaction block, to acquire governance tokens, vote through a malicious proposal, and drain roughly $182 million in one transaction. It was vote buying at warp speed, but it also exploited the absence of any time-lock, which is a delegation-adjacent design failure.
A sophisticated attacker might buy a small number of votes to push a proposal over quorum while simultaneously using a compromised delegate to supply the bulk of the voting weight. Two vectors, one attack, and defenders watching only one of them.
So here's the question worth sitting with: if your protocol's governance post-mortem would struggle to answer whether the attacker paid for influence or inherited it through the delegation graph, your threat model has a hole in it.
The more useful mental model isn't "which attack type is this" but rather: is the attacker acquiring new voting power through payment, or concentrating existing voting power through position? The answer points directly to which layer of the governance stack is broken.
Protocols that treat governance security as a single dial to turn up, rather than a set of distinct mechanisms protecting distinct attack surfaces, will keep discovering the hard way that a vote count can be perfectly legitimate and perfectly catastrophic at the same time. The governance mechanism did its job. That's the whole problem.