~$15.9M Lost: Trusted Volumes & More | BlockSec Weekly

During the past two weeks (2026/04/27 - 2026/05/10), BlockSec identified multiple attack incidents across several blockchain ecosystems. The table below lists 11 notable incidents with total estimated losses of approximately $15.9M.

Three incidents are selected for in-depth analysis based on attack novelty, financial impact, and security implications:

• Aftermath Finance: a real-world exploit on a perpetual DEX, where a subtle signed/unsigned semantic mismatch in fee validation led to the complete drainage of protocol funds.
• Trusted Volumes: significant financial impact (~$5.87M) and a clear demonstration of authorization mismatch in RFQ settlement logic.
• Wasabi Protocol: an infrastructure-to-contract-control compromise, a class of attack that is increasingly common yet underrepresented in audit scopes.

Weekly Highlight: Aftermath Finance

This incident is highlighted because the signed/unsigned semantic mismatch is a subtle vulnerability class that extends beyond any single protocol. Any DeFi protocol that uses a signed fixed-point library to validate unsigned fee or price values is susceptible to the same attack pattern, making this exploit broadly instructive for both developers and auditors.

On April 29, 2026, Aftermath Perpetuals, an on-chain perpetual futures exchange on Sui, was exploited for approximately $1.14M USDC [1]. The root cause was a signed/unsigned semantic mismatch in the protocol's builder-fee validation: the fee comparison function performed signed arithmetic over unsigned values, allowing an attacker to submit a fee value that appeared negative under signed interpretation. During settlement, the negative fee was converted into a positive collateral credit, enabling the attacker to withdraw inflated funds from the protocol vault.

Background

Aftermath Perpetuals is an on-chain perpetual futures exchange on Sui [2]. The protocol allows external integrators to earn trading fees by building front-end interfaces. Each integrator sets a fee rate (taker_fee) that is charged to traders who use their interface [3]. As a safeguard, traders can approve integrators by configuring a preset fee rate cap (maxTakerFee) that limits how much fee an integrator can charge.

When executing a market order, the protocol first compares taker_fee against maxTakerFee to ensure the fee stays within the trader-approved bound, then deducts the calculated fee from the taker's collateral and credits it to the integrator's records.

The protocol's arithmetic is built on a signed fixed-point library (ifixed), which represents values as u256 integers but interprets them under two's-complement semantics for comparison and arithmetic operations.

Vulnerability Analysis

The buggy contracts include the interface module (0x9e2080...25d136) and the clearing house module (0x21d001...7c5068).

The vulnerability lies in the calculate_taker_fees() function, which uses ifixed::less_than_eq() to compare the integrator's taker_fee against the trader's maxTakerFee:

assert!(
    ifixed::less_than_eq(
        v5.taker_fee,
        account::get_integrator_max_taker_fee(
            account::get_integrator_config(arg1, v5.integrator_address)
        )
    ),
    errors::invalid_integrator_taker_fee()
);

Both taker_fee and maxTakerFee are semantically non-negative fee rates. However, ifixed::less_than_eq() performs a signed comparison over u256. When maxTakerFee is set to 0, a value such as 2^256 - 10^16 is interpreted under signed semantics as -10^16. Since -10^16 <= 0 holds, the check passes.

The exploit path is further exposed because create_integrator_info() is publicly callable and does not enforce any permission or fee-bound validation on the supplied taker_fee:

public fun create_integrator_info(arg0: address, arg1: u256): Option<IntegratorInfo> {
    let v0 = IntegratorInfo {
        integrator_address : arg0,
        taker_fee          : arg1,
    };
    option::some<IntegratorInfo>(v0)
}

The negative fee is not merely accepted; it is transformed into a direct positive collateral credit during settlement. In the settlement path, collateral is updated as collateral += pnl - taker_fee - builder_fee. When builder_fee is negative, subtracting it becomes addition:

position::add_to_collateral_usd(
    arg0,
    ifixed::sub(v6, ifixed::add(v7, v8)),
    arg2
);

Neither the fee validation nor the settlement arithmetic enforces that fee values must be non-negative, so the two missing checks compound: the signed comparison allows the negative value in, and the signed arithmetic converts it into a collateral credit.

Attack Analysis

The following analysis is based on the transaction 4pGQdf...wVD8.

• Step 1: The attacker split 100e6 USDC into two fresh perpetual accounts, 1227 and 1228. This created isolated contexts so the attacker could act as both maker (account 1227) and taker (account 1228).

• Step 2: The attacker deposited 100e6 USDC as collateral into account 1227 and opened a market position, establishing a counterparty for the upcoming taker order.

• Step 3: The attacker created an integrator vault, then added a config to account 1228 with maxTakerFee = 0. Setting the cap to zero was essential: it made the signed comparison taker_fee <= 0 accept any value that appears negative under two's-complement.

• Step 4: The attacker started a session from account 1227 and posted a limit order with order_size = 100e6, providing the liquidity that account 1228 would trade against.

• Step 5: The attacker invoked create_integrator_info() with taker_fee = 2^256 - 100e6, a value that represents -100e6 under signed ifixed semantics. Because the function is public and performs no validation, the call succeeded.

• Step 6: The attacker executed a market order from account 1228 using the malicious integrator info. The signed fee comparison passed (-100e6 <= 0), and during settlement the negative fee was subtracted from collateral, effectively adding 100e6 in free collateral to account 1228.

• Step 7: The attacker deallocated and withdrew the inflated collateral from account 1228, gaining 79,610 USDC. The attacker repeated this pattern across multiple transactions to accumulate approximately $1.14M in total.

Conclusion

This incident was caused by a signed/unsigned semantic mismatch in Aftermath Perpetuals' builder-fee validation. The core issue is that the fee comparison function (ifixed::less_than_eq) interprets unsigned fee values under signed semantics. When combined with a publicly callable fee-setting function that performs no bound validation, an attacker can inject a value that passes the signed comparison as "negative" and is then converted into positive collateral during settlement.

The broader pattern is worth noting: any protocol that uses a signed fixed-point library to validate inherently non-negative values (fees, prices, amounts) is vulnerable to the same class of attack. Mitigations should include: (1) enforcing that fee values are non-negative before any comparison (assert!(taker_fee >= 0)), (2) restricting create_integrator_info() to authorized callers, and (3) using unsigned comparison functions for values that are semantically unsigned.

References

• [1] Aftermath Finance Post-Incident Statement
• [2] Aftermath Perpetuals Documentation
• [3] Builder Codes / Front-End Fee

More Incidents This Period

Trusted Volumes

On May 7, 2026, a custom RFQ (Request-For-Quote) proxy contract on Ethereum was exploited, draining approximately $5.87M from market maker TrustedVolumes. The root cause was an authorization mismatch in the order-fill function of the RFQ implementation contract: the signer-permission lookup and the token-transfer operation referenced different fields of the order, so the authorization check passed on one address while funds were debited from another. The attacker drained approximately 1,291 WETH, 206K USDT, 16.94 WBTC, and 1.27M USDC.

Background

TrustedVolumes operates as a market maker on the RFQ protocol deployed on Ethereum. Market makers continuously generate signed price quotes off-chain; takers (typically traders or aggregator routers) submit a chosen quote on-chain, and the protocol contract verifies the signature and atomically settles the trade by moving tokens between maker and taker through transferFrom. The protocol follows a no-vault design: it never custodies funds. Each maker pre-grants the protocol contract an ERC-20 allowance for every token it intends to quote in, and the protocol pulls tokens directly from the maker's wallet at fill time.

To allow makers to delegate the signing operation to a hot wallet, the protocol contract maintains a per-maker signer registry. A maker can call registerAllowedOrderSigner(signer, allowed) to whitelist a hot key, and any subsequent order signed by that key is honored as if signed by the maker.

Vulnerability Analysis

The RFQ proxy contract is deployed at 0xeEeEEe...051756, and the implementation contract is at 0x88eb28...2760d8.

The order-fill function 0x4112e1c2() in the RFQ implementation contract recovers the signer via ecrecover() and checks the allowedOrderSigner mapping to decide whether to accept the signature. The lookup key for this check is varg4, the order's taker-side address. However, the subsequent transferFrom that debits funds uses varg5, the order's maker field. Since varg4 and varg5 are independent fields of the order struct, the authorization check and the funds-flow operation reference different principals. No check enforces that the authorized signer domain matches the address from which tokens are actually pulled.

The registerAllowedOrderSigner function writes the whitelist under msg.sender as the outer key, while the fill path reads under varg4 as the outer key. As long as the caller at varg4 has previously registered themselves via registerAllowedOrderSigner, the authorization check succeeds regardless of which third-party maker address appears at varg5.

Attack Analysis

The following analysis is based on the transaction 0xc5c61b...990513.

• Step 1: The attacker deployed an attack contract and called registerAllowedOrderSigner through it, registering the attacker EOA in the allowed-signer whitelist. This ensured that orders signed by the attacker would pass the protocol's signer-authorization check.

• Step 2: The attack contract pulled 4 wei of USDC from the attacker EOA and approved 4 wei to the RFQ protocol, equipping the attack contract with the minimal consideration needed to act as a taker.

• Step 3: The attacker forged four orders, each signed by the attacker EOA and naming TrustedVolumes as the maker. Because the signer check looked up varg4 (the attacker's contract) while transferFrom debited varg5 (TrustedVolumes), each order drained funds from TrustedVolumes. The four orders swapped 1 wei of USDC for 1,291 WETH, 206,282 USDT, 16.939 WBTC, and 1,268,771 USDC respectively, for a total profit of approximately $5.87M.

Conclusion

The core defect is an authorization mismatch in the order-fill function: the address used for the signer-permission check differs from the address that actually pays. Specifically, registerAllowedOrderSigner writes the whitelist under msg.sender, the fill path reads under the taker field (varg4), and transferFrom debits from the maker field (varg5). Because these three operations reference different principals, any attacker who registers their own signer can forge orders that drain a third-party maker. Authorization checks that gate asset movement must be keyed on the address that will actually pay, and the write path and read path must use the same key.

Wasabi Protocol

On April 30, 2026, Wasabi Protocol, an options and perpetual futures protocol deployed across multiple EVM chains, suffered a security incident resulting in approximately $5.7M in losses ($4.8M in user funds, $900K from the Wasabi treasury) [1][2]. The attack originated from an infrastructure compromise: an exposed analytics endpoint on a public server leaked credentials that ultimately led to the theft of private keys controlling the protocol's EVM smart contracts. Using those keys, the attacker executed unauthorized withdrawals from multiple Wasabi vaults across Ethereum, Base, Blast, and Berachain.

Background

Wasabi Protocol operates deployments across EVM chains (Ethereum, Base, Blast, Berachain) and Solana. This incident was limited to the EVM side of the protocol; Solana deployments and the Prop AMM were not affected.

Wasabi's EVM contracts (WasabiLongPool, WasabiShortPool, WasabiVault) are administered via privileged keys. The protocol also runs off-chain infrastructure including analytics and monitoring services built on Spring Boot.

Attack Analysis

The incident followed an infrastructure-to-contract-control compromise chain:

• Step 1: The attacker discovered that Spring Boot Actuator was installed on a public-facing Wasabi server. Actuator heap dumps are normally password-protected, but this server used a different Spring framework variant that was incompatible with the standard password-protection mechanism, leaving the heap dump endpoint exposed.

• Step 2: The attacker retrieved the heap dump, which contained credentials for a separate internal server.

• Step 3: Using the leaked credentials, the attacker pivoted to the internal server and obtained private keys controlling Wasabi's EVM smart contracts.

• Step 4: With privileged keys in hand, the attacker executed unauthorized withdrawal flows against WasabiLongPool, WasabiShortPool, and WasabiVault contracts across Ethereum, Base, Blast, and Berachain, draining approximately $5.7M in total.

Conclusion

This incident demonstrates that smart-contract security does not end at the code level. The exploit required no on-chain vulnerability; the attacker gained control purely through infrastructure exposure. The key lessons are: (1) debugging and analytics surfaces (heap dumps, profiling endpoints, log exporters) must never be accessible on public infrastructure, (2) credentials for production systems must be strictly segmented from analysis and monitoring environments, and (3) smart-contract administration keys should be protected with defense-in-depth controls including multisig custody, hardware-backed signing, role separation, real-time monitoring, and emergency pause procedures.

References

• [1] BlockSec Phalcon Alert
• [2] Wasabi Protocol Post-Incident Statement

About BlockSec

BlockSec is a full-stack blockchain security and crypto compliance provider. We build products and services that help customers to perform code audit (including smart contracts, blockchain and wallets), intercept attacks in real time, analyze incidents, trace illicit funds, and meet AML/CFT obligations, across the full lifecycle of protocols and platforms.

BlockSec has published multiple blockchain security papers in prestigious conferences, reported several zero-day attacks of DeFi applications, blocked multiple hacks to rescue more than 20 million dollars, and secured billions of cryptocurrencies.

• Official website: https://blocksec.com/

• Official Twitter account: https://twitter.com/BlockSecTeam

• 🔗 BlockSec Auditing Service : Submit a request

• 🔗 Phalcon Security APP: Book a demo

• 🔗 Phalcon Compliance