Table of Contents
- 1 Overview
- 2 About Spartan Protocol
- 3 Root Cause of the Hack
- 4 Technical Analysis of the Hack
- 5 Stolen Fund Details
- 6 Hack Aftermath
- 7 Similar Hacks
- 8 Lessons Learnt
- 9 Conclusion
On May 1, 2021, Spartan Protocol, a DeFi protocol for synthetic assets on the Binance Smart Chain (BSC), suffered a significant security breach.
The hack, resulting in over $30 million in losses, was executed by exploiting a flaw in the protocol’s liquidity share calculation.
This vulnerability was manipulated to inflate the pool’s asset balance, enabling the withdrawal of a disproportionately large amount of assets. The attack methodology was unique in its approach, diverging from common flash loan attacks seen in the DeFi space.
About Spartan Protocol
Spartan Protocol, established as a liquidity platform within the decentralized finance (DeFi) ecosystem of Binance Smart Chain, specializes in the creation of synthetic assets.
It is notably recognized for its adaptation of the UniswapV2 protocol, with a distinctive modification in its fee mechanism to incentivize liquidity providers, especially during periods of liquidity scarcity.
This system imposes higher fees on larger volume trades, with Spartan Protocol’s pairs being analogous to those in UniswapV2, allowing users to engage in liquidity provision and redemption.
Despite its innovative approach and significant role in BSC’s DeFi landscape, the protocol suffered a monumental setback due to the aforementioned hack.
Root Cause of the Hack
Token Address: 0x3b6e77722e2bbe97c1cfa337b42c0939aeb83671](https://bscscan.com/address/0x3b6e7772
The Spartan Protocol hack was not a typical exploit involving AMM-based oracle price feeds but was primarily a consequence of flawed logic in the protocol’s liquidity share calculation, particularly in the removeLiquidity() function.
Vulnerability: The Improper Liquidity Share Calculation
The specific hack capitalized on inflating the asset balance of the pool before burning an equivalent amount of pool tokens, thereby claiming an unreasonably large amount of underlying assets. This vulnerability stems from the calcLiquidityShare() function querying the current balance, which can be artificially inflated for manipulation. A more secure design would have been to use cached balances in baseAmountPooled/tokenAmountPooled.
Technical Analysis of the Hack
Hacker Add: https://bscscan.com/address/0x3b6e77722e2bbe97c1cfa337b42c0939aeb83671
Initial Preparation: Flash loan Acquisition
Flashloan from PancakeSwap: The attacker initiated the exploit by borrowing a flash loan of 100K WBNB from PancakeSwap, which would be returned with an additional 260 WBNB as a fee at the end of the attack. First Phase of Pool Manipulation
Repeated WBNB to SPARTAN Swaps
- Series of Swaps: The attacker conducted five swaps from WBNB to SPARTAN through the exploited Spartan pool.
- Swap Details: Each swap involved different amounts of WBNB, resulting in varying quantities of SPARTAN being exchanged.
- Total Assets Acquired: Through these swaps, the attacker accumulated a total of approximately 2,536,613.206 SPARTA, alongside 11,853.332 WBNB.
- Minting Pool Tokens: The assets were then added to the pool, minting 933,350.959 SPT1-WBNB pool tokens.
- Bypassing Slippage Mitigation: It appears that the attacker used repeated calls to bypass the pool’s built-in slippage mitigation measures.
Second Phase of Pool Manipulation
Additional WBNB to SPARTAN Swaps
- More Swaps: The attacker carried ten more swaps from WBNB to SPARTAN.
- Acquisition of SPARTA: Each of these swaps involved slightly smaller amounts of WBNB, cumulatively resulting in approximately 2,639,121.977 SPARTA.
Inflating the Asset Balance
Transfer of Assets to Pool
Inflation of Pool’s Balance: The attacker then transferred 21,632.147 WBNB and all SPARTA acquired from the previous step into the pool.
Purpose: This action inflated the pool’s asset balance, setting the stage for the next phase of the exploit.
Burning Pool Tokens for Withdrawal
- Withdrawal of Liquidity: The attacker burned the 933,350.959 pool tokens to withdraw liquidity.
- Disproportionate Asset Withdrawal: Due to the inflated pool balance, the burn operation led to the withdrawal of 2,538,199.153 SPARTA and 20,694.059 WBNB.
- Profit Calculation: Notably, the initial deposit was only 11,853.332 WBNB, indicating a significant profit from this transaction. Repeating the Exploit
Additional Liquidity Addition and Withdrawal
- Further Manipulation: The attacker added the assets obtained from the previous withdrawal back into the pool.
- Minting and Burning Pool Tokens: This resulted in the minting of 1,414,010.159 pool tokens, which were immediately burned to withdraw 2,643,882.074 SPARTA and 21,555.697 WBNB.
- Continued Fund Drainage: These steps were repeated multiple times to continue draining funds from the pool.
Final Step: Returning the Flashloan
Flashloan Repayment: To conclude the attack, the original flashloan of 100K WBNB was returned to PancakeSwap, along with the agreed fee of 260 WBNB.
This sophisticated attack on Spartan Protocol demonstrates a methodical and calculated approach to exploiting a specific vulnerability in the protocol’s liquidity share calculation. The attacker meticulously executed a series of swaps and manipulations to inflate the pool’s asset balance, followed by burning pool tokens to withdraw a disproportionately large amount of assets. The careful repetition of these steps resulted in a significant extraction of funds, leading to a loss of over $30 million from the pool.
Stolen Fund Details
The Spartan Protocol hack resulted in a loss exceeding $30 million. The funds stolen from the pool were systematically moved through various addresses, as is common in such exploits, to obfuscate the trail of the stolen assets.
Spartan Protocol acknowledged the attack in a tweet, mentioning that the attacker used $61 million in BNB to exploit the pools through an unknown economic exploit path, leading to approximately $30 million withdrawal from the pools.
Impact on SPARTA Token
The value of Spartan Protocol’s native token, SPARTA, plummeted by 30% to $1.17 following the hack. This decline was not just in USD value but also in its value compared to major cryptocurrencies like Bitcoin and Ethereum, dropping over 29% and 31.4%, respectively.
Wider Impact on DeFi
The incident is noted as one of the largest monetary exploits in decentralized finance (DeFi) history. This event and other recent exploits in the DeFi space highlight the vulnerabilities present in this emerging field.
Comparison with Other DeFi Hacks
The Spartan Protocol exploit is ranked as the sixth-largest in terms of monetary loss in DeFi history, according to Rekt.
This attack is preceded by other significant DeFi exploits such as EasyFi’s $59 million, Uranium Finance’s $57.2 million, KuCoin’s $45 million, Alpha Finance’s $37.5 million, and Meerkat Finance’s $32 million.
Pattern of Recent Exploits
This attack followed closely on the heels of another significant exploit on the Binance Smart Chain’s DeFi exchange, Uranium Finance, which lost over $50 million in a similar exploit on April 28. This pattern of exploits within a short timeframe underlines systemic vulnerabilities within the DeFi sector on the Binance Smart Chain.
The Spartan Protocol hack serves as a crucial lesson in the importance of robust smart contract design and security in the DeFi space. To overcome vulnerabilities like those exploited in this hack, several technical measures and best practices can be adopted:
Rigorous Security Audits and Code Reviews
- Conduct thorough security audits of all smart contracts, particularly those involving complex financial mechanisms like liquidity pools. Engage reputable third-party auditors who can scrutinize the code for potential vulnerabilities.
- Implement regular code reviews and updates. Peer reviews by experienced blockchain developers can help identify and rectify potential flaws.
Improving Liquidity Share Calculation Logic
- The core issue in the Spartan Protocol hack was the flawed logic in the
calcLiquidityShare()function. To prevent such issues, ensure that liquidity calculations are based on locked or cached balances rather than current balances which can be artificially inflated.
- Implement mechanisms to verify the consistency and integrity of the liquidity pool’s state before and after transactions.
Enhanced Slippage Mitigation
- Implement more robust slippage control mechanisms. This can include checks to limit the maximum allowable price impact per transaction.
- Establish tighter tolerance levels for transaction slippage to prevent manipulation through small, repeated transactions.
Flash Loan Attack Mitigation
- Although flash loans are a legitimate tool in DeFi, they can be used maliciously, as seen in this hack. Protocols should incorporate flash loan attack mitigation strategies such as using Oracle time-locks to delay price updates or requiring additional collateral for large operations.
- Continuous monitoring for unusual activity patterns, like repeated transactions in a short time frame, can help in early detection of potential exploits.
Enhanced Monitoring and Anomaly Detection
- Implement real-time monitoring systems to track on-chain activities, flagging unusual patterns or suspicious behaviors.
- Set up alerts for significant changes in pool balances or token prices, which could indicate an ongoing exploit.
Regular Protocol Stress Testing
- Conduct stress tests under various scenarios to evaluate the protocol’s attack resilience.
- Simulate worst-case scenarios, including flash loan attacks, to test the system’s response and recovery procedures.
Community Involvement and Transparency
- Engage the community in vulnerability discovery programs, like bug bounties, to encourage ongoing scrutiny by independent security researchers.
- Maintain transparency with the user base, especially regarding the steps taken to secure the protocol and respond to vulnerabilities.
The Spartan Protocol hack highlights critical vulnerabilities in DeFi protocols and underscores the importance of thorough security measures.
It demonstrates how a single vulnerability in a smart contract can lead to substantial financial losses. Future security in blockchain and DeFi can be significantly enhanced by employing diligent practices, including regular audits by reputable firms like ImmuneBytes, to identify and mitigate such vulnerabilities before they can be exploited.