7ac74f432b
- Institutional / JVMTM / reserve-provenance / GRU transport + standards JSON - Validation and verify scripts (Blockscout labels, x402, GRU preflight, P1 local path) - Wormhole wiring in AGENTS, MCP_SETUP, MASTER_INDEX, 04-configuration README - Meta docs, integration gaps, live verification log, architecture updates - CI validate-config workflow updates Operator/LAN items, submodule working trees, and public token-aggregation edge routes remain follow-up (see TODOS_CONSOLIDATED P1). Made-with: Cursor
105 lines
4.6 KiB
Markdown
105 lines
4.6 KiB
Markdown
# GRU Transport Active JSON
|
|
|
|
**Purpose:** Define the active-policy overlay for the **GRU Monetary Transport Layer**.
|
|
|
|
## File
|
|
|
|
- **Config:** [`config/gru-transport-active.json`](../../config/gru-transport-active.json)
|
|
- **Standards profile:** [`config/gru-standards-profile.json`](../../config/gru-standards-profile.json)
|
|
|
|
## What it gates
|
|
|
|
This file is the final activation gate for:
|
|
|
|
- enabled canonical `c*` assets on Chain 138
|
|
- enabled public destination chains for `cW*`
|
|
- approved `CWMultiTokenBridgeL1` / `CWMultiTokenBridgeL2` peers
|
|
- 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.
|
|
|
|
## Relationship to other JSONs
|
|
|
|
- [`config/token-mapping-multichain.json`](../../config/token-mapping-multichain.json)
|
|
Holds the full mapping universe for canonical `c*`, native public assets, and mirrored `cW*`.
|
|
- [`config/routing-registry.json`](../../config/routing-registry.json)
|
|
Holds the broader route-topology registry, including legacy WETH routes.
|
|
- [`cross-chain-pmm-lps/config/deployment-status.json`](../../cross-chain-pmm-lps/config/deployment-status.json)
|
|
Holds deployed `cW*` addresses and public PMM pool status.
|
|
- [`cross-chain-pmm-lps/config/pool-matrix.json`](../../cross-chain-pmm-lps/config/pool-matrix.json)
|
|
Defines the intended first local edge pools per chain.
|
|
|
|
## Activation model
|
|
|
|
An active GRU transport pair is only valid when all of the following agree:
|
|
|
|
1. The canonical token is enabled in `gru-transport-active.json`.
|
|
2. The destination chain is enabled in `gru-transport-active.json`.
|
|
3. The pair exists in `token-mapping-multichain.json`.
|
|
4. The mirrored `cW*` token is deployed in `deployment-status.json`.
|
|
5. The approved bridge peer is present in `gru-transport-active.json`.
|
|
6. A `maxOutstanding` policy reference is set for the pair.
|
|
7. Required reserve-verifier wiring references are present.
|
|
|
|
## Standard methodology
|
|
|
|
The repo now treats GRU Transport as the canonical standard for public-chain monetary transport:
|
|
|
|
- **Chain 138** keeps the canonical `c*` asset.
|
|
- A compatible public chain receives the mirrored **`cW*`** asset.
|
|
- The transport method is **lock canonical `c*` on 138, mint mirrored `cW*` on destination**.
|
|
- Local trading remains **chain-local edge pools**, not literal cross-chain pools.
|
|
- Legacy WETH bridge routes remain separate and are not part of GRU Transport.
|
|
|
|
Compatibility is intentionally strict. A destination chain belongs in this overlay only when:
|
|
|
|
1. a multichain mapping exists
|
|
2. the `cW*` deployment is non-zero
|
|
3. `bridgeAvailable` is true
|
|
4. the chain is explicitly enabled here
|
|
|
|
## Public pools
|
|
|
|
Public pools remain **chain-local edge pools**, not literal cross-chain pools.
|
|
|
|
Operators should:
|
|
|
|
1. Deploy the pool.
|
|
2. Record the pool address in `deployment-status.json`.
|
|
3. Mark the pool `active` in `gru-transport-active.json`.
|
|
4. Only then enable `routingEnabled` and/or `mcpVisible`.
|
|
|
|
Until a pool is marked active in the overlay, token-aggregation hides GRU `cW*` pools that touch mirrored assets on public chains.
|
|
|
|
## v1 defaults
|
|
|
|
The current overlay enables:
|
|
|
|
- canonical assets: `cUSDT`, `cUSDC`
|
|
- destination chains: `25`, `56`, `137`, `43114`, `42161`, `8453`, `10`, `100`, `1`
|
|
- transport form: **Compliant Wrapped ISO-4217 M1**
|
|
|
|
## Related
|
|
|
|
- [C_TO_CW_MAPPER_MAPPING.md](C_TO_CW_MAPPER_MAPPING.md)
|
|
- [CW_BRIDGE_APPROACH.md](../07-ccip/CW_BRIDGE_APPROACH.md)
|
|
- [CW_DEPLOY_AND_WIRE_RUNBOOK.md](../07-ccip/CW_DEPLOY_AND_WIRE_RUNBOOK.md)
|