Files

defiQUG 7ac74f432b chore: sync docs, config schemas, scripts, and meta task alignment

- 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

2026-03-31 22:31:39 -07:00

4.6 KiB

Raw Blame History

GRU Transport Active JSON

Purpose: Define the active-policy overlay for the GRU Monetary Transport Layer.

File

Config: config/gru-transport-active.json
Standards profile: 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 Holds the full mapping universe for canonical c*, native public assets, and mirrored cW*.
config/routing-registry.json Holds the broader route-topology registry, including legacy WETH routes.
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 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:

The canonical token is enabled in gru-transport-active.json.
The destination chain is enabled in gru-transport-active.json.
The pair exists in token-mapping-multichain.json.
The mirrored cW* token is deployed in deployment-status.json.
The approved bridge peer is present in gru-transport-active.json.
A maxOutstanding policy reference is set for the pair.
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:

a multichain mapping exists
the cW* deployment is non-zero
bridgeAvailable is true
the chain is explicitly enabled here

Public pools

Public pools remain chain-local edge pools, not literal cross-chain pools.

Operators should:

Deploy the pool.
Record the pool address in deployment-status.json.
Mark the pool active in gru-transport-active.json.
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

4.6 KiB Raw Blame History