feat: st0x-fixed-spread-v6 asserts the signed vault NAV ratio (RAI-1721)

[hardyjosh]

What

Adds src/st0x-fixed-spread-v6.rain (+ companion src/st0x-fixed-spread-v6.md) — v6 of the ST0x fixed-spread strategy, implementing the strategy half of RAI-1721 (RAI-1479: vault NAV ratio asserted at settlement). The v5 strategy is untouched and remains live until v6 deploys; versions live side by side.

How it works

• The order's oracle-url moves to https://oracle.t0trade.com/context/v6 and oracle-schema-version to 6. Slots 0–8 are identical to v5; slot 9 carries the vault NAV ratio as the lossless Rain Float packing, at 18 decimals, of the vault's raw convertToAssets(1e18) — the exact value the pricing model priced the quote against.
• At settlement the strategy reads the wt vault's live value via erc4626-convert-to-assets from rainlanguage/rain.erc4626.words, deployed on Base at 0xd69dC3d58a7C875117f9c7cecF4F1A7f3CA47254 and bound as erc4626-subparser in both scenarios. The share amount is the Float literal 1 (one whole share), which at the vault's 18 share decimals converts losslessly to the raw 1e18 probe; the word returns the vault's answer Float-packed at the underlying asset's 18 decimals.
• The comparison is numeric equal-to, and that is exact: lossless packing of the same raw value at the same decimals is injective on values, so numeric equality of the two Floats is equivalent to bit-for-bit equality of the raw ratios — while staying robust to any normalization difference between the server's Rust packing and Solidity's LibDecimalFloat. A fill can therefore never straddle a NAV step (e.g. a dividend deposit).
• The NAV assertion is unconditional — the vault read and the equality run on every fill. This strategy only ever deploys on wt pairs (the sell/buy scenario split exists precisely because the wt side is known at deploy time), and a real vault's live convertToAssets is never zero, so a zero signed ratio fails the equality and the fill reverts. An upstream that stops publishing ratios halts fills on this strategy rather than letting them settle unprotected — that is intended. v5 covers pairs without a vault side (documented in the strat and the .md).
• The vault address is wired from the order's own IO, dia-limit style: two deployments, sell shares (wt-vault: ${order.outputs.0.token.address}) and buy shares (wt-vault: ${order.inputs.0.token.address}). No manually-entered vault address.
• Registry index updated: all pins bumped to the content commit and the st0x-fixed-spread-v6 line added, matching the pin convention of Point st0x fixed-spread and oracle-limit at 0trade v5 oracle #52/Add SFT HyperEVM subgraph URL #53.

Dependencies

Deploy sequencing: RAI-1754 + RAI-1755 before RAI-1757. This strategy is only viable once both upstreams are live:

• RAI-1754 — st0x-oracle-server serves /context/v6 (Mirror the 14 Base-only tokens onto the Ethereum and HyperEVM token lists #64, branch feat/context-v6-nav-ratio, signing slot 9 as the lossless 18-decimal Float packing). Until then the oracle URL serves nothing.
• RAI-1755 — st0x.pricing publishes real vault NAV ratios. Because the NAV assertion is unconditional, a v6 context with a Float-zero slot 9 makes every fill revert — the strat halts rather than settling unprotected.

Only then does RAI-1757 (deploying this strategy) go ahead.

Validation

• Frontmatter YAML parses; binding declarations and uses are consistent; erc4626-subparser bound to the deployed address in both scenarios.
• Word semantics verified against rain.erc4626.words source (LibERC4626.convertToAssets: shares Float → toFixedDecimalLossless at share decimals; output fromFixedDecimalLosslessPacked at asset decimals) and its parse tests, which call erc4626-convert-to-assets(<vault> 1) for one share; on-chain code confirmed at the Base address.
• scripts/build-public-registry-data-uri.sh and scripts/build-private-registry-artifact.sh both build green with the new registry line (the repo has no PR-triggered CI; both workflows are workflow_dispatch).

🤖 Generated with Claude Code

https://claude.ai/code/session_01TQ3QV1QrwmaS7ACSf7cds7

Closes RAI-1721

[linear-code]

RAI-1721

[Siddharth2207]

NAV fork validation (RAI-1721)

Added CI so this PR’s vault NAV bind can be exercised on a Base fork without bolting Foundry into the registry itself.

What runs

• Workflow: st0x-v6-nav-fork.yml
• Harness: RaindexV6St0xNavForkTest on rainlanguage/raindex@feat/st0x-v6-nav-fork-test
• Asserts:
  1. quote2 + takeOrders4 succeed when live NAV matches signed slot 9
  2. after donating underlying into the wt vault, takeOrders4 reverts with Vault NAV ratio mismatch

How to re-run

• Actions → st0x-v6 NAV fork test → Run workflow (optional raindex_ref)
• Or any PR that touches src/st0x-fixed-spread-v6.*

Local equivalent:

BASE_MAINNET_RPC_URL=<rpc> forge test --match-contract RaindexV6St0xNavForkTest -vvv

(from a raindex checkout on that branch)

[Siddharth2207]

✅ NAV fork CI green

Latest run: https://github.com/ST0x-Technology/st0x.registry/actions/runs/32760813301

Both RaindexV6St0xNavForkTest cases passed on Base fork (quote+take when NAV matches; take reverts after NAV step).

[Siddharth2207]

Fork test source

The Foundry harness lives in raindex (not this registry repo):

https://github.com/rainlanguage/raindex/blob/feat/st0x-v6-nav-fork-test/test/concrete/raindex/RaindexV6.st0xNav.fork.t.sol

Branch: feat/st0x-v6-nav-fork-test

Live Order:
https://v6.raindex.finance/orders/8453-0xe522cB4a5fCb2eb31a52Ff41a4653d85A4fd7C9D-0x153efcdae1ec00a07849110f1107ccc49d4289b94729670a297db1138390e4a8