Catapult + NIS1 Tokenomics Public Proposal

Now is a good time to share the latest document on Catapult and NIS1 tokenomics.

Japanese translation still in process. Until then, forgive my Google Translate version below.
今こそ、CatapultとNIS1 tokenomicsに関する最新のドキュメントを共有する良い機会です。 日本語の翻訳はまだ進行中です。それまでは、下記のGoogle翻訳バージョンをご容赦ください。

Tokenomics Proposal

The above proposal draws from many months of discussion and debate within various NEM teams and extensive economic modeling. I have been working on it sporadically for over a year and have examined many questions/ideas and worked with many collaborators on the NEM Foundation and NEM Ventures teams. Thanks to Dave H, Iain, Jeff M and other leaders from the migration committee.

Keep in mind that the items in this proposal are still negotiable and although the migration team and devs have discussed these, they are not nailed down. So we need to open up the discussion in order to move toward final decisions, and your contribution to the discussion is appreciated. Please put discussion in this forum thread, and comments for me can go directly in the Google doc.

Here are some highlights to get you oriented.

Catapult Economic System Modeling

We created a time-series economic simulation model for anyone to use. Please try it out! :eyes:

The goal is to understand multivariate interactions in different economic/market scenarios. It still crashes sometimes, and assumptions may not match reality, but it’s useful for understanding what could happen to token price, circulating supply, and so forth, if we change input variables. (This is the approach I used in econ system design for video games like Zynga Poker and Farmville.)

Supply Reduction

All discussions are leading to an increased circulating token supply, which can put uncontrollable downward pressure on nominal token price. To prevent perceptions of a downward spiral, we recommend reducing the maximum supply of XEM2 by a decimal place, which could increase the nominal token price by a factor x10. This means there would be a maximum of 899,999,999 XEM2, and every XEM holder would get 1 XEM2 for every 10 XEM they held during the snapshot. We understand this may be controversial, so keep in mind that it is still in discussion and your opinion will be a factor in the decision. Read the more detailed discussion is in the proposal and tell the team what you think.

Harvesting and Supernode Rewards

The most fundamental problems are creating medium/long-term sustainability for harvesters and node operators. Current XEM harvesting rewards are terrible and XEM supernode rewards draw from a fixed pool, which will be unsustainable when it runs dry.

Introducing Inflation (Up To a Fixed Cap)

To solve these items, we propose Catapult has a portion of its existing supply removed from existence and then added as an inflationary bonus to all harvesting rewards over 10 years. This does several things - it gives harvesters more exciting rates of return, it gives node operators more income (since they keep a portion of harvested rewards,) and it incentivizes transaction volume on the public chain.

Introducing Sealed Supernode Account

The above is still not a sustainable long-term reward for supernode operators. We propose to take 10% of XEM2 supply from Core Dev funds and put those tokens in a sealed account. This means these tokens can never be spent, but only used for harvesting. Those harvesting rewards are distributed to all supernode operators in perpetuity, providing a self-sustaining reward for node operators. This sealed account also has the benefit of decreasing circulating supply, which is good for price.

Allocation Vs. Swap

This proposal assumes a migration model in which users manually claim new Catapult tokens without affecting their XEM accounts (also called allocation.) This seems to be the model that has the most support, and diving into this debate has been done elsewhere. The alternative is a “swap” model where XEM are destroyed as Catapult tokens are claimed. If many in the community have strong opinions about this, we can revisit the allocation assumption and add a swap migration to this proposal.

About Me

For those who don’t know me, I’m an economist with a University of Washington MBA and a 20-year background in video game design. I built economic systems for Magic: the Gathering, Pokemon Online, Zynga Poker, among many others. I spent the last 2.5 years doing crypto economics consulting for a dozen clients building NEM applications for real estate, rewards points, and even national currency.

Note: As a policy, the NEM Foundation does not speculate about token price. Nothing in this document should be interpreted as a price prediction or speculation.

For Japanese Community:

上記の提案は、さまざまなNEMチームと広範な経済モデリング内での長年にわたる議論と議論に基づいています。私は1年以上散発的にそれに取り組んでおり、多くの質問/アイデアを検討しました NEM FoundationおよびNEM Venturesチームの多くの協力者と協力しました。 Dave H、Iain、Jeff M、および移行委員会の他のリーダーに感謝します。





目標は、さまざまな経済/市場シナリオでの多変量相互作用を理解することです。それでもクラッシュすることがあり、仮定が現実と一致しない可能性がありますが、入力変数を変更した場合、トークン価格、流通供給などに何が起こるかを理解するのに役立ちます。 (これは、Zynga PokerやFarmvilleなどのビデオゲームのeconシステム設計で使用したアプローチです。)

すべての議論は、循環トークン供給の増加につながり、名目トークン価格に制御不能な下方圧力をかける可能性があります。下降スパイラルの認識を防ぐために、XEM2の最大供給量を小数点以下で減らすことをお勧めします。これにより、名目トークン価格が10倍になる可能性があります。これは、最大899,999,999 XEM2があり、すべてのXEMホルダーがスナップショット中に保持した10 XEMごとに1 XEM2を取得することを意味します。 これは議論の余地があるかもしれないことを理解しています。それはまだ議論中であり、あなたの意見が決定の要因になることを覚えておいてください。提案にあるより詳細な議論を読んで、あなたの考えをチームに伝えてください。




上記のことは、スーパーノードオペレーターにとってはまだ持続可能な長期的な報酬ではありません。 XEM2の供給の10%をCore Devファンドから取得し、それらのトークンを封印されたアカウントに入れることを提案します。これは、これらのトークンを使用することはできず、収穫にのみ使用できることを意味します。これらの収穫報酬は、すべてのスーパーノードオペレーターに永続的に分配され、ノードオペレーターに自立した報酬を提供します。この封印されたアカウントには、循環供給を減らす利点もあります。



私を知らない人のために (, 私はワシントン大学のMBAを持ち、ビデオゲームデザインの20年の経歴を持つ経済学者です。マジックの経済システムを構築しました:The Gathering、Pokemon Online、Zynga Pokerなど。私は過去2.5年間、不動産、報酬ポイント、さらには国通貨向けのNEMアプリケーションを構築する多数のクライアントのために暗号経済コンサルティングを行ってきました。

注:ポリシーとして、NEM Foundationはトークン価格について推測していません。このドキュメントの内容は、価格の予測または推測として解釈されるべきではありません。


Firstly I would like to thank you for this proposal.

Now I have just few technical questions regarding “Introducing Sealed Supernode Account”:

  1. How do you plan to actually implement this accont?
    Who would hold delegated private key for that account and harvest with it on node? (who would be actually signing blocks)
    Isnt it huge security risk, when that private key will be stolen? (say after 100 years)

  2. what is definition of supernode? Who and how will check if node is supernode? How will supernode get payed? - do you plan to do this manually?

I was ok with having “manual” reward for nodes operated by core devs as TEMPORARY solution, not long term solution.

I also find NEMs definition of SUPERnode SUPERconfusing. Honesty, I saw people misunderstand this concept so many times I got tired of explaining it. Even long time members dont understand it.

We already have decentralized solution on catapult to support nodes, without any “supernodes”.
Supernodes should have ended with supernode fund being empty.
Why this then?
(i onw one supernode)

Maybe I am missing something here …

1 Like

Really solid proposal! :+1:

Although shifting the decimal point may seem controversial there are few risks and multiple benefits:

  1. It does not reduce the holdings of users. Each unit of CATXEM is just worth 10x a unit of XEM.

  2. It helps establish a baseline between XEM (silver) and CATXEM (gold).

  3. CATXEM would likely launch at a price point closer to $1 which has been a magic barrier for a long time that could become a resistance/support level.


When Newxem cost 1$ call me please

On this specific point, I can only agree if divisibility is increased. Fine to shift the decimal point, but allow a extra one or two (or ten) in divisibility.
There already situations with bitcoin where a half sat is needed.

1 Like

The option to decrease supply is contrary to all advice offered in the FAQ, which states nem1 tokens will be 1 for 1 with nem2.

I cant see any real benefit which justifies creating such confusion as to offer 1:10. If I have 134xem1, I receive 13xem2, who receieves the 0.4xem2?

The suggested supply change is a total distraction from the real issues at hand.

Decimal point. There is separability.

We can’t translate because we can’t copy the text.
Even if you translate in chrome, the layout will break, so you can’t read it even if you translate it.

Agree, I realise decimals exist and xem arent solely whole integers. However it may require an additional digit after the decimal point to cover the remainder lost by moving the point from 1 to 10 as Loinker suggested. eg 1.000 becomes 0.1000

The current separability is 6.
ex:) 1.000000
This is the limit indication of 9 billion + separability expression.

If it is 90 million, you can display up to 0.00000000. It becomes the same separability as BTC.

1 Like

Good work in developing a simulator, it must have taken quite some time.

The blockchain must balance its books on tx fees vs rewards for harvesting and nodes. We cant rely on sums of xem held to pay people for years to come, it needs to run independently on the tx fee. The current tx fee is the starting point, and may need adjusted, dependant on the likely total tx to be paid by users and share to harvestors and nodes. Its an enormously difficult task to define and will affect adoption of users and nodes, not sure if this is something that can be adapted as the network grows? Are the sums held there solely to support the early network with tx fee replenishing early losses paid to nodes etc, if so its potentially risky.

I really do not like the division by 10 of the total supply. Just keep it the same supply.
Also lowering the supernode requirements will put a big sell pressure on the market, I would keep it the same in the beginning.

1 Like

Lowering supernode requirements could also create incentive to buy and encourage more node operators to run nodes, this is not a bad thing.
Besides, this would allow existing supernode operators to simply run more nodes anyway. Does not mean there is any reason they should dump their tokens.

1 Like

The current 3 million XEM are certainly too great a hurdle. However, the proposed 20000 XEM are far too little.

It’s not that simple.
e.g.: SN´s (maybe NIS1+ CAT) = business = other tax classification, the same applies(possibly) with several nodes on CAT

Not everyone will end their SN on NIS1. The suggested amount is definitely too small.
Apart from that, we also need some quality, persistence at the SN.

1 Like

Hi @Brian_Tinsman,
I quickly scrolled through it and must say I’ve already seen some interesting ideas in the proposal.

At the same time I have some questions and comments but since the doc is copy protected I can’t copy/paste to quote. Any chance you could fix that ?

Why? It is still POS. The larger the stake you have, the greater your reward potential.

Lowering barrier to entry stimulates competition, and thus demand, thereby positively influencing the value of a stake.

1 Like

Why should the number of CatNEM units be reduced by a factor of 10 ?

Is the total number of pieces then also lowered or only the Airdrop speak I have
1000 XEM Nis1 (8.9 billion) = 100 CatXem Catapult (0.89 billion)

Yes I agree.
My suggestion would be to lower it by a third to begin with to say around 2M tokens, or halving it may be even better. That way a node operator could simply run 2 nodes with 1.5M tokens on each.
That way any node operator would not have surplus tokens that are no use for a node.

It should let you add comments to the document and let you save them without making changes to the actual document itself.

With POS, the greater your stake, the greater your opportunity for reward. It is only the subsidies that skews this.

1 Like

Remember that the 20000 CAT-XEM requirement would actually be the equivalent of 200000 NIS1-XEM due to the moving of the decimal point.

The above statement doesn’t mean I think the 20000 CAT-XEM is the right number either. Reducing the capital requirement by half or two thirds so its somewhere between 100,000 and 150,000 CAT-XEM I think is reasonable.