Governance Deep Dive
Governance Deep Dive
Authority Structure · Immutable vs Adjustable · Multi-Sig Execution · Proposal Lifecycle · Control 42 · Module-Aware
Complete governance architecture for the RWA Tokens platform — who can change what, how changes are authorized, what is permanently immutable, and how governance integrates with the 42 Transfer Hook security controls. The platform is operated by Groovy Company, Inc. (Wyoming domicile; principal office 600 W Peachtree St NW, Suite 1700, Atlanta, GA 30308; CIK 1499275; OTC: GROO). Governance covers all three production modules — Equities (Module 1), Real Estate (Module 2), and CORECM — Carbon Ore, Rare Earth, and Critical Minerals (Module 3) — with module-aware parameter scopes documented in each section. Written for institutional evaluators, auditors, regulators, and the executive team.
Table of Contents
Governance Philosophy
Why Not Token-Based DAO Governance
Immutable Parameters — What Cannot Be Changed
Adjustable Parameters — What Can Be Changed
Corporate Governance Layer
Multi-Sig Architecture
Timelock Mechanism
Proposal Types and Lifecycle
Parameter Adjustment Flow
Smart Contract Upgrade Protocol
Control 42 — Regulatory Compliance Freeze
Pool Governance
Governance Boundaries Diagram
Emergency Response Governance
Transparency and Reporting
Module-Aware Governance Surface
Governance FAQ
On-Chain Verification
1. Governance Philosophy
The platform's governance reflects a single principle: parameters that protect investors must be structurally impossible to change, while parameters that affect platform economics must be adjustable within defined bounds by accountable human decision-makers operating under identified security controls. This principle applies uniformly to Module 1, Module 2, and Module 3 — module-specific parameters follow the same immutable-versus-adjustable discipline as cross-module parameters.
This produces a two-tier architecture:
The Institutional Question
For an institutional investor or regulator reviewing the platform, the question is not "who controls governance?" — it is "what is the worst case if governance fails or is compromised?"
An immutable security control has no worst case: it cannot be compromised because it cannot be changed. Every governance mechanism — however well designed — introduces a pathway through which protections could theoretically be weakened. Removing that pathway entirely is the strongest institutional assurance available. This applies equally to the Module 2 NAV-deviation enforcement and the Module 3 federal-action freeze coordination — both are immutable extensions of the 42 controls, governable only through the same supermajority program-upgrade procedure that protects every other control.
2. Why Not Token-Based DAO Governance
The platform deliberately rejects anonymous token-based DAO governance for security-critical decisions. This applies uniformly to Module 1, Module 2, and Module 3.
Accountability
Anonymous token holders — no legal identity
Named officers, sole director, SEC-reporting entity (CIK: 1499275)
Legal standing
Ambiguous — DAOs face SEC scrutiny
Clear — Wyoming corporation with identified officers
Securities risk
Governance token may itself be a security
No governance token exposure — GROO is utility only
Attack surface
Flash loan governance attacks, whale accumulation
Multi-sig with geographically distributed key holders
Audit trail
On-chain votes (pseudonymous)
Board resolutions + on-chain multi-sig + SEC filings
Speed
Days–weeks for voting period
48h timelock (standard) or immediate (emergency)
Investor protection
Majority can vote to weaken protections
42 controls are immutable — governance cannot weaken them
GROO staking provides platform utility (fee discounts, AI Module access including Module 1 / 2 / 3 IDOS pipelines, staking rewards) — not governance voting power over security-critical parameters. Protocol governance is corporate governance: transparent, accountable, and subject to securities law.
3. Immutable Parameters — What Cannot Be Changed
These parameters are embedded in the platform's immutable on-chain programs. No corporate resolution, no multi-sig execution, no legal process, and no technical action can modify them without deploying an entirely new smart-contract program — which would require investors to migrate to a new token, breaking the existing custody and ownership chain. The same immutability discipline applies to every module.
3.1 Cross-Module Immutable Parameters
42 Transfer Hook security controls
Immutable — on-chain program
Core investor protection — no pathway to weaken
1:1 token-to-asset backing (Controls CV-01 to CV-06)
Immutable
Any relaxation would allow unbacked token creation
LP token burn (Global Pool)
Immutable — pool contract
No withdrawal function exists in bytecode
Pool program upgrade authority
None — program is immutable
Liquidity pool cannot be upgraded, only migrated under emergency protocol
OFAC / SDN screening per transfer (Controls SC-30 to SC-34)
Immutable
Federal sanctions compliance — cannot be disabled
AML risk scoring per transfer (Control IV-09)
Immutable
BSA compliance — cannot be disabled
Accreditation verification per transfer (Controls IV-07 / IV-08)
Immutable
Reg D / Reg S / Reg CF compliance — cannot be disabled
Reg D / Reg S / Reg CF holding periods (Control HP-24)
Immutable
Statutory minimum — cannot be shortened (Reg D 6mo / Reg S 12mo / Reg CF 12mo)
5% total transaction fee rate
Immutable — Token-2022 Transfer Fee Extension
Configured at mint creation — cannot be changed post-mint
2% staking reinvestment to Global Pool
Immutable — hardcoded in Transfer Hook
LP_REINVESTMENT_BPS is a program constant — not configurable
4.99% wallet concentration default ceiling (Control PL-16)
Immutable as program constant
Anti-manipulation ceiling — Module 2 may be issuer-configured up to 9.99% within program-defined upper bound (no governance can exceed the upper bound)
Transfer Hook address on each mint
Immutable — SPL Token-2022 standard
Set at mint creation — permanently stored in mint account
3.2 Module 2 — Real Estate Immutable Parameters
NAV-deviation circuit-breaker enforcement (CB-21 extension)
Immutable as a control mechanism
Cannot be disabled by governance; only the deviation tolerance bounds are adjustable
NAV oracle Ed25519 signature requirement
Immutable
Appraisals must be signed by an authorized appraiser; governance cannot waive
Single-asset entity backing requirement
Immutable
Each Module 2 mint must back a single-asset entity holding the underlying property
3.3 Module 3 — CORECM Immutable Parameters
Federal-action freeze coordination (REG-42 extension)
Immutable as a control mechanism
Cannot be disabled by governance; only the freeze enablement toggle (per mint) is adjustable, and it defaults to enabled
Classification oracle Ed25519 signature requirement
Immutable
Federal-action attestations must be signed by the Classification relay authority
Basin-asset entity backing requirement
Immutable
Each Module 3 mint must back a basin-asset entity holding the underlying mineral basin or concession
60-minute federal-action freeze SLA
Immutable as an operational requirement
Documented in the Incident Response Playbook §13; governance cannot extend
What "Immutable" Means Technically
These parameters exist in the deployed on-chain program binary. The Liquidity Pool program has no upgrade authority — solana program show <POOL_ID> returns Authority: none. The Transfer Hook program has a 5-of-9 upgrade authority, but any upgrade must preserve all 42 controls (enforced by audit attestation requirement and Certora invariant E.4) and cannot modify hardcoded constants like LP_REINVESTMENT_BPS or the holding-period seconds for any of the three exemption regimes. The same holds for the Module 2 NAV-deviation enforcement and the Module 3 federal-action freeze coordination — these are control extensions written into Transfer Hook bytecode that cannot be removed by any upgrade.
4. Adjustable Parameters — What Can Be Changed
These parameters may be adjusted within defined bounds. All adjustments require multi-sig execution and a 48-hour on-chain timelock. No parameter can be adjusted outside its range in a single governance action — preventing incremental boundary erosion. Module-specific parameters follow the same governance discipline as cross-module parameters.
4.1 Cross-Module Adjustable Parameters
TWAP calculation window
30 minutes
15–60 minutes
3-of-5
48 hours
All modules
Maximum price impact per trade
2%
1–5%
3-of-5
48 hours
All modules
Fee distribution ratios
200 / 150 / 106 / 44 bps
Max 10% shift per action
3-of-5
48 hours
All modules
Circuit breaker cooldown
24 hours
12–72 hours
3-of-5
48 hours
All modules
AML enhanced review threshold
Score 31
25–45
3-of-5
48 hours
All modules
TWAP outlier rejection sigma
3σ
2–5σ
3-of-5
48 hours
All modules
4.2 Module 2 Adjustable Parameters
nav_deviation_max_bps
Per mint, typically 2200 (22%)
Per-mint range set at issuance under tripartite agreement
3-of-5
48 hours
Adjustments require issuer concurrence under tripartite
nav_reappraisal_max_age_secs
Per mint, per tripartite cadence
Per-mint range set at issuance
3-of-5
48 hours
Tied to the property's reappraisal schedule
nav_circuit_breaker_enabled
true
true / false
5-of-9
48 hours
Disabling requires elevated threshold; default is enabled
4.3 Module 3 Adjustable Parameters
classification_max_age_secs
Per mint, typically 86,400 (24h)
Per-mint range set at issuance
3-of-5
48 hours
Stricter values require closer Classification oracle monitoring
federal_action_freeze_enabled
true
true / false
5-of-9
48 hours
Disabling requires elevated threshold; default is enabled and routinely retained
Bounds Are Hard Limits
Each adjustable parameter has a hard-coded minimum and maximum. A governance proposal to set the TWAP window to 5 minutes (below the 15-minute minimum) is rejected by the smart contract — not by policy, but by code. A governance proposal to set nav_deviation_max_bps outside the per-mint range registered at issuance is rejected by the smart contract. If market conditions require a parameter to move beyond its range, a full program upgrade is required (see §10).
Maximum Rate of Change
No single governance action can shift a parameter by more than the defined step size. For fee distribution ratios, the maximum shift is 10% per proposal. Moving from the current 200/150/106/44 split to a hypothetical 250/150/56/44 split (a 25% shift in the issuer allocation) would require three separate governance actions across three timelock periods — a minimum of 6+ days. The same step-size discipline applies to module-specific parameters.
5. Corporate Governance Layer
All material protocol decisions originate at the corporate governance level of Groovy Company, Inc. This is not a decentralized protocol with anonymous governance — it is a public company (CIK: 1499275; OTC: GROO) with named officers and board-level accountability. The corporate governance layer is module-agnostic — the same officers, the same authority hierarchy, and the same decision flow apply to Module 1, Module 2, and Module 3 actions.
Authority Hierarchy
Decision Flow
6. Multi-Sig Architecture
Every on-chain governance action requires multi-signature authorization. No single individual — regardless of title or authority — can unilaterally modify any platform parameter. The same multi-sig architecture serves Module 1, Module 2, and Module 3 actions.
Multi-Sig Wallets
Upgrade Authority
5-of-9
Geographically distributed across 5+ jurisdictions
Transfer Hook, AMM, Oracle Aggregator program upgrades — affecting all modules
Parameter Authority
3-of-5
Authorized officers + designated key holders
Fee ratios, thresholds, cooldowns, module-specific NAV / classification parameters
Emergency Authority
3-of-5 + Legal Counsel
Same as Parameter + Legal Counsel authorization
Control 42 regulatory freeze, including Module 3 federal-action freeze coordination
Signer Rules
No signer holds more than one position in any quorum
Policy + verification at key registration
Key holders are geographically distributed
Minimum 3 jurisdictions for 5-of-9
Keys stored on Ledger Enterprise HSMs
Hardware security modules — not software wallets
Key rotation follows the same threshold as authorized actions
Rotating a 5-of-9 key requires 5-of-9 approval
New signers require board resolution
Corporate governance gate
Why 5-of-9 for Upgrades
Program upgrades modify executable code. The elevated threshold (5-of-9 versus 3-of-5 for parameters) reflects the elevated risk: a malicious upgrade could theoretically weaken compliance controls — including the Module 2 NAV-deviation enforcement and the Module 3 federal-action freeze coordination. The 5-of-9 requirement means an attacker would need to compromise 5 geographically distributed HSM-backed keys simultaneously — while also passing an independent security audit attestation requirement and Certora invariant E.4 verification.
7. Timelock Mechanism
Every non-emergency governance action is subject to an on-chain timelock — a mandatory waiting period between authorization and execution. During the timelock, the pending action is visible on chain and can be inspected by anyone. The timelock applies uniformly across modules — a Module 2 NAV-bound adjustment goes through the same 48-hour observation window as a cross-module TWAP adjustment.
Timelock Configuration
Parameter adjustment
48 hours
2-of-5 during window
Allow observation, review, and intervention
All modules
Module-specific parameter adjustment (Module 2 / Module 3)
48 hours
2-of-5 during window
Same — module-specific changes follow standard discipline
Module 2 / Module 3
Program upgrade
48 hours
2-of-5 during window
Same + independent security review time
All modules
Emergency circuit breaker
None — immediate
N/A
Time-critical — active exploit or regulatory order
All modules
Control 42 freeze (cross-module)
None — immediate
Same process to unfreeze (Legal Counsel + 3-of-5)
Legal compliance — cannot delay court orders
All modules
Control 42 freeze (Module 3 federal-action)
None — 60-minute SLA
Same process to lift after federal action resolves
Federal action requires immediate response
Module 3
Emergency pool migration
48 hours
2-of-5 during window
Catastrophic vulnerability only — still requires observation
All modules
Timelock Lifecycle
Cancellation
During the timelock window, 2-of-5 multi-sig holders can cancel a pending action. This serves as a safeguard — if the community, an auditor, or Legal Counsel identifies an issue with a pending governance action, it can be stopped before activation. The 2-of-5 cancellation threshold is deliberately lower than the execution threshold (3-of-5 or 5-of-9) to make it easier to stop a bad action than to execute one. The cancellation discipline applies uniformly to cross-module and module-specific actions.
8. Proposal Types and Lifecycle
Three Proposal Types
ParameterAdjustment
3-of-5
48 hours
Written record of approving authority
TWAP window, price impact, fee ratios, cooldowns; Module 2 NAV bounds; Module 3 classification age
All modules
ProgramUpgrade
5-of-9
48 hours
Security audit attestation + board resolution + schema compatibility proof + Certora E.4 verification
Transfer Hook patch, AMM update, Oracle Aggregator update
All modules
EmergencyAction
3-of-5 + Legal Counsel (for Control 42) or IC authority (for circuit breaker)
None — immediate
P0 incident declaration or legal process documentation
Regulatory freeze (including Module 3 federal-action), active exploit containment
All modules
Proposal Lifecycle — ParameterAdjustment
Proposal Lifecycle — ProgramUpgrade
9. Parameter Adjustment Flow
Worked Example A — Adjusting TWAP Window (Cross-Module)
Scenario. Market analysis shows a 45-minute TWAP window would provide more stable circuit-breaker reference pricing across all modules.
Worked Example B — Tightening Module 2 NAV Deviation
Scenario. A specific Module 2 mint shows a pattern of price drift narrower than the default 22% deviation tolerance; the issuer and platform agree to tighten the bound to 2000 bps (20%) under tripartite concurrence.
Rejection Example — Out-of-Bounds
The same out-of-bounds rejection applies to module-specific parameters. A proposal to set nav_deviation_max_bps outside the per-mint range registered at issuance, or to set classification_max_age_secs to a value outside the per-mint range, is rejected at the program level.
10. Smart Contract Upgrade Protocol
Program upgrades are the most sensitive governance action — they modify the executable code that enforces compliance on every ST22 transfer across all three modules.
Upgrade Requirements (ALL must be satisfied)
Security audit attestation
Confirm no new vulnerabilities
Quantstamp, Halborn, or OtterSec
42-control preservation attestation
Confirm no control weakened or removed
Audit firm
Module-aware preservation attestation
Confirm Module 2 NAV-deviation and Module 3 federal-action freeze coordination preserved
Audit firm
Account schema compatibility
New version handles all existing account schemas via migrate() — including module-specific PDAs (NAVOracle, ClassificationOracle)
Audit firm
Certora invariant E.4 verification
Formal-verification proof of control preservation
Certora Prover
Board resolution
Corporate governance approval
Board of Directors
CTO approval
Technical authority sign-off
CTO (Frank Yglesias)
5-of-9 multi-sig
On-chain execution authorization
5 of 9 geographically distributed signers
48-hour timelock
Public observation window
On-chain timelock contract
Upgrade Governance Flow
1
Upgrade proposal drafted with full diff and rationale
Engineering team (Jhony Navarro lead)
Prior to submission
2
Independent security audit
Quantstamp / Halborn / OtterSec
7–14 days
3
Audit attestation received
Auditing firm
On completion
4
Certora E.4 verification
Certora Prover
On audit completion
5
Board resolution approving upgrade
Board of Directors
Before submission
6
CTO technical approval
CTO
Before submission
7
5-of-9 multi-sig executes proposal on chain
Authorized signers
After approvals
8
48-hour timelock begins
On-chain timelock
Automatic
9
Upgrade activates
On-chain timelock
After 48 hours
10
Post-upgrade verification (42 controls + module-aware extensions, Certora)
Engineering + audit
Within 24 hours
What An Upgrade Cannot Do
Even with a valid 5-of-9 multi-sig execution, a program upgrade cannot:
Remove any of the 42 Transfer Hook controls
Audit attestation requirement; Certora invariant E.4
Remove the Module 2 NAV-deviation enforcement
Audit attestation; Certora E.4
Remove the Module 3 federal-action freeze coordination
Audit attestation; Certora E.4
Reduce holding period below statutory minimum
Hardcoded constants — Reg D 6mo / Reg S 12mo / Reg CF 12mo
Raise wallet concentration above the program-defined upper bound (9.99%)
Hardcoded ceiling
Add a withdrawal function to the Pool program
Pool program has no upgrade authority — immutable
Disable OFAC screening
Hardcoded in Controls SC-30 to SC-34
Create admin override for token transfers
Transfer Hook architecture has no forceTransfer() equivalent
11. Control 42 — Regulatory Compliance Freeze
Control 42 is the only mechanism by which specific wallets or token mints can be frozen outside the standard 42-control validation path. It is a targeted legal compliance tool — not a general administrative override. Control 42 covers all three modules with a Module 3 federal-action variant documented below.
11.1 Activation — Cross-Module (Standard Control 42)
1
Receive formal legal process (court order, SEC enforcement, law-enforcement request)
Incoming to Legal Counsel
2
Legal Counsel reviews and authorizes — confirms process is valid and scope is appropriate
Legal Counsel
3
3-of-5 multi-sig executes targeted freeze
Authorized signers (immediate — no timelock)
4
Immutable on-chain record created
Automatic
5
Affected parties notified per legal process requirements
Compliance team
6
Ongoing reporting to requesting authority
Legal Counsel + Compliance
11.2 Activation — Module 3 Federal-Action Variant
For Module 3 mints, a federal action detected by the Classification oracle (USGS / DOE / Federal Register / DOD) automatically initiates Control 42 coordination per the Incident Response Playbook §13:
1
Federal action detected by Classification relay
Classification oracle (P0 event)
5-min cadence
2
P0 incident raised; PagerDuty alert; multi-sig holders notified
Operations + Legal Counsel
Within minutes
3
Legal Counsel confirms federal-action scope and applicability
Legal Counsel
Within 30 min
4
3-of-5 emergency multi-sig executes Control 42 freeze
Authorized signers
Detection-to-freeze within 60 min
5
Immutable on-chain record created; FederalActionFreezeApplied event
Automatic
—
6
Affected issuer and investors notified
Compliance team + Empire
Within 4 hours
The 60-minute detection-to-freeze SLA is an immutable operational requirement — governance can shorten it but cannot extend it.
11.3 Scope and Limits
Targeted only
Can freeze a specific wallet or specific mint — cannot disable the 42 controls globally
Legal process required
Court order, SEC enforcement, law-enforcement request, or detected federal action (Module 3) — reviewed by Legal Counsel
Audit trail
Every activation creates immutable on-chain record (timestamp, authority, affected addresses)
Reversible
Lifted through same Legal Counsel + 3-of-5 process upon legal resolution
Not an admin override
Cannot waive holding periods, accreditation, OFAC screening, or any investor protection
No timelock
Immediate (cross-module) or within 60-min SLA (Module 3 federal-action)
11.4 What Control 42 Cannot Do
Move tokens without holder consent
No forceTransfer() function exists
Waive holding period
Control HP-24 is immutable; Control 42 freezes transfers, it does not unlock them. Reg D / Reg S / Reg CF regimes preserved
Bypass OFAC screening
Controls SC-30 through SC-34 execute independently
Unfreeze without Legal Counsel
Legal authorization required for both freeze and unfreeze
Freeze the Global Pool itself
Pool is a program, not a wallet — Control 42 targets wallets and mints
Disable the Module 3 federal-action freeze coordination
Coordination mechanism is immutable; only the per-mint enablement toggle is adjustable
12. Pool Governance
The Global Unified CEDEX Liquidity Pool has its own governance boundary — most pool properties are immutable, with only specific operational parameters adjustable. The Global Pool is module-agnostic by design — Module 1, Module 2, and Module 3 fee deposits all route to the same shared pool.
Governable (Adjustable)
Fee distribution ratios
3-of-5 + 48h timelock
Max 10% shift per action
All modules
New ST22 token routing
Governance approval
New mints must pass verification including module-specific oracle initialization
All modules
Circuit breaker thresholds
3-of-5 + 48h timelock
Within defined safety bounds
All modules
Non-Governable (Immutable)
Permanent lock
LP tokens burned — no withdrawal path
Cannot be overridden without full contract migration under emergency protocol
2% staking reinvestment
Hardcoded program constant
Not modifiable by any governance action
Capital withdrawal
No withdrawal function in bytecode
Governance cannot create one without program migration
GROO graduation migration
Automatic transfer of bonding-curve SOL
Cannot be disabled
Pool program upgrade
No upgrade authority
Authority: none — program is permanently immutable
Cross-module fee aggregation
Pool aggregates Module 1 / 2 / 3 fees uniformly
Cannot be partitioned by module
Emergency Pool Migration
In the catastrophic event of a vulnerability in the pool contract requiring migration to a new contract, the emergency override protocol applies:
Threshold
5-of-9 multi-sig
Timelock
48 hours (even in emergency)
Audit
Independent security audit of destination contract
Legal
Legal Counsel approval
Destination restriction
Can only migrate to a contract that preserves permanent lock
Disclosure
Full public disclosure before timelock expires
This has never been activated. The pool contract was formally verified by Certora Prover (invariant E.3 — Global Pool non-extractability) prior to deployment.
13. Governance Boundaries Diagram
14. Emergency Response Governance
During a declared incident (P0 or P1), governance authority shifts to the Incident Commander. See the Incident Response Playbook for full details. The IC primary is Frank Yglesias (Chairman / CTO); IC secondary is Patrick Mokros (COO).
Emergency Decision Authority
Activate Control 42 (regulatory freeze, cross-module)
Legal Counsel + 3-of-5 multi-sig
Legal-process documentation
None — immediate
All modules
Activate Control 42 (Module 3 federal-action variant)
Legal Counsel + 3-of-5 multi-sig
Federal-action detection by Classification oracle
None — 60-min SLA
Module 3
Activate emergency circuit breaker
IC + 3-of-5 multi-sig
P0 incident declaration
None — immediate
All modules
Emergency program upgrade
IC + 5-of-9 multi-sig
Post-hoc Certora re-verification
48 hours (even in emergency)
All modules
Emergency key rotation
IC + same threshold as key being rotated
Post-hoc audit
Per action type
All modules
Emergency Escalation Levels
Level 1 — Pause
Pause new transactions only. Existing positions preserved.
CTO
Yes
All modules; can be scoped to specific mint or specific module
Level 2 — Freeze
Freeze all operations. All positions frozen.
Chairman / CTO + COO
Yes
All modules; can be scoped per module
Level 3 — Rollback
Revert to last verified good state. Positions restored from snapshot.
Full Board (sole director under board resolution)
No — requires board resolution
All modules
15. Transparency and Reporting
On-Chain Transparency
Every governance action is permanently recorded on the Solana blockchain. Module-specific actions emit module-aware events.
Parameter change
Timestamp, parameter name, old value, new value, multi-sig signatures
Public — Solana ledger
All modules
Module-specific parameter change
Same as above + affected mint identifier
Public — Solana ledger
Module 2 / Module 3
Program upgrade
Timestamp, old program hash, new program hash, audit attestation hash
Public — Solana ledger
All modules
Control 42 freeze
Timestamp, affected addresses, legal authority cited
Public — Solana ledger
All modules
Module 3 federal-action freeze
Same + classification reference (e.g., EO-14118)
Public — Solana ledger
Module 3
Emergency action
Timestamp, action type, authorizing signatures
Public — Solana ledger
All modules
Off-Chain Disclosure
SEC
EDGAR filing (8-K for material changes)
Per SEC reporting requirements
Issuers
Direct notification
Within 48 hours of any parameter change affecting their token (cross-module or module-specific)
Investors
Empire Stock Transfer communication channel
Within 48 hours of changes affecting transfer restrictions, fees, or holding periods
Public
Status page (status.cedex.market)
Real-time for operational changes
Legal Counsel Gate
Legal Counsel reviews all governance actions with potential securities-law implications before execution — not as a rubber stamp, but as an active legal-compliance gate. This applies to:
Any fee structure modification.
Any parameter change affecting investor transfer restrictions (cross-module or module-specific).
All program upgrades.
All Control 42 activations (including Module 3 federal-action variants).
Any governance action that would be disclosed in SEC filings.
16. Module-Aware Governance Surface
This section consolidates the module-specific governance surface — the same surface threaded through each section above.
16.1 Module 1 — Equities
Adjustable parameters. All cross-module adjustables (TWAP window, price impact, fee ratios, circuit-breaker cooldowns, AML threshold, TWAP sigma).
Module-specific governance surface. None beyond cross-module — Module 1 mints use the standard SecurityConfig without module-specific extensions.
Control 42 path. Cross-module standard path. SEC enforcement, court order, or law-enforcement request initiated through Legal Counsel.
16.2 Module 2 — Real Estate
Adjustable parameters. All cross-module adjustables plus nav_deviation_max_bps, nav_reappraisal_max_age_secs, nav_circuit_breaker_enabled (per mint, with tripartite concurrence required for NAV-bound adjustments).
Module-specific governance surface. NAV-bound adjustments must be made under tripartite concurrence (issuer + Empire + Groovy Company, Inc.). Disabling the NAV circuit breaker requires the elevated 5-of-9 threshold and is rarely contemplated.
Control 42 path. Cross-module standard path. Module 2 has no automatic federal-action variant — but legal process directed at the underlying real-property asset (lis pendens, foreclosure injunction, environmental hold) routes through standard Control 42.
16.3 Module 3 — CORECM
Adjustable parameters. All cross-module adjustables plus classification_max_age_secs, federal_action_freeze_enabled (per mint).
Module-specific governance surface. Disabling federal_action_freeze_enabled requires the elevated 5-of-9 threshold and is generally not contemplated — the default is enabled and operationally retained.
Control 42 path. Cross-module standard path PLUS the Module 3 federal-action variant: federal actions detected by the Classification oracle (USGS / DOE / Federal Register / DOD) initiate automatic Control 42 coordination with a 60-minute detection-to-freeze SLA. The federal-action variant is the most time-sensitive emergency path in the platform.
16.4 Cross-Module Governance Properties
The following governance properties are identical across all three modules:
The same 5-of-9 multi-sig executes program upgrades affecting any module.
The same 3-of-5 multi-sig executes parameter adjustments — cross-module or module-specific.
The same 48-hour timelock applies to non-emergency module-specific changes.
The same Legal Counsel review gates Control 42 activations regardless of module.
The same audit attestation and Certora E.4 verification protect controls across modules.
Empire Stock Transfer is the sole §17A custodian and sole onboarding authority for every issuance regardless of module.
17. Governance FAQ
Can the platform change the 5% fee?
The total 5% fee rate is immutable — it is set at mint creation via the Token-2022 Transfer Fee Extension and cannot be changed after the mint exists. The distribution ratios within the 5% (currently 200/150/106/44 bps) can be adjusted via governance, subject to 3-of-5 multi-sig, 48-hour timelock, and a maximum 10% shift per proposal. This applies uniformly to Module 1, Module 2, and Module 3.
Can the platform move my tokens?
No. There is no forceTransfer() function in the ST22 architecture. Control 42 can freeze transfers on a mint (halt all trading), but it cannot move tokens from one wallet to another. Only the wallet holder can initiate a transfer. Same answer regardless of module.
Can the platform shorten the holding period?
No. The Reg D (6-month), Reg S (12-month), and Reg CF (12-month) holding periods are hardcoded constants in the Transfer Hook program. They are immutable — governance cannot reduce them below statutory minimums.
What happens if all 9 multi-sig keys are compromised?
An attacker with 5-of-9 keys could submit a program upgrade — but the 48-hour timelock makes the upgrade publicly visible, and 2-of-5 can cancel it during the window. The attacker would also need a valid security audit attestation from Quantstamp, Halborn, or OtterSec — which requires social-engineering an audit firm — plus passing Certora invariant E.4 verification, which would reject any upgrade that weakens the 42 controls or the Module 2 / Module 3 control extensions. Even a successful malicious upgrade cannot modify hardcoded immutable constants or add functions to the immutable pool program.
Who are the multi-sig key holders?
Key holders are not publicly named (operational security). They are geographically distributed across 5+ jurisdictions, use Ledger Enterprise HSMs, and no individual holds more than one signing position in any quorum. The board has a complete registry.
Can an upgrade remove the Transfer Hook?
No. The Transfer Hook address is stored in the mint account by SPL Token-2022 — it is a property of the token standard, not the platform's program. Even if the platform's Transfer Hook program were somehow replaced with a no-op program (which the audit attestation and Certora E.4 prevent), the Token-2022 program would still invoke the hook address on every transfer.
Can governance disable the Module 2 NAV-deviation circuit breaker?
The circuit-breaker mechanism itself is immutable — it cannot be removed. The per-mint enablement toggle (nav_circuit_breaker_enabled) can be flipped only with the elevated 5-of-9 threshold plus 48-hour timelock plus board resolution. In practice this has never been done; the default is enabled and retained.
Can governance disable the Module 3 federal-action freeze coordination?
The coordination mechanism itself is immutable. The per-mint enablement toggle (federal_action_freeze_enabled) can be flipped only with the elevated 5-of-9 threshold plus 48-hour timelock plus board resolution. The default is enabled and operationally retained — disabling it would expose the platform to federal regulatory action without automated coordination, which Legal Counsel does not currently contemplate.
Can a single Module 3 federal-action freeze affect Module 1 or Module 2 mints?
No. Control 42 is targeted — a Module 3 federal-action freeze affects the specific Module 3 mint(s) referenced by the federal action. Other Module 3 mints, all Module 1 mints, and all Module 2 mints are unaffected. A federal action that simultaneously references multiple Module 3 basins can affect multiple Module 3 mints, but the freeze remains scoped to the affected mints — never platform-wide.
18. On-Chain Verification
Verify Program Upgrade Authorities
Verify Pending Governance Actions
Verify Module-Specific Governance Actions
Verify Governance Event History
Related Documentation
Architecture Decisions — ADR-003 (Global Pool permanence), ADR-004 (LP burned), module-specific architectural rationales.
Security Model — Multi-sig key management, threat model, module-specific threat surfaces.
Incident Response Playbook — Emergency governance procedures including Module 3 federal-action freeze runbook (§13).
Smart Contract Reference — Governance program instructions, module-aware program behavior, Certora invariants.
Network Configuration — Multi-sig addresses, program authorities, oracle PDAs across modules.
Compliance Integration Guide — Control 42 regulatory context, module-specific compliance, federal-action coordination.
Oracle Integration Guide — Custody, OFAC, AML, TWAP, EDGAR (Module 1), NAV (Module 2), Classification (Module 3) relay architecture.
Empire Stock Transfer Integration — Tripartite concurrence requirements for Module 2 NAV-bound adjustments.
RWA Tokens · Governance Deep Dive · Groovy Company, Inc.
Last updated
Was this helpful?