ERC-3643 vs ST22 — Seven-Pillar Category 1 Model B Comparison

Section 14: ERC-3643 vs ST22 — Seven-Pillar Category 1 Model B Comparison

RWA Tokens Platform Whitepaper · Version 10.0 Groovy Company, Inc. · May 2026 Document Reference: RWA-COMPARE-001 v2.0

This section provides the formal architectural comparison between ERC-3643 (T-REX standard, Ethereum) and ST22 (SPL Token-2022 Transfer Hook, Solana) against the seven pillars of SEC Category 1 Model B per SEC–CFTC Release No. 33-11412 and the January 28, 2026 Joint Staff Statement on Tokenized Securities.

14.1 Reference Frameworks

The comparison is anchored to the SEC's binding federal taxonomy:

Framework

Authority

Five-Category Taxonomy

SEC–CFTC Release No. 33-11412 (March 17, 2026)

Seven Pillars of Category 1 Model B

SEC Joint Staff Statement on Tokenized Securities (January 28, 2026)

Runtime-Enforcement Weight

SEC Staff Statement on Covered User Interface Providers (April 13, 2026)

14.2 Standards Under Comparison

14.2.1 ERC-3643 (T-REX Standard)

Attribute

Value

Specification

EIP-3643 — December 2023, Final

Reference implementation

T-REX (Tokeny)

Underlying chain

Ethereum L1 + EVM L2s

Underlying token standard

ERC-20 (with overlays)

Compliance mechanism

Application-layer ComplianceContract + IdentityRegistry

Total tokenized

$32B+ across 8+ years (cumulative)

Adopters

Tokeny, Securitize (partial), Polymath legacy

14.2.2 ST22 (Platform Standard)

Attribute

Value

Specification

RWA Tokens Whitepaper V10 Section 3 + SPL Token-2022

Reference implementation

Platform transfer_hook Solana program

Underlying chain

Solana Mainnet-Beta

Underlying token standard

SPL Token-2022 (with transfer-hook-interface v0.6+ extension)

Compliance mechanism

Runtime-enforced 42-control Transfer Hook + module-aware extensions

Total tokenized

Platform launch Q3 2026

Adopters

RWA Tokens platform across all three modules

14.3 Pillar-by-Pillar Comparison

14.3.1 Pillar 1 — Direct Issuer Authorization

Requirement: Board resolution authorizing the mint; tokenization is the issuer's act, not a third party's.

ERC-3643: Authorization is off-chain only. The issuer signs paperwork; the smart contracts have no on-chain attestation of issuer authorization. There is no contract-level mechanism that refuses to mint if the issuer's board has not authorized — that check is process-layer only.

ST22: Empire Stock Transfer's onboarding gate refuses to initialize the SecurityConfig PDA without a filed Certificate of Designation (M1) / Articles of SAE (M2) / Articles of BAE (M3). The issuer's board resolution is verified by Empire as part of KYB before the mint is created. The mint_authority is set to the issuer's multi-sig at creation, structurally tying mint authority to the issuer.

Verdict: ERC-3643 ⚠️ off-chain only · ST22 ✅ on-chain via Empire onboarding gate

14.3.2 Pillar 2 — Official Shareholder Register on DLT

Requirement: The DLT (token ledger) is legally the shareholder register, not a mirror of an external authoritative source.

ERC-3643: The ERC-20 balanceOf function returns token holdings. These balances are NOT the legal shareholder register. The legal register is maintained off-chain by the issuer or a transfer agent; the on-chain balances are reconciled to the off-chain register periodically. Drift can occur, and resolution favors the off-chain register.

ST22: The Empire MSF is the legally controlling shareholder register under W.S. 34-29-101. The SPL Token-2022 ledger is the transfer notification layer. The two are reconciled every Solana slot (~400 ms) via the Custody Oracle Ed25519 attestation. The on-chain ledger is the legally effective transfer-notification under Wyoming digital-asset law; the MSF is the ultimate legal register, and the architecture treats them as one continuously-reconciled system rather than two systems with periodic sync.

Verdict: ERC-3643 ❌ token ledger ≠ register · ST22 ✅ MSF + on-chain ledger reconciled per slot

14.3.3 Pillar 3 — SEC §17A-Registered Qualified Custody

Requirement: A SEC §17A-registered qualified custodian holds the underlying.

ERC-3643: Custody is at issuer discretion. Some ERC-3643 deployments use a §17A custodian; many use a crypto-native custodian (BitGo, Fireblocks, Anchorage); some use the issuer itself. There is no architectural requirement.

ST22: Empire Stock Transfer is the architectural requirement. There is no path to issuance that bypasses Empire. Empire holds 1:1 backing of Common Class B (M1) / SAE equity (M2) / BAE equity (M3). Empire is also the sole investor onboarding authority. The architecture is structurally bound to a §17A-registered transfer agent.

Verdict: ERC-3643 ⚠️ optional · ST22 ✅ architecturally required

14.3.4 Pillar 4 — True Equity Backing (1:1)

Requirement: Each token is backed by real equity in the underlying.

ERC-3643: Backing is verified off-chain via auditor attestation, periodic. Auditor reviews custody balances vs token supply and produces an attestation report. There is no on-chain mechanism that verifies backing on every transfer.

ST22: The Custody Oracle Ed25519 attestation per Solana slot is verified by Control CV-01 on every transfer. Every transfer revertsif total_supply + transfer_amount > custodied_balance. Backing verification is continuous and cryptographic, not periodic and audit-mediated.

Verdict: ERC-3643 ⚠️ off-chain attestation periodic · ST22 ✅ per-slot Ed25519 verified on every transfer

14.3.5 Pillar 5 — Clear Ownership Chain / Asset Identifier

Requirement: On-chain mapping from token to underlying equity.

ERC-3643: ONCHAINID maps wallets to identity but does NOT map tokens to specific equity instruments. CUSIP / DTC chain lookups are off-chain. The link from on-chain token to off-chain equity is process-mediated.

ST22: SecurityConfig.asset_identifier stores CUSIP (M1) / property ID (M2) / basin ID (M3) on-chain. Control CV-05 verifies on every transfer that the bound asset identifier matches the Custody Oracle's reported asset-identifier hash. The on-chain mapping is enforced runtime.

Verdict: ERC-3643 ⚠️ off-chain mapping · ST22 ✅ on-chain via Control CV-05

14.3.6 Pillar 6 — Investor Protection (Compliance at Every Transfer)

Requirement: Compliance checks execute on every transfer; no bypass exists.

ERC-3643 — The Bypass Problem:

The ERC-3643 standard adds compliance overlay via:

// Standard ERC-3643 transfer override pattern
function transfer(address to, uint256 amount) public override returns (bool) {
    require(compliance.canTransfer(msg.sender, to, amount), "Compliance blocked");
    require(identityRegistry.isVerified(to), "Recipient not verified");
    return super.transfer(to, amount);  // Calls standard ERC-20 transfer
}

This is application-layer code in a contract that holds the token logic. The bypass surface includes:

Direct ERC-20 inheritance bypass — if the contract inherits from a base ERC-20 without the override (developer error), transfer() skips compliance entirely
Proxy upgrade bypass — proxy upgrades can introduce a new contract version that omits the override
Direct token-transfer instruction bypass — at the EVM bytecode level, transfer is just a state mutation; compliance is just a require statement that can be bypassed by a contract that calls into the storage layer differently
Cross-contract call bypass — wrapper contracts can interpose and forward without triggering the compliance check
Hacken and Kaspersky audit findings — public audits of T-REX flag this surface as a governance/code-quality risk

ST22 — Runtime Enforcement:

ST22 compliance is at the SPL Token-2022 program level, which is part of the Solana runtime:

// Token-2022 program logic (Solana runtime)
// On every transfer instruction targeting a hook-extended mint:
fn process_transfer(/* ... */) -> ProgramResult {
    let mint_extensions = read_mint_extensions(mint);
    if let Some(hook_program_id) = mint_extensions.transfer_hook_program_id() {
        // The runtime REFUSES to process the transfer without invoking the hook
        invoke_signed(
            &hook_program_id,
            &transfer_data,
            &[/* ... */]
        )?;
    }
    // Settlement only proceeds if hook returned success
    update_balances(/* ... */);
    Ok(())
}

The runtime enforces hook invocation. There is no transfer instruction that skips it. This is closer to an OS system call than to a smart-contract function. The bypass surface includes:

❌ Direct ERC-20 bypass — N/A (different chain, different runtime; no analog)
❌ Proxy upgrade bypass — N/A (Solana programs don't use proxy upgrade pattern; upgrade authority can replace the program but cannot remove the hook-extension binding from the mint)
❌ Direct instruction bypass — Token-2022 refuses transfer without hook invocation
❌ Cross-program bypass — wrapper programs cannot interpose; the wrapper must still invoke Token-2022, which still invokes the hook

Verdict: ERC-3643 ⚠️ application-layer (bypassable) · ST22 ✅ runtime-enforced

14.3.7 Pillar 7 — Token Standard Compliance (Immutable, No Admin Override)

Requirement: Compliance logic is immutable post-deployment; no admin function can move tokens or alter compliance.

ERC-3643 — Admin Functions:

ERC-3643 (T-REX) includes the following admin functions:

Function

Effect

forceTransfer(from, to, amount)

Admin can move any holder's tokens without consent

freezePartialTokens(account, amount)

Admin can freeze specific token amounts

unfreezePartialTokens(account, amount)

Admin can unfreeze

recoveryAddress()

Admin can redirect tokens to a recovery address

updateIdentityRegistry()

Admin can change who is verified

setCompliance()

Admin can replace the compliance contract

Proxy upgradeTo(newImpl)

Admin can upgrade the entire token contract

These admin functions are documented in the ERC-3643 standard and in T-REX implementation. They permit the admin to move tokens without holder consent, change compliance logic post-deployment, and override the standard's stated compliance posture.

ST22 — Immutability:

ST22 includes none of the above:

Function

ST22

Force-transfer holder tokens

Does not exist

Freeze partial balance

Halt-only via Control 42 (cannot move tokens)

Recovery address

Does not exist

Modify identity verification

Empire verification is external — not modifiable by the platform

Replace compliance program

Transfer Hook program ID bound to mint at creation; cannot be repointed

Program upgrade authority

Bound by Solana program upgrade authority + 48-hour timelock + Certora E.4 specification compliance

The investor's wallet signature is the only path to debit a token account. Control 42 (Regulatory Freeze) can halt all transfers on a mint pending Legal Counsel signoff and 3-of-5 multi-sig, but it cannot move tokens. Module 3's REG-42 federal-action variant automates Control 42 on detection of qualifying federal action with halt-only semantics.

Certora invariants E.4 and E.6 formally prove:

E.4: 42 core controls and module-aware extensions cannot be removed, weakened, or repointed post-deployment
E.6: Transfer Hook program ID for a given mint cannot be changed post-creation

Verdict: ERC-3643 ❌ proxy upgrades + admin functions · ST22 ✅ bound at creation

14.4 Comparison Scorecard

Pillar

ERC-3643

ST22

Direct Issuer Authorization

⚠️ off-chain only

✅ on-chain Empire onboarding gate

Official Shareholder Register on DLT

❌ token ledger ≠ register

✅ MSF + on-chain ledger reconciled per slot

SEC §17A-Registered Qualified Custody

⚠️ optional

✅ architecturally required (Empire)

True Equity Backing 1:1

⚠️ off-chain attestation periodic

✅ per-slot Ed25519 (Control CV-01)

Clear Ownership Chain / Asset ID

⚠️ off-chain mapping

✅ on-chain via Control CV-05 (CUSIP / property ID / basin ID)

Investor Protection

⚠️ application-layer (bypassable)

✅ runtime-enforced (42 controls + module extensions)

Token Standard Immutability

❌ proxy upgrades + admin functions

✅ bound at creation (Certora E.4, E.6)

Native compliance score:

ERC-3643: 3/7 (optimistic — Pillars 1, 3, 5 with disciplined off-chain process)
ST22: 7/7

14.5 The Category 1 vs Category 2 Mapping

Under SEC–CFTC Release No. 33-11412 and the Joint Staff Statement of January 28, 2026:

Category 1 Model B requires DLT to be the official register with runtime-level compliance enforcement
Category 2 is the application-layer overlay pattern where compliance can be bypassed

Application-layer overlays cannot satisfy "DLT in official shareholder records" because the SEC explicitly defined that pillar as runtime-level integration. That is why ERC-3643 maps natively to Category 2 and ST22 maps natively to Category 1 Model B.

14.6 Cross-Module Architectural Implications

V10 introduces module-aware extensions (CB-21 NAV variant for M2; REG-42 federal-action variant for M3). The seven-pillar comparison applies identically across all three modules — the module-aware extensions are additive runtime checks that further strengthen Pillar 6 (compliance at every transfer) for the specific risk vectors of Modules 2 and 3.

Pillar

M1 Status

M2 Status

M3 Status

1. Issuer Authorization

✅

2. DLT Register

✅

3. §17A Custody

✅ (Common B)

✅ (SAE equity)

✅ (BAE equity)

4. 1:1 Backing

✅ (CV-01)

✅ (CV-01 + NAV oracle)

✅ (CV-01)

5. Asset ID

✅ (CUSIP)

✅ (property ID)

✅ (basin ID)

6. Investor Protection

✅ (42 controls)

✅ (42 controls + CB-21 NAV variant)

✅ (42 controls + REG-42 federal variant)

7. Immutability

✅

ST22 satisfies all seven pillars natively across all three modules. ERC-3643 has no native cross-module composability — every additional asset class would require separate contract deployments and separate compliance overlay code, increasing the bypass surface and audit burden linearly with the number of asset classes addressed.

14.7 Other Tokenization Standards — Brief Comparison

Standard

Native Score

Comments

ERC-1400 (Polymath legacy)

2/7

Predecessor to ERC-3643; fewer compliance hooks

ERC-3643 (Tokeny T-REX)

3/7

Section 14.3 detailed

ERC-1404 (Restricted Token)

1/7

Whitelist-only; no comprehensive framework

ERC-2222 (Funds Distribution Token)

1/7

Distribution-focused; minimal compliance surface

BlackRock BUIDL (Securitize)

4/7

Tokenized treasury fund; §17A custody yes; some application-layer overlay

Ondo USDY

3/7

Treasury-tokenization; Bermuda exempted-fund structure

Franklin Templeton FOBXX

5/7

OnChain U.S. Government Money Fund; SEC-registered

Dinari dShares

5/7

NYSE/NASDAQ Category 2 tokenization; complementary to platform's Module 1

RWA Tokens ST22

7/7

This whitepaper

14.8 Practical Implications

The seven-pillar gap between ERC-3643 (3/7) and ST22 (7/7) translates into practical differences:

Operational Aspect

ERC-3643 Reality

ST22 Reality

Compliance enforcement

Process discipline + audits

Cryptographic proof on every transfer

Backing verification

Periodic auditor attestation

Per-slot Ed25519

Bypass risk

Real (multiple paths documented)

Zero (runtime-enforced)

Admin override risk

Real (forceTransfer, recovery, upgrade)

Zero (no admin functions in compliance program)

Multi-asset-class composability

Per-product separate deployments

Single architecture, three modules

Regulatory characterization

Category 2 by structure

Category 1 Model B by structure

Per-issuer market maker requirement

Often required

Not required (Global Pool)

Pool rugpull risk

Real (LP can withdraw)

Zero (Certora E.3, LP burned)

RWA Tokens Whitepaper V10 — Section 14 — Confidential — Groovy Company, Inc.

PreviousTokenomics NextSecurity Model and Formal Verification

Last updated 1 month ago

Was this helpful?