Section 7: Protocol Governance and Parameter Management — Layers 7
|
OTCM PROTOCOL Comprehensive Technical Whitepaper — Version 7.0 ST22 Digital Securities Platform | March 2026 | Groovy Company, Inc. dba OTCM Protocol |
Section 7: Protocol Governance and Parameter Management
The governance framework for OTCM Protocol's operating parameters — defining precisely what can be adjusted, what cannot be changed by any party, who holds adjustment authority, and the security controls that protect parameter changes from unauthorized modification.
7.1 Governance Philosophy
OTCM Protocol's governance architecture reflects a straightforward principle: the 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 is a Wyoming Corporation with named officers, a board of directors, and legal counsel on record with the SEC. Protocol governance is an extension of corporate governance — transparent, accountable, and subject to the same securities law obligations as any other corporate action affecting investors.
|
The Core Governance Principle The 42 Transfer Hook security controls embedded in OTCM Protocol's immutable on-chain program cannot be changed by any party — 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 |
|
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 no 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 multi-signature execution and a 48-hour on-chain timelock before taking effect. No parameter can be adjusted outside its defined range in a single governance action — preventing incremental boundary erosion.
|
Parameter |
Current Default |
Adjustment Range |
Rationale for 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 enhanced 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 full upgrade security controls described in §7.5. |
7.4 Governance Authority Structure
7.4.1 Corporate Governance Layer
All material protocol decisions originate at the corporate governance level of 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
|
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 architecture can be weakened. |
|
Groovy Company, Inc. dba OTCM Protocol | CIK: 1499275 | Version 7.0 | March 2026 | Confidential |