🏛️ Section 7: DAO Governance & Wallet Infrastructure — Layers 7 & 8
🏛️ Layers 7 & 8 — Decentralized Autonomous Organization governance protecting security controls from unilateral modification, and the native Web3 wallet infrastructure for compliant ST22 Digital Securities management.
🏗️ 7.1 DAO Governance Architecture — Layer 7
🔹 7.1.1 Governance Philosophy
The OTCM DAO Governance layer exists for a specific and limited purpose: to prevent any single party from unilaterally altering the security controls that protect investor assets. This is not governance theater — it is a structural constraint on Groovy Company, Inc. dba OTCM Protocol itself. The company that built the protocol cannot, without on-chain DAO approval and a 48-hour timelock, change the Transfer Hook parameters governing the 42 security controls.
The governance scope is deliberately bounded. Investors need assurance that the 1:1 backing requirement, KYC/AML enforcement, and OFAC screening cannot be quietly disabled. At the same time, the protocol needs operational flexibility to adjust fee rates, graduation thresholds, and APY parameters as the market evolves. The governance architecture creates a clear separation between these two categories.
🔹 7.1.2 Governable vs. Non-Governable Parameters
Category | Governable? | Rationale |
|---|---|---|
Transaction fee rate (5%) | ✅ Yes — DAO vote | Commercial parameter · does not affect security controls |
Staking APY range (8–60%) | ✅ Yes — DAO vote | Economic parameter · affects token holders proportionally |
Graduation threshold ($250K) | ✅ Yes — DAO vote | Market parameter · reflects evolving liquidity conditions |
TWAP window (15–60 min) | ✅ Yes — DAO vote | Oracle parameter with constrained bounds |
IDOS AI scoring weights | ✅ Yes — DAO vote | Commercial intelligence parameter |
1:1 backing requirement | ❌ NO — immutable | Core Digital Securities investor protection · cannot be weakened |
KYC/AML requirement | ❌ NO — immutable | Federal law compliance · cannot be bypassed |
OFAC screening (Hook 2) | ❌ NO — immutable | Federal sanctions law · cannot be disabled |
Transfer Hook logic | ❌ NO — requires supermajority + external audit | Security-critical code |
Permanent LP lock | ❌ NO — requires 2/3 supermajority + 48h timelock | Investor asset protection |
🔹 7.1.3 Voting Tiers & Token Requirements
Proposal Type | Min. Stake to Vote | Quorum | Passage Threshold |
|---|---|---|---|
Standard parameter change | Gold (50,000 OTCM) | 10% of staked | Simple majority (>50%) |
Fee structure change | Gold (50,000 OTCM) | 15% of staked | Supermajority (>60%) |
Transfer Hook parameter | Platinum (100,000 OTCM) | 25% of staked | Supermajority (>66%) |
LP lock override | Platinum (100,000 OTCM) | 33% of staked | Supermajority (>66%) + 48h timelock |
Emergency security patch | 3/4 of core team multi-sig | N/A | 3-of-4 multi-sig + 48h timelock |
🔹 7.1.4 Proposal Lifecycle
All governance proposals follow a standardized five-stage lifecycle:
Stage 1 — Submission (Day 0)
Proposer stakes minimum required OTCM tokens and submits proposal
on-chain with full specification of parameter changes and rationale.
↓
Stage 2 — Discussion (Days 1–3)
72-hour community discussion period.
Proposer may NOT amend the proposal during this window.
Counter-proposals may be submitted.
↓
Stage 3 — Voting (Days 4–8)
5-day on-chain voting window.
Token-weighted votes recorded immutably.
Voting power snapshot taken at proposal submission time.
↓
Stage 4 — Timelock (Days 9–10)
Passed proposals enter a mandatory 48-hour timelock before execution.
This window allows community response to unexpected passages.
↓
Stage 5 — Execution (Day 11+)
Timelock expires and proposal executes automatically on-chain.
For Transfer Hook changes, external audit must be completed
before execution is permitted.🔹 7.1.5 Security Control Governance — Special Requirements
Any proposal affecting Transfer Hook logic — adding, removing, or modifying any of the 42 security controls — carries additional requirements beyond the standard proposal lifecycle:
- 14-day advance notice broadcast before voting opens
- Independent security audit of proposed code changes required before execution
- Audit report published on-chain as part of the proposal record
- Platinum tier voting — 100,000 OTCM minimum stake
- 66%+ supermajority passage threshold
- 48-hour timelock after passage regardless of urgency
These requirements exist because Transfer Hook modifications affect every ST22 Digital Securities transfer across every issuer on the platform simultaneously. A single flawed change could disable investor protections for thousands of token holders. The friction is intentional.
📐 7.2 Web3 Wallet Infrastructure — Layer 8
🔹 7.2.1 Wallet Architecture Philosophy
Layer 8 bridges the compliance architecture of Layers 2–7 with the end investor experience. The OTCM wallet is not a generic Solana wallet with a whitelist — it is a purpose-built Digital Securities wallet where:
- KYC/AML compliance is embedded in the onboarding flow
- ST22 Digital Securities token interactions are the primary use case
- Institutional custody requirements are first-class design considerations
The wallet is non-custodial: private keys are generated and stored on the user's device. Groovy Company, Inc. dba OTCM Protocol never has access to user private keys. Hardware wallet support provides an additional custody option for institutional investors requiring air-gapped key storage.
🔹 7.2.2 KYC/AML Enforcement at the Wallet Layer
Compliance is enforced at two levels: at the wallet application layer during onboarding, and at the Transfer Hook layer during every on-chain transaction. The wallet layer check is a user experience optimization — it prevents investors from attempting transactions that Transfer Hooks would reject, reducing friction and eliminating failed transaction fees.
Compliance Gate | Layer | When Applied | Fail Behavior |
|---|---|---|---|
Identity verification (KYC) | Layer 8 wallet | During account creation | Account creation blocked |
AML risk scoring | Layer 8 wallet | During onboarding + periodic refresh | Account restricted pending review |
OFAC screening | Layer 8 wallet | Real-time on wallet activation | Account blocked · compliance team notified |
Accreditation check | Layer 8 wallet | Before ST22 purchase attempts | Purchase blocked · accreditation flow triggered |
Transfer Hook execution | Layer 2 | Every on-chain transfer | Transaction reverts with error code |
🔹 7.2.3 Application Features
Feature | Description |
|---|---|
Multi-issuer portfolio | Unified dashboard for all ST22 Digital Securities holdings across all issuers on CEDEX |
Transaction history | Full audit trail of all ST22 transfers with compliance event log |
Compliance status | Real-time KYC/AML verification status with renewal reminders |
CEDEX integration | Embedded CEDEX trading interface — buy/sell ST22 without leaving wallet |
Staking dashboard | OTCM Security Token staking management · epoch tracking · reward display |
Redemption workflow | Guided Series M share redemption process with Empire Stock Transfer confirmation |
Push notifications | Launch alerts for new ST22 issuers · compliance renewal reminders |
Institutional mode | Multi-sig approval flows · hardware wallet signing · bulk transaction management |
🔹 7.2.4 Hardware Wallet Integration
Institutional investors and high-net-worth individuals requiring air-gapped private key storage may connect Ledger or Trezor hardware wallets to the OTCM wallet application. All transaction signing is handled by the hardware device — the OTCM application constructs and serializes the transaction but never accesses the signing key.
Transfer Hook execution occurs normally regardless of signing method; the hardware wallet provides signing security without affecting on-chain compliance enforcement.
🔹 7.2.5 Performance Specifications
Metric | Specification |
|---|---|
Platform support | iOS 16+ and Android 12+ native apps |
Wallet creation time | < 60 seconds including key generation |
KYC/AML onboarding | 15–30 minutes (document upload + verification) |
Transaction signing latency | < 200ms software wallet · < 3s hardware wallet (user confirmation required) |
CEDEX order submission | < 100ms from order confirmation to network broadcast |
Balance sync cadence | Real-time via Helius RPC WebSocket subscription |
Supported tokens | All ST22 Digital Securities listed on CEDEX + OTCM Security Token |
Hardware wallets supported | Ledger Nano S / X / S Plus · Trezor Model T / Safe |
Groovy Company, Inc. dba OTCM Protocol · Wyoming Corporation · invest@otcm.io · otcm.io
🏛️ Layers 7 & 8 — Decentralized Autonomous Organization governance protecting security controls from unilateral modification, and the native Web3 wallet infrastructure for compliant ST22 token management.
🏗️ 7.1 DAO Governance Architecture — Layer 7
🔹 7.1.1 Governance Philosophy
The OTCM DAO Governance layer exists for a specific and limited purpose: to prevent any single party from unilaterally altering the security controls that protect investor assets. This is not governance theater — it is a structural constraint on OTCM Protocol, Inc. itself. The company that built the protocol cannot, without on-chain DAO approval and a 48-hour timelock, change the Transfer Hook parameters governing the 42 security controls.
The governance scope is deliberately bounded. Investors need assurance that the 1:1 backing requirement, KYC/AML enforcement, and OFAC screening cannot be quietly disabled. At the same time, the protocol needs operational flexibility to adjust fee rates, graduation thresholds, and APY parameters as the market evolves. The governance architecture creates a clear separation between these two categories.
🔹 7.1.2 Governable vs. Non-Governable Parameters
Category | Governable? | Rationale |
|---|---|---|
Transaction fee rate (5%) | Yes — DAO vote | Commercial parameter; does not affect security controls |
Staking APY range (8–60%) | Yes — DAO vote | Economic parameter; affects token holders proportionally |
Graduation threshold ($75K) | Yes — DAO vote | Market parameter; reflects evolving liquidity conditions |
TWAP window (15–60 min) | Yes — DAO vote | Oracle parameter with constrained bounds |
IDOS AI scoring weights | Yes — DAO vote | Commercial intelligence parameter |
1:1 backing requirement | NO — immutable | Core investor protection; cannot be weakened |
KYC/AML requirement | NO — immutable | Federal law compliance; cannot be bypassed |
OFAC screening (Hook 2) | NO — immutable | Federal sanctions law; cannot be disabled |
Transfer Hook logic | NO — requires supermajority + external audit | Security-critical code |
Permanent LP lock | NO — requires 2/3 supermajority + 48h timelock | Investor asset protection |
🔹 7.1.3 Voting Tiers & Token Requirements
Proposal Type | Min. Stake to Vote | Quorum | Passage Threshold |
|---|---|---|---|
Standard parameter change | Gold (50,000 OTCM) | 10% of staked | Simple majority (>50%) |
Fee structure change | Gold (50,000 OTCM) | 15% of staked | Supermajority (>60%) |
Transfer Hook parameter | Platinum (100,000 OTCM) | 25% of staked | Supermajority (>66%) |
LP lock override | Platinum (100,000 OTCM) | 33% of staked | Supermajority (>66%) + 48h timelock |
Emergency security patch | 3/4 of core team multi-sig | N/A | 3-of-4 multi-sig + 48h timelock |
🔹 7.1.4 Proposal Lifecycle
All governance proposals follow a standardized five-stage lifecycle:
- Stage 1 — Submission (Day 0): Proposer stakes minimum required OTCM tokens and submits proposal on-chain with full specification of parameter changes and rationale.
- Stage 2 — Discussion (Days 1–3): 72-hour community discussion period. Proposer may not amend the proposal during this window. Counter-proposals may be submitted.
- Stage 3 — Voting (Days 4–8): 5-day on-chain voting window. Token-weighted votes recorded immutably. Voting power snapshot taken at proposal submission time.
- Stage 4 — Timelock (Days 9–10): Passed proposals enter a mandatory 48-hour timelock before execution. This window allows community response to unexpected passages.
- Stage 5 — Execution (Day 11+): Timelock expires and proposal executes automatically on-chain. For Transfer Hook changes, external audit must be completed before execution.
🔹 7.1.5 Security Control Governance — Special Requirements
Any proposal affecting Transfer Hook logic — adding, removing, or modifying any of the 42 security controls — carries additional requirements beyond the standard proposal lifecycle:
- Minimum 14-day advance notice broadcast before voting opens
- Independent security audit of proposed code changes required before execution
- Audit report published on-chain as part of the proposal record
- Platinum tier voting requirement (100,000 OTCM minimum stake)
- 66%+ supermajority passage threshold
- 48-hour timelock after passage regardless of urgency These requirements exist because Transfer Hook modifications affect every ST22 token transfer across every issuer on the platform simultaneously. A single flawed change could disable investor protections for thousands of token holders. The friction is intentional.
📐 7.2 Web3 Wallet Infrastructure — Layer 8
🔹 7.2.1 Wallet Architecture Philosophy
Layer 8 bridges the compliance architecture of Layers 2–7 with the end investor experience. The OTCM wallet is not a generic Solana wallet with a whitelist — it is a purpose-built securities wallet where KYC/AML compliance is embedded in the onboarding flow, ST22 token interactions are the primary use case, and institutional custody requirements are first-class design considerations.
The wallet is non-custodial: private keys are generated and stored on the user's device. OTCM Protocol never has access to user private keys. Hardware wallet support provides an additional custody option for institutional investors requiring air-gapped key storage.
🔹 7.2.2 KYC/AML Enforcement at the Wallet Layer
Compliance is enforced at two levels: at the wallet application layer during onboarding, and at the Transfer Hook layer during every on-chain transaction. The wallet layer check is a user experience optimization — it prevents investors from attempting transactions that Transfer Hooks would reject, reducing friction and eliminating failed transaction fees.
Compliance Gate | Layer | When Applied | Fail Behavior |
|---|---|---|---|
Identity verification (KYC) | Layer 8 wallet | During account creation | Account creation blocked |
AML risk scoring | Layer 8 wallet | During onboarding + periodic refresh | Account restricted pending review |
OFAC screening | Layer 8 wallet | Real-time on wallet activation | Account blocked; compliance team notified |
Accreditation check | Layer 8 wallet | Before ST22 purchase attempts | Purchase blocked; accreditation flow triggered |
Transfer Hook execution | Layer 2 | Every on-chain transfer | Transaction reverts with error code |
🔹 7.2.3 Application Features
Feature | Description |
|---|---|
Multi-issuer portfolio | Unified dashboard for all ST22 token holdings across all issuers on CEDEX |
Transaction history | Full audit trail of all ST22 transfers with compliance event log |
Compliance status | Real-time KYC/AML verification status with renewal reminders |
CEDEX integration | Embedded CEDEX trading interface — buy/sell ST22 without leaving wallet |
Staking dashboard | OTCM Security Token staking management; epoch tracking; reward display |
Redemption workflow | Guided Series M share redemption process with EST confirmation |
Push notifications | Launch alerts for new ST22 issuers; compliance renewal reminders |
Institutional mode | Multi-sig approval flows; hardware wallet signing; bulk transaction management |
🔹 7.2.4 Hardware Wallet Integration
Institutional investors and high-net-worth individuals requiring air-gapped private key storage may connect Ledger or Trezor hardware wallets to the OTCM wallet application. All transaction signing is handled by the hardware device — the OTCM application constructs and serializes the transaction but never accesses the signing key. Transfer Hook execution occurs normally regardless of signing method; the hardware wallet provides signing security without affecting on-chain compliance enforcement.
🔹 7.2.5 Performance Specifications
Metric | Specification |
|---|---|
Platform support | iOS 16+ and Android 12+ native apps |
Wallet creation time | < 60 seconds including key generation |
KYC/AML onboarding | 15–30 minutes (document upload + verification) |
Transaction signing latency | < 200ms software wallet; < 3s hardware wallet (user confirmation required) |
CEDEX order submission | < 100ms from order confirmation to network broadcast |
Balance sync cadence | Real-time via Helius RPC WebSocket subscription |
Supported tokens | All ST22 tokens listed on CEDEX + OTCM Security Token |
Hardware wallets supported | Ledger Nano S/X/S Plus, Trezor Model T/Safe |