DeversiFI EIP-1559 EthereumJS Fee Bug

Notice: This page is a freshly imported case study from the original repository. The original content was in a different format, and may not have relevant information for all sections. Please help restructure the content by moving information from the 'About' and 'General Prevention' sections to other sections, and add any missing information or sources you can find. If you are new here, please read General Tutorial on Wikis or Anatomy of a Case Study for help getting started.

Notice: This page contains sources which are not attributed to any text. The unattributed sources follow the initial description. Please assist by visiting each source, reviewing the content, and placing that reference next to any text it can be used to support. Feel free to add any information that you come across which isn't present already. Sources which don't contain any relevant information can be removed. Broken links can be replaced with versions from the Internet Archive. See General Tutorial on Wikis, Anatomy of a Case Study, and/or Citing Your Sources Guide for additional information. Thanks for your help!

DeversiFI

A small number of users of the DiversiFi platform were faced with unexpectedly high Ethereum transaction fees, as a result of a bug in some JavaScript libraries. For most users, they could notice that these fees were too high, or displayed in funny HEX. Most users wouldn't be able to afford the outrageous fees unless they held that amount of Ethereum, so the transaction would simply fail. But as it happened, one user held the required Ethereum and didn't notice the funny fee, signing off a transaction which sent over 6,000 of their Ethereum to a miner.

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.

This is a global/international case not involving a specific country.

About DeversiFI

"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."

"Libraries that handle fixed precision and expanded numerical range are important in the Ethereum ecosystem as smart contracts can return numbers with up to 256 bits. JavaScript on it’s own can’t handle that precision leading to truncation or floating point errors. Not all of the big number libraries support floating point values and unfortunately the ethereumjs library uses BN which also does not. On the face of it this somewhat makes sense since Solidity doesn’t directly support anything other than integers, however it does push the responsibility on to anyone integrating their libraries to also not use decimal values."

"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."

This is a global/international case not involving a specific country.

The background of the exchange platform, service, or individuals involved, as it would have been seen or understood at the time of the events.

Include:

• Known history of when and how the service was started.
• What problems does the company or service claim to solve?
• What marketing materials were used by the firm or business?
• Audits performed, and excerpts that may have been included.
• Business registration documents shown (fake or legitimate).
• How were people recruited to participate?
• Public warnings and announcements prior to the event.

Don't Include:

• Any wording which directly states or implies that the business is/was illegitimate, or that a vulnerability existed.
• Anything that wasn't reasonably knowable at the time of the event.

There could be more than one section here. If the same platform is involved with multiple incidents, then it can be linked to a main article page.

The Reality

This sections is included if a case involved deception or information that was unknown at the time. Examples include:

• When the service was actually started (if different than the "official story").
• Who actually ran a service and their own personal history.
• How the service was structured behind the scenes. (For example, there was no "trading bot".)
• Details of what audits reported and how vulnerabilities were missed during auditing.

What Happened

The specific events of the loss and how it came about. What actually happened to cause the loss and some of the events leading up to it.

Key Event Timeline - DeversiFI EIP-1559 EthereumJS Fee Bug

Date	Event	Description
September 27th, 2021 5:10:08 AM MDT	Main Event	Expand this into a brief description of what happened and the impact. If multiple lines are necessary, add them here.

Technical Details

This section includes specific detailed technical analysis of any security breaches which happened. What specific software vulnerabilities contributed to the problem and how were they exploited?

Total Amount Lost

The total amount lost has been estimated at $22,534,000 USD.

How much was lost and how was it calculated? If there are conflicting reports, which are accurate and where does the discrepancy lie?

Immediate Reactions

How did the various parties involved (firm, platform, management, and/or affected individual(s)) deal with the events? Were services shut down? Were announcements made? Were groups formed?

Ultimate Outcome

What was the end result? Was any investigation done? Were any individuals prosecuted? Was there a lawsuit? Was any tracing done?

A bounty of $147,000 USD was paid for the discovery.

Total Amount Recovered

The total amount recovered has been estimated at $22,378,000 USD.

What funds were recovered? What funds were reimbursed for those affected users?

Ongoing Developments

What parts of this case are still remaining to be concluded?

General Prevention Policies

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.

Individual Prevention Policies

No specific policies for individual prevention have yet been identified in this case.

For the full list of how to protect your funds as an individual, check our Prevention Policies for Individuals guide.

Platform Prevention Policies

Policies for platforms to take to prevent this situation have not yet been selected in this case.

For the full list of how to protect your funds as a financial service, check our Prevention Policies for Platforms guide.

Regulatory Prevention Policies

No specific regulatory policies have yet been identified in this case.

For the full list of regulatory policies that can prevent loss, check our Prevention Policies for Regulators guide.