Canary Chain Configuration Verification

canary-2.json does not include the XAUT0 LayerZero ULN config updates for the live BSC <-> Conflux peer pair. The Safe transactions for BSC and Conflux exist and replay successfully, but the decoded canary-2-xaut0 payload has no row for BSC source EID 30102 to Conflux destination EID 30212, and no row for Conflux source EID 30212 to BSC destination EID 30102.

This is not an unsupported route. Live peer checks returned true for BSC XAUT0 recognizing Conflux and for Conflux XAUT0 recognizing BSC. After replaying all submitted Safe calldata on local forks, the BSC and Conflux fork tests both failed with assertion failed: 2 != 3. The failure happened after the expected confirmations matched, so the stale value is the required DVN count. BSC -> Conflux and Conflux -> BSC remain at two required DVNs while the other canary-updated XAUT0 routes move to three required DVNs.

If the batch is approved as-is, the XAUT0 BSC <-> Conflux peer pair will keep weaker pre-canary ULN requirements while the rest of the XAUT0 mesh is updated to include the canary DVN. That leaves one live peer pair inconsistent with the intended post-canary security model.

Add Safe calldata that updates both missing XAUT0 ULN configs before approving or executing the batch: BSC source EID 30102 to Conflux destination EID 30212, and Conflux source EID 30212 to BSC destination EID 30102.

The Hyperliquid TOKEN verifier rerun reached the real governance checks and failed only the Safe owner-set check. The TOKEN proxy owner and ProxyAdmin owner both point to the expected Safe, 0xb64a89ad247a2d691a728bb6822a85eedd7fc541, and the Safe threshold matches the expected value of 3. However, getOwners() does not match the verifier's expected signer set.

The expected owner set includes 0x1a6362ad64ccff5902d46d875b36e8798267d154, but that address is missing from the live Hyperliquid TOKEN Safe. The live Safe instead includes 0x00f6d2b4b69ce697f913da16a9d73283dc4c78f2, which is not part of the verifier's expected set for this check.

TOKEN/hyperliquid
Safe: 0xb64a89ad247a2d691a728bb6822a85eedd7fc541
Failed check: safe_owners
Missing owner: 0x1a6362ad64ccff5902d46d875b36e8798267d154
Extra owner:   0x00f6d2b4b69ce697f913da16a9d73283dc4c78f2

Confirm which signer set is intended for the Hyperliquid TOKEN Safe.

The local LayerZero config explicitly defines the Solana to TON XAUT0 connection with only two required DVNs: LayerZero Labs and USDT0. The live Solana state matches that documented configuration. This is not a live/config mismatch and it is not a missing-wiring issue: TON is already wired/configured with peer, nonce state, send/receive libraries, send/receive ULN configs, executor config, and enforced options.

The gap is that the current signer scope is described as a Canary DVN add for bringing Solana pathways online, but the scoped Squads bundle only upgrades Stable, BSC and Monad to the three-DVN set. TON remains a supported Solana pathway in layerzero-xaut0.config.ts, but proposals #47, #50 and #54-#66 do not target TON and therefore leave it on the documented two-DVN LayerZero + USDT0 configuration.

Clarify the intended TON policy before signers treat this bundle as complete Canary coverage for Solana-supported pathways. If TON should receive the same Canary quorum as Stable, BSC and Monad, add explicit Solana proposals to update the TON send ULN and receive ULN required DVNs and verify executor/enforced-options coverage. If TON is intentionally excluded, document that exclusion in the signer scope and local config comments so the two-DVN TON pathway is not mistaken for an omitted part of the Canary rollout.

The XAUT config defines MONAD_ENFORCED_OPTIONS with 240000 gas for send, sendAndCall lzReceive, and sendAndCall compose execution. The Solana to Monad connection uses those Monad-specific enforced options in the connection tuple.

Scoped Squads proposal #66 does not apply those values. It decodes to the generic EVM options used by Stable and BSC: send lzReceive gas 200000, sendAndCall lzReceive gas 100000 and sendAndCall compose gas 100000. The transaction simulation passes because the program accepts the values, but the resulting Solana XAUT0 Monad peer would not match the gas settings defined by layerzero-xaut0.config.ts.

Consequently, approving #66 as-is would configure the Monad route with lower enforced execution gas than the XAUT config specifies. If Monad requires the higher gas values encoded in MONAD_ENFORCED_OPTIONS, Solana-originated XAUT0 messages to Monad can be underfunded for destination execution.

Replace proposal #66 with a SetEnforcedOptions transaction that matches MONAD_ENFORCED_OPTIONS or update layerzero-xaut0.config.ts and the signer scope if the generic values are intentional for Solana to Monad. Re-run the Squads decode, exact simulation and post-safe-txs model after the replacement.