### Author:  [@Jinx](https://forum.pokt.network/u/Jinx)
#### Post date: [December 9, 2025, 4:17pm UTC](https://forum.pokt.network/t/pip-xx-introducing-a-deflationary-mint-mechanism-for-shannon-tokenomics-revised/5621/1 "2025-12-09T16:17:19Z")
## 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
```auto
{
"mint_ratio": 1.0,
"mint_allocation_percentages": {
"dao": 0.05,
"proposer": 0.14,
"supplier": 0.78,
"source_owner": 0.03
}
}
```
### Proposed Parameters
```auto
{
"mint_ratio": 0.975,
"mint_allocation_percentages": {
"dao": 0.045,
"proposer": 0.14,
"supplier": 0.79,
"source_owner": 0.025
}
}
```
### How It Works
```auto
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:
```auto
// 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
```auto
{
"@type": "/poktroll.tokenomics.MsgUpdateParams",
"authority": "",
"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
- [Original Pre-Proposal Discussion](https://forum.pokt.network/t/pip-xx-introducing-a-dedicated-burn-mechanism-to-achieve-true-deflationary-tokenomics-pre-proposal/5621)
- [Shannon Protocol Economics Parameters](https://forum.pokt.network/t/protocol-economics-parameters-for-the-shannon-upgrade/5490)
- [Relay Burn Equals Mint Implementation](https://github.com/pokt-network/poktroll/blob/main/x/tokenomics/token_logic_module/tlm_relay_burn_equals_mint.go)
* * *
_This proposal incorporates feedback from @RawthiL, @msa6867, @Cryptocorn, @TracieCMyers, @tony, and other community members._
---
### Author:  [@RawthiL](https://forum.pokt.network/u/RawthiL)
#### Post date: [December 9, 2025, 5:52pm UTC](https://forum.pokt.network/t/pip-xx-introducing-a-deflationary-mint-mechanism-for-shannon-tokenomics-revised/5621/2 "2025-12-09T17:52:10Z")
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 😛 ) :
- The burn is implicit in the minting step, reducing the amount set here [poktroll/x/tokenomics/token\_logic\_module/tlm\_relay\_burn\_equals\_mint.go at 907b72ade6cdf094180c5ee65a7b28a47b838b32 · pokt-network/poktroll · GitHub](https://github.com/pokt-network/poktroll/blob/907b72ade6cdf094180c5ee65a7b28a47b838b32/x/tokenomics/token_logic_module/tlm_relay_burn_equals_mint.go#L114)
- All dashboards and tooling remains the same, only an extra parameter to track, lets call it `supply_burn_per_claim` which should be `<1.0`.
- Total supply is reduced (some coins ceased to exist, less coins were minted into existence).
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.
---
### Author:  [@msa6867](https://forum.pokt.network/u/msa6867)
#### Post date: [December 9, 2025, 6:59pm UTC](https://forum.pokt.network/t/pip-xx-introducing-a-deflationary-mint-mechanism-for-shannon-tokenomics-revised/5621/3 "2025-12-09T18:59:59Z")
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?
> [@RawthiL](#):
>
> The burn is implicit in the minting step, reducing the amount set here [poktroll/x/tokenomics/token\_logic\_module/tlm\_relay\_burn\_equals\_mint.go at 907b72ade6cdf094180c5ee65a7b28a47b838b32 · pokt-network/poktroll · GitHub](https://github.com/pokt-network/poktroll/blob/907b72ade6cdf094180c5ee65a7b28a47b838b32/x/tokenomics/token_logic_module/tlm_relay_burn_equals_mint.go#L114)
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?
> [@Jinx](#):
>
> - Less control over entity-specific impacts
> - Proportionally affects all entities equally
> - Harder to adjust targeting in future
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.
> [@Jinx](#):
>
> The USD-pegged CU pricing means burn quantity varies inversely with POKT price:
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).
---
### Author:  [@Jinx](https://forum.pokt.network/u/Jinx)
#### Post date: [December 9, 2025, 7:15pm UTC](https://forum.pokt.network/t/pip-xx-introducing-a-deflationary-mint-mechanism-for-shannon-tokenomics-revised/5621/4 "2025-12-09T19:15:10Z")
> [@msa6867](#):
>
> 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.
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:
```auto
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:
> [@RawthiL](#):
>
> The burn is implicit in the minting step, reducing the amount set here [poktroll/x/tokenomics/token\_logic\_module/tlm\_relay\_burn\_equals\_mint.go at 907b72ade6cdf094180c5ee65a7b28a47b838b32 · pokt-network/poktroll · GitHub](https://github.com/pokt-network/poktroll/blob/907b72ade6cdf094180c5ee65a7b28a47b838b32/x/tokenomics/token_logic_module/tlm_relay_burn_equals_mint.go#L114)
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 😉 ), but doesn’t offer the same level of control.
> [@msa6867](#):
>
> 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)
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.
---
### Author:  [@Jinx](https://forum.pokt.network/u/Jinx)
#### Post date: [December 9, 2025, 7:28pm UTC](https://forum.pokt.network/t/pip-xx-introducing-a-deflationary-mint-mechanism-for-shannon-tokenomics-revised/5621/5 "2025-12-09T19:28:00Z")
> [@RawthiL](#):
>
> - 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)
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.
> **[Buf Schema Registry](https://buf.build/cosmos/cosmos-sdk/docs/a755fefe3a55b97a1ecbc9e13f24864a06eccff0:cosmos.bank.v1beta1#cosmos.bank.v1beta1.MsgBurn)**
I think that addresses the observability and supply reduction concern, no?
---
### Author:  [@msa6867](https://forum.pokt.network/u/msa6867)
#### Post date: [December 9, 2025, 7:30pm UTC](https://forum.pokt.network/t/pip-xx-introducing-a-deflationary-mint-mechanism-for-shannon-tokenomics-revised/5621/6 "2025-12-09T19:30:41Z")
> [@Jinx](#):
>
> 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.
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.
> [@Jinx](#):
>
> 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.
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,
---
### Author:  [@Jinx](https://forum.pokt.network/u/Jinx)
#### Post date: [December 9, 2025, 7:38pm UTC](https://forum.pokt.network/t/pip-xx-introducing-a-deflationary-mint-mechanism-for-shannon-tokenomics-revised/5621/7 "2025-12-09T19:38:37Z")
> [@msa6867](#):
>
> 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
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?
---
### Author:  [@RawthiL](https://forum.pokt.network/u/RawthiL)
#### Post date: [December 9, 2025, 7:44pm UTC](https://forum.pokt.network/t/pip-xx-introducing-a-deflationary-mint-mechanism-for-shannon-tokenomics-revised/5621/8 "2025-12-09T19:44:52Z")
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.
---
### Author:  [@Jinx](https://forum.pokt.network/u/Jinx)
#### Post date: [December 9, 2025, 7:51pm UTC](https://forum.pokt.network/t/pip-xx-introducing-a-deflationary-mint-mechanism-for-shannon-tokenomics-revised/5621/9 "2025-12-09T19:51:40Z")
> [@RawthiL](#):
>
> 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).
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.
> [@RawthiL](#):
>
> anyhow the final impact is difficult to track in both implementations
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?
---
### Author:  [@msa6867](https://forum.pokt.network/u/msa6867)
#### Post date: [December 9, 2025, 8:19pm UTC](https://forum.pokt.network/t/pip-xx-introducing-a-deflationary-mint-mechanism-for-shannon-tokenomics-revised/5621/10 "2025-12-09T20:19:51Z")
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.
---
### Author:  [@Jinx](https://forum.pokt.network/u/Jinx)
#### Post date: [December 9, 2025, 8:24pm UTC](https://forum.pokt.network/t/pip-xx-introducing-a-deflationary-mint-mechanism-for-shannon-tokenomics-revised/5621/11 "2025-12-09T20:24:34Z")
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.
---
### Author:  [@msa6867](https://forum.pokt.network/u/msa6867)
#### Post date: [December 9, 2025, 8:39pm UTC](https://forum.pokt.network/t/pip-xx-introducing-a-deflationary-mint-mechanism-for-shannon-tokenomics-revised/5621/12 "2025-12-09T20:39:10Z")
“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.
---
### Author:  [@Cryptocorn](https://forum.pokt.network/u/Cryptocorn)
#### Post date: [December 9, 2025, 10:43pm UTC](https://forum.pokt.network/t/pip-xx-introducing-a-deflationary-mint-mechanism-for-shannon-tokenomics-revised/5621/13 "2025-12-09T22:43:59Z")
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.
---
### Author:  [@Jinx](https://forum.pokt.network/u/Jinx)
#### Post date: [December 10, 2025, 2:40pm UTC](https://forum.pokt.network/t/pip-xx-introducing-a-deflationary-mint-mechanism-for-shannon-tokenomics-revised/5621/14 "2025-12-10T14:40:02Z")
@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.
---
### Author:  [@mike](https://forum.pokt.network/u/mike)
#### Post date: [December 18, 2025, 10:30am UTC](https://forum.pokt.network/t/pip-xx-introducing-a-deflationary-mint-mechanism-for-shannon-tokenomics-revised/5621/15 "2025-12-18T10:30:35Z")
Cleaner,leaner method of implementing deflationary tokenomics.