DEV Community: Daniel

VOLOSC 194: How an Accepted Direct Theft Primitive Ended as a USD 500 Medium

Daniel — Fri, 28 Aug 2026 15:50:45 +0000

A technical account of a direct theft primitive, 151 days of review, and the incentive problem behind responsible disclosure in Web3

On 27 March 2026, at 00:05, I submitted VOLOSC 194 to the Volo Smart Contracts bug bounty program through HackenProof. The report was titled Curator valuation updater can overwrite the principal slot and reopen direct NAV manipulation, and I submitted it as Critical because the issue did not stop at an incorrect number inside the vault. The proof of concept showed a complete accounting path in which an ordinary caller could redirect a legitimately approved curator value into the vault principal slot, inflate NAV, inflate the share ratio, and ultimately cause the normal withdrawal logic to pay substantially more real principal for the same number of shares.

The numbers in the proof were deliberately simple. In the honest control path, 100000000000 shares returned 100000000000 units of principal. In the exploit path, the same 100000000000 shares returned 1100000000000. The vault ended with free_principal = 0. That was the reason I did not view the issue as a theoretical accounting discrepancy. The corrupted value was consumed by a real withdrawal calculation and reached a real balance split.

The first review response recognized essentially the same root cause and consequence. The vulnerable code was later fixed, and months afterward the final HackenProof triage comment described the report as an accepted direct theft primitive. Even so, after 150 days, 23 hours, and 40 minutes of review, the report ended as Medium.

What makes this case interesting is not simply that I disagreed with the final severity. The technical facts changed as the review progressed. HackenProof eventually produced an onchain chronology showing that the vulnerable package had been fixed shortly before the first curator position was created. I also had to correct one of my own later conclusions about version 10. By the end, the disagreement was no longer about whether the code defect existed. It had become a much narrower question about how severity should be measured when vulnerable code is already deployed, but responsible disclosure allows the team to fix it before the final legitimate state required for exploitation becomes active.

That is the question I want to document here, together with the complete technical path and the evidence that led both sides to their final positions.

To keep the article readable, I am reproducing only four screenshots from the larger evidence archive. The technical and chronological details below still reflect the complete record I reviewed, but the images are limited to the points that are most useful for a reader following the dispute from beginning to end.

The case in one table

Item	Recorded result
Report	`VOLOSC 194`
Target	Volo Smart Contracts
Platform	HackenProof
Category	Business Logic Errors
Submitted	27 March 2026 at 00:05
Submitted severity	Critical
Final severity	Medium
Payment	Paid
Time to first review response	1 day, 9 hours, and 34 minutes
Time from submission to Medium decision	150 days, 23 hours, and 40 minutes

Before going into the code, there is one communication detail worth clarifying. The screenshots preserve two different channels. At several points, an account identified by the HackenProof interface as company admin responded directly inside the report, mainly on technical and operational questions. At other points, especially around goodwill, severity, payout, escalation, and the final decision, the messages came from HackenProof triage. I keep those roles separate throughout the article because attributing every statement to the same party would make the chronology less accurate.

Where the vulnerability lived

The flaw was inside update_curator_position_value. The function existed to take a curator position value that had already gone through the intended curator process and update the value stored by the vault. The dangerous part was not the existence of the curator value itself. The dangerous part was that the function accepted an asset_type string from the caller and never proved that this string represented the curator position being updated.

That detail matters because the principal coin type already exists as an accounting slot when the vault is created. The report highlighted the initialization that registers the principal asset inside the vault:

vault.set_new_asset_type(
    type_name::get<PrincipalCoinType>().into_string()
);

The curator position is also paired with a vault before it later becomes a supported vault asset. The relevant creation path stores that relationship and initializes the value record:

self.curator_position_to_vault.add(
    id_address,
    vault_id
);

self.curator_position_values.add(
    id_address,
    CuratorPositionValue {
        position_value: 0,
        position_value_updated: 0,
        position_value_valid_time: 0,
        valid: false,
    },
);

This distinction became important in the proof of concept. The curator position could already be paired with the vault while the curator asset was still not a normal supported vault asset. The attack therefore did not require adding the curator position as a supported asset first and then corrupting its own value. The state confusion happened through the destination selected by the public updater.

The value used by the exploit also did not need to be fabricated. A curator could submit a legitimate value through the intended privileged path:

self.assert_valid_curator_cap(
    curator_position_id,
    curator_cap.id
);

self.update_position_value(
    curator_position_id,
    position_value,
    now,
    valid_time
)

An operator could then validate that value normally:

if (approved) {
    curator_position_value.valid = true;
}

The attacker comes after those legitimate steps. That distinction is one of the reasons I considered the bug serious: the exploit did not require compromising the curator, forging an approval, or obtaining one of the privileged capability objects. It reused a valid approved value and abused where the public function allowed that value to be written.

The vulnerable updater looked like this in the relevant path:

public fun update_curator_position_value<PrincipalCoinType>(
    self: &mut CuratorConfig,
    vault: &mut Vault<PrincipalCoinType>,
    asset_type: String,
    curator_position_id: address,
    oracle_config: &OracleConfig,
    clock: &Clock,
) {
    let now = clock.timestamp_ms();

    assert!(
        self.curator_position_to_vault[curator_position_id]
            == vault.vault_id(),
        ERR_CURATOR_POSITION_NOT_PAIRED_WITH_VAULT
    );

    self.assert_valid_curator_position_value(
        curator_position_id,
        now
    );

    let principal_based_position_value =
        self.position_value(curator_position_id);

    let principal_price =
        vault_oracle::get_normalized_asset_price(
            oracle_config,
            clock,
            type_name::with_defining_ids<PrincipalCoinType>()
                .into_string(),
        );

    let position_value =
        vault_utils::mul_with_oracle_price(
            principal_based_position_value,
            principal_price,
        );

    vault.finish_update_asset_value(
        asset_type,
        position_value,
        now
    );
}

The function correctly checked that the curator position belonged to the supplied vault, but that check protected a different invariant from the one I reported. It prevented a curator position paired to one vault from simply being used against another vault. It did not prove that the caller supplied asset_type represented the curator position inside the correct vault.

That is why I described the root cause as same vault slot confusion rather than cross vault access. The caller could be operating on the correct vault and still select the wrong registered accounting slot.

The destination string then flowed directly into the generic storage write:

public(package) fun finish_update_asset_value<PrincipalCoinType>(
    self: &mut Vault<PrincipalCoinType>,
    asset_type: String,
    usd_value: u256,
    now: u64,
) {
    let last_update_time =
        &mut self.assets_value_updated[asset_type];

    *last_update_time = now;

    let position_value =
        &mut self.assets_value[asset_type];

    *position_value = usd_value;
}

Once execution reached this function with the principal asset type, the stored principal valuation was replaced. The real principal balance did not increase with it, so the vault accounting could now claim a principal value that was much larger than the actual backing.

There was another detail in the codebase that made the missing check particularly notable. A separate coin asset updater already prevented the principal coin type from going through the generic asset valuation path:

assert!(
    type_name::get<CoinType>()
        != type_name::get<PrincipalCoinType>(),
    ERR_INVALID_COIN_ASSET_TYPE,
);

In other words, the codebase already recognized that the principal slot should not be treated like an ordinary generic asset slot. The curator updater reopened a path to that same storage without enforcing the equivalent identity constraint.

How an accounting overwrite became a withdrawal of real principal

The next question was whether corrupting the stored principal value actually mattered financially. In this case, the value did not remain isolated. The vault aggregated stored asset values through get_total_usd_value:

self.asset_types.do_ref!(|asset_type| {
    let usd_value =
        *self.assets_value.borrow(*asset_type);

    total_usd_value =
        total_usd_value + usd_value;
});

That total then fed into get_share_ratio:

let total_usd_value =
    self.get_total_usd_value(clock);

let share_ratio =
    vault_utils::div_d(
        total_usd_value,
        self.total_shares
    );

The withdrawal path consumed the resulting ratio to calculate the amount of principal associated with the shares being withdrawn:

let ratio =
    self.get_share_ratio(clock);

let usd_value_to_withdraw =
    vault_utils::mul_d(
        shares_to_withdraw,
        ratio
    );

let amount_to_withdraw =
    vault_utils::div_with_oracle_price(
        usd_value_to_withdraw,
        vault_oracle::get_normalized_asset_price(
            config,
            clock,
            type_name::get<PrincipalCoinType>()
                .into_string(),
        ),
    ) as u64;

assert!(
    amount_to_withdraw
        <= self.free_principal.value(),
    ERR_NO_FREE_PRINCIPAL
);

let mut withdraw_balance =
    self.free_principal.split(
        amount_to_withdraw
    );

That created a direct chain from the public corruption primitive to a real balance movement. The approved curator value could be written into the principal accounting slot, the forged value could inflate total NAV, the inflated NAV could increase the share ratio, and the withdrawal calculation could then split more actual principal from free_principal than the same shares should receive.

The proof of concept made that difference visible by running an honest control and the exploit from equivalent state:

Metric	Honest control	Exploit path
Free principal before withdrawal	`1100000000000`	`1100000000000`
Principal slot before overwrite	`1100000000000`	`1100000000000`
Principal slot before withdrawal	`1100000000000`	`12100000000000`
Share ratio before withdrawal	`1000000000`	`11000000000`
Shares withdrawn	`100000000000`	`100000000000`
Principal payout	`100000000000`	`1100000000000`
Free principal after exploit	Residual backing remains	`0`

The same number of shares therefore received eleven times more principal in the exploit path. The Move test completed successfully with one test passed and zero failures. The curator value had been legitimately approved, the corruption step was performed by an ordinary caller, and the financial consequence appeared when the normal withdrawal path trusted the manipulated share ratio.

That is the technical basis on which I submitted the report as Critical.

From technical validation to a dispute over prior knowledge

The report received its first review response on 28 March at 09:39, 1 day, 9 hours, and 34 minutes after submission. The account visible in the report recognized the core issue and described essentially the same sequence: arbitrary asset type selection, generic asset value storage, principal slot overwrite, inflated total USD value, inflated share ratio, and drainage of free_principal through a normal withdrawal. It also referenced the honest and exploit payout difference from the proof of concept.

At that point, the main technical primitive was understood. The first major dispute appeared on 6 April at 16:30, when a participant identified by the interface as company admin responded directly. The message said the report was a valid issue but claimed that a similar problem had already been received from an audit firm. A screenshot was attached showing another reviewer questioning the same public function and the ability to associate a curator position value with another asset type.

The screenshot was technically relevant, but it did not visibly establish the chronology required for a duplicate determination. It did not show the audit firm name, a report date, a finding identifier, an affected version range, or other metadata that would prove the material predated my 27 March submission. I therefore asked for objective prior discovery evidence rather than treating the screenshot alone as conclusive.

At the same time, I separated the duplicate question from another issue that would eventually become far more important: production reachability. If the report was not going to be treated as a proven duplicate, what exact production condition prevented the demonstrated path from being reachable when I submitted it?

That question changed the direction of the review.

The argument moved to production reachability

On 16 April at 00:29, the company admin account responded again. The protocol side argued that the attack was not feasible because creating the curator capability required an administrator, because a curator position could only affect the vault to which it was paired, and because an operator remained involved in the withdrawal process.

I disagreed with the way those points were being applied to the reported root cause. The same vault pairing assertion did not prevent the caller from choosing the wrong slot inside that same vault, which was the actual issue. I also did not see the privileged curator and operator steps as equivalent to an attacker needing those privileges. The curator could approve a legitimate value, and the operator could execute the protocol's normal withdrawal flow. The malicious state corruption itself still happened through a public updater that did not require AdminCap, OperatorCap, or CuratorCap.

On 18 April at 02:26, HackenProof triage made an important clarification. It said the available audit material was not sufficient by itself to conclusively prove prior discovery of the same root cause and exploit path before my submission, so the review would not rely on duplicate classification on that evidence alone. The report was described as a meaningful code level issue, but production reachability remained the central concern. HackenProof triage also communicated that the protocol team wanted to provide a goodwill payment while the severity dispute remained unresolved.

I did not consider that goodwill payment a resolution of the severity question. I asked instead for the concrete onchain state that prevented the exploit path from being reachable during the vulnerable deployment window.

A separate security incident, and why I did not attribute it to this bug

On 21 April, while the report was still under discussion, Volo publicly disclosed a separate security incident involving approximately USD 3.5 million in WBTC, XAUm, and USDC removed from Volo Vaults. The protocol said the affected vaults were frozen and that it was prepared to absorb the loss. A later update said approximately half a million dollars associated with the incident had been frozen, and NAVI Protocol also announced a precautionary pause while reviewing the situation.

I added those public statements to the report because the discussion at the time was still focused on whether the reported issue could be practically relevant in production. I did not claim that the April incident used VOLOSC 194, and I do not make that claim now. The later onchain chronology established that the principal overwrite path from my report had already been closed on 3 April, before the first curator position existed. Without transaction level evidence connecting the April incident to the same root cause, attributing it to this finding would go beyond the evidence.

The evidence that finally narrowed the dispute

After my 21 April update, the report became quiet. I followed up again on 5 May at 12:15. The next substantive technical response visible in the evidence did not arrive until 12 August at 17:43, which was another 99 days, 5 hours, and 28 minutes later. Measured from my 18 April request for concrete production state evidence, the detailed answer took 116 days, 9 hours, and 23 minutes.

That August response was important because it finally supplied the onchain history needed to answer the reachability question. The vulnerable package was identified as:

0x7a663d394fa9ea6bac32a860957014ec951730f79f3fa1ec73d261463f13b1b1

It had been deployed on 2 March 2026 at 07:24 UTC. My report was submitted on 27 March at 00:05 in the interface timezone, which means the vulnerable package had already been live for 24 days, 19 hours, and 41 minutes before submission after timezone normalization.

The corrected package was:

0x8d9b38f82fcfc70a869eac1f7cefa871e9f22360aab94224f6bf751c1b9d7a2b

It was deployed on 3 April at 04:18:06 UTC. The first curator position was then created at 05:25:56 UTC, the first curator value was submitted at 07:09:12 UTC, and the first approved curator value appeared at 07:11:31 UTC.

UTC time	Event	Why it matters
3 April 2026 04:18:06	Corrected package deployed	The reported caller selected principal overwrite path was closed
3 April 2026 05:25:56	First curator position created	The first curator position required by the path appears
3 April 2026 05:55:02	Curator cap added	Additional curator configuration occurs
3 April 2026 06:49:55	Curator position added as DeFi asset	The position becomes a supported vault asset
3 April 2026 07:09:12	First curator value submitted	A value enters the intended curator flow
3 April 2026 07:11:31	First curator value approved	The approved value used by the proof of concept now exists

The corrected package therefore preceded the first curator position by 1 hour, 7 minutes, and 50 seconds. It preceded the first approved curator value by 2 hours, 53 minutes, and 25 seconds.

This is the strongest fact supporting HackenProof's eventual downgrade. The vulnerable package and the legitimate curator state required by the proof of concept did not coexist on mainnet. Before a curator position was registered, the required curator_position_to_vault lookup could not satisfy the attack path.

I accept that chronology.

The same August review also corrected something I had previously gotten wrong. During my own follow up investigation on 3 April and 4 April, I concluded that version 10 still preserved the original vulnerability. That conclusion was incorrect. The later source and bytecode analysis showed that the new validation was an equality allowlist that bound asset_type to the curator asset type:

let curator_asset_type =
    vault_utils::parse_key<CuratorPosition>(0);

assert!(
    self.curator_position_to_vault[curator_position_id]
        == vault.vault_id(),
    ERR_CURATOR_POSITION_NOT_PAIRED_WITH_VAULT
);

assert!(
    asset_type == curator_asset_type,
    ERR_INVALID_CURATOR_ASSET_TYPE
);

Passing the principal coin type used by the original proof of concept now aborts with ERR_INVALID_CURATOR_ASSET_TYPE, value 8013, before the write can occur. The later bytecode comparison also showed that version 10 and the subsequent package contained the same corrected curator module.

I accepted that correction as well. It means the approximately USD 25.7 million in publicly displayed vault TVL that I mapped during my interim analysis cannot be presented as capital that remained exposed to this specific path after version 10. That was an error in my follow up analysis, and a complete public account should say so plainly.

By this point, most of the factual disagreement had disappeared. The earlier deployed code contained the defect. Version 10 fixed it. The fix arrived before the first curator position. Had the curator feature been active under the vulnerable package, the demonstrated path would have been reachable. The question left was how those facts should translate into severity.

From Informational to an independent escalation

On 13 August at 02:22, HackenProof triage communicated that the report would remain Informational. The reasoning was that the required curator state did not exist before the corrected package was deployed, so the reported path had not been reachable against live funds during the relevant production window. The payment being discussed at that stage was described as discretionary recognition for the usefulness and quality of the report rather than as a normal severity based bounty.

That sequence mattered to me because the payment had been presented as goodwill while the report itself was considered Informational. I opened a HackenProof support ticket and asked for an independent review. My question was not simply whether the payment could be increased. I wanted to understand the rule being applied. Specifically, I asked what published criterion applicable on 27 March made a valid vulnerability in deployed, in scope code Informational because a legitimate prerequisite protocol state had not yet been instantiated before the vulnerability was fixed.

The support discussion continued through August. I repeatedly separated the payment question from the severity question because the central issue was not whether the bounty amount was a nice gesture. It was whether the report qualified for a normal bounty tier and, if so, how the demonstrated impact should be classified.

On 24 August at 23:45, HackenProof triage said the matter had been reviewed with the project team and that the report would be reclassified as Medium. The previously discussed payment would be retained and processed. From the original submission to that message, 150 days, 23 hours, and 40 minutes had passed.

I appreciated that the Informational classification had been withdrawn, but the technical question was still open. I asked why the final tier was Medium rather than High or Critical.

The final technical basis for Medium

On 26 August at 08:39, HackenProof finally gave the most precise explanation of the severity decision. The response said the program considered three dimensions together: caller privilege for the corruption step, reachability at the time of submission, and the structure of the monetization path.

On caller privilege, HackenProof agreed with an important part of the original report. update_curator_position_value could be reached without AdminCap, OperatorCap, or CuratorCap, which meant the state corruption itself was unprivileged. The response explicitly said this was what placed the report in a bounty tier at all.

The decisive issue was reachability. HackenProof relied on the August chronology and noted that the vulnerable code and an activated curator position with an approved value never coexisted in production. In its explanation, Critical was calibrated to a demonstrated path against live funds at the time of submission, while High required a reachable path with material fund loss. Because the curator state required by the proof of concept did not exist during the vulnerable deployment window, HackenProof treated that gap as preventing promotion into either tier.

The third factor was monetization structure. HackenProof also argued that even in a reachable state, the transfer from corrupted NAV to the attacker did not complete in one entirely unprivileged call. execute_withdraw was operator gated, and the response also referenced the MAX_UPDATE_INTERVAL = 0 freshness condition. In their view, that was a separate structural constraint that further prevented the finding from clearing High.

This was the first time the final Medium classification had been explained with that level of specificity, and it allowed the remaining disagreement to be stated much more precisely.

I asked where those requirements were written

After receiving that explanation, I reviewed the publicly available Volo Smart Contracts rules and HackenProof's public Smart Contract Vulnerability Classification. I could find broad impact categories covering direct financial loss, unauthorized fund access, unauthorized extraction capable of draining protocol treasury or user deposits, direct theft, and protocol insolvency. I could also find a general statement that privileged actions may justify a downgrade.

What I could not find was an express rule saying that Critical required the complete exploit path to be reachable against live funds at the exact moment of submission, or that High or Critical required a fully unprivileged single caller monetization primitive. I therefore asked HackenProof to identify the specific publicly applicable rule containing those requirements, or to clarify whether they were part of the platform's internal severity methodology.

HackenProof responded at 10:30 on 26 August. The answer did not point to a separate rule containing the exact wording I had requested. Instead, it explained that this was standard smart contract triage practice and not a novel or retrospective methodology. According to the response, severity is tied to demonstrated impact, and impact is evaluated against what the exploit chain can actually accomplish against protocol state at the time of submission rather than against a state that had not yet been instantiated.

The most important sentence in that response was that the reachability gap was dispositive for tier calibration. That clarified the hierarchy of the final reasoning. Operator gated settlement remained a secondary constraint, but even without relying on it, HackenProof considered the production reachability gap enough to prevent High or Critical.

The determination was described as having been made at senior review level. HackenProof also acknowledged that reasonable disagreement was possible about how much weight should be placed on the reachability gap compared with the code level validity of the primitive. That is where the private severity dispute effectively ended.

The phrase that defined the final outcome

At 10:32, HackenProof triage added a final report comment after further review with the project team. That comment confirmed the core root cause in direct terms: the caller supplied asset_type was not bound to the passed curator_position_id, so an approved curator value could be written into another registered assets_value slot, including the vault principal slot. It also confirmed that the version 10 remediation directly closed the reported path and matched the type of fix proposed in the report.

The comment confirmed Medium severity and described the finding as an accepted direct theft primitive whose classification remained constrained by the production reachability gap.

For me, that phrase captures the entire case. By the end of the review, the disagreement was not whether the primitive could produce direct theft under the demonstrated state. It was whether the absence of that legitimate state during the vulnerable production window should prevent the demonstrated impact from controlling the severity.

The bounty was paid

The USD 500 bounty was subsequently paid, and the report moved to a final Medium and Paid state.

There is one economic comparison that deserves to be put into perspective. During my investigation, I had mapped more than USD 25 million in TVL across the vaults I was analyzing. The later review established that the vulnerable package was fixed before the curator state required by the proof of concept became active, so I am not presenting that TVL as capital proven to have been immediately exploitable through VOLOSC 194. The important point is that responsible disclosure prevented the vulnerable implementation and the intended curator state from ever coexisting in production.

Against a reference base of USD 25 million in TVL, the USD 500 bounty I received represents roughly 0.002%. Even if the report had been classified as Critical and the program had paid its advertised maximum bounty of USD 150,000, that maximum would still represent only about 0.6% of USD 25 million.

The contrast is difficult to ignore. A researcher can spend weeks understanding a protocol, finding a vulnerability, building an executable proof of concept, demonstrating a path to real financial loss, documenting the root cause, and giving the team enough time to remediate the issue before users are exposed, while the economic reward for choosing responsible disclosure remains tiny compared with the scale of capital the protocol manages.

Unfortunately, this is still the incentive structure researchers frequently face in Web3. The ecosystem asks researchers to choose responsible disclosure over exploitation, yet the financial reward for protecting protocol capital can be negligible compared with both the capital under management and the potential upside available to an attacker. If the goal is to make researchers report vulnerabilities early, before every prerequisite is live and before users lose funds, then responsible disclosure has to make sense economically as well as ethically.

The chronology in context

A compact timeline makes the progression easier to see without replacing the narrative above.

Date	What happened
2 March 2026	The vulnerable package was deployed
27 March 2026	`VOLOSC 194` was submitted as Critical
28 March 2026	The first review response recognized the root cause and withdrawal consequence
3 April 2026 at 04:18:06 UTC	The corrected package was deployed
3 April 2026 at 05:25:56 UTC	The first curator position was created
3 April 2026 at 07:11:31 UTC	The first curator value was approved
6 April 2026	The protocol side said the issue was valid but already known
18 April 2026	HackenProof stopped relying on the available audit screenshot alone as conclusive duplicate evidence and communicated a goodwill proposal
21 April 2026	Volo disclosed a separate security incident, which I documented without attributing it to this finding
5 May 2026	I followed up after the report became quiet
12 August 2026	The detailed technical and onchain review arrived and corrected my version 10 analysis
13 August 2026	Informational plus a goodwill payment was communicated as the position at that stage
24 August 2026	The report was reclassified to Medium while retaining the previously discussed payment
26 August 2026 at 08:39	HackenProof provided the detailed privilege, reachability, and monetization rationale
26 August 2026 at 10:30	The senior review response said the reachability gap was dispositive for severity calibration
26 August 2026 at 10:32	The final report comment confirmed Medium, the root cause, the fix, and the accepted direct theft primitive characterization
Final state	The bounty was paid

Where I agree with the final review

There is no value in pretending the later evidence did not change the case. It did. Version 10 closed the reported principal overwrite path. The corrected package was already live before the first curator position existed, and the first approved curator value appeared only after the fix. My earlier version 10 conclusion was wrong, and the TVL I mapped during that interim analysis cannot be used as evidence that the same path remained exploitable after the correction. The final withdrawal was also operator mediated, which is a real structural characteristic of the monetization path.

I also accept that HackenProof did ultimately arbitrate the dispute rather than simply leaving the protocol's initial position untouched. The case was reopened, Informational became Medium, a senior review was performed, and a detailed technical rationale was finally provided. Any fair account of the process has to acknowledge those facts.

At the same time, those concessions do not erase the original primitive. The vulnerable implementation was deployed before my report. The caller controlled asset type confusion was real. The principal slot could be selected as the destination for an approved curator value. The proof of concept demonstrated the resulting NAV inflation, share ratio inflation, and withdrawal of real free_principal once the legitimate curator state existed. The protocol changed the exact write target, regression coverage was added, and the final HackenProof comment itself described the finding as an accepted direct theft primitive.

That is the factual foundation of my remaining disagreement.

Why I still consider VOLOSC 194 Critical

The strongest argument against Critical is no longer ambiguous: the legitimate curator state required by the proof of concept did not exist while the vulnerable package was live. HackenProof considers that reachability gap decisive. I understand the reasoning, but I do not reach the same severity conclusion.

The vulnerable implementation was already deployed, and the missing state was not an invented configuration unrelated to the protocol. It was the intended curator functionality that the system was about to use. The first curator position appeared only 1 hour, 7 minutes, and 50 seconds after the fixed package went live, and the first approved curator value appeared less than three hours after the fix. Had remediation not landed first, the same public corruption primitive demonstrated in the proof of concept would have become reachable as soon as that intended state appeared.

When reachable, the consequence was direct principal loss. The bug did not merely cause a stale display value or a temporary mismatch that could not affect funds. The manipulated principal slot entered total NAV, the inflated NAV changed the share ratio, and the withdrawal path used that ratio to split real principal from the vault. The final HackenProof comment's own description, accepted direct theft primitive, is consistent with the impact I demonstrated.

This is where my methodology differs from HackenProof's final methodology. I assess the severity of the deployed vulnerable primitive from the demonstrated consequence under the intended protocol state that was about to become active. HackenProof calibrated the tier against the exact production state that existed while the vulnerable package remained deployed. Under that interpretation, successful remediation before curator activation is precisely what prevents the direct theft consequence from reaching High or Critical.

Under mine, the same sequence demonstrates that responsible disclosure worked before the vulnerable code and the intended state could coexist.

That is why my own assessment remains Critical.

The part that matters beyond this one bounty

Beyond the severity label itself, this case raises a broader question about incentives. Bug bounty programs exist because researchers sometimes discover vulnerabilities before attackers exploit them. At that moment, the researcher may already understand how the issue could be monetized. The program asks the researcher to choose disclosure instead: build the proof, document the root cause, avoid harming users, provide the details privately, and give the protocol time to fix the problem.

That model works only when early disclosure is rewarded rather than inadvertently penalized. VOLOSC 194 sits in an uncomfortable edge case because the disclosure happened while the vulnerable implementation was already deployed but before the final legitimate curator state existed. The protocol then fixed the root cause, and only afterward did the first curator position and approved value appear.

From a defensive security perspective, that is close to the ideal outcome. The vulnerability was found early enough that the dangerous combination of vulnerable code and active curator state never existed on mainnet. No user needed to lose funds through this path for the code to be fixed.

The incentive problem appears if that success is also what lowers the severity. Had a researcher intentionally waited for the curator state to be activated before reporting, the same vulnerable implementation would have had a stronger contemporaneous reachability argument. Reporting earlier made the protocol safer. Waiting would have made the severity case stronger.

I do not believe a researcher should wait, and I am not advocating exploitation. Draining a protocol is harmful, unlawful, and incompatible with responsible security research. The point is exactly the opposite: the bounty model should make the safe behavior economically rational as well as ethically correct. Researchers should never have to wonder whether disclosing before the last legitimate prerequisite becomes active will make the vulnerability they prevented worth less than it would have been if they had waited.

That is the incentive inversion I think Web3 bounty programs need to take seriously.

What I think a platform should provide

The final stage of the review also changed how I would describe HackenProof's role. It would be inaccurate to say the platform never arbitrated the dispute. The report was reopened, the Informational classification was changed to Medium, a senior review was performed, and HackenProof eventually provided a detailed explanation of the methodology used.

My remaining concern is predictability rather than the absence of review. If production reachability at the exact moment of submission can be dispositive even when the missing state is an intended feature activated immediately after remediation, that principle has a major effect on how researchers should understand severity. The same is true if operator mediated settlement materially caps a finding even when the operator is executing the protocol's normal flow after an unprivileged corruption.

Those may be familiar considerations inside professional smart contract triage, but the more decisive they are for classification and payout, the more useful it is for researchers to understand them before disclosure. The platform sits between a protocol that wants vulnerabilities fixed while controlling cost and a researcher who gives up the information advantage as soon as the report is submitted. Clear, predictable severity treatment is part of what makes that intermediary relationship valuable.

In my view, the strongest bounty programs are not simply the ones with large maximum rewards. They are the ones where a researcher can reasonably predict how the demonstrated exploit, required privileges, production state, and settlement path will be translated into severity before spending weeks or months defending the report.

Would I report the vulnerability again?

Yes. Exploitation is not an alternative, and users should not become collateral damage in a disagreement about bounty economics. But the ecosystem should not take that answer for granted from every researcher forever.

From a security perspective, the report achieved the outcome responsible disclosure is supposed to achieve. A reproducible proof was delivered, the root cause was understood, the vulnerable write target was fixed, regression coverage was added, and the intended curator state became active only after remediation. The vulnerable code never got the opportunity to coexist with the final prerequisite needed by the proof of concept.

The unresolved question is how a bounty system should value that outcome.

Final thoughts

After almost five months, VOLOSC 194 ended in a much more precise place than where it began. The report was not dismissed as invalid, the available prior audit screenshot was not enough on its own to conclusively establish a duplicate, the version 10 fix was verified, and I corrected my own mistaken follow up analysis. The production reachability gap was established onchain, the Informational classification was withdrawn, and a senior review ultimately concluded Medium. The final report comment confirmed the root cause, confirmed that the remediation closed the reported path, and described the vulnerability as an accepted direct theft primitive.

I respect the fact that HackenProof eventually provided a detailed technical rationale and explicitly acknowledged that reasonable disagreement was possible over the weight assigned to the reachability gap. I still disagree with the severity. To me, a deployed public corruption primitive capable of redirecting a legitimately approved curator value into principal accounting, inflating NAV and the share ratio, and producing direct principal loss under the intended curator state is Critical in technical impact. HackenProof reached a different conclusion because the required curator state was not instantiated until after the vulnerable package had been fixed, making that reachability gap decisive under its impact based methodology.

That is the final disagreement, and it matters because it touches the core incentive behind responsible disclosure. The safest outcome is not for a researcher to wait until every prerequisite is live and capital is immediately exposed. It is to report one step earlier, while the protocol still has time to remove the dangerous primitive before the final state becomes active.

If early disclosure achieves exactly that, the reward system should not leave researchers wondering whether waiting would have produced a better economic outcome. Web3 security depends on researchers choosing disclosure over exploitation, and the ecosystem should make that choice obvious by rewarding the people who find vulnerabilities, prove their impact, report them early, and give protocols the opportunity to protect users before an attacker arrives.

CVE-2026-40021: How Invalid XML Properties Could Silently Drop Log Events in Apache Log4net

Daniel — Mon, 17 Aug 2026 23:11:56 +0000

While researching the Apache Log4j Bug Bounty Program on YesWeHack, I came across an issue in Apache Log4net that initially looked like a fairly ordinary XML serialization problem. The vulnerable code was located in XmlLayoutSchemaLog4J, a layout responsible for formatting logging events as XML.

What made the issue interesting was not simply that malformed data could cause XML serialization to fail. The more important behavior appeared when I followed the failure through the rest of the logging pipeline. If a forbidden XML character reached a structured logging property, the XML writer could throw an exception. Log4net would catch that exception internally and allow the application to continue running, but the logging event that triggered the failure would never be written.

The result was a subtle loss of audit information. Data influenced by an attacker could potentially cause the log entry associated with that data to disappear from the XML output. Instead of producing malformed XML or crashing the application, the logging system could silently lose the individual event that was supposed to record what happened.

The issue was eventually assigned CVE 2026 40021 and remained classified as Medium throughout the disclosure process.

Where the problem started

The vulnerable code was inside XmlLayoutSchemaLog4J.FormatXml(), where Log4net processes the properties associated with a LoggingEvent.

When properties were present, the layout iterated over the property dictionary and created an XML element for each entry.

PropertiesDictionary properties = loggingEvent.GetProperties();

if (properties.Count > 0)
{
  writer.WriteStartElement("log4j:properties", "log4j", "properties", "log4net");

  foreach (KeyValuePair<string, object?> entry in properties)
  {
    writer.WriteStartElement("log4j:data", "log4j", "data", "log4net");
    writer.WriteAttributeString("name", entry.Key);

    string? valueStr =
      loggingEvent.Repository?.RendererMap.FindAndRender(entry.Value);

    if (!string.IsNullOrEmpty(valueStr))
    {
      writer.WriteAttributeString("value", valueStr);
    }

    writer.WriteEndElement();
  }

  writer.WriteEndElement();
}

The important part of this code is the way the property name and rendered property value are passed directly to the XML writer.

writer.WriteAttributeString("name", entry.Key);
writer.WriteAttributeString("value", valueStr);

Neither value passed through Log4net's invalid character masking logic before reaching WriteAttributeString().

This distinction is important because XML escaping and XML validity are two different problems. Characters such as <, > and & can be represented safely in XML through escaping. Some control characters cannot.

A character such as U+0001, for example, is forbidden by XML 1.0. It is not a matter of changing it into an entity or escaping it differently. The character itself cannot legally appear in the XML document.

When XML character validation is enabled, attempting to write such a character can cause the XML writer to throw an exception. Because the property serialization path passed the data directly to that writer, a forbidden character inside a property could reach exactly that condition.

The protection was already present elsewhere

One of the reasons the behavior stood out was that Log4net already had a mechanism designed specifically to deal with invalid XML characters.

The layout hierarchy exposes the following property:

public string InvalidCharReplacement { get; set; } = "?";

The purpose of this setting is to replace characters that cannot be represented safely in XML with another character. By default, the replacement is ?.

This meant the application already had an expected way of handling this type of input. Rather than failing to serialize the entire event, Log4net could replace the unsupported character and continue producing valid XML.

That behavior was already used in other parts of the XML layout. The rendered log message, for instance, passed through a transformation helper before being written.

Transform.WriteEscapedXmlString(
  writer,
  loggingEvent.RenderedMessage,
  InvalidCharReplacement
);

The property path behaved differently. Property names and rendered values were written directly into XML attributes without equivalent invalid character handling.

That made the root cause relatively small. Log4net did not lack the necessary protection. One serialization path simply bypassed a protection that the rest of the layout already understood how to use.

The consequence of that small inconsistency, however, only became clear after following the exception beyond the serializer.

What happens after XML serialization fails

The next part of the investigation was understanding how Log4net behaves when an appender encounters an exception.

Appender execution is protected by exception handling around the code that ultimately writes the logging event.

try
{
  _recursiveGuard = true;

  if (FilterEvent(loggingEvent) && PreAppendCheck())
  {
    Append(loggingEvent);
  }
}
catch (Exception ex) when (!ex.IsFatal())
{
  ErrorHandler.Error("Failed in DoAppend", ex);
}
finally
{
  _recursiveGuard = false;
}

This behavior makes sense from a reliability perspective. Logging infrastructure generally should not bring down the application simply because one event could not be formatted correctly.

If XmlLayoutSchemaLog4J throws during formatting, the exception is caught by the appender pipeline. The application can therefore continue running normally.

The problem is that catching the exception does not recover the logging event.

Once serialization has failed, that event has not been successfully written. The exception is handled, execution continues, and the original record is absent from the XML output.

This was the point where the issue stopped looking like a simple formatting bug.

The application remained available. The log file itself did not necessarily become corrupted. There was no requirement for a malicious downstream XML parser. Instead, the individual event containing the problematic data simply disappeared.

If the event represented a request, an authentication attempt, a suspicious action or another security relevant operation, the logging system could lose exactly the record that investigators would later expect to find.

Reproducing the behavior

I reproduced the issue with a minimal Log4net configuration using a FileAppender together with XmlLayoutSchemaLog4J.

The property used for the test contained the forbidden XML 1.0 character U+0001.

data.Properties["user"] = "A\u0001B";

The event was then passed through the normal Log4net logging path.

var evt = new LoggingEvent(null, repo, data);
log.Logger.Log(evt);

Under the expected behavior, Log4net should have recognized the invalid character and replaced it using InvalidCharReplacement.

Since the default replacement value is ?, the property could have been represented in the XML output as something similar to:

A?B

The logging event would still exist, the XML would remain valid, and the surrounding audit trail would remain intact.

Instead, the raw value reached the XML attribute writer. Serialization failed when the forbidden character was processed, and the exception propagated into the appender error handling path.

The application continued running, but the corresponding event was not present in the expected logging output.

This detail was important for establishing the security impact. The proof did not depend on editing an existing log file, corrupting previously written entries or exploiting another system after the XML had been generated.

The record was lost before successful log emission.

Why this can matter in real applications

Modern applications frequently enrich logging events with structured properties. These properties can contain usernames, request identifiers, authentication information, correlation values, request metadata, client supplied fields and other contextual information that helps explain what was happening when the event was generated.

Some of that information can ultimately originate from an external user.

If attacker influenced data reaches a property that is later serialized through XmlLayoutSchemaLog4J, a forbidden XML character can cause the serialization of that event to fail.

The impact is therefore best understood as a loss of audit trail integrity.

This vulnerability does not allow an attacker to modify arbitrary application data. It does not provide arbitrary file access, and it does not allow previously written log entries to be rewritten.

The demonstrated behavior is narrower.

An individual event containing the triggering data can be prevented from reaching the XML logging output.

That becomes relevant when the missing event is itself important from a security perspective. A malicious request might generate exactly the information that an administrator, security analyst or incident responder would later use to understand what happened.

If that record disappears while the rest of the application continues functioning normally, the resulting gap can be difficult to notice.

This is also why logging failures deserve more attention than they sometimes receive. A logging system is not merely an output mechanism. In many environments it is part of the evidence collection process used for monitoring, detection, investigations and incident response.

Severity, disclosure and CVE assignment

I initially submitted the vulnerability as Medium with a CVSS 3.1 score of 5.3.

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

During triage, the impact model was adjusted. The scope was considered changed because the security consequence affected the logging environment rather than directly affecting the system where the original input was processed.

Integrity impact was classified as Low, while availability impact was removed.

The resulting YesWeHack vector became:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N

This resulted in a final CVSS 3.1 score of 5.8, keeping the vulnerability within the Medium severity range.

The vulnerability was later assigned CVE 2026 40021.

Apache's final advisory described a broader affected surface that included both XmlLayout and XmlLayoutSchemaLog4J. The advisory covers MDC property keys, property values and the identity field, and confirms that versions before 3.3.0 are affected.

Apache Log4net 3.3.0 contains the fix, and the Apache advisory credits the discovery to f00dat.

The report also received a €600 bounty through YesWeHack.

How the issue can be fixed

The underlying remediation follows the protection that Log4net already used elsewhere in its XML serialization logic.

Before property names or rendered values are passed to the XML writer, characters that are invalid under XML 1.0 should be replaced according to the configured InvalidCharReplacement value.

Instead of passing the property name directly:

writer.WriteAttributeString("name", entry.Key);

the value can first be processed with the existing transformation logic:

writer.WriteAttributeString(
  "name",
  Transform.MaskXmlInvalidCharacters(
    entry.Key,
    InvalidCharReplacement
  )
);

Rendered property values require the same treatment.

writer.WriteAttributeString(
  "value",
  Transform.MaskXmlInvalidCharacters(
    valueStr,
    InvalidCharReplacement
  )
);

With this behavior, an unsupported character no longer causes the entire event to fail serialization. The invalid character is replaced, the XML remains valid, and the logging record can still be preserved.

A regression test can verify the fix by creating a logging event that contains a forbidden XML character in one of its properties and passing that event through XmlLayoutSchemaLog4J.

The important assertion is not only that the generated XML is valid. The test should also confirm that the logging event itself remains present and that the unsupported character has been replaced according to the configured behavior.

The part of the bug that mattered most

What I found most interesting about this vulnerability was how easy it would have been to stop the analysis too early.

Looking only at the vulnerable lines, the issue appears to be a small XML validation inconsistency. A property contains a character that XML 1.0 does not allow, the serializer rejects it, and the immediate conclusion could simply be that the output cannot be generated correctly.

Following the execution path further changes the picture.

The serializer throws an exception. The appender catches it. The application keeps running. The logging event disappears.

That sequence is what gives the bug its security relevance.

The important failure was not that Log4net could produce invalid XML. In fact, the XML writer prevented exactly that from happening.

The important failure was that the system responded to an invalid value by losing the complete event instead of replacing the unsupported character and preserving the record.

Security research often comes down to following these small inconsistencies far enough to understand what they actually mean in the context of the complete system.

In this case, a few property serialization calls were enough to affect the reliability of the audit trail.

That behavior ultimately became CVE 2026 40021.

How Scalelite Playback Broke Tenant Isolation in BigBlueButton Multitenancy

Daniel — Mon, 17 Aug 2026 22:47:36 +0000

While researching the BigBlueButton bug bounty program on YesWeHack, I found an access control issue in Scalelite’s recording playback flow.

The problem appeared when multitenancy was enabled.

Scalelite already derived tenant context from the request hostname for BigBlueButton API requests and scoped recording queries to that tenant. The playback controller did not follow the same model. It resolved recordings using only record_id and playback format.

As a result, a recording assigned to Tenant A could also be requested through Tenant B’s hostname if the same record_id was known.

I submitted the finding as High, with CVSS 3.1 score 7.5. Triage later classified it as Medium, with CVSS score 5.3. The report received a €250 bounty.

The intended tenant boundary

When Scalelite multitenancy is enabled through MULTITENANCY_ENABLED=true, tenant identity is derived from the request hostname.

The helper responsible for that behavior was:

def fetch_tenant_name_from_url
  request.host.split(".").first
end

def fetch_tenant(name: nil)
  return nil unless Rails.configuration.x.multitenancy_enabled

  tenant_name = name.presence || fetch_tenant_name_from_url
  tenant = Tenant.find_by_name(tenant_name)
  raise ChecksumError if tenant.blank?

  tenant
end

For example, these hostnames represent different tenant contexts:

tenantA.sl.example.com
tenantB.sl.example.com

The project documentation also states that each tenant should have access only to its own meetings and recordings.

The BigBlueButton API controller followed this model. When multitenancy was enabled, it resolved the current tenant and used that context when querying recordings.

The recording query included a metadata filter matching tenant-id to the current tenant:

query = Recording
        .includes(playback_formats: [:thumbnails], metadata: [])
        .left_joins(:metadata)
        .distinct

query = query.where(
  metadata: {
    key: "tenant-id",
    value: @tenant.id
  }
) if @tenant.present?

So the tenant boundary already existed for recording discovery through the API.

Playback used a global lookup

The vulnerable behavior was inside PlaybackController.

Both playback actions resolved a recording using its identifier and playback format:

@playback_format = PlaybackFormat
                   .joins(:recording)
                   .find_by!(
                     format: params[:playback_format],
                     recordings: {
                       record_id: params[:record_id]
                     }
                   )

@recording = @playback_format.recording

There was no tenant lookup from the hostname.

There was no before_action :set_tenant.

There was no condition requiring the recording metadata to contain a tenant-id matching the current request.

The query therefore answered only whether a recording with the requested identifier and format existed.

It did not verify whether that recording belonged to the tenant represented by the hostname.

Reproducing the issue

I reproduced the problem with an RSpec request test while multitenancy was enabled.

The test created a published recording and explicitly associated it with Tenant A:

create(
  :metadatum,
  recording: recording,
  key: "tenant-id",
  value: "tenantA-id"
)

A presentation playback resource was then created for the same recording:

create(
  :playback_format,
  recording: recording,
  format: "presentation",
  url: "/presentation/#{recording.record_id}/index.html"
)

The first request used Tenant A’s hostname and returned HTTP 200 as expected.

The second request used Tenant B’s hostname while keeping the same path and record_id.

That request also returned HTTP 200.

Both responses exposed the same X-Accel-Redirect target for the recording resource.

The recording ownership never changed. Only the request hostname changed.

The test completed successfully:

Finished in 0.19804 seconds
2 examples, 0 failures

This demonstrated that playback authorization depended on possession of the record_id, not on tenant ownership.

Why this matters

The affected playback routes can serve recording pages and their associated resources.

Depending on the generated recording format and meeting content, those resources may include presentation material, media, captions, notes, chat content, participant related information, and other recording assets.

The attacker still needs to know or obtain the victim recording’s record_id.

The vulnerability is not that every identifier is automatically discoverable. The issue is that once an identifier is known, the playback path does not enforce the tenant boundary that multitenancy is supposed to provide.

Protected recordings also have their own token and cookie mechanism. That mechanism is separate from tenant ownership and does not replace tenant isolation.

Why this is an access control flaw

The key difference is between object existence and object ownership.

The vulnerable lookup effectively used:

record_id + format

Under multitenancy, the authorization decision needed to include the current tenant:

tenant + record_id + format

The API side already enforced that distinction through tenant-id metadata.

Playback did not.

That is why the issue fits CWE 284, Improper Access Control. It also matches the authorization bypass pattern described by CWE 639, where a user controlled object identifier can reach data outside the caller’s authorization boundary.

Severity

I originally submitted the issue with this CVSS 3.1 vector:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

That produced a base score of 7.5.

During triage, the confidentiality impact was reduced from High to Low, resulting in:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

The final score was 5.3, and the finding was classified as Medium.

The public writeup preserves both values because the first reflects the submitted assessment and the second reflects the final program classification.

Remediation

The playback path should enforce the same tenant ownership rule already used by the recording API.

When multitenancy is enabled, PlaybackController should resolve the tenant from the request hostname and scope the recording lookup to metadata where tenant-id matches that tenant.

The expected behavior should be:

Tenant A requesting Tenant A recording = HTTP 200
Tenant B requesting Tenant A recording = HTTP 404

The cross tenant response should not receive an X-Accel-Redirect for the recording resource.

Legacy recordings without tenant metadata also need an explicit policy. The safer behavior under multitenancy is to deny access until ownership has been established or migrated.

A regression test should keep this boundary covered by creating a recording for one tenant and confirming that the same identifier cannot be served through another tenant hostname.

The broader lesson

Multitenancy failures often appear when different application surfaces reach the same object through different lookup paths.

In this case, the recordings API understood tenant ownership.

Playback reached the same underlying data without carrying that context forward.

That inconsistency was enough to break the isolation model.

The useful question when reviewing a multitenant application is:

Does every path that can return this object enforce the same tenant boundary?

For Scalelite recording playback, the answer was no.

The recording belonged to one tenant in metadata, but playback resolved it globally by record_id and format.

That was enough to allow cross tenant access to recording playback resources.

How TipRun’s Liquidation Path Could Force Healthy Accounts Into Arbitrary Terms

Daniel — Mon, 17 Aug 2026 15:42:49 +0000

During the TipRun audit on HackenProof, I found a flaw in the perpetual trading liquidation flow that was easy to misread as a signature issue.

TYPE_LIQUIDATE contained a signed LimitOrder, but that signature belonged to the liquidator. The account being liquidated did not sign the forced terms, which can be completely valid in a liquidation design.

The actual security requirement was different.

If the victim does not consent, the contracts must prove that the account is eligible for liquidation and that the forced terms stay inside an economically safe range.

TipRun did not enforce those conditions before resizing the target account.

I originally submitted the finding as High. HackenProof later validated it as Critical.

The signature protected only one side

The liquidation payload was:

struct Liquidate {
    LimitOrder liquidatorOrder;
    uint64 liquidatedUid;
    int256 actualCollateral;
    int256 actualSynthetic;
    uint256 actualLiquidatorFee;
}

The only signed object is liquidatorOrder.

That signature can authenticate the liquidator side of the transaction. It does not establish that liquidatedUid is below maintenance, that the target has an exposure that should be reduced, or that the forced collateral amount is consistent with the oracle price.

Those properties require separate on chain checks.

Without them, a valid liquidator signature does not make the forced transition safe for the account being affected.

The liquidation request had no eligibility gate

PerpPlugin decoded TYPE_LIQUIDATE and forwarded it to LiquidateTransLib:

if (txType == TYPE_LIQUIDATE) {
    Liquidate memory liquidate = abi.decode(payload, (Liquidate));
    CollateralAssetInfo memory collateralInfo = generalConfig.getCollateralAssetInfo();

    liquidate.process(
        position,
        funding,
        generalConfig,
        order,
        signer,
        collateralInfo.assetId,
        generalConfig.getFeeAccountId(),
        transactionProcessor
    );

    emit LiquidateProcessed(liquidate);
    return true;
}

There was no check at this point to determine whether the target account was actually liquidatable.

Inside the library, the victim deltas were derived directly from the submitted values:

int256 liquidatedCollateralDelta = 0;
int256 liquidatedSyntheticDelta = 0;

if (liquidate.liquidatorOrder.isBuyingSynthetic) {
    liquidatedCollateralDelta = liquidate.actualCollateral;
    liquidatedSyntheticDelta = -liquidate.actualSynthetic;
} else {
    liquidatedCollateralDelta = -liquidate.actualCollateral;
    liquidatedSyntheticDelta = liquidate.actualSynthetic;
}

Those deltas were then applied to the target account:

position.updatePosition(
    liquidatedPosition,
    liquidatedUid,
    liquidatedCollateralDelta,
    syntheticAssetId,
    liquidatedSyntheticDelta
);

The path checked basic conditions such as a nonzero target account, collateral asset identity, and whether the synthetic asset was tradable.

The missing checks were the ones that defined whether a forced liquidation was legitimate.

There was no explicit requirement that the original account was below maintenance, no requirement that an existing exposure was being reduced, and no oracle bound on actualCollateral.

Why the generic margin check did not solve it

TipRun already performed generic risk validation around position transitions, so I checked whether that logic indirectly enforced liquidation eligibility.

It did not.

The relevant risk path returned when the updated position was healthy:

(int256 updatedTotalValue, int256 updatedTotalRisk) =
    getAccountPositionStatusWithBoundaryCheck(fullUpdated);

if (updatedTotalRisk <= updatedTotalValue * FXP_32_ONE) {
    return;
}

That check asks whether the resulting state satisfies a generic margin condition.

Liquidation eligibility asks a different question: was the original account below maintenance before the forced transition?

A healthy final state cannot answer that.

This distinction allowed the liquidation path to accept a forced change against an account that should never have entered liquidation in the first place.

Reproducing the issue through real protocol paths

I built the proof through the real TYPE_TRADE, TYPE_LIQUIDATE, and TYPE_WITHDRAWAL flows.

The victim deposited 1000 collateral and opened a small short through signed orderbook trades.

Immediately before liquidation, the account state was:

Collateral: 1001
Synthetic: -1
Normalized value: 1000
Normalized risk: 1

The account was far above maintenance.

The liquidator then signed its own order, and the authorized batch path submitted a liquidation with:

Synthetic amount: 1
Submitted collateral: 100
Oracle fair collateral: 1

The oracle fair value for one synthetic unit was 1, while the submitted liquidation used 100.

The transaction succeeded.

After the forced transition, the victim had:

Collateral: 901
Synthetic: 0

The liquidator had:

Collateral: 100
Synthetic: -1

Relative to oracle fair value, the victim lost 99 units of normalized value and the liquidator gained 99.

This was the central impact demonstrated by the proof.

A healthy account was forced through liquidation using economic terms that were not bounded by the oracle.

Proving that the value was realizable

I also tested whether the liquidator could externalize the resulting collateral without relying on another vulnerability.

After liquidation, the protocol reported 98 collateral as safely removable from the liquidator account.

The liquidator submitted a valid signed TYPE_WITHDRAWAL for exactly 98.

The withdrawal succeeded, 98 ERC20 units reached the external recipient, and the LoadingZone system balance decreased by the same amount.

The liquidator remained at maintenance afterward:

Collateral: 2
Synthetic: -1
Normalized value: 1
Normalized risk: 1

This demonstrated realizable economic impact while keeping the withdrawal inside the protocol’s normal margin rules.

Liquidation could create exposure instead of reducing it

The missing eligibility logic was not limited to the first scenario.

I also tested a healthy account with collateral and no synthetic exposure:

Collateral: 1000
Synthetic: 0

TYPE_LIQUIDATE still executed.

The resulting state was:

Collateral: 900
Synthetic: 1

Instead of reducing an existing risky position, the liquidation path created a new synthetic exposure.

That behavior showed why a forced liquidation mechanism needs an explicit exposure reduction rule.

Control cases

The proof included controls around the neighboring security boundaries.

A zero liquidatedUid reverted.

A collateral asset mismatch reverted.

A nontradable synthetic asset reverted.

A mutated liquidator order reverted.

A direct caller outside the authorized batch path reverted.

A withdrawal beyond the safely removable amount reverted.

I also tested a genuinely undercollateralized account after a large oracle price movement. A bounded liquidation still succeeded.

That final control was important because the intended fix should preserve valid liquidation while rejecting forced transitions against accounts that are not eligible.

Separate from the earlier deleverage finding

I had previously reported a different vulnerability in TYPE_DELEVERAGE, so I isolated this proof from that issue.

This test never executed TYPE_DELEVERAGE.

It did not depend on the deleverage nonce problem or on deleverage replay.

The affected transaction here was TYPE_LIQUIDATE, the main affected library was LiquidateTransLib, and the liquidator order was validly signed.

The failure was the absence of protections for the third party account receiving the forced state change.

Test results

The full Foundry suite completed successfully:

12 passed
0 failed
0 skipped

The tests covered the healthy account path, oracle price bounds, realizable withdrawal, zero exposure behavior, valid liquidation, guard conditions, arithmetic, and isolation from the deleverage flow.

The proof used local execution through real protocol components. It did not depend on RPC access, governance action, direct mutation of vulnerable state, or external oracle manipulation.

Why the final classification was Critical

I submitted the report as High, while HackenProof ultimately accepted it as Critical.

The final impact went beyond a missing precondition.

The liquidation mechanism could apply unfavorable forced terms to a healthy account, move collateral to the opposite side, and produce value that could be withdrawn through a legitimate protocol path.

It could also create exposure in an account that had no position to liquidate.

That made the issue a realizable collateral loss path inside an authorized protocol operation.

The contest economics

The financial outcome was very different from the technical severity.

The issue was independently reported by 31 researchers, so the Critical reward was shared across the valid submissions.

My payout for this report was $4.84.

The submission fee was $5.

Across the TipRun contest, my total loss was $18.

This individual Critical report therefore did not recover its own submission fee. It is a useful example of how duplicate density and reward sharing can make contest economics very different from technical impact.

How I would fix it

The liquidation flow should remain forced. Requiring the victim to sign would undermine the purpose of liquidation.

Instead, the protocol should validate the forced action before changing the target account.

At minimum, the contracts should require:

The target account is below maintenance before liquidation.
The target has an existing exposure in the direction being reduced.
The liquidation cannot cross the position through zero and create opposite exposure.
actualCollateral stays within an oracle derived range that includes only the configured liquidation penalty.

These conditions should be checked before position.updatePosition() applies the target deltas.

The existing liquidator signature can continue to authenticate the liquidator order. The missing protection is the on chain validation for the account that does not sign.

The broader lesson

Forced protocol actions require explicit invariants.

When user consent is intentionally absent, the contract has to define exactly when the action is allowed and how far it can go.

A valid signature from one side does not authorize arbitrary consequences for another account.

The useful security question is therefore not only:

Who signed this operation?

It is also:

What on chain rule proves that forcing these terms onto the affected account is legitimate?

In TipRun’s liquidation path, that second guarantee was missing.

That gap was enough to turn a liquidation mechanism intended for risk management into a path capable of forcing economically unfair state transitions onto healthy accounts.

How TipRun’s Unsigned Deleverage Path Allowed Arbitrary Collateral Transfers

Daniel — Mon, 17 Aug 2026 15:06:01 +0000

During the TipRun audit on HackenProof, I found a flaw in the perpetual trading deleverage flow that initially looked like a missing authorization check.

The TYPE_DELEVERAGE payload did not contain a user signature.

That observation alone was not enough to prove a vulnerability. A deleverage mechanism can legitimately be forced if it exists to reduce protocol risk. In that design, requiring the affected user to approve every operation could defeat the purpose of the mechanism.

The real issue was that TipRun did not replace user consent with objective safety rules enforced by the contracts.

The deleverage path accepted concrete economic terms without a signature or nonce, did not require the affected account to be unsafe, did not constrain the collateral amount to the oracle price, and did not prevent the same payload from being processed again.

That combination allowed a healthy account to lose collateral through the authorized batch execution path.

I reported the issue during the audit. HackenProof later validated it as Critical.

The protocol model

TipRun processes protocol operations through a sequencer and batch execution architecture.

Normal user actions rely on signed data. The contracts verify the relevant authorization before applying changes to user accounts.

The deleverage transaction followed a different pattern.

struct Deleverage {
    address deleveragableAddress;
    uint64 deleveragableAccountId;
    address deleveragerSigner;
    uint64 deleveragerAccountId;
    uint64 syntheticAssetId;
    int256 amountSynthetic;
    int256 amountCollateral;
    int256 deleveragerIsBuyingSynthetic;
}

The struct contains account identifiers, signer addresses, an asset identifier, two amounts, and a direction.

It does not contain a signature, nonce, deadline, or signed hash that binds those terms to either user.

That can still be valid if deleverage is intentionally forced. The problem begins when the contract also fails to define the limits of what may be forced.

Signer registration was treated as sufficient authorization

Inside DeleverageTransLib, the protocol checked whether the supplied addresses were registered signers for the two accounts.

require(
    signerManager.checkSigner(deleveragable, self.deleveragableAddress),
    "DeleverageTransLib: deleveragable signer unauthorized"
);

require(
    signerManager.checkSigner(deleverager, self.deleveragerSigner),
    "DeleverageTransLib: deleverager signer unauthorized"
);

The underlying check was simple:

function checkSigner(uint64 accountId, address signer) public view returns (bool) {
    uint256 permissions = signerPermissions[accountId][signer];
    return permissions != 0;
}

This proves that an address has permissions for an account.

It does not prove that the address approved the current deleverage terms.

That distinction matters because the transaction supplied all economically relevant values directly. The account identifiers, synthetic asset, synthetic amount, collateral amount, and direction were never cryptographically bound to user approved data.

The protocol therefore knew that the addresses were registered, but it did not know whether those addresses had authorized the operation being executed.

Why forced deleverage still needed stronger checks

If TYPE_DELEVERAGE is meant to be voluntary, the missing signatures and nonces are already enough to make the authorization model incomplete.

But I wanted to test the stronger interpretation: assume deleverage is intentionally forced.

Under that model, the contracts should enforce the conditions that make a forced operation legitimate.

The affected account should actually require intervention.

The direction should reduce existing exposure.

The operation should not push a position through zero into the opposite side.

The amount of collateral exchanged should remain within a valid range relative to the oracle price and any configured penalty.

The same instruction should not be executable twice.

The implementation did not enforce those properties.

That changed the issue from a simple missing signature into an unconstrained forced deleverage path.

The state update trusted the supplied amounts

The state transition used the values from the payload directly.

if (self.deleveragerIsBuyingSynthetic == 1) {
    deleveragerSyntheticDelta = self.amountSynthetic;
    deleveragerCollateralDelta = -self.amountCollateral;
    deleveragableSyntheticDelta = -self.amountSynthetic;
    deleveragableCollateralDelta = self.amountCollateral;
} else {
    deleveragerSyntheticDelta = -self.amountSynthetic;
    deleveragerCollateralDelta = self.amountCollateral;
    deleveragableSyntheticDelta = self.amountSynthetic;
    deleveragableCollateralDelta = -self.amountCollateral;
}

There was no independent calculation that derived the collateral amount from the oracle price.

That created a direct question for the proof of concept:

What happens if the oracle says one synthetic unit is worth one collateral unit, but the deleverage payload requests one thousand collateral units?

Building the proof through real protocol paths

I wanted the proof to demonstrate the issue without direct storage mutation or artificial calls to internal accounting functions.

The test created two accounts with registered signers.

The victim deposited 100000 collateral.

The recipient deposited 1 collateral.

A real signed TYPE_TRADE then opened opposing perpetual positions.

After the trade, the victim held 100001 collateral and a synthetic position of 0 − 1.

The recipient held 0 collateral and a synthetic position of 1.

The victim was healthy before deleverage. Its normalized account value was 100000, while its normalized risk value was only 1.

This established that the test was not exercising a legitimate emergency action against an insolvent account.

Executing arbitrary deleverage terms

The test then submitted a normal TYPE_DELEVERAGE payload through the batch execution path.

The synthetic amount was 1.

The collateral amount was 1000.

The oracle price for one synthetic unit was 1.

The economically fair collateral value was therefore 1, but the payload requested 1000.

The contract accepted it.

After execution, the victim held 99001 collateral and no remaining synthetic position.

The recipient held 1000 collateral and no remaining synthetic position.

The victim had lost 1000 collateral units while the recipient had gained the same amount.

After accounting for the synthetic exposure that was removed, the victim lost 999 units of value and the recipient gained 999 units of excess value.

The important point is not merely that the transaction was unsigned. The contract accepted economically arbitrary terms against a healthy account.

Turning the internal gain into external tokens

A balance change inside a protocol is not always equivalent to realizable loss.

So the next step was to test whether the recipient could actually remove the gained collateral.

After receiving 1000 collateral through deleverage, the recipient submitted a normal signed TYPE_WITHDRAWAL.

The withdrawal succeeded.

The recipient received 1000 ERC20 units externally, and the system balance inside LoadingZone decreased accordingly.

This confirmed that the impact was not limited to internal accounting. The value gained through the malformed deleverage operation could leave the protocol through its legitimate withdrawal path.

Replay and position crossing

TYPE_DELEVERAGE also lacked transaction level replay protection.

The payload contained no nonce or unique identifier that would mark it as already processed.

I executed the exact same payload a second time.

It succeeded again.

The victim collateral fell to 98001, while the recipient collateral increased to 2000.

The second execution also pushed the synthetic positions through zero and into the opposite direction.

The victim synthetic balance became 1.

The recipient synthetic balance became 0 − 1.

This proved that the same unsigned instruction could be reused and that the path did not enforce exposure reducing behavior.

Control tests

The proof also checked neighboring security boundaries so that the result could not be explained by unrelated broken protections.

An unregistered signer still reverted.

A raw attempt to withdraw more collateral than allowed still reverted.

An external account could not directly call the protected transaction processor path.

Those controls passed.

The finding therefore did not depend on an arbitrary externally owned account bypassing the batcher.

The vulnerable behavior happened after a deleverage payload reached the legitimate authorized execution path.

What the test suite proved

The Foundry suite passed with nine tests and no failures.

The proof established all of the following:

Real signed TYPE_TRADE transactions created the initial market state.
The victim was healthy before deleverage.
The Deleverage payload contained no signature and no nonce.
The protocol accepted 1000 collateral for 1 synthetic while the oracle price was 1.
The victim lost collateral and the recipient gained it.
The recipient externalized the gained collateral through a real signed withdrawal.
The same deleverage payload executed twice.
Unregistered signer validation still worked.
Raw over withdrawal protection still worked.
Direct unauthorized access to the transaction processor still failed.

The proof used local Foundry execution and real protocol paths. It did not depend on an RPC fork, governance action, direct vulnerable state mutation, or owner compromise.

Running the proof

The complete suite was executed with:

forge test --match-contract DeleveragePoC -vvv

The result was:

Suite result: ok.
9 passed
0 failed
0 skipped

I also separated the core properties into dedicated tests for cash out, healthy account deleverage, replay, price fairness, guards, and arithmetic.

This made it easier to verify each part of the exploit independently.

Why HackenProof classified it as Critical

I originally reported the issue as High because I wanted to remain conservative around the authorized batch trust boundary.

HackenProof later validated it as Critical.

That classification makes sense when the full impact is considered.

The contracts accepted attacker chosen economic terms against a healthy account, allowed value to be transferred to another account, and allowed that value to be withdrawn from the system.

The same payload could also be replayed.

This was not a harmless mismatch between documentation and implementation. It was a realizable collateral loss path inside a legitimate protocol transaction flow.

The contest economics

The technical severity and the financial outcome were very different.

The submission fee for this report was $5.

The same vulnerability was independently reported by 27 researchers, so the Critical reward was shared across the valid reports.

My payout was $8.48.

Across the TipRun contest, my total loss reached $18.

That is one of the realities of competitive audit programs. Finding a Critical vulnerability does not guarantee a large payout when many researchers reach the same issue and the reward is divided among them.

How I would fix it

The correct remediation depends on the intended semantics of TYPE_DELEVERAGE.

If deleverage is voluntary, every economically relevant field should be bound to typed signed data, and the protocol should consume nonces before applying state changes.

The signed message should cover the relevant account identifiers, asset, synthetic amount, collateral amount, direction, and any applicable deadline.

If deleverage is intentionally forced, victim consent is not required, but the contract must enforce the conditions that make the operation safe.

The affected account should be unsafe before forced deleverage is allowed.

The direction should reduce an existing synthetic exposure.

The operation should not cross the position through zero.

The collateral amount should be bounded by the oracle price together with any explicitly configured premium or penalty.

The protocol should also include replay protection so that the same deleverage instruction cannot be processed more than once.

These guarantees should exist on chain.

A trusted sequencer deciding that an operation is reasonable is not equivalent to the contract enforcing the financial invariants itself.

The broader lesson

Privileged execution paths deserve the same economic scrutiny as public entry points.

It is easy to stop at the question of who is allowed to call a function.

But access control does not guarantee that the data supplied by an authorized caller is safe.

A registered signer is not the same thing as a signer who approved the current message.

A forced protocol action is not automatically safe merely because the caller is trusted.

The more important question is:

Once an authorized operation reaches the contract, what prevents economically impossible terms from being accepted?

In this case, the contract did not enforce enough.

TYPE_DELEVERAGE accepted supplied terms after checking signer registration, but without cryptographic consent and without the objective constraints required for safe forced deleverage.

That gap was enough to turn a risk management mechanism into a direct collateral transfer primitive.

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.