feat: /context/v7 signs the deployment chain id at slot 10 (RAI-1991) - #65
Open
hardyjosh wants to merge 1 commit into
Open
feat: /context/v7 signs the deployment chain id at slot 10 (RAI-1991)#65hardyjosh wants to merge 1 commit into
hardyjosh wants to merge 1 commit into
Conversation
Contributor
Author
This stack of pull requests is managed by Graphite. Learn more about stacking. |
hardyjosh
force-pushed
the
feat/rai-1991-context-v7-chain-id
branch
from
August 24, 2026 10:33
fab6d7f to
1b61e1e
Compare
hardyjosh
marked this pull request as ready for review
August 25, 2026 17:18
The signature over the context is chain-agnostic EIP-191 and no slot names a chain, so a signed payload binds only to the token address pair. ST0x tokens are deterministic clones across chains -- the same addresses can exist on two chains -- so a context produced for chain A verifies byte-for-byte inside an order on chain B. Today that is mitigated operationally (the oracle URL is a per-order deploy-time binding and the server is Base-only), not cryptographically. v7 closes it in the signed payload: the deployment's chain id (new config key chain_id, default 8453) rides slot 10, covered by the existing signature over all slots. Per-order rainlang asserts equal-to(signed-context<0 10> expected-chain-id) against a per-deployment binding, same pattern as the oracle-signer binding. Chain-scoped subpaths need zero solver changes (allowlist is startsWith), so a future multichain server can surface the value per path segment without touching this schema. v6 stays unchanged and is still served on /context/v6. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
hardyjosh
force-pushed
the
feat/rai-1991-context-v7-chain-id
branch
from
August 26, 2026 16:55
1b61e1e to
44a1741
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

Closes RAI-1991. Hardening only — per the multichain review, Raindex trading (and therefore this server) stays Base-only in v1; this is not a Bebop-rollout blocker.
The gap
The signature over the context is chain-agnostic EIP-191 and no slot names a chain, so a signed payload binds only to the
(input_token, output_token)pair. ST0x tokens are deterministic clones across chains — the same addresses can exist on two chains — so a v6 context produced for chain A verifies byte-for-byte inside an order on chain B. Today that's mitigated operationally (the oracle URL is a per-order deploy-time binding; the server is Base-only), not cryptographically.What v7 adds
/context/v7: the v6 shape plus the deployment's chain id at slot 10, Rain-Float encoded, covered by the existing EIP-191 signature over all slots. Strict extension — slots 1–9 byte-identical to v6 from the same quote (pinned by test).chain_id(default 8453). The server stays single-chain by design; the chain rides the per-order oracle URL, and the solver's allowlist isstartsWith, so a future multichain server can surface the value per path segment with zero solver changes and no schema change.equal-to(signed-context<0 10> expected-chain-id)against a per-deployment binding — same pattern as theoracle-signerbinding. The wrong-chain payload then fails the strategy's own assert regardless of URL wiring.Testing
cargo test: 96 pass (5 new: v7 layout, strict-extension vs v6 at both builder and route level, arbitrary chain ids incl. 1/999, route-level slot-10 pin; v7 added to the rate-orientation sweep across all endpoints)cargo fmt --checkclean.cargo clippycurrently fails on unmodified master on this box (num_enumproc-macro resolution inside the nix shell — pre-existing local env issue, reproduced on a cleancargo cleanrebuild without my diff). CI'soracle-rs-staticis the authority here.🤖 Generated with Claude Code