Cowrie Research

post-trade-solvency-validation-bypass

15 min read

Post-Trade Solvency Validation Bypass / Toxic Execution Admission

  • Name: post-trade solvency validation bypass / toxic execution admission
  • Category: exploit pattern / unhealthy-position admission / execution-path solvency failure / slippage-socialization bug
  • Summary: Post-trade solvency validation bypasses happen when a leveraged protocol, margin engine, or other borrow-backed execution path lets the dangerous trade happen first and only conditionally proves afterwards that the resulting position is still healthy. If the order itself is big enough to destroy execution price, the protocol can underwrite its own toxic flow into a shallow venue, create an already-underwater position, and then leak value to whoever pre-positioned the opposite side. Sometimes the attacker first conditions the oracle or strategy mark that decides whether the route is allowed at all, but the decisive second failure is still that the protocol admits a position whose real executable fill is already bad. The failure is not market moved after the borrow; it is the protocol admitted a position that was already insolvent once its own trade actually cleared.
  • What it is:
    • A protocol lets users open leveraged or borrow-backed positions by routing a real trade through one or more external venues.
    • The protocol assumes that if the resulting position would be unhealthy, a final health check will reject it.
    • In practice, that validation is skippable, too late, or weaker than the execution path that already consumed liquidity.
    • The protocol’s own order moves the venue far enough that the new position starts life underwater.
    • An attacker with opposite-side inventory, or one who can cheaply acquire it in the same bundle, monetizes the protocol-created mispricing while the protocol keeps the toxic position.
  • Typical preconditions:
    • A margin, leverage, or structured-trade flow can borrow first and validate after routing the trade.
    • The allowed trade size is large relative to executable liquidity on the actual venue path.
    • Final solvency checks sit behind optional branches, Boolean short-circuits, or helper-path assumptions rather than one unavoidable validation boundary.
    • The attacker can atomically pre-position the opposite-side asset or hedge leg that profits from the protocol’s own price impact.
    • The protocol socializes execution losses to a lending pool, vault, or shared balance sheet once the unhealthy position is admitted.
  • Common vulnerable surfaces:
    • leverage products that route large market orders into shallow AMMs or single-reserve aggregators
    • marginTrade, structured-deposit, or one-click leverage flows that borrow protocol funds before confirming post-trade health
    • execution helpers whose safe path branch skips the same solvency checks the riskier branch still performs
    • protocols that cap leverage notionally but do not cap venue-relative slippage or route-relative executable depth
    • strategy adapters or farm integrations that treat a manipulable oracle or TWAP as permission to route borrowed funds into the same thin venue that produced the mark
    • systems where downstream liquidations are expected to clean up a position that should never have been admitted in the first place
  • Failure sequence:
    1. The attacker prepares opposite-side inventory or some other leg that benefits if the target protocol shoves a shallow market out of line.
    2. The attacker opens a leveraged or borrow-backed trade through the target protocol.
    3. The protocol borrows funds and executes the route, pushing the venue to a catastrophically bad fill.
    4. The new position should fail maintenance-margin or health-factor rules immediately after execution.
    5. A skipped, short-circuited, or too-weak post-trade validation path admits the position anyway.
    6. The attacker sells into the protocol-created distortion, unwinds the financing leg, and leaves the protocol holding the underwater side.
  • Variants:
    • Boolean short-circuit bypass — a path that looks like an overcollateralized or same-asset case skips the health check entirely.
    • Execution-before-validation design — the health check exists, but only after the protocol has already routed the full toxic order into the venue.
    • Route-depth blindness — leverage limits are set from nominal collateral rules rather than the real depth of the route the protocol will actually hit.
    • Oracle-conditioned toxic admission — a manipulated or weakly defended oracle makes a borrow-backed strategy look healthy long enough for the protocol to route real funds into a venue whose executable depth never supported that solvency claim.
    • Opposite-side inventory harvest — the attacker does not need to fabricate a fake price feed; they just need inventory ready to sell into the protocol’s self-created mispricing.

Three borrowed-execution questions reviewers should not collapse

  1. Did some permissioning mark say the route was admissible at all?

    • A TWAP, oracle, strategy sanity flag, collateral mark, or leverage gate may say this entry is allowed.
    • That is only the first promotion. It does not yet prove the route can safely absorb the borrowed size.

  2. Could the protocol actually execute that borrowed route at this size without self-authored toxic flow?

    • This is the route-depth and fill-quality question: actual venue depth, hop composition, slippage bounds, same-venue feedback loops, and whether the protocol is borrowing from a deep pool to force size into a thin one.
    • A route can be allowed at the permissioning mark and still be too shallow to survive the protocol’s own order.

  3. Did the resulting post-fill position still deserve shared balance-sheet support?

    • Even if the route executed, the final position still has to prove it is healthy at the real fill and under realistic unwind assumptions.
    • The trade completed is not the same thing as the protocol should keep this position on the books.

Rodeo is a good reminder that these are separate questions. The manipulated multi-window TWAP answered may enter, the live route depth and unreleased-strategy hardening answered can borrow into this venue safely, and the post-trade health check should have answered does the resulting position deserve to survive at all. Healthy systems do not let those three questions collapse into one vague the strategy looked healthy conclusion.

  • Detection heuristics:
    • Ask whether a freshly opened leveraged position can be unhealthy at the exact execution price the protocol itself just paid. If yes, the protocol needs an unavoidable post-trade reject path.
    • Compare maximum supported trade size against executable venue depth, not just collateral ratios or nominal leverage caps.
    • Trace every branch into the final health check and prove that no helper-path assumptions can short-circuit it.
    • Simulate attacker-controlled opposite inventory in the same transaction bundle; many systems look safe until the protocol’s own slippage is treated as harvestable value.
    • If strategy admission depends on an oracle or TWAP, test the worst still-admissible mark and then replay the actual route through the same venue. A strategy that only looks healthy at the permissioning mark but not at the realizable fill is already toxic on entry.
    • Treat routing, slippage bounds, oracle permissioning, and validation order as one solvency surface rather than separate UX and risk modules.
  • Defenses:
    • Make post-trade solvency validation mathematically unavoidable on every execution path.
    • Refuse to route orders whose worst-case executable fill would already violate maintenance margin or health-factor constraints.
    • Add venue-depth-aware trade caps and per-route slippage limits, not just collateral-based leverage caps.
    • Keep routing logic and solvency logic coupled tightly enough that any path changing execution semantics also inherits the same validation boundary.
    • Do not let oracle-sensitive or incompletely configured strategies become borrowable before their sanity checks, route guards, and executable-depth assumptions are all live.
    • Treat liquidate later if needed as a failure mode, not a safety mechanism, for positions that are born underwater because of the protocol’s own trade.
  • High-signal incidents:
    • [[../../../incidents/lending-liquidations/bzx-fulcrum-eth-wbtc-margin-pump-shouldliquidate-bypass-2020-02-15|bZx / Fulcrum ETH-WBTC margin-pump shouldLiquidate() bypass (2020-02-15)]] — the canonical Boolean-short-circuit case: Fulcrum’s own oversized Kyber-routed short shoved Uniswap so far out of line that the new position should have failed maintenance-margin checks immediately, but a skipped shouldLiquidate() gate let the attacker monetize the distortion with hoarded Compound WBTC.
    • ForceInvestment health-factor bypass (2023-07-11) — the oracle-conditioned strategy-admission cousin: Rodeo let a gameable multi-window TWAP make strategy 41 look healthy, then Investor.earn() borrowed real USDC and routed it into the same thin market, so the protocol admitted a toxic position whose apparent solvency only existed at the attacker-shaped mark.

What sound design looks like

  • One admission decision should already include executable reality: the permissioning mark, route, venue depth, slippage ceiling, and post-trade health test all need to describe the same worst-case fill before borrowed funds move.
  • One route-size policy should dominate: leverage limits should be capped by realizable depth on the actual execution path, not by headline collateral ratios alone.
  • One post-state solvency proof should gate every borrow-backed trade. Same-asset shortcuts, helper branches, retries, and asynchronous continuations should all have to prove the resulting position is healthy at the fill the protocol actually got.
  • One failure mode should be preferred over toxic admission: if the protocol cannot prove the route stays solvent at executable prices, it should shrink, delay, or refuse the trade rather than trust later liquidation to socialize the mistake.
  • One admitted mistake should still be survivable: per-market borrow caps, venue-aware notional limits, route-specific pauses, and slippage bounds should keep a single toxic execution from becoming systemwide bad debt.
  • One review ladder should stay explicit: permissioning mark allowed entry, route could really absorb the borrowed size, and post-fill position still deserves shared solvency support are separate gates, not one blended trade looked okay feeling.

Failure-prevention checklist

  • Make post-trade health validation an unavoidable boundary for every borrow-backed execution path. No same-asset shortcut, helper branch, or safe mode path should be able to skip the check that proves the resulting position is still healthy at the real fill.
  • Size leverage against executable route depth, not just collateral ratios. If the venue path cannot absorb the order without producing an already-liquidatable position, the trade size is unsafe even when pre-trade math looks fine.
  • Compute worst-case admission against the exact route semantics the protocol will use: venue mix, pool fee tier, inventory source, callback path, and slippage bounds. A risk engine that evaluates one market but executes another is already detached from truth.
  • Keep routing, slippage control, and solvency logic in one shared execution envelope. If one module can change route shape or execution venue without inheriting the same post-trade validation rules, it has become an unsupervised balance-sheet surface.
  • Refuse to socialize large price impact from protocol-borrowed flow into thin venues. Borrow-backed market orders should degrade into smaller chunks, route-specific caps, or outright refusal when the protocol would otherwise be underwriting its own toxic fill.
  • Treat strategy-entry or leverage-entry oracles as permissioning hints, not as proof that executable depth exists. A manipulable TWAP or stale mark should never be enough to authorize borrowed funds into the same thin venue that produced the mark.
  • Force review to preserve the whole ladder from entry is allowed to route can absorb this size to resulting position is healthy. If any one of those steps is missing, the protocol is still letting borrowed execution outrun solvency proof.
  • Fail closed on missing or ambiguous downstream health evidence. If a route cannot produce the data needed to prove post-trade solvency at execution price, the protocol should not complete the trade and hope liquidation cleans it up later.
  • Bind asynchronous helpers, retries, and keeper-side continuation paths to the same final solvency predicate as the direct user path. Delayed settlement or multi-step execution should not open a looser admission rule.
  • Put blast-radius limits under the route anyway: per-market borrow caps, per-route notional caps, tighter slippage ceilings, and strategy-specific pauses should stop one toxic trade from becoming protocol-scale bad debt.
  • Monitor for impossible admissions in production: positions born near or below liquidation threshold, repeated fills landing at extreme slippage, or strategies whose post-trade health only survives at the permissioning mark rather than the executed one.

Audit prompts

  • At what exact point does the protocol prove this position is healthy after the real fill, and can any branch spend borrowed funds before that proof becomes unavoidable?
  • Which object first says this trade may enter — oracle, TWAP, strategy flag, collateral mark, route quote, or leverage gate — and what separate proof says the venue can actually absorb the borrowed size without the protocol authoring its own toxic fill?
  • Which paths can short-circuit or weaken the final health check: same-asset trades, overcollateralized branches, rescue helpers, retries, batch execution, asynchronous callbacks, or stale-cache fast paths?
  • What executable liquidity model does the protocol actually use for admission: oracle mark, quoted path, AMM spot, TWAP, offchain router quote, or a bounded worst-case simulation? Which of those is closest to the real fill?
  • If the attacker holds the opposite-side inventory, how much value can the protocol’s own order donate to them before the trade would become immediately liquidatable?
  • Can the protocol route borrowed funds into the same venue, pool, or strategy path that also authored the oracle or TWAP used to admit the trade in the first place?
  • Do slippage limits protect the protocol balance sheet or only protect the user from visibly terrible UX? A route cap that still permits an underwater position is not a solvency control.
  • Are route-size limits expressed per market, per venue, per hop, and per collateral type, or only as a notional leverage multiple divorced from real depth?
  • What happens when downstream execution becomes partial, delayed, or keeper-completed? Does the same post-trade solvency proof still gate settlement, or does the protocol fall back to optimistic accounting?
  • Can a liquidator or backstop later socialize the loss from a position the protocol itself should have rejected on entry? If yes, the liquidation design may just be monetizing toxic admission rather than containing it.
  • Which tests explicitly prove that a newly opened leveraged position cannot start life below maintenance margin at the execution prices the protocol itself can realistically clear?

Lessons that should already be standard

  • We check health after execution is not enough if execution already spent shared funds into a venue the protocol was too large for. If the post-trade reject path is optional, late, or economically toothless, the protocol has already underwritten the loss.
  • Route depth is part of solvency, not a separate trading-quality concern. A leverage engine that ignores its own market impact is outsourcing risk control to whoever stands on the other side of the book.
  • Liquidation is not a cleanup substitute for toxic admission. A position born underwater because of the protocol’s own trade should be treated as an entry failure, not as valid business that keepers can sort out later.
  • Same-asset or apparently safer branches deserve extra suspicion, not less. Many catastrophic bypasses hide behind the code path developers felt least needed the expensive health check.
  • Oracle permissioning and execution routing are one security story when borrowed funds are involved. If the mark that authorizes entry is easier to shape than the venue that clears the trade, the protocol is already split across two inconsistent notions of truth.
  • Entry looked allowed is weaker than route was executable, and route was executable is weaker than the resulting position deserved to survive. Healthy leverage systems keep those three answers separate and machine-checked.
  • Leveraged products should price their own size honestly. A system that can only stay solvent when users or attackers politely avoid the full notional it advertises is not conservatively designed; it is under-tested.
  • Multi-step strategies and helper paths are not just UX wrappers. Once they decide when borrowed funds move and when health is re-checked, they are balance-sheet code.
  • The clean design goal is stronger than most trades stay healthy: no admitted position should require favorable post-entry drift, instant external arbitrage, or later liquidation subsidy to justify the fill the protocol itself just took.

Internal linkages

Control surface

Graph View

Backlinks