On August 7th, 2025, an attack occurred on the SparkDEX Perpetual Exchange on the Flare blockchain. The hacker exploited a reentrancy vulnerability in the SparkDex Perpetual Exchange smart contract and successfully launched three attacks within 40 minutes. The root cause of this vulnerability is that while the platform was sending position profit (debitTraderProfit), it triggered the attacker-controlled contract’s fallback function, allowing a reentrant call to removeMargin to withdraw margin. The subsequent normal margin transfer did not use the updated position state, which allowed the attacker to withdraw margin again and caused losses to the platform. The following figure describes the brief process of the hacker’s attack.

Due to the prompt attention of the SparkDex team to the abnormal behavior, the smart contract was halted, and the hacker’s assets were frozen. As a result, no users suffered any financial losses, and the hacker incurred a loss of approximately $80,000. This article will provide a detailed retrospective of the entire attack process and analyze the vulnerabilities in the smart contract.

SparkDex is a decentralized exchange (DEX) operating on the Flare blockchain, serving as a core DeFi component within the Flare blockchain ecosystem. It was launched by Flare Networks Ltd. around 2023, with the SparkDEX Perpetual Exchange introduced towards the end of 2024. Flare Networks Ltd. was established in 2017 and is headquartered in London, UK. The company focuses on building scalable blockchain platforms and addresses blockchain data and interoperability challenges through innovative protocols such as FTSO (Flare Time Series Oracle).

Timeline

2025–08–06 03:44:34 The hacker transferred gas fund to the account.

2025–08–06 03:57:31–2025–08–06 05:37:47 The hacker transferred USDT, the attack funds, valued at approximately 80,000 USD, from ARB and ETH to the account on the Flare blockchain.

2025–08–07 03:24:40–03:58:04 The hacker exchanged USDT for FLR.

2025–08–07 03:56:51 The attack contracts were deployed. There were three contracts in total, including one control contract and two operation contracts responsible for conducting the attack.

2025–08–07 04:12:19 The hacker prepared for the attack by opening long and short positions for ETH-USD with 1x leverage, each worth around $40,000.

2025–08–07 04:45:57, 05:06:24, and 5:20:59 The hacker launched three attacks, with profits of approximately 38,000 USD, 56,000 USD, and around 80,000 USD for the first, second, and third attacks, respectively.

2025–08–07 05:26:28 The project team frozen the contracts.

2025–08–07 08:24 An announcement was made to halt perpetual contract trading.

2025–08–07 09:27 A security notice was issued mentioning the safety of user funds.

Vulnerability Analysis

This section is primarily divided into two parts. In the first part, the attack process is analyzed, while in the second part, the cause of the vulnerability is examined through code analysis.

Before a detailed analysis, let’s first introduce the basics of the SparkDex Perpetual smart contracts. The SparkDex Perpetual smart contracts can be broadly divided into three parts, including Core Trading, Governance & Configuration, External System Integration. Core Trading mainly consists of smart contracts related to trading, including OrderBook.sol (Order lifecycle management), Executor.sol (Order execution and liquidation), PositionManager.sol (Position and margin management) and Store.sol (Asset and Liquidity management); Governance and Configuration mainly includes smart contracts related to governance, including AddressStorage.sol for contract registration and Governable.sol; External System Integration contains something related to price oracle, funding tracker, trading validation, referrals and discounts. Refer to the diagram below.

Attack Process

This attack process can be summarized as follows: the attack occurred while the attacker was closing a position. The normal process for closing a profitable position on the SparkDex Perpetual platform involves two parts: transferring profit and transferring margin. In the first part, the Store contract of SparkDex Perpetual, while transferring the position profit to the attacker (debitTraderProfit), triggered the fallback function of a contract controlled by the attacker, allowing the attacker to reenter from the contract’s fallback and call the PositionManager contract’s removeMargin function to withdraw margin once. In the second part, the PositionManager contract did not use the updated position state when transferring margin to the attacker, allowing the attacker to withdraw margin again.

The main contracts involved in the entire attack process are as follows:

1. Control Contract (0xE0fa..0e): The initiator of the attack, controlling other contracts to execute the entire attack.
2. Operation 1 Contract (0x4eB3..A0) and Operation 2 Contract (0xc2BE..96): Responsible for specific attack actions, including opening positions, closing positions, triggering vulnerabilities, and more.
3. Orderbook Contract (0xE9dD..3a): The Orderbook contract of StarkDex Perpetual Exchange, responsible for maintaining the order book.
4. Executor Contract (0x87D5..C2): The Executor contract of StarkDex Perpetual Exchange, responsible for executing orders, settlements, and more.
5. PositionManager Contract (0x8ebe..Af): The PositionManager contract of StarkDex Perpetual Exchange, responsible for managing position information.
6. Store Contract (0xF59b..68): The Store contract of StarkDex Perpetual Exchange, responsible for managing various system states, including positions, assets, and more.

The pre-attack steps:

1. The hacker evenly distributed the FLR funds to the Operation 1 Contract and Operation 2 Contract for the subsequent opening of positions by both contracts.

Based on the diagram below, a typical attack process unfolds as follows:

1. Control Contract (0xE0fa..0e) Opens Positions through Operation Contracts: Operation 1 contract (0x4eB3..A0) opens the ETH long position and Operation 2 contract (0xc2BE..96) opens the ETH short position
2. Control Contract (0xE0fa..0e) Attempts to Close the Pre-Opened Positions: Since both positions were opened simultaneously, at the time of closing, there is a high probability that one position will be profitable while the other incurs a loss.

2.1 If closing the losing position, the vulnerability is not triggered.

2.2 If closing the profitable position, the vulnerability is triggered. The key steps related to transferring funds during the closure of a profitable position are as follows:

a. Calculate PNL and transfer the PNL to the user. In this diagram, transferring the PNL to the Operation 2 Contract triggers a CALLBACK in the contract. Through reentry, the hacker then invokes the removeMargin function of the PositionManager to reduce the position’s margin, which is subsequently transferred to the user by the PositionManager Contract via the Store Contract.

b. Transfer the remaining margin after deducting fees to the user. The PositionManager Contract transfers the remaining margin after deducting fees to the user. Despite the hacker extracting the margin through the reentrancy vulnerability in the decreasePosition, the pre-calculated “remaining margin after deducting fees” at this stage is not reevaluated based on the latest position, leading the PositionManager Contract to transfer the margin a second time to the user, resulting in losses for the StarkDex Perpetual Exchange platform.

3. Control Contract (0xE0fa..0e) Rebalance the balances of Operation 1 and Operation 2 Contracts: Ensures that the balances of the two contracts are equal.

4. As the Balances of Operation 1 and Operation 2 Contracts Increase with Each Attack: The hacker can repeat this operation, and with each attack, the profits will continue to grow.

The following figure is the calltrace of one of the attack transactions, which clearly shows the occurrence of reentrancy:

Code Analysis

Let’s focus on the implementation of the decreasePosition function. During the process of reducing positions with PNL > 0, the function debitTraderProfit is used to transfer profits to the user. In a normal scenario, debitTraderProfit only transfers PNL to the user. However, in this attack, the hacker extracted the margin by reentering removeMargin.

After debitTraderProfit transfers profits to the user, the PositionManager transfers the margin minus the fees based on the reduced position to the user. The amount to be transferred is amountToReturnToUser, which is calculated at the beginning of decreasePosition and is not updated due to the hacker extracting the margin through reentry in removeMargin, resulting in the second transfer of the margin to the hacker.

The removeMargin function is an externally callable function that reduces the margin of a specified position based on the user’s request.

Conclusion

SparkDex Perpetual Exchange is not a fork of GMX, but similar to the reason for the attack on GMX, the core issue lies in the reentry triggered by transferring funds to users during the position reduction process.

Since the hacker used the profits from the first three attacks for the subsequent openings, when the SparkDex administrators froze the contracts, the hacker’s positions were still open. This resulted in not only the profits from the initial three attacks being locked but also the initial capital being trapped. As a result, the platform did not suffer losses, and the hacker incurred a loss of approximately $80,000 in initial capital.