# 3. Tokenomics

## 3. Tokenomics

{% hint style="info" %}
This chapter defines DOR token economics as a closed-loop system, from fixed supply and genesis allocation to staking, governance, burn mechanics, and in-app utility.
{% endhint %}

DOR tokenomics is designed to converge the "Many Memes, One Pool" architecture into a single unit of account. All protocol cash flows, including swap spreads, contribution fees, staking yield, and external operation returns, are measured and redistributed in DOR terms. In this framework, DOR functions as both the reserve accounting unit and the settlement asset of the meme meta-market.

This chapter covers:

1. Supply and distribution architecture.
2. Utility functions and policy roles of DOR.
3. Swap and staking product mechanics that convert meme volatility into DOR-denominated cash flow.

#### 3.1 Token Structure and Distribution

**3.1.1 Issuance and Supply Cap**

DOR is issued as the single native token of the protocol. There is no dual-token design.

* Total supply: 50,000,000 DOR (fixed).
* Mint policy: fully minted at genesis.
* Inflation policy: no additional inflationary minting after genesis.

Circulating supply changes only through vesting unlock schedules, governance-approved buyback and burn, and treasury-level reallocation.

A bookkeeping reference of `1 DOR = 1 USD` may be used pre-listing for internal accounting only. After listing, valuation fully transitions to the oracle plus TWAP fair-value framework defined in Chapter 2.

**3.1.2 Genesis Allocation**

![DOR Genesis Allocation](/files/CHmylk6oGLCjaUc4HcDN)

*Figure 1. Genesis allocation across treasury, liquidity bootstrap, and long-term incentive categories based on fixed supply of 50 million DOR.*

The genesis allocation follows three macro objectives: governable capital, liquidity bootstrap, and long-term incentives.

1. Foundation and Core Treasury: 10%
   * Intended use: smart contract audits, infrastructure, R\&D, oracle/indexing operations, go-to-market support.
   * Governance path: managed by foundation before DAO transition, with transparent accounting commitments.
2. Bootstrap Liquidity and Market Operations: 30%
   * Intended use: DEX listing support, initial LP provisioning, market-making, cross-chain routing reserves.
   * Unused allocation can be reassigned or burned through governance proposals.
3. Locked and Incentive Pools: 60%
   * Intended use: long-duration liquidity incentives, staking rewards, cross-meme programs, buyback and burn reserve.
   * Policy principle: emission is constrained by system health metrics rather than flat-time release only.

This allocation separates short-term operational liquidity from long-term reinforcement, reducing short-cycle extraction pressure.

**3.1.3 Lock-up, Vesting, and Re-circulation Policy**

Emission speed from the locked and incentive pools is governed by parametric policy linked to state variables.

Key indicators:

* `CRR (Capital Retention Ratio)`: retained net capital versus external inflow.
* `LR (Liquidity Reinforcement)`: increase in effective liquidity versus incentive emission.
* `sigma_sup (Stabilization Coefficient)`: normalized indicator of downside shock absorption.

Vesting emission at time `t` is modeled as:

`V_t = V_base * f_CRR(t) * f_LR(t) * f_sigma(t)`

Interpretation:

* If CRR deteriorates, emission decelerates.
* If LR becomes inefficient, emission decelerates.
* If stabilization quality is weak, emission decelerates.
* If all indicators improve, emission can accelerate within policy limits.

This creates performance-linked emission rather than unconditional token release.

#### 3.2 Token Utility

DOR utility is organized across six functions:

1. Unit of account and settlement.
2. Liquidity and staking participation with synthetic yield.
3. Parametric governance.
4. Risk buffering and stabilization policy.
5. Incentive and culture module base asset.
6. In-app utility payments.

**3.2.1 Unified Unit of Account**

DOR is the protocol numeraire. Swap ratios, staking yield, DAO rewards, treasury accounting, and external operation returns are evaluated in DOR-denominated fair value terms.

This creates a two-layer model:

* Meme assets as high-volatility culture layer.
* DOR as accounting and settlement layer.

**3.2.2 Liquidity, Staking, and Synthetic Yield**

DOR is directly integrated into HLP and staking logic.

1. Deposit Staking (DS)
   * A fixed ratio of inflow value (for example, 30%) is automatically assigned to DS.
   * Principal and yield are accounted and paid in DOR.
   * Long lock-up and gradual unlock schedules form long-duration capital.
2. Liquidity Provision and Yield Layer
   * DOR is a core asset across MSP/RP and external LP positions.
   * Liquidity providers receive DOR-denominated portions of spread, contribution, and operation yield.

Synthetic yield refers to compression of volatility, spread, and operation returns into one DOR accounting stream redistributed to long-term participants.

**3.2.3 Parametric Governance**

DOR holders govern key protocol parameters through snapshot and on-chain voting processes.

Typical governance controls include:

* MOP/SOP/IRP allocation weights.
* DS ratio and interest policy.
* Contribution ranges, execution bands, and circuit-breaker thresholds.
* Min/max weights for specific meme assets in HLP.
* Treasury policy, including external staking, insurance sizing, buyback and burn schedules.

Beyond simple token-weighted voting, models such as quadratic or conviction voting can be adopted by DAO policy.

**3.2.4 Risk Buffer and Stabilization**

Treasury and IRP positions allow DOR to operate as a risk-absorbing buffer.

* In stressed markets, treasury DOR can be rebalanced to increase stable or hedge positions.
* In discounted conditions, protocol policy may accumulate meme inventory for controlled mean-reversion exposure.
* If DS maturity obligations exceed IRP reserves, predefined transfer rules can route a portion of operation yield into IRP.

DOR therefore has a dual role: defensive capital in crisis and growth leverage in normalized regimes.

**3.2.5 Incentive and Culture Primitive**

DOR is the base asset for programmable modules such as cross-staking, boost campaigns, farming, meme indices, and seasonal quests.

A portion of traffic and income from dominant memes can be aggregated in DOR and redistributed to:

* Theme index pools.
* New meme bootstrap programs.
* Creator reward pools.

This internalizes cross-meme network externalities.

**3.2.6 In-app Utility Items**

DOR is also used for app-level utility purchases. These items are operational features tied to execution experience and strategy automation, not only cosmetic upgrades. Pricing and settlement are DOR-native, and usage records are reflected in accounting logs.

Representative items:

1. Swap Completion Alarm
   * Push notification for swap finalization.
   * Example validity: 7 days from activation.
2. Auto Reinvestment Bot
   * Semi-automated scheduled swap execution (for example, up to four rounds under policy).
   * Example validity: 5 days or until rounds are consumed.
3. Guaranteed Yield Booster
   * Conditional yield adjustment tool for low-activity users under strict caps and one-time constraints.

Item revenue can be routed to treasury, burn, or incentive channels according to governance policy.

#### 3.3 Swap and Staking Product Mechanics

This section describes user-visible product flows and internal nonlinear dynamics.

**3.3.1 Capital Branching: 30% Deposit Staking, 70% Swap Capital**

Incoming meme value is first converted into DOR accounting terms, then split into:

* `30% -> Deposit Staking (DS)`
  * Long lock-up structure, DOR-denominated principal and yield, staged unlock after maturity.
* `70% -> HLP Operation Capital`
  * Used for swap operations, liquidity reinforcement, and downside-driven inflow execution.

Accounting interpretation:

* DS portion is future DOR liability.
* Operation portion is volatility-harvesting working capital.

**3.3.2 Downside-Driven Swap Kernel**

![Downside-driven swap kernel](/files/yjfK5UrrjxbpTlju39PB)

*Figure 2. Parametric inflow model where deeper drawdown induces stronger inflow response under saturation limits.*

Core variables:

* `x_t`: relative drawdown versus reference price.
* `v_t`: market depth/liquidity.
* `D_t`: swap inflow demand into DOR.

Design properties:

1. Larger negative `x_t` -> larger `D_t`.
2. Lower `v_t` -> stronger inflow sensitivity.
3. Extreme drawdowns are bounded by saturation parameters.

Circulating supply adjustment can be represented as:

`Delta C_t = -k * D_t`, where `0 < k < 1`.

As inflow rises during downside, external circulating meme inventory is reduced, dampening additional sell pressure.

**3.3.3 Swap Types: Liquidity-Contributing and Farming**

![Swap type comparison](/files/qHZbKphyqF6stFMQJlat)

*Figure 3. Product-level split between liquidity-contributing swaps and farming swaps.*

1. Liquidity-Contributing Swap (`MEME -> DOR`)
   * User deposits meme assets and receives DOR under unlock plus interest policy.
   * A portion of released DOR is circulated to users while contribution flows are re-routed to staking and treasury channels.
2. Farming Swap (`DOR <-> MEME`)
   * User enters short-cycle strategies targeting round-based micro-yield.
   * Principal is recycled into HLP/LP depth reinforcement.
   * Daily participation can be capped by policy (for example, up to four rounds).

**3.3.4 Contribution and Distribution Mechanics**

Contribution policy can be asymmetric by direction to control inflow, outflow, and retention quality.

Example policy format:

* `MEME -> DOR` contribution bucket may allocate shares to:
  * Staking reinforcement.
  * Direct user rewards.
  * DAO treasury.
  * Burn channel.
* `DOR -> MEME` contribution bucket may allocate shares to:
  * User-side farming incentives.
  * Staking reinforcement.
  * DAO and stabilization reserve.

## 3. Tokenomics

{% hint style="info" %}
This chapter defines the closed-loop DOR economy, from total supply and genesis allocation to staking, governance, and burn mechanics, with DOR as the base settlement asset of the meme meta-market.
{% endhint %}

DOR tokenomics is designed to converge the "Many Memes, One Pool" architecture into a single unit of account. All protocol cash flows, including swap spreads, contribution fees, staking yield, and external strategy returns, are measured and distributed in DOR terms. In this sense, DOR functions as both reserve currency and settlement asset for the meme meta-market.

This chapter covers:

1. DOR supply and allocation structure
2. Core utility functions of DOR inside the protocol
3. Swap and staking product mechanics that convert meme volatility into DOR-denominated cash flows

#### 3.1 Token Structure and Distribution

**3.1.1 Issuance and Supply Cap**

DOR is issued as the protocol's single native token. No dual-token design is used; one asset spans settlement, incentives, and governance.

Under the reference framework, total supply is fixed at `50,000,000` DOR. The full amount is minted at genesis. No inflationary minting is allowed after launch. Post-genesis circulating supply changes come only from vesting unlocks and DAO-approved buyback/burn operations.

The initial accounting reference (`1 DOR = 1 USD`) is pre-listing only. After listing, valuation fully transitions to oracle and TWAP-based fair value as described in Chapter 2.

**3.1.2 Genesis Allocation**

![DOR token genesis allocation - foundation, liquidity, community, and ecosystem ratios](/files/CHmylk6oGLCjaUc4HcDN)

*Figure 1. DOR genesis allocation by category, based on fixed 50 million total supply*

Initial distribution is organized into three policy domains: governance capital, liquidity bootstrap, and long-term incentive reserves.

1. **Foundation / Core Treasury - 10%**
   1. Typical use: smart contract audits, infrastructure and rollup costs, research, market operations.
   2. Before full DAO transition, funds are managed by the foundation with daily accounting disclosure.
   3. Purpose: bootstrap protocol R\&D and security-critical operations.
2. **Bootstrap Liquidity and Market Operations - 30%**
   1. Purpose: DEX listing, initial liquidity provisioning, market-making, and cross-chain reserve buffers.
   2. Typical deployment: initial AMM pairs (for example, DOR-ETH and DOR-USDC), strategic LP incentives, bridge-routing liquidity.
   3. Unused balance is returned to DAO treasury and can later be reallocated or burned by governance.
3. **Locked and Incentive Pools - 60%**
   1. Purpose: long-term liquidity incentives, staking rewards, cross-meme incentives, buyback/burn funding.
   2. Policy model: roughly half for vesting to long-term contributors and LPs; the remainder remains locked until DAO decisions specify burn, reallocation, or risk-buffer conversion (for example, insurance or sequencer staking reserves).

This separation isolates short-term launch operations (10% + 30%) from long-term stability and incentive programs (60%), prioritizing sustained time-in-protocol over short-term pumping.

**3.1.3 Lock-up, Vesting, and Re-circulation Policy**

Emission from the 60% locked/incentive pool is controlled by protocol state variables through parametric policy.

Primary control metrics:

* `CRR (Capital Retention Ratio)`: net retained protocol capital divided by external inflow.
* `LR (Liquidity Reinforcement)`: increase in effective HLP liquidity relative to DOR distributed in the period.
* `sigma_sup (Stabilization Coefficient)`: normalized measure of downside buffering effectiveness.

Per-interval vesting amount `V_t` follows a form such as:

`V_t = V_base x f_CRR(t) x f_LR(t) x f_sigma_sup(t)`

If CRR is weak, LR is inefficient, or stabilization effect is insufficient, vesting decelerates automatically. As indicators improve, emissions accelerate. This creates performance-linked emissions rather than fixed airdrop-like distribution.

#### 3.2 Token Utility

DOR utility spans six domains:

1. Unit of account and settlement
2. Liquidity and staking with synthetic yield
3. Parametric governance
4. Risk buffer and stabilization
5. Incentive and cultural primitive
6. In-app utility items

**3.2.1 Single Unit of Account**

All major economic outputs are denominated in DOR fair market value:

* Swap exchange rates
* Staking interest
* DAO rewards
* External deployment returns
* Treasury accounting

This creates a dual-layer system: meme assets as high-volatility culture layer, and DOR as settlement/accounting layer.

**3.2.2 Liquidity, Staking, and Synthetic Yield**

DOR directly powers HLP-linked staking and liquidity programs.

1. `Deposit Staking (DS)`
   1. A predefined share of external meme inflow (for example, 30%) is automatically routed into DS.
   2. Principal and yield are both denominated and paid in DOR.
   3. Typical structure includes long lock-up with staged unlock to create long-duration capital.
2. `Liquidity Provision / Yield Layer`
   1. DOR is a core quote/base asset across MSP/RP and external DEX LP positions.
   2. LPs receive part of spread income, contribution fees, and external operation yield in DOR terms.

Synthetic yield means compressing volatility-derived cash flows into one accounting denomination (DOR), then redistributing that stream to long-term participants.

**3.2.3 Parametric Governance**

DOR is also the governance token controlling protocol parameters, including:

* Asset allocation across `MOP / SOP / IRP`
* DS ratio and interest policy
* Contribution fee ranges, band width, and circuit-breaker thresholds
* Minimum and maximum asset weights inside HLP
* Treasury policy, including external deployment, insurance reserves, and buyback/burn schedule

Beyond linear one-token-one-vote, DAO may adopt lock-aware voting models such as quadratic or conviction voting.

**3.2.4 Risk Buffer and Stabilization**

Through treasury and IRP design, DOR also acts as risk-absorbing capital.

* Under stress, treasury DOR can be rotated into stable or hedge positions.
* In deep drawdowns, treasury can accumulate meme inventory at lower basis.
* If DS maturity obligations exceed IRP reserves, part of MOP returns can be auto-routed to IRP.

Accordingly, DOR serves two roles: defensive capital during stress and growth leverage after stabilization.

**3.2.5 Incentive and Culture Primitive**

Programmable modules, such as cross-staking, boosts, farming, meme indices, and seasonal quests, are all DOR-denominated.

Traffic and revenue generated by popular memes can be converted to DOR and redistributed into thematic indices, new meme bootstrap pools, and creator rewards. This internalizes cross-meme network externalities.

**3.2.6 In-app Utility Items**

In addition to on-chain settlement and governance, DOR is the payment unit for functional in-app items in the DAO marketplace. These items are utility-oriented, not cosmetic-only, and include execution alerts, auto-reinvestment tools, and yield-adjustment boosters.

All purchases, usage records, and distribution outcomes are committed through the accounting pipeline. Depending on governance policy, item proceeds may be routed to treasury accumulation, reward redistribution, or burn mechanisms.

#### 3.3 Swap and Staking Product Mechanics

This section explains user-facing product behavior and its internal non-linear dynamics.

**3.3.1 Capital Split: 30% Deposit Staking / 70% Swap Capital**

Incoming meme assets are not loaded into one flat pool.

The flow is split into two branches after DOR-denominated valuation:

* `30% -> Deposit Staking (DS)`
  * Example structure: 12-month lock, 5% simple annual rate, principal and yield paid in DOR, then staged unlock over 10 months.
* `70% -> Swap and operation capital (HLP)`
  * Used for liquidity-contributing swaps, farming swaps, and downside-driven operation.

From an accounting perspective, the DS branch is future DOR liability, while the HLP branch is active capital for short-term volatility capture.

**3.3.2 Downside-Driven Swap Kernel**

![Downside-driven swap kernel - inverse-correlation demand curve with stronger inflow in drawdowns](/files/yjfK5UrrjxbpTlju39PB)

*Figure 2. Parametric inflow function where liquidity inflow increases during price declines*

DOR assumes inverse-correlation demand dynamics:

* Relative drawdown from reference: `x_t`
* Market depth: `v_t`
* Swap inflow demand into DOR: `D_t`

Design properties:

1. Larger negative `x_t` increases `D_t`.
2. Lower external depth `v_t` amplifies inflow response.
3. Saturation parameters cap extreme reactions in severe drawdowns.

External circulating supply change can be represented as:

`delta C_t = -k * D_t`, where `0 < k < 1`.

This means deeper declines induce stronger absorption by DOR and dampen incremental downside pressure.

**3.3.3 Swap Types: Liquidity-Contributing vs Farming**

![Comparison of liquidity-contributing swap and farming swap](/files/qHZbKphyqF6stFMQJlat)

*Figure 3. Product-level comparison of liquidity-contributing and farming swap structures*

Two user-facing swap types are exposed on top of the downside-driven kernel:

1. `Liquidity-Contributing Swap`
   1. Direction: `MEME -> DOR`
   2. Users deposit meme assets and receive DOR including unlocked principal-share logic and accrued components.
   3. Part of generated fees and yield is re-circulated into staking pools and DAO treasury.
2. `Yield-Farming Swap`
   1. Direction: `DOR <-> MEME`
   2. Users deploy DOR to pursue round-based short-term yield.
   3. Principal is reallocated into HLP/LP depth reinforcement.
   4. Up to 4 rounds per day can be enabled under policy-defined success rules.

Illustrative step schedule:

* Round 1: `DOR -> MEME`, `+0.14375%`
* Round 2: `MEME -> DOR`, `+0.43125%`
* Round 3: `DOR -> MEME`, `+0.14375%`
* Round 4: `MEME -> DOR`, `+0.43125%` with probability weighting (for example, `p = 0.2`)

Gross directional totals before probability weighting are:

* `MEME -> DOR`: `0.8625%`
* `DOR -> MEME`: `0.2875%`

**3.3.4 Contribution Fees and Distribution: 0.8625% vs 0.2875%**

Contribution fees are asymmetric by direction.

`MEME -> DOR` nominal fee: `0.8625%`

* Staking pool: `21%`
* User rewards: `49%`
* DAO treasury: `20%`
* Burn: `10%`

`DOR -> MEME` nominal fee: `0.2875%`

* User rewards: `48%`
* Staking pool: `20%`
* DAO treasury: `32%`

This structure keeps exits available while preserving treasury and long-term reinforcement channels.

**3.3.5 Expected Yield Dynamics**

In a 4-round daily model where rounds 1-3 always execute and round 4 is probability-weighted (`p = 0.2`), the expected gross daily yield is approximately `+1.15%` under the illustrative step schedule.

![Expected return distribution by farming rounds 1-4](/files/zxVfBgXzQE704NqIbZYs)

*Figure 4. Simulated cumulative return under 4th-round probability weighting*

Applying a representative user-share rule (for example, `49%`) gives an illustrative daily user expectation around `+0.5635%`. This is not a guaranteed fixed return. Realized outcomes depend on participation frequency, volatility regime, adaptive parameter changes, and stochastic round outcomes.

**3.3.6 Structural Flywheel**

Taken together, liquidity-contributing and farming swaps create a regime-dependent flywheel:

* Drawdown regime:
  * `MEME -> DOR` inflow rises
  * External circulating supply contracts
  * DOR, DS, DAO, and burn channels are reinforced
* Expansion regime:
  * `DOR -> MEME` farming activity increases
  * Previously absorbed meme inventory is redistributed
  * Treasury and staking channels are replenished

By combining downside-driven inflow with round-based farming, DOR turns meme volatility into recurring DOR-denominated cash flow for long-term stakeholders.


---

# Agent Instructions: 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://dormanagement.gitbook.io/dormanagement-docs/3-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.