# Our Revenue Model

Kredo’s revenue model is designed to be **protocol-native**, predictable, and non-extractive.

#### **Authorization Fees**

Rather than charging per transfer or per balance:

* Fees are assessed per **validated spending intent**
* Fees are paid by integrators, applications, or liquidity operators
* End-users may never see or handle fees directly

This aligns revenue with **actual system usage**, not speculative activity.

#### **Policy & Infrastructure Access Fees**

Entities using advanced features—such as:

* High-volume authorization throughput
* Custom identity policies
* Specialized liquidity configurations
* Compliance-oriented rule sets

Pay recurring protocol fees denominated in $KREDO or routed through i

#### **Liquidity Fog Pool Participation Fees**

Liquidity providers who contribute capital to fog pools:

* Earn usage-based compensation
* Pay protocol coordination fees for pool access
* Operate within strict invariant rules enforced by authorization logic

Kredo does not monetize user balances, because balances do not exist.

#### **No User Monetization**

Critically:

* Users are not charged custody fees
* Users do not pay account maintenance fees
* Users do not hold protocol debt

Revenue is generated at the **infrastructure and integration layer**, not at the individual user layer.