> For the complete documentation index, see [llms.txt](https://docs.grindurus.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.grindurus.xyz/general/overview/tokenomics.md). # Tokenomics After establishing how GrindURUS extracts yield from market volatility thought Grinder, the third pillar of the protocol is its **economic layer - GRAI**. Whole economic layer is smart contracts ## Architecture

GRAI capital structure of one asset

## **GRAI** Symbol: `GRAI`\ Name: `Grinders Artificial Index` GRAI acts as a unified accounting and ownership layer for all capital managed by the protocol. Designed as a share-based index token representing a proportional share of the total value. Total value is the aggregated value of all assets in the system, normalized to a common unit of account (USD) using external price oracles The total value consists of\ • idle assets - assets on GRAI\ • active assets - assets stored on graiAsset vault OR deployed into Grinder Custodies\ • yield - accumulated profits on Grinder Custody or GRAI By design the total value is computed as $$ total\_value = \sum\_{k=1}^n (idle\_k + active\_k + yield\_k) \cdot price\_k $$ where each component of asset and yield is normalized to USD by price. On program is is computed as $$ total\_value = \sum\_{t=1}^n deposit\_amount\_t \* price\_t $$ where t is moment in time Unlike traditional vault tokens, GRAI operates in a dynamic multi-asset system where capital is continuously deployed, rebalanced, and reintegrated through strategy execution.
Example: How exact total value calculates Consider a system with the following assets: * **Idle assets (in GRAI):** * 1000 USDC * 2 ETH * **Active assets (in Grinder Custody):** * 500 USDC * 1 ETH * **Accumulated yield:** * 100 USDC * 0.2 ETH Assume market prices: * 1 ETH = 2000 USD * 1 USDC = 1 USD #### Step 1: Aggregate Assets Total amounts per asset: * 1000 + 500 + 100 = 1600 USDC * 2+1+0.2=3.2 ETH *** #### Step 2: Convert to USD * USDC value:1600⋅1=1600 USD * ETH value:3.2⋅2000=6400 USD *** #### Step 3: Compute Total Value total\_value=1600+6400=8000 USD
### Minting Minting is the process by which a user/agent deposits assets into the protocol and receives GRAI tokens in return. By minting GRAI, the user acquires a **proportional share of the total value** and **GRAI increases total\_supply**. Let: * `amount` — deposited asset amount * `price` — asset price in USD * `total_value` — total system value in USD * `total_supply` — total GRAI supply First, the deposit value is computed: $$ deposit\_value=amount⋅price $$ Then, the amount of GRAI to mint: $$ grai\_amount = deposit\_value \cdot \frac{total\_supply}{total\_value} $$ ### Bootstrap Case If the system is empty (`total_supply = 0`): $$ grai\_amount = deposit\_value $$ This initializes the system with a 1:1 correspondence between value and GRAI.
Example: How exact GRAI amount calculates Assume: * `total_value = 8000 USD` * `total_supply = 8000 GRAI` A user deposits: * `100 USDC` → price = 1 USD

deposit_value = 100 * 1 = 100 USD

grai_amount=100 * 8000 / 8000​=100 GRAI

*** If the value has grown: * `total_value = 10000 USD` * `total_supply = 8000 GRAI`

grai_amount=100⋅8000 / 10000=80 GRAI

Earns less share-index *** If the value has drawdown: * `total_value = 6000 USD` * `total_supply = 8000 GRAI` (unchanged)

grai_amount=100⋅6000/ 8000≈133.33 GRAI

Earns more share-index
### Phases-Aligned Capital Incentives The protocol distinguishes between two market phases: **drawdown** and **upside**. The phase is determined by comparing two valuations: 1. the **internal valuation of inventory** (protocol-defined value) 2. the **market valuation of inventory** (based on external oracle prices) Let: * `internal_value` — internal (accounting) value of inventory * `market_value` — current market value of inventory **Drawdown phase**: $$ internal\_value > market\_value $$ **Upside phase**: $$ internal\_value \leq market\_value $$ In **drawdown**, the market undervalues the inventory relative to its internal valuation In **upside**, the market value meets or exceeds the internal valuation
ConditionDrawdown PhaseUpside Phase
Total ValueDecreasesIncreases
VolatilityIncreases with high probabilityRemains present (oscillations)
Entry IncentiveStablecoin deposits (e.g. USDC)Base asset deposits (e.g. ETH, SOL)
User OutcomeLarger share of the systemIntegration of appreciated assets
Protocol EffectLiquidity inflowsExpansion of value base
Risk DynamicsInventory risk dilution over timeValue absorption and continuation
This phase-aligned mechanism enables participants to strategically position their capital to **maximize their share of future yield generation**.
Example: Why undervalued assets are NOT incentivized by the GRAI mechanism on users behalf Assume the system holds: * **Internal inventory value**: 10,000 USD * **Market inventory value**: 7,000 USD *** #### Step 1: Identify Phase internal\_value>market\_value → The system is in **drawdown phase** *** #### Step 2: System Behavior * The market undervalues the inventory * Volatility is elevated * The protocol incentivizes **stablecoin deposits (USDC)** #### Step 3: GRAI Mint Actions Assume a user holds: * **100 USDC** * **1 SOL**, which: * was bought by user at **100 USD** (users internal valuation) * current market price = **80 USD** | Deposit Choice | Valuation Basis | Effective Value | Minted GRAI | | -------------- | --------------- | --------------- | --------------- | | **100 USDC** | Market (1 USD) | 100 USD | **133.33 GRAI** | | **1 SOL** | Market (80 USD) | 80 USD | **106.67 GRAI** |
### Redemption Redemption is a liquidity-aware process by which a user exits the system by burning GRAI tokens in exchange for a proportional share of available idle assets. GRAI represents a proportional share of `total_value`, while redemption is executed against available idle liquidity in `senior_vault`. Only liquid capital (idle) can be withdrawn without disrupting system execution. Active capital is preserved for strategy execution, while idle capital serves as the liquidity buffer for redemption. Over time, yield and rebalancing convert active capital into idle liquidity, enabling gradual withdrawal of total value. Let: * `grai_amount` — amount of GRAI to redeem * `total_supply` — total GRAI supply * `idle_amount` — total amount of asset in the senior\_vault First, the share is computed: $$ share = \frac{grai\_amount}{total\_supply} $$ Then, for each asset: $$ redeem\_amount\_i​ = share \cdot idle\_amount\_i​ $$
Example: how GRAI redemption works Assume the system state is: * `total_supply = 180 GRAI` * `idle_amount = 50 USDC` * `active_amount = 150 USDC` * `total_value = 200 USDC` A user holds: * `grai_amount = 100 GRAI` User share: * `share=100/180≈55.56%` #### Redemption Since redemption is based only on idle liquidity: `redeem_amount=share⋅idle_amount` redeem\_amount = 0.5556⋅50 ≈ 27.78 USDC #### Outcome * The user receives **27.78 USDC** * The user burns **100 GRAI** * The remaining system state: * `idle ≈ 22.22 USDC` * `active = 150 USDC` * `total_supply = 80 GRAI` * The remaining participants now collectively hold **100% of the remaining GRAI supply**
### GRAI on market While redemption provides a liquidity-aware exit mechanism, it is intentionally limited to **idle assets and realized yield**, and does not extend to **actively deployed capital**. This follows from the protocol design: * idle assets → immediately withdrawable * yield → gradually realized into idle liquidity * active assets → preserved for strategy execution Because a portion of capital remains actively deployed, full immediate redemption of total system value is not always possible. > As a result, redemption reflects **available liquidity** (idle assets), NOT **total value**. To complement this, the protocol introduces a **secondary liquidity layer** via decentralized exchanges (DEXs). GRAI can be traded freely in liquidity pools (e.g., GRAI/USDC), enabling: * instant exit without waiting for liquidity to become idle * market-driven price discovery * continuous transfer of ownership between participants
MechanismNaturePricing
RedemptionProtocol liquidityFair (idle-based by senior_vault`s)
Secondary Market (DEX)Market liquidityMarket-based
### Arbitrage Between Fair Prices and Market Price The existence of two price layers of **fair price** and **market price** creates natural arbitrage opportunities. 1. Fair prices defines as $$ price\_{redeem} = \frac{sum\ of\ idle\ values}{total\_supply} \ price\_{mint} = \frac{total\_value}{total\_supply} $$ 2. Market price (price on DEX) determined by supply and demand in the secondary market. $$ price\_{market} $$ The difference between **fair prices** and **market price** creates arbitrage opportunities.
Case 1: Discount (Undervalued GRAI) `price_market​ < price_redeem​` In this case, GRAI trades below the value of its underlying assets. **Arbitrage flow:** 1. Buy GRAI on the DEX at a "discounted" price 2. Hold GRAI to: * gain exposure to total value * passive participation in price volatility yield generation 3. Redeem idle liquidity **Effect:** * demand for GRAI increases * market price moves upward between `price_redeem` and `price_mint` spread
Case 2: Premium (Overvalued GRAI) `price_market​ > price_mint​` In this case, GRAI trades above its intrinsic value. **Arbitrage flow:** 1. Deposit assets into GRAI 2. Mint GRAI at mint price 3. Sell GRAI on the DEX at a premium *** **Effect:** * supply of GRAI increases * market price moves downward between `price_redeem` and `price_mint` spread
The interaction between minting, redemption, and secondary market trading establishes a natural price band for GRAI, where the lower bound is defined by redeemable liquidity (idle assets) and the upper bound by the total value (NAV). Within this range, the market price fluctuates based on supply and demand. Arbitrage between mint, redeem, and market prices continuously enforces these bounds, creating a self-regulating pricing mechanism. Importantly, as the **protocol accumulates yield over time, total value increases, effectively shifting the upper bound upward and allowing the entire price band to expand**. This results in a system where price is not fixed, but dynamically evolves with both liquidity conditions and realized yield. ## **graiAsset** graiAsset vaults (junior vaults) are smart contracts, that manage asset allocated from GRAI and serve as an intermediary layer between: * **GRAI (accounting and ownership layer)** * **Grinders Custody (execution layer)** graiAsset vaults are responsible for: * holding pre-active assets (e.g. USDC, ETH, SOL) * accounting how much capital is borrowed and used by each Grinder Custody
Example: Capital Allocation from graiUSDC to Grinder Custody Assume: * graiUSDC vault holds **1000 USDC** * idle liquidity is already separated #### Step 1: Grinder Requests Capital A Grinder requests: * **200 USDC** for allocation #### Step 2: Vault Allocates Capital The graiUSDC vault: * transfers **200 USDC** to the Grinder * records: ``` Grinder_Custody_A borrowed: 200 USDC ``` #### Step 3: Updated State * total vault balance: 800 USDC * total allocated capital: 200 USDC
## **Grinder Custody** Grinder Custody is an on-chain smart contract responsible for **holding and operating allocated capital.** It acts as an execution environment where assets are: * stored * swapped * rebalanced Grinder Custody separates: * **strategy decision-making (Grinder, off-chain)** * **capital storage and swaps execution (Custody, on-chain)** ### Custodial Design Although Grinder Custody holds assets, the system is custodial. > All funds are governed by castodial smart contract rules. The Grinder acts as an external execution agent, but: * does not own funds * cannot withdraw assets arbitrarily * cannot bypass protocol-defined constraints ### Yield Generation Yield is generated through the execution of market operations performed via Grinder Custody. The source of yield is market price volatility, where executes buy low -> sell high OR sell high -> buy low. While Grinder defines strategy decisions off-chain, Grinder Custody executes asset swaps on-chain via swap aggregators, allowing the system to capture price volatility across market movements.
Example: Yield generation by Grinder Assume: * Grinder Custody holds **200 USDC** * SOL price moves from **100 → 110 → 100** Execution: 1. tx1: swap **200 USDC → SOL** at price 100 2. tx2: swap SOL **→ USDC** at price 110 Result: * total balance becomes **220 USDC** * **20 USDC** is realized as yield
### Yield Distribution Yield generated in Grinder Custody is distributed between **GRAI holders** and the **protocol treasury**. The yield allocation is initially computed by the Grinder off-chain based on executed strategy performance. Algorithm: 1. Grinder executes trading operations and generates yield 2. Off-chain, the Grinder computes assets yield 3. The computed values are submitted on-chain by `distribute()` transaction 4. Smart contracts apply the distribution of yield to GRAI and Protocol Treasury in 80%+20% split
Example: Yield Distribution Assume: * Grinder Custody holds **200 USDC** * After trading operations, balance becomes **240 USDC** * Total realized yield = **40 USDC** * Distribution split = **80% GRAI / 20% Treasury** *** #### Step 1: Yield Calculation (Off-chain) * initial balance: 200 USDC * final balance: 240 USDC → realized yield = **40 USDC** *** #### Step 2: On-chain Distribution On custody executes transaction `distribute()` called by Grinder: * **+32 USDC** is accounted as yield in GRAI (increases total\_value) * **+8 USDC** is transferred to Protocol Treasury *** #### Resulting State * total\_value increases by **32 USDC** * total\_supply unchanged * value per GRAI increases * Treasury balance increases by **8 USDC**
--- # 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://docs.grindurus.xyz/general/overview/tokenomics.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.