Files

defiQUG dbd517b279 Sync workspace: config, docs, scripts, CI, operator rules, and submodule pointers.

- Update dbis_core, cross-chain-pmm-lps, explorer-monorepo, metamask-integration, pr-workspace/chains
- Omit embedded publish git dirs and empty placeholders from index

Made-with: Cursor

2026-04-12 06:12:20 -07:00

4.6 KiB

Raw Blame History

GRU V2 Chain 138 Readiness

Purpose: Turn the GRU c* V2 program into an operator-checked Chain 138 surface instead of leaving it as a standards-only plan.

Current Chain 138 V2 addresses

Asset	Address	Live state
`cUSDT V2`	`0x9FBfab33882Efe0038DAa608185718b772EE5660`	Deployed, bytecode present, active in `UniversalAssetRegistry` as `AssetType.GRU`, `forwardCanonical=true`, IPFS metadata wired
`cUSDC V2`	`0x219522c60e83dEe01FC5b0329d6fA8fD84b9D13d`	Deployed, bytecode present, active in `UniversalAssetRegistry` as `AssetType.GRU`, `forwardCanonical=true`, IPFS metadata wired

What the readiness checker proves

Run:

bash scripts/verify/check-gru-v2-chain138-readiness.sh

Optional:

RUN_LOCAL_TESTS=1 bash scripts/verify/check-gru-v2-chain138-readiness.sh
bash scripts/verify/check-gru-v2-chain138-readiness.sh --report-only

The checker verifies:

deployed bytecode exists on Chain 138 for cUSDT V2 and cUSDC V2
both assets are active in UniversalAssetRegistry
both assets are registered as AssetType.GRU
core V2 identity and signing surface works:
- name
- symbol
- versionTag
- currencyCode
- assetId
- assetVersionId
- DOMAIN_SEPARATOR
contract-linked metadata is populated:
- tokenURI
- tokenURI uses ipfs://...
rollout caveats are explicit:
- any selected V2 address with forwardCanonical=false is not ready
- any selected V2 address missing the governance / supervision metadata ABI is not ready
- any active GRU registry entry with no bytecode is reported as an orphaned registry artifact

Current status as of 2026-04-03

Green

CompliantFiatTokenV2Test passes locally.
Both V2 assets are deployed on Chain 138.
Both V2 assets are active in UniversalAssetRegistry.
Both V2 assets expose the core V2 identity and signing surface:
- name
- symbol
- versionTag
- currencyCode
- assetId
- assetVersionId
- DOMAIN_SEPARATOR

Remaining caveat

UniversalAssetRegistry still contains one orphaned GRU entry from the interrupted April 3, 2026 rollout: 0x9AA44008f30B7F6D2BfB74016420c5eA49c5ebE4 is marked active but has no bytecode.
The current registry implementation does not expose a public remove/deactivate path, so that orphan remains a cleanup item for a future controlled registry upgrade rather than an in-band token rollout step.

Meaning

Chain 138 now has live forward-canonical GRU V2 USD assets:

V2 addresses are real
V2 addresses are GRU-registered
V2 addresses are x402-signing-capable at the core token layer
V2 addresses are the forward-canonical GRU USD assets
live deployed bytecode matches the governance / supervision metadata surface expected by the latest GRU V2 source
the remaining issue is registry hygiene for the orphaned no-bytecode entry

Practical next steps

Keep cUSDT V2 and cUSDC V2 as the canonical GRU V2 USD pair on Chain 138.
Treat V1 cUSDT / cUSDC as legacy liquidity addresses until PMM, cW, and transport cutover is complete.
Preserve the IPFS metadata/disclosure/reporting bundle as the presentation source of truth for the active V2 pair.
Plan a controlled UniversalAssetRegistry upgrade if you want to remove the orphaned 0x9AA... GRU record instead of merely documenting it.
Continue the downstream cutover: explorer precedence, cW bridge mappings, pool migrations, and transport overlays.

Operator guidance

Use check-cstar-v2-transport-stack.sh for the predeploy contract/transport green path.
Use check-gru-v2-chain138-readiness.sh for the live Chain 138 promotion gate.
Do not treat cUSDT V2 / cUSDC V2 as canonical-forward GRU USD until the readiness checker returns zero blockers.

4.6 KiB Raw Blame History