PIP-XX: Introducing a Deflationary Mint Mechanism for Shannon Tokenomics (Revised)

Proposals Pre-Proposals
1

Summary

This proposal introduces an initial and reducible 97.5% mint ratio to Shannon tokenomics, ensuring POKT achieves measurably deflationary supply dynamics. By minting only 97.5% of application burns, 2.5% of all relay-driven token flow is permanently removed from supply—creating clear, on-chain deflation that scales with network usage. As the token value grows, the mint may be further reduced to more rapidly decrease the total supply.

Authors

  • Jinx (Chris Jenkins)

Revision Notes

This revision incorporates community feedback from @RawthiL, @msa6867, and @Cryptocorn on the original pre-proposal. The primary change is adoption of a simplified implementation approach that achieves the same deflationary outcome with reduced code complexity and cleaner parameter values.

Motivation

The Current State

Shannon introduced the mint = burn mechanism where tokens burned by applications are matched by equivalent minting for network participants. While this achieves supply neutrality under ideal conditions, POKT remains slightly inflationary due to the global Mint TLM parameters producing fractional inflation even at minimal values

This fractional inflation undermines our ability to market POKT as a truly deflationary asset. “Mostly neutral with tiny inflation” is categorically different from “definitively deflationary.”

Why This Matters

  • Investor confidence: Clear deflationary mechanics create buy pressure from both speculation and utility

  • Exchange relationships: Listings and continued support depend on healthy token economics

  • Marketing narrative: “Burns 2.5% of every relay” is infinitely more compelling than “roughly neutral tokenomics”

  • Price floor mechanism: At lower POKT prices, more tokens are burned per dollar of relay fees, creating natural price support

Specification

Implementation Approach: Reduced Mint Ratio

Based on community discussion, this proposal adopts the mint ratio reduction approach rather than adding a burn allocation entity. This method:

  • Requires minimal code changes (single parameter adjustment)

  • Achieves true supply reduction (unminted tokens never exist)

  • Avoids creating a superfluous “burn” actor in the distribution

  • Maintains clean, easily communicable parameter values

Current Parameters

{
  "mint_ratio": 1.0,
  "mint_allocation_percentages": {
    "dao": 0.05,
    "proposer": 0.14,
    "supplier": 0.78,
    "source_owner": 0.03
  }
}

Proposed Parameters

{
  "mint_ratio": 0.975,
  "mint_allocation_percentages": {
    "dao": 0.045,
    "proposer": 0.14,
    "supplier": 0.79,
    "source_owner": 0.025
  }
}

How It Works

Data Request
    │
    └── Application burns CUPR (e.g., 100 POKT worth)
            │
            └── TLM Mints 97.5% of burn (97.5 POKT)
                    │
                    ├── 79.0% → Supplier (77.03 POKT)
                    ├── 14.0% → Proposer (13.65 POKT)
                    ├── 4.5% → DAO (4.39 POKT)
                    └── 2.5% → Source Owner (2.44 POKT)
                    
            └── 2.5% NEVER MINTED (2.5 POKT permanently removed from supply)

Parameter Changes Summary

Parameter Current Proposed Rationale
Mint Ratio 100% 97.5% Creates 2.5% net deflation
DAO 5.0% 4.5% Slight reduction, offset by token appreciation
Proposer 14.0% 14.0% Unchanged—protects validator economics
Supplier 78.0% 79.0% Slight increase—protects node runner incentives
Source Owner 3.0% 2.5% Reduction to underutilized allocation

Net Impact on Recipients

For every 100 POKT burned by applications:

Entity Before (100% mint) After (97.5% mint) Net Change
Supplier 78.00 POKT 77.03 POKT -1.24%
Proposer 14.00 POKT 13.65 POKT -2.50%
DAO 5.00 POKT 4.39 POKT -12.2%
Source Owner 3.00 POKT 2.44 POKT -18.7%
Supply Reduction 0 POKT 2.50 POKT ∞

The allocation adjustments deliberately protect suppliers and proposers (the active network participants) while the DAO and source_owner allocations absorb proportionally more of the deflationary impact.

Code Changes Required

The implementation is localized to a single location in the Token Logic Module:

// In tlm_relay_burn_equals_mint.go

// Current implementation (line ~114):
tlmbem.tlmCtx.SettlementCoin = settlementCoin

// Modified implementation:
mintRatio := tlmbem.tlmCtx.TokenomicsParams.MintRatio // Initially 0.975
adjustedAmount := settlementCoin.Amount.ToLegacyDec().Mul(mintRatio).TruncateInt()
tlmbem.tlmCtx.SettlementCoin = sdk.NewCoin(settlementCoin.Denom, adjustedAmount)

The existing distribution logic then operates on the reduced mint amount with no changes required to distribution code.

Governance Transaction

{
  "@type": "/poktroll.tokenomics.MsgUpdateParams",
  "authority": "<dao_authority_address>",
  "params": {
    "mint_ratio": "0.975",
    "mint_allocation_percentages": {
      "dao": "0.045",
      "proposer": "0.14",
      "supplier": "0.79",
      "source_owner": "0.025"
    }
  }
}

Economic Analysis

Current Network Metrics

Metric Value
Daily Relays 150-250M (avg ~200M)
Daily CU Usage 400-600B (avg ~500B)
CUTTM ~100,000 pPOKT (at ~$0.01 POKT)
Daily App Burn ~50,000 POKT

Deflationary Impact Projections

With 2.5% mint reduction at current traffic levels:

Timeframe App Burn Net Supply Reduction
Daily ~50,000 POKT ~1,250 POKT
Monthly ~1.5M POKT ~37,500 POKT
Annual ~18.25M POKT ~456,250 POKT

Annual supply reduction: ~0.019% of total supply at current traffic levels.

Scaling with Traffic Growth

Daily CU Usage Daily App Burn Annual Net Burn % of Supply
500B (current) 50,000 POKT 456K POKT 0.019%
1T 100,000 POKT 912K POKT 0.038%
2.5T 250,000 POKT 2.28M POKT 0.095%
5T 500,000 POKT 4.56M POKT 0.19%
10T 1,000,000 POKT 9.12M POKT 0.38%

Price Sensitivity

The USD-pegged CU pricing means burn quantity varies inversely with POKT price:

POKT Price CUTTM (approx) Daily Burn Annual Net Reduction
$0.005 200,000 pPOKT 100,000 POKT 912K POKT
$0.01 100,000 pPOKT 50,000 POKT 456K POKT
$0.05 20,000 pPOKT 10,000 POKT 91K POKT
$0.10 10,000 pPOKT 5,000 POKT 46K POKT

This creates natural price support: Lower prices → more POKT burned → greater supply reduction → upward price pressure.

Rationale

Why 97.5% Mint Ratio (2.5% Deflation)?

  1. Conservative starting point: Allows data-driven increases via future governance

  2. Minimal stakeholder impact: Suppliers see only ~1.24% reduction in rewards

  3. Clear narrative: “2.5% of every relay burns tokens” is simple and compelling

  4. Foundation sustainability: PNF remains the largest network consumer; aggressive burns could squeeze operational runway

Why This Implementation Over Burn Entity?

Per community feedback from @RawthiL:

“The burn is implicit in the minting step… Total supply is reduced (some coins ceased to exist, less coins were minted into existence).”

And @msa6867:

“Option A is not particularly elegant. We just burned POKT from app usage; why follow this with mint directly to a burn wallet… just mint less in the first place.”

Benefits of reduced mint ratio approach:

  • True supply reduction: Unminted tokens never exist (vs. minting then burning)

  • Simpler code: Single parameter change vs. new distribution entity

  • Cleaner accounting: No burn wallet balance to track or explain

  • Ecosystem consistency: All dashboards and tooling work unchanged

Why These Allocation Adjustments?

The allocation changes (Supplier 78%→79%, DAO 5%→4.5%, etc.) are designed to:

  1. Protect active participants: Suppliers and proposers see minimal net impact

  2. Absorb from reserves: DAO and source_owner take proportionally larger reductions

  3. Maintain clean numbers: All values use at most one decimal place

Future Adjustability

The mint ratio can be adjusted via governance as conditions evolve:

Scenario Action
Token price increases significantly Consider increasing burn (lower mint ratio)
Network usage grows substantially Data supports higher burn rate
Supply reduction insufficient for narrative Increase burn rate
Economic stress on participants Can reduce burn rate if needed

Recommended approach: Start at 97.5%, evaluate quarterly, adjust in 0.5% increments based on network health metrics.

Backwards Compatibility

This proposal:

  • Does not alter existing claim/proof mechanics

  • Does not change relay pricing (CUTTM, CU per relay)

  • Does not affect staking requirements

  • Requires no changes to existing integrations

Security Considerations

  1. Integer precision: Ensure mint ratio multiplication doesn’t create dust accumulation

  2. Parameter validation: Mint ratio should be constrained to reasonable bounds

  3. Governance safeguards: Large changes should require elevated consensus

Test Cases

  1. Basic reduction: Verify mint = 97.5% of burn

  2. Distribution accuracy: Confirm allocation percentages apply correctly to reduced mint

  3. Zero traffic: No mint occurs when no relays processed

  4. High volume: Test at 10T+ CU levels for integer handling

  5. Parameter bounds: Governance rejects mint_ratio outside valid range

Implementation Timeline

Phase Duration Activities
Discussion 1 week Final community feedback
Implementation 1 week Code changes, unit tests
Testnet 1 week Deployment and validation
Governance 1 week Proposal submission and voting
Mainnet — Activation upon next release

Summary

This proposal achieves true deflationary tokenomics for POKT through a simple mechanism:

Mint 97.5% of what applications burn.

The result:

  • 2.5% net deflation on every relay

  • Scales with usage: More traffic = more deflation

  • Protects participants: Suppliers see only ~1.24% reduction

  • Simple narrative: Easy to explain to investors and DAO members

  • Minimal code changes: Single parameter adjustment

Combined with Shannon’s burn-to-pay model, this positions POKT as one of the few DePIN tokens with genuinely deflationary economics tied directly to real utility.

References

This proposal incorporates feedback from @RawthiL, @msa6867, @Cryptocorn, @TracieCMyers, @tony, and other community members.

5 Likes
2

Thanks for putting this together @Jinx .

I think that the supply reduction narrative is good, and Shannon was supposed to ship with a way to achieve this from day zero. Current state of the code only allow us to go down to a very small supply reduction (supply only reduced by fees burning).

The proposed implementation is correct, but I proposed the “B“ version due to some disadvantages I see:

  • The burn mechanism is not actually burning, its transferring to an address that cannot be accessed (coins still present in total supply).
  • Creates a superfluous actor in the network, the “burn“ that does not share an origin with all the rest. (this mostly looks bad IMO)

The option B provides the following advantages (since @jinx introduced none :stuck_out_tongue: ) :

I my opinion, both A and B will reach the same goal, and both will have the same problem: Observability over supply reduction.

In both cases the value set will affect the income of different suppliers in a complex way (comparing to current). As @Jinx show in the impact assessment table, changing 1% on the supplier creates an impact of 1.28% in their income, same as DAO, where a 0.5% is a 10% change. This is unavoidable but completely manageable with some math (very similar math both in A and B scenarios).

Regarding the specifics of the amount of burn we want to implement here, I have not an strong oppinion, 2.5% sounds OK and is just as arbitrary as any other small value. The only thing that we need to keep in mind before getting greedy with this parameter, is that the amount of USD going to suppliers and DAO will be effectively reduced, no matter the price of POKT (thanks to CUTTM peg to USD). This means that we need to be conservative and do not expect a strong supply reduction if the POKT price grows.

2 Likes
3

Thanks @Jinx . I think with the dust settled on clearing out most of the early Shannon bugs, it would be good time to implement this.

I think @RawthiL makes some good points regarding the favorability of option B, but I would ask is the disadvantanges he associates with option A actual? In other words, how do other projects with deflationary tokenomics tend to achieve it…if through a burn wallet, then don’t the cointrackers already routinely have a system in place to report suppies net of burn wallet?

So are you saying that no code change is needed to implement option B… that it is already in the code, and all we needto do is set the mint% to a number less than 1 (e.g., 0.975) rather than 1?

I’m a little confused by this. As long as there are not granularity issues that limit ability to allocate between actors, then one can achieve as fine a control between actors in option B as in option A. E.g., DAO = .0462 (0.045/0.975), etc, achieves the equivalent balance of allocation between actors as in option A.

As to initial percentage of burn, perhaps you could word the proposal to implement non-zero burn up to 2.5%. That gives complete leeway to PNF to ramp up however they see fit.

I think since the percentage hit is small enough, we could at the same time defer adjustments of allocation impact among actors to PNF discretion.

That being said, my “two-cents” on that subject is to carve a disproportion amount of it for now - if not all of it - out of source owner until such time that this category is utilized. (If DAO is absorbing that allocation right now and is relying on it as a funding source, then discard the above, and share the hit with servicers and validators so DAO is not unduly impacted)

Alternately, I see nothing wrong with leaving allocations unchanged and everyone experiences a 2.5% hit. CUs per day are wildly variable as it is, and the change roughly represents getting paid on 2.5% less CUs per day. As CUs grow, I doubt it will be significantly missed.

A really good reason to start implementing burn ASAP. As long as there is network usage, burn feedback mechanism prevents the token price from collapsing to zero. In mint=burn there is nothing to prevent token price collapse (the network runs just as happily and smoothly at $POKT = 0.0001 as it does at 0.01 or 0.1).

4

In option B, the fixed value (e.g. “.975”) is applied prior to the distribution math, so the reduction affects all entities in equal proportions. That reduction impacts the minter event here, which is then passed to the distribution function:

func (tlmbem *tlmRelayBurnEqualsMint) processTokenomicsMint() error {
	// Mint the total settlement amount to the tokenomics module for distribution
	tlmbem.tlmCtx.Result.AppendMint(tokenomicstypes.MintBurnOp{
		OpReason:          tokenomicstypes.SettlementOpReason_TLM_RELAY_BURN_EQUALS_MINT_TOKENOMICS_CLAIM_DISTRIBUTION_MINT,
		DestinationModule: tokenomicstypes.ModuleName,
		Coin:              tlmbem.tlmCtx.SettlementCoin,
	})
	tlmbem.logger.Info(fmt.Sprintf("operation queued: mint (%v) coins to tokenomics module for distributed settlement", tlmbem.tlmCtx.SettlementCoin))

	return nil
}

Ramiro notes this here:

So that approach doesn’t at all allow for granularity in determining the source of the supply pulled for the burn. It is an easier approach (there, I noted an advantage @RawthiL :wink: ), but doesn’t offer the same level of control.

We’re using this as an offered incentive to bring new data sources to the network, so I don’t want to base this proposal on a heavy usage of that parameter when we may need to roll it back shortly after implementation to keep the incentive alive. I’m not entirely convinced this entity is actually useful for the long term, but I want to give it a fair shake. I think we can target that as an immediate place where we can increase the burn in the near term if it doesn’t prove out to be a useful incentive.

5

There is an implementable hard burn function that fully removes those coins from the total supply, which can be performed on the burn address:

In the Cosmos ecosystem, MsgBurn is a specific transaction type within the x/bank module that permanently removes (destroys) tokens from circulation, decreasing the total supply, unlike MsgSend (transfer) or MsgMultiSend (multiple transfers). It works by an account invoking the Burn method, specifying the amount of coins, which the bank module then permanently removes from that account’s balance, making them unspendable and reducing the overall token count on the blockchain, often used for fee burning or deflationary mechanisms.

I think that addresses the observability and supply reduction concern, no?

1 Like
6

Copy.

On the other hand, I see nothing wrong with leaving allocations unchanged and everyone experiences a 2.5% hit. CUs per day are wildly variable as it is, and the change roughly represents getting paid on 2.5% less CUs per day. As CUs grow, I doubt it will be significantly missed.

Yes, duly noted. I was only pointing out that complete equivalence between option A and B can be achieved, taking this into account. I.e., whatever distribution you came up with in option A, simply multiply by 1/(1-burn) to get the equivalent implementation in option B

eg option A

dao": 0.045,
“proposer”: 0.135,
“supplier”: 0.77,
“source_owner”: 0.025,
“burn”: 0.025

becomes option B

dao": 0.0462,
“proposer”: 0.1385,
“supplier”: 0.7897,
“source_owner”: 0.0256,

1 Like
7

Ah, I see what you mean. Using more fractional values to create the same per-entity net reduction.

@RawthiL this seems to achieve the net end result I’m looking for, albeit with a less “anyone can get it” level of math, and allows for a B implementation. That being said, the observability in the A method is much more clear in my mind using the Cosmos burn functions.

How would B accomplish the same thing?

8

yeah what @msa6867 is describing is basically how to adjust using option B, it is a little more complex but anyhow the final impact is difficult to track in both implementations. Option A just gives you a more “direct“ value (2.5% reduction in option A instead of 97.5% mint in option B).

Regarding the burn operation, in option A you would need to:

  1. Mint to burn address
  2. Burn all balance from burn address

While in option B you don’t need any of this ops, the mint operation will just mint less. The original burn operation (applied to the app stake) will take care of the supply reduction.

9

Right, and the explainability of the math is part of my consideration in option A.

”Suppliers get 77% of the mint” is hella easier to explain than “Suppliers get 78.97% and the DAO gets 4.62%” etc.

It seems to me that a dedicated burn account with a full list of MsgBurn transactions that is verifiable through any of the existing explorers wouldn’t be difficult to track at all. What am I missing?

10

I cannot speak to the last question; I’ll defer to @RawthiL on that. But I think whatever direction you go, people will adapt to thinking within the given framework. Also, there is so much range of acceptable allocation values that precision to 4 places is not necessary… I was just making a point.

Eg, close enough for option B could be

dao": 0.045,
“proposer”: 0.14,
“supplier”: 0.79,
“source_owner”: 0.025

The more I think of it, option A is not particularly elegant. We just burned pokt from the app usage,; why follow this with mint directly to a burn wallet. I think most of the projects that are using burn wallets of the sort described in option A use it as a partial allocation of token flow from one network actor to another set of actors, not as a protocol mechanism to internally mint directly to burn. As @RawthiL says, just mint less in the first place.

11

I’m a fan of whichever route achieves all the desired objectives with the greatest simplicity, so I’m certainly open to an option B formulation that includes a simple to explain granularity on burn source.

1 Like
12

“Mint to burn ration has been adjusted from 100% to 97.5% resulting in 2.5% of app burn being removed from the token supply. Correspondingly, mint recipients (DAO, proposers, suppliers, source owners) will see, on average, a 2.5% reduction in rewards compared to the old mint-to-burn ration of 100%. That being said, slight adjustments in allocation between mint recipients have been made to cause suppliers and proposers to see a smaller net reduction in rewards - closer to 1% reduction rather than 2.5% reduction - with a corresponding larger percentage reduction to DAO and source owner rewards.”

IMO, after this initial configuration, people will adjust their mindsets to the new allocations as the “new normal” and it will cease to be an issue or source of confusion.

13

I’m very much supportive of this.

I’d add:

  • Make sure to name the burn address something distinctive and clear, assuming it is used: ‘ poktxxBurnAddressxxxx’ so it can be easily understood by those new to the ecosystem.
  • I would assume that we will want to tune the burn amount overtime - likely to increase it as CUs and price increase. Slightly confusingly, i’d:
  • A) Be in favour of the ‘easy to read’ numbers of POKT remuneration reduction presented above for the initial 2.5% burn for people to understand the change.
  • B) However I’d also suggest (and this may need to come in a separate proposal) that we then move to @msa6867 % reduction across all sources so that we can relatively quickly move the burn up and down as required.
1 Like
14

@RawthiL @msa6867 I’ve reworked the proposal taking your feedback into account to include the simplicity of option B with the desired outcome targets of option A.

1 Like