## Summary
On 2023-11-21, the Atomicals Market trading platform experienced users' asset loss incident that has thrown Atomicals Protocol and Atomicals Market, into a storm recently. A series of questions about the ARC-20 token have sparked widespread discussion and skepticism.

## Atomicals Protocol & Atomicals Market
Atomicals Market is the trading marketplace for ARC-20, it applies Atomicals Protocol to trade ARC-20 (Note: Atomicals Market and Atomicals Protocol do not belong to the same company).
Atomicals Market issued a post on the 21st stating that a PBST flaw was discovered in its trading process based on Atomicals Protocol, causing users to experience losses when trading atom tokens
![image.png](https://storage.googleapis.com/metatrust/website/post/image/1701396047873_image.png)
However, Atomicals Protocol issued a post on the 24th to counter Atomicals Market's comments and pointed out that the cause of the problem was Atomicals Market's negligence in using SIGHASH_NONE signatures in transactions, putting its users at risk. They stated that it had warned Atomicals Market that it should NOT use SIGHASH_NONE for signatures (it is worth noting that a similar situation does not appear to have occurred with SatsX, which is also an Atomicals trading platform).
![image.png](https://storage.googleapis.com/metatrust/website/post/image/1701396063181_image.png)
Upon analysis, the root cause of the users' asset loss was found to be Atomicals Market's incorrect use of SIGHASH_NONE (TX:1623bf2997cde779dd9e0e2c54b5f7f196f36826dcb689e41acd7fff27ec5c93) in the PSBT.
![image.png](https://storage.googleapis.com/metatrust/website/post/image/1701396075837_image.png)
## Preliminary knowledge
Before we go any further in analyzing why things are happening, some preparatory knowledge is needed, and that's because BTC doesn't use the same account model as Ethereum.
## UTXO
A Bitcoin Unspent Transaction Output (UTXO) represents a specific segment of bitcoin ownership. Unlike traditional systems which utilize accounts and balances, Bitcoin operates with these individual bitcoin segments. Each UTXO is defined by a particular value, representing the distinct portions of bitcoin that are transferred in transactions.
![image.png](https://storage.googleapis.com/metatrust/website/post/image/1701396108907_image.png)
In the process of a transaction, a UTXO is consumed and ceases to exist. Consequently, this action generates one or more new UTXOs. The collective set of these UTXOs, known as the UTXO set, is maintained and updated by all network nodes. This occurs each time a new block processes transactions that generate and extinguish UTXOs. The UTXO set plays a critical role in enabling nodes to independently confirm the legitimacy of transactions and the bitcoins they aim to spend.
## PSBT
A Partially Signed Bitcoin Transaction (PSBT) is a protocol in the Bitcoin ecosystem designed to enhance the ease of transferring unsigned transactions, enabling multiple participants to concurrently sign a single transaction.
PSBTs (Partially Signed Bitcoin Transactions) offer utility across numerous scenarios. Consider the creation of a CoinJoin transaction involving three individuals. In this process, each of the three participants sends a message to a central coordinator. This message includes details of the UTXOs (Unspent Transaction Outputs) they wish to include in the CoinJoin. Additionally, every participant specifies the addresses to which their share of bitcoin should be returned after the CoinJoin transaction is completed.
![image.png](https://storage.googleapis.com/metatrust/website/post/image/1701396123906_image.png)
## What's the problem?
Atomicals Protocol mentioned performing the PBST swap securely requires the seller to sign 2nd input containing the ARC20 Atomical and 2nd output to receive the payment amount. 
The seller needs to sign with SIGHASH_SINGLE | ANYONECANPAY allows the buyer to later add their input for funding and their receive address for the purchased ARC20 tokens.
![image.png](https://storage.googleapis.com/metatrust/website/post/image/1701396134170_image.png)
Then, Atomicals Market does not use SIGHASH_SINGLE in a swap, but SIGHASH_NONE.
We can look at the difference between NONE and SINGLE:
![image.png](https://storage.googleapis.com/metatrust/website/post/image/1701396142843_image.png)
Since, Atomicals Market uses NONE, just signing an INPUT means that only the number of tokens sold is verified. And no signature was applied to the OUTPUT, meaning that no verification was applied to the tokens received. As a result, malicious users can buy tokens from users without paying for them.
![image.png](https://storage.googleapis.com/metatrust/website/post/image/1701396152828_image.png)
## Lost
33,000 $ATOM
## Follow-up
Atomicals Market Promises to Compensate Users for Losses.
![image.png](https://storage.googleapis.com/metatrust/website/post/image/1701396162774_image.png)
## Recommendation
The project owner should have an in-depth study of the protocols it relies on, and the product needs to be adequately tested and audited, paying attention to the recommendations from the protocols and security organizations.

## About MetaTrust Labs 

MetaTrust Labs is a leading provider of Web3 AI security tools and code auditing services incubated at Nanyang Technological University, Singapore. We provide advanced AI solutions that empower developers and project stakeholders to protect Web3 applications and smart contracts. At MetaTrust Labs, we are committed to protecting the Web3 space so that builders can innovate with confidence and reliability.

Website: https://metatrust.io/

Twitter: https://twitter.com/MetatrustLabs

On 2023–11–21, the highly Atomicals Market trading platform experienced users’ asset loss incident that has thrown Atomicals Protocol and Atomicals Market, into a storm recently. A series of questions about the ARC-20 token have sparked widespread discussion and skepticism.

The Analysis of the Atomicals Market User Asset Loss

### Summary
2023-11-11 02:59:23 a.m. UTC +8:00, MetaScout detected that the stablecoin protocol on #Ethereum, Raft, was under a flash loan attack. It resulted in ~6.7m stablecoin $R being minted and the protocol lost $3.6M. The root cause is the precision calculation issue when minting share tokens, which is used by the hacker to get extra share tokens.

MetaTrust Labs conducted in-depth research and analysis on the exploit, revealing how the hacker exploits vulnerability.
### The Stablecoin Protocol Raft
Raft is a DeFi protocol that lets you generate R by depositing liquid staking tokens (LSDs) as collateral, providing a capital-efficient way to borrow while keeping your staking rewards. https://raft.fi/.
![image.png](https://storage.googleapis.com/metatrust/website/post/image/1699700681338_image.png)
As of the time of writing, its TVL has dropped 46% to $7M after today's attack. The price of $R has dropped 99.6% to $0.0036
![image.png](https://storage.googleapis.com/metatrust/website/post/image/1699701052176_image.png)


### Transaction
https://etherscan.io/tx/0xfeedbf51b4e2338e38171f6e19501327294ab1907ab44cfd2d7e7336c975ace7
### Attacker
0xc1f2b71a502b551a65eee9c96318afdd5fd439fa
### Attacking Contract
0x0a3340129816a86b62b7eafd61427f743c315ef8
### Vulnerable Contract
InterestRatePositionManager: 0x9ab6b21cdf116f611110b048987e58894786c244

### Attacking Steps
1. Lend 6000 $cbETH from AAVE with the flash loan ;
2. Transfer a total of 6001 $cbETH to the InterestRatePositionManager contract;
3. Liquidate a pre-created position 0x011992114806e2c3770df73fa0d19884215db85f on the InterestRatePositionManager contract:
![image.png](https://storage.googleapis.com/metatrust/website/post/image/1699701018269_image.png)
4. Set the index of the raft collateral indexable token to 6,003,441,032,036,096,684,181, which is the $cbETH balance of the InterestRatePositionManager contract and amplified more than 1000 times due to the donation of step 2:
![image.png](https://storage.googleapis.com/metatrust/website/post/image/1699701003445_image.png)
5. 5. Mint 1 wei share with only 1 wei $cbETH, due to the divUp function being used when calculating the share. Note that, the minimal value returned from the divUp function is 1 when the numerator is non-zero no matter how big the denominator is:
![image.png](https://storage.googleapis.com/metatrust/website/post/image/1699701009191_image.png)
6. Repeat step 5 60 times to get 60 wei shares, which is 10,050 $cbETH;
7. Redeem 6003 $cbETH with only 90 wei $rcbETH-c;
![image.png](https://storage.googleapis.com/metatrust/website/post/image/1699700994927_image.png)
8. Borrow 6.7M $R, which is profit, and finally swapped for 1575 $ETH(worth $3.6M) with different Dapps, including: 
  - Swap 2.1M $R for 2M $sDAI on Balancer;
  - Swap 1.2M $R for 1.15 $DAI on Balancer;
  - Swap 200K $R for 86K $USDC on Uniswap.
![image.png](https://storage.googleapis.com/metatrust/website/post/image/1699700988253_image.png)
9. What is unbelievable is that the hacker burned 1570 $ETH to the blackhole address, which means no profit 
![image.png](https://storage.googleapis.com/metatrust/website/post/image/1699700982172_image.png)
### Root Cause
The root cause is the precision calculation issue when minting share tokens, which is used by the hacker to get extra share tokens. Because the index was amplified by the donation of $cbETH, the hacker's shares are worth more value, so the hacker can redeem a tiny $rcbETH-c for 6003  $cbETH and borrow tons of $R.
### Key Code
```solidity
    function divUp(uint256 a, uint256 b) internal pure returns (uint256) {
        if (a == 0) {
            return 0;
        } else {
            return (((a * ONE) - 1) / b) + 1;
        }
    }
    
    function mint(address to, uint256 amount) public virtual override onlyPositionManager {
        _mint(to, amount.divUp(storedIndex));
    }
```
### Asset Loss
$3.6M
### Fund flow 
1570 $ETH was burned by the mistake of the hacker.
![image.png](https://storage.googleapis.com/metatrust/website/post/image/1699700961999_image.png)
As of the time of writing, there are 1.4M $R tokens (worth $4.6K) staying in the attacker's wallet.
![image.png](https://storage.googleapis.com/metatrust/website/post/image/1699700968212_image.png)
### Recommandation
1. Consider checking the potential rounding issue in the case of rate calculation, if it is manipulatable by the malicious user in edge cases, like the Raft exploit case.
2. Recommend adopting the monitoring system and pausing the protocol when emergency cases happen. Alternatively, integrating a mempool blocking system would be beneficial. This system can effectively detect attack transactions in the mempool when attackers are executing their attacks, allowing for preemptive blocking to avoid losses.

### About MetaTrust Labs
MetaTrust Labs is a leading provider of Web3 AI security tools and code auditing services incubated at Nanyang Technological University, Singapore. We provide advanced AI solutions that empower developers and project stakeholders to protect Web3 applications and smart contracts. At MetaTrust Labs, we are committed to protecting the Web3 space so that builders can innovate with confidence and reliability.

Website: https://metatrust.io/ 

Twitter: https://twitter.com/MetatrustLabs

2023-11-11 02:59:23 a.m., our MetaScout detected that the stablecoin protocol on #Ethereum, Raft, was under a flash loan attack. It resulted in ~6.7m stablecoin $R being minted and the protocol lost $3.6M. The root cause is the precision calculation issue when minting share tokens, which is used by the hacker to get extra share tokens.
MetaTrust Labs conducted in-depth research and analysis on the exploit, revealing how the hacker exploits vulnerability.

When Hacking Goes Haywire, Raft's 1570 ETH Loss Takes a Cosmic Detour to the Black Hole

### Summary
On Nov 1, 2023, our MetaScout [detected](https://x.com/MetaTrustAlert/status/1719660132240691257?s=20) that the lending protocol, Onyx Protocol on Ethereum, was under a flash loan attack with a loss of $2.1M. The root causes are the proposal of adding a new market that was first executed by the hacker, and the precision loss issue of the compound-fork protocol. 
MetaTrust Labs conducted in-depth research and analysis on the exploit, revealing how hackers used governance proposals and protocol vulnerability to attack Onyx Protocol.

### Onyx Protocol
Onyx Protocol(https://docs.onyx.org/) is an algorithmic money market designed to bring secure and trustless credit and lending to users on the Ethereum Network. 
![image.png](https://storage.googleapis.com/metatrust/website/post/image/1698907360943_image.png)
On Oct 29, 2023, Onyx protocol(https://x.com/OnyxProtocol/status/1718348637158137858?s=20) launched a proposal OIP-22 to add $PEPE to the market. However, it is unfortunately targeted and executed by the hacker for the exploiting.
![image.png](https://storage.googleapis.com/metatrust/website/post/image/1698907434080_image.png)
The Onyx protocol turned out to be a compound-forked protocol after we checked its on-chain deployed contracts, and its TVL dropped from $2.86M to $557K due to yesterday's attack.
![image.png](https://storage.googleapis.com/metatrust/website/post/image/1698907444856_image.png)

### Attacking Timeline
| Time | Action | Transaction |
| --- | --- | --- |
| 2023-10-28 02:29:11 PM +UTC | The proposal OIP-22 was created to add a new market  | 0x309f437ece123ee77b5cc2435783578424bb4e30448dedf6f845bd0c2a4e40a6 |
| 2023-11-01 **09:57:47**  AM +UTC | The hacker executed proposal OIP-22 | 0xb91e0731a0f1eb0abf884717a065f7282a5daaacd172a0db8d4a61609c978ed8 |
| 2023-11-01 **09:58:47**  AM +UTC | Launched the attack only 1 minute later than the execution of proposal 22. Note that the hacker is the one who first interacts with the new market.  | 0xf7c21600452939a81b599017ee24ee0dfd92aaaccd0a55d02819a7658a6ef635 0x27a3788d504af542681436bfdecf1823f7a8a691d04309ad33e6d3825e899746  |

### Attack Loss 
The total loss of two attacking transactions is ~$2.14M.
| Transaction | Amount |
| --- | --- |
| 0xf7c21600452939a81b599017ee24ee0dfd92aaaccd0a55d02819a7658a6ef635 | 1,156.9 $ETH(worth $2.088M) |
| 0x27a3788d504af542681436bfdecf1823f7a8a691d04309ad33e6d3825e899746 | $60K worth assets, including $MATIC, $UNI, $APE, $USDP, and $WETH. |

### Attackers
- 0x085bDfF2C522e8637D4154039Db8746bb8642BfF
- 0x5083956303a145f70ba9f3d80c5e6cb5ac842706
### Attacking Contract
0x052ad2f779c1b557d9637227036ccaad623fceaa
### Attacked Contract
- Proxy contract: https://etherscan.io/address/0x5fdbcd61bc9bd4b6d3fd1f49a5d253165ea11750
- Implementation Contract: https://etherscan.io/address/0x9dcb6bc351ab416f35aeab1351776e2ad295abc4#code
### Governance Contract
https://etherscan.io/address/0xdec2f31c3984f3440540dc78ef21b1369d4ef767
### Attacking Steps
TL;DR

Take one of the attacking transactions, 0xf7c216, as an example.
1. The hacker(0x085bDf) executes proposal OIP-22 first to add a new market oPEPE(0x5fdbcd).
![image.png](https://storage.googleapis.com/metatrust/website/post/image/1698907522497_image.png)
![image.png](https://storage.googleapis.com/metatrust/website/post/image/1698907532668_image.png)
2. One minute after the new market is added, launches a flash loan from AAVE and gets 4,000 $WETH
    1. Swaps 4,000 $WETH to 2,520,870,348,093 $PEPE
    2. Transfers all the $PEPE to the address 0xf8e153
![image.png](https://storage.googleapis.com/metatrust/website/post/image/1698907856990_image.png)
    3. Creates contract at the above address 0xf8e153, mints 50,000,000,000,000,000,000 $oPEPE with 1 $PEPE, redeems most of $oPEPE and leaves only **2 wei** to the market oPEPE.
    4. Transfers 2,520,870,348,093 $PEPE to the market oPEPE and enters the market with $oPEPE
    5. Borrow 334 $ETH
    6. redeem only 1 wei $oPEPE for 2,520,870,348,093 $PEPE due to precision loss issue.
        1. exchangeRate = (totalCash + totalBorrows - totalReserves) / totalSupply 
= 2,520,870,348,093,423,681,390,050,791,472 / 2 
= 1,260,435,174,046,711,840,695,025,395,**736**
        2. redeemAmountIn = 2,520,870,348,093,423,681,390,050,791,**470**
        3. redeemTokens = redeemAmountIn / exchangeRate = 1, due to the truncation. 
![image.png](https://storage.googleapis.com/metatrust/website/post/image/1698907716744_image.png)
        4. Liquidates borrower(0xf8e153)'s 881,647,840 wei $PEPE
        5. Redeems 856,961,701 wei $PEPE
  7. Repeats above steps from step b. to step f. borrows $USDC, $USDT, $PAXG, $DAI, $WBTC, and $LINK, and swaps them for $ETH.
3. Repays the AAVE flash loan with 4,002 $WETH and get a profit of 1156.9 $ETH.

### Root Cause
- On the one hand, the hacker is very familiar with the precision loss issue of compound-fork protocols and noticed the bug of Onyx protocol in advance, thus, the hacker probably monitors proposal OIP-22, once the proposal is active and ready to be executed, the hacker firstly executes it, only one minute later, launches the attack.
- On the other hand, the precision loss bug is the root cause of the attack. The hacker manipulates the `totalSupply` to be a tiny value, 2, and increases the totalCash to be extremely high value, 2520870348093423681390050791471, to amplify the `exchangeRate`, which results in calculation truncation when redeeming.
```solidity
    function exchangeRateStoredInternal() internal view returns (MathError, uint) {
        //...
        /*
        *  exchangeRate = (totalCash + totalBorrows - totalReserves) / totalSupply
        */
        uint totalCash = getCashPrior();
        uint cashPlusBorrowsMinusReserves;
        Exp memory exchangeRate;
        MathError mathErr;

        (mathErr, cashPlusBorrowsMinusReserves) = addThenSubUInt(totalCash, totalBorrows, totalReserves);
        if (mathErr != MathError.NO_ERROR) {
            return (mathErr, 0);
        }

        (mathErr, exchangeRate) = getExp(cashPlusBorrowsMinusReserves, _totalSupply);
        if (mathErr != MathError.NO_ERROR) {
            return (mathErr, 0);
        }
        //...
    }
```
### Recommendation
1. Do a detailed audit of the governance proposal, not limited to the smart contract, especially for the initialization scenario and other edge cases.
2. Consider adding a small amount of shares into the market initialization to prevent manipulation, especially for the compound-fork protocols.
3. Recommend adopting the monitoring system and pausing the protocol when emergency cases happen, if there is a monitoring system for Onyx, the second attack transaction that happened more than half an hour later could be prevented to decrease the loss. Alternatively, integrating a mempool blocking system would be beneficial. This system can effectively detect attack transactions in the mempool when attackers are executing their attacks, allowing for preemptive blocking to avoid losses.
 
### Fund Flow
As of the time of writing, attack(0x085bDf) transfers 1140 $ETH to the money-laundry protocol Tornado.Cash with another controlled address(0x4c9c86).
![image.png](https://storage.googleapis.com/metatrust/website/post/image/1698907665670_image.png)
Another attacker still keeps stolen tokens in the same wallet(0x508395).

### Similar Attack
The bug is similar to [the previous hack](https://x.com/HundredFinance/status/1647247792589471745?s=20) of Hundred Finance on 2023.04.15, which resulted in a loss of approximately $7 million.

TX: 0x6e9ebcdebbabda04fa9f2e3bc21ea8b2e4fb4bf4f4670cb8483e2f0b2604f451

### About MetaTrust Labs
MetaTrust Labs is a leading provider of Web3 AI security tools and code auditing services incubated at Nanyang Technological University, Singapore. We provide advanced AI solutions that empower developers and project stakeholders to protect Web3 applications and smart contracts. At MetaTrust Labs, we are committed to protecting the Web3 space so that builders can innovate with confidence and reliability.

Website: https://metatrust.io/

Twitter: https://twitter.com/MetatrustLabs

On Nov 1, 2023, our MetaScout [detected](https://x.com/MetaTrustAlert/status/1719660132240691257?s=20) that the lending protocol, @OnyxProtocol on Ethereum, was under a flash loan attack with a loss of $2.1M. The root causes are the proposal of adding a new market that was first executed by the hacker, and the precision loss issue of the compound-fork protocol. Here is a detailed exploit analysis by MetaTrust Labs to uncover how this all happened.

How Onyx's Governance and Vulnerability Became Hackers' Golden Shovels

MetaTrust Labs checked and scanned the trending token $TIP's contract address 0x0176b898e92e814c06cc379e508ceb571f70bd40. This report summarizes the security assessment, analyzing the key centralized roles, functionality, token distribution, and provides recommendations to improve the overall security posture of the contract.


# Contract Address 

0x0176b898e92e814c06cc379e508ceb571f70bd40

https://etherscan.io/token/0x0176b898e92e814c06cc379e508ceb571f70bd40


# Centralized Roles


- Owner: 0x34c6F1Ea29156ddcaEd5f9df9035195A5F279738

- Sell fee: 5%

- Buyer fee: 5% 

- Tax Wallet: 0x902D9627f7cA78Eb6A8cd5368B899eE934998915 - Currently has accumulated 269.7 ETH (worth $436,800)


# Centralized Functionality


The owner has sole authority over critical functionality like enabling trading, setting fees, withdrawing funds, and more.

- `enableTrading`: This function allows the owner to enable trading for the contract. When trading is enabled, buying and selling of the token are allowed. This function also sets tradingEnabled and swapEnabled flags to true.
- `excludeFromFees`: The owner can use this function to exclude or include addresses from fees. This is typically used to exempt certain addresses from transaction fees.
- `setAuthorizedEditor`: The owner can set or revoke authorized editor status for specific addresses. Authorized editors likely have special privileges within the contract.
- `excludeFromMaxTransaction`: The owner can exclude or include specific addresses from maximum transaction limits. This is used to set exceptions to the maximum transaction amount for certain addresses.
- `setMarketMakerPair`: The owner can set whether a given pair address is considered a market maker pair. Market maker pairs might have different rules or restrictions compared to regular addresses.
- `removeLimits`: This function allows the owner to remove certain limits that are active in the contract. This could include transaction amount limits and wallet balance limits.
- `send`: The owner can use this function to send funds from the contract to a designated tax wallet address.
- `lowerTaxes`: Authorized editors can use this function to lower the buy and sell fees. It checks that the caller is an authorized editor and that the new fees are lower than the current ones.
- `lowerSwapThreshold`: The owner can lower the swapTokensThreshold, which determines the amount of tokens needed in the contract to trigger a swap operation.
- `addLiquidity`: The owner can add liquidity to the contract by providing ETH. This function is typically used during the initial setup of the contract to provide liquidity for trading.


# Token Distribution 


The top 4 addresses hold 80.3% of the total token supply. The owner (0x34c6) holds 65% of the supply.
![piic.png](https://storage.googleapis.com/metatrust/website/post/image/1695379511729_piic.png)
https://etherscan.io/token/0x0176b898e92e814c06cc379e508ceb571f70bd40#balances


# Security Recommendations


The owner (0x34c6) is an EOA address holding 65% of tokens. It is recommended to replace the owner with a multi-sig wallet contract to mitigate the risks associated with a single address holding a majority of the supply.


**About Us**

At MetaTrust, our primary focus is on creating a secure infrastructure that caters to the needs of developers in the WEB 3.0 space. We offer an array of AI-Driven automation tools and security services to assist Web3 developers and project stakeholders in achieving a secure development environment.

[Website](https://www.metatrust.io/) || [Twitter](https://twitter.com/MetaTrustLabs) || [Telegram](https://t.me/metatrustlabs) || [Try MetaScan for FREE](https://app.metatrust.io/sign-up)

The owner of $TIP is an EOA address holding 65% of tokens, here are some centralization risks you should care.

Analyzing the Centralization Risks of TipCoin ($TIP) 

In a recent turn of events, Earning.Farm, a project deployed on the Ethereum blockchain, has fallen prey to a malicious attack due to contract logic vulnerabilities. As indicated by MetaTrust Alerts' Twitter post, the extent of the damage incurred by this attack has surged to around 288 ETH, equating to a staggering value of approximately $536,000 USD. It's noteworthy that all tokens have been transferred to a new wallet address, specifically 0xee4b3d.

The root cause of this vulnerability can be attributed to a flawed function within the "EFVault" contract, namely the "withdraw" function. This particular function, fraught with logic flaws, allows the user to burn the user's ENF_ETHLEV balance even if it is less than the expected amount of shares.


### Attacking Steps

1. The attacker procured 10,000 Ethereum tokens through a flash loan, subsequently depositing 80 of these tokens into the ENF_ETHLEV contract. This move granted the attacker ownership of 295e18 shares.
2. The attacker withdraws 295e18 shares from the ENF_ETHLEV contract by calling the withdraw function. Then, the "withdraw" function calls the withdraw function of the external contract "controller", retrieves 80ETH, and triggers the fallback function of the attacker's contract at the same time.
3. Within the confines of the fallback function, the attacker skillfully transferred (295e18-1000) ENF_ETHLEV tokens to a new wallet address, represented as 0xfd29f2. Consequently, the attacker incurred a mere loss of 1000 ENF_ETHLEV tokens.
4. The attacker converted the ENF_ETHLEV tokens residing within the 0xfd29f2 wallet into ETH. This enabled the assailant to both repay the flash loan and capitalize on the situation to reap profits.

One of the transactions executed in the course of this attack is depicted below:
https://etherscan.io/tx/0x878d8986ed05ab32cc01e05663d27ea471576d2baff1081b15ed5fb550f9d81b
![111.png](https://storage.googleapis.com/metatrust/website/post/image/1691638623982_111.png)
Check MetaTrust Alerts' tweet: https://twitter.com/MetaTrustAlert/status/1689196222048030721?s=20

**About Us**

At MetaTrust, our primary focus is on creating a secure infrastructure that caters to the needs of developers in the WEB 3.0 space. We offer an array of AI-Driven automation tools and security services to assist Web3 developers and project stakeholders in achieving a secure development environment.

[Website](https://www.metatrust.io/) || [Twitter](https://twitter.com/MetaTrustLabs) || [Telegram](https://t.me/metatrustlabs) || [Try MetaScan for FREE](https://app.metatrust.io/sign-up)

Earning.Farm fell victim to smart contract logic vulnerability, suffering loss of approximately 288 ETH. 

Earning.Farm Lost $536,000 Due to Logic Flaw in Smart Contract "Withdraw" Function

In a recent turn of events, the decentralized stablecoin protocol Curve faced a significant reentrancy attack resulting in severe losses. Here, MetaTrust Labs presents a security analysis of the incident and provides essential security recommendations.


### Event Recap

According to Curve Finance's official Twitter account, on July 31, 2023, some stablecoin pools (alETH/msETH/pETH) written using Vyper version 0.2.15 were subjected to a reentrancy attack. Curve Finance clarified that this attack was caused by a malfunctioning reentrancy lock in Vyper 0.2.15 and solely affected pools using pure ETH. Presently, Curve is assessing the extent of the damage, ensuring the safety of other pools.

Based on MetaTrust Labs' analysis, this vulnerability was introduced between August and October 2021, primarily due to the Vyper compiler versions 0.2.15/0.2.16/0.3.0. The root cause of the exploit was a compiler bug that resulted in ineffective reentrancy protection in the generated bytecode.

On the day of the attack, MetaTrust Labs published 3 alert tweets in the first time and informed one of the attacked projects, AlchemixFi, through twitter message, which was recognized and liked by the team.
![110.jpg](https://storage.googleapis.com/metatrust/website/post/image/1690861529974_110.jpg)

As per on-chain data, the Curve Finance stablecoin pool hack has led to cumulative losses of $52 million in projects like Alchemix, JPEG’d, and the CRV/ETH pool. The Curve Finance native token, CRV, has also taken a hit, experiencing a drastic intraday drop of over 15%.


### Root Causes

Curve Finance fell victim to this attack due to the use of Vyper, a smart contract programming language, with version 0.2.15. Unfortunately, this version contained a bug known as "malfunctioning reentrancy locks," which attackers exploited to cause the losses. The vulnerability faced by Curve Finance is categorized as a Language Specific flaw.

Language Specific vulnerabilities arise from defects or incompatibilities in the programming language or compiler itself. These types of vulnerabilities are challenging to detect and prevent since they result from issues with the underlying technical platform rather than developer oversight or logical errors. Moreover, such vulnerabilities may affect multiple projects or contracts utilizing the same language or compiler.

Vyper, as a Python-based smart contract programming language, aims to provide higher security and readability. It claims to be "security-first" and omits certain features, such as classes, inheritance, modifiers, and inline assembly, which could introduce security risks. Nevertheless, Vyper is not without flaws and may still have bugs or vulnerabilities that can impact contract security. In addition to the reentrancy lock fault faced by Curve Finance, Vyper has previously encountered issues like array overflows, integer overflows, and storage access errors.


### Security Suggestions

In response to the reentrancy attack on Curve Finance, several measures have been taken or proposed. Here are some potential security actions Curve could take:
1. Remove Liquidity: Users of affected pools can choose to remove liquidity to avoid further losses. Curve Finance has already provided a "Remove Liquidity" button on its official website to facilitate this process.
2. Upgrade Compiler: Contracts compiled with Vyper versions 0.2.15/0.2.16/0.3.0 should be upgraded to the latest version, Vyper 0.3.1, as it addresses the reentrancy lock issue. Additionally, employing other tools or methods for contract security verification, such as formal verification and code audits, is advisable.
3. Heightened Vigilance: Projects utilizing Vyper or any other programming language should exercise increased vigilance, closely monitoring language or compiler updates and vulnerability fixes, and taking necessary measures to safeguard their assets. Furthermore, when adopting new languages or technologies, thorough evaluations of their maturity and stability are essential to avoid blindly pursuing novelty or efficiency.


### Conclusion

The reentrancy attack on Curve Finance serves as a regrettable security incident and a thought-provoking lesson. In the realm of DeFi, security always takes precedence, and project teams must continually raise their awareness and capabilities to combat potential threats. In this ever-evolving landscape, even the smallest detail can become an attacker's point of entry.

**About Us**

At MetaTrust, our primary focus is on creating a secure infrastructure that caters to the needs of developers in the WEB 3.0 space. We offer an array of AI-Driven automation tools and security services to assist Web3 developers and project stakeholders in achieving a secure development environment.

[Website](https://www.metatrust.io/) || [Twitter](https://twitter.com/MetaTrustLabs) || [Telegram](https://t.me/metatrustlabs) || [Try MetaScan for FREE](https://app.metatrust.io/sign-up)

The reentrancy attack on Curve Finance serves as a regrettable security incident and a thought-provoking lesson.

Curve Cracked: How $52M Vanished in a Vyper Vulnerability

We analyzed Worldcoin's token $WLD smart contract [0x163f8c2467924be0ae7b5347228cabf260318753](https://etherscan.io/token/0x163f8c2467924be0ae7b5347228cabf260318753) and found some security concerns. Here are risks that you should keep alert.

## Centralized Risks


🔵 The mintOnce Function

The contract implements a centralized minting mechanism mintOnce, allowing the owner to mint tokens to multiple addresses in one transaction. This one-time function has already been called by the current owner.

The current owner is a 1/1 multisig wallet contract [0x59a0f98345f54bAB245A043488ECE7FCecD7B596](https://etherscan.io/address/0x59a0f98345f54bAB245A043488ECE7FCecD7B596), with only one owner eth:0xc534a745bFfaF9466Ed7B47fA23B0177b99A3e77. This means only one signature is needed to represent the owner to perform privileged operations.
![1.png](https://storage.googleapis.com/metatrust/website/post/image/1690267060289_1.png)

🔵 The setMinter Function

In addition, the contract also implements the setMinter function, allowing the owner to set a minter address. Currently the minter is zero address.
![2.png](https://storage.googleapis.com/metatrust/website/post/image/1690267821859_2.png)

🔵 The mintInflation Function

If the owner sets a non-zero minter, the minter can arbitrarily call mintInflation to mint unlimited tokens to any address.



## Token Distribution


Statistics show the first 6 addresses already hold 94.5% of the total supply. This indicates a highly centralized token distribution.
![3.png](https://storage.googleapis.com/metatrust/website/post/image/1690267832105_3.png)

In summary, the token contract has the following security risks:
1. The owner currently has only one signer, which reduces security control over the owner account.
2. There is a risk of unlimited token minting after a minter is set.
3. The token distribution is overly centralized with the top 6 addresses holding most tokens.

To mitigate these risks, here are our security suggestions:
1. Increase the number of signers for the owner to enforce multi-sig management.
2. Disable arbitrary settings of minters to prevent unlimited minting.
3. Adopt vesting or continuous distribution to reduce the centralization of token distribution.

Security is the cornerstone of a healthy blockchain ecosystem. We will continue monitoring project security, performing timely security risk alerts, to jointly maintain the security of blockchain.

**About Us**

At MetaTrust, our primary focus is on creating a secure infrastructure that caters to the needs of developers in the WEB 3.0 space. We offer an array of AI-Driven automation tools and security services to assist Web3 developers and project stakeholders in achieving a secure development environment.

[Website](https://www.metatrust.io/) || [Twitter](https://twitter.com/MetaTrustLabs) || [Telegram](https://t.me/metatrustlabs) || [Try MetaScan for FREE](https://app.metatrust.io/sign-up)

The current owner of $WLD is a 1/1 multisig contract with only one owner


Only 1 Owner of Multi-Signed Contract? Worldcoin May Involve Centralized Risks

iZiFinance is a decentralized finance protocol that leverages zkSync, a layer-2 scaling solution for Ethereum. zkSync enables fast and low-cost transactions on Ethereum, while preserving the security and composability of the layer-1 network. However, gas optimization is still an important aspect of smart contract development on zkSync, as it affects the performance and profitability of the protocol.

In this analysis, we will examine one of the core contracts of iZiFinance, iZiSwapPool.sol, and identify a simple way to reduce gas consumption by eliminating a redundant expression.


### The iZiSwapPool Contract

The iZiSwapPool contract implements the logic of liquidity pools and token swaps on iZiFinance. It conforms to the IiZiSwapPool interface, which defines the functions and events of the contract. One of the functions is modifyFeeChargePercent, which allows the owner of the contract (the factory) to adjust the fee charge percent for each pool. The fee charge percent is a parameter that determines the distribution of the swap fee between the liquidity providers and the protocol.

The code of the modifyFeeChargePercent function is as follows: 
![code.png](https://storage.googleapis.com/metatrust/website/post/image/1689589009758_code.png)
The function accepts a uint24 argument called newFeeChargePercent, which represents the new fee charge percent to be set. It also has some modifiers and requires statements to ensure that only the owner can invoke the function and that the newFeeChargePercent is valid.

### Code Analysis

This contract code is written in Solidity and represents a function that modifies a fee charge percent. It seems to have been designed in a secure manner, considering the restrictions applied before making the actual modification (lines 534-536). 

However, line 535 require(newFeeChargePercent >= 0, "FP0"); is indeed unnecessary. This is due to the fact that in Solidity, the uint (unsigned integer) data type cannot be negative. uint24 is an unsigned integer type that ranges from 0 to 2^24 - 1. Hence, checking if the newFeeChargePercent is greater than or equal to 0 is tautological, because by definition, an unsigned integer cannot be less than 0.

Therefore, this line constitutes a tautology and can be safely removed without affecting the functionality of the code or introducing any security vulnerabilities. The line immediately after it, require(newFeeChargePercent <= 100, "FP0");, is enough to ensure that the newFeeChargePercent is within the desired range (0-100).


### Centralized Risks

We also found some centralized risks that could compromise the security and trustlessness of the protocol. 
![output.png](https://storage.googleapis.com/metatrust/website/post/image/1689589064097_output.png)

### Security Suggestions

Here are 10 security tips for iZiFinance to take into consideration to better protect on-chain assets for users.
1. Impose timelocks on critical functions like setFarm() and setWrapToken() to only allow modification at a future specified time, giving the community time to discuss and reach consensus.
2. Require multi-sig approvals from multiple wallet addresses to invoke functions like enableFeeAmount() and newPool() that affect fees and rewards.
3. Implement role-based access control for functions like expandObservationQueue() and collectFeeCharged(), restricting invocation to designated roles.
4. Make core parameters like startBlock, endBlock, rewardPerBlock immutable at contract deployment, disallowing subsequent changes.
5. Establish a DAO governance structure where invocation of sensitive functions requires community proposals and voting.
6. Adopt a modular architecture with separation of duties, avoiding excessive centralization in any single module.
7. Build in an emergency stop mechanism with multi-sig authentication to halt the protocol if issues arise.
8. Conduct regular external security audits and promptly address findings to reduce centralized control risks.
9. Incorporate fuzz testing and other methods during development to identify and eliminate centralized control vulnerabilities.
10. Follow the principle of least privilege, granting roles and accounts only the minimum permissions necessary.

These risks stem from the fact that the contract owner may have excessive control over the parameters and functions of the contract, which could allow them to manipulate the protocol or harm the users. We hope that this article has provided some useful insights and security suggestions for improving the smart contract of iZiFinance.

**About Us**

At MetaTrust, our primary focus is on creating a secure infrastructure that caters to the needs of developers in the WEB 3.0 space. We offer an array of AI-Driven automation tools and security services to assist Web3 developers and project stakeholders in achieving a secure development environment.

[Website](https://www.metatrust.io/) || [Twitter](https://twitter.com/MetaTrustLabs) || [Telegram](https://t.me/metatrustlabs) || [MetaScan for FREE](https://app.metatrust.io/sign-up)

In this analysis, we will examine one of the core contracts of iZiFinance and identify a simple way to reduce gas consumption by eliminating a redundant expression.

Security Analysis Report: Centralization Risk in iziFinance Smart Contract


### Summary

On July 1st, 2023, an attacker exploited a vulnerability in the Biswap V3Migrator contract on Binance Smart Chain (BSC) and stole about $144,000 worth of tokens from unsuspecting users. The attacker used a fake token attack to manipulate the parameters of the migration function and siphon off the liquidity from users who approved their liquidity provider (LP) tokens to the V3Migrator contract. The exploit was possible because the V3Migrator contract did not validate the parameters when migrating from Biswap V2 to Biswap V3. It could have resulted in losses of tens of millions of dollars for its users if this attack had not been stopped in time.

### Transactions

The attacker executed three transactions to carry out the exploit:
https://bscscan.com//tx/0xe13ec0941580d3c286b46fa6566f20195bdd52b3d65fc7ff4a953a8fc774c6c4
https://bscscan.com//tx/0xe5c89e9ac217e4e16c2399f3597f7b5fbb73b45c1d3360788ee51ea2561def3a
https://bscscan.com//tx/0x8693a95f8481ba02ceaabed8e95b4e1eb8ac589c69c027c96b12ac5295714c3f

### Attacker

The attacker’s address is [[0xa1e31b29f94296fc85fac8739511360f279b1976](https://bscscan.com/address/0xa1e31b29f94296fc85fac8739511360f279b1976)]. 

### Attacking Contract

The attacking contract is [[0x1d448e9661c5abfc732ea81330c6439b0aa449b5](https://bscscan.com/address/0x1d448e9661c5abfc732ea81330c6439b0aa449b5)]. This contract was deployed by the attacker on June 30th, 2023, one day before the exploit. The contract has a simple logic that calls the V3Migrator contract with different parameters.

### Attacked Contract

The attacked contract is [[0x839b0afd0a0528ea184448e890cbaaffd99c1dbf](https://bscscan.com/address/0x839b0afd0a0528ea184448e890cbaaffd99c1dbf)]. This is Biswap’s V3Migrator contract that was deployed on June 28th, 2023. The contract is supposed to help users migrate their LP tokens from Biswap V2 to Biswap V3.

### Attacking Steps

The attacker exploited a flaw in the V3Migrator contract that allowed them to tamper with the parameters of the migration function. The attacking steps are as follows:
1. Victims approved LP tokens for the Biswap V3Migrator contract;
2. The attacker burned the victim’s V2 LP token and added V3 liquidity with fake tokens. At this step, the `token0` and `token1` of V2 LP were still in the V3Migrator contract;
3. The attacker burned the fake V2 LP token and added V3 liquidity with `token0` and `token1` of V2 LP. Finally, the surplus `token0` and `token1` that were not used to add the V3 liquidity were transferred back to the attacker. At the same time, the V3 liquidity in this step also belonged to the attacker.

### Root Cause

The root cause of the exploit is that Biswap’s V3Migrator contract did not validate the parameters when migrating from Biswap V2 to Biswap V3. Specifically, there is a significant issue in the contract:
The contract does not verify that the `token0` and `token1` parameters match with the actual tokens in the V2 LP token;
These issues allow the attacker to pass fake tokens and amounts to the migration function and steal the real tokens from the users who approved LP tokens to the V3Migrator contract.

### Key Code
![1280X1280.PNG](https://storage.googleapis.com/metatrust/website/post/image/1689067340006_1280x1280.PNG)


### Asset Loss

0xa1e31b29f94296fc85fac8739511360f279b1976 get a profit of ~$144,000

### Financial Flows

The attacker removed the liquidity and swapped tokens for $BNB 
![651882f2-4b7f-4d61-a5af-38688d719e94.png](https://storage.googleapis.com/metatrust/website/post/image/1689067391550_651882f24b.png)
Finally, the attacker transferred 603 $BNB into Tornadocash for money laundering.
![output.png](https://storage.googleapis.com/metatrust/website/post/image/1689067483975_output.png)

### PoC
![1280X1280 (1).PNG](https://storage.googleapis.com/metatrust/website/post/image/1689067431825_1280x1280-.PNG)

https://github.com/SunWeb3Sec/DeFiHackLabs/blob/main/src/test/Biswap_exp.sol

### Suggested Solution

Highly recommend users revoke their approval to Biswap V3Migrator from https://bscscan.com/tokenapprovalchecker

### Conclusion

The Biswap exploit is another example of how fake token attacks can be used to exploit DEXes on BSC. The exploit shows the importance of validating the parameters and balances of contracts that handle user funds. Users should also be careful when approving their tokens to third-party contracts and check the source code and audits of the contracts before using them.

As the leading web3 security service provider, MetaTrust Labs was the first to discover this attack and report it to Biswap on Twitter on July 1st. 
MetaTrust Labs also provided Biswap with two suggestions to stop the attack and prevent further losses:
- Ask users to revoke their approvals for the V3Migrator contract as soon as possible, so that the attacker could not access their LP tokens anymore;
- Delete their own tweet that promoted the V3 migration and informed users about the benefits of migrating their LP tokens, as this tweet could mislead users into falling victim to the attack.
![output (1).png](https://storage.googleapis.com/metatrust/website/post/image/1689067452779_output-1.png)
If this attack had not been stopped in time, all of Biswap’s migration contracts would have suffered losses of tens of millions of dollars. This would have been a devastating blow to Biswap and its users, as well as a serious setback for the development of DEXes on BSC.

**About Us**

At MetaTrust, our primary focus is on creating a secure infrastructure that caters to the needs of developers in the WEB 3.0 space. We offer an array of AI-Driven automation tools and security services to assist Web3 developers and project stakeholders in achieving a secure development environment.

[Website](https://www.metatrust.io/) || [Twitter](https://twitter.com/MetaTrustLabs) || [Telegram](https://t.me/metatrustlabs) || [MetaScan for FREE](https://app.metatrust.io/sign-up)

Attacker exploited a vulnerability in the Biswap V3Migrator contract on BSC and stole about $144,000 worth of tokens

How a Fake Token Attack Drained $144,000 from Biswap Users on BSC

This security report outlines Project Onchain Trade's potential vulnerabilities and centralization risks on token staking, rewarding and trading, which could pose significant threats to the integrity and security of the platform.

### Contract Centralized Risk


This smart contract encompasses several functions related to the management of a token staking and reward platform. Here's a centralized report outlining the core functions:

1. `addRevenueToken()`: This function is responsible for adding a new token as a revenue token. The token details are then added to the 'RevenueInfo' map and the 'revenueInfoList'.

2. `addRevenue()`: This function allows the contract owner to add revenue tokens, their amounts, and also updates the 'boost point'. It also ensures the stake token and reward balances are kept updated.

3. `updateScore()`: This function is for updating the score of a user. The score is computed based on the amount of reward the user has earned per unit time.

4. `addToken()`: This function allows the contract owner to add a new token to the pool of tokens for mining. The details of the token, including the reward per second and the start time, are added to 'PoolInfo'.

5. `setPoolInfo()`: This function allows the contract owner to set and update the pool info for a particular LP token, including the reward per second and the end time.

6. `addMintPool()`, `updateMintPool()`: These functions let the contract owner add a new mint pool or update an existing one, with details like the reward token, reward per second, start time, and end time.

7. `setUpdater()`, `setFastPriceEvents()`, `setPriceDuration()`, `setMinBlockInterval()`, `setMaxTimeDeviation()`,` setLastUpdatedAt()`, `setMaxDeviationBasisPoints()`, `setTokens()`, `setPrice()`, `setPrices()`, `setCompactedPrices()`: These functions allow the contract owner to set various parameters related to price events, timing, tokens, and token prices. 

8. `setOracle()`, `setRouter()`: These functions enable the contract owner to specify the Oracle and Router addresses.

9. `setMinExecFee()`, `setSystemRouter()`: These functions let the contract owner set the minimum execution fee and designate a system router.

10. `listPair()`, `setMaxTotalSize()`, `setPairStatus()`, `setTradingFeeRate()`, `setMaxLeverage()`, `setMarginRatio()`: These functions let the contract owner manage the pairing of tokens, maximum size, pair status, trading fee rate, maximum leverage, and margin ratio.

11. `setPriceFeed()`, `setFutureUtil()`, `setProtocolFeeTo()`: These functions enable the contract owner to set the price feed address, future utility address, and protocol fee recipient address.

12. `realizePairProtocoFee()`, decreaseInsuranceFund(): These functions let the contract owner or protocol fee recipient realize the pair protocol fee and decrease the insurance fund.


### Conclusion


The contract encompasses several functions related to the management of a token staking and reward platform. The contract owner has extensive control over platform parameters, token pools, reward rates, price feeds, and more. We have analyzed the contract code and identified potential vulnerabilities and risks that could affect the security and functionality of the platform. Practices should be taken to mitigate these issues and improve the quality and robustness of the contract.


**About Us**

At MetaTrust, our primary focus is on creating a secure infrastructure that caters to the needs of developers in the WEB 3.0 space. We offer an array of AI-Driven automation tools and security services to assist Web3 developers and project stakeholders in achieving a secure development environment.

[Website](https://www.metatrust.io/) || [Twitter](https://twitter.com/MetaTrustLabs) || [Telegram](https://t.me/metatrustlabs) || [MetaScan for FREE](https://app.metatrust.io/sign-up)

We've checked Onchain Trade's smart contract and found out there are potential vulnerabilities and centralization risks on token staking, rewarding and trading.

The Analysis of the Atomicals Market User Asset Loss

Blogs

The Analysis of the Atomicals Market User Asset Loss

When Hacking Goes Haywire, Raft's 1570 ETH Loss Takes a Cosmic Detour to the Black Hole

How Onyx's Governance and Vulnerability Became Hackers' Golden Shovels

Analyzing the Centralization Risks of TipCoin ($TIP)

Earning.Farm Lost $536,000 Due to Logic Flaw in Smart Contract "Withdraw" Function

Curve Cracked: How $52M Vanished in a Vyper Vulnerability

Only 1 Owner of Multi-Signed Contract? Worldcoin May Involve Centralized Risks

Security Analysis Report: Centralization Risk in iziFinance Smart Contract

How a Fake Token Attack Drained $144,000 from Biswap Users on BSC

Is token trading still secure? Centralization Risks in OnchainTrade Smart Contract

Products

Company

Legal

Social Media