# Incentives and Value Flow

### Trust Ledger Utilization Fees

A relying party executes a Trust Ledger Utilization every time it wants to verify a credential presented by the individual. It is the core value-generating event in the network.

Let:

* N<sub>t</sub>​ = number of verifications in period t
* f<sub>t​</sub> = fee per verification (denominated in $VLCT)

Total fees collected in period t:

F<sub>t</sub>=N<sub>t</sub>×f<sub>t</sub>

Each Trust Ledger Utilization fee paid by a relying party is programmatically distributed to align incentives and ensure long-term sustainability:

* **70%** → Issuer reward
* **10%** → Oracle node operator reward pool
* **10%** → Foundation treasury
* **10%** → Token burn *(activated only once the node operator reward pool is sufficiently funded)*

During the early phases of the network, the burn component is temporarily redirected to the node operator reward pool until a target funding level is reached. Once this threshold is achieved, the burn mechanism is activated, introducing a deflationary dynamic tied directly to network usage.

This structure ensures that value generated by verification activity is:

* distributed to contributors who create and maintain trust in the network,
* reinvested into ecosystem development, and
* increasingly returned to token holders through scarcity over time.

### Gas Fees

Credential registration and revocation executed by Issuers are core infrastructure operations that maintain the integrity and reliability of the network.

#### Fee Allocation

Gas fees are allocated with a different priority than Trust Ledger Utilization fees.

Their primary purpose is to ensure that the network has sufficient economic resources to support:

* reliable node operation,
* consistent transaction processing, and
* long-term protocol sustainability.

Gas fees is programmatically distributed as follows:

* **100% → Oracle node operator reward pool (until target funding level is reached)**
* **Thereafter: 100% → Foundation treasury**

#### Bootstrap Phase — Infrastructure First

During the early stages of the network, all registration and revocation fees are directed to the **node operator reward pool**.

This ensures:

* sufficient incentives for node operators,
* stable and predictable participation, and
* reliable processing of credential writes from inception.

At this stage, credential write activity directly contributes to securing the network.

#### Transition to Treasury Funding

Once the node operator reward pool reaches its target funding level, the allocation of credential write fees transitions:

* fees are no longer required to support node incentives,
* and are instead directed to the **Foundation treasury**.

This transition reflects the maturation of the network, where:

* node operators are primarily sustained by verification fees and reduced emissions,
* and credential write activity becomes a source of ecosystem funding.

#### Role in the Network Economy

Credential write operations are intentionally positioned as: **low-cost infrastructure actions that maintain trust and data integrity**

They are not designed to maximize value capture, but to ensure that:

* credentials can be issued at scale,
* revocations are frictionless and consistently executed, and
* the network remains accurate and trustworthy over time.

As such:

* **early-stage value** supports network security and participation,
* **later-stage value** supports ecosystem growth and governance.

#### Economic Implications

This model ensures that:

* infrastructure costs remain aligned with network needs,
* node operators are properly incentivized during critical growth phases, and
* the Foundation is sustainably funded as the network matures.

It also reinforces a clear separation of roles within the economy:

* **Verification fees** drive value capture and participant rewards
* **Credential write fees** support infrastructure and ecosystem continuity

#### Summary

Gas fees evolve with the network:

* Initially supporting **node operator incentives and network stability**
* Later contributing to **Foundation-led ecosystem development**

This ensures that even low-cost, high-frequency operations contribute meaningfully to the long-term sustainability of the Velocity Network.

### Issuer Reward

Issuers earn rewards only when their credentials are verified.

Use:

* i = credential type (Identity or Standard)&#x20;
* j = issuer
* t = period

Let:

* V<sub>i,j</sub> = number of verifications of credentials type i issued by issuer j in period t
* p = issuer share per verification fee (in $VLCT), where p=60%⋅f<sub>t</sub>

Issuer revenue:

hen issuer reward becomes:

IssuerReward<sub>j,t</sub>=∑<sub>i</sub>p<sub>i</sub>⋅V<sub>i,j,t</sub>

Issuer rewards may be shared between:

* the **Credential Issuer**, and
* the **Credential Agent Operator** (a service provider operating on behalf of the issuer)

Issuers are therefore incentivized to issue credentials that are:

* accurate,
* compliant,
* economically meaningful, and
* in demand by relying parties.

Issuance volume alone produces no reward.

### Oracle Node Operator Reward

Oracle node operators and their delegators earn rewards from the **node operator reward pool**, funded by a fixed share of verification fees.

* **20% of each verification fee** is allocated to this pool
* During the bootstrap phase, the pool is additionally supplemented by emissions

Target staking yield:

Ytarget≈3%&#x20;

Yield sources evolve over time:

* **Bootstrap phase** — emissions dominate
* **Growth phase** — mixed emissions + fees
* **Maturity phase** — fees dominate, emissions approach zero

The temporary redirection of the burn allocation to the reward pool in early stages ensures:

* sufficient incentives for node participation,
* stable and predictable yield, and
* secure network operation from inception.

Over time, as fee volume grows, rewards become increasingly driven by real economic activity rather than token issuance.

This results in a yield profile that is:

* transparent,
* bounded, and
* increasingly utility-backed.


---

# 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://velocity-network.gitbook.io/velocity-network/usdvlct-tokenomics/incentives-and-value-flow.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.