$22 534 000 USD
DESCRIPTION OF EVENTS
"DiversiFi is a decentralized exchange platform, which was audited by PeckShield."
"Our decentralised exchange is the easiest way to access DeFi opportunities on Ethereum: invest, trade, and send tokens without paying gas fees." "We’ve got a suite of tools to help you make the most of DeFi. From managing your crypto portfolio, to trading, swapping and sending assets and tokens and even putting your investments to work earning you rewards and interest."
"Getting started with DeversiFi couldn't be simpler, whether you’re a crypto ninja or just starting out, our DEX really is the simplest way to access all the opportunities of decentralised finance."
"The core smart-contracts employed by DeversiFi to secure customer funds on the Ethereum blockchain were designed and deployed by StarkWare Industries. StarkWare are leaders in the field of cryptography and blockchain systems. [An] independent audit report was made by PeckShield."
"In response to high and often unpredictable transaction fees a new concept was introduced – namely a base cost of gas which would scale more smoothly depending on network load. The gas consumed by a transaction would be specified by the product of this base fee and the complexity of the interaction (i.e. the gas cost). On the face of it, this would result in a much more predictable mechanism eliminating the possibility of accidentally overspending on fees. These fees would then be burned during execution, potentially pushing Ethereum into deflationary economic territory."
"A common misconception is that EIP-1559 transactions entirely eliminate the possibility of someone overpaying for a transaction. Whilst this may be true for the max fee which specifies a ceiling cost, not the final cost – the priority fee behaves like a legacy transaction in that it is all taken by the miner. In a situation where both the priority fee and max fee are set too high there is no protection from accidental overpayment."
"DeversiFi is a layer 2 protocol on Ethereum for Decentralised Finance. Our team hosts a front-end which provides an easy interface to access the protocol from a variety of wallets, including Metamask and Ledger. About a month ago we updated the front-end for DeversiFi to make use of EIP-1559 transactions provided by the London hardfork activation. We switched to the latest version of the Ethereum library and implemented the new functionality as documented."
"Prior to going live with the new transaction type, the changes were extensively tested on our test and staging environments. Additionally, we actively monitor on mainnet any on-chain events which enabled us to see that for the vast majority of users the updated transactions were working correctly. On-chain transactions can sometimes fail due to network activity bumping up gas prices suddenly or through insufficient fees being manually set. As such when we saw occasional layer 1 transactions failing to be broadcast or confirmed on-chain, it was not always easy to understand why."
"The first part of this process is where a problem occurred, specifically when the gas and priority fees were calculated and then converted into a big number object. Since the last few blocks are used to predict priority fees, the calculation could result in a decimal figure."
"When the gas values generated were integers, the underlying Ethereum library code worked perfectly, however when passing a decimal value things quickly became strange. The BN library used by the Ethereum library code throws an error to indicate an invalid value has been passed, however since the value was converted to a buffer first no error handling was triggered." "For example, passing a value of 33974230439.550003 would set an integer 35624562649959629 – potentially six orders of magnitude higher than intended."
"The core technical issue is that ethjs-util’s intToBuffer does not support incoming floating-point data. Ethereumjs uses ethjs-util’s intToBuffer."
"In short: when DApp uses ethereumjs to construct a transaction, if the incoming commission has a decimal number, it may return a large number in the browser as a commission due to a bug in the type conversion. And the hardware wallet is not displayed clearly, causing the user to directly authorize and sign the transaction with the sky-high gas fee."
"When this mangled numeric interpretation occurred it would either fail due to the priority gas amount being higher than the max fee per gas or, more insidiously, because the amount of ETH a user had in the wallet was almost always unlikely to be high enough to cover this enormous overspend of gas fees."
"This means that for the minority of hardware wallet users who experience this issue, almost all will never understand why their transaction (sometimes silently) failed. They will then simply retry and in all likelihood it will work on the second attempt when the base fee predictions for the next block had updated to return a non-decimal value."
"When signing a transaction on a Ledger, the max fee is displayed to the user for them to verify the terms of the transaction they’re about to authorise. An exacerbating factor is that sometimes Ledger currently displays very large fees as a hex value."
"In trying to reproduce the issue, we encountered fee prompts as shown above. In this example transaction showing the issue, a hex value of B526167CF91FECE4 equals 13053145295991336164 which equates to an astronomical fee of 13053145295991.336164 Gwei or ~13.05 ETH."
"If this transaction were accepted (and the funds to cover it present in the wallet) the user would be signing a maximum fee of 216,564 ETH. The actual amount might be lower depending on the priority fee which is not shown."
"Whilst these may be outrageous numbers for the majority of wallets, resulting in these transactions not normally being accepted by the network, for wallets who have the funds to cover these eye-watering sums there was no other safety mechanism to prevent the broadcast of such an expensive transaction."
"By 12:30:00 PM UTC+1 the team at DeversiFi were aware of the issue and began our investigation. We quickly identified two primary areas of concern which we began actively testing in an attempt to reproduce and explain how the erroneous transaction was created." "We then shared an explanation with our community and the blockchain world at large who had started to notice this transaction." "By 16:45 UTC + 1 we had disabled deposits from Ledger users to enable us to identify the issue without putting further users at risk."
"By the evening we had found the likely culprits in the gas fee functions and set about implementing an improvement to prevent the edge case." "Additional safety and sanity checks were also added to ensure gas fees associated with transactions could not exceed unrealistic thresholds to protect against user error, extreme network fee spikes and as an additional layer of protection against any future coding error." "We have raised an issue with the EthereumJs maintainers describing the defect in the library."
"Lastly we communicated with the Ledger team about anomalies discovered during testing which could obfuscate abnormally high fees for any Ethereum transaction." "Safety improvements rolled out and ledger deposits re-enabled by 15:30 on 28/09/21."
"After seeing that the miner of block 13307440 who had received the fee was periodically depositing mined ETH to Binance we made contact with Binance. Binance agreed to pass our email addresses to their customer so that they might be able to reach out to us. By 20:36 UTC + 1 we had received an email from the miner who had reached a process for safely returning funds. Within an hour they had made the first return transaction, with a total of 7626 returned. DeversiFi offered for the miner to keep 50 ETH as a return fee."
"DeversiFi are actively engaging with both the Ethereum community and Ledger to patch issues that may have contributed to this occurrence. On our platform we’ll be implementing stronger defensive measures when interfacing with external libraries, reviewing how we treat failed transactions and also enforcing a ceiling value for any max transaction fees as additional protection."
The miner was a person of integrity and returned the funds, keeping only the offered 50 ETH as a finders fee. As a result, the affected user only lost 50 ETH. DeversiFi has since rebranded their project as Rhino Finance.
HOW COULD THIS HAVE BEEN PREVENTED?
The primary method of preventing falling victim to paying a large fee due to human error in a transaction, either a bug in an automated generation or when manually making the transaction by some other method, is through a multi-signature setup. In this setup, the probability of catching the issue is multiplied.
It is best practice to store the majority of funds offline and if this practice was employed, the balance would be insufficient to cover the transaction fee, so the transaction would be rejected in a case like this.
blocksec-incidents/2021.md at main · openblocksec/blocksec-incidents · GitHub (Aug 11)
Decentralized Cryptocurrency Exchange | Ethereum Exchange | DeversiFi (Oct 13)
Smart Contract Audit Report | DeversiFi (Oct 13)
SlowMist Hacked - SlowMist Zone (Jun 26)
A 23.7 million dollar Ethereum transaction fee post mortem... | DeversiFi (Dec 5)
The Analysis Of Sky High Gas Fee Im Not The Real Man Of Rich (Dec 5)
Ethereum Transaction Hash (Txhash) Details | Etherscan (Dec 5)
@deversifi Twitter (Dec 5)
@tayvano_ Twitter (Dec 5)
Ethereum Transaction Hash (Txhash) Details | Etherscan (Dec 5)
@deversifi Twitter (Dec 5)
https://coinmarketcap.com/currencies/ethereum/historical-data/ (Dec 21)
$23.7m Ethereum Transaction Fee Post Mortem | DeversiFi Blog (Jul 2)
@DeversiFiLabs Twitter (Jul 2)
@amanusk_ Twitter (Jul 22)
The miner who got $22.47 million, for processing USDT transaction is refunding the transaction fees. : CryptoCurrency (May 2)