Summary
The subparser words calculated-max-output(), calculated-io-ratio() (and input-vault-increase()/output-vault-decrease()) revert with an opaque Panic(0x32) (array OOB) when used in the calculate-order entrypoint, instead of returning 0 as their NatSpec promises ("This is 0 before calculations have been run", LibRaindexSubParser.sol lines 450/457/490/525).
Verified on 08d547fab (real interpreter + parser)
An order whose calculate source reads calculated-max-output() (e.g. _ _:calculated-max-output() 2;:;) makes quote2/takeOrders/clear revert Panic(0x32); the NatSpec-documented ensure(equal-to(calculated-max-output() 0)) form reverts before the ensure can evaluate. Root cause: RaindexV6.calculateOrderIO builds callingContext = new bytes32[][](4) and fills only indices 0/2/3; index 1 (CONTEXT_CALCULATIONS_COLUMN) stays a zero-length array during eval (it is populated only after eval4, RaindexV6.sol:854), so LibOpContext.run hits Solidity bounds-checks and reverts rather than reading 0.
Impact / triage
Medium (code-vs-NatSpec, no value loss). An expression author who follows the docs produces an order that always reverts opaquely. Fix: either pre-size/zero-fill the calculations column before eval4 so "0 before calculations" actually holds, or correct the NatSpec on all four words.
Surfaced by a blind adversarial sweep (code + spec only, no audit access) of 08d547fab, then re-verified with a real repro on that commit and dispatcher-reviewed. Part of a batch from the adversarial-mutation-test skill run.
Summary
The subparser words
calculated-max-output(),calculated-io-ratio()(andinput-vault-increase()/output-vault-decrease()) revert with an opaquePanic(0x32)(array OOB) when used in the calculate-order entrypoint, instead of returning0as their NatSpec promises ("This is 0 before calculations have been run",LibRaindexSubParser.sollines 450/457/490/525).Verified on
08d547fab(real interpreter + parser)An order whose calculate source reads
calculated-max-output()(e.g._ _:calculated-max-output() 2;:;) makesquote2/takeOrders/clearrevertPanic(0x32); the NatSpec-documentedensure(equal-to(calculated-max-output() 0))form reverts before theensurecan evaluate. Root cause:RaindexV6.calculateOrderIObuildscallingContext = new bytes32[][](4)and fills only indices 0/2/3; index 1 (CONTEXT_CALCULATIONS_COLUMN) stays a zero-length array during eval (it is populated only aftereval4, RaindexV6.sol:854), soLibOpContext.runhits Solidity bounds-checks and reverts rather than reading 0.Impact / triage
Medium (code-vs-NatSpec, no value loss). An expression author who follows the docs produces an order that always reverts opaquely. Fix: either pre-size/zero-fill the calculations column before
eval4so "0 before calculations" actually holds, or correct the NatSpec on all four words.Surfaced by a blind adversarial sweep (code + spec only, no audit access) of
08d547fab, then re-verified with a real repro on that commit and dispatcher-reviewed. Part of a batch from the adversarial-mutation-test skill run.