Smart Contracts

ERC-2771 integration introduces address spoofing vulnerability — OpenZeppelin

The smart contract vulnerability arises after the integration of ERC-2771 and multicall standards. OpenZepplin identified 13 sets of vulnerable smart contracts.

Soon after Thirdweb revealed a security vulnerability that could impact a variety of common smart contracts used across the Web3 ecosystem, OpenZeppelin identified two specific standards as the root cause of the threat.

On Dec. 4, Thirdweb reported a vulnerability in a commonly used open-source library, which could impact pre-built contracts, including DropERC20, ERC-721, ERC-1155 (all versions) and AirdropERC20.

James Edwards, the lead maintainer for cybersecurity investigator Librehash, said that while AI chatbots can develop smart contracts, deploying them in a live environment is risky.

Read more

Web3 firm detects major security flaw in common smart contracts

A security vulnerability potentially affecting hundreds of smart contracts that were pre-built using a commonly used open-source library has been reported by Web3 firm Thirdweb.

Smart contract development firm Thirdweb reported a security vulnerability that potentially “impacts a variety of smart contracts across the Web3 ecosystem.”

On Dec.

Highlighting the vulnerability’s potential to cause massive damage if not rectified immediately, Thirdweb stated:

“The impacted pre-built contracts include but are not limited to DropERC20, ERC721, ERC1155 (all versions), and AirdropERC20.”

Following the proactive warning to Web3 ecosystem, the firm cautioned users who deployed its contracts before Nov.

Thirdweb also advised developers to help users revoke approvals on all affected contracts using revoke.cash, “which will protect your users if you choose not to mitigate the contract,” DefiLlama developer “0xngmi” commented on the request to revoke approvals.

Thirdweb has contacted the maintainers of the open-source library at the root of the vulnerability and contacted other teams potentially impacted by the issue.

It also pledged to increase investment in security measures and double bug bounty payouts from $25,000 to $50,000 while implementing a more rigorous auditing process.

Read more

Polygon calls on EU lawmakers to address smart contracts in Data Act

The project claims that the bill, as currently written, could “substantially inhibit innovation and economic growth” in the EU.

Polygon Labs, the core company behind the development of Ethereum layer-2 scaling solution Polygon, has called on policymakers in the European Union to “clarify the scope and intent” of legislation targeting smart contracts.

In an open letter published to members of the European Parliament, the European Council and the European Commission on April 17, Polygon Labs proposed Article 30 under the Data Act be amended to apply to permissioned smart-contract-based-systems owned and operated by an “enterprise,” as opposed to permissionless under the current wording. The platform said hardware wallet developer Ledger had also signed up to request the legislation better reflect its intent.

“Polygon Labs has an interest in this matter because we seek to ensure the growth and responsible development of permissionless blockchain-based systems globally,” said the letter. “We respectfully request that you consider the proposed revisions to Art. 30 […] to ensure that this new law does not inadvertently capture open, transparent and permissionless parts of emerging blockchain technology.”

Article 30 in the version of the Data Act passed by the European Parliament in March detailed “essential requirements regarding smart contracts for data sharing.” Polygon Labs claimed that should the act pass without amendments to clarify the nature of parties — if any — operating smart contracts, the legislation “would not be enforceable for open, permissionless and decentralized smart contract applications and would substantially inhibit innovation and economic growth in the EU.”

Other experts have raised similar concerns with the Data Act potentially affecting the way regulators could handle smart contracts. Michael Lewellen, head of solutions architecture at OpenZeppelin, told Cointelegraph in March that the wording, which would allow for a “kill switch” of smart contracts, “undermines immutability guarantees and introduces a point of failure.”

Related: The future of smart contract adoption for enterprises

Polygon requested the Data Act “remain consistent” with the Markets in Crypto-Assets framework, scheduled for a final vote on April 19 after extensive negotiations between the European Parliament, the European Council and the European Commission. The Data Act will likely face similar treatment from EU policymakers before reaching the final form of the law, giving Polygon Labs’ request time for consideration.

Magazine: ZK-rollups are ‘the endgame’ for scaling blockchains: Polygon Miden founder

Euler Finance attack: How it happened, and what can be learned

The Euler Finance exploit was the largest of Q1 2023, and the risk of a similar attack on other protocols remains.

The March 13 flash loan attack against Euler Finance resulted in over $195 million in losses. It caused a contagion to spread through multiple decentralized finance (DeFi) protocols, and at least 11 protocols other than Euler suffered losses due to the attack.

Over the next 23 days, and to the great relief of many Euler users, the attacker returned all of the exploited funds.

But while the crypto community can celebrate the return of the funds, the question remains whether similar attacks may cause massive losses in the future.

An analysis of how the attack happened and whether developers and users can do anything to help prevent these kinds of attacks in the future may be helpful.

Luckily, Euler’s developer docs clearly explain how the protocol works, and the blockchain itself has preserved a complete record of the attack. 

How Euler Finance works

According to the protocol’s official docs, Euler is a lending platform similar to Compound or Aave. Users can deposit crypto and allow the protocol to lend it to others, or they can use a deposit as collateral to borrow crypto.

The value of a user’s collateral must always be more than what they borrow. Suppose a user’s collateral falls below a specific ratio of collateral value to debt value. In that case, the platform will allow them to be “liquidated,” meaning their collateral will be sold off to pay back their debts. The exact amount of collateral a user needs depends upon the asset being deposited vs. the asset being borrowed.

eTokens are assets, while dTokens are debts

Whenever users deposit to Euler, they receive eTokens representing the deposited coins. For example, if a user deposits 1,000 USD Coin (USDC), they will receive the same amount of eUSDC in exchange.

Since they become worth more than the underlying coins as the deposit earns interest, eTokens don’t have a 1:1 correspondence with the underlying asset in terms of value.

Euler also allows users to gain leverage by minting eTokens. But if they do this, the protocol will send them debt tokens (dTokens) to balance out the assets created.

For example, the docs say that if a user deposits 1,000 USDC, they can mint 5,000 eUSDC. However, if they do this, the protocol will also send them 5,000 of a debt token called “dUSDC.”

The transfer function for a dToken is written differently than a standard ERC-20 token. If you own a debt token, you can’t transfer it to another person, but anyone can take a dToken from you if they want to.

Related: Liquidity protocol Sentiment exploited for over $500K

According to the Euler docs, a user can only mint as many eTokens as they would have been able to by depositing and borrowing over and over again, as it states, “The Mint function mimics what would happen if a user deposited $1,000 USDC, then borrowed $900 USDC, then redeposited that $900 USDC, to borrow $810 more USDC, and so on.”

Users liquidated if health scores drop to 1 or below

According to a blog post from Euler, each user has a “health score” based on the value of the eTokens held in their wallets vs. the value of the dTokens held. A user needs to have a greater dollar value of eTokens than dTokens, but how much more depends on the particular coins they are borrowing or depositing. Regardless, a user with enough eTokens will have a health score greater than 1.

If the user barely falls below the required number of eTokens, they will have a health score of precisely 1. This will subject them to “soft liquidation.” Liquidator bots can call a function to transfer some of the user’s eTokens and dTokens to themselves until the borrower’s health score returns to 1.25. Since a user who is barely below the collateral requirements will still have more collateral than debt, the liquidator should profit from this transaction.

If a user’s health score falls below 1, then an increasing discount is given out to the liquidator based on how bad the health score is. The worse the health score, the greater the discount to the liquidator. This is intended to make sure that someone will always liquidate an account before it accumulates too much bad debt.

Euler’s post claims that other protocols offer a “fixed discount” for liquidation and argues why it thinks variable discounts are superior.

How the Euler attack happened

Blockchain data reveals that the attacker engaged in a series of attacks that drained various tokens from the protocol. The first attack drained around $8.9 million worth of Dai (DAI) from the Dai deposit pool. It was then repeated over and over again for other deposit pools until the total amount was drained.

The attacker used three different Ethereum addresses to perform the attack. The first was a smart contract, which Etherscan has labeled “Euler Exploit Contract 1,” used to borrow from Aave. The second address was used to deposit and borrow from Euler, and the third was used to perform a liquidation.

To avoid having to repeatedly state the addresses that Etherscan has not labeled, the second account will be referred to as “Borrower” and the third account “Liquidator,” as shown below:

Ethereum addresses used by the hacker. Source: Etherscan

The first attack consisted of 20 transactions in the same block.

First, Euler Exploit Contract 1 borrowed 30 million DAI from Aave in a flash loan. It then sent this loan to the borrower account.

After receiving the 30 million DAI, borrower deposited 20 million of it to Euler. Euler then responded by minting approximately 19.6 million eDAI and sending it to borrower.

These eDAI coins were a receipt for the deposit, so a corresponding amount of dDai was not minted in the process. And since each eDAI can be redeemed for slightly more than one DAI, the borrower only received 19.6 million instead of the full 20 million.

After performing this initial deposit, borrower minted approximately 195.7 million eDAI. In response, Euler minted 200 million dDAI and sent it to borrower.

At this point, borrower was near their eDAI mint limit, as they had now borrowed about 10 times the amount of DAI they had deposited. So their next step was to pay off some of the debts. They deposited the other 10 million DAI they had held onto, effectively paying back $10 million of the loan. In response, Euler took 10 million dDAI out of borrower’s wallet and burned it, reducing borrower’s debt by $10 million.

Related: Allbridge offers bounty to exploiter who stole $573K in flash loan attack

The attacker was then free to mint more eDAI. Borrower minted another 195.7 million eDAI, bringing their eDAI total minted to around 391.4 million. The 19.6 million eDAI in deposit receipts brought borrower’s eDAI total to about 411 million.

In response, Euler minted another 200 million dDai and sent it to borrower, bringing borrower’s total debt to $400 million.

Once borrower had maximized their eDAI minting capacity, they sent 100 million eDai to the null address, effectively destroying it.

This pushed their health score well below 1, as they now had $400 million in debt vs. approximately $320 million in assets.

This is where the liquidator account comes in. It called the liquidate function, entering borrower’s address as the account to be liquidated.

Liquidation event emitted during the Euler attack. Source: Ethereum blockchain data

In response, Euler initiated the liquidation process. It first took around 254 million dDAI from borrower and destroyed it, then minted 254 million new dDai and transferred it to liquidator. These two steps transferred $254 million worth of debt from borrower to liquidator.

Next, Euler minted an additional 5.08 million dDAI and sent it to liquidator. This brought liquidator’s debt to $260 million. Finally, Euler transferred approximately 310.9 million eDAI from borrower to liquidator, completing the liquidation process.

In the end, borrower was left with no eDAI, no DAI, and 146 million dDAI. This meant that the account had no assets and $146 million worth of debt.

On the other hand, liquidator had approximately 310.9 million eDAI and only 260 million dDAI.

Once the liquidation had been completed, liquidator redeemed 38 million eDAI ($38.9 million), receiving 38.9 million DAI in return. They then returned 30 million DAI plus interest to Euler Exploiter Contract 1, which the contract used to pay back the loan from Aave.

In the end, liquidator was left with approx. $8.9 million in profit that had been exploited from other users of the protocol.

This attack was repeated for multiple other tokens, including Wrapped Bitcoin (WBTC), Staked Ether (stETH) and USDC, amounting to $197 million in exploited cryptocurrencies.

Losses from Euler attack. Source: Blocksec

What went wrong in the Euler attack

Blockchain security firms Omniscia and SlowMist have analyzed the attack to try and determine what could have prevented it.

According to a March 13 report from Omniscia, the primary problem with Euler was its “donateToReserves” function. This function allowed the attacker to donate their eDAI to Euler reserves, removing assets from their wallet without removing a corresponding amount of debt. Omnisica says that this function was not in the original version of Euler but was introduced in Euler Improvement Proposal 14 (eIP-14).

The code for eIP-14 reveals that it created a function called donateToReserves, which allows the user to transfer tokens from their own balance to a protocol variable called “assetStorage.reserveBalance.” Whenever this function is called, the contract emits a “RequestDonate” event that provides information about the transaction.

Blockchain data shows that this RequestDonate event was emitted for a value of 100 million tokens. This is the exact amount that Etherscan shows were burned, pushing the account into insolvency.

Euler’s RequestDonate event being emitted during the attack. Source: Ethereum blockchain data

In their March 15 analysis, SlowMist agreed with Omniscia about the importance of the donateToReserve function, stating:

“Failure to check whether the user was in a state of liquidation after donating funds to the reserve address resulted in the direct triggering of the soft liquidation mechanism.”

The attacker might have also been able to carry out the attack even if the donate function had not existed. The Euler “EToken.sol” contract code on GitHub contains a standard ERC-20 “transfer” function. This seems to imply that the attacker could have transferred their eTokens to another random user or to the null address instead of donating, pushing themselves into insolvency anyway.

Euler eToken contract transfer function. Source: GitHub

However, the attacker did choose to donate the funds rather than transfer them, suggesting the transfer would not have worked.

Cointelegraph has reached out to Omniscia, SlowMist and the Euler team for clarification on whether the donateToReserves function was essential to the attack. However, it has not received a response by publication time.

Related: Euler team denies on-chain sleuth was a suspect in hack case

The two firms agreed that another major vulnerability in Euler was the steep discounts offered to liquidators. According to SlowMist, when a lending protocol has a “liquidation mechanism that dynamically updates discounts,” it “creates lucrative arbitrage opportunities for attackers to siphon off a large amount of collateral without the need for collateral or debt repayment.” Omniscia made similar observations, stating:

“When the violator liquidates themselves, a percentage-based discount is applied […] guaranteeing that they will be ‘above-water’ and incur only the debt that matches the collateral they will acquire.”

How to prevent a future Euler attack

In its analysis, SlowMist advised developers on how to prevent another Euler-style attack in the future. It argued that lending protocols should not allow users to burn assets if this will cause them to create bad debt, and it claimed that developers should be careful when using multiple modules that may interact with each other in unexpected ways:

“The SlowMist Security Team recommends that lending protocols incorporate necessary health checks in functions that involve user funds, while also considering the security risks that can arise from combining different modules. This will allow for the design of secure economic and viable models that effectively mitigate such attacks in the future.”

A representative from DeFi developer Spool told Cointelegraph that technological risk is an intrinsic feature of the DeFi ecosystem. Although it can’t be eliminated, it can be mitigated through models that properly rate the risks of protocols.

According to Spool’s risk management white paper, it uses a “risk matrix” to determine the riskiness of protocols. This matrix considers factors such as the protocol’s annual percentage yield (APY), audits performed on its contracts, time since its deployment, total value locked (TVL) and others to create a risk rating. Users of Spool can employ this matrix to diversify DeFi investments and limit risks.

The representative told Cointelegraph that Spool’s matrix significantly reduced investor losses from the Euler incident.

“In this incident, the worst affected Smart Vaults, those designed by users to seek higher (and riskier) yields, were only affected for up to 35%. The lowest affected vault with exposure to Euler strategies (via Harvest or Idle), in comparison, was only affected by 6%. Some vaults had zero exposure and were thus not impacted,” they stated.

Spool continued, “While this is not ideal, it clearly demonstrates the ability of the Smart Vaults to provide tailored risk models and to distribute users’ funds among multiple yield sources.”

Cointelegraph got a similar answer from SwissBorg, another DeFi protocol that aims to help users limit risk through diversification. SwissBorg CEO Cyrus Fazel stated that the SwissBorg app has “different yield strategies based on risk/timeAPY.”

Some strategies are listed as “1: core = low,” while others are listed as “2: adventurous = risky.” Because Euler was given a “2” rating, losses from the protocol were limited to only a small portion of SwissBorg’s total value locked, Fazel stated.

SwissBorg head of engineering Nicolas Rémond clarified further that the team employs sophisticated criteria to determine what protocols can be listed in the SwissBorg app.

“We have a due-diligence process for all DeFi platforms before entering any position. And then, once we’re there, we have operation procedures,“ he said, adding, ”The due diligence is all about TVL, team, audits, open-source code, TVL, oracle manipulation attack, etc. […] The operation procedure is about platform monitoring, social media monitoring and some emergency measures. Some are still manual, but we’re investing to automatize everything based so that we can be extremely reactive.”

In a March 13 Twitter thread, the SwissBorg team stated that although the protocol had lost 2.2% of the funds from one pool and 29.52% from another, all users would be compensated by SwissBorg should the funds not be recoverable from Euler.

The Euler attack was the worst DeFi exploit of Q1 2023. Thankfully, the attacker returned most of the funds, and most users should end up with no losses when all is said and done. But the attack raises questions about how developers and users can limit risk as the DeFi ecosystem continues to expand.

Some combination of developer diligence and investor diversification may be the solution to the problem. But regardless, the Euler hack may continue to be discussed well into the future, if for no other reason than its sheer size and illustration of the risks of DeFi exploits.

Visa: Token bridges were a favored target for thieves in 2022

The fraudsters would usually exploit the smart contracts to allow for the approval of unauthorized transactions.

According to the global payment provider Visa, 2022 became a record-breaking year for cryptocurrency thefts, with over $3 billion stolen in on-chain exploits. Cryptocurrency bridge services were a favored target for threat actors.

Visa published the biannual threats report on March 20. The document contains data on all sorts of violations occurring globally in the digital payments system last year — from plastic card fraud schemes to malware. A separate section is dedicated to cryptocurrency and digital platforms.

Quick history of blockchain-based major thefts. Source: Investopedia

It pays particular attention to the vulnerability of token bridges. Commonly, fraudsters exploit a bridge service’s smart contracts to either forge new transactions or allow for the approval of unauthorized transactions. The total amount of funds stolen via token bridges totals $2 billion from January through early October 2022.

The report also mentions a crypto-focused phishing campaign, whose actors were impersonating a crypto exchange in emails to harvest the victim’s account login data. Once the real exchange prompts the threat actor for the two-factor authentication (2FA), they would use the spoofed site to prompt the victim to enter their 2FA information, using the real 2FA from the spoofed site to complete the login process.

Related: ​​Visa’s crypto strategy targets stablecoin settlements

In February, it was reported that, along with its competitor Mastercard, Visa would delay the launch of new partnerships with crypto firms due to high-profile bankruptcies in the industry. However, Cuy Sheffield, head of product at Visa, called the report inaccurate and reassured that Visa would “continue to partner with crypto companies to improve fiat on and off-ramps,” and “build new products that can facilitate stablecoin payments.”

On Feb. 20, the Bitcoin market cap flipped the market cap of Visa for the third time in history. By March 14, the gap between the two reached more than $20 billion in favor of BTC.

ChatGPT won’t replace developers — ETHDubai devs weigh in

The latest version of ChatGPT is able to identify Ethereum smart contract vulnerabilities and exploits — but will it replace developers in the future?

The newest version of ChatGPT has caused a stir online, scoring high marks for SAT tests and highlighting vulnerabilities and exploits in Ethereum smart contracts.

GPT-4 is the latest version of the highly influential artificial intelligence (AI) language model, boasting “human-level performance on various professional and academic benchmarks,” according to its developer OpenAI.

Aside from outstanding scores on a range of various professional and academic benchmarks, GPT-4 has also demonstrated the ability to review Ethereum smart contracts, highlighting vulnerabilities and even suggesting potential ways to exploit the code.

Coinbase director Conor Grogan shared a prompt dialogue with ChatGPT in which the AI chatbot “highlighted a number of security vulnerabilities” before verifying a method to exploit the contract.

Related: 10 ways blockchain developers can use ChatGPT

Perhaps more interesting is that ChatGPT’s recommendation checks out, given that the exact same smart contract had been hacked in 2018 via the same method that the language model suggested.

On the back of the latest ChatGPT upgrade and its potential to review, suggest and provide insights to Ethereum smart contract developers, Cointelegraph journalist Ezra Reguerra explored the topic in conversation with attendees at the ETHDubai conference this week.

Cointelegraph journalist Ezra Reguerra in conversation with blockchain developer Salman Arshad at the ETHDubai conference.

Blockchain developer Salman Arshad highlighted the connection that ChatGPT has with blockchain, given the focus on Web3 in security and auditing processes. Smart contract auditors are costly, and ChatGPT offers a timely and cost-efficient way to review code:

“ChatGPT and AI tools are a blessing; they are not our enemies and are not here to end the career of a developer.”

Arshad added that ChatGPT’s broad knowledge base is its strength, but it still requires human input for specific business logic and prompts. The benefit is that developers can get far more work done in far less time by using AI-powered tools:

“You know what your company wants to do. You can tell ChatGPT, and it can perfectly transform your commands into a smart contract, auditing process, document or white paper.”

Another blockchain developer, Syed Ghazanfer, also highlighted the collaborative nature of ChatGPT, which still remains far more beneficial to a wide range of users than the potential threat of automating processes and replacing human workers:

“I’m really in favor of ChatGPT. For it to replace you, you have to communicate requirements which are not possible in native English. That’s why we invented programming languages.”

Ghazanfer added that ChatGPT will remain a useful tool for developers, automating processes like reading and condensing full documentation.

As previously explored by Cointelegraph, ChatGPT is proving significantly useful for developers to solve coding problems. The AI-powered tool also promises to be useful for security audits of smart contracts and Web3 platforms.

Euro Parliament approves Data Act that requires kill switches on smart contracts

The act would encourage data sharing, but it imposes requirements for smart contracts used in this setting that have alarmed members of the crypto community.

The European Parliament passed the Data Act on March 14. The comprehensive bill was intended to “boost innovation by removing barriers obstructing access to industrial data.” Among its provisions is an article that would require smart contracts to be alterable. 

The legislation established rules for fairly sharing data generated by “connected products or related services,” such as the Internet of Things and “industrial machines.” Eighty percent of industrial data generated is never used, the European Parliament noted in a statement, and this act would encourage greater use of those resources to train algorithms and lower prices for device repairs.

The act contains provisions to protect trade secrets and avoid unlawful data transfers, and it set requirements for the smart contracts of parties offering sharable data, including “safe termination and interruption”:

“The smart contract shall include internal functions which can reset or instruct the contract to stop or interrupt the operation. […] Especially, it should be assessed under which conditions non-consensual termination or interruption should be permissible.”

The act also granted smart contracts equal protection when compared with other forms of contract.

Experts identified a number of issues with the legislation. OpenZeppelin head of solutions architecture Michael Lewellen commented in a statement provided to Cointelegraph:

“Including a kill switch undermines immutability guarantees and introduces a point of failure since someone needs to govern the use of such a kill switch. […] Many smart contracts such as Uniswap do not have this kill switch ability.”

Related: FTX proves MiCA should be passed fast, officials tell European Parliament committee

Professor Thibault Schrepel of the Vrije Universiteit Amsterdam said in a tweet that the act “endangers smart contracts to an extent that no one can predict,” and pointed out sources of legal uncertainty in the act. In particular, he found that it did not specify who could stop or interrupt a smart contract.

The bill was passed by a margin of 500-23, with 110 abstentions. Parliament members will now negotiate the final form of the law with the European Council and individual member countries of the European Union.

Privacy-focused blockchain network closes Aztec Connect tool

Aztec Network said the research made with Aztec Connect would be usable and critical to developing a next-generation blockchain.

Privacy-oriented blockchain platform Aztec is preparing to shut down Aztec Connect, the network’s privacy infrastructure serving as the encryption layer for Ethereum.

Aztec Network officially announced the upcoming closure of Aztec Connect, and plans to disable Aztec Connect deposits from front-ends like zk.money and zkpay.finance on March 17.

According to a blog post by Aztec, users will be able to withdraw their funds from Aztec Connect with no fees for one year. “While withdrawals will always be possible, they will become significantly more burdensome after March 21, 2024,” Aztec said, recommending users withdraw funds as soon as possible. Since it launched in July 2022, Aztec Connect has amassed more than 100,000 users, the announcement notes.

From March 2024, Aztec will no longer run a sequencer, meaning the current system will no longer publish rollup blocks processing Aztec Connect transactions. “Contract permissions will be renounced, and all rollup functionality will be ceased,” the announcement reads.

As Aztec has fully open-sourced the entire Aztec Connect protocol, the firm encourages the Aztec community to fork, deploy and operate a new version of the system. “We’d love to see an independently-operated Aztec Connect and are ready to fund it,” Aztec said.

According to the announcement, the shutdown of Aztec Connect marks a milestone in the development of a decentralized general-use encrypted blockchain. Before launching Aztec Connect in July 2022, Aztec first experimented with using a zk-Rollup with Aztec 1, which was “slow, inefficient, costly” and limited in functionality to “basic private transfers.”

Source: Aztec

Aztec emphasized that the research made with Aztec Connect will be usable and critical to the development of a next-generation blockchain, providing a basis for a fully programmable version of encrypted rollups, adding:

“It’s undeniable that Aztec Connect was an important stepping stone towards realizing our ultimate goal. It’s now time for us to focus fully on that goal: a decentralized general-use encrypted blockchain.”

After closing Aztec Connect, Aztec plans to focus on developing the universal zero-knowledge language known as Noir and the next-generation encrypted blockchain.

Related: Crypto projects respond to privacy coin ban in Dubai

The news comes amid ConsenSys preparing to release its zero-knowledge Ethereum Virtual Machine rollup on a public testnet on March 28. The launch will follow more than four years of research, potentially enabling faster transactions, higher throughput and better security of settlements on the Ethereum blockchain.

Aave DAO votes for ‘rescue plan’ to save lost tokens

The plan intends to allow developers to recover tokens from certain Aave contracts and send them to owners who transferred them by mistake.

Some Aave users who accidentally sent tokens to the wrong address may soon be able to recover them, according to the text of a proposal passed by the Aave decentralized autonomous organization (DAO) on March 10. The proposal, called “Rescue Mission Phase 1 Long Executor,” authorizes Aave developers to upgrade smart contracts that have been mistakenly sent tokens in the past, causing the contracts to send the lost tokens back to their original owners automatically.

The confirmed proposal only affects lost AAVE (AAVE), LEND, Tether (USDT), UNI (UNI) and staked AAVE (stkAAVE) tokens that were mistakenly sent to the AAVE token contract, the LEND token contract, the LendtoAaveMigrator or the stAAVE token contract.

It further authorizes the team to initialize a new implementation for these contracts. The Aave DAO said that during the initialization, the lost tokens will be sent automatically to a separate AaveMerkleDistributor contract, where they will then be sent to the owners.

The proposal’s text emphasizes that these tokens will only be transferred during the contracts’ initialization phase, stating: “To be as less invasive as possible, these new implementations only include that extra logic on their initialize() function, with everything else remaining the same.” This seems to imply that only tokens lost in the past will be recoverable. Future tokens mistakenly sent to these addresses may be permanently lost unless a new proposal is passed in the future.

Related: Stablecoin adoption could lead to DeFi growth, says AAVE founder

Losing tokens by mistakenly transferring them to a token contract is a common problem in the crypto community. ChainSafe developer Muhammad Altabba has estimated that hundreds of millions of dollars worth of tokens and Ether (ETH) are locked in the Ethereum null address (0x0) and token contracts. One Ethereum user lost over $500,000 worth of wrapped Ether (wETH) by transferring it to the wETH token contract instead of calling its “unwrap” function as they intended.

If a contract cannot be upgraded, tokens lost in this way are usually impossible to recover.

By their nature, crypto transfers are supposed to be immutable. So, even if mistaken transfers can be reversed, attempts to do so are sometimes controversial. In 2016, The DAO, an early version of today’s DAOs, was exploited for $60 million worth of ETH, which the investors in The DAO presumably did not intend to happen. The majority of Ethereum validators implemented a hard fork to reverse the exploit transaction, but some validators rejected this move, creating Ethereum Classic in the process.

The Aave DAO vote to rescue the lost tokens was not nearly as controversial. The proposal passed with more than 99.9% of the vote. Only one user voted against the proposal, using a single AAVE token to do so.

Uniswap DAO debate shows devs still struggle to secure cross-chain bridges

Developers face tradeoffs between making bridges upgradeable to fix bugs versus making them decentralized.

Over $2.5 billion was stolen in cross-chain crypto bridge hacks from 2021 to 2022, according to a report by Token Terminal. But, despite several attempts by developers to improve bridge security, a debate from December 2022 to January 2023 on the Uniswap DAO forums has laid bare security weaknesses that continue to exist in blockchain bridges.

In the past, bridges like Ronin and Horizon used multisig wallets to ensure that only bridge validators could authorize withdrawals. For example, Ronin required five out of nine signatures to withdraw, whereas Horizon required two out of five. But attackers figured out how to circumvent these systems and withdrew millions of dollars worth of crypto, leaving users of these bridges with unbacked tokens.

After these multisig bridges were hacked, developers started turning to more sophisticated protocols like Celer, LayerZero and Wormhole, which claimed to be more secure.

But in December 2022, Uniswap DAO began discussing deploying Uniswap v3 to the BNB Chain. In the process, the decentralized autonomous organization (DAO) had to decide which bridge protocol would be used for cross-chain Uniswap governance. In the discussion that followed, the security of each solution was challenged by critics, leaving some observers to conclude that no single bridge solution was secure enough for Uniswap’s purposes.

As a result, some participants concluded that only a multibridge solution can secure crypto assets in the cross-chain environment of crypto today.

Over $10 billion of crypto assets are currently locked on bridges as of Feb. 15, according to DefiLlama, making the issue of bridge security an urgent one.

How blockchain bridges work

Blockchain bridges enable two or more blockchains to share data with each other, such as cryptocurrency. For example, a bridge may enable USD Coin (USDC) to be sent from Ethereum to BNB Chain or Trader Joe (JOE) from Avalanche to Harmony.

But each blockchain network has its own architecture and database, separate from others. So in a literal sense, no coin can be sent from one network to another.

Cybersecurity, Security, Web3, Smart Contracts, Hacks

To get around this problem, bridges lock coins on one network and mint copies of them on another. When the user wants to “move” their coins back to the original network, the bridge then burns the copies and unlocks the original coins. Although this doesn’t move coins between networks, it’s similar enough to suit the purposes of most crypto users.

However, the problem arises when an attacker can either mint unbacked coins on the receiving chain or withdraw coins on the sending chain without burning its copies. Either way, this results in the receiving chain having extra coins that are not backed by anything. This is exactly what happened in the Ronin and Horizon hacks of 2022.

Ronin and Horizon: When bridging goes wrong

Ronin bridge was a protocol that allowed Axie Infinity players to move coins between Ethereum and the Ronin sidechain to play the game.

The Ethereum contracts for the bridge had a function called “withdrawERC20For,” which allowed Ronin validators to withdraw tokens on Ethereum and give them to the user, with or without burning them on Ronin. However, the Ronin software that validators ran was programmed only to call this function if the corresponding coins on Ronin had been burned. Calling the function required signatures from five out of the nine validator nodes, preventing an attacker from withdrawing the funds even if they got control of a single node.

To further ensure that the funds couldn’t be stolen, Axie Infinity developer Sky Mavis distributed the majority of validator keys to other stakeholders, including Axie DAO. This meant that if Sky Mavis’s computers were taken over, the attacker still wouldn’t be able to withdraw coins without their backing since the attacker would only have four keys.

But despite these precautions, an attacker could still obtain all four of Sky Mavis’ keys, plus a fifth signature from Axie DAO to withdraw over $600 million worth of crypto from the bridge.

Recent: SEC vs. Kraken: A one-off or opening salvo in an assault on crypto?

Sky Mavis has since reimbursed victims of the attack and has relaunched the bridge with what the developers call a “circuit breaker” system that halts large or suspicious withdrawals.

A similar attack happened to the Harmony Horizon Bridge on June 24, 2022. This bridge allowed users to transfer assets from Ethereum to Harmony and back again. The “unlockTokens” (withdraw) function could only be called if two out of five signatures from the Harmony team authorized it. The private keys that could produce these signatures were encrypted and stored using a key management service. But through some unknown method, the attacker was able to gain and decrypt two of the keys, allowing them to withdraw $100 million of crypto from the Ethereum side of the bridge.

The Harmony team proposed a reimbursement plan in August 2022 and relaunched the bridge using LayerZero.

After these hacks, some bridge developers believed they needed better security than a basic multisig wallet. This is where bridging protocols came in.

The rise of bridging protocols

Since the Ronin and Horizon hacks have called attention to the problem of bridge security, a few companies have begun to specialize in creating bridge protocols that other developers can customize or implement for their specific needs. These protocols claim to be more secure than just using a multisig wallet to handle withdrawals.

In late January, the Uniswap DAO considered launching a BNB Chain version of its decentralized exchange. In the process, it needed to decide which protocol to use. Here are the four protocols considered, along with a brief explanation of how they try to secure their bridges.

LayerZero

According to the LayerZero docs, the protocol uses two servers to verify that coins are locked on the original chain before allowing them to be minted on the destination chain. The first server is called the “oracle.” When a user locks coins on the sending chain, the oracle transmits the block header for that transaction to the destination chain.

The second server is called the “relayer.” When a user locks coins on the sending chain, the relayer sends proof to the second chain that the locking transaction is contained within the block referenced by the oracle.

As long as the oracle and relayer are independent and do not collude, it should be impossible for an attacker to mint coins on chain B without locking them on chain A or to withdraw coins on chain A without burning them on chain B.

LayerZero uses Chainlink for the default oracle and provides its own default relayer for application developers that want to use it, but devs can also create custom versions of these servers if they want to.

Celer

According to the Celer cBridge docs, Celer relies on a network of proof-of-stake (PoS) validators called “state guardians” to verify that coins are locked on one chain before being minted on another. Two-thirds of the validators have to agree that a transaction is valid for it to be confirmed.

In the Uniswap debate, Celer co-founder Mo Dong clarified that the protocol also offers an alternative mechanism for consensus called “optimistic rollup-style security.” In this version, transactions are subject to a waiting period, allowing any single state guardian to veto the transaction if the information it has contradicts the two-thirds majority.

Mo argued that some app developers, including Uniswap, should use the “optimistic rollup-like security model” and run their own app guardian to guarantee they can block fraudulent transactions even if the network is compromised.

In response to a question about who the validators for the network are, the Celer co-founder stated:

“Celer has a total of 21 validators, which are highly reputable PoS validators securing chains such as Binance Chain, Avalanche, Cosmos and more, such as Binance, Everstake, InfStones, Ankr, Forbole, 01Node, OKX, HashQuark, RockX and more.”

He also emphasized that Celer slashes validators who attempt to get fraudulent transactions confirmed.

Wormhole

According to a forum post from the team, Wormhole relies on 19 validators called “guardians” to prevent fraudulent transactions. 13 out of 19 validators have to agree for a transaction to be confirmed.

In the Uniswap debate, Wormhole argued that its network is more decentralized and has more reputable validators than its peers, stating, “Our Guardian set comprises the leading PoS validators, including Staked, Figment, Chorus One, P2P, and more.”

DeBridge

The deBridge docs say that it is a proof-of-stake network with 12 validators. Eight of these validators have to agree that a transaction is valid for it to be confirmed. Validators that attempt to pass through fraudulent transactions are slashed.

In the Uniswap debate, deBridge co-founder Alex Smirnov stated that all deBridge validators “are professional infrastructure providers that validate many other protocols and blockchains” and “all validators bear reputational and financial risks.”

In the later stages of the debate, Smirnov began advocating for a multibridge solution rather than for using deBridge as the sole solution for Uniswap, as he explained:

“If deBridge is chosen for the temperature check and further governance voting, the Uniswap-deBridge integration will be built in the context of this bridge-agnostic framework and thus, will enable other bridges to participate.”

Throughout the Uniswap bridge debate, each of these protocols was subjected to criticism in terms of its security and decentralization.

LayerZero allegedly gives power to app devs

LayerZero was criticized for allegedly being a disguised 2/2 multisig and for putting all power into the hands of the app developer. On Jan. 2, L2Beat author Krzysztof Urbański alleged that the oracle and relayer system on LayerZero can be circumvented if an attacker takes control of the app developer’s computer systems.

To prove this, Urbański deployed a new bridge and token using LayerZero, then bridged some tokens from Ethereum to Optimism. Afterward, he called an admin function to change the oracle and relayer from the default servers to ones under his control. He then proceeded to withdraw all of the tokens on Ethereum, leaving the tokens on Optimism unbacked.

Urbański’s article was cited by multiple participants in the debate, including GFX Labs and Phillip Zentner of LIFI, as reasons why LayerZero shouldn’t be used as the sole bridging protocol for Uniswap.

Speaking to Cointelegraph, LayerZero CEO Bryan Pellegrino responded to this criticism, stating that a bridge developer using LayerZero “can burn [its] ability to change any settings and have it be 100% immutable.” However, most developers choose not to do this because they fear imposing immutable bugs into the code. He also argued that putting upgrades into the hands of a “middlechain auth” or third-party network can be riskier than having an app developer control it.

Some participants also criticized LayerZero for having an unverified or closed-source default relayer. This would allegedly make it difficult for Uniswap to develop its own relayer quickly.

Celer raises concerns about security model

In an initial non-binding vote on Jan. 24, the Uniswap DAO chose to deploy to BNB Chain with Celer as the official Uniswap bridge for governance. However, once GFX Labs started testing the bridge, they posted concerns and questions about Celer’s security model.

According to GFXLabs, Celer has an upgradeable MessageBus contract under the control of three of five multisigs. This could be an attack vector by which a malicious person could gain control of the entire protocol.

In response to this criticism, Celer co-founder Mo stated that the contract is controlled by four highly-respected institutions: InfStones, Binance Staking, OKX and the Celer Network. Dong argued that the MessageBus contract needs to be upgradeable to fix bugs that may be found in the future, as he explained:

“We made the MessageBus upgradeable with the goal of making it easier to address any potential security issues just in case and add must-have features. However, we approach this process with care and continually evaluate and improve our governance process. We welcome additional active contributors such as GFXLabs to be more involved.”

In the later stages of the debate, Celer began supporting a multibridge solution instead of arguing for its own protocol being the only bridge.

Wormhole not slashin’

Wormhole was criticized for not using slashing to punish misbehaving validators and for allegedly doing a lower volume of transactions than it is admitting.

Mo argued that a PoS network with slashing is usually better than one without, stating, “Wormhole does not have any economic security or slashing built in the protocol. If there is any other centralized/off-chain agreement, we hope wormhole can make them known to the community. Just by looking at this comparison, a reasonable level of economic security in protocol >> 0 economic security in the protocol.”

Mo also claimed that Wormhole’s transaction volume might be lower than the company admits. According to him, over 99% of Wormhole transactions come from Pythnet, and if this number is excluded, “there are 719 message per day in the last 7 days on Wormhole.”

DeBridge had very little criticism directed against it, as most participants seemed to think that Celer, LayerZero and Wormhole were the dominant choices.

In the later stages of the debate, the deBridge team began advocating for a multibridge solution.

Toward a multibridge solution?

As the Uniswap debate continued, several participants argued that no single bridging protocol should be used for governance. Instead, they argued that multiple bridges should be used and that a majority or even unanimous decision from all bridges should be required to confirm a governance decision.

Celer and deBridge came around to this point of view as the debate progressed, and LIFI CEO Phillip Zentner argued that Uniswap’s move to BNB should be postponed until a multibridge solution could be implemented.

Ultimately, the Uniswap DAO voted to deploy to BNB Chain with Wormhole as the official bridge. However, Uniswap executive director Devin Walsh explained that deployment with a single bridge does not preclude adding additional bridges at a later date. So the advocates for a multibridge solution will likely continue their efforts.

Can blockchain bridges be secure?

No matter what ultimately happens to Unsiwap’s cross-chain governance process, the debate has illustrated how hard it is to secure cross-chain bridges.

Putting withdrawals into the hands of multisig wallets creates the risk that bad actors may gain control of multiple signatures and withdraw tokens without the consent of users. It centralizes the blockchain world and makes users rely upon trusted authorities instead of decentralized protocols.

Recent: DeFi security: How trustless bridges can help protect users

On the other hand, proof-of-stake-style bridging networks are complex programs that may be found to have bugs, and if their contracts are not upgradeable, these bugs can’t be fixed without a hard fork of one of the underlying networks. Developers continue to face a tradeoff between putting upgrades into the hands of trusted authorities, who may get hacked, versus making protocols truly decentralized and, therefore, non-upgradeable.

Billions of dollars of crypto assets are stored on bridges, and as the crypto ecosystem grows, there may be even more assets stored on these networks over time. So the problem of securing a blockchain bridge and protecting these assets continues to be critical.