Summary

This referendum performs two Root-gated actions in one utility.batch:

1. Point the IntentGateway proxies at the new IntentGatewayV2 implementation on all nine
   supported EVM mainnets, via nine intentsCoprocessor.upgradeGateway cross-chain dispatches.
2. Authorize the nexus runtime 8300 upgrade via system.authorizeUpgrade.

1. IntentGatewayV2 activation

The new implementation is already deployed and explorer-verified at the deterministic CREATE2
address 0x976B268b06f545c4A2BF44866Aa2465bd8B3C67d on ethereum, arbitrum, optimism, base, bsc,
gnosis, soneium, polygon and Polkadot Hub (24,502 bytes of identical bytecode on every chain,
recorded in PR #1113). The ERC-1967
proxies at 0xAe041F7B0CB581876832830baeB6a2Aa2a3C9716 still point at the previous implementation
(0x7b4b4Bf42B6f822D95D11877699A4bf9216cd6cE), so nothing has changed on mainnet yet — this
referendum is the activation step.

What the new implementation changes: the OrderPlaced event carries the full order call payloads
and graffiti (predispatchCall, outputCall, graffiti) — see
PR #1093. The order commitment is
unchanged; only the event schema, and therefore its topic0, changes from 0x34509e62… to
0x76dc946f….

Each call is a zero-fee ISMP POST from pallet-intents-coprocessor to the gateway on the
destination chain, authorized on the contract by source == hyperbridge. init_data is empty — no
storage migration is required. The upgrades take effect per-chain as relayers deliver each request,
so activation is not simultaneous across the nine chains.

Integrator prerequisite. Because topic0 changes, an integrator or filler running pre-upgrade
software sees no OrderPlaced logs at all against an upgraded gateway, and a pre-upgrade
placeOrder reverts at receipt parsing after funds are escrowed. @hyperbridge/sdk 2.8.0 is
published; the filler 0.9.0 rollout to active fillers must be confirmed before this referendum is
enacted.

2. Nexus runtime 8300

Authorizes the runtime published as
nexus-v8300:

• Code hash (Keccak-256): 0xa8489747e3bb99ec7c247592130826a64919164b895cce182edb34808fe742ee
• Core version: nexus-8300, metadata V14, 2,090,728 bytes
• Built with rustc 1.91.1 (ed61e7d7e), reproducible via ./scripts/build_release_runtime.sh nexus-runtime

Contents: bundling of phantom pairs into a single order plus pair-centric liquidity pool indexing
(PR #1086), and the runtime version bump.

system.authorizeUpgrade only records the authorization; the WASM itself is not carried in this
proposal. After enactment anyone may submit the (free, unsigned) system.enactAuthorizedUpgrade(code)
with the matching blob to apply it.

Execution details

• Origin: Root (intentsCoprocessor.upgradeGateway is gated by EnsureRoot, as is
  system.authorizeUpgrade), i.e. the root track, or the whitelisted_caller track after a technical
  collective whitelist.
• Call: utility.batch (0x12c2adbe…) / utility.batchAll (0xc668756b…), 289 bytes.
• Weight: 6,289,827,621 refTime / 40,928 proofSize with a 5% buffer — well inside the normal-class
  per-extrinsic limit.
• Verified on-chain that all nine state machines have a registered gateway, so no call reverts with
  GatewayNotFound.

Risks

• Non-atomicity of utility.batch. A failing call is skipped and the batch continues (emitting
  BatchInterrupted), which could leave some chains upgraded and others not. utility.batchAll is
  the atomic alternative if voters prefer all-or-nothing.
• Staggered activation. Relayer delivery is per-chain, so the nine gateways switch over at
  different times. Fillers must handle both event schemas during the window; SDK 2.8.0 does.
• Enactment timing vs. filler rollout. If enacted before fillers have upgraded, orders placed on
  an upgraded chain go unfilled until they do. Enactment should be scheduled only after the filler
  rollout is confirmed.
• Polkadot Hub inclusion. PR #1113 excluded chain 420420419; the implementation there has since
  been independently confirmed deployed, verified and carrying the new event schema, so it is
  included here. Confirm with the PR author that the exclusion note referred only to the deployment
  step and not to an outstanding Revive-specific concern.
• Runtime authorization is inert on its own — no state change until enactAuthorizedUpgrade is
  submitted. The authorization is recorded with check_version = true, so the blob is validated
  (matching spec name, strictly increasing spec version) at the point it is applied, not now.