Shipped behavior (stays as-is per ruling): clear3 (src/concrete/raindex/RaindexV6.sol:705-720) passes bobSignedContext into alice's calculateOrderIO and aliceSignedContext into bob's. The interface (raindex.interface IRaindexV6.sol) documents aliceSignedContext as "Optional signed context that is relevant to A" — and the sibling entrypoints route by order (quote line 433: quoteConfig.signedContext to the quoted order; takeOrders line 519: takeOrderConfig.signedContext to the taken order). clear3 alone inverts, and RaindexV6.clear.context.t.sol passes empty arrays both sides, so no test arbitrates.
Why this is not a security bug: the clearer supplies both arrays and controls slot placement entirely; an order's expression can only trust signer + signed content, never slot. A malicious clearer gains nothing from the swap, and content-level binding (order hash inside the signed payload) survives it. The harm is to honest spec-following callers: context attached per the docs is delivered to the wrong eval, so clears that consume signed context revert or misbehave, and the empirical workaround (swap the arrays until it works) enshrines the inversion.
Ruling (2026-08-27): production/V6 continues with shipped behavior. The fix lands in the next interface version and MUST fail loudly so consumers see they have to change:
- Next interface version replaces
clear3 with a corrected entrypoint (new name/selector, e.g. clear4) that routes each order's signed context to that order's own eval, matching quote/takeOrders.
- The old selector is REMOVED in the implementing contract of that version — callers carrying V6 assumptions (including empirically swapped arrays) hit a hard revert at the missing selector instead of a silent semantic change.
- The new version ships a context test that pins the routing (which eval sees which signed context, asserted by signer/content) — closing the zero-coverage that let spec and impl disagree.
- V6's interface NatSpec is the lying artifact for the shipped version; triage may route a doc correction (documenting the actual counterparty-swapped routing, with a warning) to raindex.interface for V6 consumers.
🤖 Generated with Claude Code
Shipped behavior (stays as-is per ruling):
clear3(src/concrete/raindex/RaindexV6.sol:705-720) passesbobSignedContextinto alice'scalculateOrderIOandaliceSignedContextinto bob's. The interface (raindex.interface IRaindexV6.sol) documentsaliceSignedContextas "Optional signed context that is relevant to A" — and the sibling entrypoints route by order (quoteline 433:quoteConfig.signedContextto the quoted order;takeOrdersline 519:takeOrderConfig.signedContextto the taken order).clear3alone inverts, and RaindexV6.clear.context.t.sol passes empty arrays both sides, so no test arbitrates.Why this is not a security bug: the clearer supplies both arrays and controls slot placement entirely; an order's expression can only trust signer + signed content, never slot. A malicious clearer gains nothing from the swap, and content-level binding (order hash inside the signed payload) survives it. The harm is to honest spec-following callers: context attached per the docs is delivered to the wrong eval, so clears that consume signed context revert or misbehave, and the empirical workaround (swap the arrays until it works) enshrines the inversion.
Ruling (2026-08-27): production/V6 continues with shipped behavior. The fix lands in the next interface version and MUST fail loudly so consumers see they have to change:
clear3with a corrected entrypoint (new name/selector, e.g.clear4) that routes each order's signed context to that order's own eval, matchingquote/takeOrders.🤖 Generated with Claude Code