Layer 1: Solana Blockchain Foundation
SECTION 5 — Layer 1: Solana Blockchain Foundation
RWA Tokens Platform Whitepaper · V10.0 · May 2026 Issued by: Groovy Company, Inc. (Wyoming corporation; OTC: GROO; SEC EDGAR CIK 1499275) Section classification: Technical Specification — Infrastructure Layer Authority: SEC–CFTC Release No. 33-11412 § Five-Category Taxonomy; Solana Mainnet-Beta Specification
5.1 Layer 1 Architectural Position
Layer 1 is the distributed-consensus and execution substrate underneath the entire RWA Tokens platform stack. Every other layer — the Transfer Hook (Layer 2), the core protocol PDAs (Layer 3), the Global Unified Liquidity Pool (Layer 4), the CEDEX trading venue (Layer 5), the Oracle Network (Layer 6), governance (Layer 7), wallet infrastructure (Layer 8), and the IDOS intelligence module (Layer 9) — depends architecturally on properties supplied by Solana Mainnet-Beta. The platform is not a multi-chain abstraction. The platform is a Solana-native protocol that derives operational guarantees from properties that no other production L1 supplies in combination.
This section specifies (a) the Solana properties the platform depends on, (b) why no alternative L1 currently satisfies these dependencies, (c) the full Solana program inventory the platform deploys, (d) the production infrastructure (RPC, MEV protection, monitoring) supporting these programs, and (e) the network constants and finality semantics used elsewhere in this whitepaper.
5.2 Why Solana — Architectural Dependency Analysis
The platform's runtime-enforced compliance model (SEC Category 1 Model B Pillar 6) creates four Layer 1 requirements that together eliminate every L1 alternative as of the V10 specification date.
Runtime-level Transfer Hook
The base token program must invoke a registered hook on every transfer, with no bypass instruction
✅ SPL Token-2022 with spl-transfer-hook-interface v0.6+ enforces invocation at the runtime layer
❌ ERC-20 transfer() is application-layer; ERC-3643 overlay can be bypassed by direct calldata to underlying ERC-20
❌ Same as Ethereum L1 — no native runtime hook
Per-transfer compliance economics
Per-transfer cost low enough to verify 42 controls plus module-aware extensions on every trade at every market-cap tier
✅ ~$0.00025 per transfer (variable with priority fee)
❌ $5–$50+ per transfer; impossible at OTC-microcap tier
⚠️ $0.05–$2.00 per transfer; viable for large-cap, prohibitive for microcap
Sub-second finality
Settlement finality on the same order as Empire Stock Transfer's per-slot Ed25519 attestation cadence
✅ ~400 ms single-block finalization (Tower BFT)
❌ ~12-second blocks; ~12-minute economic finality
⚠️ ~2 second blocks; finality bonded to L1 confirmation
Native Ed25519 verification
Native cryptographic precompile for Empire's per-slot signature verification (compute-cheap)
✅ Native Ed25519 sysvar precompile
❌ Requires precompile contract; ~3,000 gas per verification
❌ Same as Ethereum L1
The combination — runtime-hook + low cost + sub-second finality + native Ed25519 — exists on Solana Mainnet-Beta and on no other production L1 as of V10. This is the architectural reason the platform is Solana-native rather than chain-agnostic. ADR-001 (Architecture Decisions registry) memorializes this analysis.
5.3 Core Protocol Innovations
Solana's consensus design supplies the four properties above through three protocol-level innovations the platform depends on.
5.3.1 Proof-of-History (PoH) — Verifiable Delay Function
PoH is a Verifiable Delay Function (VDF) — a cryptographic clock that provides a verifiable ordering of events without requiring nodes to communicate to agree on time. Every Solana validator advances a single SHA-256 chain at a roughly constant rate; the chain's current hash is a cryptographic proof that a specific amount of wall-clock time has passed since any earlier hash. Transactions are timestamped against this chain.
Why the platform depends on PoH: per-slot Ed25519 attestation from Empire Stock Transfer (Section 11) anchors to the slot's PoH hash. The attestation states "at this slot, custodied balance equals issued balance." Because PoH supplies a verifiable wall-clock ordering, the attestation cannot be backdated or forward-dated by the relay. Tampering with the attestation timestamp would require breaking SHA-256.
5.3.2 Proof-of-Stake — Tower BFT Consensus
Tower BFT is Solana's PBFT-derived consensus protocol layered over PoH. Validators vote on the current chain head; votes accumulate "lockout" via an exponential weighting that grows with consecutive confirmations. The result: a block becomes economically final after roughly 32 confirmations (~13 seconds at typical conditions) and probabilistically final at 1 confirmation (~400 ms).
Why the platform depends on Tower BFT: the ~400 ms single-confirmation finality matches the cadence at which Empire publishes custody attestations. Trades settle on Solana, the on-chain ledger reflects the settlement, and Empire's next attestation reconciles the MSF state — all within the same human-perception interval. Compare to Ethereum L1, where ~12-minute economic finality means a settlement-attestation reconciliation cycle would lag the trade by 12+ minutes — long enough for shareholder-register divergence to materially affect dividend distributions or proxy votes scheduled near a custodial event.
5.3.3 Native Ed25519 Precompile
Solana exposes Ed25519 signature verification via a native runtime sysvar (Secp256k1Program::id() for Secp256k1 and an Ed25519 program for Ed25519). Verification cost is a fixed compute-unit charge — typically ~600 CU per verification, compared to several thousand CU for an in-program signature verification implementation.
Why the platform depends on it: the Transfer Hook performs Ed25519 verification on every transfer of every ST22 mint to verify the Empire custody attestation (Control CV-04). The 42 controls + module-aware extensions consume ~800K–830K CU per transfer (varies by module — see §5.7); a non-native Ed25519 verification path would push compute consumption past the per-transaction CU ceiling. Native Ed25519 is the architectural enabler for runtime-enforced custody verification.
5.4 Account Model — Program Derived Addresses
Solana's account model is account-centric, not contract-centric: every byte of state lives in an account, and programs read/write accounts via the runtime's account-borrowing rules. The platform makes extensive use of Program Derived Addresses (PDAs) — accounts whose addresses are deterministically derived from seeds and a program ID, with no associated private key.
5.4.1 PDA Derivation Function
find_program_address repeatedly hashes the seeds plus a counter (the "bump") with the program ID until it finds a result that lies off the Ed25519 curve. The off-curve constraint is essential: it guarantees no private key can ever sign for the address, which means only the owning program can sign for the PDA via the runtime's invoke_signed mechanism. The bump value is stored in the PDA itself for stable rederivation.
5.4.2 Platform PDA Inventory
SecurityConfig
[b"security-config", mint]
transfer_hook
M1, M2, M3
HoldingPeriodAccount
[b"holding-period", mint, beneficiary]
transfer_hook
M1, M2, M3
CustodyOracle
[b"custody-oracle", mint]
oracle_aggregator
M1, M2, M3
OFACOracle
[b"ofac-oracle"] (singleton)
oracle_aggregator
M1, M2, M3
AMLOracle
[b"aml-oracle", wallet]
oracle_aggregator
M1, M2, M3
TWAPOracle
[b"twap-oracle", mint]
oracle_aggregator
M1, M2, M3
EDGAROracle
[b"edgar-oracle", cik]
oracle_aggregator
M1
NAVOracle
[b"nav-oracle", mint]
oracle_aggregator
M2
ClassificationOracle
[b"classification-oracle", mint]
oracle_aggregator
M3
LiquidityPool
[b"liquidity-pool"] (singleton — Global Pool)
liquidity_pool
M1, M2, M3
PoolPosition
[b"pool-position", mint]
liquidity_pool
M1, M2, M3
AmmMarket
[b"amm-market", mint]
amm
M1, M2, M3
GovernanceProposal
[b"proposal", proposal_id]
governance
M1, M2, M3
Why PDA-centric design matters for the platform: every per-mint configuration (compliance parameters, custody attestation, NAV/Classification state) lives in a PDA whose address is deterministically derivable from the mint pubkey. There is no centralized "registry" account whose corruption could affect multiple mints — each mint's state is isolated by construction.
5.4.3 Account Rent and Reserved State
Solana accounts pay rent unless they hold sufficient SOL to be "rent-exempt." All platform PDAs are funded to rent-exemption at creation. The transfer_hook program initialization computes the rent-exempt minimum for the SecurityConfig PDA at program-deployment time and refuses initialization with insufficient lamports. ADR-005 documents the rent-funding economics.
5.5 SPL Token-2022 — Compliance-Critical Token Standard
The platform uses SPL Token-2022 (token program ID TokenzQdBNbLqP5VEhdkAS6EPFLC1PHCBxGTJSAGkSm), Solana's extended token standard supporting the Transfer Hook extension. This is architecturally distinct from the original SPL Token program, which has no hook mechanism.
5.5.1 Transfer Hook Extension Mechanics
When an ST22 mint is created, the Token-2022 program is invoked with the TransferHookExtension initialized to the platform's transfer_hook program ID. From that point forward:
Any transfer instruction on the mint is dispatched through the Token-2022 program
Token-2022 inspects the mint's extensions and identifies the registered hook program
Token-2022 invokes the hook program via cross-program invocation (CPI)
The hook program executes its 42 controls plus module-aware extensions
If the hook returns success, Token-2022 completes the underlying balance update
If the hook returns error, Token-2022 reverts the entire transaction atomically
There is no instruction in Token-2022 that bypasses step 3. The hook invocation is enforced at the Token-2022 program level — which is itself a runtime-loaded program governed by Solana's program-upgrade authority (currently held by the Solana Foundation under multi-sig; see §5.6.4 for the platform's upgrade-authority isolation strategy).
5.5.2 Other Token-2022 Extensions Used
TransferHook
✅ All ST22 mints
The 42 controls + module-aware extensions
MintCloseAuthority
❌ Disabled
Mint cannot be closed — protects 1:1 backing invariant
ConfidentialTransfer
❌ Disabled
Conflicts with Empire MSF reconciliation transparency
InterestBearing
❌ Disabled
Yield handled via staking program, not token-level
CpiGuard
✅ Enabled on issuer treasury PDAs
Prevents accidental CPI-driven debits from issuer accounts
ImmutableOwner
✅ Enabled on AMM market accounts
Prevents account-owner reassignment that could break AMM accounting
MetadataPointer
⚠️ Optional per mint
Issuer-supplied metadata URI for on-chain mint discoverability
The deliberate absence of MintCloseAuthority and ConfidentialTransfer is a Category 1 Model B compliance posture: Pillar 4 (1:1 Backing) requires that mint supply remain pinned to custodied equity, and Pillar 2 (Official DLT Register) requires reconciliation-transparency between the on-chain ledger and the Empire MSF.
5.6 Platform Solana Program Inventory
The platform deploys five Solana programs to Mainnet-Beta. Each has a distinct responsibility, a distinct upgrade-authority configuration, and explicit Certora-verified invariants.
5.6.1 Program Inventory Table
1
transfer_hook
RWAhook111… (32-byte placeholder per V10 deployment plan)
Executes the 42 controls + module-aware extensions
None — immutable post-deployment
E.2, E.4, E.5, E.6
2
amm
RWAamm1…
CEDEX Custom Constant Product Market Maker
3-of-5 multi-sig + 48-hour timelock
E.3 (partial — pool reserve protection)
3
liquidity_pool
RWApool1…
Global Unified Liquidity Pool management; LP burn enforcement
3-of-5 multi-sig + 48-hour timelock
E.3
4
governance
RWAgov1…
On-chain proposal and voting; multi-sig / timelock orchestration
3-of-5 multi-sig + 48-hour timelock
(governance-scope only)
5
oracle_aggregator
RWAoracle1…
Aggregates oracle attestations: Custody, OFAC, AML, TWAP, EDGAR, NAV, Classification
3-of-5 multi-sig + 48-hour timelock
E.1 (custody invariant)
Program IDs above are placeholder labels. Mainnet-Beta deployment IDs are published in the platform Smart Contract Reference and pinned to the production deployment by the Q3 2026 launch.
5.6.2 transfer_hook Program — Immutable
transfer_hook Program — ImmutableThe transfer_hook program is deployed with no upgrade authority (upgrade_authority set to Pubkey::default() or program closed to upgrades). This is an architectural decision documented in ADR-006: the 42 controls + module-aware extensions are immutable post-deployment by construction. Certora invariant E.4 formally proves this property — there exists no execution path by which the 42 core controls or applicable module-aware extensions can be removed, weakened, or repointed.
The cost: any defect in the deployed transfer_hook program cannot be patched. The mitigation: extensive formal verification (Certora suite, six invariants), Trail of Bits security audit, Halborn audit on the V9 module-aware extensions, and a 12-month bug-bounty period preceding production deployment. See Section 15 for the full security verification dossier.
5.6.3 Multi-Sig and Timelock for Mutable Programs
The four mutable programs (amm, liquidity_pool, governance, oracle_aggregator) operate under a 3-of-5 multi-sig with 48-hour timelock:
Multi-sig signers: Frank Yglesias (Chairman & CTO of Groovy Company), Patrick Mokros (COO of Groovy Company; Founder of Empire Stock Transfer), Empire Stock Transfer Compliance Officer, External Technical Advisor #1 (regulatory expertise), External Technical Advisor #2 (cryptography expertise)
Threshold: 3 of 5 signatures required
Timelock: 48-hour delay between multi-sig approval and on-chain program upgrade
Override: none — the timelock cannot be shortened by any mechanism, including the multi-sig itself
The 48-hour timelock provides a forced public-disclosure window: any pending program upgrade is observable on-chain for 48 hours before activation, allowing the community, regulators, or outside observers to flag concerns before changes go live. This is a Category 1 Model B Pillar 7 ("immutable, no admin override") posture: the only "admin" capability is upgrade-authorization, and that capability is bounded by multi-sig and timelock.
5.6.4 Token-2022 Program Trust Boundary
A subtle property: the platform's transfer_hook is immutable, but the Token-2022 program itself is governed by the Solana Foundation's program-upgrade authority. Theoretically, a Solana Foundation upgrade to Token-2022 could weaken hook-invocation enforcement. The platform mitigates this by:
Pinning to specific Token-2022 program-version IDs in compliance-critical paths
Monitoring Solana Foundation governance activity for any Token-2022 changes
Maintaining a contingency procedure (Incident Response Playbook §11) for Control 42 invocation if a Solana Foundation Token-2022 upgrade weakens hook enforcement
This is the residual L1 trust assumption the platform retains. It is documented transparently in ADR-007 and disclosed in the Risk Disclosure document.
5.7 Compute Budget per Module
Solana transactions are subject to a per-transaction Compute Unit (CU) ceiling — typically 1,400,000 CU for non-priority transactions, expandable to 1,400,000+ CU via ComputeBudgetInstruction. The platform's per-transfer compute budget varies by module due to the additional cost of module-aware extensions:
Module 1 — Equities
~800,000
(none — baseline)
~800,000
Module 2 — Real Estate
~800,000
~20,000 (CB-21 NAV variant — NAV deviation math + appraiser signature verification)
~820,000
Module 3 — CORECM
~800,000
~30,000 (REG-42 federal variant — Classification status check + federal-action state machine)
~830,000
All three modules fit within the standard 1,400,000 CU ceiling with substantial headroom. The CEDEX amm swap path consumes additional CU for AMM math (~150,000 CU), bringing total CU per CEDEX trade to ~950,000–980,000 CU depending on module — still within the standard ceiling.
5.8 Performance Characteristics
Block time
~400 ms
Tower BFT slot duration
Single-confirmation finality
~400 ms
Probabilistic
Economic finality
~13 seconds
~32 confirmations
Per-transfer cost (base)
~$0.00025
At ~$150 SOL price; 5,000 lamports base fee + priority fee
Per-transfer cost (priority)
$0.0005–$0.001
During congested periods; CEDEX uses dynamic priority fees via Jito
Network throughput (theoretical)
65,000 TPS
Solana whitepaper figure
Network throughput (sustained, realistic)
2,000–4,000 TPS
Mainnet-Beta observed sustained throughput
Platform throughput (compliance-verified ST22 trades)
400–600 TPS
Bottleneck is hook execution + Ed25519 verification cost per trade
RPC capacity (platform dedicated cluster)
500+ req/sec
Helius dedicated tier; Triton failover
The 400–600 TPS platform throughput reflects compliance-verified ST22 trades specifically. Non-compliance traffic (e.g., GROO Utility Token trades, USDC stablecoin transfers) is unaffected and can run at network ceiling.
5.9 Production Infrastructure
5.9.1 RPC Cluster — Helius Dedicated + Triton Failover
Primary
Helius (dedicated cluster)
500+ req/sec
All read-path queries (account fetches, mint queries, oracle reads); CEDEX order book backend
Failover
Triton One
200+ req/sec
Primary failure detection triggers automatic switchover within 30 seconds
Public fallback
Solana Foundation public RPC
best-effort
Last-resort read-only fallback; never used for write path
Why dedicated capacity matters: the November 2025 MSPC beta validated empirically that shared-tier RPC capacity (50 req/sec) is the primary bottleneck under launch volume. CEDEX peak load projections require 300+ req/sec sustained, which only dedicated infrastructure supplies reliably.
5.9.2 MEV Protection — Jito Block Engine
All CEDEX trades route through the Jito Block Engine for MEV protection. Jito provides:
Transaction-bundle inclusion via auction (mitigates sandwich attacks)
Priority-fee market for predictable inclusion under congestion
Searcher mempool isolation (CEDEX trades not exposed to public mempool)
Why MEV protection matters: the December 2025 GRLF beta validated that 85% of trade activity on unprotected venues was bot-driven extraction. Jito routing reduces extraction surface to the auction-cleared bundle level, where extraction must compete against legitimate priority demand on equal footing. ADR-010 documents the integration.
5.9.3 Monitoring — Datadog + PagerDuty
Transaction throughput
Real-time TPS, success rate, error rate by program
Compute consumption
CU per transfer by module, percentile distribution
Oracle freshness
Slot age for Custody / OFAC / AML / TWAP / EDGAR / NAV / Classification
Hook control errors
Error code 6001–6042 frequency by mint, by error type
Module-aware extension errors
CB-21 NAV-deviation rejections by mint; REG-42 federal-action freezes by mint
MSF reconciliation
Empire MSF vs on-chain ledger drift detection per slot
Liquidity pool depth
Reserve balances; price impact at standard trade sizes
Wallet behavioral signals
Coordinated activity signatures (sniper-bot detection); Layer 9 IDOS feed
PagerDuty escalations route to platform compliance (Empire compliance officer) and Layer 1 SRE (platform engineering). Module-specific dashboards added in V9 surface module-aware extension activity: a Module 2 dashboard tracks NAV deviation patterns; a Module 3 dashboard tracks federal-action freeze events and 60-minute SLA performance.
5.9.4 Validator Strategy
The platform runs non-validating Solana infrastructure — no platform-operated validator nodes. Validation is the responsibility of the broader Solana validator set. This is an intentional design: a platform-operated validator would introduce a centralization vector that compromises the Category 1 Model B Pillar 7 ("no admin override") posture. The platform's role is application-layer (programs, RPC, monitoring, oracle relays) — not consensus.
5.10 Network Constants and Reference Values
The following constants are used elsewhere in this whitepaper and in the Smart Contract Reference. Their values are pinned by the V10 specification:
SLOT_DURATION_MS
400
Average Solana slot duration
SLOTS_PER_SECOND
2.5
Inverse of slot duration
SLOTS_PER_MINUTE
150
60 × 2.5
SLOTS_PER_HOUR
9,000
60 × 150
SLOTS_PER_DAY
216,000
24 × 9,000
SLOTS_PER_YEAR
78,840,000
365 × 216,000
STAKING_EPOCH_SLOTS
432,000
~2 days; staking reward distribution cadence
CUSTODY_ATTESTATION_MAX_AGE_SLOTS
4
~1.6 seconds; CV-04 freshness threshold
OFAC_ORACLE_MAX_AGE_SLOTS
216,000
24 hours; SX-34 staleness threshold
AML_ORACLE_MAX_AGE_SLOTS
1,512,000
7 days; IV-12 staleness threshold
TWAP_ORACLE_MAX_AGE_SLOTS
4
~1.6 seconds; CB-22 freshness threshold
NAV_ORACLE_MAX_AGE_SLOTS_DEFAULT_M2
19,440,000
90 days; CB-21 NAV variant default reappraisal cadence
CLASSIFICATION_ORACLE_MAX_AGE_SLOTS_DEFAULT_M3
216,000
24 hours; REG-42 federal variant default classification staleness
FEDERAL_ACTION_DETECTION_SLA_SLOTS_M3
9,000
60 minutes; REG-42 federal variant SLA
HOLDING_PERIOD_REG_D_SLOTS
39,447,000
~6 months; Reg D HP-24 enforcement
HOLDING_PERIOD_REG_S_SLOTS
78,840,000
~12 months; Reg S HP-24 enforcement
HOLDING_PERIOD_REG_CF_SLOTS
78,840,000
~12 months; Reg CF HP-24 enforcement
REGULATORY_FREEZE_TIMELOCK_SLOTS
432,000
48 hours; Control 42 manual-freeze timelock
5.11 Architectural Decision Records — Layer 1
ADR-001
Solana as Layer 1 substrate
March 2025
Dependency analysis (§5.2) eliminated Ethereum L1, Ethereum L2s, Avalanche, Polygon as alternatives. Solana selected for runtime hook + cost + finality + Ed25519 combination.
ADR-002
Custom AMM vs Raydium/Orca
November 2025
GROO beta validated external DEXs bypass all 42 hook controls. Custom CPMM AMM purpose-built around Token-2022 hook semantics required.
ADR-005
PDA rent-funding economics
June 2025
All platform PDAs funded to rent-exemption at creation; rent-exempt minimum computed at program-deployment time.
ADR-006
transfer_hook immutability
August 2025
transfer_hook deployed with no upgrade authority. Defects must be addressed via re-deployment to a new program ID and migration path, never via in-place upgrade.
ADR-007
Token-2022 trust assumption
September 2025
Residual L1 trust on Solana Foundation's Token-2022 upgrade authority disclosed in Risk Disclosure; mitigated by version-pinning + monitoring + Control 42 contingency.
ADR-009
Stablecoin settlement (USDC, PYUSD)
December 2025
Per GENIUS Act framework; atomic on-chain settlement matched to ~400 ms finality; no fiat wires; no native crypto.
ADR-010
Jito MEV protection
December 2025
December 2025 GRLF beta validated 85% bot share. Jito Block Engine integration mandatory for CEDEX.
5.12 Cross-References
Section 6 — Layer 2 Transfer Hook (the program loaded into the Token-2022 hook extension)
Section 11 — Empire Stock Transfer §17A custody and the per-slot Ed25519 attestation flow
Section 12 — Oracle Network (the seven oracle PDAs deployed under
oracle_aggregator)Section 13 — CEDEX Market (the
ammprogram's settlement layer)Section 14 — Global Unified Liquidity Pool (the
liquidity_poolprogram)Section 15 — Security Model and Formal Verification (Certora invariants E.1 through E.6)
Smart Contract Reference — full account schemas, instruction interfaces, and program ID registry
Network Configuration — production deployment parameters, RPC endpoints, monitoring dashboards
Infrastructure Overview — Helius / Triton / Jito / Datadog deployment diagram
RWA Tokens Platform Whitepaper · Section 5 — Layer 1: Solana Blockchain Foundation · V10.0 · Groovy Company, Inc.
Last updated
Was this helpful?