> 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/whitepaper-v10/tokenomics.md).

# Tokenomics

## SECTION 13 — Tokenomics

**RWA Tokens Platform Whitepaper · V10.0 · May 2026** **Issued by:** Groovy Company, Inc. (Wyoming corporation; OTC: GROO; SEC EDGAR CIK 1499275) **Section classification:** Technical Specification — Economic Architecture **Authority:** SEC–CFTC Release No. 33-11412; GENIUS Act; Wyoming W\.S. 34-29-101

***

### 13.1 Scope

This section documents the complete economic architecture of the RWA Tokens platform — the three-token classification (GROO Utility Token, Groovy Security Token (STO), and ST22 Digital Securities), the unified 5% fee structure applied to all ST22 transactions across all three modules, the immutable 0.44% lock that permanently funds the Global Unified Liquidity Pool, the staking architecture for the Groovy Security Token, the GROO bonding curve distribution mechanics, the five-year platform revenue model, and the module-aware economic considerations for Module 2 (NAV-bound) and Module 3 (federal-action-bound) issuances.

All allocations described in this section are enforced in Solana program logic (the `transfer_hook`, `amm`, `liquidity_pool`, and staking programs) and cannot be altered by governance vote, administrative function, or any other mechanism — except parameter ranges explicitly defined as governance-modifiable in Section 17.

### 13.2 Three-Token Architecture

The platform involves three distinct token classes with distinct legal classifications, distinct economic roles, and distinct regulatory frameworks. They are **not** interchangeable. Conflating them is the single largest risk in platform discourse.

#### 13.2.1 Token Comparison Table

| Attribute                               | GROO Utility Token                                                               | Groovy Security Token (STO)               | ST22 Digital Security                                     |
| --------------------------------------- | -------------------------------------------------------------------------------- | ----------------------------------------- | --------------------------------------------------------- |
| **Issuer**                              | Platform ecosystem                                                               | Groovy Company, Inc.                      | Third-party issuer (per module)                           |
| **Release No. 33-11412 classification** | Category 1 (Digital Commodity) or Category 3 (Digital Tool) — **not a security** | Category 5 (Digital Security)             | Category 5 (Digital Security)                             |
| **Backing**                             | None                                                                             | Common Class B of Groovy Company, Inc.    | M1: issuer Common Class B; M2: SAE equity; M3: BAE equity |
| **Custody**                             | None required                                                                    | Empire Stock Transfer 1:1                 | Empire Stock Transfer 1:1                                 |
| **Distribution**                        | Deterministic linear bonding curve                                               | $20M Reg D raise                          | Per-issuer Reg D / Reg S / Reg CF                         |
| **Trading venue**                       | Open (subject to local regs)                                                     | CEDEX                                     | CEDEX                                                     |
| **Holding period**                      | None                                                                             | Reg D 6-month                             | Reg D 6-month / Reg S 12-month / Reg CF 12-month          |
| **Transfer Hook controls**              | Not applicable                                                                   | Full 42 controls                          | Full 42 controls + module-aware extensions                |
| **Governance rights**                   | Post-graduation (2028+)                                                          | Common Class B voting rights              | Common Class B / SAE / BAE shareholder rights             |
| **Fee participation**                   | Staking rewards (1.5% of all CEDEX trades)                                       | Issuer participation in Groovy Co revenue | Issuer participation per § 13.4                           |

#### 13.2.2 GROO Utility Token — Distribution Architecture

The GROO Utility Token is distributed through a **deterministic linear bonding curve** with no pre-sale, no founder allocation, no treasury reserve, and no ICO until governance-decided Scale phase Dutch auction. The distribution mechanism is mathematically transparent and on-chain.

**Bonding curve formula:**

```
price(supply) = base_price + slope × supply
```

Where:

* `base_price = 0.000001 SOL` (1 micro-SOL — the bonding curve starting price)
* `slope = 1e-15 SOL per token` (linear price increase per token minted)
* `supply` = current GROO supply in circulation

The deterministic, transparent, and admin-free nature of the bonding curve is itself part of the GROO classification posture: it cannot be characterized as an "issuer-managed offering" because there is no issuer-managed offering. The bonding curve runs in the `groo_bonding_curve` Solana program; there is no admin function to modify `base_price` or `slope` post-deployment.

**Phase progression:**

| Phase           | Trigger                 | Effect                                                                              |
| --------------- | ----------------------- | ----------------------------------------------------------------------------------- |
| Genesis         | Program deployment      | Bonding curve active; price = 0.000001 SOL                                          |
| Bonding         | Accumulating purchases  | Linear price increase per token; SOL collected to escrow                            |
| Graduation      | $1M+ TVL milestone      | Liquidity migrated to Global Unified Pool; LP burned                                |
| Post-graduation | Pool active             | GROO trades on CEDEX (and external venues subject to local regs); staking activates |
| Scale           | Governance vote (2028+) | Optional Dutch auction for additional supply; not imminent                          |

#### 13.2.3 Groovy Security Token (STO) — $20M Reg D Architecture

The Groovy Security Token is the platform operator's own equity tokenization. It is structurally identical to a Module 1 ST22 Digital Security except that the issuer is Groovy Company, Inc. itself. Salient features:

| Feature                     | Value                                                                    |
| --------------------------- | ------------------------------------------------------------------------ |
| Backing                     | Common Class B of Groovy Company, Inc.                                   |
| Offering size               | $20,000,000 Reg D (US accredited investors)                              |
| Offering price              | Per Form D filing                                                        |
| Minimum investment          | $25,000 (institutional-grade ticket)                                     |
| Use of proceeds             | Seeds Global Unified Liquidity Pool via Solana Treasury PDA              |
| Holding period              | Reg D 6-month (HP-24 enforced)                                           |
| Trading post-holding-period | CEDEX                                                                    |
| Wallet cap                  | 9.99% of supply (default)                                                |
| Compliance                  | Full 42 controls; Empire onboarding; Custody Oracle attestation per slot |

The use-of-proceeds allocation — seeding the Global Unified Liquidity Pool — is the architectural mechanism by which the platform's primary capital event becomes the foundation of the platform's permanent shared liquidity infrastructure. The $20M is transferred to the Solana Treasury PDA, then routed through the `liquidity_pool` program to the Global Pool, where the corresponding LP tokens are immediately burned. **The capital is one-way: it flows in and never returns.**

#### 13.2.4 ST22 Digital Securities — Per-Issuer, Per-Module

ST22 Digital Securities are the per-issuer tokenization product. Each issuer operates within its own ST22 mint with its own SecurityConfig PDA, its own custody attestation, and its own holding-period accounting. ST22 economics are issuer-specific within the constraints of the immutable 5% fee structure (§13.3).

### 13.3 The Unified 5% Fee Architecture

The platform charges a **single unified 5% transaction fee** on all ST22 Digital Security transactions across all three modules. The fee applies identically at both phases of the ST22 lifecycle: the primary offering (pre-CEDEX, during the Reg D / Reg S / Reg CF capital raise) and all secondary market trading on CEDEX (post-CEDEX, after holding periods expire).

#### 13.3.1 Fee Application — Primary Offering Phase

When an investor purchases ST22 tokens during an active offering, the 5% fee is deducted from the gross subscription amount before proceeds are remitted to the issuer:

| Cash Flow                          | Allocation               |
| ---------------------------------- | ------------------------ |
| Investor pays (gross subscription) | 100.00 USDC or PYUSD     |
| Issuer receives (net of fee)       | 95.00 USDC or PYUSD      |
| Platform fee                       | 5.00 USDC or PYUSD       |
| Investor receives                  | 100% of tokens purchased |

The fee is a cost of platform access, not a dilution of token allocation. The investor's token receipt equals the full subscription amount divided by the offering price; the fee is structured so the investor is not penalized in token quantity.

#### 13.3.2 Fee Application — Secondary Market (CEDEX) Phase

Every ST22 trade executed on CEDEX after the applicable holding period expires carries the same 5% fee. This fee applies on every trade, continuously and permanently, for the life of the ST22 issuance. The issuer receives no share of secondary market trading fees.

| Cash Flow                      | Allocation           |
| ------------------------------ | -------------------- |
| Buyer pays (gross trade value) | 100.00 USDC or PYUSD |
| Seller receives (net of fee)   | 95.00 USDC or PYUSD  |
| Platform fee                   | 5.00 USDC or PYUSD   |

#### 13.3.3 5% Fee Decomposition — Cross-Module

Of every 5% fee charged on every ST22 transaction (primary or secondary, M1 / M2 / M3), the fee is split into four components enforced atomically in the Transfer Hook execution path:

| Component                | Allocation | Routing                                                             |
| ------------------------ | ---------- | ------------------------------------------------------------------- |
| **Issuer rebate**        | 2.00%      | Issuer Treasury PDA (controlled by issuer multi-sig)                |
| **Staking rewards**      | 1.50%      | Staking program reward pool (distributed to GROO stakers per epoch) |
| **Protocol revenue**     | 1.06%      | Platform Treasury PDA (operational expenses; reserve fund)          |
| **Global Pool (locked)** | 0.44%      | Global Unified Liquidity Pool — LP burned at receipt                |
| **Total**                | **5.00%**  |                                                                     |

The four allocations are enforced in the `transfer_hook` program logic via Control GA-42 (audit emission and fee distribution). The percentages are immutable: the only governance-modifiable parameter is the *destination* multi-sig signer set for the issuer rebate, never the *amount* of the four splits. Certora invariant E.4 covers this immutability.

#### 13.3.4 0.44% Permanent Lock — Architectural Detail

The 0.44% routed to the Global Unified Liquidity Pool is the most important component of the fee architecture from a network-effect standpoint. Three properties combine:

1. **Immutable enforcement.** The 0.44% routing is part of the `transfer_hook` GA-42 logic. The `transfer_hook` is deployed with no upgrade authority (§5.6.2). The split cannot be altered.
2. **LP burned at receipt.** When the 0.44% reaches the `liquidity_pool` program, the corresponding LP tokens are immediately burned via SPL Token-2022 burn instruction. Withdrawal becomes mathematically impossible.
3. **Cross-module accumulation.** All three modules feed the same pool. A Module 3 BAE basin's $50M trading volume contributes $220K (0.44%) to the pool. That liquidity supports a Module 1 OTC microcap issuer's secondary market by deepening the shared reserve.

**Certora invariant E.3 (Pool Non-Extractability):** No execution path exists by which the Global Pool's reserves can be debited to a withdrawal destination. This is the mathematical guarantee of non-rugpull. See Section 15.

### 13.4 Issuer Economics — 2% Rebate

The 2% issuer rebate component is the issuer's continuous economic participation in their ST22 issuance's secondary market activity. Unlike traditional securities offerings where the issuer's economic relationship to investors is largely confined to the primary offering plus dividends, the platform's 2% rebate creates a perpetual issuer-revenue stream tied to secondary trading volume.

#### 13.4.1 Issuer Rebate by Module

| Module                     | Issuer Rebate Use Case                                                                                                                            |
| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Module 1 — Equities**    | Issuer Treasury operational funding; corporate development; bolt-on acquisitions; share repurchase                                                |
| **Module 2 — Real Estate** | SAE operational reserves; property maintenance / capex; appraiser fees; debt service; SAE common-stock dividend distribution                      |
| **Module 3 — CORECM**      | BAE operational reserves; basin-asset capex; classification-relay fees; federal-compliance legal expenses; BAE common-stock dividend distribution |

#### 13.4.2 Issuer Rebate Velocity Comparison

A worked example showing the issuer rebate's economic significance:

**Scenario:** A Module 1 OTC microcap issuer, $5M market cap, 5,000,000 ST22 tokens issued.

| Metric                          | Year 1     | Year 2     | Year 3      |
| ------------------------------- | ---------- | ---------- | ----------- |
| Annual secondary trading volume | $3,000,000 | $7,500,000 | $15,000,000 |
| Issuer 2% rebate                | $60,000    | $150,000   | $300,000    |

For comparison, an equivalent OTC issuer pre-tokenization would receive zero secondary-market participation. Brokerage commissions on OTC trades flow exclusively to broker-dealers; market-making spreads flow to MMs; nothing returns to the issuer. The 2% rebate is **structurally novel** — only protocol-owned exchange architecture (not third-party ATSs, not traditional OTC) can route a continuous secondary-trading revenue stream back to the issuer.

### 13.5 Staking Architecture — Groovy Security Token

The Groovy Security Token (STO) holders earn passive rewards through participation in protocol operations via the staking program. The staking architecture is designed around a 2.6-day epoch cycle (432,000 Solana slots at 400 ms/slot) producing approximately 140 compounding events annually — delivering meaningful yield advantage over traditional quarterly dividend structures.

#### 13.5.1 Staking Tier Structure

| Tier     | Stake Range                | APY Range   | Lockup   |
| -------- | -------------------------- | ----------- | -------- |
| Bronze   | 1,000–9,999 STO tokens     | 8.0%–12.0%  | 30 days  |
| Silver   | 10,000–99,999 STO tokens   | 12.0%–24.0% | 60 days  |
| Gold     | 100,000–999,999 STO tokens | 24.0%–40.0% | 90 days  |
| Platinum | 1,000,000+ STO tokens      | 40.0%–60.0% | 180 days |

APY is configurable by Groovy Company governance within protocol-enforced bounds. The 8% floor and 60% ceiling are hard-coded in the staking smart contract — no governance vote can set APY outside this range. This is enforced by:

```rust
require!(
    apy_basis_points >= 800 && apy_basis_points <= 6000,
    StakingError::ApyOutOfBounds
);
```

#### 13.5.2 Compounding Advantage — Effective APY

The 2.6-day epoch produces \~140 compounding events per year. The effective APY exceeds the nominal APY due to compounding:

```
APY_effective = (1 + APY_nominal / n)^n − 1   where n ≈ 140
```

| Nominal APY | Effective APY (n=140) | Advantage |
| ----------- | --------------------- | --------- |
| 8.0%        | 8.33%                 | +0.33%    |
| 24.0%       | 27.13%                | +3.13%    |
| 40.0%       | 49.13%                | +9.13%    |
| 60.0%       | 82.06%                | +22.06%   |

Higher nominal APYs produce disproportionately higher effective APYs due to compounding mathematics. The 60% nominal Platinum tier delivers an effective \~82% — a substantial yield premium versus traditional fixed-income or quarterly-dividend instruments.

#### 13.5.3 Epoch Reward Calculation

```rust
// Epoch reward calculation (Rust/Anchor)
// APY range: 800–6000 bps (8%–60%) — enforced in smart contract
// Epoch duration: 432,000 slots (~2.6 days at 400 ms/slot)
// Slots per year: 78,840,000 (per Section 5.10 network constants)

pub fn calculate_epoch_reward(
    staked_amount: u64,
    apy_basis_points: u16,        // 800 = 8%; 6000 = 60%
    epoch_duration_slots: u64,    // Always 432,000
    slots_per_year: u64,          // 78,840,000
) -> Result<u64> {
    require!(
        apy_basis_points >= 800 && apy_basis_points <= 6000,
        StakingError::ApyOutOfBounds
    );
    require!(
        epoch_duration_slots == 432_000,
        StakingError::InvalidEpochDuration
    );

    // reward = staked * (apy_bps / 10_000) * (epoch_slots / slots_per_year)
    // Rearranged for u128 overflow safety:
    // reward = staked * apy_bps * epoch_slots / (slots_per_year * 10_000)

    let reward = (staked_amount as u128)
        .checked_mul(apy_basis_points as u128)
        .ok_or(StakingError::Overflow)?
        .checked_mul(epoch_duration_slots as u128)
        .ok_or(StakingError::Overflow)?
        .checked_div((slots_per_year as u128).checked_mul(10_000).unwrap())
        .ok_or(StakingError::Overflow)?;

    u64::try_from(reward).map_err(|_| error!(StakingError::RewardTooLarge))
}
```

The staking program executes `calculate_epoch_reward` for every stake position at every epoch boundary. Rewards accrue to the staker's reward pool PDA and can be claimed any time after accrual.

#### 13.5.4 Staking Reward Pool — Funding Source

The staking program's reward pool is funded continuously by the **1.5% staking allocation from every ST22 transaction across all three modules**. This creates a direct economic linkage between platform trading volume and staking yields: as ST22 secondary market activity grows, staking rewards grow proportionally.

```
StakingRewardPool inflow per epoch = Σ (1.5% of all ST22 trade volume in epoch)
                                   across M1 + M2 + M3 mints
```

Stakers participating during high-volume epochs receive proportionally larger rewards.

#### 13.5.5 2% Staking Reinvestment — Global Pool Accumulation

A separate mechanism: 2% of staking rewards are automatically reinvested into the Global Unified Liquidity Pool at every epoch. This produces a recursive deepening: trading volume → staking rewards → 2% reinvestment → deeper Global Pool → tighter spreads → more trading volume.

### 13.6 GROO Utility Token Economics

GROO Utility Token economics are intentionally minimal — bonding curve only, no centralized issuance schedule, no founder allocation. The economic model is documented in §13.2.2 and supported by the bonding curve program logic.

#### 13.6.1 GROO Bonding Curve — Mathematical Properties

| Property                         | Value                                                                  |
| -------------------------------- | ---------------------------------------------------------------------- |
| `base_price`                     | 0.000001 SOL (1 micro-SOL)                                             |
| `slope`                          | 1e-15 SOL per token                                                    |
| Initial purchase cost (token #1) | 0.000001 SOL                                                           |
| 1,000,000th token cost           | 0.000001 + 1,000,000 × 1e-15 = 0.000001000001 SOL (\~negligible slope) |
| 1,000,000,000th token cost       | 0.000001 + 1e9 × 1e-15 = 0.000001001 SOL                               |
| 1,000,000,000,000th token cost   | 0.000001 + 1e12 × 1e-15 = 0.000002 SOL (2× starting)                   |

The slope is intentionally shallow: GROO's distribution is designed to be wide and economically accessible across millions of holders. The slope steepens only at extreme supply levels.

#### 13.6.2 GROO Use Cases

| Use Case                                   | Mechanism                                                                        |
| ------------------------------------------ | -------------------------------------------------------------------------------- |
| Transaction fee discount on CEDEX          | Stakers receive reduced 5% → 4.5% fee on personal trades (Bronze tier and above) |
| Staking yield                              | Bronze 8% to Platinum 60% nominal APY (§13.5.1)                                  |
| Governance voting (post-graduation, 2028+) | Per-token vote weight on protocol governance proposals (Section 17)              |
| Gas-fee abstraction (future)               | Optional GROO-denominated transaction fee bundle for institutional users         |

GROO is **not** a security under Release No. 33-11412 because it has no backing instrument, no centralized issuance authority controlling distribution, and no expectation of profits derived from the efforts of others (the bonding curve is deterministic and admin-free). The post-graduation governance rights activate the Category 3 (Digital Tool) classification posture.

### 13.7 Module-Aware Economic Considerations

While the 5% fee structure is uniform across all three modules, certain economic considerations are module-specific.

#### 13.7.1 Module 2 — NAV-Bound Pricing Premium

Module 2 ST22 tokens trade at up to **22% premium over NAV** (the default `nav_deviation_max_bps = 2200` enforced by Control CB-21 NAV-deviation variant — see Section 9). The 22% premium decomposes into:

| Component                 | Allocation | Rationale                                                                                                  |
| ------------------------- | ---------- | ---------------------------------------------------------------------------------------------------------- |
| Liquidity premium         | \~10%      | Fractional ownership of an indivisible underlying property; instant trade-out vs months of property sale   |
| Fractionalization premium | \~5%       | Investors otherwise unable to access the property at full ownership cost                                   |
| Custody overhead          | \~3%       | Empire §17A custody costs of SAE equity; per-slot attestation infrastructure                               |
| Protocol overhead         | \~4%       | 5% transaction fee continues to apply on each trade; the 22% NAV premium is structural, not a one-time fee |

This is an architectural distinction from Module 1 (where ST22 tokens trade at market-derived prices reflecting investor valuation of the underlying issuer) and Module 3 (where ST22 tokens trade reflecting basin-specific value drivers and federal-action risk). Module 2 is uniquely NAV-anchored.

#### 13.7.2 Module 3 — Federal-Action Liquidity Discount

Module 3 ST22 tokens may exhibit **federal-action liquidity discount** during periods when Control REG-42 federal-action variant has triggered an automatic 60-minute SLA freeze (see Section 10). When trading resumes, market participants typically reprice the token to reflect:

| Risk Factor                                        | Pricing Consequence                                              |
| -------------------------------------------------- | ---------------------------------------------------------------- |
| Federal action duration uncertainty                | Discount until classification resolves                           |
| Section 232 / DPA Title III tariff effect on basin | Reduces or increases token value depending on event direction    |
| IRA tax-credit eligibility changes                 | Reprices ongoing tax benefits                                    |
| EO 14017 supply-chain priority designation         | May increase value (positive designation) or decrease (negative) |

The pricing impact is asymmetric — positive federal designations (e.g., DPA Title III investment, IRA tax-credit qualification) typically produce upward repricing; negative federal actions (e.g., Section 232 tariff against basin output) produce downward repricing.

### 13.8 Five-Year Platform Revenue Model

The platform's revenue is derived entirely from the 1.06% protocol component of the 5% transaction fee. There are no subscription fees, listing fees, or access fees. Revenue scales linearly with total ST22 transaction volume across all issuances and all modules.

#### 13.8.1 Revenue Component

```
Platform revenue per period = 1.06% × (total ST22 transaction volume in period)
                            = 1.06% × (Σ M1 trades + Σ M2 trades + Σ M3 trades)
```

#### 13.8.2 Five-Year Volume and Revenue Projections

The following projections model platform revenue at the 1.06% protocol component of the 5% fee. Assumptions reflect accelerating issuer adoption driven by the Layer 9 IDOS module's outreach pipeline and progressive module activation (M1 in Q3 2026 launch, M2 active by Q4 2026, M3 active by Q1 2027).

| Year                     | Active M1 Issuers | Active M2 Issuers | Active M3 Issuers | Total Annual Volume | Platform Revenue (1.06%) | Global Pool Accumulation (0.44%) |
| ------------------------ | ----------------- | ----------------- | ----------------- | ------------------- | ------------------------ | -------------------------------- |
| 2026 (H2 only)           | 25                | 5                 | 0                 | $50,000,000         | $530,000                 | $220,000                         |
| 2027                     | 150               | 30                | 5                 | $400,000,000        | $4,240,000               | $1,760,000                       |
| 2028                     | 500               | 100               | 25                | $1,500,000,000      | $15,900,000              | $6,600,000                       |
| 2029                     | 1,250             | 250               | 75                | $4,500,000,000      | $47,700,000              | $19,800,000                      |
| 2030                     | 2,500             | 500               | 200               | $11,000,000,000     | $116,600,000             | $48,400,000                      |
| **Cumulative 2026–2030** |                   |                   |                   | **$17,450,000,000** | **$184,970,000**         | **$76,780,000**                  |

These projections assume:

* Average per-issuer annual secondary trading volume scales from $1M (year 1 issuer) to $4M (mature issuer)
* Module activation cadence: M1 immediate; M2 from Q4 2026; M3 from Q1 2027
* Issuer adoption accelerates from year 2 driven by IDOS-driven outreach and SEC examination clarity
* No catastrophic regulatory event halting the platform; continued Category 1 Model B framework

#### 13.8.3 Cumulative Global Pool Depth — Architectural Significance

By end-2030, the cumulative Global Pool accumulation reaches **$76.78M from the 0.44% lock alone** — independent of the initial $20M Groovy Security Token (STO) seed. Total Global Pool depth at end-2030: \~$96.78M+ in permanent locked liquidity, all withdrawal-impossible per Certora invariant E.3.

This depth is what enables a Module 1 OTC microcap issuer with $500K market cap to access institutional-grade liquidity that would be uneconomical via market-maker subsidies on traditional OTC venues. The shared-pool architecture turns aggregate platform volume into per-issuer liquidity — a structural advantage no per-product-isolated tokenization platform can match.

### 13.9 Tokenomics Summary Table

| Mechanism                           | Value                                | Module Coverage      | Enforced By                                   |
| ----------------------------------- | ------------------------------------ | -------------------- | --------------------------------------------- |
| 5% transaction fee                  | Total fee on all ST22 trades         | M1, M2, M3           | `transfer_hook` GA-42                         |
| 2% issuer rebate                    | Routed to issuer treasury            | M1, M2, M3           | `transfer_hook` GA-42 distribution            |
| 1.5% staking rewards                | Routed to STO staker pool            | M1, M2, M3           | `transfer_hook` GA-42 distribution            |
| 1.06% protocol revenue              | Routed to platform treasury          | M1, M2, M3           | `transfer_hook` GA-42 distribution            |
| 0.44% permanent Global Pool lock    | LP burned at receipt                 | M1, M2, M3           | `transfer_hook` GA-42 + `liquidity_pool` burn |
| 22% NAV premium tolerance (default) | Module-specific economic property    | M2 only              | Control CB-21 NAV-deviation variant           |
| Federal-action freeze (60-min SLA)  | Module-specific operational property | M3 only              | Control REG-42 federal-action variant         |
| 2.6-day staking epoch               | 140 compounding events/year          | All staking          | Staking program `calculate_epoch_reward`      |
| 8%–60% APY bounds                   | Hard-coded; immutable                | All staking tiers    | `StakingError::ApyOutOfBounds`                |
| GROO bonding curve                  | `price = 1e-6 + 1e-15 × supply` SOL  | GROO ecosystem token | `groo_bonding_curve` program                  |
| $20M Groovy Security Token raise    | Use-of-proceeds: Global Pool seed    | Platform-wide        | One-time Reg D issuance                       |

### 13.10 Architectural Decision Records — Tokenomics

| ADR     | Title                            | Date         | Decision Summary                                                                                                                                               |
| ------- | -------------------------------- | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| ADR-003 | 5% unified fee structure         | March 2025   | Single fee across primary + secondary, all modules. Simpler than tier-based pricing; eliminates governance ambiguity.                                          |
| ADR-004 | 0.44% permanent Global Pool lock | June 2025    | Mathematical permanence via LP burn; differentiated from market-maker withdrawability; Certora E.3.                                                            |
| ADR-008 | GROO bonding curve parameters    | August 2025  | `base_price = 1e-6 SOL`; `slope = 1e-15 SOL/token`. Wide accessibility; admin-free distribution.                                                               |
| ADR-011 | 2% staking reinvestment          | January 2026 | Recursive Global Pool deepening; aligns staker incentives with platform-wide liquidity.                                                                        |
| ADR-012 | Module-aware economic posture    | March 2026   | Same 5% fee across modules; module-specific risk surfaces (NAV deviation M2; federal action M3) handled by Transfer Hook variants, not by fee differentiation. |

***

### 13.11 Cross-References

* **Section 5** — Layer 1 Solana Foundation (`transfer_hook` immutability; the architectural foundation of fee permanence)
* **Section 7** — Layer 2 Transfer Hook (the 42 controls + module-aware extensions; GA-42 audit and fee distribution control)
* **Section 8** — Module 1 Equities (M1 issuer economics; Common Class B backing)
* **Section 9** — Module 2 Real Estate (NAV-bound 22% premium economic structure)
* **Section 10** — Module 3 CORECM (federal-action economic considerations)
* **Section 14** — Global Unified Liquidity Pool (the destination of the 0.44% lock; LP burn mechanics)
* **Section 15** — Security Model (Certora E.3 pool non-extractability; E.4 fee-allocation immutability)
* **Section 17** — Governance (the bounded set of governance-modifiable parameters; APY range enforcement)
* **Tokenomics Deep Dive** — extended modeling, sensitivity analysis, alternative scenarios
* **Smart Contract Reference** — full `staking` program interface; epoch reward Rust source

***

*RWA Tokens Platform Whitepaper · Section 13 — Tokenomics · V10.0 · 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:

```
GET https://bitbook.rwatokens.net/reference/reference/whitepaper-v10/tokenomics.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.