Skip to content

feat: /context/v7 signs the deployment chain id at slot 10 (RAI-1991) - #65

Open
hardyjosh wants to merge 1 commit into
mainfrom
feat/rai-1991-context-v7-chain-id
Open

feat: /context/v7 signs the deployment chain id at slot 10 (RAI-1991)#65
hardyjosh wants to merge 1 commit into
mainfrom
feat/rai-1991-context-v7-chain-id

Conversation

@hardyjosh

@hardyjosh hardyjosh commented Aug 24, 2026

Copy link
Copy Markdown
Contributor

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).
  • New config key chain_id (default 8453). The server stays single-chain by design; the chain rides the per-order oracle URL, and the solver's allowlist is startsWith, so a future multichain server can surface the value per path segment with zero solver changes and no schema change.
  • Consumer contract: v7 rainlang MUST assert equal-to(signed-context<0 10> expected-chain-id) against a per-deployment binding — same pattern as the oracle-signer binding. The wrong-chain payload then fails the strategy's own assert regardless of URL wiring.
  • v6 (and below) unchanged and still served.

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 --check clean.
  • Caveat: cargo clippy currently fails on unmodified master on this box (num_enum proc-macro resolution inside the nix shell — pre-existing local env issue, reproduced on a clean cargo clean rebuild without my diff). CI's oracle-rs-static is the authority here.

🤖 Generated with Claude Code

@linear-code

linear-code Bot commented Aug 24, 2026

Copy link
Copy Markdown

RAI-1991

hardyjosh commented Aug 24, 2026

Copy link
Copy Markdown
Contributor Author

@hardyjosh
hardyjosh force-pushed the feat/rai-1991-context-v7-chain-id branch from fab6d7f to 1b61e1e Compare August 24, 2026 10:33
@hardyjosh
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
hardyjosh force-pushed the feat/rai-1991-context-v7-chain-id branch from 1b61e1e to 44a1741 Compare August 26, 2026 16:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant