> ## Documentation Index
> Fetch the complete documentation index at: https://docs.notareum.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Fee model

# Fee Model

Protocol fees fund validator rewards, create deflationary pressure on NOTA supply through burning, and capitalize the treasury for ecosystem development. This page covers the three fee types, collection, burn mechanics, treasury allocation, and validator distribution. All fees are denominated in NOTA to reduce oracle dependency.

## Fee types

Three fee types are defined in `NotareumFeeManager`.

| Fee Type             | Enum | Description                                        | Amount                          |
| -------------------- | ---- | -------------------------------------------------- | ------------------------------- |
| `VERIFICATION`       | 0    | Paid by resource owners to request verification    | 100 / 500 / 2,000 NOTA by level |
| `ALIAS_REGISTRATION` | 1    | Paid to register a human-readable alias            | Governance-configurable         |
| `DISPUTE_BOND`       | 2    | Posted by reporters; returned or burned by verdict | 1K / 5K / 25K NOTA by level     |

## Verification fees

| Level         | Fee        |
| ------------- | ---------- |
| BASIC         | 100 NOTA   |
| ENHANCED      | 500 NOTA   |
| INSTITUTIONAL | 2,000 NOTA |

On rejection, 50% of the fee (`REJECTION_REFUND_BPS = 5000`) is refunded to the requester. The remaining 50% flows to the fee manager.

## Fee distribution flow

```mermaid theme={"system"}
flowchart TD
    A[User pays verification fee] --> B[VerificationEngine]
    B --> C{Resolution}
    C -->|Verified| D[Full fee to approving validators]
    C -->|Rejected| E[50% refund to requester]
    E --> F[50% to FeeManager]
    G[Alias fees + other revenue] --> F
    F --> H[distributeFees]
    H --> I[Burn: 10% default]
    H --> J[Treasury: 20% default]
    H --> K[Validators: 70% default]
    I --> L[Permanent supply reduction]
    J --> M[Ecosystem grants + operations]
    K --> N[Per-validator reward balance]
```

## Burn and treasury rates

Governance can adjust burn and treasury allocation within bounds:

| Parameter     | Default        | Min | Max            |
| ------------- | -------------- | --- | -------------- |
| Burn rate     | 10% (1000 bps) | 0%  | 50% (5000 bps) |
| Treasury rate | 20% (2000 bps) | 0%  | 50% (5000 bps) |

**Constraint:** `burnRate + treasuryRate <= 10,000 bps`. The remainder flows to validators.

`setBurnRate(uint256 rate)` and `setTreasuryRate(uint256 rate)` are restricted to `ROLE_PROTOCOL_ADMIN`.

## Distribution formula

Given `total = pendingFees`:

```
burnAmount      = (total * burnRate) / 10000
treasuryAmount  = (total * treasuryRate) / 10000
validatorAmount = total - burnAmount - treasuryAmount
```

With defaults: 10% burned, 20% to treasury, 70% to validators.

Validator rewards are split equally among all validators passed to `distributeFees(address[] validators)`. In production, this SHOULD be the set of active validators at distribution time, weighted by recent verification count.

Each validator accumulates a `_validatorRewards` balance, claimable via `claimReward()`.

## Goal-oriented burn dynamics

The whitepaper specifies an adaptive burn framework. Supply evolves as:

```
S_{t+1} = S_t + M_t - B_t * p_burn - L_t + U_t
```

Where:

* `M_t`: tokens minted (goal-oriented, KPI-based)
* `B_t`: burnable tokens (fees plus slashing)
* `p_burn`: burn rate
* `L_t`: governance-locked (veNOTA) tokens
* `U_t`: governance-unlocked tokens

When `M_t = 0` (after all allocations are distributed) and `L_t >= U_t`, the protocol becomes net deflationary. The burn rate is the primary governance lever for supply management.

## Recommended burn schedule

The whitepaper suggests a maturity-based schedule.

| Year    | Recommended Burn Rate |
| ------- | --------------------- |
| Year 1  | 10%                   |
| Year 2  | 25%                   |
| Year 3+ | 50%                   |

Governance SHOULD follow this schedule but MAY deviate based on network conditions.

## Fee example: a verified payment

A merchant registers their treasury address and requests `ENHANCED` verification. The fee is 500 NOTA.

* If verified: 500 NOTA split equally among 7 approving validators = \~71 NOTA each.
* If rejected: 250 NOTA refunded to merchant, 250 NOTA to FeeManager.

At default split on the rejected path:

* Burn: 25 NOTA burned.
* Treasury: 50 NOTA to treasury.
* Validators: 175 NOTA distributed across active set on next `distributeFees` call.

## Governance control

| Parameter                   | Role                                   |
| --------------------------- | -------------------------------------- |
| `burnRate`                  | `ROLE_PROTOCOL_ADMIN`                  |
| `treasuryRate`              | `ROLE_PROTOCOL_ADMIN`                  |
| `aliasFee`                  | `ROLE_PROTOCOL_ADMIN`                  |
| Verification fees per level | Currently immutable; future governance |
| Treasury address            | `ROLE_PROTOCOL_ADMIN`                  |
| Burn address                | `ROLE_PROTOCOL_ADMIN`                  |

See [Governance](governance.md) for the role structure and progressive decentralization plan.

## Security considerations

**Fee manipulation.** Governance-controlled parameters could be abused. `ROLE_PROTOCOL_ADMIN` SHOULD be held by a timelock with a minimum 48-hour delay.

**Validator reward distribution.** In v1.0, `distributeFees` accepts a caller-supplied validator list. The caller MUST honestly supply the correct set. Future versions will implement on-chain active validator tracking.

**Reentrancy.** Fee collection and distribution involve token transfers. All transfers MUST use `SafeERC20`. Contracts follow checks-effects-interactions and use reentrancy guards for extended distribution logic.

## Related pages

* [Verification Engine](verification-engine.md) for fee collection flow
* [Tokenomics](../token/tokenomics.md) for the full token economic model
* [Slashing](slashing.md) for burn-via-slashing
* [FeeManager contract](../smart-contracts/fee-manager.md)