Back to Blog

Deposit Less, Get More: yCREDIT Attack Details

Code Auditing
January 3, 2021

On January 2, 2021 (Beijing Time 07:25 am), our monitoring system ThunderForecast reported a series of suspicious transactions towards the yCREDIT smart contract. Then, we used the EthScope system developed by our research team to analyze these transactions and confirm that all reported transactions are malicious. In this blog, we illustrate the attack details.

Details

The attack is due to the number of tokens minted is inconsistent with the intended one. As such, the attacker can get many more yCREDIT tokens with lower price. Then these tokens can be sold to gain profits.

The vulnerable function is in the _deposit function of the StableYieldCredit contract.

In the following, we will use an attack transaction to illustrate the whole process.

The attacker first transferred 1e-8 WBTC and 331.335 yCredit tokens to the WBTC-yCREDIT Pair pool. Then the attacker deposited 0.5 WBTC to the StableYieldCredit contract to launch the attack.

Specifically, the _value is calculated using the amount (0.5) of the token (0x2260fac5e5542a773aa44fbcfedf7c193bc2c599 - WBTC) based on the price oracle provider ChainLink (line 480, _value is 1466786010075). The intention is to calculate the value of the deposited WBTC in USD. Then the contract will transfer the number of yCREDIT tokens (_value - fee) to the one who deposited the WBTC (the attacker). That's because the value of yCREDIT equals one USD (as designed by the system). Everything is fine except the attacker loses a small amount of fee.

Moreover, the contract will add the deposited WBTC to the WBTC-yCREDIT Pair pool. That's because if the deposited WBTC is locked into the contract, it will lose liquidity. As such, it first calculated the value of the token pair (WBTC to yCREDIT) that will be put into the pool. This value is calculated using the function _addLiquidity. Basically, it is calculated based on the existing reserves inside the pool. Since the pool only has 1e-8 WBTC and 331.335 yCREDIT tokens, the amountA calculated is 44 (amountB is 1466786010075). That means the attacker only spends 44e-8 WBTC (line 485) and gets 14667.86010075 - fee = 14594.52080025 yCREDIT tokens (line 493). At the same time, there is a small number of WBTC (1e-8 + 44e-8) and (331.335 + 14667.86010075) yCREDIT tokens leaving in the pool.

To get profits, the attacker can simply trade the gained 14594.52080025 yCREDIT tokens in exchanges. Interestingly, the process to gain profits in this transaction is far more complicated than necessary. We have also observed a clever attacking strategy in other transactions.

There are a serial of transactions involved in the attack, including (but not limited to) the following ones.

Update

2020/01/03: There is an new smart contract that fixes the vulnerability.

Timeline

  • 2021/01/01 23:25 UTC, attacks were captured by our system
  • 2021/01/02 16:20 UTC, this blog is released
Sign up for the latest updates
Harmony Cross-Shard ONE Mint + ~$47M Key Losses | BlockSec Weekly
Security Insights

Harmony Cross-Shard ONE Mint + ~$47M Key Losses | BlockSec Weekly

During the week of August 10-16, 2026, 5 notable security incidents are featured, involving approximately $47M in quantified losses, with the detailed analysis focused on a chain-implementation flaw in the Harmony Layer-1. Harmony suffered unauthorized minting of native ONE through a cross-shard receipt replay: destination shards derived the receipt spent-marker from unauthenticated MerkleProof.ShardID and BlockNum fields instead of the signed source header, so an already-credited receipt could be replayed with no matching source-shard debit. Approximately 3.01T ONE was forged, but its nominal value far exceeds the token's market capitalization and is neither realizable nor confirmed realized loss, so Harmony is excluded from the total; the ~$47M came from private-key compromises (Unknown Whale Wallet ~$25M, Kite ~$14M, and Coinsbuy ~$7.9M) plus a Fox business-logic flaw (~$117K).

~$1.6M Lost: Moke Token, LpdFi Exploits | BlockSec Weekly
Security Insights

~$1.6M Lost: Moke Token, LpdFi Exploits | BlockSec Weekly

During the week of August 3-9, 2026, 2 notable security incidents on BNB Chain resulted in approximately $1.6M in total losses, both from price manipulation. The highlighted LpdFi incident (~$697K) reused the same manipulable PancakeSwap pair reserves for both order valuation and interest redemption, letting the attacker inflate a position's principal and reshape the pool to redeem an oversized interest claim. Moke Token (~$906K) combined a manipulable spot price with duplicated LP dividend accounting to claim inflated MOKE and collect the resulting BNB dividends multiple times.

COLDCARD Incident: When a Wallet's "Random" Seed Wasn't Random
Security Insights

COLDCARD Incident: When a Wallet's "Random" Seed Wasn't Random

A silent build-and-integration bug in COLDCARD firmware routed Bitcoin seed generation onto a software RNG fallback, whose weak randomness left wallet seeds recoverable offline. Because the weakness is in the seed itself, a firmware update cannot undo it; verified sweeps reached 1,405 BTC (~$91M) by 7 August 2026, with private-channel estimates as high as 2,055 BTC.

Best Security Auditor for Web3

Validate design, code, and business logic before launch. Aligned with the highest industry security standards.

BlockSec Audit
Deposit Less, Get More: yCREDIT Attack Details