Ethereum’s Solidity language is under the spotlight following the programming error resulting in the loss.
Compound Finance rolled out Proposal #62 on Wednesday to implement “Dynamic COMP reward distribution,” and patch a number of minor bugs.
However, soon after executing the upgrade, Compound Labs reported “unusual activity,” resulting in some users being able to claim more $COMP tokens than allowable.
Having looked into the contract, smart contract auditor Kurt Barry said the bug resulted from the tiniest of errors. He added that this minor mistake cost Compound Labs tens of millions.
But how tiny was this error?
Ethereum’s Solidity language is unforgiving
Solidity is an object-orientated programming language, meaning it organizes design around objects and data. As opposed to function and logic.
It has similarities to C and C++ so it’s relatively simple to learn. And given the number of programmers who are already familiar with C and C++, transitioning to Solidity doesn’t take much.
However, this imperative approach has risks in that programmers must tell the code exactly what to do at every stage. And a mistake, even a tiny omission leaves the smart contract open to vulnerabilities.
“With an imperative approach, a developer writes code that specifies the steps that the computer must take to accomplish the goal. This is sometimes referred to as algorithmic programming. In contrast, a functional approach involves composing the problem as a set of functions to be executed.”
In this case, Barry’s investigation showed that Compound’s Proposal #62 error was due to the programmer missing an “=” sign in two locations.
“Smart contracts are unforgiving of the tiniest errors…COMP bug is a tragic case of “>” instead of “>=” (in two code locations). Two characters, tens of millions of value lost.”
Critics will argue that Compound’s audit and testing process should have been more thorough. However, isn’t this another example of Solidity’s flaws, which get magnified when millions of dollars are at risk?
What is the Compound Finance Proposal #62?
Previously, the Compound Finance rewards rate was the same rate for both suppliers and borrowers, and this fostered problems such as negative interest rates when borrowing particular assets.
Proposal #62 intended to split the COMP distribution to liquidity suppliers and borrowers based on governance-set ratios rather than an equal 50/50 share model.
“This proposal changes the Comptroller logic to have two different COMP distribution rates for each and every market – borrow-side (compBorrowSpeeds) rate and supply-side (compSupplySpeeds) rate.”
However, the bug contained within the upgrade enabled some users to claim more $COMP tokens than allowable.
At this stage, exact details of the loss are unknown. However, Compound CEO Robert Leshner states the worst-case scenario is an overclaim of 280,000 COMP tokens, equating to $82,880,000 at today’s price.