Schnoodle Reward Calculation Error

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.

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!

Schnoodle Homepage/Logo

Schnoodle was a smart contract platform launched by Jason Payne, with nickname Neo, which allowed users to earn rewards simply by holding a SNOOD token. On June 18, 2022, Schnoodle lost $112K due to a hack which took advantage of an error in the reward calculation algorithm. The smart contract developer reached out on the Stack Exchange forums to get assistance in determine how their smart contract had been exploited. It is unclear if any compensation was provided to affected users.

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

About Schnoodle

"PEER-TO-PEER, BLOCKCHAIN AUTOMATED REWARD KICKBACKS (BARK!) Schnoodle is a progressive DeFi peer-to-peer cryptocurrency with built-in Blockchain Automated Reward Kickbacks (BARK!) technology. Watch your balance grow automatically simply by holding SNOOD!"

"Designed and expertly coded from the ground up, Schnoodle is a first class DeFi cryptocurrency that you can truly trust. Schnoodle is an ERC-777 token that uses the latest technologies and practices to protect holders and ensure low gas fees. Key features: Upgradeability, oracle-based governance (DAO), multisig protection, eleemosynary fund, staking, farming, NFT rewards. Schnoodle really is man’s best friend!"

"Schnoodle is a fully decentralized, peer-to-peer cryptocurrency, owned entirely by its community (no team tokens). With oracle-based governance and multisig protection, Schnoodle will be the first of its kind to become a true DAO."

"All transfers incur a 1% eleemosynary donation, and a 4% fee that is proportionately distributed to all holders automatically as instant rewards. Sit back, relax, and watch your SNOOD balance grow on every transaction all day, every day."

"Schnoodle was incepted by our founder and CTO, Jason Payne, who decided to build Schnoodle because he was disillusioned with cryptocurrencies being released one after the other that had no real innovation, and were mostly copypasta smart contract clones of other tokens with a few tweaks. And those tweaks were typically convoluted layers of abstraction that usually benefited the dev team rather than the community."

"My ERC-777 smart contract (Schnoodle, symbol SNOOD) was attacked yesterday resulting in the entire liquidity in the UniswapV2Pair token being drained (104 ETH). The attack was by way of an attacker contract that performed a series of interactions with the liquidity token and my smart contract during its creation (txn here)."

"What I would like to know is, how did this attack take place, where is the vulnerability? And how do I protect against it? If this is an vulnerability in the SNOOD code, then how do I fix it? If it's a vulnerability in the UniswapV2Pair code related to ERC-777 tokens which is what SNOOD is, then I guess I would have to change my contract to ERC-20, or use UniswapV3Pair, or another DEX altogether."

"Seems to me that your error is here. Typically this kind of computation is done using fixed-point arithmetic or using a reflection * totalSupply / reflectedSupply calculation. In the case of transaction 0x9a6227ef97d7ce75732645bd604ef128bb5dfbc1bfbe0966ad1cd2870d45a20e , during the call to _spendAllowance, the _getStandardAmount call returns 0, even though the amount being transferred is significant. It's hard to tell what the intent of this code is, but the result is that the reflected amount isn't converted to a token amount, but is instead simply set to zero because _getReflectRate returns a large value. As a result, even though the UniswapV2 trading pair does not have an allowance set, the attacker is able to transferFrom the total balance of the pair to their attack contract. Subsequently, the attacker calls sync to force the pair to take up its new, vastly-decreased balance as the reserve. After that, it's a simple matter of swapping the stolen SNOOD tokens for the WETH left in the pair."

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 - Schnoodle Reward Calculation Error

Date	Event	Description
May 14th, 2021 6:54:49 AM MDT	Schnoodle Website Online	First capture of the Schnoodle website.
June 18th, 2022 1:05:24 AM MDT	Malicious Transaction	The malicious transaction is made which allows the theft of funds.
August 24th, 2022 11:06:48 AM MDT	Stack Overflow Discussion	Developer asks for help on the Ethereum stack exchange.
September 21st, 2023 8:12:54 PM MDT	Website Last Capture	The Schnoodle website is captured for the last time.
November 29th, 2023 2:29:26 AM MST	Website Offline	The Schnoodle website appears to be offline for the first time.

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 $112,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?

Total Amount Recovered

The total amount recovered is unknown.

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?

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.