Proposal 19: MCB New Tokenomics

Current MCB issuance summary

Upon Jan 12th, 2021, 2,016,096 MCB has been issued, among which:

  • 1 million MCB belongs to the team and investors:
    • Dev Team: 510K
    • Angel investor: 170K
    • Private token sale: 320K, Price 2.5USD/MCB
  • 996,955 MCB belongs to Liquidity providers
  • 19,141 MCB belongs to community contributors

Updated tokenomics

  1. The already issued MCB will keep circulating, but the total amount will reduce from 100 million to 10 million.
  2. MCDEX DAO will be responsible for the specific usage of the newly issued MCB (refer to Mai 3 Protocol)
  3. The speed of issuance will be under following restrictions:
    a) It is plausible to issue 1 MCB for 1 USD captured by the MCDEX DAO vault
    b) At least 0.2 MCB can be issued by one Ethereum block (approximately 1300MCB/day)
  4. For every new issuance, 25% of it belongs to the team, and 75% is for community incentive.

Highlights of the new tokenomics

As stated in the Mai3 protocol: MCB is the governance token of MCDEX DAO. MCDEX DAO continuously captures value in the MCDEX ecosystem, and MCB holders can participate in the governance of DAO vault. In MCDEX V3, MCDEX DAO will charge 0.015% of the trading volume as vault fee, and this would be the major source of the value captured by the MCDEX DAO vault.

The new tokenomics tries to balance between “to issue more MCB as incentive” and “to protect existing holders“. On one hand, we need to issue more MCB as community incentive, especially liquidity incentive. We profoundly understand that liquidity is essential for MCDEX, and liquidity mining is the best way to obtain liquidity at an early stage and to bootstrap the platform. On the other hand, to issue more MCB will dilute the share of current MCB holders, especially when MCB is not yet good at value capture at the early stage.

The new MCB tokenomics tries to approach the abovementioned concerns:

  1. Reduce the total supply from 100 million to ten million. The action of issuing more MCB to incentivize liquidity should only take place during the early stage to bootstrap the platform. As the platform itself enters a virtuous cycle/positive feedback loop, MCDEX DAO will continue to capture value. At this point the value captured by DAO is a sufficient income for liquidity incentive and other community incentive. Taking into account that 2,016,096 MCB has already been issued, and an additional 7,983,904 can be issued in the new tokenomics. Among them, 75% (5,987,928 MCB) can be used for early-stage incentive, which should be large enough for bootstrap. On the other hand, to reduce the total supply will lower the diluting effect for current MCB holders, protecting their profit.
  2. In the new tokenomics, the issuance speed of MCB is correlated to the accumulated value captured by DAO. So as to say, 1 MCB can be issued for every 1 USD captured. There are two advantages of this method: To prevent a hyper issuance speed when the value capturing ability of DAO is relatively weak. As DAO captures more value, new MCB will be gradually issued. Furthermore, when the value capture ability of MCB improves, the issuance speed could potentially be increased for ecosystem incentive. Since the value capture ability of MCB is strong enough at this point, to increase the issuance speed to a certain extent will no longer have a huge impact on the token price, protecting holder’s profit.
  3. The minimum speed is 0.2 MCB per block (approximately 1300 per day). When the value capture ability of MCB is not strong enough, 1300 per day fulfills the need for the basic liquidity incentive. If we hypothesize that the annual cost of liquidity is 10%, the token price of MCB is $3, and 75% of the newly issued MCB is used for liquidity mining, then the available liquidity would be approximately $10M. In the AMM design of Mai3, $10M is a great start. Moreover, this speed corresponds to a 22% annual inflation rate, and this rate decreases gradually. This is an inflation rate at average level, which should be acceptable for MCB holders.
  4. The developers will obtain 25% of the newly issued MCB. While covering the fundamental rights of the developers is protected, this share serves as an incentive for developers to maintain and develop the MCDEX ecosystem. In additional, since MCDEX DAO has complete managing authority over MCB, MCDEX DAO is able to cancel this share through on-chain governance if the developers are incapable of maintaining and developing the MCDEX ecosystem in the future.

Execution of the Proposal

Once this proposal has been approved, the team will execute the following operations:

  1. Burn all MCB held by MCDEX Foundation (24,990,859 MCB)
  2. Burn all MCB locked in the team vesting smart contract (24,000,000 MCB)
  3. Deploy MCDEX DAO smart contract and transfer the MCB’s admin privileges to MCDEX DAO.
  4. The MCDEX DAO smart contract will limit the issuance speed and amount of MCB based on the new tokenomics. In addition, every new issuance requires on-chain governance by MCDEX DAO.

Quorum Requirements

Due to the fact that this proposal involves significant changes to the MCB tokenomics, we would like it to be fully discussed by the community members to reach maximum consensus. Therefore, the discussion of this proposal will last around 2 weeks, and the voting quorum is 1 million MCB (about 50% of the current supply).


Holders who have MCB, MCB/ETH LP Token or MCB/USDC LP Token please vote on Proposal 19: MCB New Tokenomics
Voting time: Jan. 22th 12:00 UTC ~ Jan. 29th 12:00 UTC


One page for proposed MCBnomics


I have no issues with the proposal. Glad the team is taking strong measures to protect current holders and using a sustainable approach to MCB issuance.

1 Like

I think that’s a great proposal. Good balance between preserving holders interest and incentivizing platform usage (ie: bootstrapping).

Did you consider keeping the same total supply (100M), and instead of burning the existing inventory, distribute it to holders? Only difference would be the price of 1 MCB I guess ?

Mathematically, it should be equivalent. But it may be easier for ordinary people to understand the burning and it is earlier to implement the burning than the distribution.

this picture is extremely hard to read, anyway to blow it up?

Please refer to our official tweet here:

In general, I feel that the proposal is sound and geared towards bootstrapping which is essential for the project at this early stage.

Some of my thoughts:

  1. Issuance speed is correlated to the accumulated value captured by DAO. What does this “accumulated value capture mean”. Does it mean a 0.02% transaction fees or something else?

    1.1) if its the fees, can the team release a rough projection of estimated volume and thus fee capture? With this we can estimate the MCB issue rate.

  2. Any cap and restrictions on LP emissions: To understand the emission rate, we should discuss on what is the optimal APY that MCB should aim for in its LM programs (to be able to sufficiently attract users.)

    Also, the MCB issue rate should not be correlated to the emission rate. (this was not discussed) In my opinion, it does not mean that we need to spend everything that the MCB issue. Perhaps some limits in the proposal will be nice.

  3. The developers will obtain 25% of new MCB issued: is there any lockup/ or vesting schedule for this allocation. I think it will be prudent to introduce a lock up (eg. 50% for 3months rolling) to prevent dumping of tokens. This can also give confidence to the community that the developer team has skin in the game. Perhaps new developers can also take this as a form of bonus to work towards.

Just some of my thoughts - happy to bounce it around.


Thanks for your deep thoughts!

  1. “Accumulated value captured” comes mainly from a 0.02% transaction fee (fee rate can be changed by MCDEX DAO) at the beginning. Besides, with more products are released, some products may capture value except the trading fee. If all value captured comes from the 0.02% transaction fee, to issue 8M MCB the DAO needs to capture $8M value, which means a cumulative $40B trading volume. If the platform’s daily trading volume is $100M, it will cost about 400 days to issue all the 8M MCB. The larger the daily trading volume, the faster the insurance speed. For example, if the daily trading volume is 1B, all the 8M MCB can be issued in 40 days. But, even in this case, it only means the DAO CAN issure all the 8M MCB, it is NOT A MUST. All the issues of MCB must be processed by the DAO governance. Thus, the “Accumulated value captured” limits the issue rate.

  2. LM should aim at some “Liquidity Cost”. The DAO should set target liquidity for the pool and the liquidity cost. For example, the target liquidity is $20M, the liquidity cost APY is 20% and MCB’s price is $5, then the daily MCB used for LM is $20M * 0.2 / 365 / 5 = 2192 MCB. The DAO should adjust the LM speed according to the price of MCB. This LM speed is not correlated to “Accumulated value captured”, but limited by “Accumulated value captured”. For example, even if the DAO can issue 5000MCB daily according to the “Accumulated value captured” cap, the DAO can only issue 2000MCB for LM daily. And the remain 3000 MCB quota can be used for other purposes in the future.

  3. There is no such vesting schedule for developers. Because the developers give up the old simple 4-years vesting plan and choose a more tough way. The new issue plan for the developers is something like a “performance commitment system”: if the trading volume can not increase hugely, the developers have little new MCB issued, the most of the 25% MCB can be considered as locked. The only way for the developers to obtain the 25% MCB is to put every effort, including recruiting new developers, to develop the platform and make the trading volume increase. If the developers succeed, they deserved the MCB.

I think the token redenomination make sense and am generally in favor of the proposal.

However, it creates too much burden and liability for the team to tie new issuances to “value capture” by the protocol. Yearn community had a very good debate on the performance-based incentive discussion recently.

Early value capture via fees probably hurt adoption more than the benefits it promise.

Also, on the funding front, if the whole team and development is funded by MCB only, though interests are well aligned, there is huge downside as well, i.e if we enter into a prolonged bear market, liquidity and market value of MCB could be negatively impacted, which could jeopardise team’s dev funding.

I think it’s prudent to set up a dev fund denominated in stablecoin (neutral to market conditions) instead of 100% funded by MCB, we can’t expect all future team members to be comfortable with MCB-only compensation, the proposal seems light on the future funding mechanism.

1 Like