Skip to main content

Global Mint TLM

tl;dr Distribute newly minted (net new) coins on a per claim basis to all involved stakeholders.

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 newley minuted tokens would be distributed as follows:

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. This is shown in red.

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 supplement the Global Mint TLM such that:

  1. The application is overcharged by the inflation amount in TLM: Global Mint.
  2. The application must "show face" in front of the DAO/PNF to request reimbursement.
  3. 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.

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

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 send funds to previously KYCed gateways
  6. The script above, and the trust that it'll be maintained, updated and executed relies in 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 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.