QuadrigaCX Contract Error

From Quadriga Initiative Cryptocurrency Hacks, Scams, and Frauds Repository
Revision as of 13:57, 5 April 2023 by Azoundria (talk | contribs) (Initial case study created and online now.)
Jump to navigation Jump to search

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' section 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.

It’s easy to forget the level of trust that Quadriga had in the market. The top upvoted comment reads “thank you for the statement and transparency and sharing all details”. Given failures and many hacking incidents, smart contracts should in general not be relied upon, and an exchange should always have redundancy and auditing checks built in for every single system. While some issues may be seen as inevitable, having an issue persist for 3 days without being noticed is troubling. While there are many steps which could have been taken to prevent or notice the issue sooner, and this incident did contribute to the depletion of reserves, it’s not the reason anyone ultimately lost their funds. This type of failure is very challenging to regulate, already in the best interest of the exchange to avoid, and rare compared to other types of failures which can occur. The exchange needs to transparently cover this shortfall, with the assistance of any hot wallet insurance.

This exchange or platform is based in Canada, or the incident targeted people primarily in Canada.

About QuadrigaCX

"Earlier this week, we noticed an irregularity with regards to the sweeping process of incoming Ether to the exchange. The usual process involved sweeping the ether into a ETH/ETC splitter contract, before forwarding the ether to our hot wallet. Due to an issue when we upgraded from Geth 1.5.3 to 1.5.9, this contract failed to execute the hot wallet transfer for a few days in May. As a result, a significant sum of Ether has effectively been trapped in the splitter contract. The issue that caused this situation has since been resolved." “In order to call a function in an Ethereum contract, we need to work out its signature. For that we take the HEX form of the function name and feed it to Web3 SHA3. The Web3 SHA3 implementation requires the Hex value to be prefixed with 0x - optional until Geth 1.5.6. Our code didn't prefix the Hex string with 0x and when we upgraded Geth from 1.5.3 to 1.5.9 on the 24th of May, the SHA3 function call failed and our sweeper process then called the contract with an invalid data payload resulting in the ETH becoming trapped.” “While this issue poses a setback to QuadrigaCX, and has unfortunately eaten into our profits substantially, it will have no impact on account funding or withdrawals and will have no impact on the day to day operation of the exchange. All withdrawals, including Ether, are being processed as per usual and client balances are unaffected.” “Data from EtherScan shows that the contract in question currently holds 67,317.25 ETH – an amount worth roughly $14.7m at current ether prices.”

This exchange or platform is based in Canada, or the incident targeted people primarily in Canada.

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.

The issue with the smart contract was described in the statement which was released by QuadrigaCX[1].

In order to call a function in an Ethereum contract, we need to work out its signature. For that we take the HEX form of the function name and feed it to Web3 SHA3. The Web3 SHA3 implementation requires the Hex value to be prefixed with 0x - optional until Geth 1.5.6.

Our code didn't prefix the Hex string with 0x and when we upgraded Geth from 1.5.3 to 1.5.9 on the 24th of May, the SHA3 function call failed and our sweeper process then called the contract with an invalid data payload resulting in the ETH becoming trapped.

As far as recoverability is concerned, EIP 156 (https://github.com/ethereum/EIPs/issues/156) could be amended to cover the situation where a contract holds funds and has no ability to move them.

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 - QuadrigaCX Contract Error
Date Event Description
May 30th, 2017 3:15:18 AM MDT Failed Deposit Transaction Example An example transaction occurs which attempts to deposit 4.382119011569663172 ETH, which gets stuck in the smart contract[2].
June 2nd, 2017 1:16:32 AM MDT Community Asking About Loss A thread is posted to Reddit reporting that user ethereum deposits are being "sent to an address that's unrecoverable"[3]. (TBD expand further.)
June 2nd, 2017 5:36:48 AM MDT Details Posted on Reddit The QuadrigaCX platform posts details about the incident to Reddit[1]. (TBD expand with details.)
June 2nd, 2017 6:20:35 AM MDT Post Praising Transparency A response to the incident praises QuadrigaCX for their high level of transparency and explains the technical details of what happened[4].
June 2nd, 2017 12:00:01 PM MDT CoinDesk Article CoinDesk publishes an article on the incident[5]. (TBD expand with details.)
June 2nd, 2017 Date In Timelines The date is widely reported as June 2nd, 2017[6][7].
February 6th, 2019 Verdict Timeline The smart contract loss is referenced in a timeline published by Verdict[8]. (TBD add more timeline information.)
February 22nd, 2019 CoinRivet Article The contract incident is referenced in a CoinRivet article on CoinBase CEO Brian Armstrong's reactions to the collapse of the QuadrigaCX coin exchange[9].

Total Amount Lost

The Crypto Theft Timeline reports the total loss as 60000 "Crypto", which likely indicates 60,000 ethereum[6]. The BitcoinExchangeGuide also lists the amount of the loss as 60,000 ethereum[7].

The total amount lost has been estimated at $14,700,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

Community Reactions Prior To Announcement

Multiple posts on Reddit reference an issue with Ethereum deposits into the QuadrigaCX coin exchange[3].

All over the ETH reddit says you guys screwed up your SafeConditionalHFTransfer without a function and users keep deposit ETH which is sent to an address that's unrecoverable.

For example https://etherscan.io/tx/0x7e86b05eac756b1062e7420bcefe581a2e906197a8fc87832e7783905b2d88cf

client deposit to 0xf8cf56df660b655cb913931ddb10fbd25ec5df82 and the exchange redirects to 0x027BEEFcBaD782faF69FAD12DeE97Ed894c68549 but due to an error in their code they did not call the right function and the 4 ether is trapped in the contract

there are many such tx in the last few days from many addresses but with this same error

QuadrigaCX Posts Reddit Announcement

Ultimately, QuadrigaCX posted a detailed announcement about the situation to Reddit[1].

Earlier this week, we noticed an irregularity with regards to the sweeping process of incoming Ether to the exchange. The usual process involved sweeping the ether into a ETH/ETC splitter contract, before forwarding the ether to our hot wallet. Due to an issue when we upgraded from Geth 1.5.3 to 1.5.9, this contract failed to execute the hot wallet transfer for a few days in May. As a result, a significant sum of Ether has effectively been trapped in the splitter contract. The issue that caused this situation has since been resolved.

While this issue poses a setback to QuadrigaCX, and has unfortunately eaten into our profits substantially, it will have no impact on account funding or withdrawals and will have no impact on the day to day operation of the exchange.

All withdrawals, including Ether, are being processed as per usual and client balances are unaffected.

Community Reactions Following Announcement

The Reddit community was largely supportive of the situation and the level of transparency provided was praised[4][10].

thank you for the statement and transparency and sharing all details.

I really hope you guys recover from this. Hopefully maybe ETH will go back to $50ETH/USD and you'll be able to buy back all the trapped ETH.

Ultimate Outcome

The smart contract incident did not cause any noted losses at the time, however it did reduce the amount of Ethereum on the QuadrigaCX balance sheet, and could be argued to contribute towards the ultimate collapse of the platform in 2019.

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

Total Amount Recovered

According to BitcoinExchangeGuide, "QuadrigaCX resolved the issue, and customers were not penalized"[7].

There do not appear to have been any funds recovered in this case.

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?

Prevention Policies

Coming soon.

References

Cite error: <ref> tag with name "messari-81" defined in <references> is not used in prior text.