Why and how it works

GrindURUS is based on the fundamental property of financial markets - price volatility.

Volatility as a Source of Yield

In volatile markets, prices oscillate between levels over time. Even in the absence of a clear upward or downward trend, these fluctuations create repeated opportunities to:

• buy at relatively lower prices

• sell at relatively higher prices

OR

• sell at relatively higher prices

• buy at relatively lower prices

GrindURUS systematically captures this spread through automated execution, without requiring directional forecasting.

Example of Volatility Capture

Consider a simple scenario:

• Price moves from 100 → 110 → 100

Even though the market ends at the same level, the system can:

• accumulate position near 100

• reduce position near 110

• repeat the cycle

This creates incremental gains from each oscillation, independent of overall price direction.

What About Extreme Drawdowns?

GrindURUS is designed to operate under volatility, NOT to eliminate directional market risk.

The protocol does not deploy all capital at a single price level. Capital is allocated progressively, allowing the system to avoid full exposure at early stages of a drawdown. This approach retain reserve liquidity for continue operating on price volatility as prices decline.

Instead, it manages directional risk through a combination of accounting structure, synthetic loan, and liquidity dilution.

Example: Managing -80% drawdown

Consider a simplified scenario:

• Initial capital: 1000 quote_asset

• Initial price: 100 quote_asset/base_asset

• Market price drops to: 20 (−80%) quote_asset/base_asset

Progressive Deployment (accounting structuring)

Instead of buying everything at 100, capital is deployed in stages:

• 200 quote_asset at price 100 quote_asset/base_asset → 2.0 base_asset

• 200 quote_asset at price 80 quote_asset/base_asset → 2.5 base_asset

• 200 quote_asset at price 60 quote_asset/base_asset → 3.33 base_asset

• 200 quote_asset at price 40 quote_asset/base_asset → 5.0 base_asset

• 200 quote_asset at price 20 quote_asset/base_asset → 10.0 base_asset

That gives total:

• 1000 USDT deployed

• 22.83 units accumulated

• Average entry price ≈ 43.8 quote_asset/base_asset

The GrindURUS propose more sofisticated tricks:

Step 1 - Initial Deployment

Instead of deploying all capital at once, the system allocates in stages:

• 200 at 100 → 2.0 base

• 200 at 80 → 2.5 base

After two allocations:

• Total spent: 400 quote

• Inventory: 4.5 base

• Remaining liquidity: 600 quote

Step 2 - Synthetic Loan Activation

Accumulated base_asset inventory is no longer treated as passive holdings.

It becomes part of an internal synthetic loan layer.

The system can:

• temporarily utilize accumulated base (4.5 units)

• convert part of it into quote-equivalent liquidity (via execution)

This effectively increases reusability of inventory and execution capacity.

Step 3 - Liquidity Dilution Using Synthetic Loan

Now, when price continues to drop 200 quote (external liquidity) + synthetic base loan (from base inventory) are used together to enter new positions

At price 80:

• external 200 quote

• a fraction of accumulated base inventory is dynamically utilized as synthetic liquidity

This results:

• more base accumulated in lower prices positions

• faster reduction of average entry price

• redistribution of exposure across price levels

So, inventory base liquidity is no longer static it is recycled and diluted through internal loans.

Step 4 — Continued Deployment

• at 60 → base accumulated increases

• at 40 → more base added

• at 20 → maximum accumulation

Without syntetic loan amplification final state:

• 1000 quote deployed

• 22.83 base accumulated

• average entry ≈ 43.8

With synthetic loan layer final state:

• effective deployed liquidity > 1000

• some base inventory + volatility yield

• stronger price positioning for recovery (<43.8)

So, by this sophisticated schema we procure volatility yield and better inventory management. The exact parameters, approaches and functions remain internal to the protocol.