> For the complete documentation index, see [llms.txt](https://bitbook.rwatokens.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://bitbook.rwatokens.net/ai-and-tokenomics/ai-and-tokenomics/governance-deep-dive.md). # 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 1. Governance Philosophy​ 2. Why Not Token-Based DAO Governance​ 3. ​Immutable Parameters — What Cannot Be Changed​ 4. ​Adjustable Parameters — What Can Be Changed​ 5. ​Corporate Governance Layer​ 6. ​Multi-Sig Architecture​ 7. ​Timelock Mechanism​ 8. ​Proposal Types and Lifecycle​ 9. ​Parameter Adjustment Flow​ 10. ​Smart Contract Upgrade Protocol​ 11. ​Control 42 — Regulatory Compliance Freeze​ 12. ​Pool Governance​ 13. ​Governance Boundaries Diagram​ 14. ​Emergency Response Governance​ 15. ​Transparency and Reporting​ 16. ​Module-Aware Governance Surface​ 17. ​Governance FAQ​ 18. ​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: ``` ┌──────────────────────────────────────────────────────────────────┐ │ IMMUTABLE TIER │ │ │ │ 42 Transfer Hook controls · 1:1 backing · LP burn · OFAC/AML │ │ Reg D / Reg S / Reg CF holding periods · 4.99% wallet limit │ │ 2% staking reinvestment · 5% total fee · pool immutability │ │ Module 2: NAV-deviation enforcement (CB-21 extension) │ │ Module 3: federal-action freeze coordination (REG-42 extension) │ │ │ │ CANNOT BE CHANGED BY ANY PARTY — including Groovy Company, Inc. │ │ Mathematical property of deployed smart contracts │ └──────────────────────────────────────────────────────────────────┘ ┌──────────────────────────────────────────────────────────────────┐ │ ADJUSTABLE TIER │ │ │ │ TWAP window · price impact threshold · fee distribution ratios │ │ circuit breaker cooldown · AML review threshold · TWAP sigma │ │ Module 2: nav_deviation_max_bps · nav_reappraisal_max_age_secs │ │ Module 3: classification_max_age_secs · federal_action toggle │ │ │ │ Adjustable WITHIN DEFINED BOUNDS by named officers, board │ │ resolution, multi-sig execution, 48h timelock, audit attestation │ └──────────────────────────────────────────────────────────────────┘ ``` #### 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. | Property | Token-Based DAO | Groovy Company, Inc. Corporate Governance | | ------------------- | ------------------------------------------------- | ------------------------------------------------------------------ | | 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 | Parameter | Status | Why Immutable | | ---------------------------------------------------------------- | --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | | 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 | Parameter | Status | Why Immutable | | ----------------------------------------------------------- | -------------------------------- | ------------------------------------------------------------------------------------ | | 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 | Parameter | Status | Why Immutable | | ----------------------------------------------------- | --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | 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 ` 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 | Parameter | Current Default | Adjustment Range | Multi-Sig | Timelock | Module Scope | | ------------------------------ | ------------------------ | ------------------------ | --------- | -------- | ------------ | | 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 | Parameter | Default | Adjustment Range | Multi-Sig | Timelock | Notes | | ------------------------------ | -------------------------------- | --------------------------------------------------------- | --------- | -------- | --------------------------------------------------------- | | `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 | Parameter | Default | Adjustment Range | Multi-Sig | Timelock | Notes | | ------------------------------- | -------------------------------- | ------------------------------ | --------- | -------- | -------------------------------------------------------------------------------- | | `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 ``` GROOVY COMPANY, INC. (Wyoming domicile; principal office Atlanta, GA) CIK: 1499275 · OTC: GROO │ │ PNXP holds 51% of GROO │ ├─ BOARD OF DIRECTORS (sole director: Frank Yglesias) │ └─ Approves: material changes to platform economics, │ security posture, issuer onboarding standards (cross-module), │ smart-contract upgrades, and Module 2 / Module 3 charters │ ├─ Frank Yglesias — Chairman of the Board, CTO, sole director │ └─ Strategic authority, technical authority over smart-contract │ upgrades and security architecture decisions │ ├─ Patrick Mokros — COO of Groovy Company, Inc., │ Founder of Empire Stock Transfer │ └─ Operational authority over parameter adjustments within │ pre-approved bounds; Empire-side custody and onboarding │ ├─ Jhony Navarro — Engineering (CTO-level engineering, not a director) │ └─ Engineering execution under Frank's technical authority │ └─ Legal Counsel └─ Legal authority over regulatory compliance, Control 42 authorization (including Module 3 federal-action freezes), SEC engagement ``` #### Decision Flow ``` 1. NEED IDENTIFIED (engineering, operations, or compliance) Module-aware: parameter need may be cross-module or Module 1 / Module 2 / Module 3 specific 2. CORPORATE DECISION ├─ Cross-module parameter adjustment → COO / CTO authority (within bounds) ├─ Module 2 NAV-bound adjustment → COO / CTO + tripartite concurrence ├─ Module 3 classification-age adjustment → COO / CTO authority (within bounds) ├─ Fee structure change → Board resolution required ├─ Program upgrade → Board resolution + CTO approval ├─ Emergency action → Incident Commander authority └─ Regulatory freeze → Legal Counsel authority (Module 3 federal-action freezes use this path with 60-min SLA) 3. ON-CHAIN EXECUTION ├─ Multi-sig signers assembled ├─ Transaction submitted ├─ Timelock begins (48h standard, 0 for emergency) └─ Activation after timelock 4. DISCLOSURE ├─ On-chain record (automatic, immutable) ├─ SEC EDGAR filing (if material) ├─ Issuer notification (within 48h) └─ Investor notification (via Empire channels) ``` *** ### 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 | Wallet | Threshold | Signers | Purpose | | ------------------- | ---------------------- | -------------------------------------------------- | ----------------------------------------------------------------------------------- | | 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 | Rule | Enforcement | | ------------------------------------------------------------- | ------------------------------------------------ | | 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 | Action Type | Timelock | Cancellation | Rationale | Module Scope | | ---------------------------------------------------------- | -------------------- | -------------------------------------------------- | ------------------------------------------------------------ | ------------------- | | 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 ``` T=0h Multi-sig submits governance transaction ├─ Transaction visible on chain ├─ Anyone can inspect the pending change └─ 48-hour countdown begins T=0-48h OBSERVATION WINDOW ├─ Community can review ├─ Independent auditors can verify ├─ Legal Counsel can intervene └─ 2-of-5 can CANCEL if issue discovered T=48h ACTIVATION ├─ No further action needed — automatic ├─ Parameter change takes effect └─ On-chain record created (permanent) ``` #### 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 | Type | Threshold | Timelock | Additional Requirements | Use Case | Module Scope | | ------------------- | ----------------------------------------------------------------------------- | ---------------- | ----------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- | ------------ | | 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 ``` 1. INITIATION └─ COO or CTO identifies need for parameter change └─ Example A: "Increase TWAP window from 30 to 45 minutes" (cross-module) └─ Example B: "Tighten nav_deviation_max_bps from 2200 to 2000 for mint X" (Module 2) └─ Example C: "Reduce classification_max_age_secs from 86400 to 43200 for mint Y" (Module 3) 2. AUTHORIZATION └─ Written approval from authorizing officer └─ Verified within adjustment bounds (Example A: 15–60 min range → 45 min ✓) 3. ON-CHAIN SUBMISSION └─ 3-of-5 multi-sig signers coordinate └─ Transaction submitted to the governance program └─ Proposal ID generated, visible on chain 4. TIMELOCK (48 hours) └─ Pending change visible to all └─ Cancellation possible (2-of-5) 5. ACTIVATION └─ SecurityConfig (or per-mint NAVOracle / ClassificationOracle PDA) updated for affected mint(s) └─ GovernanceExecuted event emitted └─ Immutable on-chain record 6. NOTIFICATION └─ Affected issuers notified within 48 hours └─ Investor notification via Empire channels └─ SEC EDGAR filing if material ``` #### Proposal Lifecycle — ProgramUpgrade ``` 1. ENGINEERING └─ Upgrade proposal drafted with full code diff and rationale └─ Module-aware coverage statement: any module-specific control extensions (Module 2 NAV, Module 3 federal-action) are explicitly preserved or extended in the proposal 2. SECURITY AUDIT (7–14 days) └─ Independent audit by Quantstamp, Halborn, or OtterSec └─ Audit attestation confirms: ├─ All 42 controls preserved at current specifications ├─ Module 2 NAV-deviation enforcement preserved ├─ Module 3 federal-action freeze coordination preserved ├─ Account schema compatibility (migrate function) └─ No new vulnerabilities introduced 3. BOARD RESOLUTION └─ Board of Directors approves upgrade submission 4. CTO REVIEW └─ CTO confirms technical correctness and security posture 5. ON-CHAIN SUBMISSION └─ 5-of-9 multi-sig executes upgrade proposal └─ Proposal includes: new program binary hash, audit attestation 6. TIMELOCK (48 hours) └─ New program binary visible for independent verification └─ Cancellation possible (2-of-5) 7. ACTIVATION └─ BPF loader deploys new program version └─ Old version replaced atomically └─ UpgradeExecuted event emitted 8. POST-UPGRADE VERIFICATION └─ All 42 controls verified operational across all modules └─ Certora re-verification (post-hoc) — invariants E.1 through E.6 └─ 48-hour enhanced monitoring ``` *** ### 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. ``` STEP 1: COO (Patrick Mokros) reviews data and approves change Current: 30 minutes (1,800 seconds) Proposed: 45 minutes (2,700 seconds) Range check: 15–60 minutes → 45 minutes is WITHIN bounds ✓ STEP 2: 3-of-5 multi-sig signers coordinate Signer 1 (US East): signs via Ledger Enterprise Signer 2 (US West): signs via Ledger Enterprise Signer 3 (EU): signs via Ledger Enterprise Threshold met: 3 of 5 STEP 3: Transaction submitted to the governance program Instruction: adjust_parameter Parameter: twap_window_secs New value: 2700 Proposal ID: GOV-2026-047 STEP 4: 48-hour timelock begins On-chain: GovernanceProposed { id: GOV-2026-047, param: "twap_window_secs", value: 2700 } Anyone can inspect: solana account --output json STEP 5: 48 hours elapse — no cancellation SecurityConfig.twap_window_secs updated to 2700 across all active mints (Module 1, 2, and 3) On-chain: GovernanceExecuted { id: GOV-2026-047 } STEP 6: Notification Issuers across all three modules notified of TWAP change Next SEC filing includes parameter update disclosure ``` #### 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. ``` STEP 1: Tripartite concurrence Issuer, Empire Stock Transfer, and Groovy Company, Inc. agree in writing under the existing tripartite agreement STEP 2: COO (Patrick Mokros) approves change for the affected mint Current per-mint: 2200 bps (22%) Proposed: 2000 bps (20%) Range check: Per-mint range set at issuance — 2000 ✓ STEP 3: 3-of-5 multi-sig executes Proposal ID: GOV-2026-052 STEP 4: 48-hour timelock + activation as in Example A NAVOracle.deviation_tolerance_bps updated for the affected mint only STEP 5: Notification Affected issuer notified; investor notification via Empire as the change tightens (stricter) protections ``` #### Rejection Example — Out-of-Bounds ``` ATTEMPT: Set TWAP window to 5 minutes (300 seconds) Range check: 15–60 minutes → 5 minutes is BELOW minimum ✗ Smart contract rejects: Error: GovernanceError::ParameterOutOfBounds Message: "twap_window_secs 300 below minimum 900" Transaction reverts. No state change. No timelock initiated. ``` 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) | Requirement | Purpose | Verified By | | ------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------- | | 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 | Step | Action | Performer | Timeframe | | ---- | -------------------------------------------------------------------------- | ------------------------------------- | ------------------- | | 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: | Prohibited Action | Enforcement | | ------------------------------------------------------------------------ | -------------------------------------------------------------- | | 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) | Step | Action | Authority | | ---- | ----------------------------------------------------------------------------------------- | -------------------------------------------- | | 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: | Step | Action | Authority | SLA | | ---- | --------------------------------------------------------------------- | -------------------------------- | --------------------------------- | | 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 | Property | Detail | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------ | | 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 | Prohibited Action | Why | | ------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | | 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) | Parameter | Adjustment Mechanism | Bounds | Module Scope | | -------------------------- | --------------------- | -------------------------------------------------------------------------------- | ------------ | | 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) | Parameter | Status | Why | | ---------------------------- | ----------------------------------------------- | ----------------------------------------------------------------------------- | | 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: | Requirement | Detail | | ----------------------- | ------------------------------------------------------------ | | 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 ``` ┌────────────────────────────────────────────────────────────────────┐ │ GOVERNANCE SCOPE MAP │ │ │ │ ┌────────────────────────────────────────────────────────────┐ │ │ │ OUTSIDE GOVERNANCE (IMMUTABLE) │ │ │ │ │ │ │ │ 42 Transfer Hook controls · 1:1 backing · LP burn │ │ │ │ OFAC/AML per transfer · holding periods (D/S/CF) │ │ │ │ 4.99% default ceiling · 9.99% program upper bound │ │ │ │ 2% staking reinvestment · 5% total fee · pool immutability│ │ │ │ │ │ │ │ Module 2: NAV-deviation enforcement (CB-21 extension) │ │ │ │ Module 3: federal-action freeze coordination │ │ │ │ (REG-42 extension; 60-min SLA) │ │ │ │ │ │ │ │ NO AUTHORITY CAN CHANGE THESE │ │ │ │ — including Groovy Company, Inc. itself │ │ │ └────────────────────────────────────────────────────────────┘ │ │ │ │ ┌────────────────────────────────────────────────────────────┐ │ │ │ INSIDE GOVERNANCE (ADJUSTABLE) │ │ │ │ │ │ │ │ ┌────────────────────────────────────────────────────┐ │ │ │ │ │ 5-of-9 + 48h + AUDIT + BOARD + CERTORA E.4 │ │ │ │ │ │ Program upgrades (preserving all 42 controls │ │ │ │ │ │ plus module-aware extensions) │ │ │ │ │ │ Emergency pool migration │ │ │ │ │ └────────────────────────────────────────────────────┘ │ │ │ │ │ │ │ │ ┌────────────────────────────────────────────────────┐ │ │ │ │ │ 3-of-5 + 48h │ │ │ │ │ │ Cross-module: TWAP window · price impact · │ │ │ │ │ │ fee ratios · cooldowns · │ │ │ │ │ │ AML threshold · TWAP sigma │ │ │ │ │ │ Module 2 only: nav_deviation_max_bps · │ │ │ │ │ │ nav_reappraisal_max_age_secs │ │ │ │ │ │ Module 3 only: classification_max_age_secs │ │ │ │ │ └────────────────────────────────────────────────────┘ │ │ │ │ │ │ │ │ ┌────────────────────────────────────────────────────┐ │ │ │ │ │ 3-of-5 + LEGAL COUNSEL (IMMEDIATE / 60-MIN SLA) │ │ │ │ │ │ Control 42 — regulatory freeze (cross-module) │ │ │ │ │ │ Control 42 — Module 3 federal-action variant │ │ │ │ │ │ Emergency circuit breaker │ │ │ │ │ └────────────────────────────────────────────────────┘ │ │ │ │ │ │ │ └────────────────────────────────────────────────────────────┘ │ │ │ └────────────────────────────────────────────────────────────────────┘ ``` *** ### 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 | Action | Authority | Approval | Timelock | Module Scope | | ----------------------------------------------------- | ---------------------------------------- | ------------------------------------------------- | ---------------------------- | ------------ | | 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 | Action | Authorized By | Reversible | Module Scope | | ------------------ | --------------------------------------------------------------------- | ------------------------------------------------- | ------------------------------ | -------------------------------------------------------------- | | 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. | Record | Content | Visibility | Module Scope | | -------------------------------- | --------------------------------------------------------------------- | ---------------------- | ------------------- | | 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 | Audience | Channel | Timing | | --------- | ------------------------------------------- | ----------------------------------------------------------------------------------------------- | | 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 ```bash # Transfer Hook — should be 5-of-9 multi-sig solana program show | grep "Authority" # AMM — should be 5-of-9 multi-sig solana program show | grep "Authority" # Liquidity Pool — MUST be "none" (immutable) solana program show | grep "Authority" # Expected: "Authority: none" # Governance — should be 3-of-5 multi-sig solana program show | grep "Authority" # Oracle Aggregator — should be 5-of-9 multi-sig solana program show | grep "Authority" ``` #### Verify Pending Governance Actions ```bash # Check for pending timelocked proposals anchor account governance GovernanceProposal \ --provider.cluster mainnet | jq '{ proposal_id: .proposalId, action: .actionType, param: .parameterName, new_value: .proposedValue, affected_mint: .affectedMint, submitted_at: .submittedAt, activates_at: .activatesAt, status: .status }' ``` #### Verify Module-Specific Governance Actions ```bash # Check for pending Module 2 NAV-bound adjustments anchor account governance GovernanceProposal \ --provider.cluster mainnet | jq ' select(.actionType == "ParameterAdjustment" and (.parameterName == "nav_deviation_max_bps" or .parameterName == "nav_reappraisal_max_age_secs")) ' # Check for pending Module 3 classification-age adjustments anchor account governance GovernanceProposal \ --provider.cluster mainnet | jq ' select(.actionType == "ParameterAdjustment" and .parameterName == "classification_max_age_secs") ' ``` #### Verify Governance Event History ```bash # Query all GovernanceExecuted events curl -s https://api.cedex.market/v1/governance/history | jq '.events[] | { id: .proposal_id, action: .action_type, param: .parameter, old_value: .old_value, new_value: .new_value, affected_mint: .affected_mint, module_scope: .module_scope, timestamp: .executed_at, signers: .signer_count }' ``` *** ### 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.* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://bitbook.rwatokens.net/ai-and-tokenomics/ai-and-tokenomics/governance-deep-dive.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.