GRU Storage, Governance, and Supervision Standard

Purpose: Define the canonical storage and governance metadata that every future GRU monetary asset, wrapped transport asset, base component, financial instrument, and tokenized asset must carry so upgrades, expansion, and jurisdictional supervision can be handled consistently.

Primary machine-readable profile: config/gru-governance-supervision-profile.json

Current implementation surface: CompliantFiatTokenV2.sol, CompliantWrappedToken.sol, UniversalAssetRegistry.sol, GovernanceController.sol

1. Required asset metadata

Every governed GRU asset should expose or be mirrored into the registry with:

assetId
assetVersionId
governanceProfileId
supervisionProfileId
storageNamespace
primaryJurisdiction
regulatoryDisclosureURI
reportingURI
canonicalUnderlyingAsset
supervisionRequired
governmentApprovalRequired
minimumUpgradeNoticePeriod

These fields are now implemented directly on the canonical c* V2 and cW* contracts and synchronized into the universal registry.

2. Storage namespace rules

Canonical c* assets use deterministic storage namespaces in the pattern gru.storage.asset.<symbol>.<version>.
Wrapped cW* transport assets use deterministic storage namespaces in the pattern gru.storage.transport.<symbol>.
Registry mirrors use deterministic storage namespaces in the pattern gru.storage.registry.<symbol>.
GRU Diamond control-plane storage continues to use deterministic facet namespaces such as grc.storage.monetary, grc.storage.gov, and related GRCStorage slots.

The rule is simple: metadata and policy state must be discoverable without relying on a symbol string alone.

3. Jurisdictional supervision model

The registry owns jurisdiction profiles and authority assignments.
A jurisdiction profile can define whether government approval is required, whether periodic reporting is expected, and the minimum upgrade notice period.
Authorities are assigned per jurisdiction with explicit permissions for governance approval, upgrade approval, pause authority, and reporting reception.
Asset registration pulls governance/supervision metadata from the token when available, then applies stronger jurisdiction defaults from the registry.
Normal token and registry metadata setters are executable only through the configured governance controller.
Emergency and manual admin paths remain available outside the controller through EMERGENCY_ADMIN_ROLE so bootstrap configuration, incident response, and regulator-directed intervention do not depend on an active proposal lifecycle.

This creates one place to express supervisory expectations without hardcoding a single legal regime into every token contract.

4. Governance execution model

Governance proposals are created per asset through GovernanceController.proposeForAsset.
The jurisdiction review id, review-required flag, and minimum notice period are derived from UniversalAssetRegistry state for that asset instead of being manually tagged afterward.
Jurisdiction-policy changes in the registry are executed through asset-derived registry entry points so the affected jurisdiction is still anchored to a concrete registered asset.
When the derived asset profile is jurisdiction-review-sensitive, a proposal cannot be queued until at least one authorized jurisdictional authority has approved it.
If a proposal changes an asset’s primary jurisdiction, it must collect approval from both the current jurisdiction and the destination jurisdiction before queueing.
The queue delay must respect the larger of:
- the proposal’s governance-mode timelock
- the asset’s derived minimum upgrade notice period, including stronger jurisdiction defaults from the registry
Asset-scoped proposals can only target:
- the asset contract itself
- registry calls whose scoped asset argument matches the proposal asset
- asset-derived registry jurisdiction entry points that resolve policy updates from that same proposal asset

This is now enforced in the shared governance controller, so “upgradeability” is not only a proxy question but also a policy and supervision workflow question.

5. Scope by asset family

Asset family	Storage/governance expectation
Canonical `c*`	Full metadata, disclosure, reporting, jurisdiction, supervision, and upgrade notice
Wrapped `cW*`	Same metadata discipline, plus canonical-underlying linkage and transport identity
GRU base components / registries	Upgradeable controller + registry storage, jurisdiction-aware proposal review where sensitive
Financial instruments / tokenized assets	Registry-backed metadata, explicit jurisdiction, reporting/disclosure URIs, policy profile IDs
Vault and reserve sidecars	Separate storage namespace; never overload canonical money-token storage

6. Recommendations

Migrate future flagship monetary assets toward upgradeable implementations only when the operational migration path and jurisdictional review flow are both documented and tested.
Require every production asset onboarding checklist to populate regulatoryDisclosureURI and reportingURI, even when the initial content is an attested placeholder.
Keep the registry as the operational source of truth for supervision metadata until the GRU M00 Diamond standards registry fully replaces or mirrors it.
Use asset-scoped proposals on any change to mint policy, burn policy, reserve thresholds, bridge permissions, metadata, upgrade targets, or pause authorities so the applicable jurisdiction is derived from the registered asset state.
Maintain multisig or institutional signer separation between protocol admins and jurisdictional authorities.

7. Verification

The current repo verifies this standard through focused Foundry suites:

Those suites are wired into the contract green-path verifier at check-cstar-v2-transport-stack.sh.

6.6 KiB Raw Blame History Unescape Escape