Global Mint TLM

Token Distribution (Global Inflation)

The Global Mint TLM is, theoretically, going to reach zero when the network reaches maturity in the far future.

On a per-claim basis, the network mints new tokens based on the amount of work claimed. The newly minted tokens are distributed to the DAO, Service Owner, Application, Supplier and its Revenue Shareholders based on the values of various governance params.

Example Distribution

For example, assuming the following tokenomic module params:

{
  "params": {
    "mint_allocation_percentages": {
      "dao": 0.1,
      "proposer": 0.1,
      "supplier": 0.7,
      "source_owner": 0.1,
      "application": 0
    },
    "dao_reward_address": "pokt10...",
    "global_inflation_per_claim": 0.2
  }
}

The newly minted tokens would be distributed as follows:

⚡ Token Minting & Distribution

🌍 Global Inflation Calculation

• Session.Cost

• Session.Cost + 0.2 × Session.Cost (chain.GlobalInflationPerClaim = 0.2)

• Distribution:

  • 0.7 × Session.Inflation → Supplier

  • 0.1 × Session.Inflation → DAO

  • 0.1 × Session.Inflation → Block Proposer

  • 0.1 × Session.Inflation → Service Owner

Key items referenced:

• Session.Cost (uPOKT)

• chain.GlobalInflationPerClaim (0.2)

• session.Inflation (uPOKT × 0.2)

• session.MintBurnInflate (Session Cost + Inflation)

Stakeholders / wallets referenced:

• Application Wallet (User Controlled)

• Supplier Wallet (Operator Controlled)

• DAO Treasury (pokt10...)

• Block Proposer (Validator Wallet)

• Service Owner Wallet (Service Controlled)

---

TLM: Global Mint Reimbursement Request (GMRR)

tl;dr Prevent self-dealing by over-charging applications, sending the excess to the DAO/PNF, and emitting an event as a reimbursement request.

Self Dealing Attack

A self-dealing attack is when an application leverages the inflationary nature of the tokenomics to increase its balance by sending spam traffic.

• Above the Inflation note, the number of tokens in circulation remains constant.

• After the Inflation note, the number of tokens in circulation increases.

If the individual managing the Application/Gateway is the same one who is managing the Supplier and/or Service Owner, they could mint an unbounded number of new tokens for themselves by sending fake traffic.

(diagram and process flow describing Block Proposer → DAO → Service Owner → Protocol → Supplier → Application/Gateway and the loop of providing service, minting inflation, settling session accounting, and self-dealing attack)

Reimbursement Request Philosophy

Solving the above problem is non-trivial.

See the resources for more information on the long-term game-theoretic solutions.

In the meantime, the interim manual approach described below is a stepping stone — do things that don't scale in the short term, but can be easily automated, while enabling permissionless demand and dissuading self-dealing attacks.

Reimbursement Request Design

This TLM is a dependency of the Global Mint TLM; i.e., it MUST be active ONLY IF Global Mint is active.

This TLM can, theoretically, be removed if self-dealing attacks are not a concern, or if the global mint per claim governance parameter is set to zero.

The goal of the TLM is to supplement the Global Mint TLM such that:

1

Overcharge the Application

The application is overcharged by the inflation amount in TLM: Global Mint.

2

Reimbursement Request

The application must "show face" in front of the DAO/PNF to request reimbursement.

3

Manual Approval

PNF needs to manually approve the reimbursement request.

While this is not perfect, it follows on the Deterrence Theory that the increased risk of punishment will dissuade bad actors.

NOTE: A side effect of this TLM is creating additional buy pressure of the token as Applications and Gateways will be responsible for frequently "topping up" their balances and app stakes.

Process elements referenced:

• TLM: Global Mint — Distribute Inflation (IA)

  • INCREASE Balances

  • Prevent Self Dealing: HOLD IA, Emit Event, INCREASE Module Balance (IA)

• Application Operations — REDUCE Stake by IA (Application Module / Application Keeper / Application Address)

• Tokenomics Operations — MINT IA (IA = SA * PCGI)

  • IA: Inflation Amount

  • SA: Settlement Amount

  • PCGI: Per Claim Global Inflation

• Application Reimbursement Request Event emitted by Tokenomics Module

• Inflation Distribution handled by Tokenomics Module (see Global Mint TLM for details)

• Governance Params govern the behavior

Later, PNF, on behalf of the DAO, will review the reimbursement requests and approve them.

(off-chain flow): PNF retrieves all reimbursement requests, reviews each, and either approves (send reimbursement) or rejects.

---

FAQ

Are Applications responsible for endorsing/covering the whole global mint amount?

tl;dr Yes, for the first version.

The application PAYS the supplier for work done (i.e. Mint=Burn). The application GETS REIMBURSED for the inflation (i.e. Global Mint).

This will require staked Applications (sovereign or those managed by Gateways) to periodically "top up" their balances to cover not only the onchain costs/burn, but also the inflation until it is reimbursed by the DAO/PNF.

Will there be onchain enforcement of how Applications get reimbursed?

tl;dr Unfortunately, no.

The Applications will indeed have to trust the DAO/PNF to reimburse them. The following is an example of the approach PNF could take:

1. Assume Application staking by Gateways is permissionless and done.

2. Applications pay onchain for costs and inflation.

3. PNF KYCs Gateways who seek reimbursement.

4. Gateways that don't go through the KYC process cover the cost of inflation out of pocket.

5. A script that retrieves onchain reimbursement requests will be written that automatically sends funds to previously KYCed gateways.

6. The script above, and the trust that it'll be maintained, updated and executed relies on the Gateways' trust in the PNF.

This is similar, in spirit, but still an improvement on top of the trust between Gateways and PNF in Morse today in order to:

• Get access to the limited supply of Gateway keys

• Gateways paying the onchain burn manually

How does this solution scale for Sovereign Applications?

Sovereign Applications are no different than Gateway Applications in this respect. They are smaller and a much less common use case, but will have to follow the same reimbursement process described above.

Read more about their differences and similarities here.

What kind of resources are needed to scale and automate reimbursement?

This will be a combination of onchain and offchain resources (EventReader, TxSubmission, Accounting, etc...). In particular:

• Onchain: load testing will show if events take up too much onchain space. This is unlikely to be an issue relative to proofs.

• Offchain: PNF Directors are aware and approve of the operational overhead this will require. This will require some offchain scripting to automate the process.