DEV Community: Daniel

How a Constructor Bypass Let Malicious CROSS Makers Block Native Pair Matching

Daniel — Mon, 10 Aug 2026 14:28:38 +0000

A contract can have no runtime code and still already be executing as a contract.

That construction window is enough to bypass one of CROSS DEX V3's maker restrictions.

The router tries to reject contract accounts with:

function _checkAccountCode(address account) private view {
    if (whitelistedCodeAccounts.contains(account)) return;

    if (account.code.length != 0) {
        revert RouterContractAccountBlocked(account);
    }
}

During a constructor, however:

address.code.length == 0

A malicious maker can therefore submit a sell order while it is still being deployed. After deployment, the same address has runtime code and can reject native CROSS in receive().

That becomes exploitable on native CROSS quote pairs because CROSS WETH automatically unwraps payouts to non pair recipients.

When an honest buyer matches the malicious sell order, the maker payout becomes a native CROSS transfer. The maker rejects it, the WETH transfer reverts, and the buyer's entire matching transaction rolls back.

The malicious order remains live with the same amount, so later buyers can hit the same failure again.

I reported this finding as Medium through the CertiK SkyShield CROSS bug bounty program. It earned $109.40.

Public report and PoC

The demonstrated impact is localized order book griefing, not theft or global DEX unavailability.

The constructor bypass creates a valid contract owned order

Order submission uses the router's checkSubmit path, which eventually calls _checkAccountCode(_msgSender()).

The restriction works for contracts that already have runtime code. The PoC confirms that with a post deployment control.

The problem is the constructor case.

The PoC uses CREATE2 so the attacker's future maker address is known before deployment. The attacker approves that predicted address to spend the required BASE tokens.

Then RejectMaker is deployed.

Inside its constructor, it:

pulls BASE from the attacker
approves the router
submits a sell limit order

At that moment the router sees no runtime code and accepts the maker.

After deployment, the contract has:

receive() external payable {
    revert RejectNative();
}

The order itself remains a normal stored sell order owned by that now deployed contract.

This matters because matching does not later revalidate whether the owner can safely receive the configured payout.

Native CROSS settlement turns the maker into a revert point

When an honest buyer crosses a sell order, PairImplV3 pays the maker in the pair's QUOTE token:

function _exchangeSellOrder(
    uint256 orderId,
    address _owner,
    uint256 amount,
    uint256 fee
) private {
    if (fee == 0) {
        QUOTE.safeTransfer(_owner, amount);
    } else {
        uint256 value = amount - fee;
        QUOTE.safeTransfer(_owner, value);
    }
}

For a normal ERC20 quote asset, the malicious contract can receive the token and matching succeeds.

Native CROSS pairs are different because QUOTE is CROSS WETH.

Its transfer path automatically unwraps tokens sent to non pair recipients:

function _update(
    address from,
    address to,
    uint256 value
) internal override {
    super._update(from, to, value);

    if (to != address(0)) {
        if (!IRouterV3(ROUTER).isPair(to)) {
            _burn(to, value);
            payable(to).sendValue(value);
        }
    }
}

The maker is not a registered pair.

So what looks like a WETH payout becomes:

WETH transfer
→ burn
→ native CROSS transfer

The malicious maker rejects that native transfer.

sendValue reverts, which propagates through the WETH transfer and through the buyer's match.

The failed match does not consume the malicious order

Because the buyer transaction reverts atomically, the attempted trade does not partially complete.

The PoC verifies:

buyer receives BASE
0

maker receives native CROSS
0

buyer match
REVERTED

malicious order remains live
YES

order amount unchanged
YES

That persistence is what makes the issue a repeatable liveness problem rather than an isolated failed trade.

While the order remains in the book, later matching attempts that reach it can encounter the same revert.

Four controls isolate the exact cause

The Foundry PoC contains four tests:

Test	What it proves
`testBug`	A constructor submitted maker order is accepted, an honest native CROSS match reverts, and the order remains unchanged.
`testEOA`	The same native CROSS path succeeds with an EOA maker.
`testToken`	The same malicious contract works when QUOTE is a normal ERC20.
`testBlock`	A contract submitting after deployment is correctly rejected by the router.

The reproduced run completed with:

4 passed
0 failed
0 skipped

These controls rule out the main false positives.

The issue is not that native pair matching is generally broken.

It is not that contract makers inherently break every quote asset.

And it is not that the router completely fails to block deployed contracts.

The failure requires this specific chain:

constructor submission
→ contract maker stored
→ native CROSS quote
→ WETH auto unwrap
→ rejecting receive()
→ settlement revert
→ full rollback
→ order remains live

Why this is Medium, not Low

The demonstrated impact is griefing and matching liveness failure, not theft.

That limitation is real and is why I do not classify the issue as High or Critical. But it does not reduce the finding to an informational or minor implementation quirk.

The downgrade rationale identifies several constraints:

the order must be submitted during construction
the pair must use CROSS on the maker payout side
the attacker must lock their own BASE into the malicious order
the impact is localized rather than protocol wide

Those are valid exploit preconditions and they should be included in the severity analysis.

They do not, however, change what happens once the malicious order has been accepted.

The PoC reaches a deterministic state:

constructor submitted order accepted
→ contract finishes deployment
→ maker rejects native CROSS
→ honest buyer reaches the order
→ CROSS WETH auto unwraps the maker payout
→ receive() reverts
→ buyer matching transaction reverts
→ the order and its amount roll back unchanged

Because the malicious order survives the failed transaction, the failure is repeatable. A later matching attempt that reaches the same order can hit the same revert again.

The attack requires attacker supplied inventory

The attacker must fund the sell order with BASE.

That is a meaningful constraint and it makes the attack less attractive than a zero cost denial of service.

The article should not hide that fact.

But requiring the attacker to place real inventory into a valid looking maker order does not eliminate the impact on honest takers. The protocol accepts that order into the book, and once settlement reaches it, the buyer cannot complete the match because the protocol's own payout path invokes a hostile native receive hook.

The report does not need to assume that the attacker's locked BASE is stolen, lost, or recoverable through some unproven path. The relevant demonstrated fact is narrower: the funded order exists, remains live after the failed match, and can continue to poison settlement while it remains in the book.

The taker failure is caused by protocol settlement

The honest buyer is not directly choosing to send native CROSS to the maker.

PairImplV3 pays the sell maker through QUOTE.safeTransfer, and CROSS WETH itself converts that transfer into native CROSS for a non pair recipient.

There is no recovery path around the reverting sendValue inside the matching transaction shown by the PoC. The revert propagates and rolls the transaction back.

That makes the failure part of the normal in scope matching path, not merely a malicious contract reverting an unrelated call.

Localized does not mean negligible

The downgrade correctly notes that the issue does not compromise protocol wide solvency, ownership, or accounting.

I agree.

The PoC also does not demonstrate:

direct theft
unauthorized minting
permanent user fund loss
full DEX unavailability

Those limitations are exactly why the report was submitted as Medium griefing.

But the affected path is still a real user facing trading path. An order accepted by the router can become persistently unmatchable on a native CROSS pair and make honest buyer transactions revert whenever matching reaches it.

That is more than a cosmetic inconsistency or a best practice observation.

The contract restriction is intentionally enforced by the router

CROSS explicitly blocks non whitelisted accounts that already have runtime code:

if (account.code.length != 0) {
    revert RouterContractAccountBlocked(account);
}

The PoC confirms this policy with testBlock.

The constructor path defeats that restriction only because runtime code has not been installed yet. The accepted address later becomes exactly the type of deployed contract the router normally refuses as a maker.

That bypass would still be incomplete as a report if no downstream effect existed.

Here there is one: the stored contract maker can make the native payout revert and abort honest matching.

The controls support Medium griefing

The four tests isolate the impact:

post deployment contract submission blocked
YES

constructor submitted contract order accepted
YES

EOA maker on native CROSS succeeds
YES

same malicious maker on non native quote succeeds
YES

native CROSS match against malicious maker reverts
YES

buyer receives BASE
NO

maker receives native CROSS
NO

malicious order remains live after revert
YES

order amount remains unchanged
YES

The issue is therefore conditional and narrow, but it is also concrete and repeatable.

That maps cleanly to the report's original framing:

Smart Contract Medium: Griefing

I therefore consider Medium technically better supported by the demonstrated behavior than Low.

The downgrade's prerequisites reduce exploitability and blast radius. They do not turn a repeatable failure of honest matching against an accepted order into a non impactful implementation detail.

Fix the settlement dependency

The most direct fix is to prevent arbitrary contract receive hooks from controlling DEX matching.

The report recommends auto unwrapping WETH only for EOAs.

Contract recipients should receive WETH instead and explicitly unwrap it later if they can safely accept native CROSS.

Conceptually:

if (
    !IRouterV3(ROUTER).isPair(to)
    && to.code.length == 0
) {
    _burn(to, value);
    payable(to).sendValue(value);
}

A separate explicit withdraw() path can let contract recipients unwrap voluntarily.

That changes the security property from:

maker receive() decides
whether matching succeeds

to:

matching completes in WETH
maker decides later
whether to unwrap

The router's account restriction should also not assume that code.length == 0 proves an address will permanently behave like an EOA.

But the settlement fix is more important because it removes the ability of an untrusted recipient hook to revert an otherwise valid match.

Broader audit lesson

This finding comes from combining two behaviors that look manageable on their own:

constructor:
code.length == 0

and:

WETH transfer:
automatic native unwrap

The vulnerability appears only when the entire lifecycle is followed:

maker validation
→ constructor order
→ stored owner
→ later matching
→ quote payout
→ auto unwrap
→ receive() revert
→ transaction rollback
→ order survives

That is the broader lesson.

If a protocol validates an account only when state is created, ask whether the account can behave differently when that state is consumed later.

And if settlement sends native value to an arbitrary recipient, ask whether that recipient can make unrelated users' transactions fail.

Conclusion

CROSS DEX V3 tries to block contract makers by checking account.code.length.

A constructor can bypass that restriction because runtime code is still absent.

Using CREATE2, the PoC funds a predicted maker address and submits a sell order from inside the maker's constructor. After deployment, the same maker rejects native CROSS.

When an honest buyer later matches that order on a native CROSS quote pair, CROSS WETH automatically unwraps the maker payout into native CROSS.

The maker rejects the transfer.

The entire buyer match reverts, and the malicious order remains live with the same amount.

The core invariant is:

A maker's payout behavior should not be able to make honest taker matching revert.

A stored order should be safe to settle even if its owner is a contract with hostile native receive behavior.

That repeatable, user facing matching failure is why I classify the issue as Medium rather than Low.

How a Positive offsetSeconds Bug Let a CROSS Forge Mint Twice the Intended ERC20 Period Limit

Daniel — Mon, 10 Aug 2026 13:32:35 +0000

ERC20MintLimited is not an unlimited forge minter.

It authorizes a forge to mint only while that forge remains inside the configured capacity for the current period.

This finding breaks that second authorization boundary.

With a positive offsetSeconds, CROSS calculates the current period start incorrectly. At the native UTC boundary, PeriodManager.getPeriodStartForTime() can return the next offset boundary even though that boundary is still in the future.

ERC20PeriodMintLimit interprets the changed timestamp as a new period and restores a full LIMIT of capacity before the real configured period has ended.

The PoC demonstrates:

Configured limit
100,000 tokens per period

First mint
100,000 tokens

Remaining capacity
0

Configured +9h period ended?
NO

Capacity at UTC boundary
100,000 tokens

Second mint
100,000 tokens

Total inside the same intended period
200,000 tokens

I reported the finding as Critical through the CertiK SkyShield CROSS bug bounty program. CROSS finalized it as Low, and the report earned $109.40.

Public report and PoC

The severity dispute turns on whether forge membership alone authorizes the amount being minted. The contract does not support that interpretation.

The mint policy has two gates

The base mint path requires onlyForge:

modifier onlyForge() {
    if (!isForge(_msgSender())) {
        revert TokenBase__OnlyForge(_msgSender());
    }
    _;
}

But ERC20MintLimited routes minting through ERC20PeriodMintLimit, which also checks the available period capacity:

if (periodCapacity < amount) {
    revert ERC20PeriodMintLimit__ExceedsPeriodLimit(
        amount,
        periodCapacity
    );
}

_periodCapacity = periodCapacity - amount;

super.mint(to, amount);

The effective policy is therefore:

caller is an authorized forge

AND

amount <= remaining capacity
for the current configured period

The PoC does not claim that a random EOA bypasses onlyForge.

It proves that a forge with zero remaining capacity can receive a new full capacity before the period actually ends and mint supply that the period limit should reject.

The positive offset formula is wrong

For positive offsets, the vulnerable implementation effectively computes:

floor(timestamp / duration)
× duration
+ offsetSeconds

For an offset period, the timestamp must be shifted before flooring:

floor(
    (timestamp - offsetSeconds)
    / duration
)
× duration
+ offsetSeconds

The PoC uses:

duration = 86,400 seconds
offsetSeconds = 32,400 seconds
LIMIT = 100,000 tokens

The intended period is:

[1000 days + 9 hours,
 1001 days + 9 hours)

One second before the UTC boundary, the forge mints the full LIMIT. Capacity becomes zero, and an additional one wei mint is rejected.

Then the timestamp reaches:

1001 days

The configured +9h period still has nine hours remaining.

The correct current period start is still:

1000 days + 9 hours

The PoC records:

block.timestamp
86486400

expected period start
86432400

actual period start
86518800

So CROSS returns a current period start that is greater than block.timestamp.

That impossible timestamp is the root cause.

The future timestamp restores capacity

ERC20PeriodMintLimit resets capacity whenever the calculated period start changes:

uint256 currentPeriodStart =
    _period.getCurrentPeriodStart();

if (currentPeriodStart != _periodStartTime) {
    _periodStartTime = currentPeriodStart;
    periodCapacity = _limit;
}

At the UTC boundary, the bad positive offset calculation changes currentPeriodStart even though the real configured period is still active.

Capacity is restored to LIMIT.

The same forge then mints another full LIMIT, and the call reaches the real ERC20 mint path.

This is not merely an incorrect view value. totalSupply increases.

The PoC isolates the bug

The Foundry proof uses the real ERC20MintLimited preset, ERC20PeriodMintLimit, PeriodManager, onlyForge, and ERC20 mint path.

It contains three tests:

Test	What it proves
`testBug`	The full limit is consumed, capacity resets too early, and the same forge mints a second full limit before the actual period ends.
`testControl`	An extra mint is correctly rejected while capacity is legitimately zero before the false reset.
`testAccess`	A non forge caller cannot mint.

The run completed with:

3 passed
0 failed
0 skipped

The relevant result is:

Non forge mint
REJECTED

First forge mint
LIMIT

Capacity afterward
0

Extra forge mint before UTC
REJECTED

Configured +9h period still active at UTC
YES

Returned period start in future
YES

Capacity at UTC
LIMIT

Second forge mint
LIMIT

Total minted in intended period
2 × LIMIT

Excess over configured limit
1 × LIMIT

This is why the issue cannot be reduced to a generic access control discussion. Access control is working. The quantitative mint authorization is not.

Why I classified it as Critical

At the time of submission, the CROSS SkyShield scope listed Unauthorized mint, burn, or transfer of crypto assets as a Critical smart contract impact.

My report maps the second full LIMIT mint to that category because the supply exceeds the amount authorized by the preset for the active period.

After the first mint:

remaining period capacity = 0

Before the false boundary, another mint correctly reverts.

The real configured period has not changed one second later. Only the incorrect PeriodManager result changes.

That result creates capacity that should not exist and allows another full supply increase.

If forge membership alone authorized every amount, ERC20MintLimited would add no security boundary beyond onlyForge.

But it does add one: a per period quantitative limit.

The PoC demonstrates one full LIMIT of supply above that limit.

That is the technical basis for my Critical assessment.

Why the Low rationale is not supported by the PoC

The downgrade explanation raised four points:

Downgrade point	What the code and PoC show
Minting remains restricted to forges	Correct, but the finding is an amount authorization bypass, not a forge identity bypass.
The effect is bounded and timing dependent	The bound is still one full extra `LIMIT` in the demonstrated period. Timing is deterministic at the native boundary.
Native aligned windows remain near `LIMIT`	The affected positive offset configuration is supported. A different configuration working correctly does not repair this one.
`DEFAULT_ADMIN_ROLE` can adjust `LIMIT`	A manual parameter response does not fix the incorrect period calculation or restore automatic enforcement.

None of those points changes the core state transition:

period not ended
capacity already 0
extra mint should revert
future period start returned
capacity reset to LIMIT
second full LIMIT mint succeeds
totalSupply increases

I therefore consider the Low rationale technically inconsistent with the behavior demonstrated by the contract and PoC.

That conclusion does not require speculating about motive. The public evidence supports a strong technical disagreement. It does not establish bad faith.

Bounded does not mean harmless

The PoC uses:

LIMIT = 100,000 tokens

and produces:

intended maximum
100,000 tokens

actual minted
200,000 tokens

excess
100,000 tokens

The issue does not need infinite minting to violate the security policy.

The entire purpose of the rate limit is to prevent the forge from creating that additional supply before the configured period ends.

The relevant question is whether the contract creates supply that its own limit logic should reject.

The PoC shows that it does.

Fix

The offset must be applied before the timestamp is floored.

Conceptually:

shifted =
timestamp - offset

periodStart =
shifted
- (shifted % duration)
+ offset

The period calculation should always preserve:

periodStart <= timestamp

and:

timestamp < periodStart + duration

For the PoC configuration, the regression should be:

mint LIMIT before UTC boundary
SUCCEEDS

mint 1 extra wei
REVERTS

reach UTC boundary
capacity remains 0

mint LIMIT
REVERTS

reach actual +9h boundary
capacity resets to LIMIT

The report also recommends normalizing offsets by the period duration so equivalent offsets map to the same canonical boundary.

Broader audit lesson

Role authorization and quantitative authorization are separate controls.

A protocol can correctly enforce:

who may call

while incorrectly enforcing:

how much that caller may do

The same reasoning applies to mint quotas, withdrawal ceilings, bridge caps, spending limits, epoch budgets, and rate limits.

When a quantity is part of the policy, bypassing that quantity is an authorization failure even if the caller identity is valid.

Time based controls add another useful invariant:

A function returning the start of the current period must never return a timestamp in the future.

That invariant would have exposed this bug directly.

Conclusion

The CROSS bug is a positive offset period accounting failure in the mint limit path.

After an authorized forge consumes its full LIMIT, capacity should remain zero until the actual offset boundary.

Instead, at the earlier UTC boundary, PeriodManager can report the next +9h boundary as the current period start.

ERC20PeriodMintLimit treats that future timestamp as a new period, restores a full LIMIT, and allows another full mint while the same configured period is still active.

The PoC proves that non forge callers remain blocked, exhausted capacity normally rejects extra minting, the period has not ended, capacity resets early, and total minting reaches 2 × LIMIT.

The relevant authorization question is not only:

is the caller a forge?

It is:

is the caller a forge
and does it still have capacity
inside the current configured period?

The second condition fails because of CROSS's period calculation.

That is why I reported the finding as Critical, and why I do not consider the Low downgrade technically supported by the demonstrated behavior.

How Double Subtracting cash_reserve Reopened Full CurrentSui Markets and Diverted Liquidity Mining Rewards

Daniel — Mon, 10 Aug 2026 12:48:00 +0000

A deposit cap is supposed to answer one simple question:

Is this market already full?

In CurrentSui, that answer can become wrong once the protocol has accumulated reserve.

The reason is a double subtraction of cash_reserve.

The protocol’s total_deposit_plus_interest() value already represents depositor backing net of reserve. But deposit_limit_breached() subtracts cash_reserve again before comparing the result with max_deposit_amount.

That makes current utilization look smaller than it really is.

Once positive reserve exists, a market that is already full according to the protocol’s own depositor backing metric can admit another deposit that should have been rejected.

The impact becomes more interesting when deposit liquidity mining is active. An extra deposit accepted through the broken cap receives cTokens, enters the reward share set, and starts receiving campaign emissions.

The PoC demonstrated this with an exact reserve state: a market already at its configured cap accepted an additional deposit equal to 8,000 USDC of reserve, and that new depositor later captured more than 1,000 USDC of rewards that would otherwise have remained with the original lender.

I reported this finding as Medium in the Sherlock CurrentSui contest. It earned $92.24.

Public Sherlock submission

The flash loan path used in the PoC is only a deterministic way to create positive reserve. The exploit itself is the ordinary public deposit path.

The cap is supposed to measure total market deposits

CurrentSui defines max_deposit_amount as the maximum amount that can be deposited across the market:

/// max amount this asset can be deposited across the market
max_deposit_amount: u64,

Source: asset.move

The intended invariant is straightforward:

current depositor backing
+
new deposit
<=
max_deposit_amount

If current backing is already equal to the configured cap, a new deposit should fail.

Depositor backing already removes cash_reserve

The important accounting path begins in reserve.move:

public(package) fun cash_plus_borrows_minus_reserves<MarketType>(
    self: &Reserve<MarketType>
): Decimal {
    self.debt.add_u64(self.cash).sub(self.cash_reserve)
}

The exchange rate uses that value:

public(package) fun exchange_rate<MarketType>(
    self: &Reserve<MarketType>
): Decimal {
    if (self.total_supply == 0) {
        return float::from_quotient(1, 1)
    };

    let numerator = self.cash_plus_borrows_minus_reserves();
    let denominator = float::from(self.total_supply);

    numerator.div(denominator)
}

And total_deposit_plus_interest() is calculated from the exchange rate:

public(package) fun total_deposit_plus_interest<MarketType>(
    self: &Reserve<MarketType>
): Decimal {
    self.exchange_rate().mul_u64(self.total_supply)
}

Source: reserve.move

So the resulting depositor backing already reflects:

debt
+
cash
-
cash_reserve

That reserve subtraction has already happened before the deposit cap check runs.

The deposit gate subtracts the same reserve again

The bug is in deposit_limit_breached():

public(package) fun deposit_limit_breached<MarketType>(
    self: &Reserve<MarketType>,
    increment: u64,
    limit: u64
): bool {
    let total_deposit_plus_interest =
        self.total_deposit_plus_interest();

    total_deposit_plus_interest.ceil()
        + increment
        - self.cash_reserve.ceil()
        > limit
}

Source: reserve.move

Conceptually, the intended check is:

current depositor backing
+
new deposit
>
cap

But the implementation behaves like:

current depositor backing
+
new deposit
-
cash_reserve
>
cap

Because current depositor backing was already net of reserve, the gate understates utilization by the reserve term again.

In the PoC, the broken check reopens apparent capacity equal to the 8,000 USDC reserve.

The public deposit path trusts the broken result

The market deposit flow directly relies on that helper:

assert!(
    !reserve.deposit_limit_breached<MarketType>(
        deposit_amount,
        asset_config.max_deposit_amount(),
    ),
    error::market_deposit_limit_exceeded(),
);

let ctoken = reserve.mint_ctokens(coin);

Source: market.move

There is no later cap reconciliation.

If deposit_limit_breached() returns false, the deposit is accepted and cTokens are minted.

That is what turns the accounting mistake into a real public state transition.

Positive reserve is a normal protocol state

The PoC uses flash loan fees because they make it easy to construct an exact reserve amount without changing depositor backing or depositor shares.

But the vulnerability is not specific to flash loans.

The protocol can accumulate reserve through ordinary mechanisms, including borrow interest accrual, liquidation revenue, over repayment donated to reserve, and retained flash loan fees.

For example, borrow interest accrual increases cash_reserve here:

let interest_accumulated =
    self.debt.mul(simple_interest_factor);

self.debt =
    self.debt.add(interest_accumulated);

self.cash_reserve =
    self.cash_reserve.add(
        reserve_factor.mul(interest_accumulated)
    );

Source: reserve.move

So an ordinary user can encounter the vulnerable state after reserve has accumulated naturally.

The attacker does not need to control the mechanism that created the reserve.

Why the flash loan setup does not make the exploit privileged

The test uses the real flash loan fee path because it creates a clean state where:

depositor backing
unchanged

depositor shares
unchanged

protocol reserve
positive

Flash loan borrowing itself requires a permissioned caller, but that permission is only used to build the test state.

The action that exploits the broken cap is the normal public deposit() entry point.

Once positive reserve already exists, the attacker only needs an ordinary position and the ability to deposit.

The accepted deposit immediately affects liquidity mining

After handle_mint() succeeds, the deposit entry point updates the user’s deposit reward share:

let (
    ctoken_amount,
    total_ctoken_amount
) = market.handle_mint(
    obligation_owner_cap.id(),
    coin,
    now
);

let miner =
    market.borrow_liquidity_mining_mut<MarketType>();

miner.update_obligation_reward_manager<
    MarketType,
    CoinType
>(
    get_deposit_reward_type(),
    obligation_owner_cap.id(),
    total_ctoken_amount,
    clock
);

Source: deposit.move

That update changes the reward manager share accounting used to distribute campaign emissions.

So the broken cap does not stop at market capacity.

It changes who participates in reward distribution.

The PoC proves the full chain

The Move PoC uses seven tests, each isolating a different part of the finding:

Test	What it proves
`cap_fail`	The exploit sized deposit correctly fails when no reserve has created false capacity.
`gate_lies`	After reserve exists, the market is still economically full but `deposit_limit_breached()` returns false for the extra deposit.
`cap_pass`	The attacker successfully deposits the full reopened amount through the public path.
`reserve_8k`	The setup proves the exact reserve amount and computes the expected reward diversion.
`mine_full`	Without the attacker, the original lender receives the full campaign reward.
`mine_1k`	The accepted extra deposit produces a measurable attacker reward and an equal lender loss.
`live_1k`	The same diversion works after the reward campaign is already active.

The root cause is demonstrated especially clearly by gate_lies.

Before the attacker deposits, the test proves that depositor backing remains equal to the cap and that the new deposit would push backing above it.

Yet the helper still says the limit is not breached:

assert!(
    !r.deposit_limit_breached<MainMarket>(
        target,
        cap0
    ),
    37
);

The later reward tests then show why that incorrect admission matters economically.

Without the exploit, the lender receives the full campaign. With the extra deposit, the attacker receives more than 1,000 USDC, and the lender’s reduction matches the attacker’s gain.

The live_1k test also starts the campaign before the attacker enters, proving that the attacker can dilute an already active reward program rather than merely joining some future campaign.

The complete test run passed:

Test result: OK.
Total tests: 7; passed: 7; failed: 0

The evidence therefore forms one continuous path:

full market
→ positive reserve
→ utilization undercounted
→ extra public deposit accepted
→ reward shares increased
→ attacker receives campaign rewards
→ original lender loses the same value

Why I reported it as Medium

The impact demonstrated by the PoC is direct user yield loss.

The attacker enters a market that should reject new deposits, becomes part of the active deposit reward share set, and receives emissions that would otherwise have remained with existing lenders.

The test demonstrates a four figure attacker reward and an equal lender loss.

At the same time, exploitation depends on positive protocol reserve and an active deposit liquidity mining campaign.

Those are realistic protocol states, but they are still required conditions.

That is why I reported the finding as Medium.

The fix is straightforward

The cap should use one consistent measure of depositor backing.

Since total_deposit_plus_interest() already excludes cash_reserve, the second reserve subtraction should be removed.

A safe check is conceptually equivalent to:

self.total_deposit_plus_interest().ceil()
    + increment
    > limit

The key invariant is:

if current depositor backing
is already equal to max_deposit_amount,

any additional deposit must revert
regardless of cash_reserve

Regression coverage should exercise every normal reserve growth path that can expose the bug, including interest accrual, liquidation revenue, over repayment, and flash loan fees.

It is also worth keeping a reward focused regression test. A deposit cap bug can become a yield ownership bug when accepted deposits feed directly into liquidity mining shares.

The broader lesson

This finding is a good example of why derived accounting values need clear semantics.

If one helper already represents:

cash + borrows - reserves

then a downstream caller must not silently assume reserve still needs to be removed.

The arithmetic error here is small in code but crosses subsystem boundaries:

market risk control
        ↓
deposit admission
        ↓
reward share accounting
        ↓
user yield distribution

The useful audit question is not only whether a cap computes the correct number.

It is also what the rest of the protocol trusts once that cap says yes.

Conclusion

CurrentSui’s deposit cap gate used total_deposit_plus_interest(), a value already net of cash_reserve, and then subtracted cash_reserve again.

That understated utilization whenever protocol reserve was positive.

The PoC showed that a market already at its configured cap could accept an additional 8,000 USDC after exactly 8,000 USDC of reserve had accumulated.

Because a successful deposit immediately enters the liquidity mining share accounting, the extra depositor could then capture more than 1,000 USDC from an active reward campaign, with the original lender losing the same amount.

The underlying rule is simple:

A reserve accounting component should be removed exactly once from the metric used to enforce a market wide deposit cap.

When that rule is broken, a limit bypass can propagate into a completely different subsystem and become direct user yield loss.

How an Expired CurrentSui Reward Pool Could Refund Yield Borrowers Had Already Earned

Daniel — Mon, 10 Aug 2026 12:13:06 +0000

An expired reward pool is not necessarily an economically empty reward pool.

That distinction caused this finding in CurrentSui’s borrow liquidity mining flow.

A borrower can already be active before a new reward campaign is created. Their participation is reflected in the global reward share accounting, but the borrower specific tracker for the new pool is created only when that borrower interacts again or claims.

If the campaign expires before that tracker is materialized, the close path can see:

num_obligation_reward_managers = 0

and treat the pool as safe to refund.

The problem is that zero materialized trackers does not mean zero economically accrued rewards.

The proof of concept showed both sides of that mismatch. If the borrower claims first, the borrower receives the reward and a later close refunds zero. If the pool is closed first, the close recipient receives the same value and the borrower can no longer claim it.

I reported the finding as High in the Sherlock CurrentSui contest. Sherlock ultimately classified it as Medium, and it earned $92.24.

Public Sherlock submission

The bug is therefore not simply about claim timing. It is about using lazy materialization as a proxy for reward ownership.

The accounting model creates economic rewards before claim

Claim is not the moment the reward first comes into existence.

CurrentSui tracks borrow liquidity mining participation globally through total_shares, and the pool later updates cumulative_rewards_per_share.

That means an active borrower can participate economically in a campaign even if the borrower specific reward tracker for that pool has not yet been created.

This matters because lazy accounting is only safe when every lifecycle function understands that some obligations may exist economically before they exist as explicit per user state.

The close path does not preserve that distinction.

A borrower can already be active before the campaign exists

When a user borrows, the borrow path updates the obligation reward manager immediately:

let miner = market.borrow_liquidity_mining_mut<MarketType>();

miner.update_obligation_reward_manager<MarketType, CoinType>(
    get_borrow_reward_type(),
    obligation_owner_cap.id(),
    total_borrow.floor(),
    clock
);

Source: borrow.move

So a borrower can already have active borrow reward shares when a later reward pool is created.

That is the setup used by the PoC: the borrower exists first, then the campaign is added.

A new pool starts with no materialized borrower trackers

A newly created reward pool starts with:

num_obligation_reward_managers: 0

along with zero allocated rewards and zero cumulative rewards per share:

let pool_reward = PoolReward {
    id,
    reward_type: object::id::<TypeName>(&RewardType<CoinType> {}),
    start_time_ms,
    end_time_ms,
    total_rewards: rewards.value(),
    allocated_rewards: float::from(0),
    cumulative_rewards_per_share: float::from(0),
    num_obligation_reward_managers: 0,
    additional_fields
};

Source: reward_manager.move

Starting at zero is not itself a problem.

The problem appears later when the close path interprets that counter as evidence that no borrower reward remains.

Rewards accrue through the global share total

The pool update logic distributes unlocked rewards across total_shares:

if (pool_reward_manager.total_shares == 0) {
    pool_reward_manager.last_update_time_ms = cur_time_ms;
    return
};

let unlocked_rewards =
    float::from(pool_reward.total_rewards).mul(
        float::from(time_passed_ms)
    ).div(
        float::from(pool_reward.end_time_ms - pool_reward.start_time_ms)
    );

pool_reward.allocated_rewards =
    pool_reward.allocated_rewards.add(unlocked_rewards);

pool_reward.cumulative_rewards_per_share =
    pool_reward.cumulative_rewards_per_share.add(
        unlocked_rewards.div(
            float::from(pool_reward_manager.total_shares)
        )
    );

Source: reward_manager.move

As time passes, value becomes attributable to active shares.

So the system can already have borrower yield that is economically earned even though the pool still has no materialized borrower tracker for that user.

The borrower tracker is created lazily

The user specific tracker is filled later inside update_obligation_reward_manager.

That same path increments num_obligation_reward_managers:

let optional_reward = obligation_reward_manager.rewards.borrow_mut(i);

if (optional_reward.is_none()) {
    if (obligation_reward_manager.last_update_time_ms <= pool_reward.end_time_ms) {
        optional_reward.fill(ObligationReward {
            pool_reward_id: object::id(pool_reward),
            earned_rewards: {
                if (obligation_reward_manager.last_update_time_ms <= pool_reward.start_time_ms) {
                    pool_reward.cumulative_rewards_per_share.mul(
                        float::from(obligation_reward_manager.share)
                    )
                } else {
                    float::from(0)
                }
            },
            cumulative_rewards_per_share: pool_reward.cumulative_rewards_per_share
        });

        pool_reward.num_obligation_reward_managers =
            pool_reward.num_obligation_reward_managers + 1;
    };
}

Source: reward_manager.move

This creates the dangerous state:

borrower has active economic participation
YES

borrower specific tracker for this pool
NO

num_obligation_reward_managers
0

The counter describes materialization state, not necessarily economic obligation state.

The expired pool close path relies on that counter

The close function extracts the pool, checks that the campaign has ended, and then requires:

assert!(
    num_obligation_reward_managers == 0,
    error::liquidity_mining_not_all_rewards_claimed()
);

Relevant code:

public(package) fun close_pool_reward<CoinType>(
    pool_reward_manager: &mut PoolRewardManager,
    index: u64,
    clock: &Clock
): Balance<CoinType> {
    let optional_pool_reward =
        pool_reward_manager.pool_rewards.borrow_mut(index);

    let PoolReward {
        id,
        reward_type: _,
        start_time_ms: _,
        end_time_ms,
        total_rewards: _,
        allocated_rewards: _,
        cumulative_rewards_per_share: _,
        num_obligation_reward_managers,
        mut additional_fields,
    } = optional_pool_reward.extract();

    object::delete(id);

    let cur_time_ms = clock.timestamp_ms();

    assert!(
        cur_time_ms >= end_time_ms,
        error::liquidity_mining_pool_reward_period_not_over()
    );

    assert!(
        num_obligation_reward_managers == 0,
        error::liquidity_mining_not_all_rewards_claimed()
    );

    let reward_balance =
        additional_fields.remove<
            RewardBalance<CoinType>,
            Balance<CoinType>
        >(RewardBalance<CoinType>{});

Source: reward_manager.move

The close path does not first refresh the pool and materialize the reward state of already active borrowers.

As a result, it can interpret a zero tracker count as permission to refund a pool whose global share accounting would produce a nonzero borrower claim.

The claim path exposes the mismatch

The normal claim path does something the close path does not.

Before reading the borrower’s reward tracker, it calls:

update_obligation_reward_manager(
    pool_reward_manager,
    obligation_id,
    clock,
    false
);

Source: reward_manager.move

That update materializes the borrower’s reward state.

So the same expired campaign can produce two mutually exclusive ownership outcomes:

Borrower claims first
→ reward state is materialized
→ borrower receives the accrued reward
→ later close has nothing to refund

or:

Pool closes first
→ tracker count is still zero
→ reward balance is refunded
→ borrower cannot realize the reward afterward

The borrower’s economic participation is the same in both paths. Only the timing of materialization changes.

The PoC proves the value is the borrower’s reward, not leftover dust

The Move PoC uses five tests that answer different questions.

Test	What it proves
`ctl`	An already active borrower can claim more than 10 USDC after the campaign expires.
`tail`	If the borrower claims first, the later pool close refund is exactly zero.
`exp`	If the pool closes first, the close recipient receives more than 10 USDC.
`cmp`	The normal borrower claim is exactly equal to the close first refund.
`dead`	After the pool closes first, the borrower can no longer claim the reward.

The strongest comparison is in cmp:

assert!(a > TEN, 5);
assert!(b > TEN, 6);
assert!(t == 0, 7);
assert!(a + t == REWARD, 8);
assert!(a == b, 9);

Here:

a = borrower claim in the normal path
t = refund after the normal claim
b = refund when the pool closes first

The assertions prove:

t = 0
a = b
a + t = REWARD

So the close first path is not collecting unrelated campaign dust.

It receives the same value that the borrower receives in the normal path.

The PoC defines REWARD as 1,000 USDC, and the comparison test accounts for that entire amount through the control claim and zero tail refund.

The full Move test suite passes

The PoC lives in:

tests/integration/test_cases/poc_close.move

and runs with:

sui move test protocol::poc_close -i 100000000000

The reported result was:

[ PASS    ] protocol::poc_close::cmp
[ PASS    ] protocol::poc_close::ctl
[ PASS    ] protocol::poc_close::dead
[ PASS    ] protocol::poc_close::exp
[ PASS    ] protocol::poc_close::tail

Test result: OK.
Total tests: 5; passed: 5; failed: 0

Together, these tests establish the full lifecycle problem: the borrower can claim the reward normally, the post claim refund is zero, closing first redirects the same value, and the borrower cannot recover it afterward.

Impact and severity context

The demonstrated impact is direct loss of borrower yield.

The finding does not depend on malicious privileged behavior. Closing an expired pool is part of the intended reward lifecycle, and there is no contract rule requiring every already active borrower to claim before closure.

The problem is that the close function itself treats:

num_obligation_reward_managers == 0

as its safety condition even though that counter only reflects materialized trackers.

My original High assessment was based on the fact that the PoC demonstrates user yield loss greater than 10 USDC and shows that the same value moves to the close recipient instead.

The official Sherlock classification is Medium, which is the severity I use in my public record.

Regardless of severity, the technical failure is clear: pool closure can refund value that the normal claim path proves was economically attributable to an eligible borrower.

Fix the lifecycle, not only the counter

The core invariant should be:

Closing a reward campaign must not destroy or refund rewards that have already accrued economically to eligible users.

There are several possible directions.

The pool can be fully refreshed before refund logic runs.

Existing obligations can have their reward trackers materialized when a new pool is created.

A cleaner long term design is to separate campaign finalization from reward ownership: closing the campaign stops new accrual, while rewards already earned before expiry remain claimable.

Only value that is provably not attributable to eligible users should become refundable.

A regression test should preserve the control and close first comparison from the PoC. If a borrower can claim X immediately before closure, closing the campaign must not make that same X refundable to another recipient.

The broader lesson

Lazy accounting is useful because it avoids updating every user whenever global state changes.

But it creates a strict design requirement:

not materialized
does not mean
not economically owed

Any close, sweep, refund, cleanup, or migration path that treats lazy state as complete state risks erasing obligations that would have appeared on the next user interaction.

Reward systems are especially sensitive because time can create economic entitlement while user specific state remains untouched.

The safest review question is simple:

If a user can claim X immediately before closure,
can closure make X disappear or become refundable elsewhere?

If the answer is yes, the lifecycle is not preserving reward ownership.

Conclusion

The CurrentSui reward pool close path used materialized borrower trackers as a proxy for outstanding economic obligations.

That proxy was incomplete.

An already active borrower could accrue rewards through the global share accounting while the pool still reported zero materialized obligation reward managers. If the borrower interacted first, the normal claim path materialized the reward and paid it to the borrower. If the expired pool closed first, the same value could be refunded and the borrower could no longer claim it.

The core issue is not reward calculation accuracy. It is reward ownership being decided by the timing of lazy materialization.

The engineering rule is broader than this one protocol:

Lifecycle functions must reason about economic obligations, not only the objects that have already been materialized to represent them.

How a 1 USDC Position Let an Attacker Withdraw 800 USDC From Fluid MoneyMarket’s Shared Liquidity

Daniel — Mon, 10 Aug 2026 02:28:46 +0000

A withdrawal cap only protects funds if every downstream layer uses the capped amount.

That was the problem in Fluid MoneyMarket’s normal supply withdrawal path.

When a user requests more than their position balance, MoneyMarket converts the request into raw units and caps withdrawAmountRaw_ to the position’s actual tokenRawSupply_. This keeps the internal position update within the user’s balance.

But the protocol then calls the Liquidity layer with the original, uncapped supplyAmount_.

The result is a mismatch between ownership accounting and the real token transfer.

In the proof of concept, a victim supplied 1,000 USDC and an attacker supplied only 1 USDC. The attacker then requested an 800 USDC withdrawal. MoneyMarket exhausted the attacker’s 1 USDC position in storage, while Liquidity transferred the full 800 USDC. The attacker ended with a 799 USDC net profit, and the victim’s later withdrawal reverted.

I reported the finding as High in the Sherlock Fluid DEX V2 contest, where it earned $34.

Public Sherlock submission

No oracle manipulation, reentrancy, governance compromise, privileged role, or unusual ERC20 behavior was required. The issue came from one value being capped for storage while another value was used for the external withdrawal.

The broken accounting invariant

MoneyMarket and Liquidity use different accounting layers, but they still need to agree on the economic amount being withdrawn.

The relevant invariant is:

Value withdrawn from Liquidity
<=
Value debited from the withdrawing user’s MoneyMarket position

The vulnerable path violates that invariant because the storage debit is based on withdrawAmountRaw_, while the actual Liquidity call still depends on the original supplyAmount_.

That means MoneyMarket can correctly determine that a user owns only a small position and still authorize a much larger withdrawal against its pooled Liquidity balance.

Where the mismatch begins

The vulnerable logic is in _processNormalSupplyAction.

For a normal withdrawal, the user provides a negative supplyAmount_. MoneyMarket converts that amount into raw units and calculates withdrawAmountRaw_.

If the requested raw withdrawal exceeds the position’s current supply, the code caps it:

if (withdrawAmountRaw_ > tokenRawSupply_) {
    withdrawAmountRaw_ = tokenRawSupply_;
}

Source: MoneyMarket operate helper

The cap itself is reasonable. It allows the protocol to consume at most the available position instead of passing an excessive raw amount into the storage update.

The vulnerability is that this new effective withdrawal amount is not propagated to the value later sent to Liquidity.

Storage uses the capped amount

The final raw amount reaches _updateStorageForWithdraw.

That helper rejects a raw withdrawal larger than the stored position:

if (tokenRawSupply_ < withdrawAmountRaw_) revert();

It then subtracts only the amount passed to it:

tokenRawSupply_ =
    tokenRawSupply_ - withdrawAmountRaw_;

Source: MoneyMarket storage withdrawal helper

Because _processNormalSupplyAction already capped withdrawAmountRaw_, this storage update succeeds even when the original user request was larger than the position.

So the internal accounting remains bounded by what the attacker actually owns.

Liquidity still receives the uncapped request

After the storage update, MoneyMarket calls:

LIQUIDITY.operate(
    token_,
    supplyAmount_,
    0,
    to_,
    ...
);

Source: MoneyMarket Liquidity call

The important detail is that supplyAmount_ is still the original user supplied withdrawal request.

It is not recomputed from the capped withdrawAmountRaw_.

The protocol therefore applies one amount to the attacker’s position and another amount to the real asset movement.

This is not a precision or rounding edge case. The raw conversion successfully detects that the request exceeds the position and the code intentionally caps it. The failure happens afterward, when the external call goes back to the original input.

Why Liquidity can pay the larger amount

Liquidity tracks supply using:

_userSupplyData[msg.sender][token_]

Source: Liquidity user module

During this flow, msg.sender at the Liquidity layer is the MoneyMarket contract.

Liquidity therefore does not see separate balances for Alice, Bob, or each MoneyMarket NFT. It sees MoneyMarket’s aggregated supply position.

That separation is expected. MoneyMarket is responsible for tracking how much of that aggregate position belongs to each user.

The problem is that after limiting the attacker’s internal debit, MoneyMarket still asks Liquidity to release the larger requested amount.

As long as MoneyMarket has enough aggregate supply at Liquidity and the configured withdrawal constraints permit the operation, Liquidity can fulfill it from the pooled position.

That is how funds backing other MoneyMarket suppliers become available to the attacker.

The PoC demonstrates the full economic impact

The Foundry proof uses a listed USDC normal supply market and two ordinary users.

The victim supplies:

uint256 victimSupply = 1_000e6;

The attacker supplies:

uint256 attackerDeposit = 1e6;

The attacker then chooses an explicit withdrawal larger than their position:

uint256 overWithdraw = 800e6;

The exploit uses the normal operate() path:

moneyMarket.operate(
    attackerNftId,
    attackerPosIndex,
    abi.encode(
        -int256(overWithdraw),
        alice
    )
);

The test confirms three separate facts.

First, the attacker receives the full requested amount:

assertEq(
    attackerBalAfterExploit - attackerBalAfterDeposit,
    overWithdraw,
    "attacker got overWithdraw"
);

Second, the attacker’s internal MoneyMarket supply is fully exhausted:

assertEq(
    attackerRawAfterExploit,
    0,
    "attacker raw supply should be exhausted in storage"
);

Third, the victim can no longer complete a full withdrawal afterward:

vm.expectRevert(stdError.arithmeticError);

moneyMarket.operate(
    victimNftId,
    victimPosIndex,
    abi.encode(
        type(int256).min,
        bob
    )
);

The resulting state is:

Victim supplied
1,000 USDC

Attacker supplied
1 USDC

Attacker received
800 USDC

Attacker net profit
799 USDC

Attacker remaining raw supply
0

Victim withdrawal afterward
REVERTED

This is the important proof boundary. The test does not merely show inconsistent storage. It shows an actual token transfer above the attacker’s deposited amount and downstream failure for another supplier.

The validated Foundry run completed with:

1 passed; 0 failed; 0 skipped

The PoC did not modify the protocol contracts.

Why the protocol’s amount limits do not stop it

MoneyMarket also checks amounts through _verifyAmountLimits(int256).

That validation enforces configured minimum and maximum magnitudes. It does not enforce the user specific condition:

requested withdrawal
<=
position balance

An attacker can therefore request more than their own position while still staying within protocol configured amount limits.

The exact maximum extractable amount per call depends on available pooled liquidity and Liquidity withdrawal constraints.

The PoC does not establish an unlimited drain under every configuration, and the finding does not require that claim. It proves that the protocol can transfer more underlying than it debits from the attacker’s position.

Why the withdraw all branch is different

The issue is specific to the normal explicit withdrawal amount path.

The report distinguishes it from the sentinel branch:

supplyAmount_ == type(int256).min

That branch represents withdrawing the full available position.

There, MoneyMarket rewrites supplyAmount_ to the actual withdrawable amount before calling Liquidity. The value used for the external transfer therefore follows the position balance.

The vulnerable branch instead behaves like this:

User provides explicit negative withdrawal
        ↓
withdrawAmountRaw_ is capped
        ↓
Storage uses the capped amount
        ↓
supplyAmount_ remains unchanged
        ↓
Liquidity receives the original request

This distinction matters because it isolates the bug to one concrete value propagation path rather than every MoneyMarket withdrawal.

Severity

The exploit is permissionless once normal system conditions exist.

The target token must be listed, MoneyMarket must have pooled supply for that token at Liquidity, and the attacker needs a MoneyMarket NFT with a normal supply position. Those are ordinary prerequisites for using the feature.

The attack does not rely on an oracle, callback, governance action, special token behavior, or compromised role.

The demonstrated impact is direct extraction from MoneyMarket’s pooled Liquidity position followed by a failed withdrawal for another supplier.

The maximum amount is still bounded by available pooled liquidity and configured Liquidity limits, so the PoC should not be read as proving that any arbitrary amount can always be drained in one transaction.

What it does prove is that an individual user’s balance is no longer the effective authorization boundary for the withdrawal.

That is the basis for the High severity assessment.

Fix the effective withdrawal amount once

The protocol should ensure that the value forwarded to Liquidity is derived from the same final amount used for the MoneyMarket storage debit.

If partial fulfillment is intentional, the safe flow is:

User requests withdrawal
        ↓
Convert to raw units
        ↓
Cap raw amount to position balance
        ↓
Convert the final capped raw amount
back into normal units
        ↓
Use that final amount for Liquidity

The report recommends following the same conversion style used by the withdraw all path and rounding down when converting the capped raw amount back into normal units so the protocol cannot over withdraw.

The final adjusted amount should also be the amount checked by _verifyAmountLimits.

A simpler alternative is to revert whenever the requested withdrawal exceeds the position balance. That changes the user experience from partial fulfillment to rejection, but it also prevents the two layers from executing different withdrawal amounts.

The regression test should recreate a large victim position and a small attacker position, attempt an over balance withdrawal, and assert either that the operation reverts or that the attacker receives no more than the economic value removed from their position. The victim should remain able to withdraw afterward.

The broader audit lesson

This finding is a useful example of a value propagation bug.

A security check can be correct where it is written and still fail to protect funds if the corrected value is not carried through the rest of the call chain.

For multi layer accounting flows, it is worth tracing the same user controlled value through every transformation:

User input
→ normal amount
→ raw amount
→ capped raw amount
→ storage debit
→ external protocol argument
→ actual token transfer

Here, MoneyMarket correctly discovered that the attacker did not own the full requested amount and protected its own storage accordingly.

The protection failed because the final Liquidity call returned to the original request instead of using the adjusted value.

The cap protected the accounting record, but not the pooled assets.

Conclusion

Fluid MoneyMarket’s normal supply withdrawal path used two different effective withdrawal amounts inside the same transaction.

withdrawAmountRaw_ was capped to the user’s real tokenRawSupply_, so MoneyMarket storage consumed only the available position. But LIQUIDITY.operate() still received the original supplyAmount_, allowing the external transfer to exceed the value debited from that user.

Because Liquidity accounts for the MoneyMarket contract as an aggregated supplier, the excess can be paid from pooled funds backing other MoneyMarket positions.

The PoC demonstrated that this mismatch was economically exploitable and could leave another supplier unable to withdraw.

The invariant for the fix is simple:

The amount transferred by Liquidity must never exceed the economic amount debited from the withdrawing user’s MoneyMarket position.

Once a withdrawal amount is adjusted, every downstream accounting and transfer operation must use that same effective value.

How Transaction-Scoped 0xMarkets Oracle Prices Could Freeze CarthaVault After GM Settlement

Daniel — Sun, 09 Aug 2026 10:10:55 +0000

The bug was not a bad oracle price.

It was a mismatch in how long that price was supposed to exist.

CarthaVault included the value of its settled 0xMarkets GM balance in total value locked. To calculate that value, PoolDeployLib.gmValueInUsdc queried the 0xMarkets Oracle for the market’s primary prices.

That looks reasonable until you follow the lifetime of those prices.

0xMarkets primary prices are transaction scoped execution values. OracleModule.withOraclePrices sets them before keeper execution and clears them before the transaction ends.

CarthaVault, however, can continue holding the GM token long after that execution transaction is over.

The resulting steady state was:

CarthaVault holds GM
YES

0xMarkets primary prices exist
NO

From there, the next CarthaVault operation that needed TVL could reach Oracle.getPrimaryPrice and revert with EmptyPrimaryPrice.

The proof reproduced that failure across:

depositAndLock

lockTopUp

release

processQueuedWithdrawals

It also broke:

totalValueLocked

deployedGmBalance

I reported the finding as High through the 0xMarkets program on HackenProof.

It earned $0.52.

The important part was not that a view could revert. The same valuation dependency blocked state changing deposit and withdrawal paths while the vault held real GM.

The lifecycle mismatch

CarthaVault calculates TVL from two components:

Idle vault asset
+
Value of settled GM

The implementation is:

function _totalValueLocked()
    internal
    view
    returns (uint256)
{
    CarthaVaultStorage storage $ =
        _getCarthaVaultStorage();

    return
        IERC20($.asset)
            .balanceOf(address(this))
        +
        _gmValueInUsdc($);
}

The GM valuation is delegated to PoolDeployLib:

function _gmValueInUsdc(
    CarthaVaultStorage storage $
)
    internal
    view
    returns (uint256)
{
    return
        PoolDeployLib.gmValueInUsdc(
            address($.poolToken),
            $.reader,
            $.dataStore,
            $.marketToken,
            $.oracle
        );
}

Source: CarthaVault.sol

That is safe only if the configured price source is available whenever CarthaVault needs to value its GM holdings.

PoolDeployLib.gmValueInUsdc takes an early return while the GM balance is zero. Once GM is present, it reaches _getGmPrice, which reads the 0xMarkets Oracle:

function _getGmPrice(
    address reader,
    address dataStore,
    address market,
    address oracle
)
    private
    view
    returns (
        int256 gmPrice
    )
{
    I0xMReader r =
        I0xMReader(reader);

    I0xMOracle o =
        I0xMOracle(oracle);

    I0xMReader.MarketProps memory mkt =
        r.getMarket(
            dataStore,
            market
        );

    I0xMReader.PriceProps memory indexPrice =
        o.getPrimaryPrice(
            mkt.indexToken
        );

    I0xMReader.PriceProps memory longPrice =
        o.getPrimaryPrice(
            mkt.longToken
        );

    I0xMReader.PriceProps memory shortPrice =
        o.getPrimaryPrice(
            mkt.shortToken
        );

    (
        gmPrice,
    ) =
        r.getMarketTokenPrice(
            dataStore,
            mkt,
            indexPrice,
            longPrice,
            shortPrice,
            MAX_PNL_FACTOR_FOR_DEPOSITS,
            false
        );
}

Source: PoolDeployLib.sol

The integration therefore assumes that Oracle.getPrimaryPrice behaves like a persistent price feed.

It does not.

0xMarkets clears the prices by design

The 0xMarkets execution model makes the lifetime of primaryPrices explicit:

modifier withOraclePrices(
    OracleUtils.SetPricesParams memory params
) {
    oracle.setPrices(params);
    _;
    oracle.clearAllPrices();
}

The atomic-action variant follows the same pattern:

modifier withOraclePricesForAtomicAction(
    OracleUtils.SetPricesParams memory params
) {
    oracle.setPricesForAtomicAction(
        params
    );
    _;
    oracle.clearAllPrices();
}

Source: OracleModule.sol

The prices are available while the keeper action is executing.

Then clearAllPrices removes them:

function clearAllPrices()
    external
    onlyController
{
    uint256 length =
        tokensWithPrices.length();

    for (
        uint256 i;
        i < length;
        i++
    ) {
        address token =
            tokensWithPrices.at(0);

        _removePrimaryPrice(
            token
        );
    }

    minTimestamp = 0;
    maxTimestamp = 0;
}

Later, getPrimaryPrice explicitly rejects an empty value:

function getPrimaryPrice(
    address token
)
    external
    view
    returns (
        Price.Props memory
    )
{
    if (
        token == address(0)
    ) {
        return
            Price.Props(
                0,
                0
            );
    }

    Price.Props memory price =
        primaryPrices[
            token
        ];

    if (
        price.isEmpty()
    ) {
        revert
            Errors.EmptyPrimaryPrice(
                token
            );
    }

    return price;
}

Source: Oracle.sol

So seeing EmptyPrimaryPrice after an execution is not evidence that 0xMarkets itself failed to clean up.

The cleanup is the expected behavior.

The integration failure is using that transaction scoped state as though it were available for persistent vault accounting.

A normal deposit creates the frozen steady state

The PoC did not manufacture the condition by directly minting GM or directly clearing the Oracle.

It used the real 0xMarkets deposit execution path.

DepositHandler.executeDeposit runs under withOraclePrices:

function executeDeposit(
    bytes32 key,
    OracleUtils.SetPricesParams calldata oracleParams
)
    external
    globalNonReentrant
    onlyOrderKeeper
    withOraclePrices(
        oracleParams
    )
{

Source: DepositHandler.sol

During execution, the market token is minted to the request receiver.

For this integration, the receiver is the real CarthaVault.

The transaction therefore legitimately performs both of these actions:

Mint GM to CarthaVault

Clear Oracle primary prices

After the transaction ends, the PoC observed:

CarthaVault GM balance
50000000000000000000000

Oracle tokensWithPrices count
0

That raw GM balance is 50,000e18.

CarthaVault now has an asset it must value across transactions, but the price state selected by the integration has already completed its lifecycle.

Before GM existed, the vault worked normally

The proof first established a healthy control state.

User A started with:

1,000,000 USDC

and deposited:

200,000 USDC

The result was:

User A balance after deposit
800,000 USDC

CarthaVault idle USDC
200,000 USDC

CarthaVault GM balance
0

totalValueLocked
PASS

This matters because gmValueInUsdc skips the oracle path while GM is zero.

The vault only enters the broken state after a real 0xMarkets deployment has settled and GM is actually held.

The keeper deployed only 50,000 USDC

The PoC then deployed:

50,000 USDC

from the vault into 0xMarkets.

That deliberately left:

150,000 USDC

inside CarthaVault.

The real 0xMarkets deposit request was created and executed.

GM was minted to the vault.

The Oracle finished the keeper transaction with:

tokensWithPrices
0

That produced the exact state needed to test whether CarthaVault could continue operating after normal settlement.

It could not.

TVL and deployed GM accounting reverted

Once GM was positive, the early-return condition in gmValueInUsdc no longer applied.

CarthaVault attempted to value the GM.

The valuation reached Oracle.getPrimaryPrice after the prices had been cleared.

The PoC observed:

totalValueLocked
REVERTS EmptyPrimaryPrice

deployedGmBalance
REVERTS EmptyPrimaryPrice

If that were the full impact, this could be dismissed as a reporting or UI problem.

The same dependency sits inside state changing user paths.

New deposits were blocked

depositAndLock calculates shares through _convertToShares:

function _convertToShares(
    uint256 assets
)
    internal
    view
    returns (
        uint256 shares
    )
{
    uint256 totalShares =
        totalSupply();

    uint256 totalAssets_ =
        _totalValueLocked();

    if (
        totalShares == 0
            ||
        totalAssets_ == 0
    ) {
        CarthaVaultStorage storage $ =
            _getCarthaVaultStorage();

        return
            assets
            *
        10 ** (
            decimals()
                -
            IERC20Metadata(
                $.asset
            ).decimals()
        );
    }

    return
        (
            assets
                *
            totalShares
        )
            /
        totalAssets_;
}

Source: CarthaVault.sol

User B had:

1,000,000 USDC

before the attempted deposit.

While GM was held, depositAndLock reverted with EmptyPrimaryPrice.

Afterward:

User B balance
1,000,000 USDC

Position created
NO

The failed call did not consume the user’s assets, but new deposits were unavailable.

Existing positions could not be topped up

The PoC then exercised lockTopUp on User A’s existing position.

That path also required TVL based share conversion.

It reverted with:

EmptyPrimaryPrice

The user balance and position values remained unchanged.

So the deposit side was blocked for both new users and existing positions.

Direct release failed despite abundant idle liquidity

This was the strongest control in the entire proof.

A withdrawal failure after deploying funds externally could otherwise be explained as an ordinary liquidity problem.

The PoC made that explanation impossible.

Before the release probe, CarthaVault still held:

150,000 USDC

The user attempted to release only:

10,000 USDC

The vault had fifteen times the probe amount available locally.

After the lock and cooldown requirements were satisfied, User A called the real release path.

The result was:

release
REVERTS EmptyPrimaryPrice

User release delta
0 USDC

The reason is that release needs _convertToAssets:

function _convertToAssets(
    uint256 shares
)
    internal
    view
    returns (
        uint256 assets
    )
{
    uint256 totalShares =
        totalSupply();

    if (
        totalShares == 0
    ) {
        return 0;
    }

    return
        (
            shares
                *
            _totalValueLocked()
        )
            /
        totalShares;
}

Source: CarthaVault.sol

The vault had enough USDC.

What it lacked was a price source that survived long enough to calculate the payout.

That isolates the liveness failure from ordinary external illiquidity.

Queued withdrawal processing was blocked too

The proof also exercised the keeper-driven withdrawal flow.

User A successfully called:

requestRelease

and the pending withdrawal was set.

The keeper then called:

processQueuedWithdrawals

That operation also depended on TVL and reverted with:

EmptyPrimaryPrice

The pending withdrawal was not processed.

The two tested withdrawal modes therefore failed for the same root cause:

Direct release
FAILED

Queued withdrawal processing
FAILED

A full GM recall restored normal accounting

The issue had a valid recovery path.

The keeper created a real 0xMarkets withdrawal for the vault’s complete GM balance and executed it through the real withdrawal handler.

Afterward:

CarthaVault GM balance
0

deployedGmBalance
0

totalValueLocked
PASS

Once the GM balance reaches zero, gmValueInUsdc no longer needs to query the cleared 0xMarkets primary prices.

This is why the demonstrated impact is a temporary freeze rather than a permanent one.

The proof establishes that normal accounting resumes after a full recall. It does not rely on keeping stale primary prices alive.

The PoC used the real integration

The test was:

FreezeFlow.ts

and used the real:

CarthaVault

CarthaVault proxy and factory

Cartha AccessControl

0xMarkets Oracle

0xMarkets Reader

0xMarkets ExchangeRouter

0xMarkets DepositHandler

0xMarkets WithdrawalHandler

0xMarkets MarketToken

OracleModule.withOraclePrices

It did not:

Mock the 0xMarkets Oracle

Mock the 0xMarkets Reader

Mock the ExchangeRouter

Mint GM directly

Call clearAllPrices directly

Depend on mainnet

Depend on testnet

Depend on public RPC

Require governance compromise

Require malicious admin behavior

The validated run ended with:

✔ freezes (611575ms)

1 passing (10m)

The runtime evidence

Metric	Observed result
User A initial deposit	200,000 USDC
Idle USDC before deploy	200,000 USDC
USDC deployed to 0xMarkets	50,000 USDC
Idle USDC after deploy	150,000 USDC
GM before execution	0
GM after execution	50,000e18 raw units
Oracle tokens with prices after execution	0
`totalValueLocked`	`EmptyPrimaryPrice`
`deployedGmBalance`	`EmptyPrimaryPrice`
New `depositAndLock`	`EmptyPrimaryPrice`
`lockTopUp`	`EmptyPrimaryPrice`
Direct release probe	10,000 USDC
Idle USDC available for release	150,000 USDC
`release`	`EmptyPrimaryPrice`
`processQueuedWithdrawals`	`EmptyPrimaryPrice`
Full GM recall	Restored TVL

The most important comparison is:

Idle liquidity
150,000 USDC

Release probe
10,000 USDC

Liquidity sufficient
YES

Release result
EmptyPrimaryPrice

The user was not blocked because the vault lacked assets.

The user was blocked because the vault could not value the GM it already held.

Why I reported it as High

The proof did not demonstrate:

Direct theft

Insolvency

Permanent freezing of funds

No honest recovery path

A complete GM recall restored accounting.

That bounded the severity.

But the issue was clearly more than a failed view.

While GM remained held, the same root cause blocked:

New deposits

Position top-ups

Direct releases

Queued withdrawal processing

Existing users could not release through either tested withdrawal route even though enough idle USDC was already available.

Recovery required a keeper to unwind the complete GM position before normal TVL based operations resumed.

That is why I reported the finding as High.

The HackenProof reward allocated to the report was $0.52.

Why this is not the GM decimal mismatch

A separate CarthaVault finding also involved settled GM valuation, but the failure mode is different.

The decimal-normalization issue has this shape:

GM exists

Price exists

Valuation returns

Returned value uses the wrong scale

This finding has this shape:

GM exists

Primary price has been cleared

Valuation reverts

One corrupts the number returned by TVL.

The other prevents TVL from being calculated at all.

They require different fixes.

Why this is not the pending-request accounting issue

The pending-request finding exists before 0xMarkets settlement.

This issue exists after settlement.

Here:

Deposit request
EXECUTED

GM minted to CarthaVault
YES

Oracle price cache
CLEARED

Steady-state TVL
BROKEN

The bug does not depend on value being in transit.

It depends on using transaction scoped oracle state to value an asset held persistently across transactions.

Fix the price lifetime mismatch

CarthaVault should not use Oracle.primaryPrices as its persistent GM valuation source.

Those prices belong to the 0xMarkets execution lifecycle.

The report proposes a dedicated GM pricing adapter backed by a persistent token price source.

Conceptually:

CarthaVault
    ↓
Persistent GM price adapter
    ↓
Persistent token prices
    ↓
0xMarkets Reader.getMarketTokenPrice
    ↓
GM valuation

instead of:

CarthaVault
    ↓
0xMarkets Oracle.primaryPrices
    ↓
Transaction scoped execution state
    ↓
EmptyPrimaryPrice after execution

This lets CarthaVault continue using the market valuation logic without assuming that execution-only Oracle state survives into later transactions.

The integration should enforce a simple invariant:

If CarthaVault can hold GM across transactions, it must have a valuation source that remains available across transactions.

The lifetime of the asset and the lifetime of its pricing dependency must be compatible.

Regression coverage

A corrected implementation should reproduce the same normal lifecycle:

1. User deposits into CarthaVault

2. Keeper calls deployToPool

3. Real 0xMarkets deposit executes

4. GM is minted to CarthaVault

5. 0xMarkets clears primary prices

6. CarthaVault continues holding GM

At that point, none of the CarthaVault operations should depend on the cleared cache.

The regression suite should require:

totalValueLocked
PASS

deployedGmBalance
PASS

depositAndLock
PASS

lockTopUp
PASS

release with sufficient idle USDC
PASS

processQueuedWithdrawals
PASS

The test should not preserve or restore 0xMarkets primaryPrices to make these checks pass.

The fix should remove the persistent dependency on that transient state.

The broader audit lesson

Cross-protocol integrations need compatible state lifetimes, not just compatible interfaces.

A function called:

getPrimaryPrice

can look like a conventional oracle read.

That name alone says nothing about whether the value exists outside an execution transaction.

When integrating another protocol’s state, I now treat these as separate questions:

Who sets the value?

When does it become valid?

Who clears it?

How long is it expected to exist?

Does my protocol need it after that lifetime ends?

0xMarkets cleared its primary prices as part of the normal execution lifecycle.

CarthaVault held the resulting GM after that lifecycle had finished.

The integration crossed those two lifetimes without a persistent pricing layer in between.

That was the bug.

Conclusion

CarthaVault valued its settled 0xMarkets GM through PoolDeployLib.gmValueInUsdc, which queried Oracle.getPrimaryPrice.

A real DepositHandler.executeDeposit call set the required prices for execution, minted GM to CarthaVault, and then cleared the Oracle primary prices through OracleModule.withOraclePrices.

After the transaction, the vault was left in a normal but incompatible state:

GM held by CarthaVault
YES

0xMarkets primary prices available
NO

Any CarthaVault operation that needed TVL then reached the cleared price cache and reverted with EmptyPrimaryPrice.

The proof demonstrated failures in depositAndLock, lockTopUp, release, and processQueuedWithdrawals.

The release control was especially strong: the vault had 150,000 USDC of idle liquidity while the user attempted to release only 10,000 USDC, yet the call still reverted.

A full GM recall restored accounting, so the demonstrated impact was a temporary freeze rather than a permanent one.

I reported the finding as High through HackenProof and received $0.52.

The core engineering lesson is:

Persistent accounting cannot depend on transaction scoped oracle state.

If a vault holds an external asset after the execution transaction ends, the valuation source for that asset must still exist when the next transaction begins.

How Successful 0xMarkets Requests Could Permanently Orphan Users’ WNT Execution Fees

Daniel — Sun, 09 Aug 2026 09:44:09 +0000

A successful request is usually the path auditors worry about the least.

The user submits the request, a keeper executes it, the expected protocol action completes, a success event is emitted, and the request disappears from storage. From the outside, everything looks finished.

In 0xMarkets, that assumption was wrong for several request types.

A user could supply a nonzero WNT execution fee through the normal production flow. The protocol accepted and recorded that fee, stored it in the request, executed the request successfully, and removed the request from storage.

But the success path never settled the fee.

The keeper received no WNT execution payment.

The user received no refund of the original fee.

The WNT remained inside the request vault and remained included in the vault’s StrictBank accounting baseline.

A later request then recorded only newly transferred WNT, so the old fee was not rediscovered through the normal request lifecycle.

I reported this finding as High through the 0xMarkets program on HackenProof.

It earned $0.24.

The reward was small, but the underlying lifecycle failure affected five distinct production request paths.

The proof reproduced the same behavior across five successful production paths:

Withdrawal

Order

GLV Deposit

GLV Withdrawal

Shift

None of those requests failed.

None depended on cancellation.

None depended on a frozen order.

Every mandatory request executed successfully.

That is what made the bug interesting: the requested action completed, while value associated with that request did not.

The execution fee has its own lifecycle

0xMarkets request flows can carry a WNT execution fee intended to support keeper execution.

A simplified expected lifecycle is:

User supplies WNT execution fee
        ↓
Request vault records the transfer
        ↓
Request stores executionFee
        ↓
Keeper executes the request
        ↓
GasUtils.payExecutionFee
        ↓
Keeper receives the execution payment
        ↓
Any remaining amount is refunded

The affected success paths instead behaved like this:

User supplies WNT execution fee
        ↓
Request vault records the transfer
        ↓
Request stores executionFee
        ↓
Keeper executes the request successfully
        ↓
Request is removed
        ↓
Execution fee payout is skipped
        ↓
WNT remains in the request vault

The protocol finished the request lifecycle.

It did not finish the fee lifecycle.

Withdrawal shows the mismatch clearly

WithdrawalUtils.createWithdrawal records incoming WNT through the real WithdrawalVault:

address wnt = TokenUtils.wnt(dataStore);
uint256 wntAmount =
    withdrawalVault.recordTransferIn(
        wnt
    );

if (
    wntAmount
        <
    params.executionFee
) {
    revert Errors.InsufficientWntAmount(
        wntAmount,
        params.executionFee
    );
}

params.executionFee =
    wntAmount;

Source: WithdrawalUtils.sol

The important point is that this is not a stray token accidentally sent to a vault.

The protocol:

Receives the WNT

Records the WNT

Checks the amount against executionFee

Stores the resulting value in the request

The problem appears after successful execution.

ExecuteWithdrawalUtils.executeWithdrawal removes the request, performs the withdrawal, emits WithdrawalExecuted, executes the callback, calculates the oracle price count, and then reaches a disabled payout:

// ! EXECUTION FEE EXEMPTION
// GasUtils.payExecutionFee(
//     params.dataStore,
//     params.eventEmitter,
//     params.withdrawalVault,
//     params.key,
//     withdrawal.callbackContract(),
//     withdrawal.executionFee(),
//     params.startingGas,
//     cache.oraclePriceCount,
//     params.keeper,
//     withdrawal.receiver()
// );

Source: ExecuteWithdrawalUtils.sol

The request succeeds.

The request is gone.

The fee remains.

Orders had the same lifecycle break

Normal user orders could also store a nonzero execution fee.

OrderUtils.createOrder records WNT and stores the resulting amount:

uint256 wntAmount =
    orderVault.recordTransferIn(
        cache.wnt
    );

if (
    wntAmount
        <
    params.numbers.executionFee
) {
    revert Errors.InsufficientWntAmountForExecutionFee(
        wntAmount,
        params.numbers.executionFee
    );
}

params.numbers.executionFee =
    wntAmount;

Later:

uint256 executionFee;

(
    executionFee,
    cache.executionFeeDiff
) =
    (
        params.numbers.executionFee,
        0
    );

order.setExecutionFee(
    executionFee
);

Source: OrderUtils.sol

The success path then skips the production payout routine:

// ! EXECUTION FEE EXEMPTION
// GasUtils.payExecutionFee(
//     params.contracts.dataStore,
//     params.contracts.eventEmitter,
//     params.contracts.orderVault,
//     params.key,
//     params.order.callbackContract(),
//     params.order.executionFee(),
//     params.startingGas,
//     GasUtils.estimateOrderOraclePriceCount(
//         params.order.swapPath().length
//     ),
//     params.keeper,
//     params.order.receiver()
// );

Source: ExecuteOrderUtils.sol

The code comments correctly note that liquidation and ADL orders can have zero execution fees.

That does not resolve normal user orders that actually stored a nonzero fee before successful execution.

Both GLV directions were affected

The same pattern existed in GLV request processing.

GLV Deposit

GlvDepositUtils.createGlvDeposit either separates WNT from the deposited token amount or records a separate WNT transfer and stores the result as the request’s executionFee.

After successful execution, the payout call is disabled:

// ! EXECUTION FEE EXEMPTION
// GasUtils.payExecutionFee(
//     params.dataStore,
//     params.eventEmitter,
//     params.glvVault,
//     params.key,
//     glvDeposit.callbackContract(),
//     glvDeposit.executionFee(),
//     params.startingGas,
//     cache.oraclePriceCount,
//     params.keeper,
//     glvDeposit.receiver()
// );

Source: GlvDepositUtils.sol

GLV Withdrawal

GlvWithdrawalUtils.createGlvWithdrawal records WNT in GlvVault and stores that amount as executionFee.

Its successful execution path reaches the same disabled settlement pattern:

// ! EXECUTION FEE EXEMPTION
// GasUtils.payExecutionFee(
//     params.dataStore,
//     params.eventEmitter,
//     params.glvVault,
//     params.key,
//     glvWithdrawal.callbackContract(),
//     glvWithdrawal.executionFee(),
//     params.startingGas,
//     cache.oraclePriceCount,
//     params.keeper,
//     glvWithdrawal.receiver()
// );

Source: GlvWithdrawalUtils.sol

Different request direction.

Same orphaned fee.

Shift makes the lifecycle problem especially visible

Shift performs an internal withdrawal followed by an internal deposit.

Those internal requests deliberately use:

executionFee
0

because the outer Shift request carries the user-funded fee.

That is internally consistent.

The problem is what happens when the Shift finishes.

After the internal withdrawal and deposit complete, ShiftExecuted is emitted and the callback runs.

The outer fee settlement is then disabled:

// ! EXECUTION FEE EXEMPTION
// GasUtils.payExecutionFee(
//     params.dataStore,
//     params.eventEmitter,
//     params.shiftVault,
//     params.key,
//     shift.callbackContract(),
//     shift.executionFee(),
//     params.startingGas,
//     GasUtils.estimateShiftOraclePriceCount(),
//     params.keeper,
//     shift.receiver()
// );

Source: ShiftUtils.sol

The entire Shift can therefore succeed while its original nonzero WNT execution fee remains in ShiftVault.

StrictBank is why the old fee does not become the next fee

The strongest part of the proof was not simply showing WNT sitting in the vault.

It showed why a later request does not naturally recover it.

Each request vault inherits StrictBank, which keeps an accounting baseline:

mapping(
    address =>
    uint256
) public tokenBalances;

recordTransferIn calculates only the balance increase since the previous accounting point:

function _recordTransferIn(
    address token
)
    internal
    returns (
        uint256
    )
{
    uint256 prevBalance =
        tokenBalances[
            token
        ];

    uint256 nextBalance =
        IERC20(
            token
        ).balanceOf(
            address(
                this
            )
        );

    tokenBalances[
        token
    ] =
        nextBalance;

    return
        nextBalance
            -
        prevBalance;
}

Source: StrictBank.sol

Suppose the first request adds one execution fee:

Vault actual WNT
old balance + fee

StrictBank tokenBalances
old balance + fee

The request then succeeds without paying or refunding that fee.

Nothing removes it from either the real vault balance or the accounting baseline.

When another request transfers new WNT:

prevBalance
already includes old fee

nextBalance
old fee + newly transferred fee

recordTransferIn
new fee only

The old fee is not picked up again.

The PoC explicitly created a later request for every affected path and verified that only newly transferred WNT was recorded.

That is why the issue is stronger than “the vault has leftover tokens.”

The original execution fee becomes detached from the request that owned it and invisible to later request accounting.

What “permanent” means in this report

The word permanent should be read precisely.

The PoC proves that the fee is permanently lost from the normal request lifecycle:

Original request
Removed

Keeper settlement
Absent

User refund
Absent

Old fee discovered by later request
No

Normal request-based recovery
Gone

The proof does not establish that no privileged migration, contract upgrade, or extraordinary administrative recovery could ever move the WNT.

That is not required for the demonstrated bug.

The security failure is that after a successful request is removed, the protocol leaves no normal request state through which that user’s fee is settled or recovered.

The production settlement routine already existed

GasUtils.payExecutionFee contains the expected settlement logic.

It calculates the keeper portion:

uint256 executionFeeForKeeper =
    adjustGasUsage(
        dataStore,
        gasUsed,
        oraclePriceCount
    )
        *
    tx.gasprice;

if (
    executionFeeForKeeper
        >
    executionFee
) {
    executionFeeForKeeper =
        executionFee;
}

bank.transferOutNativeToken(
    keeper,
    executionFeeForKeeper
);

and then computes the remainder:

cache.refundFeeAmount =
    executionFee
        -
    executionFeeForKeeper;

Source: GasUtils.sol

This matters because the report is not inventing a hypothetical fee destination.

The protocol already has a production routine designed to:

Pay the keeper

Refund the remainder

Cancellation paths use fee settlement behavior.

The affected successful paths do not.

The PoC used real routers, handlers, vaults, and accounting

The proof was a single TypeScript test built on the repository’s production deployment fixture.

It exercised these complete paths:

Path	Creation entrypoint	Execution entrypoint	Vault
Withdrawal	`ExchangeRouter.createWithdrawal`	`WithdrawalHandler.executeWithdrawal`	`WithdrawalVault`
Order	`ExchangeRouter.createOrder`	`OrderHandler.executeOrder`	`OrderVault`
GLV Deposit	`GlvRouter.createGlvDeposit`	`GlvHandler.executeGlvDeposit`	`GlvVault`
GLV Withdrawal	`GlvRouter.createGlvWithdrawal`	`GlvHandler.executeGlvWithdrawal`	`GlvVault`
Shift	`ExchangeRouter.createShift`	`ShiftHandler.executeShift`	`ShiftVault`

It did not depend on:

Mock affected contracts

Custom harnesses

Direct storage writes

Direct vault accounting mutation

Failed requests

Cancellation

Frozen orders

Mainnet

Testnet

Public RPC

The test execution fee was:

1000000000000000 wei
0.001 WNT

All five mandatory paths passed.

The exact test run finished with:

✔ locks (614607ms)

1 passing (10m)

What was verified after each successful execution

A commented-out function alone would not prove impact.

For every path, the PoC followed the state before and after execution.

It verified:

Nonzero executionFee stored before success

Request created through the production router

Production handler execution succeeded

Expected success event emitted

Cancel event absent

Freeze event absent where applicable

Request removed after success

KeeperExecutionFee event absent

ExecutionFeeRefund event absent

ExecutionFeeRefundCallback event absent

Keeper WNT delta zero

Original fee remained in the request vault

Original fee remained in StrictBank accounting

Later request registered only newly transferred WNT

There is one important measurement nuance.

Withdrawal-like operations may legitimately send WNT to the receiver as protocol output.

For that reason, the proof did not identify the missing execution-fee refund merely by looking at the receiver’s raw WNT delta.

It relied on the absence of the production refund events together with the fact that the original fee remained in the vault and in StrictBank accounting.

That prevents normal withdrawal output from being mistaken for a fee refund.

Why this is not merely an unpaid keeper

The keeper receiving zero WNT is one symptom.

The user-funded value is the more important part.

If successful execution was intentionally supposed to be fee exempt, the protocol had safe design options:

Do not accept a nonzero fee

or

Return the supplied fee

or

Settle it explicitly under another documented policy

Instead, the affected flows:

Accept the WNT

Validate the WNT

Store executionFee

Execute successfully

Delete the request

Leave the WNT in the vault

A fee exemption can explain why the keeper is not paid.

It does not explain why user-supplied WNT should become detached from the request that supplied it.

Why I reported it as High

The submitted report mapped the issue to three impact categories:

Theft of gas or execution fee

Permanent freezing of funds

Functional correctness failure

The affected value is not the user’s principal position or LP pool principal.

The proof also did not demonstrate:

Protocol insolvency

Protocol-wide unrecoverable loss

Direct theft of market principal

Attacker-controlled extraction of the locked WNT

Those limits are important.

But the affected WNT is still user-supplied value accepted by production request flows.

The protocol stores it specifically as an execution fee and then loses the normal settlement path after successful request deletion.

The same root cause reproduced across five distinct request classes.

That is why I submitted the finding as High.

The HackenProof reward allocated to my report was $0.24.

The reward amount reflects contest payout mechanics. It does not alter what the proof demonstrated.

Why this is separate from other 0xMarkets fee findings

Several 0xMarkets findings involved execution fees, but the lifecycle and root cause here are different.

Frozen order execution fee lock

That issue occurs in the freeze path.

This report requires successful execution and does not use freezeOrder.

Callback fee-cap behavior

Those findings concern oversized execution fees and callback-based recovery behavior.

This report uses normal nonzero execution fees that remain in the vault after success.

Pyth Lazer provider drain

That finding concerns ETH held by the oracle provider and permissionless verification calls.

This report concerns user-supplied WNT stored in request vaults.

Cartha fee routing

The Cartha integration issue sends WNT to the wrong destination before 0xMarkets can record the request fee.

Here, WNT reaches the correct 0xMarkets vault and is correctly recorded.

The failure happens after successful execution.

Fix the lifecycle, not just the symptom

The safest correction is to make every success path that accepts a nonzero execution fee settle that fee before returning.

The commented GasUtils.payExecutionFee calls show the intended settlement structure and already contain the required request-specific parameters.

However, the fix should be applied consistently with the protocol’s intended fee policy.

For example, order creation also contains disabled execution-fee validation and capping logic. A production patch should review creation and settlement together rather than blindly uncommenting one line in isolation.

The invariant should be:

A successful request that accepts a nonzero execution fee must not leave that fee orphaned from the request lifecycle.

If successful execution is intentionally subsidized, creation should reject unnecessary nonzero fees or return them explicitly.

What should never be possible is:

Accept fee
Store fee
Execute successfully
Delete request
Leave fee without a normal owner-specific settlement path

Regression tests

A complete correction should cover all five affected request families:

Withdrawal success
Fee settled
No orphaned WNT

Order success
Fee settled
No orphaned WNT

GLV Deposit success
Fee settled
No orphaned WNT

GLV Withdrawal success
Fee settled
No orphaned WNT

Shift success
Fee settled
No orphaned WNT

The suite should also verify:

Later requests record only their own incoming fee

StrictBank accounting matches the intended post-settlement balance

Cancellation behavior remains correct

Liquidation and ADL zero-fee behavior remains correct

Zero-fee requests remain valid where intended

Receiver protocol output is not mistaken for execution-fee refund

The broader audit lesson

Request-based protocols have two lifecycles that need to be reviewed independently.

The first is the action:

Create
↓
Execute
↓
Complete

The second is every asset attached to that action:

Fund
↓
Account
↓
Store
↓
Settle
↓
Release

A success event only proves the first lifecycle completed.

It says nothing about whether every associated balance was settled correctly.

This finding existed precisely in that gap.

The request succeeded.

The fee did not.

Conclusion

0xMarkets accepted nonzero WNT execution fees in successful Withdrawal, Order, GLV Deposit, GLV Withdrawal, and Shift flows.

The protocol recorded the fee and stored it in each request.

The production handler then executed the requested operation successfully and removed the request.

But the corresponding execution-fee payout was disabled.

The keeper received no execution-fee WNT.

No production refund was emitted for the original fee.

The WNT remained in the request vault and remained part of StrictBank accounting.

Later requests recorded only newly transferred WNT, so the old fee did not return through subsequent request processing.

The proof reproduced this behavior across all five mandatory paths using real routers, handlers, vaults, and accounting. It required no affected-contract mocks, custom harnesses, direct storage writes, failed requests, cancellation, freeze path, live RPC, mainnet, or testnet.

I reported the finding as High through HackenProof and received $0.24.

The engineering invariant is simple:

Successful execution must settle every piece of value that the request accepted before the request is deleted.

A success event should never be the moment a user-funded fee becomes orphaned from the protocol’s normal lifecycle.

How Permissionless Pyth Lazer Calls Could Drain 0xMarkets’ Oracle Fee Balance and Break Price Updates

Daniel — Sun, 09 Aug 2026 09:14:22 +0000

Oracle integrations often look like read-only infrastructure.

This one was not.

Inside 0xMarkets, PythLazerFeedProvider.getOraclePrice could be called directly by any external account. Every successful call then paid the Pyth Lazer verification fee using ETH already held by the provider contract.

The caller did not need to be the protocol Oracle.

The caller did not need the CONTROLLER role.

The caller did not need administrator privileges.

The caller did not even need to send ETH.

With valid update data, an unprivileged account could repeatedly call the provider with:

msg.value
0 ETH

while the provider paid the verification fee from its own native balance.

In my proof of concept, the provider held:

0.05 ETH

and the local verification fee was:

0.01 ETH

Five zero-value attacker transactions reduced the provider balance to zero.

The same legitimate Oracle.setPrices flow that worked before the drain then failed because PythLazerFeedProvider could no longer fund pythLazer.verifyUpdate.

I submitted this finding as Medium through the 0xMarkets audit contest on HackenProof.

It earned $1.24.

The interesting part was never the small test balance.

The real issue was the authorization boundary:

Any external account with valid update data could decide when the protocol spent its oracle-verification balance and could keep doing so until the provider no longer had enough funds to execute the legitimate price-update path.

The design assumption

PythLazerFeedProvider was intentionally able to hold ETH:

// Accept ETH to cover Pyth verification fees
receive() external payable {}

That is reasonable if the provider is expected to pay a verification fee on behalf of the protocol.

The problem was that the function spending that balance was unrestricted:

function getOraclePrice(
    address token,
    bytes memory data
) external returns (OracleUtils.ValidatedPrice memory) {
    uint32 feedId =
        uint32(
            dataStore.getUint(
                Keys.pythLazerFeedIdKey(token)
            )
        );

    if (feedId == 0) {
        revert Errors.EmptyPythLazerFeedId(token);
    }

    uint256 feedMultiplier =
        dataStore.getUint(
            Keys.pythLazerFeedMultiplierKey(token)
        );

    if (feedMultiplier == 0) {
        revert Errors.EmptyPythLazerFeedMultiplier(token);
    }

    bool inverted =
        dataStore.getBool(
            Keys.pythLazerFeedInvertedKey(token)
        );

    uint256 fee =
        pythLazer.verification_fee();

    (
        bytes memory payload,
    ) =
        pythLazer.verifyUpdate{
            value: fee
        }(
            data
        );

There was no onlyOracle style guard.

There was no onlyController restriction.

Nothing checked msg.sender before the fee-bearing external call.

The original implementation is visible in PythLazerFeedProvider.sol.

Why zero `msg.value` is the decisive detail

A natural reaction to a paid oracle call is:

The caller is paying the verification fee.

That would change the threat model completely.

But it was not what happened here.

The provider calculated the fee internally:

uint256 fee =
    pythLazer.verification_fee();

and then executed:

pythLazer.verifyUpdate{
    value: fee
}(
    data
);

That value came from the balance of PythLazerFeedProvider.

The caller only paid transaction gas.

The PoC made this explicit by sending every drain transaction with:

attacker msg.value
0 ETH

Each successful call still reduced the provider balance by exactly one verification fee.

The vulnerable capability was therefore not merely:

Anyone can request an oracle validation

It was:

Anyone can request an oracle validation
and make the protocol pay for it

The legitimate oracle path

The intended flow was protected at the higher level.

Oracle.setPrices is restricted to controllers:

function setPrices(
    OracleUtils.SetPricesParams memory params
) external onlyController {
    OracleUtils.ValidatedPrice[] memory prices =
        _validatePrices(
            params,
            false
        );

    _setPrices(
        prices
    );
}

During _validatePrices, the Oracle calls the configured provider:

OracleUtils.ValidatedPrice memory validatedPrice =
    IOracleProvider(
        provider
    ).getOraclePrice(
        token,
        data
    );

So the legitimate architecture looked like this:

Controller
    ↓
Oracle.setPrices
    ↓
Oracle._validatePrices
    ↓
PythLazerFeedProvider.getOraclePrice
    ↓
pythLazer.verifyUpdate
    ↓
Validated price

The problem was that nothing forced callers to use that architecture.

An attacker could skip the protected Oracle contract and call the provider directly:

Unprivileged account
    ↓
PythLazerFeedProvider.getOraclePrice
    ↓
Provider pays verification fee

0xMarkets protected who could set prices.

It did not protect who could spend the fee balance required to validate those prices.

The attack in eleven steps

The proof used a configured token and valid local Pyth Lazer update data.

The complete sequence was:

1. PythLazerFeedProvider is funded with 0.05 ETH

2. The verification fee is configured to 0.01 ETH

3. A controller calls Oracle.setPrices

4. The legitimate price update succeeds

5. An unprivileged account calls getOraclePrice directly

6. The attacker sends zero ETH

7. The provider pays 0.01 ETH to the verifier

8. The attacker repeats the call five times

9. The provider balance reaches zero

10. The controller calls Oracle.setPrices again

11. The legitimate update fails because the provider cannot fund verifyUpdate

The attacker did not receive the drained ETH.

That distinction matters.

This was not demonstrated as direct attacker profit.

It was protocol-funded griefing: the attacker controlled when operational ETH was converted into verification fees.

The accounting was exact

The test started with:

Provider balance
0.050000000000000000 ETH

The configured fee was:

Verification fee
0.010000000000000000 ETH

The attacker executed:

Direct transactions
5

msg.value per transaction
0 ETH

Afterward:

Provider balance
0 ETH

Provider loss
0.05 ETH

Verifier gain
0.05 ETH

The provider lost exactly the amount the verifier gained.

That was important because it proved where the ETH went.

This was not an estimate based on gas usage.

It was not a balance change caused by the attacker sending value.

It was the provider paying the verification fee five times.

The legitimate price path failed afterward

The PoC established a before-and-after control.

Before depletion:

Oracle.setPrices
PASS

Primary price
SET

The test then cleared the previously stored price state before starting the attacker drain.

After depletion:

Oracle.setPrices
FAIL

Price count after failed update
0

The second setPrices attempt failed because the provider no longer had the funds required for verifyUpdate.

This is the actual liveness impact.

For a token configured to use this provider, fresh Pyth Lazer prices could no longer be validated through the demonstrated path until the provider was funded again or the implementation was corrected.

The PoC exercised the real vulnerable path

The proof was not built around a replacement provider or copied vulnerable function.

It used the real:

PythLazerFeedProvider

PythLazerFeedProvider.getOraclePrice

PythLazerFeedProvider.receive

Oracle.setPrices

Oracle._validatePrices

ChainlinkDataStreamProvider

The local Pyth Lazer verifier was the only external boundary simulated.

Its job in the test was narrow:

Expose the verification fee

Accept the valid local update payload

Receive the fee

Return parsed payload data

The access-control failure and provider-funded payment remained inside the real PythLazerFeedProvider.

The test suite completed with:

3 passing

The Chainlink provider exposed the inconsistency

The strongest comparison was already in the same repository.

ChainlinkDataStreamProvider protected its equivalent provider entrypoint with:

modifier onlyOracle() {
    if (
        msg.sender != oracle
    ) {
        revert Errors.Unauthorized(
            msg.sender,
            "Oracle"
        );
    }

    _;
}

and:

function getOraclePrice(
    address token,
    bytes memory data
)
    external
    onlyOracle
    returns (
        OracleUtils.ValidatedPrice memory
    )
{

The PoC tested both providers:

Direct attacker call to ChainlinkDataStreamProvider
REJECTED

Direct attacker call to PythLazerFeedProvider
ACCEPTED

That comparison did more than suggest a possible fix.

It showed that the codebase already had the correct trust boundary for another oracle provider.

The Pyth Lazer implementation was the outlier.

The static-call control removed another false positive

The PoC also tested repeated callStatic invocations.

Those calls validated successfully but did not change the provider balance.

Then the attacker sent a real transaction using the same entrypoint.

The provider lost one fee.

The control result was:

callStatic
No balance change

Real transaction
Provider balance decreases

That matters because an oracle function can appear exploitable during simulation while no persistent value movement actually occurs.

Here, real transactions produced the drain.

Valid update data was a precondition, not an authorization control

The attacker needed valid update data for a configured feed.

That is an important limitation and should not be hidden.

But valid oracle data answers one question:

Is this update acceptable?

It does not answer another:

Who is allowed to make the protocol pay to verify it?

The attack did not depend on forged prices.

The attacker could use legitimate update material and repeatedly externalize the verification cost to the protocol.

Data validity and spending authorization were separate security boundaries.

Only the first one was enforced.

Why I submitted it as Medium

The proof demonstrated concrete economic and liveness impact:

Permissionless provider-funded verification

No protocol role required

Zero attacker msg.value

Deterministic depletion of operational ETH

Legitimate Oracle.setPrices failure after depletion

Configured token price updates unavailable through this provider until recovery

It did not demonstrate:

Direct theft of trader or LP funds

Oracle price forgery

Permanent corruption of oracle state

Irrecoverable protocol shutdown

Attacker capture of the drained ETH

The provider could be funded again.

That bounded the duration of the liveness failure.

For that reason, I submitted the issue as Medium: the attack could force the protocol to spend operational funds and disable a critical price-validation path, but the proof did not establish direct user-fund theft or an irreversible outage.

The HackenProof reward was $1.24.

The root cause in one table

Property	Observed behavior
Native fee balance	`PythLazerFeedProvider` accepts ETH
Unrestricted entrypoint	`getOraclePrice` has no caller guard
Provider-funded verification	`verifyUpdate` spends the provider balance
Attacker privileges	None
Attacker value	Zero `msg.value`
Broken legitimate path	`Oracle.setPrices`

Any one of those design choices can be reasonable in isolation.

The dangerous combination was:

A protocol-funded external call exposed through a permissionless entrypoint.

The missing invariant was simple:

Only the protocol Oracle should be able to trigger provider-funded Pyth Lazer verification.

Recommended fix

The cleanest fix is to mirror ChainlinkDataStreamProvider.

PythLazerFeedProvider should know the authorized Oracle:

address public immutable oracle;

and enforce:

modifier onlyOracle() {
    if (
        msg.sender != oracle
    ) {
        revert Errors.Unauthorized(
            msg.sender,
            "Oracle"
        );
    }

    _;
}

The provider entrypoint then becomes:

function getOraclePrice(
    address token,
    bytes memory data
)
    external
    onlyOracle
    returns (
        OracleUtils.ValidatedPrice memory
    )
{

The constructor should receive the Oracle address:

constructor(
    DataStore _dataStore,
    address _oracle,
    address pythLazerFeedVerifier
) {
    dataStore =
        _dataStore;

    oracle =
        _oracle;

    pythLazer =
        PythLazer(
            pythLazerFeedVerifier
        );
}

The deployment configuration must pass the Oracle contract address, and existing deployments would need to migrate to the corrected provider and update the configured provider for affected tokens.

Why the fix preserves the intended flow

The legitimate call already originates through Oracle:

Controller
    ↓
Oracle.setPrices
    ↓
Oracle._validatePrices
    ↓
PythLazerFeedProvider.getOraclePrice

After the fix:

Oracle.setPrices
ALLOWED

Oracle.setPricesForAtomicAction
ALLOWED through Oracle

Direct external provider call
REJECTED

Provider funding
UNCHANGED

Authorized Pyth Lazer verification
UNCHANGED

The patch does not remove provider-funded verification.

It restricts who can trigger that expenditure.

Regression coverage

The regression suite should permanently establish:

Direct attacker call to PythLazerFeedProvider.getOraclePrice
REVERTS

Oracle.setPrices with valid Pyth Lazer data
SUCCEEDS when provider is funded

Repeated unauthorized calls
CANNOT reduce provider balance

Authorized Oracle calls
CAN spend the configured verification fee

Direct Chainlink provider calls
CONTINUE to revert

It is also worth applying the same review rule to any future provider that pays an external service from protocol-owned funds.

The broader audit lesson

A function named getOraclePrice sounds like a read.

This one was a spend.

That distinction is easy to miss during a large protocol review.

The moment a function performs:

externalCall{
    value: protocolFunds
}(...)

the audit needs to treat caller authorization as an economic security boundary.

The useful question is not only:

Can the returned data be trusted?

It is also:

Who controls how often this contract pays to obtain that data?

In this case, the answer was:

Any external account with valid update data

That was enough to turn the oracle fee balance into a permissionless griefing surface.

Conclusion

PythLazerFeedProvider held ETH to pay Pyth Lazer verification fees.

Its getOraclePrice function was externally callable and did not restrict the caller to the protocol Oracle.

Every successful call executed:

pythLazer.verifyUpdate{
    value: fee
}(
    data
);

using ETH from the provider itself.

The attacker sent zero ETH.

Five real transactions consumed the complete 0.05 ETH test balance.

The verifier received the same 0.05 ETH.

Before depletion, the legitimate Oracle.setPrices flow succeeded.

After depletion, that same path failed because the provider could no longer fund verification.

The finding was submitted as Medium through HackenProof and earned $1.24.

The engineering lesson is broader than this one provider:

If the protocol funds oracle verification, permission to request that verification is permission to spend protocol funds.

That permission should belong to the protocol’s Oracle path, not to every external account.

How Integer-Truncated Vote Weights Could Lock WEMIX Governance for Seven Days

Daniel — Fri, 07 Aug 2026 02:27:42 +0000

A governance ballot should not remain open after every eligible member has already voted.

WEMIX could reach exactly that state.

Each member received equal voting power through integer division:

uint256 weight =
    10000
        /
    getMemberLength();

With six members:

10000 / 6
1666 per voter

The division discarded the remainder.

Even after all six members voted, the maximum recorded power was:

1666 × 6
9996

The finalization logic required one side to reach the 5001 threshold or the combined power to equal exactly 10000:

if (
    accept >= threshold
        ||
    reject >= threshold
        ||
    (
        accept
            +
        reject
    )
        ==
    10000
) {
    finalizeVote(
        ballotIdx,
        ballotType,
        accept > reject,
        false
    );
}

A three-to-three split therefore produced:

Accept power
4998

Reject power
4998

Total power
9996

Neither side reached 5001.

The total could never reach 10000.

Every eligible member had voted.

Duplicate votes were correctly rejected.

The ballot still remained InProgress.

Because WEMIX used ballotInVoting as a singleton active-voting slot, that fully participated ballot prevented another valid governance proposal from being voted until the maximum duration expired.

The proof of concept used the configured maximum duration:

604800 seconds
7 days

It then created a valid operational emergency proposal and demonstrated:

Emergency vote before timeout
Reverted

Emergency vote at endTime minus one
Reverted

Timeout cleanup
Succeeded

Emergency vote after cleanup
Succeeded

I submitted this report as Major through the WEMIX bug bounty program hosted on CertiK Skynet.

The program classified it as Low and paid a $100 bounty.

That classification does not match the demonstrated impact.

This was not a cosmetic four-unit rounding discrepancy.

Those four unreachable units made fully recorded participation indistinguishable from incomplete voting power and allowed one ballot to block the governance voting pipeline for seven days.

The complete public report and proof of concept are available in the GitHub Gist.

The invariant that failed

Equal-weight governance does not require 10000 to divide perfectly by every possible member count.

It does require the protocol to recognize when every eligible voter has participated.

The invariant should be:

Once every eligible member has voted, arithmetic rounding must not keep the ballot active.

WEMIX inferred full participation from:

accept power + reject power == 10000

That proxy works only when:

10000 % memberCount == 0

For six members:

10000 % 6
4

Those four units were never assigned to any voter.

The contract interpreted the missing power as incomplete participation even though the authoritative voter count already showed that all six members had voted.

Where the voting power was truncated

createVote calculated the weight at the moment each vote was created:

function createVote(
    uint256 ballotIdx,
    bool approval
)
    private
{
    uint256 voteIdx =
        voteLength
            +
        1;

    address staker =
        getStakerAddr(
            msg.sender
        );

    uint256 weight =
        10000
            /
        getMemberLength();

    uint256 decision =
        approval
            ?
        uint256(
            DecisionTypes.Accept
        )
            :
        uint256(
            DecisionTypes.Reject
        );

    IBallotStorage(
        getBallotStorageAddress()
    ).createVote(
        voteIdx,
        ballotIdx,
        staker,
        decision,
        weight
    );

    voteLength =
        voteIdx;
}

With six members:

Exact mathematical weight
1666.666...

Stored weight
1666

The remainder was not distributed, stored, or reconciled later.

That alone would have been a minor precision issue if ballot finalization used the actual participation count.

It did not.

Finalization depended on an unreachable equality

After recording a vote, GovImp.vote read the accumulated power:

(
    ,
    uint256 accept,
    uint256 reject
) =
    getBallotVotingInfo(
        ballotIdx
    );

uint256 threshold =
    getThreshold();

if (
    accept >= threshold
        ||
    reject >= threshold
        ||
    (
        accept
            +
        reject
    )
        ==
    10000
) {
    finalizeVote(
        ballotIdx,
        ballotType,
        accept > reject,
        false
    );
}

The three finalization conditions were:

Accept reaches 5001

Reject reaches 5001

Combined power reaches exactly 10000

For a balanced six-member vote:

3 × 1666
4998 accept

3 × 1666
4998 reject

Every condition remained false.

The ballot was fully participated but numerically unable to prove it.

The contract already knew that everybody had voted

BallotStorageImp tracked the real number of voters:

_ballot.totalVoters =
    _ballot.totalVoters
        +
    1;

It also prevented duplicate votes:

require(
    !hasVotedMap[
        _ballotId
    ][
        _voter
    ],
    "already voted"
);

After the sixth vote:

totalVoters
6

eligible members
6

all members voted
Yes

But the finalization path ignored totalVoters.

That created an impossible lifecycle state:

Every eligible member has voted
True

Any member can vote again
False

Either side reached threshold
False

Combined power equals 10000
False

Ballot finalized
False

The missing four units could not be supplied by any legitimate action.

Why another vote could not fix the ballot

Once all six members had voted, the duplicate-vote protection correctly rejected every further attempt.

Before timeout:

Additional eligible voters
0

Duplicate voting allowed
No

Power still missing
4

Normal finalization available
No

The ballot was not waiting for participation.

It was waiting for voting power that the formula had made unreachable.

BallotInVoting amplified one rounding bug

WEMIX allowed only one ballot to occupy the active voting slot.

When a ready ballot began, checkVotable required:

require(
    ballotInVoting == 0,
    "Now in voting with different ballot"
);

It then assigned:

ballotInVoting =
    ballotIdx;

If a ballot was already InProgress, voting was restricted to that same ballot:

require(
    ballotIdx
        ==
    ballotInVoting,
    "Now in voting with different ballot"
);

The affected ballot therefore did more than remain unresolved.

It occupied the shared voting slot and blocked every different proposal from entering the voting flow.

The PoC blocked a valid emergency proposal

After creating the stuck ballot, the proof created a separate valid operational environment proposal.

Proposal creation succeeded.

Voting on it reverted because ballotInVoting still referenced the fully voted split ballot.

The test then advanced time to:

endTime - 1

The emergency vote still reverted.

Only after moving beyond the end time could a member call:

finalizeEndedVote();

The timeout cleanup rejected the expired ballot and reset:

ballotInVoting =
    0;

The same emergency proposal then became votable and finalized normally.

The demonstrated sequence was:

Fully participated split ballot
Remained InProgress

Emergency proposal
Created

Emergency vote before timeout
Blocked

Emergency vote one second before expiry
Blocked

Timeout cleanup
Succeeded

Emergency vote after cleanup
Succeeded

This moved the impact beyond incorrect accounting and into governance liveness.

The lock used the real maximum duration

The PoC read:

getBallotDurationMax()
604800

That equals seven days.

The affected ballot was created with this valid configured duration.

The test did not invent a delay outside protocol rules.

It proved that the contract could keep the active voting slot occupied for the maximum duration allowed by governance.

For an operational emergency proposal, seven days is a material delay.

The ballot and voters were valid

The proof removed several alternative explanations.

Every participant was:

A real governance member

A real staker

Assigned a nonzero staker index

Within the required staking range

The member count was read from the real contract and remained six during the affected ballot.

The proposal was a valid addProposalToChangeEnv ballot.

There was no voter-only target, invalid role configuration, NCP exit path, delegated reserve path, or understaked member.

The stuck state came directly from the voting-power formula and the finalization conditions.

What the proof used

The Go test exercised the real:

GovImp

GovImp.vote

GovImp.checkVotable

GovImp.finalizeEndedVote

BallotStorageImp

BallotStorageImp.createVote

BallotStorageImp.hasVotedMap

StakingImp

Current member count

Configured maximum ballot duration

The vulnerable arithmetic and lifecycle logic were not copied into a simplified contract.

The command was:

go test ./wemix/governance-contract/test \
    -run TestVoteRounding \
    -count=1 \
    -v

The test passed.

Exact runtime result

The proof recorded:

Current member count
6

Vote weight
1666

Recorded full-participation power
9996

Lost remainder
4

Accept voters
3

Reject voters
3

Accept power
4998

Reject power
4998

Threshold
5001

All voters participated
Yes

Ballot state
InProgress

Maximum duration
604800 seconds

The liveness assertions recorded:

Further votes can clear the ballot
No

Emergency vote before timeout
Reverted

Emergency vote at endTime minus one
Reverted

Timeout cleanup
Succeeded

Emergency vote after cleanup
Succeeded

The clean controls also showed:

Emergency proposal without a stuck ballot
Votable

Normal majority ballot
Finalized

These controls isolated integer truncation as the cause of the lock.

Why this is a separate finding

This report is distinct from the other WEMIX governance findings.

It does not use a voter-only target

Every voter was a real staker with a nonzero staker index.

It does not involve NCPExit

No exit reserve, delegated balance, or exit mapping was involved.

It does not remove an NCP

The test never reached transferLockedAndUnlock.

It does not depend on minStaking underflow

Every voter remained within the required staking range.

It is entirely on chain

The root cause exists in smart contract vote arithmetic and ballot finalization, not in the client or P2P layer.

What the proof establishes

The proof directly demonstrates:

Six valid members

1666 power per vote

Four voting-power units lost

All six members voted

Three accepted and three rejected

4998 power on each side

9996 total power

No threshold reached

Ballot remained InProgress

No voter could vote again

Another valid proposal could not be voted

The block persisted at endTime minus one

Timeout cleanup restored governance

The emergency proposal succeeded afterward

The proof does not demonstrate:

Direct theft

Permanent governance takeover

Permanent fund freeze

Protocol insolvency

Unauthorized minting

Permanent network shutdown

A lock that survives the configured timeout

Those limits are why the report was submitted as Major rather than Critical.

Why this is Major, not Low

The issue caused a temporary denial of service against the governance voting pipeline.

The ballot had complete participation

This was not a proposal waiting for absent members.

Every eligible voter had acted.

The protocol still failed to finalize it.

The only active voting slot remained occupied

ballotInVoting prevented any different proposal from being voted.

The impact therefore extended beyond the original split ballot.

A valid emergency proposal was demonstrably blocked

The PoC created another valid proposal and showed that its vote reverted both before timeout and at endTime - 1.

The lock lasted seven days

The duration came from the real getBallotDurationMax() configuration.

Recovery was available only after timeout cleanup.

That makes the issue temporary, which rules out Critical, but it does not make the impact Low.

No invalid privilege was required

The state could arise from six legitimate members casting ordinary votes.

No outsider, invalid role, administrator key, or contract owner permission was needed to create the vulnerable ballot state.

Low does not fit the demonstrated effect

Low would fit:

A displayed percentage discrepancy

A harmless four-unit rounding loss

A ballot that still finalized from voter count

A state that did not affect other proposals

A delay immediately recoverable through another vote

This report showed a fully participated ballot preventing emergency governance voting for the maximum configured duration.

That is Major.

Why the $100 outcome understates the evidence

The final Low classification produced a $100 bounty.

That records the program decision.

It does not change the observed result:

Eligible voters
6

Votes cast
6

Recorded power
9996

Ballot finalized
No

Emergency vote before timeout
Reverted

Emergency vote one second before expiry
Reverted

Governance restored only after timeout
Yes

The vulnerability was not the numerical difference between 9996 and 10000.

The vulnerability was the lifecycle consequence:

Full participation was treated as incomplete participation, allowing one ballot to block every other governance vote for seven days.

That is a Major governance liveness failure.

Why I describe the WEMIX handling as systematic downgrading

Severity disagreements are normal in bug bounty programs.

My concern is the recurring outcome across my own valid WEMIX submissions.

Reports supported by reproducible proofs and concrete protocol behavior were repeatedly assigned substantially lower final severities.

This report was submitted as Major.

The PoC showed every eligible member voting, the ballot remaining InProgress, duplicate votes being impossible, a valid emergency proposal being blocked at endTime - 1, and governance recovering only after timeout cleanup.

It was classified as Low.

I cannot infer intent from that decision.

I can document the repeated outcome and compare the final classification with the technical evidence.

Calling it systematic downgrading describes that recurring pattern across my WEMIX submissions without claiming a motive.

A technically convincing Low justification would need to explain why these effects are minor:

Every eligible member already voted

The ballot still remained active

No additional vote could change the result

BallotInVoting blocked another valid proposal

The emergency vote remained blocked for seven days

Only timeout cleanup restored voting

Without addressing those facts, the Low classification does not match the proof.

The minimal correction

The contract already tracked totalVoters.

The minimal correction is to use the actual participation count instead of an exact rounded-power equality.

Inside vote:

(
    uint256 totalVoters,
    uint256 accept,
    uint256 reject
) =
    getBallotVotingInfo(
        ballotIdx
    );

uint256 threshold =
    getThreshold();

if (
    accept >= threshold
        ||
    reject >= threshold
        ||
    totalVoters
        >=
    getMemberLength()
) {
    finalizeVote(
        ballotIdx,
        ballotType,
        accept > reject,
        false
    );
}

The corresponding validation in fromValidBallot should use the same rule:

(
    uint256 totalVoters,
    uint256 accept,
    uint256 reject
) =
    getBallotVotingInfo(
        ballotIdx
    );

require(
    accept >= getThreshold()
        ||
    reject >= getThreshold()
        ||
    totalVoters
        >=
    getMemberLength(),
    "Not yet finalized"
);

This makes full participation depend on actual voters rather than a power total that may be mathematically unreachable.

Hardening the fix

Using the current member count is the smallest compatible correction for the demonstrated flow.

A more robust governance design should snapshot the number of eligible voters when the ballot starts and compare totalVoters against that snapshot.

That prevents later membership changes from redefining what full participation means for an already active ballot.

The invariant becomes:

totalVoters >= eligibleVotersAtBallotStart

Why the correction preserves existing behavior

The patch keeps:

Accept threshold finalization

Reject threshold finalization

Duplicate-vote prevention

Existing majority behavior

Existing tie outcome

A full-participation tie still reaches:

accept > reject

and finalizes as rejected under the existing decision rule.

The only behavior removed is the invalid state where every eligible voter has participated but integer truncation keeps the ballot open.

Regression tests

A complete correction should verify:

Six members with a three-to-three split finalize after the sixth vote
Full participation finalizes for every supported member count even when 10000 is not evenly divisible
Majority acceptance remains unchanged
Majority rejection remains unchanged
Duplicate votes remain rejected
Finalization releases ballotInVoting
Another valid proposal becomes votable immediately
fromValidBallot uses the same full-participation rule
Membership changes cannot redefine the eligible voter count for an active ballot

The central invariant is:

Once every voter eligible for a ballot has voted, integer rounding must not keep that ballot active.

Broader lessons

Percentages should not replace participation counts

A rounded power total is not authoritative evidence that everybody has voted.

The contract already stored the real count.

Exact equality turns small remainders into liveness failures

Losing four units appears minor.

Requiring exactly 10000 converted that small arithmetic loss into a seven-day governance lock.

Singleton state amplifies local bugs

One ballot failed to finalize.

Because ballotInVoting was global, every other proposal was affected.

Emergency governance must be tested behind existing state

Creating an emergency proposal is not enough.

The protocol must also prove that it can enter voting while previous ballots exist.

Full participation is a protocol event

It should be detected from eligible voters and recorded participation, not inferred from a percentage sum that may truncate.

Conclusion

WEMIX governance had six valid members.

Each vote received:

All six votes produced:

A three-to-three split recorded:

Accept
4998

Reject
4998

No side reached 5001.

The total never reached 10000.

Every eligible member had voted.

Nobody could vote again.

The ballot remained InProgress.

Because it occupied ballotInVoting, a valid emergency proposal could not be voted.

The lock remained at endTime - 1.

Only after the maximum duration of 604800 seconds could timeout cleanup restore governance voting.

The program classified the report as Low and paid $100.

The demonstrated impact was Major.

The report did not claim theft, permanent takeover, or permanent shutdown.

It demonstrated a narrower and directly proven failure:

Integer-truncated vote weights could keep a fully participated ballot active and block all other governance voting for seven days.

A governance ballot that has received every possible vote but still blocks emergency action until maximum timeout is not a Low-severity issue.

How a MinStaking Increase Could Make an Understaked WEMIX NCP Unremovable

Daniel — Fri, 07 Aug 2026 01:50:39 +0000

A governance system should always be able to remove a member that no longer satisfies its active staking requirements.

WEMIX had a state where the opposite happened.

An NCP could join governance while the current minStaking requirement was satisfied.

Governance could later raise that minimum above the NCP’s locked balance.

The NCP would remain in the member set, but checkLockedAmount would prevent it from voting or creating proposals.

That was already an inconsistent state:

Still a governance member
Yes

Still satisfies the current staking minimum
No

Can vote
No

Can create proposals
No

The deeper failure appeared when valid members tried to remove it.

The finalization path reached:

uint256 ext =
    locked
        -
    getMinStaking();

When:

locked < current minStaking

Solidity 0.8 checked arithmetic reverted before either removal branch could run.

The entire transaction rolled back.

The understaked NCP remained in the governance member set.

The proof of concept demonstrated:

Initial minStaking
1,500,000 WEMIX

Target locked balance
1,500,000 WEMIX

Current minStaking after increase
2,000,000 WEMIX

Target remains a member
True

Target vote
Reverted

Target proposal
Reverted

Removal proposal from a valid member
Succeeded

Removal parameters
Valid

Removal finalization
Reverted

Target remains a member after failed removal
True

I submitted this report as Major through the WEMIX bug bounty program hosted on CertiK Skynet.

The program classified it as Low and paid a $100 bounty.

That classification does not match the demonstrated impact.

This was not a harmless arithmetic edge case.

The underflow disabled the standard cleanup path for exactly the member state governance needed to clean up.

The result was a governance lifecycle denial of service: an NCP that no longer met the current minimum could neither participate normally nor be removed through the ordinary finalization flow.

The complete public report and proof of concept are available in the GitHub Gist.

The invariant governance must preserve

A configurable staking minimum can change over time.

That means governance must safely handle members who were valid under an earlier value but fall below a later one.

The required invariant is:

An NCP that becomes understaked after a valid minStaking change must remain removable by valid governance members.

WEMIX violated that invariant.

The same parameter increase that disabled the target’s normal participation also created the arithmetic condition that blocked its removal.

Governance could therefore create a member state that its own cleanup logic could not resolve.

The target entered governance legitimately

The PoC did not begin with an invalid or manually corrupted member.

The initial minimum was:

1,500,000 WEMIX

The target locked:

1,500,000 WEMIX

At admission time:

locked balance >= current minStaking

The target satisfied the active requirement and entered through the real membership flow.

No admission check was bypassed.

No storage was modified directly.

The vulnerable state appeared only after a later governance parameter change.

Governance raised minStaking above the target balance

The proof used the real environment proposal flow to raise minStaking to:

2,000,000 WEMIX

The target remained locked at:

1,500,000 WEMIX

The resulting state was:

Target locked balance
1,500,000 WEMIX

Current minStaking
2,000,000 WEMIX

Shortfall
500,000 WEMIX

The target remained present in the actual member set.

The parameter change did not automatically remove it, migrate it, or place it into a separate cleanup state.

The target lost normal governance participation

The ordinary governance gate was:

modifier checkLockedAmount() {
    address staker =
        getStakerAddr(
            _msgSender()
        );

    require(
        lockedBalanceOf(
            staker
        )
            <=
        getMaxStaking()
            &&
        lockedBalanceOf(
            staker
        )
            >=
        getMinStaking(),
        "Invalid staking balance"
    );

    _;
}

After the increase, the target failed:

lockedBalanceOf(target) >= getMinStaking()

The PoC confirmed that the target’s vote reverted.

It also confirmed that the target could not create a normal proposal protected by the same modifier.

The target therefore remained a governance member in storage while losing the ordinary powers associated with membership.

A valid member could still create the removal proposal

Another member remained above the new minimum.

That valid member created a proposal to remove the understaked target.

The relevant proposal checks included:

require(
    isMember(
        staker
    ),
    "Non-member"
);

require(
    lockedBalanceOf(
        staker
    )
        >=
    lockAmount,
    "Insufficient balance that can be unlocked."
);

The PoC used:

unlockAmount
1,500,000 WEMIX

slashing
0 WEMIX

The removal helper later required:

require(
    unlockAmount
        +
    slashing
        <=
    getMinStaking(),
    "minStaking value must be greater than or equal to the sum of unlockAmount, slashing"
);

The values were valid:

1,500,000 + 0 <= 2,000,000

The proposal was accepted.

The voting member was valid.

The target was still a member.

The failure occurred only when the approved cleanup reached finalization.

Finalization reached the vulnerable helper

The real removal flow called:

transferLockedAndUnlock(
    ballotIdx,
    oldStaker
);

The affected helper was:

function transferLockedAndUnlock(
    uint256 ballotIdx,
    address addr
)
    private
{
    (
        uint256 unlockAmount,
        uint256 slashing
    ) =
        getBallotForExit(
            ballotIdx
        );

    require(
        unlockAmount
            +
        slashing
            <=
        getMinStaking(),
        "minStaking value must be greater than or equal to the sum of unlockAmount, slashing"
    );

    IStaking staking =
        IStaking(
            getStakingAddress()
        );

    uint256 locked =
        staking.lockedBalanceOf(
            addr
        );

    uint256 ext =
        locked
            -
        getMinStaking();

    if (
        locked
            >
        unlockAmount
    ) {
        unlock(
            addr,
            unlockAmount
        );

        staking.transferLocked(
            addr,
            slashing,
            ext
        );
    } else {
        unlock(
            addr,
            locked
        );
    }
}

The implementation assumed:

locked >= current minStaking

That assumption was valid for an active member before the parameter increase.

It was not valid for the member state created by the increase itself.

The underflow happened before branch selection

The concrete values were:

locked
1,500,000 WEMIX

current minStaking
2,000,000 WEMIX

The helper attempted:

1,500,000
-
2,000,000

The subtraction reverted.

The function never reached:

if (
    locked
        >
    unlockAmount
)

This distinction is important.

The bug was not that the wrong branch executed.

No cleanup branch executed at all.

The arithmetic failed before the function could decide how to unlock or transfer the target’s stake.

Atomic rollback restored every removal change

removeMember modified membership structures before calling transferLockedAndUnlock.

It removed entries from the staker, voter, reward, and node structures, reduced the member count, and then reached the vulnerable helper.

But EVM transactions are atomic.

When the helper reverted, every earlier state update in that transaction reverted too.

The final state was:

Target was a member before finalization
True

Removal finalization
Reverted

Target is a member afterward
True

Target locked balance afterward
1,500,000 WEMIX

The source code may appear to remove the member first.

The committed state did not.

The target was trapped in a contradictory lifecycle state

After the minimum increase and failed cleanup:

Target remains a member
True

Target satisfies current minStaking
False

Target can vote
False

Target can create proposals
False

Valid members can propose removal
True

Approved removal can finalize
False

The member was too understaked to participate.

The same understaked condition caused the removal calculation to revert.

This is the core lifecycle failure.

The controls isolate the exact cause

The proof included three positive controls.

Top up control

The target added enough stake to satisfy the new minimum.

Afterward:

locked >= current minStaking

The subtraction no longer underflowed.

Removal succeeded.

Lower minimum control

Governance lowered minStaking back to the target’s locked amount.

Again:

locked >= current minStaking

Removal succeeded.

Healthy removal control

A target that never became understaked was removed successfully through the ordinary path.

Together, the controls demonstrate:

Proposal creation works

Voting works

Removal works for healthy members

Removal works after a top up

Removal works after lowering the minimum

Removal fails specifically while locked < current minStaking

That isolates the unchecked subtraction as the root cause.

The PoC used the real governance path

The Go proof used:

Real GovImp

Real StakingImp

Real EnvStorageImp

Real BallotStorageImp

Real addProposalToChangeEnv

Real addProposalToRemoveMember

Real vote finalization

Real transferLockedAndUnlock

The vulnerable calculation was not copied into a simplified contract.

The primary path used:

No delegated user reserve

No NCPExit deposit

No NCPExit mapping overwrite

No public RPC

No mainnet or testnet dependency

The command was:

go test ./wemix/governance-contract/test \
    -run TestUnder \
    -count=1 \
    -v

The test passed and confirmed:

Target became below minStaking
Pass

Target vote rejected
Pass

Target proposal rejected
Pass

Removal proposal accepted
Pass

Removal finalization reverted
Pass

Target remained a member
Pass

Top up control removal succeeded
Pass

Lower minimum control removal succeeded
Pass

Healthy removal control succeeded
Pass

Why this is a separate finding

This issue is distinct from the previous WEMIX NCP exit reports.

It is not the NCPExit overwrite

That finding required multiple deposits for the same NCP and overwrote existing exit accounting.

This report:

Does not call NCPExit twice

Does not overwrite NCPExit mappings

Does not strand value already deposited into NCPExit

The root cause is an unchecked subtraction in GovImp.transferLockedAndUnlock.

It is not the delegated exit skip

The delegated reserve finding used:

locked == current minStaking

Removal completed, but the delegated reserve was not transferred to NCPExit.

This report uses:

locked < current minStaking

Removal does not complete.

The transaction reverts before either branch can run.

One issue completes removal with broken delegated accounting.

This issue blocks removal itself.

What the proof establishes

The proof directly demonstrates:

The target entered under a valid earlier minimum

Governance raised minStaking above the target balance

The target remained in the member set

The target could no longer vote

The target could no longer create proposals

A valid member created the removal proposal

The removal parameters passed their bounds

Finalization reached the real removal path

locked - getMinStaking underflowed

The transaction reverted

The target remained a member

Three control paths succeeded after the underflow condition was removed

The proof does not demonstrate:

Direct theft

Loss of user balances

Protocol-wide insolvency

Permanent network shutdown

An arbitrary external attacker changing governance parameters

A state that no upgrade or parameter change could recover

Those limits are why the report was submitted as Major rather than Critical.

Why this is Major, not Low

The report demonstrates a governance lifecycle denial of service.

The invalid member loses participation

After the parameter change, checkLockedAmount blocks the target from voting and proposing.

The target remains in governance without satisfying the current requirement.

The standard cleanup path is unavailable

Valid members can create and approve a removal proposal.

Finalization still reverts.

The ordinary mechanism intended to restore membership integrity cannot complete.

The actual member set remains inconsistent

This is not a view-only mismatch.

The target remains in the real member set after the failed transaction.

The failure is deterministic

Whenever the removal helper evaluates:

locked < current minStaking

the subtraction reverts before any branch runs.

No race, timing condition, or frontend behavior is required.

Recovery requires another state transition

The PoC demonstrated three recovery classes:

The target voluntarily tops up

Governance rolls minStaking back down

The implementation is corrected

Until one of those occurs, the standard removal finalization remains blocked.

Low does not fit the result

Low would fit:

A harmless arithmetic value

A reverted view function

A cosmetic member-status mismatch

An unreachable edge case

A failed path with another normal cleanup route

This report showed the real governance cleanup transaction reverting and the invalid member remaining in the actual member set.

That is Major.

Why the $100 outcome understates the evidence

The final Low classification produced a $100 bounty.

That records the program decision.

It does not change the observed result:

Initial minStaking
1,500,000 WEMIX

Current minStaking
2,000,000 WEMIX

Target locked
1,500,000 WEMIX

Target participation
Blocked

Removal proposal
Valid

Removal finalization
Reverted

Target remains a member
True

The demonstrated impact was not a theoretical unsigned subtraction.

It was governance cleanup denial of service.

A member that no longer satisfies the active requirement can remain stuck until a top up, parameter rollback, or implementation correction removes the condition.

That is not Low severity.

Why I describe the WEMIX handling as systematic downgrading

Severity disagreements are normal in bug bounty programs.

My concern is the recurring outcome across my own valid WEMIX submissions.

Reports supported by reproducible proofs and concrete protocol behavior were repeatedly assigned substantially lower final severities.

This report was submitted as Major.

The proof showed a valid governance parameter change producing an understaked member that could no longer participate and could not be removed because the real finalization path reverted.

It was classified as Low.

I cannot infer intent from that decision.

I can document the repeated outcome and compare the final classification with the technical evidence.

Calling it systematic downgrading describes that recurring pattern across my WEMIX submissions without claiming a motive.

A technically convincing Low justification would need to explain why these effects are minor:

An invalid NCP remaining in the actual member set

The target unable to vote or propose

A valid removal proposal being accepted

Finalization reverting deterministically

The target remaining a member after failed cleanup

Removal succeeding only after the underflow condition is eliminated

Without addressing those facts, the Low classification does not match the proof.

The minimal safe correction

The subtraction must occur only when excess stake actually exists.

The report proposed:

function transferLockedAndUnlock(
    uint256 ballotIdx,
    address addr
)
    private
{
    (
        uint256 unlockAmount,
        uint256 slashing
    ) =
        getBallotForExit(
            ballotIdx
        );

    uint256 minStaking =
        getMinStaking();

    require(
        unlockAmount
            +
        slashing
            <=
        minStaking,
        "minStaking value must be greater than or equal to the sum of unlockAmount, slashing"
    );

    IStaking staking =
        IStaking(
            getStakingAddress()
        );

    uint256 locked =
        staking.lockedBalanceOf(
            addr
        );

    uint256 ext =
        0;

    if (
        locked
            >
        minStaking
    ) {
        ext =
            locked
                -
            minStaking;
    }

    if (
        locked
            >
        unlockAmount
    ) {
        unlock(
            addr,
            unlockAmount
        );

        staking.transferLocked(
            addr,
            slashing,
            ext
        );
    } else {
        unlock(
            addr,
            locked
        );
    }
}

The rule becomes:

If locked > minStaking
ext = locked - minStaking

Otherwise
ext = 0

There is no unsigned negative excess.

The function can reach the appropriate cleanup branch instead of reverting during arithmetic.

Why the correction preserves existing behavior

For a member above the minimum:

ext = locked - minStaking

The existing excess calculation remains unchanged.

For a member exactly at the minimum:

ext = 0

That is the correct mathematical excess.

For a member below the minimum:

ext = 0

The cleanup no longer attempts an impossible unsigned subtraction.

The proposal bound remains intact:

unlockAmount + slashing <= current minStaking

The patch does not weaken that rule.

Delegated reserve scenarios still require regression coverage together with the separate delegated exit correction because that report addresses a different accounting invariant.

Regression tests

A complete correction should verify:

A target below the current minimum can be removed
A target exactly at the current minimum preserves existing behavior
A target above the current minimum preserves the excess path
Valid members can still create and finalize removal proposals
The target no longer remains in membership after successful cleanup
Top up and lower-minimum controls continue to succeed
Delegated reserve scenarios remain safe with the separate delegated exit fix

The central invariant is:

A valid minStaking change must never create an NCP state that is both ineligible to participate and impossible to remove.

Broader lessons

Configuration changes create migration states

Raising a minimum does not automatically migrate existing members.

Cleanup logic must support members admitted under the previous value.

Removal code must handle invalid members

A removal path exists to process members that should no longer remain.

It cannot assume the target still satisfies every current admission requirement.

Arithmetic should follow the condition it represents

ext represented stake above the current minimum.

The code calculated it before checking whether any excess existed.

Atomicity can hide failed cleanup

The source removed membership entries before calling the helper.

The later revert restored all of them.

Only the committed state determines whether removal succeeded.

Controls make lifecycle findings stronger

The top up, lower-minimum, and healthy controls proved that the entire governance system was not generically broken.

The failure was the exact state:

locked < current minStaking

Conclusion

The target entered governance with:

Locked balance
1,500,000 WEMIX

Initial minStaking
1,500,000 WEMIX

Governance later raised the minimum to:

2,000,000 WEMIX

The target remained a member but could no longer vote or propose.

A valid member created a valid removal proposal.

During finalization, transferLockedAndUnlock attempted:

1,500,000
-
2,000,000

The subtraction reverted before either branch executed.

The whole removal transaction rolled back.

The understaked NCP remained in the member set.

The program classified the report as Low and paid $100.

The demonstrated impact was Major.

The report did not claim theft, insolvency, or permanent network shutdown.

It demonstrated a narrower and directly proven failure:

A valid minStaking increase could leave an NCP too understaked to participate and understaked in a way the normal removal calculation could not safely handle.

A governance cleanup path that cannot remove the invalid member it was invoked to remove is not a Low severity issue.

How Unsolicited EtcdCluster Packets Could Stall or Redirect WEMIX Mining Coordination

Daniel — Fri, 07 Aug 2026 01:04:40 +0000

A node that asks one peer for a cluster response should not accept the first answer broadcast by somebody else.

WEMIX etcdJoin did exactly that.

The function selected a specific peer, sent admin_requestEtcdAddMember for that peer’s ID, and then waited for a response through a global feed:

ch := make(
    chan string,
    16,
)

sub :=
    wemixapi.SubscribeToEtcdCluster(
        ch,
    )

That feed carried only:

Cluster string

It did not carry:

Sending peer ID

Request ID

Pending join identity

Meanwhile, every accepted partner EtcdCluster packet was published into the same feed:

go wemixapi.GotEtcdCluster(
    cluster,
)

As a result, another WEMIX partner peer could send an unsolicited cluster string before the legitimate response arrived.

The target would consume that value as though it answered the pending join.

The proof of concept demonstrated the real etcdJoin requesting:

legit-id

and then consuming an attacker value first.

The join returned:

not found

before the legitimate response was released.

A separate control showed that an attacker-influenced cluster containing the local node endpoint passed etcdFixCluster and became a valid InitialCluster candidate.

I submitted this report as Major through the WEMIX bug bounty program hosted on CertiK Skynet.

The program classified it as Low and paid a $100 bounty.

That classification does not match the demonstrated impact.

This was not a harmless unsolicited packet.

It was request confusion in a privileged P2P control plane used for mining coordination.

The complete public report and proof of concept are available in the GitHub Gist.

The security invariant

WEMIX uses etcd as part of the coordination layer for mining nodes.

A node joining that cluster needs an InitialCluster configuration describing the expected members and endpoints.

The request-response invariant should be simple:

A join request sent for peer A must be completed only by a response correlated with peer A and that pending request.

Partner status alone is not enough.

A peer may be authorized to participate in the partner protocol without being authorized to answer every join request currently pending on the target.

EtcdJoin selected a legitimate peer

The request side knew which peer it wanted:

func (
    ma *wemixAdmin,
) etcdJoin(
    name string,
) error {
    var node *wemixNode

    ma.lock.Lock()

    for _, i :=
        range ma.nodes {
        if i.Name == name ||
            i.Enode == name ||
            i.Id == name ||
            i.Ip == name {
            node = i
            break
        }
    }

    ma.lock.Unlock()

    if node == nil {
        return ethereum.NotFound
    }

The function later issued:

err :=
    admin.rpcCli.CallContext(
        ctx,
        nil,
        "admin_requestEtcdAddMember",
        &node.Id,
    )

In the PoC, the selected peer was:

Name
legit

ID
legit-id

The RPC boundary confirmed that etcdJoin requested the correct ID.

The failure was not incorrect peer selection.

The failure was losing that identity while waiting for the response.

The response path discarded correlation

The subscription API exposed a process-wide feed of strings:

func SubscribeToEtcdCluster(
    ch chan string,
) event.Subscription {
    return etcdClusterFeed.Subscribe(
        ch,
    )
}

func GotEtcdCluster(
    cluster string,
) {
    etcdClusterFeed.Send(
        cluster,
    )
}

The consumer received no origin information.

Once a value entered the feed, etcdJoin could not determine:

Which peer sent it

Which request it answered

Whether it was solicited

Whether it arrived for another concurrent operation

This is the root cause.

A broadcast notification channel was used as though it were a correlated response channel.

Any accepted partner packet entered that feed

The P2P handler checked whether both the local node and the sending peer were WEMIX partners:

func handleEtcdCluster(
    backend Backend,
    msg Decoder,
    peer *Peer,
) error {
    if !wemixminer.AmPartner() ||
        !wemixminer.IsPartner(
            peer.ID(),
        ) {
        return nil
    }

    var cluster string

    if err :=
        msg.Decode(
            &cluster,
        );
        err != nil {
        return fmt.Errorf(
            "%w: message %v: %v",
            errDecode,
            msg,
            err,
        )
    }

    go wemixapi.GotEtcdCluster(
        cluster,
    )

    return nil
}

The partner check is a real exploitation precondition.

The report does not claim that an arbitrary public peer can reach this path.

But after the check, peer.ID() was discarded.

Only the cluster string survived.

The code transformed:

A message from partner X

into:

An originless global event

That allowed one partner to satisfy a request intended for another.

First response wins

The relevant response branch inside etcdJoin was:

case cluster :=
    <-ch:

    cluster, err :=
        ma.etcdFixCluster(
            cluster,
        )

    if err != nil {
        log.Error(
            "etcd failed to join",
            "error",
            err,
        )

        return err
    }

    cfg :=
        ma.etcdNewConfig(
            false,
        )

    cfg.InitialCluster =
        cluster

    etcd, err :=
        embed.StartEtcd(
            cfg,
        )

The first delivered value controlled the attempt.

If etcdFixCluster rejected it, etcdJoin returned immediately.

It did not ignore the unrelated packet and continue waiting for the expected peer.

If the value passed parsing, the result became:

cfg.InitialCluster =
    cluster

The code never compared the response against:

node.Id

Expected partner

Pending request ID

The parser could reject or preserve attacker input

etcdFixCluster required the local node to appear in the candidate cluster.

If the local entry was absent, it returned:

ethereum.NotFound

If the local endpoint was present, the function could normalize that entry while preserving other supplied members.

The PoC used two attacker strings.

Deterministic stall input

evil=https://203.0.113.10:2380

This omitted the local node.

The real parser rejected it.

Because etcdJoin treated the packet as the awaited response, the whole join attempt returned before the legitimate response arrived.

Redirect candidate input

evil=https://203.0.113.10:2380,=https://127.0.0.1:50001

This included:

An attacker-controlled member

The expected local endpoint

The parser accepted it and returned a fixed cluster candidate.

The proof deliberately did not start a persistent etcd process with that value.

That kept the test deterministic and bounded.

The directly demonstrated result is therefore:

The wrong peer can terminate the real join

and:

An attacker-influenced redirect candidate can pass the real parser

The article does not claim that the PoC maintained a live malicious etcd cluster.

The complete stalled-join sequence

The proof executed this flow:

1. The target called etcdJoin("legit")

2. EtcdJoin selected legit-id

3. It subscribed to the global EtcdCluster feed

4. It sent admin_requestEtcdAddMember for legit-id

5. The legitimate response was delayed

6. The attacker cluster was emitted first through GotEtcdCluster

7. The global feed delivered that value to the real etcdJoin

8. EtcdFixCluster returned not found

9. EtcdJoin returned before the legitimate response was released

10. The later legitimate response could not complete the finished attempt

The recorded result was:

RPC requested peer ID
legit-id

Malicious cluster emitted first
True

EtcdJoin consumed attacker cluster first
True

EtcdJoin returned before legitimate response
True

Join error
not found

That is deterministic request confusion.

The legitimate response arrived too late

The in-process RPC boundary delayed the legitimate cluster until after the attacker value had already caused etcdJoin to return.

The test then released:

wemixapi.GotEtcdCluster(
    r.legit,
)

The legitimate cluster itself was valid.

The real parser accepted it in the direct control.

But the request had already been completed by the wrong value.

The bug was therefore not:

The legitimate peer returned malformed data

It was:

The consumer accepted an unrelated response first

The protocol already recognized request IDs

The P2P layer contained request-tracking machinery:

func (
    p *Peer,
) RequestEtcdAddMember() error {
    id :=
        rand.Uint64()

    requestTracker.Track(
        p.id,
        p.version,
        EtcdAddMemberMsg,
        EtcdClusterMsg,
        id,
    )

    return p2p.Send(
        p.rw,
        EtcdAddMemberMsg,
        common.Big1,
    )
}

The eth66 response shape also contained:

type EtcdClusterPacket66 struct {
    RequestId uint64
    EtcdClusterPacket
}

The problem was not the complete absence of a correlation concept in the codebase.

The problem was that etcdJoin ultimately consumed only:

chan string

By the time the cluster reached the waiting join, peer and request context were gone.

What the PoC used

The proof used the real:

wemixAdmin.etcdJoin

SubscribeToEtcdCluster

GotEtcdCluster

etcdFixCluster

Node-selection logic

First-response consumption behavior

An in-process RPC boundary was used only to:

Record admin_requestEtcdAddMember

Confirm legit-id was requested

Delay the legitimate response

It did not publish the malicious value.

It did not decide the final error.

The attacker value entered through the same GotEtcdCluster sink used by the real P2P handler after partner validation.

The real etcdJoin consumed it.

The real etcdFixCluster returned ethereum.NotFound.

The command was:

go test ./wemix \
    -run TestEtcd \
    -count=1 \
    -v

The test passed.

The controls isolated the issue

The PoC verified:

Real EtcdJoin used
True

Real EtcdFixCluster used
True

Real global feed used
True

Requested peer
legit-id

Feed contains peer identity
False

Feed contains request ID
False

Join consumed attacker first
True

Join returned before legitimate response
True

Legitimate cluster passes parser
True

Invalid attacker cluster fails parser
True

Attacker redirect candidate passes parser
True

Persistent etcd process started in primary path
False

These controls matter because they separate three questions:

Was the correct peer requested?
Yes

Did the consumer know who answered?
No

Could the attacker value control the result?
Yes

What the proof establishes

The proof demonstrates:

EtcdJoin selected a specific legitimate peer

The RPC request contained legit-id

The response feed had no peer binding

The response feed had no request binding

An unsolicited attacker value arrived first

The real join consumed it

The real join returned before the legitimate response

A malformed attacker value caused deterministic join failure

An attacker-influenced cluster passed the real parser

The proof does not demonstrate:

Direct fund theft

A completed live-network exploit

Total network shutdown

Permanent consensus failure

A persistent attacker-controlled etcd process

Exploitation by a non-partner peer

Those limits are why the report was submitted as Major rather than Critical.

Why this is Major, not Low

The impact is a privileged P2P control-plane failure affecting mining coordination.

The request was completed by the wrong peer

The target requested legit-id.

The consumer accepted an originless value that could have come from another partner.

That is a failure of request-response integrity.

The join failed through the real path

The attacker value was not rejected as unrelated.

It reached etcdFixCluster.

The function returned not found.

The real etcdJoin terminated before the legitimate response.

The attacker could influence the cluster candidate

The redirect control passed the real parser while preserving the attacker-controlled member.

The PoC did not start etcd with that candidate, but it proved the value crossed the validation step that feeds InitialCluster.

The affected path coordinates mining nodes

This was not a UI or monitoring endpoint.

The function joins the etcd cluster used by mining nodes.

A failed or attacker-influenced join can prevent the target from coordinating as intended and can contribute to missed production opportunities.

The attack is privileged but not administrative

A real exploit requires a WEMIX partner peer.

It does not require:

Governance control

Administrator credentials

Validator private keys

Public RPC manipulation

Partner membership should permit protocol participation.

It should not permit one peer to impersonate another peer’s response.

The failure can be raced again

A failed attempt requires another join.

Without correlation, the same class of unsolicited partner packet can race the next attempt as well.

Low does not fit the demonstrated result

Low would fit:

An unsolicited packet ignored before use

A stale status update

A harmless parser discrepancy

A message with no effect on a pending operation

A UI-only failure

This report showed the real mining-coordination join being terminated by the wrong response.

That is Major.

Why the $100 outcome understates the evidence

The final Low classification produced a $100 bounty.

That records the program decision.

It does not change the result:

Requested peer
legit-id

Consumed response
Attacker cluster

Peer identity in feed
None

Request ID in feed
None

Join returned before legitimate response
True

Join result
not found

Attacker-influenced redirect candidate accepted
True

The strongest directly demonstrated impact was a malicious partner controlling the result of another peer’s pending mining-coordination join.

That is a Major control-plane and liveness issue.

Why I describe the WEMIX handling as systematic downgrading

Severity disagreements are normal in bug bounty programs.

My concern is the recurring outcome across my own valid WEMIX submissions.

Reports supported by reproducible proofs and concrete protocol behavior were repeatedly assigned substantially lower final severities.

This report was submitted as Major.

The proof showed the real etcdJoin requesting legit-id, consuming an unsolicited attacker value, and returning before the legitimate response.

It also showed that the consumer received neither peer identity nor request ID and that an attacker-influenced redirect candidate passed etcdFixCluster.

The report was classified as Low.

I cannot infer intent from that decision.

I can document the repeated outcome and compare the final classification with the technical evidence.

Calling it systematic downgrading describes that recurring pattern across my WEMIX submissions without claiming a motive.

A technically convincing Low justification would need to explain why these effects are minor:

One partner satisfying another peer’s pending request

No peer binding

No request-ID binding

The real join consuming the attacker value

The join returning before the legitimate response

Attacker-controlled membership surviving parser validation

Mining coordination for the target being stalled or influenced

Without addressing those facts, the Low classification does not match the proof.

The correct fix

The response consumed by etcdJoin must preserve correlation context.

A structured response can carry:

type EtcdClusterResponse struct {
    PeerID    string
    RequestID uint64
    Cluster   string
}

The pending join should record:

Expected peer ID

Expected request ID

The handler should preserve:

Actual sending peer ID

Received request ID

Cluster string

The waiting join must ignore any response where:

PeerID does not match

or:

RequestID does not match

The existing global string feed may remain for telemetry or legacy observers.

It must not control a correlated join operation.

Safer lifecycle

The corrected flow should be:

1. EtcdJoin selects legit-id

2. The request receives a unique request ID

3. The pending operation stores both values

4. A partner response arrives

5. The handler preserves peer and request identity

6. EtcdJoin rejects unrelated peers

7. EtcdJoin rejects mismatched request IDs

8. Only the matching cluster reaches etcdFixCluster

9. Only the validated matching result becomes InitialCluster

An unsolicited packet can then be logged or penalized without completing the join.

Regression tests

A complete correction should verify:

The expected peer with the correct request ID completes the join
Another partner’s response is ignored
A mismatched request ID is ignored
An unsolicited packet arriving first cannot terminate the operation
An unrelated malformed cluster cannot make etcdJoin return
An attacker-influenced cluster from the wrong peer cannot become InitialCluster
Concurrent joins cannot consume each other’s responses
Timeout behavior remains bounded when no matching response arrives

The central invariant is:

Only a response matching both the intended peer and the pending request may complete an etcd join.

Broader lessons

Partner status is not response correlation

A partner can be authorized to use a privileged protocol without being authorized to answer every pending request.

Global feeds are wrong for correlated responses

Broadcast feeds are useful for notifications.

They are unsafe when exactly one response must complete exactly one request.

First response wins is not authentication

Timing decided which cluster value etcdJoin trusted.

A peer that arrived first controlled the attempt.

Control-plane messages need context

A cluster string is not enough.

The consumer also needs:

Who sent it

Which request it answers

Targeted liveness failures still matter

A vulnerability does not need to stop the entire network to affect blockchain operations.

Disrupting one mining node’s coordination path can still cost production opportunities and degrade liveness for that target.

Conclusion

The target selected:

Peer
legit

Peer ID
legit-id

But it waited on a global feed carrying only:

Cluster string

A malicious partner emitted an unsolicited value first.

The real etcdJoin consumed it.

The feed contained no peer identity.

It contained no request ID.

The join returned not found before the legitimate response arrived.

A separate control proved that an attacker-influenced cluster containing the local endpoint passed etcdFixCluster.

The primary PoC did not start a persistent malicious etcd process.

It proved the underlying defect:

The first accepted partner cluster string could complete a pending join regardless of which peer or request it belonged to.

The program classified the report as Low and paid $100.

The demonstrated impact was Major.

The report did not claim theft, total network shutdown, or permanent consensus failure.

It demonstrated a narrower and directly proven failure:

A malicious partner peer could terminate another node’s mining-coordination join and could supply an attacker-influenced cluster candidate by winning an uncorrelated response race.

A privileged P2P response-confusion bug that controls a mining node’s join attempt is not a Low-severity issue.

How Unsigned Partner Metadata Could Make WEMIX Block Producers Build Invalid Blocks

Daniel — Fri, 07 Aug 2026 00:49:23 +0000

A signed transaction should have exactly one sender.

That sender must come from the signature.

WEMIX introduced a TransactionsEx P2P packet that carried two pieces of data:

A signed transaction

A separate From address

The From field was network metadata.

It was not part of the signed transaction bytes.

It did not change the transaction hash.

Yet when the packet came from a peer classified as a WEMIX partner, the client trusted that metadata and wrote it directly into the transaction sender cache:

if (trustIt) {
    i.Tx.from.Store(
        sigCache{
            signer: signer,
            from: i.From,
        },
    )
}

That created a dangerous contradiction.

The transaction could be signed by the attacker while the cached sender was set to a victim.

Local execution would then treat the victim as the sender.

A fresh decode of the same signed transaction would recover the attacker.

The two executions produced different state roots.

If a block producer includes the poisoned transaction, it can compute a state root that honest nodes reject after recovering the sender from the signature.

I submitted this report as Major through the WEMIX bug bounty program hosted on CertiK Skynet.

The program classified it as Low and paid a $100 bounty.

That classification does not match the demonstrated impact.

The proof did not show a harmless cache inconsistency.

It showed unauthenticated P2P metadata crossing into transaction execution, changing the sender used for gas and nonce accounting, and causing consensus-relevant state divergence.

The full public report and proof of concept are available in the GitHub Gist.

The sender must come from the signature

Ethereum-style transactions are signed objects.

The sender is recovered from the transaction signature under the applicable chain and signer rules:

V

R

S

Signing hash

Chain-specific signer rules

A network peer may relay the transaction.

It must not define who signed it.

The invariant is simple:

A peer supplied field must never replace local cryptographic sender recovery.

WEMIX broke that invariant for partner peers.

The extra From field was not authenticated

The WEMIX transaction extension was:

type TransactionEx struct {
    Tx   *Transaction
    From common.Address `json:"from" rlp:"nil"`
}

The signed transaction lived in:

TransactionEx.Tx

The separate address lived in:

TransactionEx.From

Those values were not cryptographically bound together.

A partner peer could provide:

Transaction signed by attacker

TransactionEx.From set to victim

The transaction bytes remained unchanged.

The transaction hash remained unchanged.

Only the peer-controlled metadata claimed a different sender.

The real wire path preserved the forged metadata

TransactionEx.EncodeRLP serialized the transaction and then serialized the cached sender as the extra From field:

func (tx *TransactionEx) EncodeRLP(
    w io.Writer,
) error {
    if err := tx.Tx.EncodeRLP(w); err != nil {
        return err
    }

    var from common.Address

    if sc := tx.Tx.from.Load(); sc != nil {
        from =
            sc.(sigCache).from
    }

    return rlp.Encode(
        w,
        &from,
    )
}

The receiver decoded the same structure:

func (tx *TransactionEx) DecodeRLP(
    s *rlp.Stream,
) error {
    tx.Tx =
        &Transaction{}

    if err := tx.Tx.DecodeRLP(s); err != nil {
        return err
    }

    return s.Decode(
        &tx.From,
    )
}

The PoC used this real RLP path.

It created a transaction signed by the attacker, set the sender side cache to the victim solely to construct the extended wire metadata, and encoded a TransactionEx packet carrying:

From = victim

After decoding:

Signed transaction bytes
Unchanged

Transaction hash
Unchanged

Decoded TransactionEx.From
Victim

The metadata survived the wire path without becoming part of the signature.

Partner status activated the dangerous path

The P2P handler converted extended packets through:

txs :=
    types.TxExs2Txs(
        signer,
        txexs,
        wemixminer.IsPartner(
            peer.ID(),
        ),
    )

The third argument was the trust decision:

trustIt = wemixminer.IsPartner(peer.ID())

The report does not claim exploitation by any arbitrary internet peer.

The attacker model requires a peer that WEMIX treats as a partner.

That is a meaningful precondition.

It does not make the vulnerability Low.

Partner status can justify permission to connect or relay specialized packets.

It cannot safely grant permission to redefine the cryptographic sender of a signed transaction.

The sender cache accepted the victim without verification

The vulnerable converter was:

func TxExs2Txs(
    signer Signer,
    txs []*TransactionEx,
    trustIt bool,
) []*Transaction {
    var out []*Transaction

    for _, i := range txs {
        if trustIt {
            i.Tx.from.Store(
                sigCache{
                    signer: signer,
                    from: i.From,
                },
            )
        }

        out =
            append(
                out,
                i.Tx,
            )
    }

    return out
}

When trustIt was true, the implementation did not call:

signer.Sender(i.Tx)

It did not compare:

Recovered cryptographic sender

Peer-supplied From

It simply stored the peer value as authoritative sender state.

That poisoned:

Transaction.from

The cache bypassed signature recovery

The normal sender helper first checked the cache:

func Sender(
    signer Signer,
    tx *Transaction,
) (
    common.Address,
    error,
) {
    if sc := tx.from.Load(); sc != nil {
        sigCache :=
            sc.(sigCache)

        if sigCache.signer.Equal(
            signer,
        ) {
            return sigCache.from, nil
        }
    }

    addr, err :=
        signer.Sender(
            tx,
        )

    if err != nil {
        return common.Address{}, err
    }

    tx.from.Store(
        sigCache{
            signer: signer,
            from: addr,
        },
    )

    return addr, nil
}

If the cached signer matched, types.Sender returned the cached address immediately.

There was no new signature recovery.

The PoC isolated this behavior with two controls:

trustIt = false
Sender recovered as attacker

trustIt = true
Sender returned as victim

A fresh decode of the same signed transaction bytes returned:

Attacker

The only difference was the poisoned local cache.

The poisoned value could propagate into txpool sender resolution

The sender resolver checked whether the transaction already carried a cached sender:

if addr :=
    types.GetSender(
        signer,
        tx,
    );
    addr != nil {
    s.tx2addr.Put(
        hash,
        *addr,
    )

    continue
}

Once TransactionsEx had placed the victim into Transaction.from, this path could persist that address by transaction hash.

The transaction hash did not change, so the same signed transaction could remain locally associated with a sender who never signed it.

The PoC did not need to execute the complete TxPool.ResolveSenders pipeline. This section describes the downstream propagation visible in the production code. The execution divergence itself was directly demonstrated through core.ApplyTransaction.

The poisoned sender reached real execution

The PoC did not stop at demonstrating a bad helper return.

It reached:

core.ApplyTransaction

The execution path converted the transaction into a message:

msg, err :=
    tx.AsMessage(
        types.MakeSigner(
            config,
            header.Number,
        ),
        header.BaseFee,
    )

That conversion used sender recovery.

For the poisoned transaction, the cache returned the victim.

The state transition then used:

st.msg.From()

for balance and gas handling:

if have, want :=
    st.state.GetBalance(
        st.msg.From(),
    ),
    balanceCheck;
    have.Cmp(want) < 0 {
    return fmt.Errorf(
        "%w: address %v have %v want %v",
        ErrInsufficientFunds,
        st.msg.From().Hex(),
        have,
        want,
    )
}

st.state.SubBalance(
    st.msg.From(),
    mgval,
)

The peer-controlled metadata had reached the real transaction execution layer.

The same transaction executed as two different senders

The proof executed the exact same signed transaction bytes twice.

Poisoned partner execution

Cryptographic signer
Attacker

Cached sender
Victim

Gas charged to
Victim

Nonce incremented for
Victim

Fresh honest execution

Cryptographic signer
Attacker

Recovered sender
Attacker

Gas charged to
Attacker

Nonce incremented for
Attacker

Both executions were accepted locally.

They did not produce the same state.

The concrete PoC result

The transaction used:

Transaction type
DynamicFeeTx

Gas limit
21,000

Effective gas price
2 wei

Transaction value
0

The direct debit was:

21,000 × 2 wei
=
42,000 wei

In the poisoned execution:

Victim gas debit
42,000 wei

Victim nonce after execution
1

Attacker gas debit
0

Attacker nonce after execution
0

In the fresh execution:

Attacker gas debit
42,000 wei

Attacker nonce after execution
1

Victim gas debit
0

Victim nonce after execution
0

The PoC did not present that local victim debit as network accepted theft.

The important result was execution divergence.

The state roots were different

The poisoned execution produced:

0xda61d18fc59fe2eb48c73ebcd38d2540279eeae8317436a36eda976115dccdbe

The fresh execution produced:

0xbe165c07292fb6d76231ecad028675c208201bd18c4ddabdd7a94ce6b385ed9e

The roots differed because the sender-dependent state changes affected different accounts.

A target block producer using the poisoned cache could build a block using the first state root.

Honest nodes receiving the block transaction would not receive that producer’s in-memory sender cache.

They would decode the signed transaction, recover the attacker, compute the second state transition, and reject the block because the expected root did not match.

The complete attack sequence

The demonstrated and directly implied sequence was:

1. A malicious partner peer creates a valid transaction signed by the attacker

2. The peer supplies TransactionEx.From as a victim

3. The signed transaction bytes and hash remain unchanged

4. handleTransactionsEx treats the peer as a partner

5. TxExs2Txs runs with trustIt set to true

6. The victim is stored in Transaction.from without signature recovery

7. types.Sender returns the victim

8. ApplyTransaction executes the transaction locally with the victim as sender

9. Gas and nonce are applied to the victim state

10. A fresh decode of the same transaction recovers the attacker

11. Fresh execution applies gas and nonce to the attacker state

12. The two executions produce different state roots

13. A producer that commits the poisoned root builds a block honest nodes reject

The PoC directly proved steps one through twelve with the real execution path. Step thirteen is the consensus consequence of committing a state root that honest nodes cannot reproduce from the canonical transaction bytes.

What the proof actually used

The Go proof used:

Real types.TransactionEx

Real TransactionEx RLP encoding

Real TransactionEx RLP decoding

Real types.TxExs2Txs

Real types.Sender

Real types.GetSender

Real DynamicFeeTx signature

Real core.ApplyTransaction

Real StateTransition.buyGas

The same transaction bytes in both executions

The vulnerable logic was not reimplemented in a mock.

A small ChainContext boundary stub was used because ApplyTransaction requires that interface.

The bug did not depend on the stub.

The proof did not require:

Mainnet

Testnet

Public RPC

Governance

Administrator keys

External services

It did require the partner-peer trust condition.

The test command was:

go test ./core \
    -run TestTxEx \
    -count=1 \
    -v

The test passed.

The controls made the root cause unambiguous

A strong consensus PoC needs controls.

This one included several.

Fresh sender control

A fresh decode of the signed transaction recovered:

Attacker

That proved the signature was valid and belonged to the attacker.

Untrusted conversion control

With:

trustIt = false

the receiver recovered:

Attacker

The metadata did not poison the sender.

Trusted conversion control

With:

trustIt = true

the receiver returned:

Victim

That isolated the vulnerable trust branch.

Same-bytes control

The poisoned and fresh executions used the same transaction bytes.

The From metadata did not change the signed transaction or its hash.

State-transition control

Both executions reached the real ApplyTransaction path.

One charged the victim.

The other charged the attacker.

The state roots differed.

What the report does not claim

The report does not claim:

Direct theft accepted by honest nodes

A permanent chain split

A total network shutdown

Permanent transaction confirmation failure

Exploitation by any arbitrary peer

A completed live-network attack

Honest nodes reject the poisoned block.

That rejection prevents the local false sender state from becoming canonical.

It does not make the issue harmless.

The attacker can still target block producers and make them waste proposer opportunities by constructing blocks that the rest of the network rejects.

Why this is Major, not Low

The report was submitted under the impact category:

Blockchain transient consensus failure

Block producer denial of service

The PoC demonstrated both sides of that classification.

It crosses a consensus critical trust boundary

A P2P peer influenced the sender used in transaction execution.

Sender identity is not optional metadata.

It determines:

Nonce

Gas payment

Balance checks

State transition

Final state root

It causes real execution divergence

The same signed transaction bytes produced two accepted local executions with different senders.

This is not a logging or display problem.

It changes consensus-relevant state.

It creates the exact divergence required for invalid block production

The poisoned execution computes one root.

Fresh canonical decoding computes another.

The PoC did not assemble and gossip a full block. It proved the consensus critical prerequisite through the real state transition path: honest nodes cannot reproduce the poisoned root from the signed transaction bytes.

A producer that includes the poisoned transaction and commits that root constructs an invalid block.

It can waste a block production opportunity

A targeted producer can spend its opportunity executing, assembling, and broadcasting a block that honest nodes reject.

That is a block producer denial of service impact, even though honest rejection prevents the poisoned state from becoming canonical.

The attack requires a partner peer, not an administrator

The report has a meaningful privilege precondition.

The sender must be recognized by WEMIX as a partner peer.

But the attack does not require:

Governance control

Administrator keys

Validator private keys

Public RPC manipulation

Partner status is a network privilege, not authority to override the sender authenticated by a transaction signature.

Low does not fit the demonstrated effect

Low would fit:

An incorrect cached value with no execution impact

A display-only sender mismatch

A packet rejected before state transition

A harmless performance optimization bug

A divergence that cannot reach block construction

This report reached real transaction execution and produced different state roots.

That is Major.

Why the $100 outcome understates the evidence

The final Low classification produced a $100 bounty.

That records the program decision.

It does not change the proof:

Transaction signer
Attacker

Partner metadata
Victim

Transaction bytes
Unchanged

Transaction hash
Unchanged

Sender with trust false
Attacker

Sender with trust true
Victim

Poisoned victim debit
42,000 wei

Fresh attacker debit
42,000 wei

State roots
Different

Block producer consequence
Invalid block if the poisoned root is committed

The strongest demonstrated impact was state-root divergence enabling targeted invalid block production through unauthenticated partner metadata.

That is not a Low severity cache bug.

It is a Major consensus and block production issue.

Why I describe the WEMIX handling as systematic downgrading

Severity disagreements are normal in bug bounty programs.

My concern is the recurring outcome across my own valid WEMIX submissions.

Reports backed by reproducible proofs and concrete protocol behavior were repeatedly assigned substantially lower final severities.

This report was submitted as Major.

The proof showed a partner peer making the target execute an attacker-signed transaction as though it came from a victim, producing the exact state-root divergence required for invalid block production.

It was classified as Low.

I cannot infer intent from that decision.

I can document the repeated outcome and compare the final classification with the technical evidence.

Calling it systematic downgrading describes that recurring pattern across my WEMIX submissions without claiming a motive.

A technically convincing Low justification would need to explain why these effects are minor:

Peer metadata replacing cryptographic sender recovery

The victim receiving the local gas and nonce effects

The attacker receiving those effects after fresh decoding

The same transaction bytes producing different roots

A block producer building a block honest nodes reject

A partner peer being able to trigger the poisoned trust path

Without addressing those facts, the Low classification does not match the proof.

The correct fix

The safest correction is to stop treating TransactionEx.From as authoritative.

The receiver must recover the sender locally from the signed transaction.

A compatibility-preserving patch can keep the field as advisory metadata:

func TxExs2Txs(
    signer Signer,
    txs []*TransactionEx,
    trustIt bool,
) []*Transaction {
    var out []*Transaction

    for _, i := range txs {
        if i == nil || i.Tx == nil {
            out =
                append(
                    out,
                    nil,
                )

            continue
        }

        if trustIt {
            from, err :=
                signer.Sender(
                    i.Tx,
                )

            if err == nil &&
                from == i.From {
                i.Tx.from.Store(
                    sigCache{
                        signer: signer,
                        from: from,
                    },
                )
            }
        }

        out =
            append(
                out,
                i.Tx,
            )
    }

    return out
}

The essential rule is:

Recover first

Compare second

Cache only after a match

A mismatched TransactionEx.From can then be:

Ignored

Rejected

Recorded as peer misbehavior

Used for P2P penalties

It must never become transaction authority.

Why the fix closes the bug

The exploit requires this transition:

Peer-supplied victim
→
Transaction.from cache
→
types.Sender
→
ApplyTransaction

The patch breaks the chain at the first step.

For a transaction signed by the attacker and carrying:

From = victim

local recovery returns:

Attacker

The values do not match.

The victim is not stored in the sender cache.

Fresh execution and partner-packet execution therefore resolve the same sender and produce the same state transition.

The packet format does not need to change.

The block format does not need to change.

Only the trust decision changes.

Regression tests

A complete correction should verify:

Matching TransactionEx.From may populate the cache only after local cryptographic recovery
Mismatched metadata never becomes Transaction.from
trustIt = false and trustIt = true resolve the same sender for a mismatched packet
Partner conversion and fresh decoding produce the same gas payer, nonce changes, and state root
The txpool resolver never persists unverified peer metadata
Nil or malformed extended transactions are handled safely
A metadata mismatch may trigger the configured peer response without affecting transaction execution

The central invariant is:

Every sender used by txpool, block production, and state transition must be derived locally from the signed transaction.

Broader lessons

Trusted peers still provide untrusted data

A partner may be allowed to use specialized network messages.

Every consensus-relevant field must still be verified.

Caches can become security boundaries

A sender cache looks like a performance optimization.

Once downstream code treats it as authoritative, poisoning that cache changes execution.

Transaction hashes do not cover external metadata

The transaction hash remained the same because TransactionEx.From was outside the signed payload.

That made the mismatch easy to hide behind an otherwise valid transaction.

Honest rejection is still an impact

The network rejecting the invalid block prevents canonical corruption.

The targeted producer still loses its block.

Consensus safety and producer availability are related but distinct properties.

Local and fresh decoding must be equivalent

A transaction received through a special packet must execute identically to the same transaction decoded from canonical block bytes.

Any difference is a consensus warning.

Conclusion

The transaction was signed by the attacker.

The partner packet claimed the sender was a victim.

The claimed address was not signed.

It did not change the transaction bytes.

It did not change the transaction hash.

With:

trustIt = false

WEMIX recovered the attacker.

With:

trustIt = true

WEMIX returned the victim from the sender cache.

The poisoned execution charged gas and nonce to the victim.

A fresh execution of the same bytes charged gas and nonce to the attacker.

The state roots differed.

A target producer that committed the poisoned root could therefore build a block that honest nodes reject.

The program classified the report as Low and paid $100.

The demonstrated impact was Major.

The report did not claim network accepted theft, permanent chain split, or arbitrary-peer exploitation.

It demonstrated a narrower and directly proven failure:

A malicious partner peer could replace cryptographic sender recovery with unauthenticated metadata, creating state-root divergence that makes a producer’s block invalid.

A peer-controlled cache entry that changes the state root is not a Low severity issue.