Architecture Decisions
Architecture Decision Records
ADR-001 through ADR-012 · Evidence-Based Engineering Decisions for the RWA Tokens Platform
Every major architectural decision underlying the RWA Tokens platform is documented below with context, alternatives considered, decision rationale, consequences, and — where applicable — empirical evidence from beta deployments. This is how an engineering organization operates: decisions are deliberate, documented, and traceable.
This document is maintained by Groovy Company, Inc. for institutional evaluators, prospective issuers across all three production modules (Equities, Real Estate, CORECM), regulatory counsel, and capital-markets professionals who need to understand why the platform is built the way it is.
ADR Format
Each record follows a standard structure:
Status: Accepted, Superseded, or Deprecated
Date: When the decision was finalized
Context: The problem or constraint that required a decision
Decision: What was decided
Consequences: What follows from this decision (positive and negative)
Alternatives Considered: What other options were evaluated and why they were rejected
Evidence: Empirical data, regulatory citations, or technical measurements supporting the decision
ADR Index
ADRTitleStatusDate
001
Solana over Ethereum
Accepted
June 2025
002
Custom AMM over External DEXs
Accepted
December 2025
003
Global Unified Pool over Per-Issuer Pools
Accepted
June 2025
004
LP Tokens Burned — No Withdrawal Function
Accepted
June 2025
005
Ed25519 Custody Attestation
Accepted
September 2025
006
Dual-Provider AML (Chainalysis + TRM Labs)
Accepted
October 2025
007
5% Fee Structure
Accepted
June 2025
008
Common Class B Replaces Series M
Accepted
March 2026
009
GENIUS Act Stablecoin Settlement
Accepted
January 2026
010
Jito Block Engine for MEV Protection
Accepted
December 2025
011
Three-Module Platform Architecture
Accepted
May 2026
012
Empire Stock Transfer as Sole ST22 Onboarding Authority
Accepted
March 2026
ADR-001: Solana over Ethereum
Status: Accepted Date: June 2025 Deciders: Chief Technology Officer (Frank Yglesias)
Context
The platform requires a blockchain that enforces compliance controls atomically on every token transfer — not as an application-layer overlay that can be bypassed. The January 28, 2026 Joint Staff Statement on Tokenized Securities distinguishes Category 1 (issuer-sponsored, distributed ledger technology in official records) from Category 2 (third-party sponsored, with counterparty risk). Only runtime-enforced compliance achieves Category 1 Model B treatment.
Decision
Build exclusively on Solana Mainnet-Beta using SPL Token-2022 Transfer Hooks for compliance enforcement.
Consequences
Positive:
Transfer Hook enforcement is a Solana runtime property — no bypass path exists regardless of caller, frontend, or venue.
~400ms block time matches Empire Stock Transfer's custody oracle refresh interval — real-time 1:1 verification.
~$0.00025 per transaction versus $1–$50+ on Ethereum L1 — makes per-transfer compliance economically viable.
Sealevel parallel execution — concurrent Transfer Hook verifications across non-overlapping accounts.
65,000+ TPS theoretical throughput — headroom for thousands of compliance-verified trades across all three modules.
Negative:
Smaller institutional ecosystem compared to Ethereum.
ERC-3643 (T-REX) has billions in tokenized assets and longer market adoption history.
Single-chain dependency until cross-chain bridge (Wormhole NTT) in a future phase.
Alternatives Considered
AlternativeWhy Rejected
Ethereum L1
No native Transfer Hook equivalent. ERC-3643 compliance is an application-layer overlay — a direct EVM transfer() call bypasses all compliance. Gas cost ($1–$50+) makes per-transfer compliance economically unviable. 12-second block time too slow for real-time custody verification.
Ethereum L2 (Arbitrum, Optimism, Base)
Inherits ERC-3643 bypass vulnerability. L2 adds sequencer centralization risk. Compliance enforcement still at the application layer, not runtime.
Polygon
Same ERC-20 bypass path as Ethereum. No runtime-enforced compliance primitive.
Avalanche
Subnet architecture interesting but no equivalent to Transfer Hook enforcement. Smaller DeFi ecosystem than Solana.
Aptos / Sui (Move-based)
Move Prover enables formal verification, but neither chain has a Transfer Hook equivalent. Token transfer is a system call that does not natively invoke custom compliance logic. Nascent ecosystems with limited tooling.
Evidence
SEC Release No. 33-11412 (March 17, 2026): Establishes Digital Securities as a recognized asset class. Category 1 Model B requires DLT in official shareholder records — runtime enforcement necessary.
ERC-3643 bypass risk: Documented in the platform whitepaper. Direct EVM
transfer()call bypasses ONCHAINID compliance layer entirely. SPL Token-2022 has no such bypass path.Cost comparison: 42 control checks at $0.00025 per transaction (Solana) versus $5–$50 per transaction (Ethereum L1) — a 20,000× to 200,000× cost difference per compliance-verified transfer.
ADR-002: Custom AMM over External DEXs
Status: Accepted Date: December 2025 Deciders: Chief Technology Officer (Frank Yglesias) Supersedes: Original assumption that Raydium would serve as a post-graduation trading venue
Context
The original architecture assumed ST22 tokens would graduate to Raydium constant-product market-maker pools after the bonding-curve phase. Beta deployments (GROO, GRLF, MSPC) proved this assumption catastrophically wrong. External DEXs call the original SPL Token Program — all 42 Transfer Hook controls are bypassed at the swap instruction level.
Decision
Build a custom CPMM AMM engine that natively invokes SPL Token-2022 Transfer Hooks on every swap. ST22 tokens never leave platform infrastructure.
Consequences
Positive:
All 42 controls execute on every trade — zero bypass risk.
Protocol-controlled pool creation — unauthorized liquidity-pool creation is impossible.
Fee routing enforced at the program level — cannot be circumvented.
Full CEDEX integration — compliance pre-flight plus on-chain enforcement in one execution path.
SEC Category 1 Model B compliance maintained throughout the token lifecycle.
Negative:
Must build and maintain custom AMM code — cannot leverage existing DEX infrastructure.
No Jupiter aggregator integration — ST22 tokens are not discoverable through standard DEX aggregators.
Substantial development cost for the AMM engine.
Reduced exposure to liquidity from the broader Solana DeFi ecosystem.
Alternatives Considered
AlternativeWhy Rejected
Raydium
Partial Token-2022 support. Transfer Hooks disabled at swap. Beta confirmed: GROO -95.8%, GRLF -93.69%. ~85% bot activity. $5.75M extracted from GROO alone.
Orca
Limited Token-2022 (whitelist-only). Transfer Hooks not implemented. Concentrated-liquidity design amplifies just-in-time attack surface.
Jupiter
Aggregates underlying DEXs — inherits all limitations. No independent Token-2022 support.
Meteora
Basic Token-2022. Hooks bypassed at swap.
Serum / OpenBook
Order-book DEX. No Transfer Hook support. Would require protocol-level fork to add compliance.
Wait for DEXs to add Transfer Hook support
No economic incentive for DEXs to support hooks — unprotected tokens generate more volume, more fees, and more extractable value. The platform's Alesia Doctrine: do not outsource walls to counterparties whose interests are not aligned with yours.
Evidence
On-chain, empirically verified across three beta deployments:
BetaDateResult on External DEXControls Bypassed
GROO
October 2025
-95.8% in 2 hours, $5.75M extracted by 1,000+ bots
42 of 42
GRLF
December 2025
-93.69%, ~85% bot activity, six copycat tokens, unauthorized liquidity-pool creation by third-party bot
42 of 42
MSPC
November 2025
Thirteen copycat tokens, RPC bypass of cooldown
42 of 42
This ADR was the direct result of the Alesia Doctrine — the strategic framework produced by analyzing these incidents.
ADR-003: Global Unified Pool over Per-Issuer Pools
Status: Accepted Date: June 2025 Deciders: Chief Technology Officer (Frank Yglesias)
Context
OTC microcap securities and other thinly-traded asset classes face a structural liquidity problem: individual issuers cannot attract dedicated market makers or liquidity providers. Per-issuer pools would require each tokenized issuer, property, or basin asset to source its own buy-side liquidity — the same barrier that makes OTC markets non-functional for these issuers today.
Decision
Create a single Global Unified CEDEX Liquidity Pool that serves all ST22 issuers across Modules 1, 2, and 3 simultaneously. Protocol-owned. LP tokens burned at initialization.
Consequences
Positive:
Every new issuer inherits immediate secondary-market depth on day one.
Network effect: more issuers → more trading → deeper pool → better prices → more issuers.
No dependency on external market makers or liquidity providers.
Self-reinforcing: 0.44% of every trade permanently deepens the pool.
Eliminates the bootstrapping problem for new Module 2 properties and Module 3 basin assets.
Negative:
Single pool means correlated risk across issuers and asset classes.
Pool depth per individual token is a fraction of total pool capital.
Larger issuances effectively subsidize smaller issuances during the early phase.
If pool capital is insufficient at launch, all issuers experience thin markets.
Alternatives Considered
AlternativeWhy Rejected
Per-issuer pools
Bootstrapping problem: each issuer must source $25K–$75K per year in market making. Most OTC microcap companies cannot afford this. The exact problem the platform exists to solve.
External market makers
Market makers require guaranteed fees and can withdraw at any time. Their withdrawal creates the very liquidity crises microcap investors experience today.
Uniswap V3-style concentrated liquidity
Concentrated liquidity requires active management by LPs. Microcap and basin tokens do not attract sophisticated active LPs. Just-in-time liquidity attacks amplify extractable-value risk.
Hybrid: Global Pool plus per-issuer optional
Complexity without clear benefit. Splits liquidity rather than consolidating it.
Evidence
OTC Markets Group data: approximately 12,000 OTC issuers; fewer than 500 have active market makers. The remaining ~11,500 have zero or near-zero secondary-market liquidity.
Pool economics: at 50 active issuers averaging $500K daily volume and 5% fees, the 0.44% pool allocation generates approximately $800K per year in permanent pool deepening.
ADR-004: LP Tokens Burned — No Withdrawal Function
Status: Accepted Date: June 2025 Deciders: Chief Technology Officer (Frank Yglesias)
Context
The most common failure mode in decentralized finance is liquidity withdrawal — either malicious (rug pull) or panic-driven (bank run). The Global Pool must be permanent to serve as reliable infrastructure for Digital Securities markets across all three modules.
Decision
Burn LP tokens at Global Pool initialization. The withdrawal function was never written into the smart contract code. The liquidity-pool program has no upgrade authority — it is immutable.
Consequences
Positive:
Rug pull is mathematically impossible — not policy-prohibited, not governance-restricted, but structurally nonexistent.
No bank-run risk — liquidity cannot be withdrawn under any condition.
Formal verification (Certora Prover invariant E.3) confirms this property.
Institutional evaluators can verify on-chain that the liquidity-pool program has
Authority: none.
Negative:
Capital committed to the pool can never be recovered — even by Groovy Company, Inc.
If a catastrophic smart-contract vulnerability is discovered in the pool, the code cannot be upgraded to fix it.
Pool parameters cannot be adjusted post-deployment (only the AMM program, which is upgradeable, can change how the pool is used).
Alternatives Considered
AlternativeWhy Rejected
Timelock-protected withdrawal
Timelocks can expire. Multi-signature holders can collude. Governance can be captured. Any withdrawal capability equals non-zero rug-pull risk.
Governance-gated withdrawal
Governance votes can be manipulated through capital concentration. A whale buying enough governance tokens could vote to drain the pool.
Multi-signature withdrawal
5-of-9 collusion, while unlikely, is not mathematically impossible. The security guarantee must be mathematical, not probabilistic.
Upgradeable pool with audit requirements
Upgrades introduce the exact attack surface the design must eliminate. An upgrade could add a withdrawal function.
Evidence
Formal verification: Certora Prover invariant E.3 — no instruction in any platform program can reduce Global Pool balance.
On-chain verification:
solana program show <POOL_PROGRAM_ID>returnsAuthority: none.GRLF beta incident: A third-party bot created an unauthorized Raydium pool and drained it to $0.65. This cannot happen on CEDEX because pool creation is protocol-controlled and LP tokens are burned.
ADR-005: Ed25519 Custody Attestation
Status: Accepted Date: September 2025 Deciders: Chief Technology Officer (Frank Yglesias); Empire Stock Transfer (Patrick Mokros, Founder)
Context
Transfer Hook Control 1 must verify on every transfer that the circulating ST22 token supply does not exceed Empire Stock Transfer's custodied Common Class B share count. This requires a cryptographic attestation mechanism that is verifiable on-chain, tamper-proof, and refreshable at Solana block speed (~400ms).
Decision
Empire Stock Transfer signs custody-balance attestations using Ed25519 digital signatures. The attestation payload includes mint address, balance, supply, slot, and timestamp — verified on-chain via Solana's native Ed25519 precompile.
Consequences
Positive:
Ed25519 is NIST-standardized and verified natively by Solana — no custom cryptography.
Per-block attestation (~400ms) provides near-real-time verification.
Replay protection built into the payload (slot plus timestamp).
On-chain public key registration enables anyone to independently verify attestations.
Zero discrepancy events across three beta issuers and $7M+ processed.
Negative:
Depends on Empire's key management — key compromise would enable false attestation.
Requires always-on relay infrastructure to push attestations every block.
Single-source dependency (mitigated by 2-of-3 oracle consensus for discrepancy resolution).
Alternatives Considered
AlternativeWhy Rejected
Merkle proof of reserves
Batch-oriented — cannot provide per-block attestation. Proof generation too slow for ~400ms cadence. Industry standard (e.g., Chainlink Proof of Reserves) operates on minutes/hours, not milliseconds.
Zero-knowledge proof
Computationally expensive on Solana. ZK verification compute-unit cost exceeds Transfer Hook budget. Unnecessary — Empire's balance is not private information.
Oracle network (Chainlink, Pyth)
Third-party dependency. No existing oracle provides SEC §17A transfer-agent balance feeds. Would require custom integration anyway. Direct Ed25519 signing is simpler and lower latency.
Periodic audit only (quarterly)
Quarterly verification leaves 90 days of unverified trading. Discrepancy detection delayed by months. Unacceptable for real-time securities compliance.
Evidence
Production record: Zero discrepancy events across three beta issuers, $7M+ processed liquidity. 1:1 ratio maintained at every block.
Solana Ed25519 precompile: Native instruction — no Cross-Program Invocation overhead. ~120 compute units per verification.
~400ms attestation cadence matches Solana block time. Staleness threshold: 1 slot. Anything older triggers Error 6002 and halts transfers.
ADR-006: Dual-Provider AML (Chainalysis + TRM Labs)
Status: Accepted Date: October 2025 Deciders: Chief Technology Officer (Frank Yglesias); Empire Stock Transfer (Patrick Mokros, Founder)
Context
Transfer Hook Control 11 requires real-time anti-money-laundering risk scoring on every transaction. A single-provider model creates a blind spot — if one provider's machine-learning model has a false negative, a sanctioned or high-risk entity can trade freely.
Decision
Integrate both Chainalysis Know-Your-Transaction and TRM Labs as dual AML providers. Both scores are evaluated; the higher risk score determines disposition. Three-tier risk disposition: 0–30 approve, 31–70 enhanced review, 71–100 reject.
Consequences
Positive:
Different ML models and training data reduce false-negative risk.
Chainalysis KYT: industry standard, widest coverage of known entities.
TRM Labs: 200+ behavioral features, strong in pattern detection for emerging threats.
Dual-provider satisfies institutional due-diligence requirements.
Regulatory defensibility: BSA/AML program exceeds minimum FinCEN requirements.
Negative:
Higher per-transaction cost (~$0.50–$2.00 per dual query).
Higher latency (~300–400ms combined versus ~200ms single-provider).
Integration complexity — two APIs, two scoring models, two vendor relationships.
Potential for conflicting scores requiring reconciliation logic.
Alternatives Considered
AlternativeWhy Rejected
Chainalysis only
Single-provider blind spots. If Chainalysis misses a sanctioned entity's proxy wallet, no backup detection.
TRM Labs only
Smaller market share. Less institutional recognition. Same single-provider risk.
Elliptic
Strong in EMEA. Less Solana-native integration. Would add a third provider rather than replace either.
Build in-house
Multi-year effort. No existing training data. Regulatory defensibility much weaker than established providers with law-enforcement track records.
Evidence
BSA/AML regulatory framework: 31 U.S.C. §5311 et seq. requires an "effective" AML program. Dual-provider exceeds the "reasonable" standard.
Risk disposition thresholds: Calibrated against industry data — 30/70 boundaries align with FinCEN Suspicious Activity Report filing thresholds (31 C.F.R. §1020.320).
ADR-007: 5% Fee Structure
Status: Accepted Date: June 2025 Deciders: Chief Technology Officer (Frank Yglesias)
Context
CEDEX must fund real compliance infrastructure: per-transfer oracle verification (~$2–5 per trade in compliance costs), issuer revenue sharing, permanent pool deepening, and protocol operations. Standard DEX fees (0.3%) cannot fund securities-grade compliance.
Decision
A 5% total fee (500 basis points) on every ST22 transaction — both primary offerings and secondary CEDEX trades. Distribution: 2% issuer treasury, 1.5% GROO staking pool, 1.06% protocol operations, 0.44% Global Pool (permanently locked).
Consequences
Positive:
Funds real compliance infrastructure (oracle costs, audit, monitoring).
Issuer revenue sharing (2%) makes the platform commercially viable for tokenizing companies in all three modules.
0.44% Global Pool allocation creates self-reinforcing liquidity deepening.
Staking rewards (1.5%) incentivize long-term GROO holding.
5% compares favorably to the 7–10% all-in cost of traditional broker-dealer execution for OTC microcap and similarly-illiquid asset classes.
Negative:
Significantly higher than standard DEX fees (0.3% Raydium, 0.25% Uniswap).
Makes wash trading expensive (a feature, not a bug) but also increases friction for legitimate high-frequency trading.
Institutional traders accustomed to sub-1% execution costs may resist initially.
Fee-discount tiers via GROO staking add complexity.
Alternatives Considered
AlternativeWhy Rejected
0.3% (DEX standard)
Cannot fund per-transfer compliance costs ($2–5 per trade). Would require external subsidy. Unsustainable.
1% flat fee
Covers partial compliance costs but insufficient for issuer revenue sharing and pool deepening. No margin for oracle infrastructure.
Variable fee by volume tier
Added complexity without clear benefit. 5% with staking discounts (2.5%–4.5%) achieves the same tiering more simply.
Separate compliance fee + trading fee
Confusing user experience. Users see one fee, not two. Single 5% is cleaner.
Subscription model (monthly fee)
Poor fit for retail accredited investors who trade infrequently. Per-transaction aligns costs with usage.
Evidence
Traditional securities cost comparison: Broker-dealer all-in execution cost for OTC microcap is 7–10% (commission plus spread plus clearing plus settlement). CEDEX at 5% is 30–50% cheaper.
Compliance cost per transfer: Empire oracle query plus OFAC screening plus AML scoring plus TWAP feed equals $2–5 per verified trade. At a 0.3% fee on a $100 trade, revenue is $0.30 — does not cover compliance cost.
ADR-008: Common Class B Replaces Series M
Status: Accepted Date: March 2026 Deciders: Chief Technology Officer (Frank Yglesias); Legal Counsel Supersedes: Series M Preferred as backing instrument for third-party ST22 tokens
Context
The SEC Crypto Task Force, in a March 30, 2026 meeting, directed that the backing instrument for third-party ST22 tokens should be Common Class B shares rather than Preferred Series M. Common Class B shares carry full shareholder rights by operation of state law (voting, dividends, liquidation participation). Each issuer designates specific governance terms in its own Certificate of Designation filed with the Secretary of State of the issuer's jurisdiction of incorporation.
Decision
Replace Preferred Series M with Common Class B shares as the sole backing instrument for all third-party ST22 Digital Securities tokens across all three modules. Series M is now fully obsolete for issuer-facing tokenization.
Consequences
Positive:
Full shareholder rights by operation of state law — not dependent on contract interpretation.
Simpler corporate governance — Common stock is universally understood by counsel and courts.
SEC Crypto Task Force alignment — directly responsive to regulatory guidance.
Certificate of Designation filed with Secretary of State — publicly verifiable.
Removes Preferred share complexity (liquidation preferences, conversion rights, anti-dilution).
Negative:
Required updating all existing documents, smart contracts, oracle field names, and legal templates.
45-item change register across nine categories tracked migration impacts.
Issuer counsel must file new Certificate of Designation.
Existing beta tokens (GROO, GRLF, MSPC) were issued under Series M — not retroactively changed.
Alternatives Considered
AlternativeWhy Rejected
Keep Series M Preferred
Directly contradicts SEC Crypto Task Force March 30, 2026 directive. Regulatory risk unacceptable.
Common Class A
Typically reserved for existing common shareholders with superior voting rights. Class B avoids conflict with existing capital structure.
Convertible Note / SAFE
Debt instrument, not equity. Does not satisfy Category 1 Model B requirement for direct beneficial ownership.
Evidence
SEC Crypto Task Force directive: March 30, 2026 meeting. Common Class B shares specified as backing instrument.
Custody oracle update:
series_m_balancefield renamed tocommon_b_balance. Error 6001 message updated to reference "Common Class B shares."Change register: 45 items across legal documents, SEC filings, offering documents, smart contracts, websites, Empire systems, marketing materials, GAAP/valuation, and internal operations.
ADR-009: GENIUS Act Stablecoin Settlement
Status: Accepted Date: January 2026 Deciders: Chief Technology Officer (Frank Yglesias); Legal Counsel
Context
ST22 primary offerings and CEDEX secondary trades require a settlement medium. Options: fiat wire transfer, native cryptocurrency (SOL), or regulated stablecoins. The GENIUS Act (Guiding and Establishing National Innovation for U.S. Stablecoins) provides a legislative framework for compliant stablecoin usage in securities settlement.
Decision
All ST22 purchases conducted via GENIUS Act-compliant stablecoin settlement — USDC (Circle) and PYUSD (PayPal/Paxos). Not fiat wire. Not SOL or other native cryptocurrency.
Consequences
Positive:
Regulatory clarity: GENIUS Act provides explicit legislative framework for stablecoin settlement.
1:1 USD backing — no crypto volatility risk during settlement window.
On-chain settlement — atomic with Transfer Hook enforcement (compliance and settlement in one transaction).
24/7/365 settlement — no banking hours, no wire-transfer delays.
Dual stablecoin (USDC plus PYUSD) avoids single-issuer dependency.
Existing institutional familiarity with USDC.
Negative:
Stablecoin issuer risk (Circle/Paxos operational risk).
USDC de-peg risk (March 2023 Silicon Valley Bank event: USDC traded at $0.87 briefly).
Excludes investors who prefer fiat wire or native cryptocurrency.
Regulatory dependency on GENIUS Act passage and implementation.
Alternatives Considered
AlternativeWhy Rejected
Fiat wire transfer
3–5 business-day settlement. Not atomic with on-chain execution. Would require separate clearing/settlement layer. 24/7 trading impossible with banking-hours constraint.
SOL (native)
Volatile. 20–50% intraday swings common. Investor receiving ST22 tokens would be exposed to SOL price risk during the offering period. Not suitable for securities settlement.
USDT (Tether)
Controversial reserve backing. Lower regulatory clarity than USDC. Not GENIUS Act-aligned. Reputational risk for an institutional-grade platform.
DAI / algorithmic stablecoins
Algorithmic stability mechanisms have failed (UST/LUNA collapse, May 2022). Institutional risk teams reject algorithmic stablecoins for securities settlement.
Evidence
GENIUS Act: Legislative framework establishing requirements for payment-stablecoin issuers. USDC and PYUSD satisfy issuer reserve and reporting requirements.
CFTC Letters 25-39 and 26-05: Identified as relevant to GENIUS Act stablecoin settlement layer and Empire custody architecture.
Atomic settlement: Stablecoin transfer plus ST22 token delivery plus Transfer Hook verification execute in a single Solana transaction. Fiat wire cannot achieve this.
ADR-010: Jito Block Engine for MEV Protection
Status: Accepted Date: December 2025 Deciders: Chief Technology Officer (Frank Yglesias)
Context
GROO and GRLF beta deployments confirmed that maximal-extractable-value (MEV) bots — sniper bots, sandwich attackers, front-runners — were responsible for approximately 85% of post-launch trading activity. The primary attack vector: bots monitoring the public mempool detect pending transactions and front-run them with higher priority fees.
Decision
Integrate Jito Block Engine for private transaction submission on CEDEX. Transactions are submitted directly to the Jito block producer — not visible in the public mempool until they are included in a block. Combined with Transfer Hook price-impact limits (2% maximum) and time-weighted-average-price deviation checks.
Consequences
Positive:
~95% reduction in front-running opportunities (Jito documentation claim, consistent with beta observation).
Bundled transactions execute atomically — no insertion between bundle components.
Dynamic priority fees based on network congestion (versus fixed-fee overpayment).
Complemented by on-chain defenses: 2% price-impact cap (Control 21), circuit breakers (Controls 20–23), wallet limits (Control 15).
Negative:
Jito dependency — if Jito Block Engine is unavailable, fallback to public mempool with degraded MEV protection.
Jito tip adds small cost to each transaction.
Not a complete solution alone — requires on-chain controls as a secondary defense layer.
Centralization concern: Jito validator set is a subset of total Solana validators.
Alternatives Considered
AlternativeWhy Rejected
Public mempool only
Beta evidence: ~85% bot activity, $5.75M extracted from GROO alone. Public mempool is the primary attack surface.
Commit-reveal scheme (on-chain)
Higher latency (two-phase: commit then reveal). Additional compute-unit cost. Complex UX — users must submit two transactions. Jito achieves similar protection with single-phase submission.
Flashbots Protect (Ethereum equivalent)
Ethereum-only. No Solana equivalent. Jito is Solana's native MEV protection infrastructure.
Dedicated validator (platform-operated)
Significant infrastructure cost. Single point of failure. Regulatory complexity of operating validator infrastructure. Jito provides equivalent protection as a service.
On-chain controls only (no MEV protection)
Price-impact limit (2%) and circuit breakers help but do not prevent the initial front-running. Bots can still extract value within the 2% window. Jito prevents them from seeing the transaction at all.
Evidence
GROO beta (October 2025): ~1,000+ sniper bots, $5.75M extracted, ~85% automated activity. All attacks leveraged public-mempool visibility.
GRLF beta (December 2025): 34 bot wallets detected. One wallet (
hswtMtZr…) executed 200+ transactions in minutes — mempool monitoring pattern.Jito architecture: Transactions submitted to Jito relayer, then to block producer. Not broadcast to public mempool. Visible only upon block inclusion.
Fallback behavior: CEDEX displays "MEV Protection Degraded" banner when Jito is unavailable. All fallback transactions logged for post-incident compliance review.
ADR-011: Three-Module Platform Architecture
Status: Accepted Date: May 2026 Deciders: Chief Technology Officer (Frank Yglesias)
Context
Real-world asset tokenization spans heterogeneous asset classes — equities, real property, strategic minerals, commodities, infrastructure — each with distinct regulatory frameworks, valuation mechanics, and investor profiles. A single undifferentiated tokenization product cannot address this market efficiently. Conversely, a fragmented multi-platform approach (one platform per asset class) sacrifices the network effects of shared liquidity, shared compliance, and shared institutional relationships.
The platform required a structural decision: how to organize the product so that distinct asset classes can be tokenized with class-appropriate diligence and pricing mechanics, while still benefiting from a single Solana foundation, a single Transfer Hook compliance framework, a single Global Unified Pool, and a single qualified custodian.
Decision
Organize the platform into three production modules sharing common infrastructure:
Module 1 — Equities: Tokenization of equity securities sourced from OTC microcap, NASDAQ, NYSE American (AMEX), the Toronto Stock Exchange (TSX), and additional global exchanges. Issued as ST22 Digital Securities backed 1:1 by Common Class B shares of the underlying issuer in qualified custody.
Module 2 — Real Estate: Tokenization of direct-ownership interests in real-property assets (commercial, residential, mixed-use). Each property issued by a single-asset entity holding the underlying property. Pricing anchored to independent appraisal-based Net Asset Value with constant-product market-maker mechanics and circuit-breaker controls calibrated to NAV reappraisal cycles.
Module 3 — CORECM: Tokenization of basin-asset interests within the United States strategic minerals supply chain — Carbon Ore (including DOE coal-derived rare-earth element recovery), Rare Earth elements, and Critical Minerals as defined by U.S. federal frameworks.
All three modules share: SPL Token-2022 with Transfer Hook extension, the 42-control compliance framework, the Global Unified CEDEX Liquidity Pool, Empire Stock Transfer as qualified custodian and sole investor-onboarding authority, GENIUS Act stablecoin settlement, and the platform's standard offering-exemption framework (Reg D, Reg S, and Reg CF).
Consequences
Positive:
Each module exercises module-appropriate Solana properties and Transfer Hook controls without duplicating infrastructure (see Solana Blockchain Foundation, Section 8).
Shared Global Pool: liquidity in Module 1 equity trading deepens the pool that supports Module 2 property and Module 3 basin trading. Cross-asset network effects.
Shared Transfer Hook: compliance enforcement is identical across modules — institutional evaluators verify one framework, not three.
Shared custody and onboarding: investors onboard once via Empire and trade across all three modules without re-onboarding per asset class.
Independent Sealevel execution lanes: trading activity in one module does not interfere with another (different mints, different state accounts).
Module-specific extensions are possible without rearchitecting: Module 2 NAV reappraisal mechanics, Module 3 export-control screening, etc.
Negative:
Operational complexity: each module requires module-specific diligence, valuation, and disclosure tooling.
Regulatory framing requires per-module precision — Module 3 in particular implicates federal critical-minerals regulation distinct from securities law.
Marketing must communicate three asset classes without losing the single-platform narrative.
Issuer-onboarding tooling must accommodate equity issuers, real-estate sponsors, and basin-asset operators with different document requirements.
Alternatives Considered
AlternativeWhy Rejected
Single equities-only platform
Forfeits the larger and faster-growing tokenization opportunities in real estate and strategic minerals. Restricts the platform to a single asset-class market that, while real, does not justify the underlying infrastructure investment.
Separate platforms per asset class
Fragments liquidity, compliance, and custody. Each platform must rebuild what the others already have. No cross-asset network effect. Higher total cost of operation.
Generic "RWA platform" without module structure
Loses the asset-class precision required for institutional investors and regulators. A property-tokenization buyer does not want to read equity-tokenization disclosures, and vice versa.
Two modules (equities + real estate, no CORECM)
Forfeits the most defensible competitive position the platform has — strategic-minerals tokenization aligned to USGS, DOE, Section 232, DPA Title III, IRA, EO 14017, and the Energy Act of 2020. CORECM is not an incremental product; it is a category creation.
Evidence
Market research: Independent analyses (BCG/Ripple, Standard Chartered, Citi) project the tokenized RWA market at approximately USD 4 trillion to USD 30 trillion by 2030, with the largest sub-segments being equities, real estate, and commodities/strategic minerals — the three Modules.
Solana Sealevel cross-mint parallelism: Empirically verified that trading activity in one mint does not affect transaction throughput for unrelated mints. The platform inherits this property at the module level.
Regulatory framework alignment: Module 1 maps to SEC Release No. 33-11412 and the Joint Staff Statement on Tokenized Securities. Module 2 maps to property law plus securities issuance via single-asset entities. Module 3 maps to USGS Critical Minerals List, DOE Critical Materials Strategy, Section 232 of the Trade Expansion Act of 1962, Title III of the Defense Production Act, Inflation Reduction Act critical-minerals provisions, Executive Order 14017, and the Energy Act of 2020.
ADR-012: Empire Stock Transfer as Sole ST22 Onboarding Authority
Status: Accepted Date: March 2026 Deciders: Chief Technology Officer (Frank Yglesias); Empire Stock Transfer (Patrick Mokros, Founder)
Context
ST22 Digital Securities require investor onboarding (Know-Your-Customer, Know-Your-Business, Anti-Money-Laundering, Office of Foreign Assets Control / Specially Designated Nationals screening, accreditation verification, and wallet verification) before any token can be transferred to the investor's wallet. The architectural question: should onboarding be performed by the platform, by individual issuers, by a network of compliance vendors, or centralized through a single regulated qualified custodian?
A fragmented onboarding model produces inconsistent diligence quality, duplicates investor friction (each issuer collects the same documents independently), and dilutes regulatory accountability. A platform-centric model places the platform in a regulated function (transfer agent / qualified custodian) it is not registered to perform.
Decision
Empire Stock Transfer — a transfer agent registered with the U.S. Securities and Exchange Commission under Section 17A of the Securities Exchange Act of 1934 — serves as the sole onboarding authority for all ST22 investors across Modules 1, 2, and 3. Empire performs KYC, KYB, AML screening (using Chainalysis KYT and TRM Labs per ADR-006), OFAC/SDN screening, accreditation verification, and wallet verification. No issuer, no platform component, and no third-party vendor performs these functions independently.
Consequences
Positive:
Single, consistent diligence standard across all modules and all issuers.
Investor onboards once and can trade across all three modules without re-onboarding.
Regulatory accountability is concentrated in a §17A-registered entity with established procedures, audit history, and operational maturity.
Issuers do not bear onboarding cost or complexity individually — Empire's relationship aggregates the diligence function.
Custody and onboarding under a single counterparty (Empire) simplifies the regulatory map for SEC and state-level reviewers.
Reduces investor friction: institutional investors prefer one onboarding event covering the entire platform.
Negative:
Single counterparty dependency: an Empire operational disruption affects all three modules simultaneously.
Empire's procedural standards are the platform's procedural standards — modifications require coordination with Empire rather than unilateral platform decisions.
Geographic and jurisdictional limits on Empire's onboarding capacity may constrain investor universe in some markets.
Concentration risk for regulatory examination — Empire is the operational chokepoint for compliance, which means its examination posture is the platform's examination posture.
Alternatives Considered
AlternativeWhy Rejected
Platform-direct onboarding (no transfer agent)
Places the platform in the role of a regulated transfer agent without §17A registration. Operationally and legally untenable.
Per-issuer onboarding
Inconsistent quality across issuers. Duplicate friction (investors complete KYC/AML for each issuance). No single standard for diligence. Higher aggregate cost. Fragments compliance accountability.
Multi-vendor onboarding marketplace
Investor confusion over which vendor performs which check. Inconsistent record-keeping. Difficult regulatory examination — examiners must audit multiple vendors with varying procedures.
Two-step model: platform pre-screen plus Empire confirmation
Adds complexity and latency without clear quality gain. If Empire's confirmation is the regulatory anchor, the platform pre-screen is duplicative work.
Evidence
Empire Stock Transfer registration: SEC §17A-registered transfer agent under 15 U.S.C. § 78q-1 and 17 C.F.R. § 240.17Ad-1 et seq. Federal-level regulatory anchor.
Operational record: Manages shareholder accounts for hundreds of public companies. Established AML, OFAC, accreditation, and wallet-verification procedures.
Custody integration: Empire is also the qualified custodian for ST22 backing collateral (Common Class B shares per ADR-008). Onboarding and custody under a single regulated counterparty.
No-action letter Position 1: The platform's pending consolidated no-action letter to the SEC Division of Trading and Markets includes Empire's qualified-custodian status as a primary position. Empire's regulatory standing is a load-bearing element of the platform's overall compliance posture.
ADR Governance
Adding New ADRs
New architectural decisions are documented as ADRs when they meet any of these criteria:
Affects more than one layer of the platform's nine-layer stack.
Has security implications for Transfer Hook enforcement.
Changes the regulatory compliance posture.
Is irreversible (e.g., immutable program deployment, LP burn).
Has cost implications exceeding $50,000.
Establishes or modifies a module-level architectural property.
Superseding ADRs
When a decision is reversed or replaced, the original ADR status changes to "Superseded" with a reference to the new ADR. The original record is preserved for historical context.
ADR Review
ADRs are reviewed quarterly by the Chief Technology Officer. Any ADR whose context has materially changed (new regulation, technology update, competitive development) is flagged for reassessment.
Related Documentation
Solana Blockchain Foundation — Why Solana, Token-2022, Transfer Hook, and module-specific foundations
Whitepaper — Full technical specification referenced throughout
Security Model — Threat model and formal verification
Smart Contract Reference — Program details for decisions implemented on-chain
CEDEX API Reference — Trading venue API specification
Empire Stock Transfer Integration — Custody attestation, onboarding, and regulatory-freeze workflow
Compliance Integration Guide — How module-specific issuances configure the 42 controls
RWA Tokens · Architecture Decision Records · Groovy Company, Inc.
Last updated
Was this helpful?