- reserve-verifier policy references for hard-peg eligible pairs
- required `maxOutstanding` policy per canonical token / destination chain
- public-pool exposure in token-aggregation
- pool routing eligibility in token-aggregation
- MCP visibility eligibility for public pools
The active overlay does **not** replace the existing universe/config files. It sits on top of them.
## Runtime readiness
The overlay now exposes two different readiness views through token-aggregation:
- **`eligible`**: the pair is structurally valid according to JSON policy, mappings, deployment status, and declared config refs.
- **`runtimeReady`**: the pair also has live bridge addresses, reserve-verifier refs, and required `maxOutstanding` values resolved in the current runtime environment.
This distinction matters operationally:
- A pair can be `eligible` but not `runtimeReady` if secrets or deploy-time env vars have not been loaded yet.
-`/api/v1/token-mapping/transport/active` reports both the structural pair data and summary counts such as `runtimeReadyTransportPairs`.
-`/api/v1/bridge/status` and `/api/v1/bridge/metrics` surface the same runtime-readiness view for operators.
-`/api/v1/bridge/preflight` focuses the output down to blocked pairs and the exact `runtimeMissingRequirements` / `eligibilityBlockers` that must be cleared.
Canonical `c*` on Chain 138 and mirrored `cW*` on public chains are tied together by the GRU transport bridge model (escrow / lock on L1, mint on L2; burn on L2, release on L1), implemented by `CWMultiTokenBridgeL1` / `CWMultiTokenBridgeL2` and `CompliantWrappedToken` with mint/burn roles. See [CW_HARD_PEG_DESIGN_CWUSDC_CWUSDT.md](../07-ccip/CW_HARD_PEG_DESIGN_CWUSDC_CWUSDT.md).
For each enabled canonical token, `enabledCanonicalTokens[].bridge` carries:
-`canonicalAssetVersion`: `v1` or `v2` — which compliant native contract L1 escrows.
-`mirroredAssetVersion`: `v1` or `v2` — which `cW*` contract L2 mints/burns.
`config/token-mapping-multichain.json` section **`gruIso4217Bridge`** holds Chain 138 addresses per `Compliant_*_cW` mapping key and optional **`mirroredV2ByMappingKeyAndChain`** (per destination `chainId`). `config/token-mapping-loader.cjs` resolves `canonicalAddress` / `mirroredAddress` for `getActiveTransportPairs()` from these settings. Defaults remain **v1/v1** until you deploy `cW*` v2 on each destination, fill non-null mirrored v2 addresses, update `cross-chain-pmm-lps/config/deployment-status.json``cwTokens`, register supported tokens on the live L1/L2 bridge contracts, then flip both versions to `v2`.
-`cUSDW -> cWUSDW` is already modeled in `config/token-mapping-multichain.json`, but it is **not yet an enabled canonical token** in this active overlay. Treat it as staged until the wrap-vault and transport activation steps are completed.
