Section 7: Protocol Governance and Parameter Management — Layers 8

🏗️

7.1DAO

🏛️OTCM LayersPROTOCOL 7 Comprehensive &Technical 8Whitepaper  — Decentralized AutonomousVersion Organization7.0 governance protecting security controls from unilateral modification, and the native Web3 wallet infrastructure for compliant ST22 Digital Securities management.Platform  |  March 2026  |  Groovy Company, Inc. dba OTCM Protocol

 

Section 7: Protocol Governance Architectureand —Parameter Layer 7

🔹 7.1.1 Governance Philosophy

Management

The OTCMgovernance DAO Governance layer existsframework for aOTCM specificProtocol's andoperating limitedparameters purpose:— todefining preventprecisely what can be adjusted, what cannot be changed by any singleparty, partywho fromholds unilaterallyadjustment alteringauthority, and the security controls that protect investorparameter assets.changes Thisfrom isunauthorized notmodification.

 

7.1  Governance Philosophy

OTCM Protocol's governance theaterarchitecture — it isreflects a structuralstraightforward constraintprinciple: onthe parameters that protect investors from harm must be structurally impossible to change, while the parameters that affect platform economics must be adjustable within defined bounds by accountable human decision-makers operating under identified security controls.

This approach deliberately differs from anonymous token-based governance models. Groovy Company, Inc. dba OTCM Protocol itself.is Thea companyWyoming thatCorporation builtwith named officers, a board of directors, and legal counsel on record with the protocolSEC. cannot,Protocol withoutgovernance on-chainis DAOan approvalextension of corporate governance — transparent, accountable, and asubject 48-hour timelock, changeto the Transfersame Hooksecurities parameterslaw governingobligations theas 42any securityother controls.corporate action affecting investors.

 

The Core Governance Principle The governance42 scopeTransfer isHook deliberatelysecurity bounded.controls Investorsembedded needin assuranceOTCM thatProtocol's theimmutable 1:1on-chain backing requirement, KYC/AML enforcement, and OFAC screeningprogram cannot be quietlychanged disabled.by Atany 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%) ✅ Yesparty — 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.including Groovy Company, Inc. dba OTCM Protocol, Empire Stock Transfer, or any officer or director of the Company. This is not a policy commitment. It is a mathematical property of the deployed smart contract. Governance authority extends only to adjustable economic parameters, not to the investor protections that make the platform a compliant Digital Securities infrastructure.

 

7.2  Immutable Parameters — What Cannot Be Changed

The following parameters are embedded in OTCM Protocol's immutable on-chain program. No corporate resolution, no multi-signature execution, no legal process, and no technical action can modify these parameters 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:

 

Parameter	Status	Authority / Mechanism
42 Transfer Hook security controls	Immutable — on-chain program	No authority — architecturally impossible to modify
1:1 token-to-share backing requirement	Immutable — Transfer Hook Control 1	Cannot be relaxed by any party; any discrepancy halts all transfers
LP token burn at pool initialization	Immutable — pool contract design	No withdrawal function exists; LP tokens already burned
OFAC/SDN screening on every transfer	Immutable — Controls 8–10	Cannot be disabled or bypassed by any participant including OTCM Protocol never
AML risk scoring on every transfer	Immutable — Control 11	Cannot be disabled or bypassed
Accreditation verification on every transfer	Immutable — Controls 12–18	Cannot be disabled or bypassed
Rule 144 / Reg S holding period enforcement	Immutable — Control 24	Cannot be waived by any party; no administrative override
5% transaction fee — total rate	Immutable — Token-2022 Transfer Fee Extension	Configured at mint creation; cannot be changed post-mint
2% staking reward reinvestment to Global Pool	Immutable — Transfer Hook logic	Cannot be reduced or disabled
Wallet concentration limit — 4.99% maximum	Immutable — Control 20	Cannot be increased beyond this ceiling

 

Why Immutability Is the Stronger Governance Position For an institutional investor or regulator reviewing OTCM Protocol, the question is not 'who controls the governance?' — it is 'what is the worst case if governance fails or is compromised?' An immutable security control has accessno worst case: it cannot be compromised because it cannot be changed. Every governance mechanism — however well designed — introduces a pathway through which investor protections could theoretically be weakened. Removing that pathway entirely is the strongest institutional assurance available.

 

7.3  Adjustable Parameters — What Can Be Changed

The following parameters may be adjusted within defined bounds by OTCM Protocol's authorized governance process. All adjustments are subject to usermulti-signature privateexecution keys.and Hardwarea wallet48-hour supporton-chain providestimelock anbefore additionaltaking custodyeffect. optionNo parameter can be adjusted outside its defined range in a single governance action — preventing incremental boundary erosion.

 

🔹

7.2.2KYC/

Parameter	Current Default	Adjustment Range	Rationale for institutional investors requiring air-gapped key storage.Adjustability
TWAP calculation window	30 minutes	15–60 minutes	Market conditions may warrant a longer or shorter reference window
Maximum price impact per trade	2%	1–5%	May need tightening or loosening as liquidity depth matures
Fee distribution ratios	See §5.8	Max 10% shift per action	Platform economics evolve with scale
Circuit breaker cooldown period	24 hours	12–72 hours	May need tuning based on observed market patterns
AML Enforcementenhanced review threshold	Score 31	25–45	Risk tolerance calibration as AML model matures
TWAP outlier rejection threshold	3σ from median	2–5σ	Statistical tuning as price feed data accumulates
Emergency circuit breaker trigger	3-of-5 multi-sig	Fixed at 3-of-5	Quorum for emergency platform halt

 

Adjustment Bounds Are Hard Limits Each adjustable parameter has a defined minimum and maximum. No single governance action can move a parameter outside its defined range. If market conditions require a parameter to move beyond its range, a separate protocol upgrade process is required — subject to the Walletfull upgrade security controls described in §7.5.

 

7.4  Governance Authority Structure

7.4.1  Corporate Governance Layer

ComplianceAll ismaterial enforcedprotocol atdecisions two levels:originate at the walletcorporate applicationgovernance layerlevel duringof onboarding,Groovy Company, Inc. dba OTCM Protocol. Major decisions — fee structure changes, new issuer onboarding policies, platform security posture changes — require board resolution before on-chain execution. This provides a documented, auditable decision trail consistent with the Company's obligations as an SEC-reporting public company (CIK: 1499275).

 

•       Board of Directors — Approves material changes to platform economics, security posture, and issuer onboarding standards

•       Chief Technology Officer — Frank Yglesias — Technical authority over smart contract upgrade proposals and security architecture decisions

•       Chief Legal Counsel — Jeff Turner (JDT Legal) — Legal authority over all regulatory compliance determinations, including any interaction with Control 42 (Regulatory Compliance Override)

•       Chief Operating Officer — Patrick Mokros — Operational authority over platform parameter adjustments within pre-approved bounds

 

7.4.2  Multi-Signature Execution

All on-chain parameter changes and smart contract upgrades require multi-signature execution. The multi-signature architecture ensures that no single individual — regardless of title or authority — can unilaterally modify platform parameters:

 

Action Type	Multi-Sig Threshold	Timelock	Additional Requirements
Adjustable parameter change (within bounds)	3-of-5 authorized signers	48 hours	Written record of approving authority
Emergency circuit breaker activation	3-of-5 authorized signers	None — immediate	P0 incident declaration required; post-incident review within 24 hours
Smart contract program upgrade	5-of-9 authorized signers	48 hours	Security audit attestation required; see §7.5
Emergency pool migration (catastrophic vulnerability only)	5-of-9 authorized signers	48 hours	Independent security audit of destination contract; CLO approval
Control 42 — regulatory compliance freeze	CLO authorization + 3-of-5 multi-sig	None — immediate	Written legal process documentation required

 

Multi-signature key holders are geographically distributed across multiple jurisdictions. Key rotation follows a defined schedule and requires the same multi-signature threshold as the actions the keys authorize. No key holder may hold more than one signing position in any quorum.

 

7.5  Smart Contract Upgrade Protocol

Smart contract program upgrades are the most sensitive governance action available — they modify the executable code that enforces compliance on every ST22 transfer. The upgrade protocol is designed to ensure that no upgrade can weaken investor protections, and that any upgrade is subject to independent technical review before activation.

 

7.5.1  Upgrade Requirements

•       Security audit attestation — Every upgrade proposal must include a schema compatibility attestation signed by a PCAOB-registered or recognized blockchain security firm (Quantstamp, Halborn, or OtterSec). Proposals without a valid attestation are automatically rejected by the upgrade timelock contract.

•       Account schema compatibility — The new program version must handle all existing account schema versions via a migrate() function. No upgrade may activate until all existing accounts can be migrated without data loss.

•       Immutable control preservation — The upgrade must preserve all 42 Transfer Hook security controls at their current specifications. Any upgrade that would weaken, remove, or bypass any control is rejected regardless of multi-sig approval.

•       48-hour observation window — The 48-hour timelock between approval and activation provides time for community observation, independent security review, and legal intervention if needed.

•       5-of-9 multi-sig threshold — A higher quorum than parameter changes — reflecting the elevated risk profile of code-level modifications.

 

7.5.2  Upgrade Governance Flow

 

Step	Action	Performer	Timeframe
1	Upgrade proposal drafted with full diff and change rationale	Engineering team	Prior to submission
2	Independent security audit of proposed upgrade	Quantstamp / Halborn / OtterSec	7–14 days
3	Audit attestation received confirming: control preservation, schema compatibility, no new vulnerabilities	Auditing firm	On audit completion
4	Board resolution approving upgrade submission	Board of Directors	Before on-chain submission
5	5-of-9 multi-sig executes upgrade proposal on-chain	Authorized signers	After board resolution
6	48-hour timelock begins — upgrade visible on-chain	On-chain timelock contract	Automatic
7	Upgrade activates — no further action required	On-chain timelock contract	After 48 hours

 

7.6  Control 42 — Regulatory Compliance Override

Transfer Hook Control 42 provides a targeted, legally-sanctioned mechanism for OTCM Protocol to comply with formal regulatory freeze orders, law enforcement legal process, or SEC enforcement actions requiring the suspension of specific ST22 token transfers. This control is the only mechanism by which specific wallets or token mints can be frozen outside the standard 42-control validation path.

 

7.6.1  Scope and Limits

Control 42 is a targeted freeze — it does not constitute a general override of the 42-control Transfer Hook architecture:

 

•       Targeted freeze only — Control 42 can freeze a specific wallet address or a specific token mint. It cannot disable the 42 Transfer Hook controls globally.

•       Legal process required — Activation requires documented legal process — a court order, SEC enforcement action, or written law enforcement request — reviewed and authorized by CLO Jeff Turner (JDT Legal).

•       Audit trail mandatory — Every Control 42 activation creates an immutable on-chain record including the timestamp, the legal authority cited, and the specific addresses or mints affected.

•       Reversible with same process — A freeze imposed under Control 42 can be lifted only through the same CLO authorization + 3-of-5 multi-sig process, upon resolution of the underlying legal matter.

•       Not an administrative override — Control 42 cannot be used to waive the Rule 144 holding period, the accreditation requirement, OFAC screening, or any other investor protection control. It is strictly a targeted legal compliance mechanism.

 

7.6.2  Process

Step	Action	Authority
1	Receive formal legal process (court order, SEC enforcement notice, law enforcement request)	Incoming to CLO
2	CLO review and legal authorization — confirms process is valid and scope is appropriate	CLO Jeff Turner (JDT Legal)
3	3-of-5 multi-sig executes targeted freeze via Control 42	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	CLO + Compliance team
7	Freeze lifted upon legal resolution via same CLO + multi-sig process	CLO + authorized signers

 

7.7  Governance Transparency and Reporting

All on-chain governance actions are permanently recorded on the Solana blockchain and publicly accessible. OTCM Protocol maintains the following transparency commitments:

 

•       On-chain action log — Every parameter change, upgrade activation, and Control 42 freeze is recorded on-chain with full context — timestamp, authorizing multi-sig signatures, and the specific change made

•       SEC EDGAR disclosure — Material governance changes affecting the platform's compliance architecture or economic parameters are disclosed through the Company's SEC reporting obligations as a public company (CIK: 1499275)

•       Issuer notification — ST22 issuers are notified of any parameter changes affecting their token's operating parameters within 48 hours of activation

•       Investor notification — Accredited investors holding ST22 tokens are notified of any changes affecting transfer restrictions, fee structures, or holding period parameters through the Empire Stock Transfer investor communication channel

•       CLO review of all major changes — Jeff Turner (JDT Legal) reviews all governance actions with potential securities law implications before execution — not as a rubber stamp, but as an active legal compliance gate

 

Thewalletlayer

Governance Summary OTCM Protocol's governance architecture provides maximum protection for investors (42 immutable controls), maximum accountability for operators (named corporate officers, board resolution requirements, CLO gate), and maximum security for parameter changes (multi-sig execution, 48-hour timelock, audit attestation). It does not rely on anonymous token voting, it does not introduce governance token securities exposure, and it does not create any pathway — theoretical or practical — through which the investor protections embedded in the Transfer Hook layerarchitecture duringcan everybe on-chainweakened. transaction.

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 ·CIK: invest@otcm.io1499275 · otcm.io|  Version 7.0  |  March 2026  |  Confidential

---

🏛️ 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