If you're coming to Polkadot from Ethereum – whether out of curiosity or necessity – you're probably wondering how they differ. This series will help you learn exactly that. Note that we assume basic knowledge of Ethereum 2.0.

In a previous part of this series, we explained how each of the two systems approaches sharding: the splitting of transaction processing workloads across many smaller connected chains.

A followup post explores the method of on-chain governance in each system, and introduces the concept of Treasury proposals – something we'll explore in more depth in this part.

On-chain treasury and token economics

An on-chain treasury is a wallet or smart contract owned by the protocol itself, the purpose of which is the funding of ecosystem development of that specific blockchain. This can be anything from financing development teams who build clients (nodes) to financing meetup or workshop expenses.


Ethereum has no on-chain treasury, so all ecosystem building and maintenance efforts are generally funded by either grants from key players in the ecosystem (Consensys, Ethereum Foundation) or through DAOs like MarketingDAO, MetaCartel, or MolochDAO. These DAOs are community governed and again mostly funded by either whales or the aforementioned key players.

In Ethereum, most of the gas spent on transactions is going to be burned. This creates deflationary pressure on the native currency, ether. Those using the network directly benefit all stakeholders as burned ether adds value to all ether.

Illustration of a Bunsen burner

The transactions being issued can contain a “tip” amount which acts as incentive for validators to prioritize certain transactions. The tip is given to the validator who includes the transaction in a block, so most validators would be interested in automatically grabbing the highest-tipped transactions first.

Practically speaking, Ethereum will have a smaller inflation than Bitcoin within a year from now. This deflationary pressure of low issuance in tandem with gas burning and various on-chain lockups of ether (DeFi, staking, DAI savings rate) will, in theory, produce enough upward pressure in price to secure the network with additional value.

Because Ethereum developers believe it unrealistic to commit to an issuance schedule for a long time into the future, Ethereum's issuance rate is dynamic. This means it depends both on social consensus of the developers of the protocol, and on the amount of ether staked in the system. Thus, the term minimum necessary issuance.


Polkadot also has the concept of transaction tips to encourage inclusion of their transaction.

A tip jar illustration

In Polkadot, transaction fees are split between the validators and the Treasury – an on-chain vault – in a ratio of 20%:80%. There is no burning.

This is so that the protocol can throttle its inflation and deflation more effectively. As slashing is inherently an unpredictable event, burning the stake during mass-outage events would cause sudden deflation through no fault of the validators – it was an infrastructure or protocol level failure. In those cases, Polkadot's researchers and developers believe it better to have the funds ready to pay for fixing things than to burn the funds and discourage network participation. The ratio of Treasury / Validator distribution can be changed through governance via a referendum.

As mentioned earlier, the Treasury is filled through transaction fees, through slashing events and something called reward inefficiency. It is an on-chain vault spendable through Treasury proposals which can be submitted by any DOT holder. These proposals are voted on by the Council and need a simple majority to pass. The voting period and the enactment period are both shorter than with regular referenda, so funding proposals can generally be discussed, voted on, and released fairly quickly.

Spending periods of the Treasury are 24 days in length. Any funds remaining in the Treasury after any such period suffer a partial burn, creating deflationary pressure on the native currency of the chain (KSM in Kusama, DOT in Polkadot).

Some examples of Treasury funding proposals include:

  • funding meetup or workshop expenses
  • funding tool development (grants)
  • funding developer teams
  • incentivizing Council members for doing a good job of governing the protocol
  • incentivizing the Technical Committee
  • burning to create deflation
  • funding marketing efforts akin to the recently launched MarketingDAO in Ethereum
  • and more…

Reward Inefficiency

We mentioned reward inefficiency before, so let's explain it. Polkadot / Kusama have a fixed issuance schedule at 10% per year. The reward for block production on every block is the same, but the distribution of that reward is not – it depends on how much KSM / DOT is actively staked in the system. Active stake is the amount of stake behind the validators who are in the active set – those doing the block production in the current era. Validators who are not in the active set don't count towards the active stake.

To get 100% of the block reward distributed to validators and their nominators, the amount of actively staked tokens has to be 50% of all tokens in existence. Anything more or less and the ratio between ideal staked percentage (50%) and actual staked percentage is applied to the reward distribution where the part of the block reward corresponding to the offset will be sent into the Treasury.

Submitting a spending proposal

The easiest way to submit a Treasury spend proposal is to visit the Polkadot JS UI at https://polkadot.js.org/apps/ and go to Treasury:

The treasury UI

Then, click the “Submit a spend proposal” button and enter the values, then submit the transaction. Remember that you need to have 5% of the amount you're requesting (minimum 1 KSM) in your spendable balance, otherwise the proposal submission will fail.

Submitting a proposal

That's it – once submitted, the proposal will enter the voting queue where the council can voice their opinion on it. If it gets majority support before expiring, it will pass and your deposit is returned. Otherwise, it is burned.

In the next part, we'll talk about consensus – the act of network participants automatically agreeing with each other on the current truth of the network's state.

If you missed the previous parts: