Introduction
In the world of DeFi and DAO governance, the voter escrowed (ve) model is a gold standard for aligning long-term incentives. Users lock their tokens, receive voting power, and decide how rewards (inflation) are distributed. But what happens when the system "forgets" that you’ve already withdrawn your tokens?
In this article, I’ll break down a vulnerability I discovered in the Olas Protocol (Autonolas) during a Code4rena audit, where a lack of synchronization between core contracts allows for infinite inflation manipulation.
The Architecture: A Tale of Two Contracts
The Olas governance system relies on two main pillars:
veOLAS.sol: The vault where tokens are locked and the time-weighted balance is managed.
VoteWeighting.sol: The engine that calculates voting weights to determine inflation distribution across different "gauges".
For the system to work, VoteWeighting must always know exactly how much power a user has.
The Vulnerability: Persistent Weights after Withdrawal
The flaw lies in the withdraw() flow. When a user's lock period ends in veOLAS.sol, they call the withdraw function to get their tokens back.
The Logic Failure:
veOLAS.sol successfully burns the user's lock and returns the tokens.
However, it does not trigger any update or notification to VoteWeighting.sol.
In VoteWeighting, the user's last recorded slope and bias (the mathematical components of voting power) remain on the books. The contract still "thinks" the user has voting power based on their old, now-deleted lock.
Attack Scenario: The "Sybil Inflation" Loop
An attacker can exploit this "ghost" voting power to capture a disproportionate share of the protocol's inflation:
Lock: Attacker locks a large amount of OLAS in veOLAS for the maximum duration.
Vote: They use this power in VoteWeighting to vote for a specific gauge (e.g., a pool they control).
Wait & Withdraw: Once the lock expires, they withdraw their tokens.
The Ghost Power: The attacker’s tokens are back in their wallet, but their vote in VoteWeighting is still active and counting towards reward distribution.
Repeat: The attacker moves the same tokens to a new wallet and repeats the process.
Result: An attacker can stack "ghost" votes from multiple expired locks to effectively take over the protocol's reward distribution mechanism.
Impact & Final Thoughts
While this was classified as a Low/Medium risk by some due to the specific timing required for locks, from an economic security standpoint, it’s a fundamental flaw. It breaks the "1 token = X voting power" rule.
Key Takeaway for Auditors:
Always check the "Exit" functions. If a protocol uses a multi-contract architecture for governance, ensure that every state change in the Vault is reflected in the Voting Engine.
About the Author
I am RimDinov (rdin777), a Web3 Security Researcher and Bug Bounty Hunter. I document my daily findings as I dive deeper into smart contract audits and protocol security.
Ethereum, #Solidity, #SmartContract, #Audit, #DeFi
Top comments (0)