Empire Stock Transfer — §17A Qualified Custody
Section 11: Empire Stock Transfer — §17A Qualified Custody
RWA Tokens Platform Whitepaper · Version 10.0 Groovy Company, Inc. · May 2026 Document Reference: RWA-EMPIRE-SPEC-001 v2.0
Empire Stock Transfer is the platform's exclusive SEC §17A-registered transfer agent, qualified custodian, and sole investor onboarding authority. Empire is the architectural anchor for SEC Category 1 Model B Pillar 3 (SEC §17A-Registered Qualified Custody) and Pillar 4 (True Equity Backing 1:1) across all three modules.
11.1 Empire's Role and Authority
Transfer agent
SEC §17A-registered
Qualified custodian
Per §17A; holds underlying equity 1:1 across all modules
Sole onboarding authority
KYC, KYB, AML, OFAC/SDN, wallet verification — across M1, M2, M3
Cryptographic attestor
Per-Solana-slot Ed25519 attestation of custodied balance
MSF maintainer
Master Securityholder File — legally controlling shareholder register
Reg D accreditation verifier
§501(a) accredited-investor verification
Reg CF eligibility verifier
JOBS Act §4(a)(6) investor-limit verification
Module 1 onboarding
Common Class B custody
Module 2 onboarding
SAE equity custody
Module 3 onboarding
BAE equity custody
Founder
Patrick Mokros
Empire is the platform's institutional anchor. The platform itself does not perform investor onboarding directly. The platform's investor portal (cedex.market) routes to Empire's onboarding dashboard. After Empire approves an investor, Empire signs the wallet-verification attestation that Control IV-15 reads on transfer.
11.2 The §17A Foundation
11.2.1 Statutory Basis
Section 17A of the Securities Exchange Act of 1934 establishes the framework for SEC registration of transfer agents. §17A-registered transfer agents are subject to:
Annual reporting (Form TA-1, TA-2, TA-W)
SEC Rule 17Ac2-1, 17Ac2-2
Recordkeeping
SEC Rule 17Ad-7
Safeguarding of securities
SEC Rule 17Ad-12
Cybersecurity / business continuity
SEC Rule 17Ad-22
Examination by SEC
Annual / risk-based
Empire's §17A registration is documented and maintained continuously. Empire's §17A status is the architectural prerequisite for Pillar 3 of Category 1 Model B.
11.2.2 Why §17A Custody Matters
Cryptocurrency-native custodians (BitGo, Fireblocks, Anchorage, etc.) provide custody services for digital assets. They are valuable infrastructure but are not §17A-registered transfer agents for traditional securities. They custody the digital token; they do not custody the underlying equity.
ERC-3643 deployments often use crypto-native custodians without §17A registration. This is a Category 2 architectural pattern under Release No. 33-11412 — the underlying equity is typically held by the issuer or a separate party, and the crypto-custody is a token-level overlay.
The platform's architecture instead anchors at §17A. Empire is the transfer agent for the underlying equity. The same Empire that custodies the Common Class B / SAE equity / BAE equity also operates the on-chain attestation layer. There is one institutional party that holds custody, maintains the legal register, performs onboarding, and signs attestations. This institutional unification is what eliminates the Category 2 third-party-custody-counterparty surface.
11.3 Sole Investor Onboarding Authority
11.3.1 Onboarding Scope (All Modules)
Empire is the sole authority for ST22 investor onboarding across all three modules. Empire performs:
Identity verification
Customer Identification Program (CIP) per §326 USA PATRIOT Act
KYC for individuals
FinCEN CDD; documentary + non-documentary verification
KYB for institutions
UBO identification per FinCEN CDD Rule (31 CFR 1010.230); entity formation documents review
AML
BSA / AML program; Chainalysis KYT integration; risk scoring
OFAC / SDN
Real-time SDN list match (re-verified hourly via SX-10 oracle)
Wallet control
Cryptographic challenge-response: investor signs Empire-issued challenge with wallet private key
Jurisdiction
Self-certification + corroborating documentation; sets HoldingPeriodAccount.jurisdiction
Accreditation (Reg D)
§501(a) accredited investor verification per Reg D Rule 501; income / net worth / professional certification path
Reg S non-US verification
Non-US residency documentation per Rule 902
Reg CF eligibility
JOBS Act §4(a)(6) per-investor annual limits; income/net-worth scaling per Rule 100(a)(2)
11.3.2 The Wallet-Verification Attestation
After Empire approves an investor, Empire creates an entry in its Master Securityholder File and signs a wallet-verification attestation that Control IV-15 (UnregisteredWallet) reads on transfer:
Control IV-15 verifies on every transfer that:
The wallet has an
EmpireWalletVerificationPDA (elseUnregisteredWallet)The Ed25519 signature is valid (verified via Solana native precompile)
KYC has not expired (
current_ts < kyc_expires_ts)The jurisdiction matches the investor's
HoldingPeriodAccount.jurisdiction
If any check fails, the transfer reverts. Empire's onboarding gate is thereby integrated into the runtime-enforced compliance layer.
11.4 Per-Slot Ed25519 Custody Attestation
11.4.1 The Attestation Cadence
Empire signs (mint, custodied_balance, class_label, slot) with its Ed25519 key every Solana slot (~400 ms). The signed attestation is submitted to the Custody Oracle PDA. Control CV-04 (Backing Class Match) verifies signature freshness and class consistency on every transfer.
11.4.2 Signing Infrastructure
Empire's signing infrastructure operates a continuous loop:
Continuous-loop architecture details:
Hot signing key stored in Hardware Security Module (HSM)
Multi-signer redundancy — three signing instances across separate cloud providers
Health monitoring — Datadog alerts on signing-loop failures
Priority-fee budget — reserved for SLA-critical attestations
Backup keys — cold storage; rotation procedure documented in Empire Stock Transfer Integration Guide §10
11.4.3 Attestation Failure Handling
If Empire's signing service fails:
Single-slot miss
Monitoring alert
None (1-slot tolerance per CV-02)
Auto-recover on next slot
Multi-slot miss (≥ 2 slots)
Monitoring alert
Control CV-02 starts rejecting transfers
Auto-recover on next valid attestation
Sustained failure (≥ 30 slots / ~12 sec)
Monitoring alert + PagerDuty
Control CV-40 halts affected category
Manual signing-service restart; auto-resume on resolution
Signing key compromise
External notification or anomaly detection
Manual freeze via Control 42 + governance key rotation
Backup-key activation with platform multi-sig
11.5 Master Securityholder File (MSF) and On-Chain Reconciliation
11.5.1 MSF Authority
The Empire MSF is the legally controlling shareholder register under W.S. 34-29-101 (Wyoming Digital Asset Statute). The on-chain SPL Token-2022 ledger is the transfer notification layer. The two are continuously reconciled via the Ed25519 attestation.
11.5.2 Reconciliation Architecture
In normal operation, all three layers are synchronized:
A token transfer on Solana triggers Transfer Hook execution
On success, on-chain balances update atomically
Empire's signing service detects the new state at next slot and signs an updated attestation
MSF records reflect the new state
If divergence occurs:
Empire is the legally controlling reference
Control 42 can be invoked to halt trading pending reconciliation
Reconciliation procedure documented in Incident Response Playbook §13
11.5.3 Why Reconciliation Per Slot
ERC-3643 reconciliation is typically periodic (daily, weekly). The platform's per-slot reconciliation provides:
Continuous integrity — divergence detection within ~400 ms
Strong audit trail — every slot has a signed attestation; full historical reconstruction possible
Mathematical Pillar 4 satisfaction — 1:1 backing is verifiable on every transfer, not just per-audit
Reduced attack surface — there is no "off-chain divergence window" during which an attacker could exploit balance mismatches
11.6 Cross-Module Custody — One Gate, Three Asset Classes
Empire's §17A authority extends across all three modules. The same onboarding gate covers Module 1, Module 2, and Module 3:
Module
Custodied Class
class_label
Backing Verification Path
Module 1
Common Class B
AssetClass::CommonB
Empire MSF Common B balance
Module 2
SAE common stock
AssetClass::SAE
Empire MSF SAE equity balance + NAV oracle (Section 9)
Module 3
BAE common stock
AssetClass::BAE
Empire MSF BAE equity balance + Classification oracle (Section 10)
The investor goes through Empire onboarding once and can hold ST22 tokens across all three modules without re-onboarding. KYC re-verification is required per Empire's standard cadence (typically annual). Reg D accreditation re-verification is required per the Reg D standard (annually). Reg CF investor limits are tracked per investor across all CF investments (not just platform investments) per Empire's data sharing with the funding portal partner.
11.6.1 Module-Specific Custody Operations
Custody intake
Common Class B paper certificate or electronic record
SAE common stock certificate; corporate documents
BAE common stock certificate; corporate documents + basin documentation
CUSIP issuance
Yes (M1 standard)
Property ID assigned (not CUSIP)
Basin ID assigned (not CUSIP)
Corporate-actions handling
Standard transfer agent corporate actions (dividends, splits, conversions)
SAE corporate actions (dividends to ST22 holders; reorganization scenarios)
BAE corporate actions (federal-action coordination; reorganization scenarios)
§17A reporting
Form TA-1 / TA-2 disclosure
Form TA-1 / TA-2 disclosure
Form TA-1 / TA-2 disclosure
11.7 Empire's Independence
A critical compliance property: Empire is operationally independent of Groovy Company. Empire is a separate entity with its own §17A registration, its own KYB processes, and its own examination obligations. The platform operates under tripartite governance for Module 2 NAV-band parameters and Module 3 Classification parameters, where Empire's signature is one of three required.
Empire's independence:
Eliminates the platform's ability to bypass Empire (no shortcut path exists)
Protects investors from platform-driven custody manipulation
Provides regulatory comfort that custody is at arms-length from the platform operator
Ensures Empire's signing key cannot be compromised by platform code
The CTO of Groovy Company, Frank Yglesias, also serves as Chairman & CTO. Patrick Mokros is COO of Groovy Company AND the Founder of Empire Stock Transfer. The relationship between the two entities is documented and structurally arms-length per their respective governance documents. The on-chain architecture's tripartite governance for module-specific parameters embeds this independence in the runtime.
11.8 Empire and Each Pillar of Category 1 Model B
1. Direct Issuer Authorization
Empire's KYB process verifies issuer board authorization before mint creation
2. Official Shareholder Register on DLT
Empire MSF is the legally controlling register; reconciled per slot to on-chain ledger
3. SEC §17A-Registered Qualified Custody
Empire IS the §17A-registered custodian (this pillar)
4. True Equity Backing 1:1
Empire's per-slot Ed25519 attestation feeds Custody Oracle; verified by Control CV-01
5. Clear Ownership Chain
Empire holds the equity; CUSIP / property ID / basin ID linkage flows from Empire's records
6. Investor Protection
Empire's onboarding gate is the entry point; ongoing compliance via Empire-provided attestations and re-verifications
7. Token Standard Immutability
Architectural — not Empire's role, but Empire-anchored architecture is what makes immutability viable for compliance
Empire is involved in 6 of 7 pillars directly. The seventh (immutability) is structural and depends on the SPL Token-2022 standard's runtime properties.
11.9 Empire-Specific Risk Mitigation
Empire signing key compromise
HSM custody; multi-signer redundancy; key rotation procedure; manual freeze via Control 42 on detection
Empire operational failure (extended)
Failover signing infrastructure; Control CV-40 halts on consensus failure; backup §17A-registered custodian relationship documented but not active
Empire-platform divergence
MSF is controlling; reconciliation per Incident Response Playbook §13
Empire regulatory action
Continuity plan; backup §17A custodian relationship; Control 42 halt during transition
KYC database breach at Empire
Empire's data security per Rule 17Ad-22; encrypted storage; on-chain attestation does not store PII
11.10 Empire's Differentiation vs Crypto-Native Custodians
§17A registration
No
Yes
Custody object
Token (digital)
Underlying equity (legal)
Investor onboarding scope
Often token-only
Full KYC/KYB/AML/OFAC/Reg D/Reg CF
Per-slot attestation
Not standard
Yes — architectural integration
Master register
No
Yes — MSF
Reg D accreditation verification
Limited
Yes
§17A reporting
Not applicable
Annual to SEC
Cross-asset-class scope (M1 + M2 + M3)
Token type only
All three modules
For Category 1 Model B compliance, §17A custody is the architectural requirement. Crypto-native custodians are valuable for token-level operations but cannot substitute for §17A custody. Empire's role spans both layers — it operates §17A custody of the underlying equity AND the cryptographic attestation layer that integrates with the on-chain compliance program.
RWA Tokens Whitepaper V10 — Section 11 — Confidential — Groovy Company, Inc.
Last updated
Was this helpful?