Velocore's exploit and decentralization problem

Velocore experienced a security breach on June 2nd, 2024, resulting in financial losses approximating $6.8 million in ETH. The root cause of this compromise was due to vulnerabilities within the Balancer-style CPMM pool contract.


After a hacker attack, the Ethereum Layer 2 blockchain Linea decided to halt block production, highlighting the need for Layer 2 projects to prioritize decentralization early on, as stated by Alex Gluchowski, CEO of Matter Labs.

In a post, Linea explained that on June 2nd, hackers successfully exploited the decentralized exchange Velocore based on Linea, transferring over $2.6 million worth of Ethereum (ETH) from Linea, which was launched by Consensys.

Following the incident, Linea resumed block production but decided to stop the zkEVM blockchain, indicating the necessity for Ethereum layers to be decentralized, a point emphasized by Gluchowski.

“Decentralized orderers are not optional. Every serious L2 stack must make it a priority,” said Gluchowski, whose company is one of Linea’s competitors in the zkSync space.

Declan Fox, the product manager of Linea, responded by agreeing that decentralization is not a choice but emphasized that the network is on a solid path to achieving decentralization faster than many competitors.

“Considering that many Rollup frameworks that started more than two years before us are not leading, I am very satisfied with our pace.”

In April, Linea announced the “Linea Journey: Surge” campaign, aiming to increase the total value locked on Linea to $3 billion. According to L2BEAT, the current value locked on the blockchain is just over $1.2 billion.

However, an observer criticized the company for setting such targets in light of the recent hacking incident.

The halt of Linea was an “unavoidable” action, according to the team, who had no choice but to stop their sequencer to prevent more funds from being bridged.

“This was the last resort to protect Linea users.”

Linea stated they received a hacker notification from Hexagate, which helped track the stolen user funds, vulnerable smart contracts, and exploiter addresses. Linea mentioned they could not immediately contact Velocore as it was “the middle of the night” in their timezone. “Like other L2s, we are still in the ‘training wheels’ phase, which gives us available safety measures.”

The hacker exploited the DEX Velocore based on Linea, transferring over $2.6 million worth of 700 Ethereum from Linea via a third-party bridge.

The sequencer was paused between blocks 5081800 and 5081801.

The company emphasized its future plans to decentralize the Linea network, including its sequencer, which will prevent the company from halting block production and reviewing addresses.

Meanwhile, Velocore stated they are working with relevant external networks to distribute compensation to affected victims.

Linea stressed that its network remains safe and reliable.

Consensys launched Linea in August 2023, attracting over 50 partners and transacting over $26 million worth of Ethereum.

Almost all Ethereum Layer 2 solutions remain centralized, including Base.

According to L2BEAT data, Coinbase is currently the only orderer for Base. However, the company also claims it intends to gradually decentralize Base over time.

Affected Contracts
All volatile pools(CPMM) in Linea and zkSyncEra Velocore are affected. No stable pools are affected. Velocore shared the same vulnerabilities. Blade, an advanced fork of Velocore, does not share this vulnerability as it uses simple XYK pool instead of our CPMM pool.

The primary cause of the incident was faulty logic within the ‘velocore__execute()’ function of the ConstantProductPool. When a user makes a swap on Velocore, the Vault contract makes an external call to this function to calculate the result of the swap.

Vulnerability in Fee Rate Calculation Logic
The ‘feeMultiplier’ is a variable in ‘ConstantProductPool’ that increases whenever a withdrawal occurs and resets to 1 after a block. This multiplier was introduced to prevent bypassing fees by withdrawing and then depositing, effectively making a swap without fees. This factor gets multiplied with the fee rate to calculate the actual fee (‘effectiveFee1e9’).

uint256 effectiveFee1e9 = fee1e9;
if (lastWithdrawTimestamp == block.timestamp) {
 unchecked {
 effectiveFee1e9 = (effectiveFee1e9 * feeMultiplier) / 1e9;
 }
}

The vulnerability here is that `effectiveFee1e9` was allowed to exceed 100%, causing subsequent logic to malfunction.

Underflow Potential During Single-Token Withdrawal
Velocore allows users to withdraw LP into a single token. As this is effectively a swap from the other tokens into one token, the calculation involves applying a fee to the other tokens:

unchecked {
 uint256 unaccountedFeeAsGrowth1e18 = k >= 1e18
 ? 1e18
 : rpow(1e18 - ((1e18 - k) * effectiveFee1e9) / 1e9, _sumWeight - sumUnknownWeight - sumKnownWeight, 1e18);
 requestedGrowth1e18 = (requestedGrowth1e18 * unaccountedFeeAsGrowth1e18) / 1e18;
}

`k` is the liquidity growth rate; a value greater than 1e18 indicates a deposit, and less than 1e18 indicates a withdrawal.
- `unaccountedFeeAsGrowth1e18` is the fee factor, supposed to be between 0 and 1e18, inclusive. This value represents liquidity shrinkage after withdrawing fees.
- `requestedGrowth1e18` is `k * unaccountedFeeAsGrowth1e18`, representing overall liquidity change used for calculating actual token in/out amounts.

The problem is that `effectiveFee1e9` being greater than 100% can cause `1e18 — ((1e18 — k) * effectiveFee1e9)` to underflow, changing a withdrawal into a large deposit.

Lack of Caller Checking in `velocore__execute`
There was an additional vulnerability where `velocore__execute()` does not verify whether the caller is the Vault or not. This made the exploit easier, though the attack would have been possible without this flaw.

Actual Exploit
The attacker sourced funds from Tornado, executed the exploit, bridged the funds with Across Bridge, and then deposited them back into Tornado.

The attacker first directly called `velocore__execute()`, simulating large withdrawals. This caused the `feeMultiplier` to increase to the point where `effectiveFee1e9` became greater than 100%.The attacker then used a flash loan to obtain LP tokens and withdrew most of the tokens with them, contracting the pool size.

Finally, the attacker performed a small single-token withdrawal, which minted an abnormally large amount of LP tokens due to the underflow mentioned above, allowing the attacker to repay the flash loan.

Relevant Transactions and Addresses :

Final fund destination — 0xe4062fcade7ac0ed47ad794028967a2314ee02b3
EOA —
0x8cdc37ed79c5ef116b9dc2a53cb86acaca3716bf
0xd8c465ecd8c6f1a0c114890f1ef553f82e59d274
Contracts —
0xed4e130f6f9e68918996f7e1e46a3306b3e12cec
0xb7f6354b2cfd3018b3261fbc63248a56a24ae91a
0xc030fba4b741b770f03e715c3a27d02c41fc9dae
0xf7f76b30a301524fe76508546B1e3762eF2B9267
Txs — Tx1 Tx2 zksync

The dev received a critical security alert from Cyvers after the first Linea exploit. Since they revoked their admin rights from the vault last year, they couldn’t upgrade the proxy to completely block transactions. Instead, they implemented a semi-pause function by setting the fee to the maximum, which would interrupt swaps while allowing withdrawals in case of an emergency. However, in this case, the proper mitigation was to set the fee to 0%, not to max. Unfortunately, they realized this only after reverse-engineering the transactions, and by then, it was too late.

To mitigate the issue and prevent further damage, they have set the fee to 0 for all pools. Consequently, the ‘effectiveFee1e9’ value will always be 0, effectively disabling the vulnerability described above. This measure ensures that the exploit cannot be leveraged anymore.

In light of the recent incident impacting the protocol, Velocore is committed to taking comprehensive measures to resolve the situation and ensure the security and trust of the users.

They are actively investigating to track down hackers while trying the on-chain negotiation, having requested cooperation from various protocols and central exchanges to investigate the attacker’s activities. They are also in close communication with their security partners and foundations. Based on the results of these investigations and our collaboration with partners, they will continuously adjust our future plans.