# DFXFinance - A Case Study

By [Ironblocks](https://paragraph.com/@ironblocks) · 2024-01-14

---

DFXFinance $4M Hack | [Tx on Etherscan](https://etherscan.io/tx/0x6bfd9e286e37061ed279e4f139fbc03c8bd707a2cdd15f7260549052cbba79b7)

TL;DR
=====

In this case study we’ll take a look at the underlying mechanism which was used to exploit [DFXFinance](https://dfx.finance/) in the past, and show how Ironblocks’ Firewall would have prevented it.

Introduction
============

DFXFinance is a protocol designed for optimally trading Fiat backed stablecoins, using real-word foreign-exchange price feeds. Like most decentralized exchange protocols, DFXFinance allowed its users to deposit the stablecoin tokens in exchange for Liquidity Pool tokens. The protocol also supported Flashloans - a method that allows users to “borrow → use → return” assets in a single transaction, and like most Flashloans providers, DFXFinance charged a small fee for users who took Flashloans. It’s worth noting that Flashloans are not required for the protocol’s day to day operation and were likely added as another incentive for users to engage with the protocol.

This core functionality of exchanging Liquidity Pool tokens to and from stablecoin tokens - along with the Flashloan feature - ended up being exploited, causing the loss of $4M.

Business Rule Violation
=======================

Let’s consider the business rules that were put in place regarding the Flashloan and tokens exchange.

1.  Every time you deposit a stablecoin _(USDC for example)_ you would get back Liquidity Pool tokens.
    
2.  If you took a Flashloan, the entire amount + fees need to returned before the transaction is completed
    

#### **Normal Execution**

In a normal execution scenario, a transaction would:

1.  Take a Flashloan _(Let’s say 10k USDC)_
    
2.  Use the Flashloan
    
3.  Return the Flashloan _(10k USDC + small fee)_
    
4.  The smart contact validates that the Flashloan is back in the
    
5.  End the transaction _(optimistically, you would make some profit from using the Flashloan)_
    

![](https://storage.googleapis.com/papyrus_images/9aca246602e5bb15a1f6a32134539f69b5dde0ca3edb4c8e25d2a4969649a579.png)

#### **Malicious Execution**

Since there are no business rules in place to prevent you from returning a Flashloan as a “deposit” _(instead of returning it through a normal Flashloan callback)_:

1.  Take a Flashloan _(Let’s say 10k USDC)_
    
2.  **Deposit** the entire amount _(plus some fee)_
    
3.  The deposit caused the pool to mint USDC\_XIDR tokens
    
4.  The smart contract validates that the Flashloan is return in full _(which it is)_
    
5.  The transaction ends **with the attacker gaining minted USDC\_XIDR tokens**
    
6.  The attacker can now normally swap these tokens for stablecoins, **essentially depleting the pool**
    

![](https://storage.googleapis.com/papyrus_images/af06183c67f2d044e888d33a152c67ecfb9a2f27c1af342eee07ca6fd8b18456.png)

Exploratory Research
====================

In our research, we found that there are no real-world use cases where a Flashloan would be followed by a deposit in 2 consecutive steps.

Using our **Approved Patterns Policy** the hack would have been prevented - as the malicious sequences would not have been allowed to go through.

Powered by our advance AI security engine, this policy will only allows transactions to go through if they interact with your protocol in a safe way. The engine provides a list of function calls that are allowed to be performed in sequence on your protocol.

Any transaction that performs functions calls outside the allowed list will be blocked.

![fd](https://storage.googleapis.com/papyrus_images/25fdb2bb6c330fc270e93037d5faded4dae410930cf39ec70cde71c7f6e30b06.png)

fd

* * *

> Ironblocks is the leading security provider in Web3.  
> Learn more at [www.ironblocks.com](https://www.ironblocks.com)

---

*Originally published on [Ironblocks](https://paragraph.com/@ironblocks/dfxfinance-a-case-study)*