X

Feedback + Support

Need Assistance? Notice something missing or broken? Let us know!

Press esc to dismiss

Show glossary Article List
Sort icon: direction descending

glossary

Definitions and terminology related to cryptoeconomics, blockchain and distributed ledger technology.
magnifying-glass

You've reached the end of the list

Proof of Importance (PoI)

Proof-of-Importance (PoI) is a blockchain consensus mechanism introduced by NEM. PoI reward users that actively transact on the network, building on proof-of-stake. With PoI, nodes need to ‘vest’ an amount of currency to be eligible to create blocks and are selected to create a block roughly in proportion to a score quantifying their 'contribution' to the network.

In proof-of-stake, this ‘score’ is one’s total vested amount, but, in PoI, this score includes more variables. The calculations borrows from the math of network clustering and page ranking. At a high level, the primary inputs are:

  • Net transfers: how much has been ‘spent’ in the past 30 days, with more recent transactions weighted more heavily.
  • Currency vested: how much currency was vested for purposes of creating blocks.
  • Cluster nodes: accounts that are part of interlinked clusters of activity are weighted slightly more heavily than outliers or hubs (which just link clusters but are not part of them).

The importance score is designed to address two primary criticisms of proof-of-stake. Some critics hold that proof-of-stake concentrates wealth while discouraging transactions, since users can simply hoard as many coins as possible and reap the rewards from block creation. The importance score means that hoarding will result in a lower score, while spreading XEM around will increase it; being a merchant pays better than having a hoard.

The second risk is a nothing-at-stake problem: because block creation costs no resources in a proof-of-stake consensus model, whenever there is a fork, someone can freely create blocks on both forks of the chain. Because PoI's 'importance score' is dynamic and based on network activity, supporting two forks would require supporting two patterns of transaction activity, making it more difficult to immediately create blocks on both networks.