Restoration of Osmosis Max Supply to 1 billion

Original Thread: Commonwealth

This post contains two proposals.

The first is a resubmission of Proposal 535’s parameters which were overwritten by the expedited proposal 539, the second implements a Burn address on Osmosis - something that doesn’t exist by default on Cosmos chains, and disposes of the extra epoch’s emissions through it.

Both target on-chain date of 30th June 2023.

Resubmission: Lengthen Thirdening and restore Thirdening impact

This proposal is a resubmission of Proposal 535’s parameters which were overwritten by the expedited proposal 539.

This proposal performs the following parameter changes:

  • Revert the Thirdening effect back to a third reduction
  • Increase the Thirdening length to 2 years

Osmosis Max Supply Restoration through Excess OSMO Burn

This proposal aims to restore the maximum emissions of Osmosis to 1 billion by burning the excess OSMO generated during the delay to the Thirdening event on June 20, 2023.

This proposal designates the null address (osmo1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqmcn030) as the burn address for Osmosis. All supply queries will exclude this address to create an identical function of a traditional burn address on other systems.

The amount of excess OSMO generated is 547,945.205479 OSMO, and this proposal would directly send that amount to the null address from the community pool.


Excess OSMO

The Thirdening event took place on the epoch of the 21st of June, 2023, after the passing of Proposal 539.

This delayed implementation resulted in one additional epoch (20th June 2023/Epoch 732) of emissions at the previous rates.

As the time to perform the subsequent reduction event increments from the last change, the emissions of epoch 732 were completely surplus.

Therefore excess emissions were

200,000,000 / 365 = 547,945.205479

These emissions resulted in a new maximum supply of 1,000,547,945.205479 rather than the intended 1 billion.

Burn Address

Cosmos chains do not have a burn mechanism by default. Other chains, such as Ethereum, use the null address (0x0000000000000000000000000000000000000000) as a disposable address.

The equivalent on Osmosis is osmo1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqmcn030 which can be verified on the CLI by using the command

osmosisd debug addr 0000000000000000000000000000000000000000

To cause the null address to function as a burn address, it must be excluded from supply queries, after which it can be used to dispose of unwanted tokens.

While a private key theoretically exists for the null address, it is unknown, and this process is in use by several other chains for the same key.

Sourcing from Community Pool

While the excess OSMO was distributed between all parameter destinations, this proposal only uses the Community Pool as a source of the OSMO for disposal. This far simpler prevents any clawback mechanism from requiring a hard fork.

OSMO in the community pool is not circulating and only has actual value once it enters the circulating supply.

Rejection of Proposal

Rejection of this proposal would signal that the new maximum supply is 1,000,547,945.205479 or that the rectification method is unsuitable.


The implementation of this proposal will require the following steps:

Execution of Burn Transaction

This proposal transfers 547,945.205479 OSMO from the community pool to the null address (osmo1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqmcn030).

Supply Update

All supply queries will be adjusted to ignore any tokens held in the null address during a future software upgrade.


Restoring the maximum emissions of Osmosis to 1 billion by burning the excess OSMO generated during the Thirdening delay demonstrates the Osmosis community’s commitment to maintaining the protocol’s integrity. By implementing the proposed burn and designating the null address as the burn address, Osmosis ensures accurate supply figures and establishes a mechanism for future burns if necessary. This proposal aligns with Osmosis’s long-term sustainability and growth as a leading decentralized exchange platform.



Agree that the excess emissions should be burned, but is there a specific reason why these funds have to come from the community pool rather than other sources such as the “Strategic Reserve” or another Foundation controlled address?

Understand that this is a bit of an edge case, but should community pool funds be used to rectify the unintended consequences of a proposed tokenomics upgrade?

For reference:

Community Pool Docs

(Community Pool - Osmosis Labs)

Commentary on Strategic Reserve

(OSMO Token Distribution. The Osmosis token model distributes… | by Osmosis Labs | Osmosis | Medium)



lol I love crypto so much

yes, lets

Leonoor’s Cryptoman


Help me on this one.

I was under the assumption that with the adjustments to the tokenomics we wouldn’t hit the 1 billion OSMO anyways, but rather stick to around 980 million or so?

I’m basing it on this analysis discussed here:

So the additional 500k should not pose an issue imo?

Johnny Wyles


It was going to be 980m if we didn’t sync with the thirdening but did the upgrade handler method. Since we were syncing with the thirdening, then it should have retained exactly 1 billion.

Since this was the intention we should either burn back down, or make the conscious choice to keep the slightly higher than originally planned supply.

Leonoor’s Cryptoman


Ok, and in the worst case we burn even more resulting in even a bit lower total supply :slight_smile:

Other question; why use the null address (osmo1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqmcn030)?

Why not check the burn contract as used by Chihuahua burning the coins truly for once and for all?

Johnny Wyles


Is that a cosmwasm contract? I’ll look into this before moving to chain if it’s a simple contract.

Generally less developer overhead to do this and the functionality of having a burn address can be used by any token, contract or user on Osmosis. Same way that Eth does it.

If the contract functions as a true burn though may be a better solution.

Johnny Wyles


Had a dig through the Chihuahua code, the burn contract is just the controller for the burn mechanism - it controls how much is burned per day and acts as a repository for pending burn that can be withdrawn to the community pool.

The actual burn mechanism is implemented in the bank module itself as a new message.

either way works then, but since we just want to burn anything at that address no matter what this is the simplest mechanism.


Sending to 0x0 is not a burn; therefore it should not be given the false equivalency. Why does it matter? Because on coingecko, etc incorrect values for circulating supply will be reported. That matters a lot to people looking to buy OSMO.

A burn module is trivial to implement and has its own address, so anyone can truly burn tokens, eg the community pool. We should do the right thing that requires a little bit of work but provides a mechanism that truly burns tokens and doesn’t just lock them. See Commonwealth.

Leonoor’s Cryptoman


Yeah, agreed. I will vote against the proposal currently on chain, mainly for this reason.

It kinda feels we are rushing on multiple topics on Osmosis, while we have time on our hands to do it right. We are passing proposals which will only come in play months from now, so waiting a bit for finding the right route is also a possibility.

In this case it is even “worse”, since we will not hit the max supply in the coming years. So we have time to implement the right burn methods before executing it.



eh, I am strongly in favor of this prop because 1b is so much easier to reason about than other numbers that could otherwise be chosen.