A firmness check built on EXTCODESIZE(owner) is forgeable, and six live contracts prove it

The mismatch is exact. EXTCODESIZE greater than zero confirms bytecode sits at an address and says nothing about what that bytecode is permitted to do ^[4]. A firmness guarantee is a claim about capability, whether this owner can remove its own resting depth, and the opcode answers a question about presence instead ^[2]. That is a different error from the well-known constructor case; the direction is flipped, so that instead of gating who may act, the check promises a third party that depth is stuck ^[6].

Two of the escapes are worth reading closely because they beat the defenses a careful team would reach for. The first defense is scanning the owner contract's bytecode for a cancel path. Technique four beats it by not containing one: once its order is resting, the contract calls a shared permissions registry and grants a plain wallet the right to cancel on its behalf, so the withdrawal fires through selectors that appear nowhere in the audited code ^[10]. The second defense is checking that the order still exists on the book. Technique five beats that, because it never cancels; reduceOrder shrinks the quote in place and refunds the freed escrow, collapsing an advertised 1,000,000-unit level to a minimum-size stub while the order id survives ^[11]. If the promise is that the depth cannot be withdrawn, a reduce falsifies it without tripping any cancel detector.

By the developer's account, where an escape did fail, it failed at execution rather than at classification, and that gap is the whole argument. The guarantee is made while the order rests, and at rest all six read FIRM ^[17]. A signal that misclassifies at the moment a taker decides is not rescued by a later transaction that fails against one particular pool. That is why a wrong answer here is worse than none: it launders liquidity that may not be there through a number people have chosen to trust ^[19].