Summary

This referendum calls intentsCoprocessor.setPhantomOrderConfig to register the USDC/cNGN pair on base, ethereum mainnet and polygon mainnet, with a generation interval of 300 blocks.

It is the required follow-up to the nexus runtime 8300 upgrade. Runtime 8300 restructured phantom order generation (#1086) so that one bundled order is emitted per chain rather than one order per pair, and its ClearLegacyPhantomState migration deliberately wipes PhantomOrderConfig, CurrentPhantomOrder and LastPhantomGeneration, because the stored configuration's shape changed and cannot be interpreted under the new format. Phantom order generation is therefore halted from the moment 8300 is enacted until this configuration is set. Passing this proposal restarts it, on a wider set of chains than the single-chain (base-only) configuration that 8300 cleared.

What phantom orders do

Phantom orders are non-executable probe orders the coprocessor emits on a fixed interval. Fillers bid on them, and those bids are what the indexer turns into published exchange rates for the pair. No user funds are involved and nothing settles on the destination chain — the orders exist purely to elicit priced quotes, so the practical effect of this call is which pairs and chains have a live price feed.

Configuration being set

standard_amount and standard_amount_b are 1_000_000 for every entry, and interval_blocks is 300.

Each chain registers the pair once. Under 8300 the generator expands a configured pair into both a forward and a reverse leg, so USDC→cNGN and cNGN→USDC are both priced from a single entry; registering both directions explicitly — as the pre-8300 configuration did — would now double-count the pair in the chain's bundled order and is rejected by DuplicatePhantomTokenPair.

Why these values

Amounts. standard_amount must be exactly one whole unit of token_a in its smallest denomination (10^decimals), and standard_amount_b one whole unit of token_b. These are the denominators of every rate the indexer publishes: a value that is off by a factor silently scales every published rate by that factor — it does not revert and does not warn. USDC and cNGN were each confirmed 6-decimal on all three chains by direct decimals() calls against the token contracts, so one unit is 1_000_000 in both directions on every entry.

Interval. 300 blocks, unchanged from the value in force before the migration cleared it. The pallet requires the bid acceptance window to close strictly before the next generation replaces the orders; the effective window is 25 blocks (PhantomBidWindow is unset, so it falls back to the PhantomOrderBidWindowBlocks constant of 25), and 25 < 300 satisfies that constraint.

Consensus state ids. Read from ismp.latestStateMachineHeight on nexus rather than assumed: ETH0 for both base and ethereum, POLY for polygon. The generator uses this to look up each chain's latest confirmed height directly, so a wrong id would stop that chain generating.

Execution details

• Origin: Root (GovernanceOrigin = EnsureRoot), i.e. the root track, or the whitelisted_caller track after a technical collective whitelist.
• Call: intentsCoprocessor.setPhantomOrderConfig, 253 bytes.
• Weight: 349,000,000 refTime / 1,627 proofSize; 366,450,000 / 1,709 with a 5% buffer. The benchmark is flat — it does not scale with the number of chains or pairs.
• Side effect by design: the call also clears CurrentPhantomOrder and LastPhantomGeneration, so the first bundled orders are emitted on the very next block rather than after a 300-block wait.
• All three state machines have a registered gateway in IntentsCoprocessor::Gateways, so orders can be generated for each of them.

Sequencing

This must be enacted after nexus runtime 8300. The encoded call uses the 8300 PhantomOrderConfiguration layout; dispatched against 8200 it would fail to decode. If both are in flight, confirm 8300 is live before this referendum's enactment period elapses.

Risks

• No effect until 8300 is live, and conversely the feed stays dark for the entire gap between 8300's enactment and this proposal's — the gap is operational downtime for USDC/cNGN pricing, not a safety issue.
• Amount correctness is not machine-checkable. The pallet only rejects zero; it cannot know what one unit of a token is. The 1_000_000 values rest on the on-chain decimals checks described above. A wrong value degrades the price feed silently and requires a backfill to repair.
• Adds two new chains to generation. Ethereum and polygon were not previously generating phantom orders. Each additional chain adds a bundled order every 300 blocks for fillers to bid on; the pallet's per-chain limits (16 chains, 64 pairs per chain) are far from binding at three and one.