The Omniscia team recently had the opportunity to conduct an exhaustive security audit for Myso Finance, a pioneering entity within the domain of peer-to-peer lending and borrowing protocols. This endeavor reiterates our unwavering dedication to upholding the highest standards of cybersecurity within the Web3 landscape and underscores Myso Finance’s unrelenting commitment to delivering a secure and trustworthy platform.

Borrowing and lending protocols in the decentralized finance (DeFi) space walk a particularly thin line due to their inherent complexity and the significant amount of value they often manage. They function as the backbone of DeFi, enabling users to earn interest on deposits and take out loans in a permissionless and open manner, but this also exposes them to a variety of unique risks and potential exploits.

“Our in-depth audit of Myso Finance serves as a testament to their unwavering commitment to upholding a secure, efficient, and reliable platform. At Omniscia, we take immense pride in being a part of this journey, bolstering security in the Web3 space. We eagerly look forward to continuing our work with partners like Myso Finance, who place paramount importance on user safety and system efficiency.”

— Yvan Nashr, Founder & CEO, Omniscia.io

Audit Results

As always, our audit methodology was rigorous, entailing a meticulous line-by-line examination of Myso Finance’s codebase to ensure the proper execution of all state transitions and fundamental formulas within the system.

Over the course of the audit we identified potential vulnerabilities that could lead to severe operational malfunctions if left unaddressed. These potential issues were immediately communicated to the Myso Finance team, who promptly remediated all findings.

One of the most notable vulnerabilities within the system was its insufficient validation of the interest factor described in LVI-04M. Lenders were able to create seemingly lucrative debt repayment terms at a “-100%” interest rate, essentially providing their loans without expecting any return.

Due to the design of the Myso Finance system, borrowers who acquired those loans would be unable to repay them as the system would fatally fail with a division-by-zero error. This permitted lenders to provide these loans to unsuspecting borrowers and “force” them to enter default when their repayment period expires, acquiring the borrower’s collateral at that point. The Myso Finance team has since alleviated this exhibit in the latest iteration of the codebase.

The Omniscia team also identified 31 optimizations, 14 of which directly led to significant gas reductions. All optimization suggestions were addressed by the Myso Finance team to ensure the smart contracts in scope comply with the latest best practices and standards in Solidity.

“Working alongside the security professionals from Omniscia has been an absolute privilege. We deeply appreciate their meticulous and high-quality work, as their expertise has played a pivotal role in fortifying our code security and protecting our users. Their exceptional ability to swiftly comprehend our intricate codebase and identify critical edge cases has exceeded our expectations. Collaborating with them has not only strengthened our auditor diversification but has also made a significant contribution to enhancing the quality of our code.”

— Aetienne Sardon, Founder & CEO, MYSO Finance

All in all, the Myso Finance team was extremely responsive and demonstrated their dedication to security and system efficiency, reflecting a harmonious blend of agility and technological sophistication. Shout-out to ChainSecurity and TrailOfBits for their audits of previous iterations, showcasing Myso Finance’s dedication to security and auditor diversification.

→ Read the full technical report here.

Omniscia.io is one of the fastest growing and most trusted blockchain security firms and has rapidly become a true market leader. To date, our team has collectively secured $200+ billion worth of digital assets, for 300+ happy clients by detecting 1,500+ high-severity issues in widely adopted smart contracts.

Founded at the start of 2020, and with a track record spanning back to 2017, our team has been at the forefront of auditing smart contracts, providing expert analysis and identifying potential vulnerabilities to ensure the highest level of security of popular smart contracts, as well as complex and sophisticated decentralized protocols.

Our clients, ecosystem partners, and backers include leading ecosystem players such as L’Oréal, Polygon, AvaLabs, Gnosis, Morpho, Myso Finance, CLabs, Olympus DAO, Fetch.ai, and LimitBreak, among others.

Make sure you follow us on Twitter, and other socials, and subscribe to our newsletter to stay ahead of the curve. Remember, it’s better to be secured late than sorry. 🔐

Twitter / LinkedIn / Newsletter

This article is meant to analyze the Euler Finance incident that occurred on the 13th of March at approximately 08:50 UTC in an impartial way and identify the root cause.

Vulnerability Analysis

The vulnerability that was exploited stems from how Euler Finance permits donations to be performed without a proper account health check.

The vulnerable code was introduced in eIP-14¹ which introduced multiple changes throughout the Euler Ecosystem. The flaw lies in the first change performed to the EToken implementation (EToken::donateToReserves feature²).

The logic within the Liquidation module will attempt to repay the full debt of the violator, however, if the collateral they possess would not satisfy the expected repayment yield, the system defaults to whatever collateral the user has³.

The assumption of this code block states that a borrower’s available collateral will be insufficient only when:

This can happen when borrower has multiple collaterals and seizing all of this one won’t bring the violator back to solvency

This security guarantee is not upheld by the donation mechanism which permits the user to create “bad debt” in the form of leverage that is uncollateralized by donating their EToken units without affecting their DToken balance⁴.

Core Problem

The Euler Finance protocol permits its users to create artificial leverage by minting and depositing assets in the same transaction via EToken::mint. This mechanism permits tokens to be minted that exceed the collateral held by the Euler Finance protocol itself.

The donation mechanism introduced by Euler Finance in eIP-14¹ (EToken::donateToReserves) permits a user to donate their balance to the reserveBalance of the token they are transacting with. The flaw lies in that it does not perform any health check on the account that is performing the donation.

As a donation will cause a user’s debt (DToken) to remain unchanged while their equity (EToken) balance decreases, a liquidation of their account will cause a portion of DToken units to remain at the user thus creating bad debt.

The above flaw permits the attacker to create an over-leveraged position and liquidate it themselves in the same block by artificially causing it to go “under-water”.

When the violator liquidates themselves, a percentage-based discount is applied that will cause the liquidator to incur a significant portion of EToken units at a discount, guaranteeing that the they will be “above-water” and incur only the debt that matches the collateral they will acquire.

The end result is a violator with a significant amount of “bad debt” (DToken) and a liquidator with an over-collateralization of their debt (DToken > EToken) due to the percentage-based liquidation incentives the Euler Protocol possesses⁵. As evidenced in the transaction itself⁶, the maximum 20% discount was applied during the attack’s liquidation.

Attack Scenario

In order for the attacker to be able to liquidate themselves, they had to deploy at least two contracts to exploit the vulnerability. The attack transaction⁶ submitted at approximately 2023–02–01 06:29:18 UTC invokes a contract that had been deployed in an earlier transaction⁷.

This contract performs the following steps during the attack transaction’s execution:

a. Primary Contract:

• Acquire a 30m DAI flash-loan from AAVE V2
• Deploy the two contracts (violator⁸ & liquidator⁹) for the attack
• Transfer the full 30m DAI loan balance to the violator

b. violator Contract:

• Deposit 20m DAI to the DAI EToken of Euler Finance, receiving ~19,56m eDAI tokens
• Create a 200m artificial eDAI leverage, minting ~195,68m eDAI and 200m dDAI to the violator
• Repay 10m DAI on the violator’s position, causing their dDAI balance to go to 190m
• Create another 200m artificial eDAI leverage, minting ~195,68m eDAI and 200m dDAI to the violator
• Donate 100m eDAI to the reserve of the EToken

At this point, we have the following violator state:

• eDAI: ~310,93m
• dDAI: 390m

In the above state, the violator contains a significantly larger amount of dDAI tokens than eDAI tokens that will never be collateralized as their backing was “erased” during the donation call. The liquidator will exploit this due to the calculations within the Liquidation module.

As stated earlier, the Liquidation module will liquidate up-to the collateral balance of the user. The liquidator can thus liquidate the violator, incurring their full ~310,93m eDAI balance but only a portion of their dDAI balance, further exacerbated by the liquidation discount of Euler Finance⁵.

As the maximum discount will be applied to this position due to how low its health level is, the liquidator will incur a ~310,93m eDAI balance with a conversion rate of 1.25 eDAI tokens per dDAI. This will ultimately evaluate to a post-fee ~259,31m dDAI balance.

liquidator Contract:

• Liquidate the position, acquiring ~310,93m eDAI tokens and ~259,31m dDAI tokens
• Withdraw the full reserve of DAI tokens by burning the corresponding eDAI tokens

At the withdrawal step, the eDAI to DAI exchange rate honored by EToken is skewed as the exchange rate calculated¹⁰ factors in the total borrows of the system which are artificially increased by the liquidation’s repayExtra value.

As such, an exchange rate of roughly 0,97 eDAI per DAI is utilized for the redemption. As the user is already “above-water” due to the maximum 20% liquidation discount that was applied during their liquidation, they are able to “burn” the ~38m eDAI required to release the ~38.9m DAI held by the contract.

Ultimately, the attacker was able to retain the following assets post-execution of their transaction:

• +~8,877,507 DAI = ~8,779,854.423 USD

The contracts the attacker utilized also possess non-zero eDAI and dDAI balances with a health factor of ~1.05 for the liquidator contract in particular. As such, users should avoid re-depositing DAI tokens to the EToken as they may still be vulnerable.

We can assess the financial impact of the DAI asset and calculate an estimated profit of roughly ~8,779,854.423 USD as of 2023-03-13 12:42:00 UTC.

The attack has been replicated to multiple other assets. As such, the deposit warning applies to the following EToken assets: DAI, WETH

Security Audit

Omniscia has performed multiple security audits of the Euler Finance protocol. The changes in question, however, were introduced in eIP-14. As evidenced in the message board itself, Omniscia performed an audit of only the Chainlink integration component that is publicly available here.

The EToken::donateToReserve feature that is at the crux of this vulnerability was not in scope of any audit conducted by Omniscia. As such, the code that causes the vulnerability was never in scope of any audit conducted by our team.

The donateToReserves function was audited by the Sherlock team in July 2022. Euler Finance and Sherlock have confirmed that Euler had an active coverage policy with Sherlock at the time of exploit.

Conclusion

The attack ultimately arose from an incorrect donation mechanism and did not account for the donator’s debt health, permitting them to create an unbacked DToken debt that will never be liquidated.

Sources

1. Euler Improvement Proposal 14: https://forum.euler.finance/t/eip-14-contract-upgrades/305
2. Euler Improvement Proposal 14 Delta: https://euler-xyz.github.io/euler-contracts-upgrade-diffs/eip14/EToken.html
3. Euler Liquidator Collateral Default Logic: https://github.com/euler-xyz/euler-contracts/blob/fa9398728165676a5666939d8c34a7578d8e1919/contracts/modules/Liquidation.sol#L139-L151
4. Euler EToken Faulty Donation Mechanism: https://github.com/euler-xyz/euler-contracts/blob/fa9398728165676a5666939d8c34a7578d8e1919/contracts/modules/EToken.sol#L356-L386
5. Euler Liquidation Discount: https://docs.euler.finance/euler-protocol/eulers-default-parameters#maximum-liquidation-discount
6. Etherscan Attack Transaction Link: https://etherscan.io/tx/0xc310a0affe2169d1f6feec1c63dbc7f7c62a887fa48795d327d4d2da2d6b111d
7. Etherscan Address of Primary Contract: https://etherscan.io/address/0xebc29199c817dc47ba12e3f86102564d640cbf99
8. Etherscan Address of Violator Contract: https://etherscan.io/address/0x583c21631c48d442b5c0e605d624f54a0b366c72
9. Etherscan Address of Liquidator Contract: https://etherscan.io/address/0xa0b3ee897f233f385e5d61086c32685257d4f12b
10. Euler BaseLogic Exchange Rate Calculation: https://github.com/euler-xyz/euler-contracts/blob/fa9398728165676a5666939d8c34a7578d8e1919/contracts/BaseLogic.sol#L292-L296

Omniscia.io is one of the fastest growing and most trusted blockchain security firms and has rapidly become a true market leader. To date, our team has collectively secured over $200+ billion worth of digital assets, worked with 260+ clients and detected over 1300+ high-severity issues in our clients’ smart contracts.

Founded at the start of 2021 by blockchain cybersecurity veterans, omniscia.io is a pioneer in Web3 security, utilizing years of experience, developing proprietary tooling and a tried-and-tested approach to securing smart contracts and complex decentralized protocols out there — including the likes Aave, YFI, lien, 1inch, fetch, compound, synthetix, and many others.

Our clients, partners and backers include leading ecosystem players such as L’Oréal, Polygon, AvaLabs, Morpho, Euler, CLabs, Olympus DAO, Fetch.ai, LimitBreak, and many more.

Be sure to follow our social medias and subscribe to our newsletter for more updates:

Twitter / LinkedIn / Newsletter

This article is meant to analyze the Platypus Finance incident that occurred on the 17th of February 2023 at approximately 19:16 UTC¹ in an impartial way and identify the root cause.

Vulnerability Analysis

The vulnerability that was exploited stems from incorrect integration between the PlatypusTreasure² ³ and the MasterPlatypusV4⁴ ⁵contracts of the Platypus Finance ecosystem and namely an improper logical check being present in the MasterPlatypusV4 contract.

The PlatypusTreasure contract was recently launched⁶ ⁷ to support the USP stablecoin of Platypus Finance. The contract contains a mechanism that allows borrowing the USP stablecoin with assets that are presently staked in the IMasterPlatypus implementation referenced by the collateral settings of an LP asset (PlatypusTreasure::_getCollateralAmount).

While this by itself is not a vulnerable feature, the problem arises in how the outdated MasterPlatypusV4 implementation integrates with the an IPlatypusTreasure contract. The MasterPlatypusV4 contract implementation that was referenced by the proxy at the time of the attack was deployed on the 14th of November, 2022⁸, and contained a fatal misconception in its emergencyWithdraw mechanism.

The contract was built with the integration of IPlatypusTreasure at a later point as evidenced by its platypusTreasure member and its optionality in the codebase. Within the withdrawal workflows of the MasterPlatypusV4 contract, the IPlatypusTreasure::isSolvent function is invoked to perform a debt solvency evaluation.

Core Problem

The MasterPlatypusV4::emergencyWithdraw function performs its solvency check before updating the LP tokens associated with the stake position. As a result, it is possible for a user to withdraw their funds while they are being utilized as collateral for a debt position in PlatypusTreasure as the solvency check will succeed in all circumstances.

The MasterPlatypusV4::withdraw function is not susceptible to the same attack vector as it performs a solvency check after the stake position has been updated, ensuring that the PlatypusTreasure::isSolvent function takes into account the stake position with reduced LP tokens.

The issue could have been prevented by re-ordering the MasterPlatypusV4::emergencyWithdraw statements and performing the solvency check after the user’s amount entry has been set to 0 which would have prohibited the attack from taking place.

Alternatively, the MasterPlatypusV4::emergencyWithdraw could utilize the debtAmount variable yielded by PlatypusTreasure::isSolvent and ensured that it is 0, preventing emergency withdrawals with active debt positions.

Attack Scenario

Given that it is possible to provide collateral for a debt and proceed to withdraw it without repaying the debt, the exploiter is able to create what is known as “bad debt” in the system and acquire the debt’s upside.

The attack was executed in a single transaction which was submitted at approximately 2023–02–17 19:16:54 UTC¹ in which they performed the following:

• Acquired a 44,000,000 USDC loan off the Aave V3 protocol
• Deposited the same amount of USDC in the Platypus Finance Pool to acquire the LP-USDC asset
• Deposited the newly created LP-USDC tokens to the MasterPlatypusV4 implementation
• Performed a borrow operation on the PlatypusTreasure contract of the maximum amount of USP they were able to borrow, which amounted to roughly ~41,794,533 units
• Performed an emergency withdrawal of the LP-USDC assets they had deposited in the MasterPlatypusV4 implementation, thereby causing their debt to become “bad” as it becomes no longer serviceable
• Withdrew all USDC funds associated with the LP-USDC position they had created in the second step, acquiring ~43,999,999 USDC in return
• Performed liquidation of 9,250,000 USP tokens in numerous currencies via the Platypus Finance Pool

Interestingly, the attacker’s contract performed multiple staticcall operations to the 0x000000000000000000636F6e736F6c652e6c6f67 address during the transaction’s execution. This address is in fact the “console” address in use by the hardhat toolkit⁹, indicating that the attacker used the hardhat toolkit to produce their contract.

The attacker did not liquidate the full ~41,794,533 amount of USP tokens they acquired, instead opting for smaller trades presumably due to insufficient liquidity in the USP pools they utilized. In detail, the transaction performed the following swaps before repaying the flash-loan:

• Exchange 2,500,000 USP for ~2,425,762 USDC
• Exchange 2,500,000 USP for ~1,946,900 USDC.e (Bridged USDC)
• Exchange 1,600,00 USP for ~1,552,550 USDT
• Exchange 1,250,00 USP for ~1,217,581 USDT.e (Bridged USDT)
• Exchange 700,000 USP for ~687,369 BUSD
• Exchange 700,000 USP for ~691,984 DAI.e (Bridged DAI)

Ultimately, the attacker was able to retain the following assets post-execution:

• +~2,425,762 USDC = ~2,427,390 USD @ 1.00067117
• +~1,946,900 USDC.e = ~1,948,206 USD @ 1.00067117
• +~1,552,550 USDT = ~1,553,651 USD @ 1.00070943
• +~1,217,581 USDT.e = ~1,219,725 USD @ 1.00176158
• +~687,369 BUSD = ~688,527 USD @ 1.00168506
• +~691,984 DAI.e = ~692,355 USD @ 1.00053726
• +~33,044,533 USP = Indeterminate Evaluation

As the value of the USP asset is no longer considered canonical, we can assess the financial impact of the stablecoin assets it was liquidated to and sum a total estimated profit of roughly ~8,529,854 USD as of 2023-02-17 15:20:00 UTC.

Security Audit

Omniscia performed two security audits of the Platypus Finance platform simultaneously on November 21st, 2021 with a conclusion date of December 5th, 2021 and a final delivery date of December 24th, 2021. The publicly available audits¹⁰ ¹¹ did not cover the USP stablecoin or the PlatypusTreasure implementation.

While the MasterPlatypus implementation was in scope in the “governance” audit of the protocol, we performed an audit of the V1 implementation which contained no integration points with an external platypusTreasure system.

The Platypus Finance protocol has introduced numerous updates since the time the audit was finalized, including all contracts involved in the vulnerability (MasterPlatypusV4, USP, and PlatypusTreasure). These contracts were never in scope of any audit conducted by us and thus are considered to be unaudited code by our team.

Conclusion

The attack ultimately arose from improper integration of the MasterPlatypusV4 contract with PlatypusTreasure and did not perform its solvency check in the correct order, enabling collateral to be withdrawn with an active debt. As a result, “bad debt” could be created in the system at the expense of the protocol’s USP token which was then exchanged for multiple stablecoins.

Sources

1. Snowtrace Transaction of the Attack: https://snowtrace.io/tx/0x1266a937c2ccd970e5d7929021eed3ec593a95c68a99b4920c2efa226679b430
2. Snowtrace Address of the PlatypusTreasure Contract’s Proxy: https://snowtrace.io/address/0x061da45081ace6ce1622b9787b68aa7033621438
3. Snowtrace Address of the PlatypusTreasure Contract: https://snowtrace.io/address/0xbcd6796177ab8071f6a9ba2c3e2e0301ee91bef5
4. Snowtrace Address of the MasterPlatypusV4 Contract’s Proxy: https://snowtrace.io/address/0xff6934aac9c94e1c39358d4fdcf70aeca77d0ab0
5. Snowtrace Address of the MasterPlatypusV4 Contract: https://snowtrace.io/address/0xc007f27b757a782c833c568f5851ae1dfe0e6ec7
6. Snowtrace Transaction of the PlatypusTreasure Contract’s Proxy Deployment: https://snowtrace.io/tx/0x326d5c2e0ebb68c5f267b1f2fb654729ef5bb2bcaf09a5adea382e206b17315d
7. Snowtrace Transaction of the USP Minter Set to PlatypusTreasure’s Proxy: https://snowtrace.io/tx/0x535ee1baa8688a5fb23c4b7d84aae65081e2663a783eb58357661e85c613d01b
8. Snowtrace Transaction of the MasterPlatypusV4 Contract’s Deployment: https://snowtrace.io/tx/0x0723124dfd5abdeafbfeab072a02610c868a7b7b32f641aa50fc157eca636d7d
9. Hardhat console.sol Address: https://github.com/NomicFoundation/hardhat/blob/hardhat@2.12.7/packages/hardhat-core/console.sol#L5
10. Omniscia Security Audit of Platypus Finance’s Core: https://omniscia.io/platypus-finance-core-implementation/
11. Omniscia Security Audit of Platypus Finance’s Governance: https://omniscia.io/platypus-finance-governance-staking/

Omniscia.io is one of the fastest growing and most trusted blockchain security firms and has rapidly become a true market leader. To date, our team has collectively secured over $200+ billion worth of digital assets, worked with 220+ clients and detected over 1000+ high-severity issues in our clients’ smart contracts.

Founded at the start of 2021 by blockchain cybersecurity veterans, omniscia.io is a pioneer in Web3 security, utilizing years of experience, developing proprietary tooling and a tried-and-tested approach to securing smart contracts and complex decentralized protocols out there — including the likes Aave, YFI, lien, 1inch, fetch, compound, synthetix, and many others.

Our clients, partners and backers include leading ecosystem players such as L’Oréal, Polygon, AvaLabs, Morpho, Euler, CLabs, Olympus DAO, LimitBreak, Fetch.ai and many more.

Be sure to follow our social medias and subscribe to our newsletter for more updates:

Twitter / LinkedIn / Newsletter

This article is meant to analyze the Bonq Protocol incident that occurred on the 1st of February at approximately 6.32pm UTC in an impartial way and identify the root cause.

Vulnerability Analysis

The vulnerability that was exploited stems from how the Bonq Protocol has integrated their WALBT / BEUR trove with price oracles which are used to assess what the “true” price of the WALBT asset is.

In detail, the troves that were exploited utilized a ConvertedPriceFeed smart contract¹ to assess the price of the WALBT token against the price of real-world euro (EUR), meant to be represented in a one-to-one manner by Bonq’s euro stablecoin.

To achieve this, the ConvertedPriceFeed fetches the USD-denominated price of the WALBT asset from a custom Tellor Price Feed² and divides it by the USD-denominated price of EUR from a custom Chainlink feed³, accommodating for decimals via a DECIMAL_PRECISION constant used in a multiplication before the division.

The end result of the ConvertedPriceFeed::price() function is the value of WALBT denominated in euros and is used in multiple trove calculations of the Bonq Protocol to assess the health of a trove and whether it should be liquidated.

Core Problem

The TellorPriceFeed built by Bonq to take advantage of the TellorFlex oracle system⁴ has been integrated incorrectly as it immediately consumes the latest data point reported to the TellorFlex oracle via the TellorFlex::getCurrentValue function.

The Tellor trustless oracle system works by incentivizing users to discredit improper data measurements by invoking functions on the TellorFlex contract that permit them to slash the TRB assets that the malicious party had staked to submit their incorrect data point.

As time needs to pass between a false data point’s submission to the Tellor network and its detection and consequent discreditment by an honest party, data points from Tellor oracles must be consumed after a sufficient dispute window has passed.

Attack Scenario

This pre-condition was not satisfied in the TellorPriceFeed implementation which made use of the TellorFlex::getCurrentValue function which yields the latest reported value of the oracle. As a result, the hacker was able to exploit this by submitting a false price to the TellorFlex oracle and forfeiting their 10 TRB tokens in the process.

As the value of the exploit greatly outweighed the value of the 10 TRB tokens that would be slashed, the end result of the attack was a significantly high profit for the attacker. The attack occurred in two separate transactions to maximize the profit of the attacker.

First, they submitted a transaction at approximately 2023–02–01 06:29:18 UTC in which they performed the following:

• Staked 10 TRB units on the TellorFlex oracle
• Reported a false price of exactly 5.000.000 USD per WALBT token, significantly overvaluing the token
• Created a Trove of the WALBT asset
• Transferred 0.1 WALBT tokens to the Trove⁵
• Recorded the newly submitted collateral of the Trove
• Borrowed a total of 100.000.000 BEUR tokens
• Created another Trove of the WALBT asset
• Transferred ~13.25973256272339977 WALBT tokens to the second Trove⁶
• Recorded the newly submitted collateral of the second Trove

Interestingly, the attacker did not borrow more BEUR tokens from the second Trove they created. The reason they created two different Troves under opposite circumstances was a requirement for their attack as this setup ensured that TroveFactory::firstTrove() and TroveFactory::lastTrove() would yield the attacker’s Troves.

The Troves are ordered by their collateralization ratio, permitting the attacker to “manipulate” the internal ordering of the Troves within the TroveFactory as they see fit. This was a crucial step for the next transaction to succeed.

In their second transaction submitted at approximately 2023–02–01 06:31:06 UTC, the following sequence of events transpired:

• Staked 10 TRB units on the TellorFlex oracle using an alternative address (presumably to avoid being prohibited from a second submission)
• Reported a false price of exactly 0.0000001 USD per WALBT token, significantly undervaluing the token
• Queried all Troves of the WALBT token in sequence using the firstTrove, lastTrove, and nextTrove mechanisms of the TroveFactory proxied via BonqProxy
• For each trove:
  – Evaluated whether the WALBT asset is associated with the Trove via containsTrove
  – Evaluated whether the Trove has a non-zero debt via Trove::debt(), invoking Trove::liquidate() in such a case
• Once no more Troves remained, the hacker proceeded to invoke Trove::repay() on the second Trove they opened in the first transaction with the maximum of uint256⁷to ensure their debt repayment will succeed regardless of the underlying debt
• The Trove ultimately extracted a total of ~1.341.461 BEUR tokens from the hacker to repay the debt, rendering the Trove empty of any debt
• As a final action, the hacker invoked Trove::decreaseCollateral() with an amount of roughly ~113.813.998 WALBT tokens

The hacker did not iterate through the 0x4248FD3E2c055a02117eB13De4276170003ca295 and 0x5343c5d0af82b89DF164A9e829A7102c4edB5402 Troves they opened in their first transaction as they did not wish to liquidate them.

As the debt of a particular CommunityLiquidationPool is “shared” in that it carries over to the next trove that claims it via CommunityLiquidationPool::claimCollateralAndDebt performed within a Trove’s liquidate() -> _updateCollateral() -> getLiquidationRewards() call-chain, the attacker wished to accumulate all the debt of the liquidated Troves to their own Trove #2 created in the first transaction.

This permitted them to Trove.repay() the remaining debt associated with the liquidated troves and extract the ~113.813.998 WALBT tokens that were ultimately liquidated throughout the iterative process explained above.

Ultimately, the attacker was able to retain the following assets post-execution of both transactions:

• +~113.813.998 WALBT = ~4,552,559.92 USD
• +~98.658.539 BEUR = Indeterminate Evaluation
• -20 TRB = ~358.2 USD

As the value of the BEUR asset is no longer considered canonical, we can assess the financial impact of the WALBT and TRB assets and sum a total estimated profit of roughly ~4,552,201.92 USD as of 2023-02-01 15:27:00 UTC.

Security Audit

Omniscia performed a security audit of the Bonq Protocol on August 15th, 2022 with a conclusion date of August 30th, 2022 and a final delivery date of October 12th, 2022. The publicly available audit⁸ highlighted multiple issues with the oracle system they wished to implement at the time.

The formal response by the Bonq Protocol team was that they need to re-visit their approach with regards to the pricing oracles and that they will not move forward with the implementations audited at the time, opting to integrate Chainlink oracles in the future.

The Bonq Protocol has introduced numerous updates since the time the audit was finalized, including all contracts involved in the vulnerability (ConvertedPriceFeed, ChainlinkPriceFeed, and TellorPriceFeed). These contracts were never in scope of any audit conducted by the Omniscia team and thus are considered to be unaudited code.

Conclusion

The attack ultimately arised from improper integration of the Tellor oracle system and did not account for how the system dynamics of the Tellor system mandate a time delay before a data point is considered safe to use.

Sources

1. Polygon Address of WALBT / BEUR Conversion Oracle: https://polygonscan.com/address/0x7D4c36c79b89E1f3eA63A38C1DdB16EF8c394bc8
2. Polygon Address of Bonq’s WALBT Tellor Price Feed: https://polygonscan.com/address/0xa1620af6138d2754f7250299dc9024563bd1a5d6
3. Polygon Address of Bonq’s BEUR Chainlink Feed: https://polygonscan.com/address/0x96923e13b9e7C4eB853D9c37ee32E2293eE872B8
4. Polygon Address of WALBT / USD Tellor Price Feed: https://polygonscan.com/address/0x8f55d884cad66b79e1a131f6bcb0e66f4fd84d5b
5. Polygon Address of WALBT Trove #1: https://polygonscan.com/address/0x4248FD3E2c055a02117eB13De4276170003ca295
6. Polygon Address of WALBT Trove #2: https://polygonscan.com/address/0x5343c5d0af82b89DF164A9e829A7102c4edB5402
7. Maximum of uint256 in Solidity (usually expressed as type(uint256).max): 115792089237316195423570985008687907853269984665640564039457584007913129639935
8. Omniscia Audit of Bonq Protocol (August 2022): https://omniscia.io/reports/bonq-borrowing-protocol/

Follow us on twitter — https://twitter.com/Omniscia_sec

Il existe de nombreuses manières d’effectuer des cyberattaques dans le web3. Au cours des dernières des années, les cyberattaques se sont multipliées, octobre 2022 a été un record en termes de montants dérobés avec un total de 760 millions de dollars.

Voici les cyberattaques les plus courantes dans le web3 :

Advanced Persistent Threat ou menace persistante avancée

L’APT est une approche d’attaque par laquelle une équipe d’exploitants établit une présence illicite et durable sur un réseau. Elle est généralement exécutée par un groupe de criminels bien organisé. Ils utilisent des applications pour cibler l’infrastructure des sociétés cryptos ou des applications malveillantes pour voler des clés privées afin d’exécuter des attaques ultérieures. Parfois, ils attaquent même les employés de l’entreprise avec des campagnes de phishing utilisant des logiciels malveillants.

Supply chain vulnerabilities ou attaque contre la vulnérabilité du système

Dans la plupart des cas, les projets Web3 nécessitent différentes bibliothèques logicielles tierces. Comme ces codes sont développés par des équipes externes, il est très probable que des problèmes connus soient négligés. Il est essentiel que les équipes de développement surveillent les vulnérabilités potentielles de ces composants logiciels tiers, s’assurent que les mises à niveau sont installées et suivent les mises à jour des projets dont elles dépendent.

Attaques de gouvernance

De nombreux projets Web3 comportent un volet de gouvernance permettant à leurs détenteurs de jetons de participer aux décisions relatives au réseau. Cela ouvre également une porte dérobée aux mauvais acteurs pour faire avancer des propositions malveillantes susceptibles d’endommager l’ensemble du réseau.

Les attaques contre la gouvernance se sont multipliées récemment. Les attaquants contractent d’énormes “flash-loan” pour faire basculer les votes. Grâce à cette participation, l’attaquant peut approuver l’exécution d’un code qui a transféré des actifs vers son propre portefeuille. L’attaquant a ensuite juste à rembourser instantanément le “flash-loan” avec son bénéfice.

Attaques de manipulation des prix

Dans le monde des cryptomonnaies, la volatilité du marché n’a rien de nouveau et les fluctuations soudaines des prix sont courantes. Les projets Web3 utilisent généralement des oracles pour obtenir des données sur la chaîne. Les attaquants ont trouvé des moyens de tromper les oracles et de provoquer de grands pics de prix qui deviennent rentables lorsqu’ils sont bien joués par les mauvais acteurs.

Comment renforcer la sécurité de vos smart contracts

Chez Omniscia, nous proposons des solutions à mettre en place en amont pour éviter que toutes ces attaques ne se produisent. Pour ce qui concerne les APT et les attaques contre la vulnérabilité des systèmes, nous effectuons un test de pénétration où nous simulons des attaques sur un système pour éprouver sa sécurité et identifier ses vulnérabilités. Dans le cas des attaques de gouvernance et des attaques de manipulation des prix nos services d’audit de smart-contracts et d’analyse de tokenomics permettent d’éviter tous les risques possibles.

Même si souvent, aucun smart-contract n’est piraté et que le post-mortem montre des techniques intelligentes de manipulation des prix ou des failles dans la gouvernance, l’audit de smart-contract est une étape nécessaire à tout projet qui veut accueillir de la liquidité au sein de son protocole.

Omniscia.io est l’une des sociétés de sécurité blockchain les plus fiables et dont la croissance ne cesse d’augmenter et nous sommes rapidement devenus un véritable leader du marché.

En quelques chiffres, notre équipe a collectivement sécurisé plus de 200 milliards de dollars d’actifs numériques, travaillé avec 220+ clients et détecté plus de 1000 problèmes de haute gravité dans les smart-contracts de nos clients.

Fondée au début de l’année 2021 par des vétérans en cybersécurité blockchain, utilisant des années d’expérience, développant des outils propriétaires et une approche testée et approuvée pour sécuriser les smart-contracts et les protocoles décentralisés complexes existants — y compris ceux de Aave, YFI, 1inch, fetch, compound, synthetix, et bien d’autres.

Parmi nos clients, partenaires et bailleurs de fonds figurent des acteurs majeurs de l’écosystème tels que Polygon, AvaLabs, Morpho, Euler, CLabs, Olympus DAO, Fetch.ai, allianceBlock, Boson Protocol, et bien d’autres.

Surtout, n’oubliez pas de suivre nos médias sociaux et de vous abonner à notre newsletter être au courant des dernières mises à jour :

Twitter / LinkedIn / Newsletter

Source: a16z.com

Un audit de smart-contract est un examen poussé au niveau du code informatique interne aux contrats intelligents. Il se concentre sur la robustesse des smart-contracts et des potentielles failles se trouvant dans le code de ceux-ci afin d‘améliorer leur sécurité.

Dans le cas d’Omniscia, nous ne nous contentons pas seulement de vérifier la sécurité et la véracité des contrats. Nous vérifions aussi leur efficience pour leur tâche à effectuer ainsi que leur optimisation.

Effectivement, pour qu’ils puissent fonctionner, les smart-contracts impliquent des séries de transactions compliquées entraînant des frais de Gas. En ce sens, une optimisation du code permettra de réduire et de limiter certaines étapes déclenchant ainsi une baisse des frais de gas sur un contrat.

Cette optimisation permet parfois de faire économiser beaucoup d’argent étant donné les coûts de gas de certains réseaux peu scalables comme Ethereum. De surcroît, les étapes inutiles sur un smart-contrat augmentent aussi considérablement les risques d’exploit, alors autant les éviter.

De surcroît, nous nous occupons également de tester la fiabilité des API utilisées pour interagir avec les applications décentralisées. Parfois même du réseau sur lequel les contrats sont hébergés pour éviter toute forme de vulnérabilité face aux attaques par déni de service (DDoS).

Pour la communauté crypto, les audits représentent une assurance de la confiance et du sérieux des équipes. Cette confiance est nécessaire à la poursuite de ces projets afin de gagner la confiance de la communauté crypto.

Cependant, certaines failles sont toujours détectées même après avoir effectué plusieurs audits. Aucun système informatique ne peut être fiable à 100 %. C’est pourquoi il est important de faire preuve de prudence et de procéder à des audits régulièrement.

Contrairement à nos concurrents, nos rapports sont “web-based” et ont été conçus par des ingénieurs pour des ingénieurs. Ils comportent donc des fonctionnalités qui permettent à nos clients d‘être plus flexibles face aux problèmes que nos ingénieurs découvrent.

Omniscia.io est l’une des sociétés de sécurité blockchain les plus fiables, dont la croissance ne cesse d’augmenter. Nous sommes rapidement devenus un véritable leader du marché des audits de smart-contract.

En quelques chiffres, notre équipe a collectivement sécurisé plus de 200 milliards de dollars d’actifs numériques, travaillé avec 220+ clients et détecté plus de 1000 problèmes de haute gravité dans les smart-contracts de nos clients.

Fondée au début de l’année 2021 par des vétérans en cybersécurité blockchain, utilisant des années d’expérience, développant des outils propriétaires et une approche testée et approuvée pour auditer les smart-contracts et les protocoles décentralisés complexes existants — y compris ceux de Aave, YFI, 1inch, fetch, compound, synthetix, et bien d’autres.

Parmi nos clients, partenaires et bailleurs de fonds figurent des acteurs majeurs de l’écosystème tels que Polygon, AvaLabs, Morpho, Euler, CLabs, Olympus DAO, Fetch.ai, allianceBlock, Boson Protocol, et bien d’autres.

Surtout, n’oubliez pas de suivre nos médias sociaux et de vous abonner à notre newsletter pour plus de mises à jour :

Twitter / LinkedIn / Newsletter

26 milliards de dollars. C’est ce que les protocoles de finances décentralisés (DeFi) ont perdu à ce jour, et vu les différents risques de sécurité dans le Web3 ce chiffre ne semble pas près à ralentir sa croissance.

Dans le Web3, la valeur est intégrée au Web lui-même sous la forme de cryptomonnaies. C’est une opportunité en or pour les cybercriminels de monétiser leurs attaques. Ce chiffre, bien qu’impressionnant, ne reflète pas toutes les pertes associées aux risques de sécurité dans le web3, car la diversité de leurs menaces s’étend bien au-delà de DeFi.

Voici donc les différents risques liés à la sécurité dans le web3 :

Clés privées compromises :

Les wallets de cryptomonnaies des investisseurs sont piratés tous les jours. De nombreuses pertes proviennent de clés privées compromises qui peuvent être divulguées ou volées de différentes manières.

Cela se produit en raison de pratiques de génération de clés faible. Comment ? Les clés privées peu complexes sont faciles à deviner, et les mauvais acteurs peuvent facilement en prendre le contrôle.

La perte ou le vol de la phrase d’amorçage:

Tous les utilisateurs de cryptomonnaies savent qu’une phrase de démarrage est une clé qui donne accès à tous les actifs cryptographiques d’un portefeuille. Pourtant, ces derniers temps, un grand nombre de piratages ont impliqué l’exposition accidentelle ou le vol de la phrase de démarrage.

Front running et attaques sandwich:

En raison du mode de fonctionnement de la blockchain, les transactions ne sont pas ajoutées instantanément au grand livre distribué. Au lieu de cela, elles sont stockées dans des « mempools » publics avant d’être ajoutées aux blocs.

Le temps qui s’écoule entre l’initiation d’une transaction et son inclusion dans le bloc est une occasion pour les cybercriminels d’effectuer des attaques par anticipation.

Les acteurs malveillants recherchent des transactions qui peuvent être compromises en utilisant la valeur extractible par le mineur ou « Miner Extractable Value » (MEV). Les attaquants créent alors leur propre transaction avec un frais de gas plus élevé pour la placer avant la transaction originale. Ainsi, ils peuvent s’emparer de certains bénéfices.

Attaques à 51 :

Les attaques à 51 % constituent l’un des types d’attaques les plus courants au sein du web3.

Elles sont plus fréquentes chez des protocoles PoW, en raison de leurs algorithmes de consensus, où les mineurs utilisent leur puissance de calcul pour voter.

Pour réaliser une attaque à 51 %, les exploitants prennent le contrôle d’une part importante de la puissance de calcul d’une blockchain.

En conséquence, le réseau de la blockchain est corrompu, ce qui permet aux attaquants de traiter les transactions plus rapidement que le mineur. Les attaquants peuvent arrêter la confirmation et l’ordre des nouvelles transactions, et réécrire le contenu du grand livre distribué qu’est la blockchain.

Rug Pulls :

Alors que de nombreuses attaques proviennent principalement de menaces externes, les rug pulls sont des attaques internes, émergeant des propriétaires et des développeurs de la Dapp. Le “rug pull” est un type d’escroquerie relativement nouveau. Son nom vient de l’expression “tirer le tapis”.

Elle fonctionne de la manière suivante : un développeur attire les investisseurs vers un nouveau projet crypto, puis retire les fonds des utilisateurs avant que le projet ne soit construit ou via une faille cachée au sein du code.

Se protéger contre les hacks:

Nous pensons qu’il est de la responsabilité de chaque utilisateur web3 de réfléchir à ses options de protection individuelle. Et chez Omniscia, il est de notre responsabilité, de vous fournir des rapports d’audit de hauts standards afin de faire du web3 un endroit plus sûr.

Omniscia.io est l’une des sociétés de sécurité blockchain les plus fiables et dont la croissance ne cesse d’augmenter et nous sommes rapidement devenus un véritable leader du marché.

En quelques chiffres, notre équipe a collectivement sécurisé plus de 200 milliards de dollars d’actifs numériques, travaillé avec 220+ clients et détecté plus de 1000 problèmes de haute gravité dans les smart-contracts de nos clients.

Fondée au début de l’année 2021 par des vétérans en cybersécurité blockchain, utilisant des années d’expérience, développant des outils propriétaires et une approche testée et approuvée pour sécuriser les smart-contracts et les protocoles décentralisés complexes existants — y compris ceux de Aave, YFI, 1inch, fetch, compound, synthetix, et bien d’autres.

Parmi nos clients, partenaires et bailleurs de fonds figurent des acteurs majeurs de l’écosystème tels que Polygon, AvaLabs, Morpho, Euler, CLabs, Olympus DAO, Fetch.ai, AllianceBlock, Boson Protocol, et bien d’autres.

Surtout, n’oubliez pas de suivre nos médias sociaux et de vous abonner à notre newsletter pour plus de mises à jour :

Twitter / LinkedIn / Newsletter

Les cyberattaques dans la DeFi ne sont pas nouvelles. Tous ceux qui s’intéressent aux cryptomonnaies et à la DeFi ne savent que trop bien qu’ils sont désormais des cibles populaires pour les acteurs malveillants. Dans cet article, nous souhaitons donner un aperçu de l’état de la cybersécurité dans la finance décentralisée et de ce qui peut être fait pour l’améliorer.

Les pirates profitent des vulnérabilités, des erreurs de logique et des failles de programmation dans l’architecture du code des projets ainsi que du lancement de campagnes de phishing pour voler des fonds numériques directement aux utilisateurs DeFi.

Cible principale : les projets DeFi

Les protocoles décentralisés sont sans aucun doute la première cible de cyberattaques dans la DeFi, car les récompenses sont énormes.

Les hackers poursuivent les projets sans relâche, ils étudient leurs codes, gardent un œil sur les nouvelles mises à jour et fonctionnalités et finissent par trouver une faille qui leur permet de s’introduire dans le système.

Le risque de perdre des fonds peut provenir des vulnérabilités des smart-contracts, des défauts de protocole et de sa conception, des fuites de clés, des hacks « frontend », de l’arbitrage, etc. Parfois, une erreur de code mineure dans les contrats intelligents peut provoquer un désastre et entraîner la compromission d’actifs valorisés plusieurs millions.

Cible constante : les utilisateurs DeFi

Les cybercriminels ne ciblent pas seulement les protocoles, ils ciblent également les portefeuilles numériques des utilisateurs.

Compte tenu de l’évolution constante des cyberattaques dans la DeFi, il est tout simplement impossible pour un investisseur DeFi d’être au courant de toutes les menaces. Pourtant, il est indispensable que chacun soit conscient de toutes ses actions dans le monde de la blockchain et de l’importance de renforcer sa cybersécurité personnelle. Vos actifs numériques nécessitent une sécurité fiable.

Les pirates peuvent voler des cryptomonnaies de diverses manières, qu’il s’agisse de tenter de s’approprier votre mot de passe, de vous inciter à révéler des informations par des tentatives d’hameçonnage (phishing) ou d’autres méthodes.

La protection : le maître mot

Avec autant de menaces qui nous visent, que faut-il faire ?

Pour l’instant, les développeurs DeFi semblent rechercher l’innovation dans leurs algorithmes plus que la protection. Mais avec une attaque à grande échelle faisant surface dans les projets DeFi, les équipes doivent s’assurer que des outils et des précautions efficaces sont en place pour protéger tous les actifs.

Cependant, pour un utilisateur individuel, nous avons ce conseil : n’accordez aucune confiance à un projet avant qu’il n’est prouvé sa fiabilité et même lorsque c’est le cas, il faut toujours rester prudent. Lorsque vous utilisez la DeFi, ayez toujours la sécurité à l’esprit.

Conclusion:

L’équipe d’Omniscia est sûre que la DeFi a un énorme potentiel, nous travaillons chaque jour dans le but de renforcer la protection individuelle et d’améliorer la sécurité de l’ensemble de l’industrie Web3 !

Omniscia.io est l’une des sociétés de sécurité blockchain les plus fiables et dont la croissance ne cesse d’augmenter et nous sommes rapidement devenus un véritable leader du marché.

En quelques chiffres, notre équipe a collectivement sécurisé plus de 200 milliards de dollars d’actifs numériques, travaillé avec 220+ clients et détecté plus de 1000 problèmes de haute gravité dans les smart-contracts de nos clients.

Fondée au début de l’année 2021 par des vétérans en cybersécurité blockchain, utilisant des années d’expérience, développant des outils propriétaires et une approche testée et approuvée pour sécuriser les smart-contracts et les protocoles décentralisés complexes existants — y compris ceux de Aave, YFI, 1inch, fetch, compound, synthetix, et bien d’autres.

Parmi nos clients, partenaires et bailleurs de fonds figurent des acteurs majeurs de l’écosystème tels que Polygon, AvaLabs, Morpho, Euler, CLabs, Olympus DAO, Fetch.ai, allianceBlock, Boson Protocol, et bien d’autres.

Surtout, n’oubliez pas de suivre nos médias sociaux et de vous abonner à notre newsletter pour plus de mises à jour : Twitter / LinkedIn / Newsletter

​This is part 4 of our continuing series delving deep into the internals of the EVM and how the Omniscia team regularly “exploits” peculiar traits of the EVM to minimize the execution cost of the smart contracts it audits. If you are not up to date on ‘The Optimizer’s Guide to Solidity’ series, we encourage you to check out part 1, part 2 and part 3 on our medium page.

Today we will discuss two types of optimizations which rely on how the EVM represents certain variable types and primitive function results under the hood. Both optimizations are simple to apply to any codebase and applicable to all production-ready versions of Solidity so no distinction needs to be made between them. In order to properly comprehend how these optimizations work, we first need to acknowledge a peculiar trait of the EVM.​

Solidity vs. EVM Data Types​

While Solidity presents us with multiple data types of varying binary precision (i.e. uint96 or address a.k.a. uint160), the EVM is fairly rudimentary in that it treats all data points as 32-bytes / 256-bits in length. Since the EVM has no knowledge of data types that are less than 256-bits, any sub-256-bit data type requires additional operations to be properly utilized. It is important to note that Arithmetic operations are especially expensive. For instance an addition between two uint96variables needs to overflow at type(uint96).max which will not happen at the EVM level and needs to be simulated via bitwise shifts (aka. padding / unpadding operations). As such, any variable that is declared as less than 256-bits will incur a non-negligible increase in gas cost wherever it is utilized.​

Optimal Data Types​

For projects to identify the optimal data type required by a given variable, one must first assess the actual storage needs of the said variable. Here are a few factors to take into consideration when evaluating storage needs:​

• Is the variable stored in the storage of the contract or is it simply an input argument for a given function?
• Does the project need to conform to the said data type because it integrates with external projects that expect it (i.e. Compound)?
• Is the variable part of a tight-packing code segment (i.e. contract-level variables in sequence or a struct declaration)?​

Generally, if the latter two queries do not apply then it is fair to assume that the variable type can be safely upcasted to uint256. We will use the following example of a Comp-like token compiled with a pragma version of 0.8.X and up (thus possessing safe arithmetics by default) to showcase how one can evaluate what data type to upcast:

In the above example, the Checkpoint struct contains properly defined data types as they are tight-packed into a single 32-byte storage slot. That said, the input argument of the transfer function, the Transfer event as well as the balanceOf mapping contain a uint96 variable which is suboptimal. To optimize such code blocks, one should only adjust the transfer and balance related data types:

​As observed above, we introduced an additional check to ensure that the amount variable can be safely cast to a uint224 data type as casting operations are not safely performed even with safe-arithmetics. The extra gas cost incurred by this check can be avoided entirely by instead evaluating the totalSupply of the system whenever tokens are minted and ensuring that it fits in a uint224. This would indirectly guarantee that no single balance can exceed the uint224 threshold.

​ABI Encoding System & Usage

​The ABI encoding mechanism contains two variations; the abi.encode and the abi.encodePacked functions. The former encodes the input argument(s) based on the ABI encoding standard whilst the packed variation attempts to minimize the total number of bytes utilized by the end-result bytes. Using the encodePacked function when the input arguments can be tightly packed into less than 256-bit slots makes sense. However, it is highly ineffective when the input arguments are 256-bits (or are packed in 256-bit slots regardless).

​The abi.encode-prefixed functions are usually utilized in conjunction with the keccak256 instruction meant to generate the hash of a particular set of variables. Another important trait of the EVM is that the keccak256 function operates on 256-bit inputs at a time. This means that a sub-256-bit input will incur the same gas cost to generate the hash than a 256-bit input. As a result, keccak256 operations should be optimally performed on bytes variables that have a length that is a multiple of 32.​

Let us take the following snippet as an example:

By assimilating all the information laid out above, we can deduce that the encodePacked function can be swapped with the encode variation without any operational change. Most importantly, the gas cost benefit incurred by this change will be significant since the logic of encodePacked would otherwise attempt to pack the two address arguments and fail, thus incurring additional gas in the process.

Optimized, the above snippet would turn into:

The above code is an excerpt of the Uniswap V2 ERC20 implementation that is used by its LP system. This is further evidence that mature bluechip projects in the Ethereum ecosystem are taking advantage of this optimization.​

Verdict

​Traditional developers tend to optimize their data types to minimize the memory and storage footprint of their applications. However, as illustrated in this article, the EVM expects all data to be in 256-bit sizes and it has no concern for memory restraints since they are guaranteed by the way the EVM’s stack system is defined. As a result, developers need to be extremely cautious when coding smart contracts that use sub-256-bit data types. Above all, they must ensure that this choice is for the benefit of the contract’s operational cost rather than an incorrectly assumed optimization of the contract’s memory / storage needs.

Be sure to check out our Optimizer’s Guide to Solidity series, where our team of security engineers outlines valuable tips and insights that address many of the challenges developers face when developing and deploying secure, scalable and optimized decentralized applications/smart contracts.

Omniscia.io is one of the fastest growing and most trusted blockchain security firms and has rapidly become a true market leader. To date, our team has collectively secured over $200+ billion worth of digital assets, worked with 220+ clients and detected over 1000+ high-severity issues in our clients’ smart contracts.

Founded at the start of 2021 by blockchain cybersecurity veterans, omniscia.io is a pioneer in Web3 security, utilizing years of experience, developing proprietary tooling and a tried-and-tested approach to securing smart contracts and complex decentralized protocols out there — including the likes Aave, YFI, lien, 1inch, fetch, compound, synthetix, and many others.

Our clients, partners and backers include leading ecosystem players such as Polygon, AvaLabs, Morpho, Euler, CLabs, Olympus DAO, Fetch.ai, Boson Protocol, and many more.

Be sure to follow our social medias and subscribe to our newsletter for more updates:

Twitter / LinkedIn / Newsletter

​Today we are diving deeper into the internal working of the Ethereum Virtual Machine (EVM) to illustrate how the Omniscia team regularly “exploits” peculiar traits of the EVM to minimize the execution cost of solidity smart contracts for its clients. In case you are not up to date on ‘The Optimizer’s Guide to Solidity’ series, you can find part one here and two here. In order to stay up to date with all the security tips and insights we share, be sure to subscribe to our newsletter where we will be publishing many tips and insights solidity developers can leverage to design and develop more secure and gas-efficient smart contracts.

This week we look at two different types of optimizations that are relatively simple to apply to any codebase and that are relevant to a majority of smart contracts we audit for our clients. The first optimization is applicable to all versions of Solidity. The second optimization discussed in this article is only valid for pragma versions 0.8.0 onwards. However, lets first clarify at a high level how one can assess the cost of any EVM instructions.

EVM Instruction Cost Assessment

​At the very core, the reasoning behind introducing “gas costs” to transactions and “gas limits” to assembled blocks on EVM blockchains is to 1) introduce an additional revenue stream to incentivize stakers (previously miners) to secure and validate the network and 2) act as a protection measure against Denial-of-Service (DoS) attacks by prohibiting the execution of computationally expensive tasks via the upper gas limit (e.g. for loops with significant limits that would otherwise delay the median block creation rate).​

To strike a balance between block builder compensation and a competitively priced computational system, EVM blockchains dynamically adjust their block gas limit based on the demand for bandwidth amongst network actors. Transactional gas costs are generally slow to evolve and revolve around a simplistic basis; the computational cost of performing a transaction. This may seem simple to perform within centralized and / or traditional computing environments. However, it differs greatly in blockchain ecosystems due to the way state changes of the blockchain ledger are propagated across the network of nodes that validate the instructions performed on a decentralized network.

In this article we illustrate how the hidden cost of memory can inflate the cost of otherwise straightforward transaction types on EVM blockchains, and how developers can optimize their dapps to reduce their gas footprint.​

EVM: Local Variable Hidden Cost

​When declaring a local variable that is the result of a statement, we incur a hidden gas cost proportional to the amount of “memory” needed for the local variable we declared. This extra cost is usually offset when reading variables from storage (SLOAD), storing them to a local variable (MSTORE plus hidden cost [A0–1](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) chapter of evm-opcodes), and reading them on each utilization (MLOAD).

This is not the case when dealing with primitive instructions of the EVM. Indeed, each transaction on a blockchain contains a set of unavoidable data. Consequently, sets of data are exposed to all smart contracts via primitive EVM instructions that consume very small amounts of gas. This is due to the fact that they do not require extra memory to read special data slots, as they are already loaded in-memory as part of the EVM’s block creation workflow.

The instruction set is significant and revolves around contextual data of a transaction, such as the msg.sender, block.timestamp, and more. As such, the following contract implementation is in fact inefficient:​

The Context contract is an implementation that was introduced by OpenZeppelin with the intention to streamline the development process of a contract that can be easily upgraded to a meta-transaction compatible one. However, thus far it has been mostly misused and has led to non-negligible gas increase for various protocols including both Aave V2 and Aave V3. To illustrate a tangible example of the IncentivizedERC20 implementation of Aave V3, we have provided a caption below:

​In the above function, we incur the _msgSender implementation’s msg.sender gas cost (CALLER: 2), and the _msgSender() invocation itself (JUMP: 2 as well as the memory allocation of the returned variable) twice. By optimizing the above segment, we can reduce the instructions’ gas cost by half:​

While the optimization by itself may be insignificant, it will lead to tangible savings when applied across the entire codebase.

​Solidity: Mathematical Hidden Cost​

Hidden gas costs are not only limited to the EVM. Developers need to be cognizant that the Solidity language itself has introduced some hidden costs in its latest minor semver 8, which enforces safe arithmetics by default. Given that a lot of applications already perform safety checks for unsafe arithmetic operations, as part of their error handling workflows, built-in safe arithmetic checks become superfluous and thus incur an increase in gas redundantly.

Thankfully, Solidity also introduced a new code-block declaration style that instructs the compiler to perform arithmetic operations unsafely: unchecked code blocks. These blocks can be cleverly utilized to significantly reduce the gas cost of a particular contract as long as the operation is guaranteed to be performed safely by surrounding statements and / or conditions. As an example, let’s take a look at this segment of the Compound CToken implementation’s _reduceReservesFresh function:

The totalReservesNew calculation and assignment are performed after the condition reduceAmount > totalReserves has been evaluated to false. This means that the trait totalReserves >= reduceAmount has been guaranteed by the execution context and as such the calculation of totalReservesNew can be performed in an unchecked code block as it is guaranteed to be performed properly. After optimization the above code block should resemble the caption below:​

Another way to avoid built-in safe arithmetics from incurring extra gas is during incrementation operations (++ and --). These operations are usually performed in for loops and in any post-0.8.X version. Each incrementation is performed with bound-checks when they are entirely redundant. A very simple example illustrating this is provided below:

Due to the inherent constraints of Solidity, bar.length is guaranteed to fit within a uint256 variable, meaning that performing a safe incrementation on each loop for the i variable would be redundant. To optimize such code blocks, we relocate the incrementation to the end of the unchecked code block:​

​Verdict​

The EVM is an intrinsically complex machine and as a consequence multiple tools have been developed to aid developers in creating solutions within its system using high-level languages (such as Solidity). The simplifications performed at the liberty of the Solidity compiler, however, are usually poorly relayed to the developer community and as such, programmers end up creating inefficient programs.

To counteract this, our Optimizer’s Guide to Solidity series outlines valuable tips and insights that address many of the challenges developers face when developing and deploying secure, scalable and optimized decentralized applications/smart contracts.

Omniscia.io is one of the fastest growing and most trusted blockchain security firms and has rapidly become a true market leader. To date, our team has collectively secured over $200+ billion worth of digital assets, worked with 220+ clients and detected over 1000+ high-severity issues in our clients’ smart contracts.

Founded at the start of 2021 by blockchain cybersecurity veterans, omniscia.io is a pioneer in Web3 security, utilizing years of experience, developing proprietary tooling and a tried-and-tested approach to securing smart contracts and complex decentralized protocols out there — including the likes Aave, YFI, lien, 1inch, fetch, compound, synthetix, and many others.

Our clients, partners and backers include leading ecosystem players such as Polygon, AvaLabs, CLabs, Olympus DAO, Fetch.ai, allianceBlock, Boson Protocol, and many more.

Be sure to follow our social medias and subscribe to our newsletter for more updates:

Twitter / LinkedIn / Newsletter