> For the complete documentation index, see [llms.txt](https://bitbook.rwatokens.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://bitbook.rwatokens.net/reference/reference/competitive-analysis.md). # Competitive Analysis ## Competitive Analysis **Digital Securities Market Positioning · ERC-3643 vs. ST22 · Securitize Benchmark · Three-Module Differentiation** Standalone competitive intelligence for investors, the executive team, and institutional evaluators. This document compares the RWA Tokens platform — operated by Groovy Company, Inc. — against the tokenized securities landscape, focusing on Securitize as the primary institutional benchmark, ERC-3643 as the dominant token standard, and module-by-module competitive positioning across Module 1 (Equities), Module 2 (Real Estate), and Module 3 (CORECM — Carbon Ore, Rare Earth, and Critical Minerals). *** ### Table of Contents 1. Market Landscape 2. Securitize — Primary Benchmark 3. ERC-3643 vs. ST22 — Architecture Comparison 4. Broader Competitor Landscape 5. SWOT Analysis 6. Use Case Fit Matrix 7. Transaction Economics 8. Regulatory Positioning 9. Liquidity Model Comparison 10. Where Securitize Wins 11. Where the Platform Wins 12. Strategic Positioning *** ### 1. Market Landscape #### 1.1 Tokenized Asset Market Size — Three-Module View | Segment | Estimated Size | Primary Players | RWA Tokens Module | | ------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | -------------------------------------------- | --------------------------------------------------------------------------------------------------- | | Institutional RWA (BlackRock, Apollo, KKR) | $4B+ tokenized | Securitize, Ondo, Centrifuge | Outside platform scope — different market | | Tokenized treasuries (T-bills, money market) | $2.5B+ AUM (BUIDL alone) | Securitize, Franklin Templeton, Ondo | Outside platform scope — different asset class | | Tokenized large-cap equity (NYSE/NASDAQ S\&P 500) | Emerging | Dinari (DFN), partnership candidate | **Complementary** — Dinari serves Cat-2 large-cap; platform serves Cat-1 across three asset classes | | **Equity securities — OTC microcap, NASDAQ, AMEX, TSX, global exchanges** | **\~$50B+ addressable across global exchanges** | Largely unserved at the microcap end | **Module 1 — Equities** | | **Real estate equity (single-asset entity tokenization)** | **$280T+ global real estate market; addressable subset growing** | Fragmented (RealT, Lofty, Roofstock onChain) | **Module 2 — Real Estate** | | **CORECM — Carbon Ore, Rare Earth, Critical Minerals supply chain** | **No public-chain platform; US strategic priority under EO 14017, IRA, Energy Act of 2020** | **No competitor** | **Module 3 — CORECM (true blue ocean)** | #### 1.2 Why These Markets Are Underserved Institutional tokenization platforms (Securitize, Ondo, Centrifuge) target premium-segment clients — BlackRock, KKR, Hamilton Lane. These platforms cannot economically serve the platform's three-module addressable surface because: * **Gas economics.** $1–$50+ per Ethereum L1 transaction makes per-transfer compliance verification unaffordable for sub-$10M issuers (Module 1 microcap end), per-property tokenization at retail scale (Module 2), or basin-asset trading at the per-transaction granularity strategic-mineral provenance demands (Module 3). * **Minimum capital.** Institutional platforms require $10M+ AUM to justify onboarding costs. * **Compliance overhead.** Per-issuer compliance setup is identical whether the client is BlackRock ($2.5B BUIDL) or a Pink Sheets company ($500K market cap), a single Nevada LLC holding a $2M property, or a basin-asset entity holding a critical-minerals concession. * **Market maker dependency.** Traditional tokenization requires dedicated market makers ($5K–$20K/month) — economically irrational across all three modules at scale. * **No cross-module infrastructure.** No competing platform offers a single architecture that serves equities, real estate, and strategic-minerals tokenization with shared liquidity, shared compliance, and module-aware enforcement. * **No federal-action coordination.** Module 3 specifically requires federal-action freeze coordination (Section 232, DPA Title III, EO-driven export restrictions) — a capability no other platform offers. The platform is purpose-built to serve all three modules through one architecture. The Global Unified CEDEX Liquidity Pool eliminates the market maker requirement uniformly across modules. Solana's \~$0.00025 per transaction makes per-transfer compliance economically viable across the entire addressable surface. Empire Stock Transfer's existing 530+ company infrastructure provides the custody backbone for all three modules. *** ### 2. Securitize — Primary Benchmark #### 2.1 Company Profile | Attribute | Detail | | ---------------- | ---------------------------------------------------------------------------- | | Founded | November 2017 | | Founders | Carlos Domingo, Jamie Finn | | Headquarters | Miami, Florida | | Funding | \~$147–200M across funding rounds | | Valuation | $1.25B (SPAC merger with Cantor Equity Partners II, October 2025) | | Expected listing | NASDAQ under ticker SECZ (H1 2026) | | Key investor | BlackRock (Joseph Chalom on board) | | Assets tokenized | $4B+ | | Registrations | SEC-registered transfer agent, broker-dealer (Securitize Markets), ATS | | Chains | Ethereum (primary), Solana, Polygon, Arbitrum, Avalanche, Aptos, Sei, Hedera | | Token standard | ERC-3643 (T-REX) | | Primary clients | BlackRock (BUIDL), Apollo, KKR, Hamilton Lane, VanEck | #### 2.2 Securitize Registrations | Registration | Scope | | ---------------------------------- | ----------------------------------- | | SEC transfer agent | Shareholder record management | | Broker-dealer (Securitize Markets) | Securities distribution and trading | | Alternative Trading System (ATS) | Secondary market venue | | EU MiCA | European regulatory compliance | #### 2.3 Securitize Architecture Securitize operates as middleware on public blockchains: ``` ISSUER → Securitize Platform (compliance, KYC, issuance) → ERC-3643 token on Ethereum → Securitize Markets (ATS) for secondary trading → External ATS/exchanges (tZERO, INX) via partnerships ``` Key architecture characteristics: * **Compliance at the application layer** — smart contract overlay on ERC-20, not runtime-enforced. * **Admin override functions** — `forceTransfer()`, `freezePartialTokens()`, `recoveryAddress()` enable admin-initiated token movement without holder consent. * **Multi-chain via deployment** — same ERC-3643 deployed per chain, no cross-chain native enforcement. * **Centralized compliance decisions** — identity registry and compliance contract are admin-updateable. * **Single-asset-class focus** — institutional tokenization of fund products and treasuries; no module-aware extensions for real estate NAV enforcement or strategic-minerals federal-action coordination. #### 2.4 BlackRock BUIDL BlackRock USD Institutional Digital Liquidity Fund (BUIDL) is Securitize's flagship product: * Launched March 2024. * $2.5B+ AUM — largest tokenized real-world asset fund. * ERC-3643 on Ethereum. * 1 BUIDL = $1.00 (daily accrual of US Treasury yield). * Securitize Markets provides ATS trading. * NYSE MOU (March 24, 2026) for potential NYSE-listed access. #### 2.5 Key Securitize Partnerships | Partner | Relationship | Significance | | ----------------------------- | ----------------------------------------------------------- | --------------------------------------- | | **BlackRock** | BUIDL fund. Joseph Chalom on Securitize board. | Crown jewel — institutional credibility | | **Apollo** | Tokenized fund products | Alternative asset management | | **KKR** | Tokenized fund distribution | PE distribution | | **Hamilton Lane** | Tokenized private credit | Institutional private markets | | **NYSE** | MOU for NYSE-listed access to tokenized assets (March 2026) | Traditional exchange integration | | **Cantor Equity Partners II** | $1.25B SPAC merger | Public listing vehicle | *** ### 3. ERC-3643 vs. ST22 — Architecture Comparison The reference framework for this section is **SEC–CFTC Release No. 33-11412** (March 17, 2026, binding) together with the **January 28, 2026 Joint Staff Statement on Tokenized Securities**. The Seven Pillars of Category 1 Model B (Issuer-Sponsored Tokenization) are the test grid. ST22 satisfies all seven natively at the Solana runtime; ERC-3643 satisfies three natively and bolts on the rest at the application layer — which is exactly the Category 2 (Third-Party Sponsored) failure mode the SEC named. §3.1 walks the Seven-Pillar scorecard. §3.2 through §3.7 unpack the architectural and enforcement consequences. #### 3.1 Seven-Pillar Category 1 Model B Scorecard | # | Category 1 Model B Pillar | ERC-3643 (T-REX / Ethereum) | ST22 (SPL Token-2022 / Solana) | | - | ------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | **Direct Issuer Authorization** (board resolution authorizes mint) | ⚠️ **Off-chain only.** Tokeny-issued tokens commonly originate via a deployer wallet; board-resolution linkage lives in the legal stack, not the contract. | ✅ **On-chain.** Mint authority binds to the issuer's signed board resolution; Empire Stock Transfer onboarding gate refuses mint without filed Certificate of Designation. | | 2 | **Official Shareholder Register on DLT** | ❌ **Not native.** Token ledger is ERC-20 balances. Reconciliation to a Master Securityholder File is an off-chain process. | ✅ **Native.** Empire MSF is the legal register; the on-chain SPL Token-2022 ledger is the *transfer notification layer* per W\.S. 34-29-101 et seq. Ed25519 attestation reconciles the two every Solana slot (\~400 ms). | | 3 | **SEC §17A-Registered Qualified Custody** | ⚠️ **Possible but rare in deployments.** Most ERC-3643 stacks (Tokeny, Securitize, etc.) use crypto custodians (Fireblocks, BitGo, Anchorage) — not §17A-registered transfer agents. | ✅ **Architecturally required.** Empire Stock Transfer is the §17A custodian and the *sole* onboarding authority across all three modules. No mint exists without Empire holding the underlying equity 1:1 (Common Class B for M1, SAE equity for M2, BAE equity for M3). | | 4 | **True Equity Backing (1:1)** | ⚠️ **Off-chain attestation.** Backing is asserted in offering documents; verification is auditor-driven and periodic. | ✅ **Cryptographic, continuous.** Custody oracle publishes Ed25519-signed attestation each slot. Transfer Hook **CV-04** halts every transfer if oracle is stale or backing ratio ≠ 1.000. | | 5 | **Clear Ownership Chain / CUSIP** | ⚠️ **Off-chain mapping.** ONCHAINID is a wallet→identity map; CUSIP and DTC linkage are off-ledger. | ✅ **On-chain mapping.** Control **CV-05** rejects any transfer where the mint's bound asset identifier (CUSIP for M1; property ID for M2; basin ID for M3) fails to match the custodied class. | | 6 | **Investor Protection (compliance enforcement at every transfer)** | ⚠️ **Application-layer.** Compliance lives in `Compliance.sol` + `IdentityRegistry.sol` overlays. The underlying ERC-20 `transfer()` function still exists. **A direct EVM call to the bare ERC-20 method bypasses the overlay.** This is the ERC-3643 bypass risk documented widely (and acknowledged in the T-REX architecture papers). | ✅ **Runtime-enforced.** SPL Token-2022 mandates Transfer Hook invocation by the Token-2022 *program itself*. There is no `transfer()` path that skips the hook — the runtime will reject the instruction. **42 controls plus module-aware extensions execute atomically; failure = atomic revert.** | | 7 | **Token Standard Compliance (immutable, no admin override)** | ❌ **Upgradeable proxies + admin functions.** `forceTransfer()`, `freezePartialTokens()`, and proxy-upgrade authority give the issuer/operator unilateral power to move or seize holder tokens. | ✅ **Immutable post-deployment.** Once a Token-2022 mint is created with the Transfer Hook extension pointing at the platform's compliance program, the hook cannot be removed or repointed. No `forceTransfer` primitive. Regulatory freeze (Control 42) requires 3-of-5 multi-sig + Legal Counsel signoff and is bounded to halt-only — it cannot move tokens. | **Native score: ST22 = 7/7. ERC-3643 = 3/7** (Pillars 1, 3, and 5 *can* be satisfied with disciplined off-chain process; Pillars 2, 4, 6, 7 cannot be satisfied by the standard itself — they require external assertion). #### 3.2 Summary | Attribute | ERC-3643 (T-REX / Ethereum) | ST22 (CEDEX / Solana) | | ------------------------ | ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | | Market adoption | $32B+ tokenized assets, 8+ years | Emerging; Category 1 Model B pioneer | | Token standard | ERC-20 + compliance overlay contracts | SPL Token-2022 native Transfer Hooks | | Compliance enforcement | Application-layer (ONCHAINID + registries) | **Runtime-enforced** (42 controls in Solana runtime + module-aware extensions) | | Module-aware enforcement | Not supported | **Module 2 NAV-deviation enforcement; Module 3 federal-action freeze coordination — runtime-enforced** | | Bypass risk | **Yes** — direct EVM `transfer()` bypasses overlay | **No** — hooks execute on every path | | Admin override | **Yes** — `forceTransfer()`, `freezePartialTokens()` | **No** — Groovy Company cannot move tokens without holder consent | | Transaction speed | 12–15s (L1), seconds (L2) | \~400ms finality | | Transaction cost | $1–$50+ (L1), \~$0.01 (L2) | \~$0.00025 | | Liquidity model | External DEX/ATS, issuer-deployed pools | Global Pool — protocol-owned, permanently locked, shared across all three modules | | Regulatory posture | EU MiCA compatible, SEC varying | SEC Category 1 Model B, Release No. 33-11412; Reg D + Reg S + Reg CF | | Holding-period regimes | Smart contract + admin enforcement | On-chain Control HP-24 — Reg D / Reg S / Reg CF immutable timers | | Upgrade path | Upgradeable proxy contracts | **Immutable** Transfer Hook controls; module-aware extensions cannot be removed (Certora E.4) | | Multi-chain | Native EVM + L2 deployments | Solana primary; cross-chain roadmap | | Formal verification | Varies by deployment | Certora Prover — 6 invariants covering all three modules | #### 3.3 ERC-3643 Five-Component Architecture | Component | Function | Vulnerability | | ---------------------------- | ---------------------------------- | --------------------------------------------------------------------- | | **T-REX Token** | ERC-20 + compliance hooks | Compliance hooks are application-layer — direct `transfer()` bypasses | | **ONCHAINID** | ERC-734/735 decentralized identity | Off-chain dependency for claim verification | | **Identity Registry** | Maps wallets to identities | Admin-updateable — registry manipulation risk | | **Compliance Contract** | Enforces transfer rules | Admin-upgradeable via proxy — compliance logic can change | | **Trusted Issuers Registry** | Validates identity claim issuers | Admin-updateable — issuer list can be modified | #### 3.4 ST22 Enforcement Architecture | Component | Function | Security Property | | ----------------------------------- | ----------------------------------------------------------- | ------------------------------------------------- | | **Transfer Hook** | 42 controls plus module-aware extensions on every transfer | Runtime-enforced — no bypass path exists | | **SecurityConfig** | Per-mint parameters; module-aware extension fields | PDA — deterministic, on-chain | | **CustodyOracle** | Ed25519 Empire attestation per block | Cryptographic — signature required | | **NAVOracle (Module 2)** | Per-mint NAV with deviation tolerance enforcement | Ed25519 signed by authorized appraiser | | **ClassificationOracle (Module 3)** | USGS / DOE / federal-action status | Ed25519 signed by authorized Classification relay | | **HoldingPeriodAccount** | Per-investor holding lock across Reg D / Reg S / Reg CF | On-chain timer — cannot be shortened | | **Global Pool** | Protocol-owned liquidity, single shared pool across modules | **Immutable** — no withdrawal function | #### 3.5 The Bypass Problem — Pillar 6, Concretely This is the architectural distinction the SEC Crypto Task Force is most attuned to, and the one that determines whether a tokenization stack maps natively to Category 1 or to Category 2. **ERC-3643 enforcement model:** ``` User → T-REX Token contract → calls Compliance + IdentityRegistry → conditional transfer ↑ BUT: ERC-20.transfer() inherited from OpenZeppelin still exists. A caller with token-balance access can invoke transfer() directly, bypassing the Compliance contract entirely. ``` ERC-3643 mitigates this by overriding `transfer()` to revert without compliance approval — but the override is *contract code*, and any upgrade to the proxy or any deployment that forgets the override re-opens the path. Tokeny's own audits (Hacken, Kaspersky) flag this as a governance / code-quality risk rather than an architectural guarantee. **ST22 enforcement model:** ``` User → Solana Token-2022 program → REQUIRED CPI to Transfer Hook → 42 controls + module-aware extensions → conditional transfer ↑ The Token-2022 program is part of the Solana runtime. It refuses to process a transfer instruction on a hook-extended mint without invoking the registered hook program. There is no bypass instruction. ``` The hook invocation is enforced by the Solana runtime itself, not by application code that could be overridden. **It is closer in nature to an OS system call than to a smart-contract function.** This is what allows Pillar 6 ("compliance on every transfer, no exceptions") to be a *property of the protocol* rather than a *property of the developer's discipline*. The same pseudocode comparison written more directly: ``` ERC-3643 (Ethereum): wallet.call(token.transfer(to, amount)) → IF called through T-REX contract: compliance checked ✓ → IF called through direct EVM transfer(): compliance BYPASSED ✗ → The compliance layer is an overlay — not the token itself ST22 (Solana): wallet.call(spl_token_2022.transfer(to, amount)) → Token-2022 program AUTOMATICALLY invokes Transfer Hook via CPI → Transfer Hook executes ALL 42 controls + applicable module-aware extensions → NO BYPASS PATH — hook is part of the token standard → The compliance layer IS the token standard ``` #### 3.6 The Admin Override Problem — Pillar 7, Concretely The SEC Joint Staff Statement (January 28, 2026) explicitly warns that **Category 2 (Third-Party Sponsored)** tokenization carries counterparty risk because the operator can move or freeze holder property. ERC-3643 reproduces this risk *inside* a Category 1 wrapper. | Function | ERC-3643 (T-REX) | ST22 | | ----------------------------------------------- | --------------------------------------------------- | -------------------------------------------------------------------------------- | | Force-transfer holder tokens | `forceTransfer(from, to, amount)` — **exists** | **Does not exist.** No instruction in the program. | | Freeze partial balance | `freezePartialTokens(account, amount)` — **exists** | Halt-only via Control 42; cannot move tokens. | | Upgrade compliance logic without holder consent | Yes — proxy upgrade by admin | No — Transfer Hook program ID is bound to mint at creation; cannot be repointed. | | Mint additional tokens | Subject to `mintAuthority`, often a hot wallet | Mint authority requires Empire co-signature plus the platform 3-of-5 multi-sig | | Redirect to recovery address | `recoveryAddress()` — **exists** | **Does not exist** — no recovery address mechanism | | Modify who is verified | `updateIdentityRegistry()` — **exists** | Empire verification is external — not modifiable by Groovy Company | **Practical example.** In June 2024 Tokeny published a feature article describing how `forceTransfer` was used by an issuer to "recover" tokens from a hacked investor wallet. From a compliance-architecture standpoint, that capability is the *exact attribute* Release No. 33-11412 names as creating Category 2 counterparty risk: the operator demonstrably can move tokens without the holder's signature. Whether or not the use case is benign is irrelevant — the *capability exists*, and its existence triggers the regulatory characterization. ST22 cannot do this because the instruction is not in the compliance program. The investor's wallet signature is the *only* path to debit the token account. #### 3.7 Module-Aware Extensions ERC-3643 Cannot Replicate The platform's module-aware extensions create an additional layer of architectural differentiation that ERC-3643 cannot easily replicate without abandoning its application-layer compliance model. | Extension | Module | What It Enforces | Why ERC-3643 Cannot Match Natively | | -------------------------------------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **NAV-deviation enforcement (CB-21 NAV variant)** | Module 2 | Trade rejected if on-chain price exceeds NAV by configured tolerance (default 22%) or if NAV oracle stale beyond reappraisal cadence | NAV oracle reads + deviation math at every transfer would be cost-prohibitive on Ethereum L1; ERC-3643 has no native NAV-bound enforcement primitive | | **Federal-action freeze (REG-42 federal variant)** | Module 3 | Automatic 60-minute SLA freeze on detection of Section 232 / DPA Title III / EO-driven federal action affecting basin asset | ERC-3643 has no native federal-action coordination; admin-driven freezes via `freezePartialTokens` lack the SLA, the per-mint isolation, or the automatic resumption when action lifts | | **Per-module holding regimes** | All | Reg D (6mo) / Reg S (12mo) / Reg CF (12mo) enforced per-investor on-chain via HoldingPeriodAccount | ERC-3643 deployments typically enforce one regime per mint; multi-regime per-mint enforcement requires significant overlay-contract complexity | | **Tripartite concurrence governance** | Module 2 | Per-mint NAV bounds and reappraisal cadence require concurrence among SAE issuer + appraiser + Empire Stock Transfer | ERC-3643 governance is admin-controlled, not multi-party-concurrence-enforced at the protocol layer | #### 3.8 Where ERC-3643 Actually Wins on Category Fit To be fair, ERC-3643 has two real advantages relevant to the Release No. 33-11412 framework: 1. **ONCHAINID portability (ERC-734 / 735).** Verifiable credentials follow the investor across issuers without re-KYC. ST22 currently re-onboards through Empire per issuer (acceptable for §17A but operationally heavier). 2. **MiCA compatibility.** ERC-3643 is purpose-built for the EU framework; the SEC framework is closer to MiCA than to Howey, and the institutional vocabulary (BlackRock, Hamilton Lane, Société Générale deployments) is already aligned. Neither overcomes the Pillar 6 / Pillar 7 architectural gap, but both matter for cross-border and institutional positioning — which is why the cross-chain roadmap evaluates an ERC-3643 wrapper for ST22 representation on EVM, not the reverse. #### 3.9 Bottom Line ERC-3643 is a **compliance-by-convention** standard: the rules are in contracts the issuer chooses to deploy and chooses not to override. ST22 is a **compliance-by-runtime** standard: the rules are in the chain itself, and there is no path that does not execute them. Under Release No. 33-11412 the distinction is binary — either the DLT *is* the official register (Category 1 Model B), or the DLT *mirrors* an off-chain register (Category 2). 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.** #### 3.10 Authoritative References * SEC–CFTC **Release No. 33-11412** (March 17, 2026) — binding Five-Category Taxonomy; defines Category 1 Model B. * **SEC Joint Staff Statement on Tokenized Securities** (January 28, 2026) — Category 1 vs. Category 2 distinction. * **SEC Staff Statement on Covered User Interface Providers** (April 13, 2026) — runtime-enforcement weight in compliance. * **Solana SPL Token-2022 specification** + `spl-transfer-hook-interface` v0.6+ — runtime-level hook semantics. * **ERC-3643 Specification** (EIP-3643, Final, December 2023) + Tokeny T-REX whitepaper — five-component application-layer architecture. * **Wyoming Digital Asset Statute** (W\.S. 34-29-101 et seq.) — DLT as legally effective transfer notification. * **SEC v. Telegram**, 448 F. Supp. 3d 352 (S.D.N.Y. 2020) — "compliance dependent on issuer good faith" as enforcement risk. *** ### 4. Broader Competitor Landscape #### 4.1 Tokenized Securities Platforms — Equities | Platform | Token Standard | Chain | Focus | Registrations | Differentiator | | ---------------- | --------------------- | ----------------- | -------------------------------------------------- | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | | **Securitize** | ERC-3643 | Ethereum + multi | Institutional RWA | Transfer agent, BD, ATS, MiCA | BlackRock BUIDL, institutional relationships | | **tZERO** | Proprietary | Ethereum | ATS trading | BD, ATS | Early STO platform, Overstock backing | | **Polymath** | ERC-1400 | Ethereum | Token creation | — | Polymesh (dedicated chain, now pivoting) | | **Tokeny** | ERC-3643 | Ethereum | Enterprise tokenization | EU-focused | ERC-3643 standard creators | | **INX** | Proprietary | Ethereum | Regulated exchange | BD, ATS | SEC-registered token offering | | **Republic** | Varies | Multi | Retail investment | BD, crowdfunding | Retail access, Reg CF / A+ | | **Dinari (DFN)** | Proprietary | Multi-chain | NYSE / NASDAQ large-cap (Cat-2) | — | **Complementary positioning** — large-cap focus distinct from platform's three-module Cat-1 scope | | **Ondo Finance** | Proprietary | Ethereum + Solana | Tokenized treasuries | — | USDY, treasury yield on-chain | | **Centrifuge** | Proprietary | Ethereum + Base | Real-world credit | — | Tinlake protocol, MakerDAO integration | | **RWA Tokens** | **ST22 (Token-2022)** | **Solana** | **Equities (M1) + Real Estate (M2) + CORECM (M3)** | **Empire §17A custody; FINRA-registered funding portal partnership for Reg CF** | **42 immutable controls + module-aware extensions, Global Pool, Category 1 Model B** | #### 4.2 Real Estate Tokenization — Module 2 Context | Platform | Approach | Module 2 Comparison | | --------------------------- | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------ | | **RealT** | Fractionalized rental property tokens (Ethereum) | No NAV oracle; no deviation tolerance enforcement at the token layer; no SAE-equity custody at a §17A-registered transfer agent | | **Lofty** | Real estate tokens (Algorand) | No multi-regime holding period; no shared-pool liquidity model; no SEC Category 1 framing | | **Roofstock onChain** | Whole-property NFTs | Different model entirely — single-property NFTs vs SAE-equity tokenization with secondary market | | **Tangany / Ondo / others** | Various pilots | No platform integrates Module 2 NAV-deviation enforcement, Reg D / Reg S / Reg CF per-investor regimes, and a shared cross-module liquidity pool | #### 4.3 Critical Minerals / CORECM — Module 3 Context No competitor offers a public-chain platform for tokenizing US strategic-minerals supply chain assets with on-chain federal-action coordination. The intersection of (a) Solana SPL Token-2022 runtime enforcement, (b) ClassificationOracle integration with USGS / DOE / Federal Register, and (c) automatic Control 42 federal-action freeze with 60-minute SLA is unique. Module 3 represents true blue-ocean positioning. #### 4.4 Why None Address the Platform's Three-Module Surface | Competitor | Why They Cannot Cover the Platform's Surface | | --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Securitize | Gas economics ($1–$50+/tx). Minimum AUM too high. No permanent liquidity. No NAV-deviation enforcement (Module 2). No federal-action coordination (Module 3). | | tZERO | Limited to ATS-listed tokens. No self-reinforcing liquidity pool. Low volume. Single asset class. | | Polymath | Pivoted to Polymesh chain. No permanent liquidity solution. Limited traction. Single asset class. | | Tokeny | Enterprise-focused, EU regulatory alignment. No US regulatory infrastructure. Single asset class. | | INX | Small ATS. No permanent liquidity. Limited issuer onboarding infrastructure. Single asset class. | | Dinari (DFN) | Large-cap focus (Cat-2), complementary to platform's Cat-1 three-module scope; partnership candidate, not direct competitor | | Ondo | Treasury yield products only. Not equity tokenization. Not real estate. Not strategic minerals. | | Centrifuge | Credit / lending products. Not equity tokenization. Not real estate. Not strategic minerals. | | RealT / Lofty / Roofstock onChain | Real estate only, no §17A custody integration, no deviation tolerance enforcement, no shared-pool liquidity, no other modules | *** ### 5. SWOT Analysis #### 5.1 RWA Tokens Platform | Category | Detail | | ------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **S — Runtime enforcement** | Transfer Hook executes inside Solana runtime — no application-layer bypass | | **S — 42 immutable controls + module-aware extensions** | Cannot be weakened by upgrade, governance, or admin action; Certora E.4 protects module-aware extensions | | **S — Three-module architecture** | Equities, Real Estate, and CORECM served through one architecture with shared liquidity, shared compliance, and module-aware enforcement | | **S — Module 2 NAV enforcement** | Real estate tokenization with on-chain NAV-deviation tolerance enforcement — no other platform offers this | | **S — Module 3 federal-action coordination** | Strategic-minerals tokenization with automatic federal-action freeze and 60-minute SLA — no other platform offers this | | **S — Transaction economics** | \~$0.00025/tx enables per-transfer compliance for any market cap, any module | | **S — \~400ms finality** | Real-time settlement + per-block custody attestation | | **S — Integrated exchange** | CEDEX = standard + exchange + permanent liquidity in one architecture | | **S — Permanent liquidity** | LP tokens burned — withdrawal mathematically impossible; single shared pool serves all three modules | | **S — Category 1 Model B** | Built for Release No. 33-11412 compliance from inception across all three modules | | **S — Empire custody** | SEC §17A-registered, Ed25519 attestation every \~400ms; covers Common Class B (M1), SAE equity (M2), BAE equity (M3) | | **S — Reg D / Reg S / Reg CF triple coverage** | All three offering exemptions natively supported with per-investor on-chain enforcement | | **W — Newer standard** | Less institutional track record than ERC-3643's 8+ years and $32B+ | | **W — Solana-only initially** | Cross-chain requires Phase 2+ roadmap execution | | **W — DEX incompatibility** | Raydium / Orca / Jupiter don't support Transfer Hooks — requires CEDEX | | **W — Single exchange** | All secondary trading routes through CEDEX until multi-venue expansion | | **W — Module 2 / Module 3 launch posture** | Modules 2 and 3 are launch-phase; institutional track record will accumulate post-launch | | **O — Multi-module addressable market** | Equities (microcap and global exchanges) + real estate ($280T+ global market) + critical minerals (US strategic priority under EO 14017, IRA, Energy Act of 2020) | | **O — SEC regulatory clarity** | Release No. 33-11412 provides binding federal framework | | **O — Federal critical-minerals priority** | Module 3 aligns with Section 232, DPA Title III, IRA, EO 14017 — US strategic-policy tailwind | | **O — Foreign exchange equity expansion** | Global equity tokenization across NASDAQ, AMEX, TSX, and foreign exchanges within Module 1 | | **O — White-label infrastructure** | Institutions needing compliant tokenization infrastructure across multiple asset classes | | **O — Dinari partnership** | Complementary asset-class coverage (large-cap Cat-2) creates joint regulatory positioning opportunity | | **T — ERC-3643 institutional dominance** | Institutional investors and custodians know ERC-3643 — ST22 requires education | | **T — Solana network risk** | Historical outages (pre-2023) remain a reputation factor | | **T — Securitize partnerships** | BlackRock / Apollo / KKR relationships create institutional gravity | | **T — Regulatory change** | SEC policy change could affect Category 1 framework | #### 5.2 Securitize | Category | Detail | | -------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | **S — Institutional relationships** | BlackRock, Apollo, KKR, Hamilton Lane — unmatched institutional credibility | | **S — Regulatory registrations** | Transfer agent, broker-dealer, ATS, EU MiCA — broadest coverage | | **S — Market adoption** | $4B+ tokenized, $2.5B BUIDL, $1.25B SPAC valuation | | **S — Multi-chain** | Ethereum + Solana + Polygon + Arbitrum + Avalanche + others | | **S — ERC-3643 standard** | $32B+ deployed, 8+ years, EIP Final status | | **W — Application-layer compliance** | Bypassable via direct EVM transfer — structural vulnerability | | **W — Admin overrides** | `forceTransfer()` creates centralization risk | | **W — Gas costs** | $1–$50+ on Ethereum L1 — prohibitive for mid-market | | **W — No permanent liquidity** | Securitize Markets ATS has limited secondary volume | | **W — Trading suspension history** | Platform-controlled trading halts expose investors to centralized risk | | **W — Single asset-class focus** | Institutional fund and treasury products; no native real estate NAV enforcement, no native critical-minerals federal-action coordination | | **O — NYSE MOU** | Traditional exchange access for tokenized assets | | **O — EU expansion** | MiCA license opens European institutional market | | **T — Category 2 classification risk** | SEC may classify middleware-on-public-chains as Category 2 (counterparty risk) | | **T — Competing L1s** | Non-EVM chains (Solana, Aptos) threaten Ethereum lock-in | | **T — Module-aware platforms** | Multi-asset-class platforms with native module-aware enforcement (NAV, federal-action) raise the architectural bar | *** ### 6. Use Case Fit Matrix | Use Case | ERC-3643 (Securitize) | ST22 (RWA Tokens) | Winner | | ------------------------------------------------------------------- | -------------------------------------------------- | ------------------------------------------------------------------------------------ | ---------------------- | | BlackRock-scale institutional fund ($1B+) | Established, proven, regulatory comfort | No institutional track record yet | **ERC-3643** | | Tokenized US Treasury yield | BUIDL ($2.5B), mature | Not applicable (equity / real estate / minerals, not treasuries) | **ERC-3643** | | EU-regulated tokenization (MiCA) | Licensed and operational | No EU presence | **ERC-3643** | | **Equity tokenization — OTC microcap to global exchange** | Economically unviable below \~$10M cap | **Purpose-built** — Module 1; Global Pool; $0.00025/tx | **ST22** | | **Real estate tokenization with NAV-deviation enforcement** | No native NAV-bound enforcement; admin-driven only | **Purpose-built** — Module 2 NAV oracle + 22% deviation tolerance | **ST22** | | **Critical-minerals tokenization with federal-action coordination** | No equivalent capability | **Purpose-built** — Module 3 Classification oracle + 60-minute federal-action freeze | **ST22 (uncontested)** | | 24/7 secondary trading with permanent liquidity | ATS with limited hours and volume | CEDEX 24/7, LP burned, protocol-owned, shared across modules | **ST22** | | Anti-rugpull guarantee | Admin overrides exist | Mathematically impossible — no withdrawal function | **ST22** | | Per-transfer compliance verification | Gas cost prohibitive at L1 | $0.00025 per verified transfer across all three modules | **ST22** | | Real-time custody attestation | Periodic (not per-block) | Ed25519 every \~400ms, cross-module | **ST22** | | Multi-regime per-investor holding period (Reg D + Reg S + Reg CF) | Typically one regime per mint | Native per-investor regime via HoldingPeriodAccount | **ST22** | | Cross-chain institutional custody (Fireblocks / BitGo) | Mature EVM integration | Solana custody emerging | **ERC-3643** | | Foreign-exchange equity tokenization (NASDAQ, AMEX, TSX, global) | Limited; EU MiCA covers some | Module 1 covers all global exchanges | **ST22** | *** ### 7. Transaction Economics | Metric | ERC-3643 (Ethereum L1) | ERC-3643 (L2) | ST22 (Solana) | Advantage | | --------------------------------------------------- | ----------------------------- | ---------------------------- | ------------------------------------------------------------------------ | ------------------------------- | | Base transfer fee | $1–$50+ | \~$0.01 | **\~$0.00025** | ST22: 4,000× – 200,000× cheaper | | Compliance verification cost | $5–$50 (gas for oracle reads) | \~$0.05 | **\~$0.001** | ST22: 50× – 50,000× cheaper | | Settlement finality | 12–15 seconds | 2–15 seconds | **\~400ms** | ST22: 30× – 37× faster | | Throughput | \~15 TPS | 100–4,000 TPS | **400–600 TPS** (compliance-verified) | Comparable to L2 | | Custody attestation frequency | Periodic (minutes – hours) | Same as L1 (separate chain) | **Every block (\~400ms)** | ST22: real-time | | Module-specific oracle reads (NAV / Classification) | Cost-prohibitive at L1 | Possible at L2 with overhead | **Native — included in CU budget** | ST22: structurally enabled | | Platform fee (secondary) | 0.5–2% (ATS dependent) | Same | **5%** (includes 42 controls + module-aware extensions + permanent pool) | — | #### Economic Viability by Market Cap and Module | Issuer Profile | ERC-3643 Viable? | ST22 Viable? | | ----------------------------------------------- | ------------------------------------ | -------------------------------- | | $1B+ institutional fund | Yes — gas is rounding error | Yes | | $100M – $1B equity issuer | Marginal — gas meaningful | Yes | | $10M – $100M equity issuer | Difficult — gas erodes returns | **Yes (Module 1)** | | $1M – $10M microcap issuer | **Not viable** | **Yes (Module 1)** | | <$1M issuer | **Not viable** | **Yes (Module 1)** | | Single-asset real estate entity (per-property) | **Not viable** at L1 | **Yes (Module 2)** | | Basin-asset entity with federal-action exposure | **No federal-action infrastructure** | **Yes (Module 3) — uncontested** | The platform's transaction economics make per-transfer compliance verification viable across the entire three-module addressable surface. This is the fundamental economic argument for why the platform's market cannot be served by Ethereum-based platforms at scale. *** ### 8. Regulatory Positioning #### 8.1 SEC Framework Comparison | Framework Element | Securitize | RWA Tokens | | --------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Primary SEC engagement | Crypto Task Force submission (Oct 2025) | Crypto Task Force direct meetings + no-action letter | | Classification | Varies by product | Category 5 Digital Securities (Release No. 33-11412) | | Category 1 vs Category 2 | Could be classified Category 2 (middleware on public chains) | **Category 1 Model B** (issuer-sponsored, DLT in official records) — applies across all three modules | | Compliance enforcement | Application-layer (admin-controllable) | Runtime-enforced (42 immutable controls + module-aware extensions) | | Custody | Own transfer agent registration | Empire Stock Transfer — §17A qualified custodian; covers Common Class B (M1), SAE equity (M2), BAE equity (M3) | | Admin override | `forceTransfer()` exists | No admin override — mathematical enforcement | | Holding period | Smart contract + admin enforcement; typically single regime | On-chain Control HP-24 — Reg D / Reg S / Reg CF immutable timers | | Regulatory freeze | Admin function | Control 42 — Legal Counsel + 3-of-5 multi-sig; **Module 3: automatic federal-action variant with 60-minute SLA** | | Module 3 federal frameworks | Not addressed | USGS Critical Minerals List, DOE Critical Materials Strategy, Section 232, DPA Title III, IRA, EO 14017, Energy Act of 2020 — all surfaced through Classification oracle | #### 8.2 Category 1 vs Category 2 Risk The January 28, 2026 Joint Staff Statement distinguishes: | Dimension | Category 1 (RWA Tokens) | Category 2 Risk (Securitize potential) | | ----------------------- | ----------------------------------------------------------- | -------------------------------------- | | Issuer relationship | Direct — board resolution required | Third-party sponsored (middleware) | | Counterparty risk | None — direct ownership via Empire across all three modules | Platform intermediary holds tokens | | Compliance control | Issuer cannot bypass | Admin override functions exist | | DLT in official records | Empire MSF + Solana blockchain | Public chain + off-chain registry | Securitize's admin override functions (`forceTransfer()`) could expose it to Category 2 classification risk — where a platform intermediary maintains control over investor tokens. The platform's architecture eliminates this risk by making admin overrides structurally impossible across all three modules. *** ### 9. Liquidity Model Comparison | Attribute | Securitize (ATS) | RWA Tokens (CEDEX) | | ----------------------------- | ---------------------------------------- | ---------------------------------------------------------------------------------------- | | **Venue type** | Alternative Trading System | Custom AMM + Compliant Exchange | | **Trading hours** | Limited (ATS-dependent) | **24/7/365** | | **Liquidity source** | Market makers (can withdraw) | **Global Pool — LP burned, protocol-owned** | | **Cross-asset-class pooling** | Per-product, isolated | **Single pool serves all three modules — Equities, Real Estate, CORECM** | | **Rugpull risk** | Market maker withdrawal possible | **Mathematically impossible** | | **Per-issuer dependency** | Each issuer needs dedicated market maker | **Shared pool — no per-issuer market maker needed across modules** | | **Market maker cost** | $5K – $20K/month | **$0** | | **Liquidity growth** | Depends on market maker commitment | **Self-reinforcing — 0.44% of every trade across all modules deepens pool** | | **Network effect** | Limited — each issuer isolated | **Strong — more issuers across more modules → deeper pool → better prices for everyone** | | **Formal verification** | N/A | Certora E.3 — pool non-extractability proved | *** ### 10. Where Securitize Wins | Advantage | Detail | Platform Counter-Strategy | | ------------------------------- | ---------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Institutional relationships** | BlackRock, Apollo, KKR, Hamilton Lane on platform | The platform targets different market segments (Module 1 microcap, Module 2 real estate, Module 3 critical minerals) — not competing for the same institutional fund clients. | | **Regulatory registrations** | Transfer agent, BD, ATS, EU MiCA — broadest regulatory footprint | Empire Stock Transfer §17A covers custody and onboarding across all three modules. No-action letter for CEDEX pending. FINRA-registered funding portal partnership for Reg CF. | | **Market adoption** | $4B+ tokenized, $1.25B valuation | The platform is launch-phase. Multi-module addressable market thesis offsets this through addressable surface size. | | **Multi-chain** | 8+ chains deployed | Solana-only initially. Cross-chain roadmap Phase 2 (Wormhole NTT, Dinari DFN partnership candidate). | | **ERC-3643 standard adoption** | $32B+ tokenized, 8+ years, EIP Final | ST22 is newer but architecturally superior (runtime enforcement, module-aware extensions). Market education required. | | **EU presence** | MiCA license, European institutional clients | No EU presence. Phase 3 expansion target. | *** ### 11. Where the Platform Wins | Advantage | Detail | Securitize Weakness | | ---------------------------------------- | --------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | | **Infrastructure independence** | Alesia Doctrine — eliminates third-party failure vectors | Securitize depends on EVM infrastructure, admin controls, external market makers | | **Mathematical security** | 42 Transfer Hook controls plus module-aware extensions, immutable, runtime-enforced | ERC-3643 compliance bypassable via direct EVM call. Admin overrides exist. | | **Three-module architecture** | Equities, Real Estate, CORECM served through one architecture | Single-asset-class focus; no native real estate NAV enforcement, no critical-minerals federal-action coordination | | **Permanent liquidity** | Global Pool, LP burned, Certora-verified non-extractability, single shared pool across modules | Market makers can withdraw. ATS liquidity is fragile. Per-product isolation. | | **Multi-module addressable surface** | Equities ($50B+ at microcap end alone), Real Estate ($280T+ global), CORECM (US strategic priority) | Securitize's institutional focus does not extend to per-property real estate or basin-asset critical minerals | | **Transaction economics** | \~$0.00025 per verified transfer | $1–$50+ per transfer on Ethereum L1 | | **Real-time custody** | Ed25519 attestation every \~400ms across all three modules | Periodic custody verification | | **Module 2 NAV enforcement** | On-chain NAV-deviation tolerance + tripartite-concurrence governance | Not offered | | **Module 3 federal-action coordination** | Automatic Control 42 federal-action freeze with 60-minute SLA | Not offered | | **Reg D / Reg S / Reg CF triple** | All three offering exemptions natively supported, per-investor on-chain enforcement | Typically single regime per mint | | **Category 1 Model B** | Release No. 33-11412 binding federal framework across all three modules | Category 2 classification risk from admin overrides | | **No admin override** | Groovy Company cannot move tokens without holder consent | `forceTransfer()` creates centralized risk | | **Formal verification** | 6 Certora invariants; E.4 covers module-aware extensions | Varies by ERC-3643 deployment, not standardized | *** ### 12. Strategic Positioning #### 12.1 Different Markets, Different Architectures Securitize and the RWA Tokens platform do not compete for the same clients. Securitize's institutional DNA makes it ideal for BlackRock-scale clients who need regulatory comfort and accept centralized admin control. The platform's mathematical security, permanent liquidity, and three-module architecture make it ideal for the vast underserved markets where traditional finance infrastructure has no presence — equities at the microcap and global-exchange end (Module 1), real estate at the per-property scale with on-chain NAV enforcement (Module 2), and strategic-minerals supply chain with on-chain federal-action coordination (Module 3). ``` MARKET POSITIONING Premium Institutional Multi-Module Underserved Surface (BlackRock, KKR, Apollo) (Equities + Real Estate + CORECM) ▲ ▲ │ │ SECURITIZE RWA TOKENS ERC-3643 / Ethereum ST22 / Solana $4B+ tokenized Multi-module addressable surface Single asset class M1 + M2 + M3 Admin overrides Mathematical security ATS liquidity (fragile) Global Pool (permanent, shared) $1–$50+ per tx $0.00025 per tx ``` #### 12.2 Long-Term Trajectory The competitive threat to Securitize is not the platform taking its institutional clients. The threat is the platform demonstrating that a better architectural model exists — and that the model extends across multiple asset classes. When ST22 architecture processes significant daily volume across Modules 1, 2, and 3 with zero admin overrides, real-time custody attestation, on-chain NAV enforcement (Module 2), and on-chain federal-action coordination (Module 3) — Securitize's middleware-on-Ethereum model will face increasing architectural scrutiny from regulators and institutional evaluators. Module-aware enforcement raises the architectural bar for the entire industry. #### 12.3 Convergence Risk If Securitize adds runtime-enforced compliance (through Solana Token-2022 deployment or an Ethereum protocol-level upgrade), the architectural differentiation narrows for Module 1 equity tokenization. However, this would require Securitize to abandon `forceTransfer()` and other admin override functions — a change that would fundamentally alter its institutional operating model. Module 2 NAV-deviation enforcement and Module 3 federal-action coordination would remain platform-unique even after a hypothetical Securitize architectural pivot, because those extensions reflect deliberate per-module design choices rather than general primitives. #### 12.4 Complementary Positioning — Dinari (DFN) Dinari (DFN) operates in the large-cap NYSE / NASDAQ Cat-2 tokenization space — explicitly different from the platform's Cat-1 three-module scope. Rather than direct competition, Dinari represents a partnership candidate for cross-chain ST22 distribution (DFN cross-chain capabilities), joint SEC regulatory positioning (Cat-1 + Cat-2 architectural diversity), and complementary asset-class coverage. Strategic-investment outreach is in progress. #### 12.5 Competitive Moats | Moat | Durability | Defensibility | | ----------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | | **Empire Stock Transfer integration** | High — §17A-registered; Patrick Mokros is COO of Groovy Company, Inc. and Founder of Empire Stock Transfer | Regulatory relationship not easily replicated; covers all three modules | | **Global Unified CEDEX Liquidity Pool** | Permanent — LP burned, immutable program, single shared pool across modules | Cannot be drained. Mathematical guarantee. Cross-module network effect. | | **42 immutable Transfer Hook controls + module-aware extensions** | Permanent — runtime-enforced, formally verified, Certora E.4 protects extensions | Cannot be weakened. Architectural guarantee. | | **Module 2 NAV-deviation enforcement** | Permanent — on-chain NAV oracle + tolerance tied to immutable Control CB-21 NAV variant | Requires new architectural primitives ERC-3643 cannot replicate at L1 economics | | **Module 3 federal-action coordination** | Permanent — on-chain Classification oracle + automatic Control 42 federal-action freeze | Uncontested capability; no other platform offers this | | **First Category 1 Model B platform across three modules** | High — regulatory first-mover | SEC Crypto Task Force engagement, no-action letter | | **Cross-module network effect** | Growing — more issuers across more modules → deeper shared pool | Self-reinforcing once critical mass reached | | **Reg D / Reg S / Reg CF triple coverage** | High — FINRA-registered funding portal partnership for Reg CF | Multi-regime per-investor on-chain enforcement is architecturally distinct | | **Transaction economics** | Structural — Solana's cost advantage | Ethereum cannot match \~$0.00025/tx without fundamental protocol changes | *** ### Related Documentation * **Architecture Decisions** — ADR-001 (Solana over Ethereum), ADR-002 (Custom AMM), module-aware ADRs. * **Security Model** — Formal verification and threat model; module-aware threat surfaces. * **Smart Contract Reference** — Module-aware program behavior with full PDA registry. * **Transfer Hook Reference** — Standalone reference for the 42 controls and module-aware extensions. * **Compliance Integration Guide** — Regulatory framework details across Reg D / Reg S / Reg CF. * **Oracle Integration Guide** — Custody, OFAC, AML, TWAP, EDGAR (M1), NAV (M2), Classification (M3) relay architecture. * **Governance Deep Dive** — Module-aware governance surface, tripartite concurrence pattern, Control 42 federal-action variant. * **Glossary** — Authoritative terminology reference with module-aware annotations. *** *RWA Tokens · Competitive Analysis · Groovy Company, Inc.* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://bitbook.rwatokens.net/reference/reference/competitive-analysis.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.