# Empire Stock Transfer Integration ### Empire Stock Transfer Integration **Qualified Custodian · Sole Investor Onboarding Authority · Ed25519 Attestation · Master Securityholder File** Deep-dive into the regulatory and technical integration between the platform and Empire Stock Transfer — the SEC §17A-registered entity that holds every Common Class B share, verifies every investor, and signs every custody attestation that makes the 42 Transfer Hook controls function. This integration applies across all three production modules: Equities (Module 1), Real Estate (Module 2), and CORECM — Carbon Ore, Rare Earth, and Critical Minerals (Module 3). Empire is not a vendor. Empire is load-bearing infrastructure. Without Empire, no ST22 token can exist. The platform is operated by Groovy Company, Inc. The trading venue is CEDEX. Empire Stock Transfer (Patrick Mokros, Founder) is the sole §17A-registered transfer agent and qualified custodian for all three RWA Tokens product modules. *** #### Table of Contents 1. Empire's Dual Role 2. Regulatory Foundation 3. Custody Architecture 4. Ed25519 Attestation Lifecycle 5. Master Securityholder File 6. Investor Onboarding Flow 7. KYC — Individual Verification 8. KYB — Entity Verification 9. AML and OFAC Screening 10. Wallet Verification (KYW) 11. Accredited Investor Verification 12. Transfer Hook Integration Map 13. Protective Conversion Mechanics 14. Tripartite Agreement Structure 15. Conflict of Interest Disclosure 16. Empire Operational Continuity 17. Module-Aware Custody Coverage *** #### 1. Empire's Dual Role Empire Stock Transfer serves two distinct functions in the platform's architecture. Both are mandatory for Category 1 Model B compliance. Neither can be replaced by the platform or any other component. RoleScopeRegulatory BasisReplaceable? **Qualified Custodian** Holds all Common Class B shares in irrevocable, perpetual custody. Signs Ed25519 attestations every Solana block (\~400ms). Maintains authoritative share count. SEC Exchange Act §17A No — custody must be performed by a §17A-registered entity **Sole Investor Onboarding Authority** Performs all KYC (individuals), KYB (entities), AML (Chainalysis KYT plus TRM Labs), OFAC/SDN screening, accreditation verification, and wallet registration. BSA CIP (31 CFR §1020.220), FinCEN CDD Rule, Reg D Rule 501 No — the platform does not perform onboarding **Why this architecture exists:** Category 1 Model B requires that investor verification and custody are performed by a regulated entity with §17A obligations — not by the platform operator. If the platform performed investor onboarding, the architecture would be Category 2 (third-party sponsored) with counterparty risk. Empire's independence is the structural guarantee that eliminates counterparty risk. **What the Platform Does NOT Do** FunctionPerformed ByPlatform Role Hold investor assets Empire Stock Transfer None — the platform holds no shares Verify investor identity Empire Stock Transfer Portal routes to Empire dashboard Store KYC/KYB documents Empire Stock Transfer The platform has no access to investor PII File SARs with FinCEN Empire Stock Transfer The platform provides transaction analytics Make accreditation determinations Empire Stock Transfer The platform enforces via Transfer Hook (Control 12) Maintain shareholder records Empire Stock Transfer (MSF) Solana blockchain serves as notification layer *** #### 2. Regulatory Foundation **Empire's Registrations** RegistrationAuthoritySinceScope **Transfer Agent** SEC, Exchange Act §17A 2006 Shareholder record maintenance, proxy distribution, dividend disbursement, ownership transfer **Qualified Custodian** SEC custody requirements Operating Irrevocable custody of securities on behalf of beneficial owners **Regulatory Obligations** RequirementCFR ReferenceImplementation Customer Identification Program (CIP) 31 CFR §1020.220 Four-pillar identity verification at onboarding Customer Due Diligence (CDD) 31 CFR §1010.210 Risk-based assessment at onboarding plus ongoing Beneficial Ownership 31 CFR §1010.230 UBO identification at 25% or higher for entities Suspicious Activity Reports (SARs) 31 CFR §1010.320 Filing for transactions at $5,000 or above meeting BSA criteria Currency Transaction Reports (CTRs) 31 CFR §1010.311 Filing for fiat transactions at $10,000 or above Recordkeeping 31 CFR §1010.410 5-year retention for KYC, KYB, and AML records OFAC Screening Executive Orders plus 31 CFR Parts 500–598 Real-time SDN screening at onboarding plus hourly refresh Transfer Agent Rules 17 CFR §§240.17Ad-1 through 17Ad-22 Timely processing, recordkeeping, safeguarding **Empire's Credentials** AttributeDetail SEC registration Section 17A of the Securities Exchange Act of 1934 Operating since 2006 Companies served 530+ publicly traded companies Geographic scope Operations across 5 continents DLT integration Master Securityholder File with blockchain notification layer (Category 1 Model B) *** #### 3. Custody Architecture **Custody Flow** Copy ``` ISSUER │ ├─ Board resolution authorizing Common B creation ├─ Certificate of Designation filed with Secretary of State │ ▼ EMPIRE STOCK TRANSFER — IRREVOCABLE CUSTODY │ ├─ Common B shares deposited ├─ CUSIP assigned to share class ├─ Shares recorded in Master Securityholder File ├─ Ed25519 attestation key activated ├─ Oracle relay begins publishing per-block attestations │ ▼ ON-CHAIN (Solana) │ ├─ CustodyOracle PDA created: [b"custody-oracle", mint] ├─ Empire Ed25519 public key registered ├─ Attestation: common_b_balance ≥ token_supply (every ~400ms) │ ▼ TRANSFER HOOK — Control 1 │ └─ Every ST22 transfer: verify supply ≤ custodied shares └─ Discrepancy → Error 6001 → ALL transfers halt ``` **Custody Properties** PropertySpecification **Custody type** Irrevocable — shares cannot be withdrawn by the issuer **Duration** Perpetual — no expiration, no termination by issuer **Custodian independence** Empire is an independent entity — not owned by Groovy Company, Inc. **Segregation** Common B shares segregated per issuer — no commingling **Insurance** Per Empire's §17A insurance requirements **Audit** Quarterly independent custody audit published on-chain **CUSIP** Each Common B share class receives a unique CUSIP identifier (Module 1); property identifier (Module 2); basin identifier (Module 3) **Attestation** Ed25519 signed per Solana block (\~400ms) **What "Irrevocable" Means** Once Common B shares are deposited with Empire, the issuer cannot withdraw them. This is not a policy — it is a contractual commitment in the tripartite agreement. The only way shares leave custody is through protective conversion (Controls 35–38), which converts them to common stock delivered to shareholders — not returned to the issuer. This irrevocability is what makes the 1:1 backing guarantee credible. If the issuer could withdraw shares at any time, the custody attestation would be meaningless — the issuer could empty the custody account and leave token holders with worthless tokens. Irrevocable custody eliminates this attack vector by design. *** #### 4. Ed25519 Attestation Lifecycle **How It Works** Empire Stock Transfer signs a custody balance attestation on every Solana block (\~400ms). The signed payload is submitted to the on-chain CustodyOracle account by the platform's relay service. The Transfer Hook reads this account on every ST22 transfer (Control 1). **Attestation Payload** Copy ``` ┌──────────────────────────────────────────────────────┐ │ Ed25519 SIGNED PAYLOAD (64 bytes) │ ├──────────────────────────────────────────────────────┤ │ mint: Pubkey (32 bytes) │ │ common_b_balance: u64 ( 8 bytes) │ │ token_supply: u64 ( 8 bytes) │ │ slot: u64 ( 8 bytes) │ │ timestamp: i64 ( 8 bytes) │ ├──────────────────────────────────────────────────────┤ │ SIGNED BY: Empire Ed25519 private key (HSM-backed) │ │ VERIFIED BY: Solana Ed25519 precompile (~120 CU) │ └──────────────────────────────────────────────────────┘ ``` **Attestation Lifecycle** Copy ``` 1. EMPIRE INTERNAL Empire custody system calculates current Common B share count per issuer (per mint). System runs continuously. 2. EMPIRE SIGNS Empire HSM signs the 64-byte payload with Ed25519 private key. One signature per mint per Solana block. 3. RELAY TRANSMITS The platform's custody relay service fetches signed attestation from Empire API. Relay submits update_custody_oracle transaction to Solana. 4. ON-CHAIN VERIFICATION The Oracle Aggregator program: ├─ Verifies Ed25519 signature via Solana precompile ├─ Verifies slot is current (≤1 slot old) ├─ Updates CustodyOracle account state └─ If common_b_balance < token_supply: └─ Sets discrepancy_detected = true └─ Emits CustodyDiscrepancyDetected event 5. TRANSFER HOOK READS (every transfer) Control 1: ├─ Is oracle valid? (Ed25519 verified) ├─ Is oracle fresh? (≤1 slot) ├─ supply ≤ balance? (zero tolerance) └─ Any discrepancy? (halt if true) ``` **Attestation Security Properties** PropertyMechanism **Authentication** Ed25519 — only Empire's HSM-backed private key can produce valid signatures **Freshness** Slot number in payload — stale attestations rejected (above 1 slot returns Error 6002) **Replay prevention** Slot plus timestamp — captured attestations cannot be replayed in future blocks **Tamper detection** Signature covers all payload fields — any modification invalidates signature **Independence** Empire signs; the platform's relay transmits; Solana verifies. No single entity controls all three. **Public verifiability** Empire's public key is registered on-chain. Anyone can verify attestation signatures independently. **Key Lifecycle** PhaseProcess **Key generation** Empire generates Ed25519 keypair on HSM (hardware security module) **Key registration** Empire public key registered in CustodyOracle account at oracle initialization **Key usage** Empire signs every attestation with private key. Relay submits. Solana verifies with registered public key. **Key rotation** Empire generates new keypair → communicates new public key to the platform → governance proposal to update on-chain → 48h timelock → 3-of-5 multi-signature executes → old key deauthorized **Key compromise** Immediate: halt all transfers (Control 42). Empire revokes key. New key registered. 2-of-3 oracle consensus before resume. **2-of-3 Oracle Consensus** For discrepancy resolution and post-halt resume, 2-of-3 independent sources must agree: SourceTypeAuthority **Primary** Empire Ed25519 per-block attestation Authoritative — Empire holds the shares **Secondary** Platform internal verification node Cross-references Empire data against on-chain supply **Tertiary** Quarterly third-party audit (published on-chain) Independent institutional confirmation **Production Record** Zero discrepancy events across three beta issuers (GROO, GRLF, MSPC) and over $7M in processed liquidity. The 1:1 backing ratio has been maintained at every block with zero exceptions. This record reflects the integrity of Empire's custody operations and the reliability of the attestation architecture. *** #### 5. Master Securityholder File **What Is the MSF?** The Master Securityholder File is the authoritative, legally binding record of all Common Class B share ownership. Maintained by Empire Stock Transfer. It IS the official shareholder register for all ST22-backed securities across Modules 1, 2, and 3. Under Category 1 Model B, the Solana blockchain serves as the operational notification layer — not the legal record of ownership. Empire's MSF is the legal record. The blockchain notifies Empire of transfers, and Empire updates the MSF accordingly. **Legal Basis** Every ST22 transfer on CEDEX constitutes an effective entitlement order under UCC Article 8 (§8-102(a)(8)), triggering an update to the MSF. Wyoming Digital Asset Statute (W\.S. 34-29-101) provides additional statutory support for DLT-based securities ownership records. **MSF Update Flow** Copy ``` INVESTOR A sells ST22 tokens to INVESTOR B on CEDEX │ ▼ SOLANA: Token-2022 transfer executes (with Transfer Hook — 42 controls pass) │ ├─ TransferValidated event emitted on-chain │ ▼ EMPIRE NOTIFICATION LAYER │ ├─ Platform backend detects TransferValidated event ├─ Constructs UCC Article 8 entitlement order ├─ Submits to Empire MSF API │ ▼ EMPIRE STOCK TRANSFER │ ├─ Validates entitlement order ├─ Updates Master Securityholder File: │ Investor A: balance decreased by transfer amount │ Investor B: balance increased by transfer amount ├─ Confirms update │ ▼ MSF STATE NOW REFLECTS ON-CHAIN STATE │ └─ Next custody attestation (≤400ms) reflects updated balances ``` **MSF Data Architecture** FieldDescriptionSource **Investor legal name** Full name as verified during KYC/KYB Empire CIP **Investor wallet address** Solana wallet linked to verified identity Empire KYW **Mint address** ST22 token mint (Common B share class) Platform mint creation **Share balance** Number of Common B shares held On-chain balance (authoritative) **CUSIP / property identifier / basin identifier** Securities or asset identifier for the Common B class Empire issuance record **Jurisdiction** US (Reg D) or Non-US (Reg S) or US retail (Reg CF) Empire onboarding determination **Accreditation status** Verified accredited; non-US person; or Reg CF investor Empire verification **KYC expiry** Date KYC verification expires Empire records **Holding period start** Date tokens were delivered On-chain HoldingPeriodAccount *** #### 6. Investor Onboarding Flow **End-to-End Process** Copy ``` INVESTOR visits portal.rwatokens.net │ ├─ Selects issuer / property / basin asset (Module 1, 2, or 3) ├─ The platform Portal routes to Empire Stock Transfer │ verification dashboard │ ▼ EMPIRE VERIFICATION (sole onboarding authority) │ ├─ Step 1: Identity verification (KYC or KYB) │ ├─ Individual: government ID, address, SSN/passport │ └─ Entity: formation docs, UBO identification, EIN │ ├─ Step 2: Accreditation verification (where applicable) │ ├─ US accredited: income or net worth or professional cert │ ├─ Non-US: non-US person verification under Reg S │ └─ US retail: Reg CF eligibility verification │ ├─ Step 3: AML screening │ ├─ Chainalysis KYT wallet risk score │ └─ TRM Labs behavioral analysis │ └─ Score 0–30: approve | 31–70: enhanced review | 71–100: reject │ ├─ Step 4: OFAC/SDN screening │ ├─ Layer 1: exact wallet address match │ ├─ Layer 2: fuzzy entity name match │ └─ Layer 3: 2-hop transaction graph clustering │ ├─ Step 5: Wallet verification (KYW) │ ├─ Investor provides Solana wallet address │ ├─ Empire sends Ed25519 signature challenge │ ├─ Investor signs with wallet private key │ └─ Empire registers wallet in MSF + Transfer Hook whitelist │ ▼ EMPIRE DETERMINATION │ ├─ APPROVED → investor can participate in ST22 offering │ ├─ Wallet added to Empire's verified registry │ ├─ On-chain: wallet whitelisted for Transfer Hook Controls 7–14 │ └─ Investor proceeds to stablecoin purchase (USDC/PYUSD) │ ├─ ENHANCED REVIEW → additional documentation required │ └─ AML score 31–70 triggers manual review (24h SLA) │ └─ REJECTED → investor cannot participate ├─ AML score 71–100 → wallet blocked ├─ OFAC match → wallet permanently blocked └─ KYC failure → may reapply with correct documentation ``` *** #### 7. KYC — Individual Verification Empire Stock Transfer performs all individual identity verification per BSA CIP requirements (31 CFR §1020.220). **Required Information** FieldRequiredVerification Method Full legal name Yes Government-issued photo ID Date of birth Yes Government ID match Residential address Yes (no P.O. boxes) Utility bill or bank statement (under 90 days) SSN/TIN (US persons) Yes Database verification (LexisNexis or equivalent) Passport number (non-US) Yes Document verification plus country of issuance Email address Yes Email confirmation Phone number Yes SMS verification Solana wallet address Yes Ed25519 signature challenge (KYW) **Accepted Documents** Document TypeUS PersonsNon-US Persons Government-issued photo ID Driver's license, state ID, passport Passport (required) Address proof Utility bill, bank statement (under 90 days) Same Liveness verification Biometric selfie match Same **Re-Verification** KYC is not one-time. Empire re-verifies investors periodically and on trigger events: TriggerAction KYC expiry (annual) Re-verification required — Transfer Hook Control 14 blocks expired KYC Material change (name, address, citizenship) Update required — investor provides new documentation AML score change (crosses threshold) Automatic re-review by Empire compliance OFAC SDN list update Re-screening on every transfer (Controls 8–10) Unusual transaction pattern Enhanced review triggered by platform analytics *** #### 8. KYB — Entity Verification For corporate, fund, trust, and other non-individual investors. Per FinCEN Beneficial Ownership Rule (31 CFR §1010.230). **Required Information** FieldRequiredVerification Method Legal entity name Yes Formation documents DBA names If applicable State registration Principal business address Yes Business utility bill or lease EIN/TIN Yes IRS confirmation letter State or country of formation Yes Articles of incorporation or organization Entity type Yes Formation documents Authorized signatories Yes Board resolution or operating agreement Ultimate Beneficial Owners (25% or higher) Yes UBO declaration plus identity verification per KYC **UBO Requirements** Every individual who directly or indirectly owns 25% or more of the entity must be identified and verified through the same KYC process as individual investors. This includes government-issued ID, residential address, and SSN or passport. *** #### 9. AML and OFAC Screening **AML — Dual-Provider Architecture** Empire integrates two independent blockchain analytics providers. The higher score determines disposition. ProviderCapabilitiesIntegration **Chainalysis KYT** Industry standard. Widest entity coverage. Law enforcement data. REST API per-wallet **TRM Labs** 200+ behavioral features. Strong emerging threat detection. REST API per-wallet **AML Risk Disposition** ScoreTierOnboardingTradingSAR Trigger 0–30 Low risk Approved Transfer Hook approves No 31–70 Medium risk Enhanced review (24h) Approved but flagged — compliance reviews within 24h If investigation confirms suspicious activity 71–100 High risk Rejected Transfer Hook rejects (Error 6006) Yes — SAR filed if at $5,000 or above **OFAC — Three-Layer Screening** LayerMethodCatches **1: Exact address** Direct Solana wallet match against SDN addresses Directly sanctioned wallets **2: Fuzzy entity** Entity name and alias matching via Chainalysis entity resolution Slight name variations ("ACME Corp" versus "ACME Corporation LLC") **3: 2-hop clustering** Transaction graph analysis — wallets within 2 degrees of SDN entities Proxy wallet strategies, indirect funding paths **Continuous versus Onboarding Screening** CheckpointWhenPerformed By **Onboarding** Once — at initial verification Empire Stock Transfer **Every transfer** Continuous — on every ST22 transfer Transfer Hook Controls 8–10 (on-chain) **SDN list refresh** Hourly plus emergency push Platform OFAC oracle indexer A wallet that was clean at onboarding but later added to the SDN list is blocked immediately on its next transfer attempt. This continuous re-screening is architecturally impossible in an application-layer compliance system — the Transfer Hook enforces it at the Solana runtime level. *** #### 10. Wallet Verification (KYW) **Purpose** Every Solana wallet that will hold ST22 tokens must be cryptographically linked to a verified identity in Empire's Master Securityholder File. Unregistered wallets cannot receive ST22 tokens — the Transfer Hook rejects all transfers to unverified wallets (Control 15). **Verification Process** Copy ``` 1. Investor provides Solana wallet address to Empire during onboarding 2. Empire sends Ed25519 signature challenge: "EMPIRE-KYW-{timestamp}-{random_nonce}" 3. Investor signs the challenge with their wallet's private key (proving they control the wallet) 4. Empire verifies the signature matches the provided wallet address 5. Empire registers the wallet in: ├─ Master Securityholder File (legal record) └─ Transfer Hook whitelist (on-chain enforcement) 6. Wallet can now receive ST22 tokens ``` **One Wallet Per Identity** Each verified identity is linked to a specific Solana wallet address. If an investor needs to change wallets (for example, lost key or hardware wallet upgrade), they must re-verify with Empire, and the old wallet is deregistered. *** #### 11. Accredited Investor Verification **US Persons — SEC Rule 501** Empire verifies accreditation using one of these qualification paths: PathThresholdAccepted Documentation **Income** $200,000 individual ($300,000 joint) in each of the 2 most recent years IRS W-2, 1099, K-1, tax returns **Net worth** $1,000,000 or more excluding primary residence Broker statements, bank statements, property appraisals **Professional certification** Series 7, 65, or 82 license FINRA BrokerCheck verification **Entity** $5,000,000 or more in assets, or all equity owners accredited Audited financials, formation documents **Knowledgeable employee** Of the private fund issuer Employer certification **Third-party letter** Valid for 90 days CPA, attorney, registered broker-dealer, or investment adviser letter **Non-US Persons — Reg S** Empire verifies that the investor is not a "U.S. person" per Reg S §230.902(k): * Not a natural person resident in the United States. * Not a partnership or corporation organized under US law. * Not an estate or trust with a US executor, administrator, or trustee. * Transaction occurs in an "offshore transaction." **US Retail — Reg CF** For Reg CF offerings, Empire applies the SEC Rule 100(a)(2) investment-limit determination based on the investor's annual income and net worth, plus the FINRA-registered funding portal's intermediation requirements. **On-Chain Enforcement** Empire's verification determination is reflected on-chain. Transfer Hook Controls 12 through 14 check the investor's status on every transfer. If accreditation lapses or KYC expires, transfers are blocked until re-verification. *** #### 12. Transfer Hook Integration Map Every Transfer Hook control that depends on Empire data: ControlEmpire Data SourceUpdate FrequencyError on Failure **1–6 (Custody)** Ed25519 custody attestation Every block (\~400ms) 6001 / 6002 **7 (KYC Status)** Empire verified investor registry At onboarding plus re-verification 6003 **8 (Accreditation)** Empire accreditation determination At onboarding plus annual refresh 6003 **9 (AML)** Chainalysis plus TRM via Empire integration Per transfer (cached 6h) 6006 **10 (Identity)** Empire CIP verification At onboarding 6003 **11 (Jurisdiction)** Empire Reg D / Reg S / Reg CF determination At onboarding 6003 **12 (Age)** Empire DOB verification At onboarding 6003 **13 (Classification)** Empire investor type classification At onboarding 6003 **14 (Expiry)** Empire KYC expiry date Continuous — blocks expired 6003 **15 (Wallet)** Empire MSF wallet registration At KYW plus wallet changes 6004 **24 (Holding Period)** Empire jurisdiction flag (US / Non-US / Reg CF) Set at onboarding — immutable 6024 **30–34 (OFAC)** Empire onboarding plus platform oracle (continuous) Hourly refresh plus per-transfer 6003–6005 **35–38 (Protective Conversion)** Empire custody records plus adverse event triggers Event-driven 6008 **Data Flow Summary** Copy ``` EMPIRE STOCK TRANSFER │ ├──── Custody balance ────────► CustodyOracle (on-chain, per block) │ └─► Control 1 reads per transfer │ ├──── Investor registry ──────► Controls 7–14 read per transfer │ (KYC, KYB, accreditation, (whitelist + status checks) │ jurisdiction, wallet) │ ├──── AML scoring ────────────► AMLOracle (on-chain, cached 6h) │ (via Chainalysis + TRM) └─► Control 9 reads per transfer │ ├──── OFAC screening ─────────► OFACOracle (on-chain, hourly) │ (onboarding + continuous) └─► Controls 30–34 per transfer │ └──── Adverse event triggers ─► Controls 35–38 (protective conversion) (bankruptcy, enforcement, loss of services) ``` *** #### 13. Protective Conversion Mechanics Controls 35 through 38 implement automatic conversion of Common B shares to common stock upon defined adverse events — protecting investors even if the issuer or the platform fails. **Trigger Events** ControlTriggerDetectionAction **PC-35** Issuer bankruptcy filing EDGAR 8-K detection (Layer 9) plus manual notification Common B automatically converts to common stock per Certificate of Designation **PC-36** SEC enforcement action or criminal indictment of officer or director EDGAR 8-K detection plus SEC notification Same — automatic conversion **PC-37** Loss of Empire Stock Transfer services Empire notification plus operational detection Same — custody transfers to successor entity **PC-38** Material breach of tripartite agreement Determination by the platform plus Empire Conversion at discretion of non-breaching parties **Conversion Mechanics** Copy ``` TRIGGER EVENT DETECTED │ ├─ On-chain: Controls 35–38 activate │ └─ ST22 transfers for affected mint halted (preventive) │ ├─ Off-chain: Empire initiates conversion process │ ├─ Empire updates MSF: Common B shares → Common A shares │ ├─ Investors now hold common stock (not tokenized) │ ├─ Standard transfer agent processes apply │ └─ Investors can exercise shareholder rights directly │ └─ Result: investor equity claim survives issuer distress regardless of blockchain infrastructure status ``` **Why This Matters** Protective conversion is the safety valve separating Category 1 Model B from Category 2. In a Category 2 architecture, if the platform fails, investors may be left holding tokens with no underlying claim. In Category 1, protective conversion ensures investors retain genuine equity ownership (common stock held at Empire) even if the platform, CEDEX, and the entire Solana blockchain ceased to exist. *** #### 14. Tripartite Agreement Structure **Three Parties** PartyResponsibilities **Issuer** Board resolution, Certificate of Designation, share deposit, ongoing SEC reporting, cooperation with regulatory inquiries **Groovy Company, Inc.** Technical infrastructure (ST22 minting, Transfer Hook, CEDEX, oracle relays), platform operations, compliance monitoring **Empire Stock Transfer** Irrevocable custody, investor onboarding (KYC, KYB, AML, OFAC), MSF maintenance, Ed25519 attestation, regulatory compliance **Key Terms** TermDetail **Custody** Irrevocable, perpetual. Empire cannot release shares to issuer. **Attestation** Empire authorizes Ed25519 signing per Solana block **Fee structure** 5% of all ST22 transactions (distribution per fee config) **Onboarding authority** Empire is sole investor onboarding authority — non-negotiable **Data handling** Investor PII stays at Empire. The platform receives verification status only. **Termination** Triggers protective conversion (Control 37). No unilateral termination without investor protection. **Dispute resolution** Governed by the State of Wyoming **Duration** Co-terminous with ST22 token existence. No expiration. *** #### 15. Conflict of Interest Disclosure **Patrick Mokros serves as both Chief Operating Officer of Groovy Company, Inc. and Founder of Empire Stock Transfer.** This dual role is fully disclosed. **Disclosure Framework** AspectHandling **Public disclosure** Disclosed in all SEC filings (10-K, 10-Q, 8-K), whitepaper, pitch deck, and legal documents **Related party transactions** All transactions between Groovy Company, Inc. and Empire Stock Transfer automatically classified as related party transactions **Approval requirement** Material Empire-related decisions require Audit Committee review per the platform's Related Party Policy **Fee arrangements** Standard custody and onboarding fees — modified fee arrangements require CEO and Compliance Officer approval **Equity or partnership arrangements** Require full Board approval **Why the Dual Role Exists** The dual role provides an operational advantage: direct coordination between platform operations and custody / onboarding operations without inter-company communication latency. For a platform that requires per-block custody attestation (\~400ms), this tight integration is architecturally valuable. The conflict is managed through disclosure, governance controls, and the structural independence of Empire's §17A regulatory obligations — Empire's regulatory duties to its registered companies exist independently of any relationship with Groovy Company, Inc. *** #### 16. Empire Operational Continuity **What Happens If Empire Services Are Disrupted?** ScenarioImpactResolution **Empire API temporary outage** Custody relay stops updating → oracle stales → Error 6002 after 1 slot Transfers halt automatically. Resume when API recovers. **Empire API extended outage (over 24h)** All ST22 transfers halted P0 incident. Direct Empire coordination. Backup attestation from quarterly audit data. **Empire business disruption** Control 37 trigger — protective conversion Common B converts to common stock. Investors hold equity at successor entity. **Empire regulatory action** Control 36 trigger — protective conversion Same — conversion protects investors. **Empire key compromise** False attestations possible Immediate Control 42 freeze. Empire revokes key. New key registered. 2-of-3 consensus before resume. **Successor Custodian** If Empire Stock Transfer ceases operations or loses §17A registration, the tripartite agreement requires designation of a successor transfer agent and custodian. Common B shares transfer to the successor, and the MSF transfers with them. Investors retain equity ownership throughout the transition. The protective conversion mechanism (Control 37) activates automatically, converting tokenized Common B shares to standard common stock — ensuring investor rights are protected even during the transition period when no custody attestation is available. *** #### 17. Module-Aware Custody Coverage Empire's role is identical in structure across the three RWA Tokens production modules — every module uses Common Class B custody, Ed25519 attestation, KYC / KYB / AML / OFAC onboarding, and the same MSF data architecture. The module-specific differences sit at the asset-class layer, not the custody layer. **17.1 Module 1 — Equities** **Asset class.** Public-company equity securities sourced from OTC microcap, NASDAQ, AMEX, TSX, and other global exchanges. **Empire's specific role.** Empire holds the issuer's Common Class B shares per the tripartite agreement, assigns the CUSIP, performs standard accreditation verification, and signs custody attestations every Solana block. **Module-specific onboarding considerations.** Standard accreditation paths (Reg D income, net worth, professional certification, entity tests; Reg S non-US person determination; Reg CF eligibility for retail offerings). **MSF metadata.** CUSIP, issuer name, share class, accreditation tier, jurisdiction. **Custody attestation cadence.** Every block (\~400ms), identical to all other modules. **17.2 Module 2 — Real Estate** **Asset class.** Tokenized real-property assets held via single-asset entities. **Empire's specific role.** Empire holds the Common Class B shares of the single-asset entity (the entity that holds title to the real-property asset). The economic exposure is to the single-asset entity's equity, which in turn holds the property. **Single-asset entity structure.** Each Module 2 issuance corresponds to one single-asset entity (typically a Nevada corporation or comparable structure). The Certificate of Designation authorizes the Common Class B share class. Empire's custody is of the entity's equity, not of the property itself; the property is held by the entity per its title documentation. **Module-specific onboarding considerations.** Standard accreditation paths apply. Module 2 issuances typically pair with a property identifier and appraisal-cycle metadata in the MSF. **MSF metadata.** Property identifier, jurisdiction of the single-asset entity, share class, accreditation tier, current NAV reference, last appraisal date. **Custody attestation cadence.** Every block (\~400ms), identical to all other modules. The Module 2 NAV oracle is a separate per-mint oracle that exists alongside Empire's custody attestation — the NAV oracle reports appraised value; Empire's custody attestation continues to report 1:1 backing of Common B shares. **17.3 Module 3 — CORECM** **Asset class.** Tokenization of US strategic minerals supply chain. CORECM means Carbon Ore, Rare Earth, and Critical Minerals. Frameworks include the USGS Critical Minerals List, the DOE Critical Materials Strategy, Section 232 of the Trade Expansion Act of 1962, Title III of the Defense Production Act, the Inflation Reduction Act critical-minerals provisions, Executive Order 14017, and the Energy Act of 2020. Carbon Ore covers DOE coal-derived rare-earth element recovery. **Empire's specific role.** Empire holds the Common Class B shares of the basin-asset entity (the entity that holds the mineral basin or mining concession). As with Module 2, custody is of the entity's equity, not of the underlying physical asset. **Module-specific onboarding considerations.** Empire applies enhanced KYC depth for Module 3 issuances. Enhanced depth includes verification of any federal-program eligibility constraints applicable to the basin (such as DOE coal-derived REE recovery program participation), confirmation of the investor's eligibility under any applicable export-control regime, and additional review for entity-investor UBO chains where federal counter-party diligence is appropriate. **MSF metadata.** Basin identifier, USGS classification, mineral class, jurisdiction of the basin-asset entity, share class, accreditation tier, federal-action status. **Custody attestation cadence.** Every block (\~400ms), identical to all other modules. The Module 3 Classification oracle is a separate per-mint oracle that exists alongside Empire's custody attestation — the Classification oracle reports federal classification status; Empire's custody attestation continues to report 1:1 backing of Common B shares. **Federal-action coordination.** Empire is a coordinating party in the Module 3 federal-action freeze runbook (Incident Response Playbook Section 13). When a federal action is issued affecting a basin asset, Empire is notified within the 15-minute response SLA and participates in the protective response. **17.4 Cross-Module Custody Properties** Identical across modules: * Irrevocable, perpetual Common Class B custody at Empire. * Per-block Ed25519 custody attestation. * 1:1 backing invariant enforced by Transfer Hook Control 1. * KYC, KYB, AML, OFAC, and KYW onboarding authority resides solely with Empire. * MSF as the legal record of ownership; blockchain as notification layer. * Tripartite agreement structure (Issuer, Groovy Company, Inc., Empire). * Protective conversion mechanics (Controls 35 through 38). * Successor-custodian provisions for operational continuity. The platform's structural guarantee — that no investor depends on the platform's solvency or operational continuity for their underlying equity claim — applies identically across all three modules because Empire's role applies identically. *** #### Related Documentation * **Solana Blockchain Foundation** — Why Solana, Token-2022, Transfer Hook, module-specific foundations * **Architecture Decisions** — ADR-001 through ADR-012, with ADR-012 specifically covering Empire as sole onboarding authority * **Security Model** — Threat model, key management, formal verification, module-specific threat surfaces, bug bounty * **Infrastructure Overview** — Cloud architecture, environment separation, blockchain infrastructure * **Network Configuration** — Program addresses, RPC endpoints, oracle PDAs, multi-signature addresses, production parameters * **Deployment Guide** — Build, deploy, verify, upgrade, rollback procedures including Empire integration steps in module-specific initialization * **Incident Response Playbook** — P0 through P3 runbooks; Empire coordination explicit in custody discrepancy and federal-action freeze runbooks * **Oracle Integration Guide** — Ed25519 relay service implementation, custody oracle architecture, fail-safe cascade * **Issuer Onboarding Guide** — Customer-facing nine-stage process including Empire custody and share deposit * **Compliance Integration Guide** — BSA / AML program, OFAC sanctions, regulatory mapping, federal-action coordination * **Smart Contract Reference** — CustodyOracle account schema, Control 1 implementation * **Whitepaper Section 6** — Oracle Network architecture *** *RWA Tokens · Empire Stock Transfer Integration · Groovy Company, Inc.* --- # Agent Instructions: 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: ``` GET https://bitbook.rwatokens.net/compliance_and_custody/compliance-and-custody/empire-stock-transfer-integration.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.