Investigate pinning devnet cannon-cli back to 2.23 to harmonize with cronos/mainnet

[arturbeg]

Background

Devnet currently uses @usecannon/cli@2.26.0 (aliased as @usecannon/cli-devnet in package.json so it can coexist with cronos/mainnet's @usecannon/cli@2.23.0). The 2.26 bump was introduced in #462 (April 11) alongside the perpOB devnet scaffolding.

The 3-version gap (2.23 → 2.24 → 2.25 → 2.26) brought along a behavior change in how the clone step caches module deployments. Result: dry-runs and incremental builds on devnet trigger phantom proxy upgrades that don't appear on cronos/mainnet.

What we observed

While running yarn reya_devnet:test (and a follow-up cannon ... build --dry-run --impersonate-all) on PR #472, the build re-deploys all modules behind OrdersGatewayRouter, PassivePerpRouter, and PeripheryRouter at fresh sequential-CREATE addresses on every build, and then calls upgradeTo(newRouterAddress) on those three proxies — even when nothing in the relevant TOMLs changed. CoreRouter is the only one that stays stable (cannon pulls it fully from registry cache).

Concrete diff between reya-devnet-omnibus:1.0.5@main (current devnet state, last deployed 5/12) and a fresh 1.0.6 dry-run on the same omnibus content:

Router	1.0.5 address	1.0.6 address
CoreRouter	0xe1775438…11a9d0	0xe1775438…11a9d0 ✅
OrdersGatewayRouter	0x280ce12a…125a0b	0x610178da…d40788
PassivePerpRouter	0x9b04bca7…f8dbc4a	0x3aa5ebb1…71443c
PeripheryRouter	0x86b92a06…6ef95f2	0x09635f64…58cebef

Build log evidence: under clone.reyaCoreRouter there are no Executing [deploy.X] lines, but under each of the other three clones, every module gets re-deployed:

Executing [clone.reyaOrdersGatewayRouter]...
  Executing [deploy.BatchExecutionModule]...
    ✔ Successfully deployed BatchExecutionModule
    Contract Address: 0xa513E6E4b...
  Executing [deploy.ConfigurationModule]...
  Executing [deploy.FillExecutionModule]...
  Executing [router.OrdersGatewayRouter]...
    ✔ Successfully deployed OrdersGatewayRouter
    Contract Address: 0x610178da...

Same pattern for PassivePerpRouter (8 modules) and PeripheryRouter (7 modules).

Why this matters

• Semantically the upgrade is a no-op (new routers have identical bytecode and ABI to the old ones — same package version pinned in [var.cannonClonePackages]), so deploys still produce a working system.
• But every devnet deploy now fires three Upgraded(implementation) events on real chain for proxies that didn't change, plus the gas cost of redeploying all the modules behind them (~38M gas overhead per deploy in the dry-run estimate).
• Reviewers reading the dry-run output get spooked — "why are you upgrading these proxies?" — which is exactly the question that surfaced this on #472.
• Indexers / off-chain services that cache implementation addresses behind the proxies will see the address change and need to refetch (cheap but noise).

Investigation needed

Before we can decide whether to pin devnet back to 2.23 (to harmonize with cronos/mainnet and eliminate the phantom upgrades), we need to know:

1. Which 2.26-only features the devnet introduction actually needs. #462 bumped the CLI but the commit message doesn't enumerate which features required 2.26 vs would have worked with 2.23. Candidates to check from the 2.23 → 2.26 changelog:
   • New factory.X.event / factory.X.arg semantics (used heavily in the new perpOB token TOMLs)
   • Changes to abi = "<%= JSON.stringify(...) %>" template handling
   • New dex_id_override-style env-var resolution
   • setMaxStaleDuration / setSpotMarketConfiguration ABI surface changes
2. What exactly changed in 2.24-2.26 about the clone step's module-redeploy behavior. Confirm whether it's a deliberate change in upstream cannon (with a docs/issue we can reference) or a regression we should report.
3. If we downgrade to 2.23, does the devnet omnibus actually still build cleanly? Try locally with the CLI swapped and see what breaks.

Proposed approach

1. Stash the CLI alias swap on a branch, run yarn reya_devnet:simulate to see what fails with 2.23.
2. For each failure, decide: is the feature load-bearing for perpOB devnet, or can we work around it?
3. If everything is workable: drop @usecannon/cli-devnet from package.json, point the reya_devnet:test / reya_devnet:simulate scripts at the 2.23 binary, document the rationale.
4. If 2.26 features are load-bearing: file an upstream cannon issue with the clone-step regression and live with the dry-run noise until upstream fixes it.

Out of scope

• Bumping cronos/mainnet to 2.26 to harmonize the other way — would surface the same phantom-upgrade pattern on production environments, which is undesirable.
• Anything that involves changing the routers' package pins in [var.cannonClonePackages] — those are deliberately stable.

References

• PR #462 — original 2.26 introduction (commit 4304b6d)
• PR #472 — surfaced this issue during devnet sRUSD spot market work; the dry-run output there shows the symptom in detail
• package.json lines defining @usecannon/cli / @usecannon/cli-devnet
• packages/tests/package.json reya_devnet:test script uses node_modules/@usecannon/cli-devnet/bin/cannon.js (2.26), reya_cronos:test and reya_network:test use node_modules/@usecannon/cli/bin/cannon.js (2.23)

cc anyone who worked on #462 and can quickly recall which 2.26-specific features were needed — that's the fastest path to closing this out.