For the complete documentation index, see llms.txt. This page is also available as Markdown.

Solana Blockchain Foundation

Solana Blockchain Foundation

Why Solana · How It Works · SPL Token-2022 · Module-Specific Foundations

This page explains the blockchain foundation that the RWA Tokens platform is built on — Solana Mainnet-Beta and the SPL Token-2022 Transfer Hook extension — and how that foundation supports each of the platform's three production modules: Equities, Real Estate, and CORECM (Carbon Ore, Rare Earth, and Critical Minerals).

It is written for institutional evaluators, prospective issuers, regulatory counsel, and capital-markets professionals who need to understand why Solana is the only chain where the platform's runtime-enforced compliance architecture can exist today — and what that means for each asset class the platform tokenizes.


Table of Contents

  1. ​Why Solana​

  2. Solana Architecture at a Glance

  3. ​Consensus and Finality​

  4. ​Parallel Execution​

  5. ​SPL Token-2022 — The Tokenization Standard​

  6. ​Transfer Hook — Runtime-Enforced Compliance​

  7. ​Why Ethereum Cannot Do This​

  8. ​Module-Specific Foundations​

    1. 8.1 Module 1 — Equities

    2. 8.2 Module 2 — Real Estate

    3. 8.3 Module 3 — CORECM

  9. ​Network Stability and Operational Resilience​

  10. ​Performance Comparison​

  11. ​Regulatory Alignment​

  12. ​Related Documentation


1. Why Solana

The RWA Tokens platform chose Solana for one reason above all others: SPL Token-2022 Transfer Hooks provide runtime-enforced compliance that cannot be bypassed.

This is not a preference. It is the only blockchain on which the platform's 42-control compliance architecture can be built as specified. Every other chain — Ethereum, the Ethereum Layer 2 ecosystem, Polygon, Avalanche, BNB Chain — implements security-token compliance at the application layer, where any caller with direct access to the underlying token contract can bypass the compliance wrapper. Solana's Token-2022 standard moves compliance into the token program itself, where bypass is structurally impossible. The decision is documented in the platform's Architecture Decision Records (ADR-001) with full alternatives analysis.

The secondary advantages — the approximately 400-millisecond block cadence that aligns with Empire Stock Transfer's per-block custody attestation, the per-transaction cost of approximately $0.00025 that makes per-transfer compliance economically viable, and the theoretical throughput exceeding 65,000 transactions per second — are significant but subordinate to the Transfer Hook capability.

The Core Comparison

RequirementSolanaEthereum L1Ethereum L2

Runtime-enforced compliance

Yes — Transfer Hook

No — application layer only

No — inherits L1 limitation

Compliance bypass path

None

Direct transfer() call bypasses wrapper

Same as L1

Block time

~400ms

12–15 seconds

2–15 seconds

Per-transfer cost

~$0.00025

$1–$50+

~$0.01

Per-transfer compliance economically viable

Yes — at any market capitalization

No — prohibitive below $10M

Marginal

Custody attestation cadence

Per block (~400ms)

Minutes to hours

Minutes

For a regulated tokenization platform, only the first row matters in absolute terms. The remaining rows determine whether the platform is operationally viable; the first row determines whether it can exist at all.


2. Solana Architecture at a Glance

Solana is a Layer 1 blockchain designed for high throughput and low latency. It is structurally different from Ethereum in two ways that matter for tokenization: it processes transactions in parallel rather than sequentially, and it produces a verifiable cryptographic clock (Proof of History) that allows validators to agree on transaction ordering without communicating timestamps to each other.

Core Subsystems

SubsystemFunctionRelevance to RWA Tokens

Proof of History (PoH)

Cryptographic clock — sequential SHA-256 hashing produces verifiable ordering of events

Provides the ~400ms block cadence that aligns with Empire Stock Transfer's per-block custody attestation

Tower BFT

Byzantine Fault-Tolerant consensus optimized for PoH; validators vote on block validity

Two-thirds supermajority confirmation produces deterministic finality within ~13 seconds

Sealevel

Parallel transaction execution engine

Different ST22 mints can execute transfers simultaneously — enables platform throughput at scale

Gulf Stream

Mempool-less transaction forwarding to upcoming validator leaders

Reduces latency between submission and inclusion

Turbine

Block propagation through validator network

Maintains synchronization across 2,000+ validators

Cloudbreak

Parallel-I/O accounts database

Stores all on-chain state, including ST22 mint accounts and compliance configuration

Network-Level Properties

PropertyValueWhy It Matters

Block time

~400ms

One full custody-attestation cycle per block

Theoretical throughput

65,000+ TPS

Headroom for thousands of compliance-verified trades

Compliance-verified throughput

400–600 TPS

Limited by oracle query latency, not Solana itself

Transaction cost

~$0.00025

Per-transfer 42-control verification is economically viable at any issuer market cap

Finality

~13 seconds (32 confirmations)

Trading reads use confirmed; settlement uses finalized

Validator count

2,000+

Decentralized consensus; no single-entity control

Validator client diversity

Agave + Firedancer

Two independent implementations reduce correlated-failure risk


3. Consensus and Finality

Proof of History

Solana's primary innovation. Proof of History is a cryptographic clock — a verifiable delay function that produces a hash chain proving that time has passed between events. Each hash is the SHA-256 of the previous hash, and the chain cannot be parallelized: producing hash N requires having produced hash N-1. Transactions are inserted into the hash chain at specific positions, proving they occurred at specific points relative to other transactions.

For tokenization, PoH provides something other chains cannot: a deterministic ~400-millisecond block cadence, which is the operational interval at which Empire Stock Transfer's custody oracle posts its per-block attestation that backing collateral remains intact. On Ethereum's 12-to-15-second block time, per-block attestation would mean custody verification every 12-plus seconds — a roughly thirty-fold degradation in real-time backing verification.

Tower BFT

Solana's consensus mechanism. Validators vote on the validity of PoH sequences. Once two-thirds or more of staked SOL has voted on a block, that block is considered confirmed. After 32 confirmed blocks (approximately 13 seconds), the block is finalized — the strongest level of certainty before economic settlement.

Confirmation LevelThresholdTimePlatform Usage

Processed

Leader confirms

~400ms

Not used — too risky for institutional trading

Confirmed

2/3+ supermajority

~400ms

CEDEX read operations, oracle updates

Finalized

31+ confirmed blocks

~13 seconds

CEDEX settlement, fee distribution, custody mark-offs


4. Parallel Execution

Sealevel is Solana's parallel transaction-execution engine. Unlike Ethereum's EVM, which executes transactions one at a time, Sealevel can execute thousands of transactions simultaneously across all available CPU cores — provided those transactions don't read or write the same accounts.

Why this matters for the platform: ST22 transfers for different mints (different issuers, different properties, different mineral basins) can execute in parallel because they touch independent state accounts. Transfers for the same mint serialize because they share the SecurityConfig account that governs that issuance. The result is that platform throughput scales horizontally as more issuances launch — adding a new issuer does not slow down trading for existing ones.

This property has direct economic significance for issuers in all three modules: a tokenized property in Module 2 does not compete for execution bandwidth with a tokenized rare-earth basin in Module 3 or a tokenized OTC microcap equity in Module 1.


5. SPL Token-2022 — The Tokenization Standard

Solana has two token programs. The distinction between them is the foundation of the RWA Tokens platform's security architecture.

SPL Token (Original Standard)

The original Solana token program. Supports mint, transfer, burn, approve, and revoke operations. Has no Transfer Hook support — transfers execute without any custom logic. This is the program every major Solana DEX (Raydium, Orca, Jupiter, Meteora) was built around.

SPL Token-2022 (Extended Standard)

Solana Labs' next-generation token program. Includes all original SPL Token functionality plus a set of programmable extensions. Includes the Transfer Hook extension — a custom program that the Token-2022 runtime invokes on every transfer.

ST22 Digital Securities — the platform's tokenized representation across Equities, Real Estate, and CORECM — are issued under SPL Token-2022 with the Transfer Hook extension permanently attached at mint creation.

Token-2022 Extensions Used by the Platform

ExtensionPurposeUsed by RWA Tokens?

Transfer Hook

Custom program executed on every transfer

Yes — the 42 compliance controls

Transfer Fee

Protocol-level fee on every transfer

Yes — funds the Global Unified CEDEX Liquidity Pool

Metadata

On-chain token name, symbol, URI

Yes — issuer identity, property identity, basin identity

Permanent Delegate

Irrevocable transfer authority for compliance freeze

Yes — Empire Stock Transfer regulatory-freeze authority

Confidential Transfer

Zero-knowledge encrypted balances

Not currently used

Interest-Bearing

Token balance accrues interest

Not applicable to equity, real estate, or basin assets

Default Account State

Accounts created frozen by default

Not currently used

Why External DEXs Cannot Trade ST22

Raydium, Orca, Jupiter, and Meteora were built before Token-2022 existed. Their swap programs call the original SPL Token Program — which has no Transfer Hook support. When an ST22 token is sent to one of these DEXs, the DEX's program invokes the original Token Program for the transfer, and the Transfer Hook is never triggered. All compliance controls are bypassed.

This is not a configuration issue. It is a fundamental architectural incompatibility. The DEX would need to rewrite its swap program to call Token-2022 instead of the original Token Program, and no major Solana DEX has done so because there is no commercial incentive for them: unprotected tokens generate higher trading volume, more fees, and more extractable value.

The platform's CEDEX trading venue is built specifically around Token-2022 and the Transfer Hook. Every CEDEX swap invokes the Transfer Hook via Cross-Program Invocation — meaning all 42 controls execute on every trade, atomically and irrevocably.


6. Transfer Hook — Runtime-Enforced Compliance

What a Transfer Hook Is

A Transfer Hook is a program address permanently stored in a Token-2022 mint account at the time of mint creation. When any transfer instruction is executed for tokens from that mint, the Token-2022 program automatically invokes the specified hook program before the transfer completes. If the hook returns success, the transfer proceeds. If the hook returns an error, the entire transaction reverts atomically — no tokens move, no fees are collected, no state changes persist.

The Five Properties That Make This Different

PropertyWhat It MeansWhy It Matters

Permanent

Hook address is stored in the mint account at creation; cannot be removed, changed, or disabled afterward

Compliance is permanent for the lifetime of the security

Mandatory

The Token-2022 runtime invokes the hook automatically; it is not optional

No caller, wallet, DEX, smart contract, or script can skip the hook

Atomic

Hook rejection reverts the entire transaction in a single state machine step

No partial state — either fully compliant or fully reverted

Universal

Executes regardless of caller identity or entry point

The platform itself cannot bypass its own controls

Runtime-enforced

Invocation is performed by the Token-2022 program — a Solana system program

Enforcement is by the protocol, not by application code

What "Runtime-Enforced" Actually Means

The Transfer Hook is not a smart contract call that an application chooses to make. It is executed by the Token-2022 program — which is part of the Solana protocol itself — as a mandatory step in transfer-instruction processing. This is structurally analogous to the way a Solana transaction cannot execute without paying its base fee: the fee is part of the protocol, not a policy choice that an application can opt out of.

Enforcement LevelExampleBypass Path

Policy

Terms of service

User ignores the ToS

Application

ERC-3643 compliance overlay

Direct EVM call to underlying transfer()

Smart contract

Restricted-token contract

Admin override function

Runtime

SPL Token-2022 Transfer Hook

None — enforced by the token program itself

The platform's 42 controls operate at the runtime level. There is no transferWithoutHook() function. There is no admin key that disables the hook. There is no governance vote that removes controls. The hook is permanent, mandatory, and atomic.

The Compliance Control Set

Every ST22 transfer triggers a sequence of 42 controls. The full specification is documented in the platform's Transfer Hook Technical Specification. The categories are:

CategoryControlsFunction

Custody verification

1–6

Empire Stock Transfer Ed25519 attestation that backing collateral is intact

OFAC / SDN screening

8–10

Real-time sanctions-list check against sender and recipient

AML risk scoring

11

Chainalysis Know-Your-Transaction and TRM Labs three-tier risk score

KYC / Accreditation

12–14

Investor identity and accreditation status

Holding period

24

Rule 144 and Regulation S compliance lock periods

Position limits

15–19

Per-wallet ownership ceiling (4.99% threshold)

Circuit breakers

20–23

Volatility halts and reappraisal triggers

CEI integrity

29–35

Constant-product market-maker invariant checks

Protective conversion

35–38

Cliff-date and conversion mechanics

Audit trail and governance

39–42

Event emission and regulatory-freeze authority

Every control executes on every transfer in every module. The platform cannot route around them.


7. Why Ethereum Cannot Do This

ERC-3643 — Application-Layer Compliance

Ethereum's leading security-token standard, ERC-3643 (also called T-REX), implements compliance as a set of smart-contract calls that wrap the underlying ERC-20 transfer function. The compliance checks — OnchainID, Identity Registry, Compliance Contract — execute before the transfer, but they are application-layer logic rather than runtime enforcement.

The Bypass Problem

Any caller with direct EVM access can call the underlying ERC-20 transfer() function on the token contract without going through the T-REX compliance wrapper. This is not a bug in ERC-3643. It is a structural limitation of building compliance on top of a token standard rather than inside it.

The Admin-Override Problem

ERC-3643 includes administrator functions that have no equivalent in Token-2022:

ERC-3643 FunctionPurposeToken-2022 Equivalent

forceTransfer()

Administrator moves tokens without holder consent

Does not exist

freezePartialTokens()

Administrator freezes a portion of holdings

Does not exist

recoveryAddress()

Administrator redirects tokens to recovery wallet

Does not exist

updateIdentityRegistry()

Administrator modifies the verified-identity list

Empire verification is external; the platform cannot modify it

These functions exist in ERC-3643 for legitimate operational reasons — regulatory freeze, lost-key recovery — but they also create an attack surface where a compromised administrator can move investor tokens unilaterally. In the platform's architecture, the equivalent of a regulatory freeze (Control 42) halts all transfers across the affected mint; it cannot selectively redirect tokens.

The Cost Problem

Even if Ethereum added a Transfer Hook equivalent, the gas cost of executing 42 compliance checks on every transfer would be prohibitive at L1, and marginal at L2:

OperationSolana CostEthereum L1 CostCost Ratio

Transfer with 42 compliance checks

~$0.00025

$5–$50+

20,000× to 200,000×

Custody oracle read

~$0.00001

$0.50–$5

50,000× to 500,000×

Annual cost at 1,000 transfers/day

~$91

$1.8M–$18M

Economically infeasible on L1

For a CORECM basin-asset issuance with thousands of small institutional positions trading periodically, the difference between Solana economics and Ethereum economics is the difference between a viable platform and an impossible one.


8. Module-Specific Foundations

The platform's three production modules share the same Solana foundation, the same Token-2022 standard, and the same 42-control Transfer Hook framework — but each module exercises specific Solana properties for module-specific operational reasons.

8.1 Module 1 — Equities

What gets tokenized: Equity securities of companies listed on the OTC microcap market, NASDAQ, NYSE American (AMEX), the Toronto Stock Exchange (TSX), and additional global exchanges. Tokens are issued as ST22 Digital Securities backed 1:1 by Common Class B shares of the issuer held in qualified custody by Empire Stock Transfer.

Solana properties exercised:

PropertyUse in Module 1

~400ms block time

Per-block custody attestation aligns with Empire's Ed25519 signing cadence — investors can verify backing collateral is intact in near real-time

Sealevel parallel execution

Different issuers' ST22 mints execute trades in parallel; one issuer's volume does not slow another

Token-2022 metadata extension

On-chain issuer identity, CUSIP reference, and exemption-class tagging

Transfer Hook Control 24

Rule 144 and Regulation S holding periods enforced atomically per investor

Transfer Hook Controls 12–14

Per-investor accreditation status verified on every transfer

Regulatory framework: Operates under the platform's SEC Category 1 Model B architecture as described in SEC Release No. 33-11412 (March 17, 2026), informed by the Joint Staff Statement on Tokenized Securities (January 28, 2026). Issuance offerings are conducted under Regulation D for U.S. accredited investors, Regulation S for non-U.S. investors, and Regulation Crowdfunding (Reg CF) for U.S. retail.

8.2 Module 2 — Real Estate

What gets tokenized: Direct-ownership interests in real-property assets — commercial, residential, and mixed-use. Each tokenized property is issued by a single-asset entity holding the underlying property, with backing collateral held by Empire Stock Transfer.

Solana properties exercised:

PropertyUse in Module 2

Sealevel parallel execution

Each property is a separate mint with an independent SecurityConfig account; properties trade in parallel without interference

Token-2022 metadata extension

On-chain property identifier, jurisdiction, appraisal-cycle tag, and NAV reference

Transfer Hook Controls 20–23

Circuit-breaker controls calibrated to NAV reappraisal cycles — trading halts when on-chain price diverges from appraised value beyond defined thresholds

Transfer Hook Controls 29–35

Constant-product market-maker invariant checks enforce that secondary-market pricing remains consistent with NAV-anchored bands

Per-block finality

Settlement finalizes within ~13 seconds — meaningful for property positions where holders may need to liquidate quickly relative to traditional real-estate settlement timelines

Pricing architecture: Module 2 uses appraisal-anchored Net Asset Value pricing with a constant-product market-maker mechanism on CEDEX. Circuit-breaker controls activate when on-chain price moves outside reappraisal-defined bands, pausing trading until the next appraisal cycle confirms or revises the NAV.

8.3 Module 3 — CORECM

What gets tokenized: Basin-asset interests within the United States strategic minerals supply chain — Carbon Ore (including Department of Energy coal-derived rare-earth element recovery initiatives), Rare Earth elements, and Critical Minerals as defined by U.S. federal frameworks.

Solana properties exercised:

PropertyUse in Module 3

Token-2022 metadata extension

On-chain basin identifier, USGS Critical Minerals List classification, jurisdiction, mineral-class tag

Transfer Hook Controls 8–10

OFAC and SDN screening — particularly relevant for strategic minerals subject to export-control regimes

Transfer Hook Controls 12–14

Investor accreditation verification before any transfer of a strategic-mineral basin position

Permanent Delegate extension

Regulatory-freeze authority routed through Empire Stock Transfer in coordination with U.S. agencies if a basin asset becomes subject to federal action

Cross-mint parallel execution

Each basin asset is an independent mint; trading activity in one basin does not affect another

Regulatory alignment: Module 3 is aligned to the regulatory and policy frameworks established by the United States Geological Survey Critical Minerals List, the U.S. Department of Energy Critical Materials Strategy, Section 232 of the Trade Expansion Act of 1962, Title III of the Defense Production Act, the critical-minerals provisions of the Inflation Reduction Act, Executive Order 14017 ("America's Supply Chains"), and the Energy Act of 2020. Each Module 3 issuance is subject to issuer-level technical and regulatory diligence in addition to the platform's standard offering-exemption framework.

Cross-Module Properties

What every module gets from the same Solana foundation:

  • Identical security guarantees. The Transfer Hook executes the same 42 controls regardless of asset class. A real-estate token receives the same atomic compliance enforcement as an equity token or a basin token.

  • Identical settlement mechanics. All three modules settle with ~13-second finality on Solana. There is no asset class that gets weaker settlement guarantees because of its structure.

  • Identical custody architecture. Empire Stock Transfer serves as the qualified custodian for backing collateral across all three modules; the Ed25519 attestation mechanism is the same.

  • Independent execution lanes. A spike in Module 1 equity trading does not slow Module 2 property settlement or Module 3 basin transfers. Sealevel ensures cross-module isolation.


9. Network Stability and Operational Resilience

Historical Context

Solana experienced multiple network outages in 2022 and 2023, raising legitimate concerns about reliability for financial infrastructure. The situation has materially improved through the QUIC networking transition, the deployment of the Firedancer client by Jump Crypto, and the maturation of the validator software stack.

PeriodMajor OutagesLongest OutageStatus

2022

Multiple (7+)

~17 hours

Historical — pre-QUIC

2023

2

~5 hours

Improved — QUIC deployed

2024

0 major

N/A

Stable — Firedancer in testing

2025–2026

0 major

N/A

Production-ready — Firedancer on mainnet

Mitigations the Platform Has in Place

RiskMitigation

Solana network halt

On-chain state is preserved during halts; no data loss. CEDEX pauses and resumes automatically.

Validator client bug

Firedancer (Jump Crypto) provides an independent validator client. Two-client diversity reduces correlated-failure risk.

Network congestion (priority-fee spikes)

Jito Block Engine for priority-fee optimization. Helius dedicated cluster avoids shared-tier congestion.

RPC provider failure

Helius primary plus Triton failover. Automatic failover in SDK and relay services.

What Happens to Each Module During a Solana Halt

SubsystemImpactRecovery

CEDEX trading (all modules)

Trading pauses

Automatic resume on network recovery

Custody oracle attestations

Pause; oracle staleness flag activates

Catch-up on first block of recovered network

Token balances (all modules)

Preserved on-chain

No action needed

Holding-period clocks

Pause (Solana clock stops)

Resume on recovery — no investor disadvantage

Module 2 NAV reappraisal triggers

Pause

Resume on recovery; appraisal cadence unaffected

Module 3 OFAC screening updates

Continue off-chain; queue on-chain updates

Flush queue on recovery

Global Unified CEDEX Liquidity Pool

Balance preserved (immutable program)

No action needed

The key property: a Solana halt is an operational pause, not a state loss. Investor positions, custody attestations, and compliance state survive intact.


10. Performance Comparison

MetricSolanaEthereum L1Ethereum L2 (Arbitrum)Platform Requirement

Block time

~400ms

12–15s

250ms (L2) plus 12s (L1 finality)

Per-block custody attestation

Finality

~13s (32 confirms)

~13 min (64 slots)

Minutes to hours (challenge period)

Settlement within seconds

Throughput (theoretical)

65,000+ TPS

~15 TPS

100–4,000 TPS

400–600 compliance-verified TPS

Transfer cost

~$0.00025

$1–$50+

~$0.01

Per-transfer compliance economically viable

Native runtime compliance

Yes (Token-2022)

Not available

Not available

42-control enforcement at runtime

Parallel execution

Yes (Sealevel)

No (sequential EVM)

No (sequential EVM)

Cross-module / cross-issuer parallelism

Across every metric that matters for runtime-enforced tokenization compliance, Solana is the only chain that meets the platform's requirements without compromise.


11. Regulatory Alignment

The Solana foundation supports the platform's regulatory posture in three concrete ways:

SEC Category 1 Model B architecture. SEC Release No. 33-11412 (March 17, 2026) establishes the Category 1 / Model B framework for digital securities. The Transfer Hook's runtime enforcement of custody, OFAC, AML, KYC, holding-period, and position-limit controls is what allows the platform to operate within this framework. Application-layer compliance — which is all Ethereum can offer today — does not provide the same disclosure-of-controls posture.

Joint Staff Statement on Tokenized Securities (January 28, 2026). The Joint Staff Statement clarified that tokenization does not alter the underlying legal character of a security and confirmed that existing federal securities laws apply to digital-securities issuances. The platform's runtime-enforced compliance is the technical mechanism that operationalizes this clarification: every transfer of every ST22 security across every module is subject to the same controls that would apply to the underlying security off-chain.

Stablecoin settlement under the GENIUS Act. All ST22 purchases on CEDEX settle in stablecoins compliant with the Guiding and Establishing National Innovation for U.S. Stablecoins (GENIUS) Act. Solana's per-block finality and low transaction cost are what make stablecoin-settled tokenized-securities trading economically and operationally viable at institutional scale.


  • Architecture Decisions — ADR-001 (Solana over Ethereum) with full alternatives analysis

  • Smart Contract Reference — All platform programs with instruction specifications and account schemas

  • Transfer Hook Technical Specification — Full 42-control reference

  • Competitive Analysis — ERC-3643 vs ST22 — Architectural and economic comparison

  • Whitepaper Section 2 — Technical Architecture (nine-layer stack)

  • Whitepaper Section 3 — Transfer Hook specification

  • Whitepaper Section 11 — ERC-3643 vs ST22 deep dive

  • Compliance Integration Guide — How module-specific issuances configure the 42 controls

  • Empire Stock Transfer Integration — Custody attestation, onboarding, and regulatory-freeze workflow


RWA Tokens · Solana Blockchain Foundation · Groovy Company, Inc.

Last updated

Was this helpful?