Skip to main content

​
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.

​
Verification fees

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

​
Burn and treasury rates

Governance can adjust burn and treasury allocation within bounds: 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:
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:
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. The whitepaper suggests a maturity-based schedule. 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

See Governance 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.