Knowledge base
HomeCapersWiki homeEssays
How Caper worksFoundationsRaising & marketsGovernanceEditorial policyHelpGeneral referenceDAOsDAO governance & toolingDecentralized scienceEconomics
MANIFESTO · CAPER / OWN THE GAME
An organization that raises and deploys its own capital. A market that never closes. Governance that can't be captured.
TermsPrivacy
Σ TVL:√901K|24H VOL:√0|CAPERS:13
LAUNCHGOVERN
  1. Wiki
  2. /
  3. Economics
  4. /
  5. Cryptoeconomics

PreviousCommons governance and collective actionNextCuration markets

Cryptoeconomics is the practice of building open networks, and applications on top of them, whose guarantees rest on cryptography and economic incentives together. Cryptography lets anyone check what has already happened: a digital signature proves who sent a message, and a chain of hashes proves the order in which records were added. Incentives written into the protocol make it pay to keep the system running and cost money to break it. Bitcoin is the founding case. Strangers who cannot identify one another agree on one ledger because anyone can verify the record, and because miners are paid in the network’s own coin for extending it while spending real money on hardware and electricity to compete for that pay. The investor Nick Tomaino argued that earlier peer-to-peer systems such as Kazaa and BitTorrent lacked this second half, incentives built into the protocol (Cryptoeconomics 101, 2017).

The field produces conditional guarantees: a property holds unless the people who break it are willing to lose a stated amount, and only while stated assumptions about who can coordinate with whom stay true. The security side of the field sets and prices those conditions. The design side uses the same tools to build applications. Its critics ask whether the assumptions describe how people behave.

Origin and definitions

The term entered use in the Ethereum developer community in 2014 and 2015. Jaya Klara Brekke and Wassim Alsindi, in a peer-reviewed glossary entry for the journal Internet Policy Review, attribute it to Vitalik Buterin, Ethereum’s co-founder, and date its earliest recorded public use to a 2015 talk by Vlad Zamfir, an Ethereum Foundation researcher, titled What is Cryptoeconomics. Zamfir described a formal discipline that studies the protocols governing production, distribution and consumption in a decentralised digital economy, and a practical science of designing those protocols (Brekke and Alsindi, 2021).

Buterin’s 2014 list of hard problems, kept on the Ethereum wiki, gave an early definition (Problems). It described cryptography as the study of communication among adversaries and cryptoeconomics as the next step: the study of economic interaction among adversaries, over network protocols. Tomaino’s 2017 primer repeats that definition almost word for word. The list named the domains the field covers: online trust and reputation systems, tokens and other digital assets, self-executing contracts, consensus algorithms, defences against spam and Sybil attacks (one actor posing as many), incentivised marketplaces for computing resources, and decentralised governance.

In a talk at the Berlin Ethereum Meetup on 20 February 2017, Buterin gave the formulation that later primers repeat: decide the properties a system should have, use cryptography to prove things about messages sent in the past, and use incentives defined inside the system to make the desired properties hold in the future (Introduction to Cryptoeconomics). The incentives come in two kinds. Tokens reward actors with units of the protocol’s own currency, as a block reward does. Privileges give actors decision rights they can earn from, as a miner earns fees by choosing which transactions enter its block. Either kind works as a reward when granted and as a penalty when reduced or withdrawn.

Zamfir, interviewed in October 2017, described cryptoeconomics as mechanism design added to the toolbox of cryptographers and distributed-systems engineers (Software Engineering Daily). The problems remain theirs, guarantees that a protocol keeps against adversaries; incentive design is the added tool. He also warned against calling every mechanism that happens to use cryptography cryptoeconomics. Mechanism design is the branch of economics that starts from a desired outcome and designs rules under which self-interested players produce it.

Josh Stark of the Toronto firm Ledger Labs wrote Making Sense of Cryptoeconomics (CoinDesk, August 2017) in answer to the venture investor Parker Thompson, who had dismissed the word as an excuse to ignore established economics. Stark agreed there is no crypto version of the whole of economics and placed the field elsewhere: an area of applied cryptography that takes incentives into account, closest to mechanism design, and concerned with building things. He sorted the systems being built into three kinds:

  • Consensus protocols, such as proof of work, where miners compete by spending computing power, and proof of stake, where validators lock up deposits of the network’s coin to take part.
  • Applications built on a blockchain, such as the prediction market Augur, which rewards holders of its REP token for reporting real-world outcomes truthfully so that bets can settle.
  • State channels, in which two parties exchange signed updates off-chain and settle on-chain only at the end or in a dispute, trusting the process because either can take the latest update to the chain at any time.

Stark also used the term to draw a line through the industry. A permissioned ledger that is centrally managed and does not use incentives to reach consensus is a different technology from Bitcoin or Ethereum even if it stores its data in blocks.

The security side: what an attack costs

Buterin’s 2014 list set out how cryptoeconomic security differs from the cryptographic kind. A cryptographer assumes, for example, that factoring large numbers is hard, an assumption close to absolute. A cryptoeconomist adds assumptions about people and resources: that no group holding more than a quarter of the computing power, or a quarter of the money, can collude; that some participants are altruists and some are erratic or opposed to the system, while most are roughly economically rational; that users join and leave at any time; and that many are anonymous, so bad reputations and debts are close to unenforceable. The list concluded that it will often be impossible to call a protocol secure or insecure outright. Designs are tuned to the empirical and social conditions they run in, and improved over time.

The 2017 talk supplied the vocabulary for pricing a guarantee. A cryptoeconomic security margin is an amount X such that either a guarantee holds, or whoever broke it ends up at least X poorer than they would otherwise have been. A cryptoeconomic proof is a signed message by which the signer certifies that either a statement is true or they lose X. Each margin is computed against a model of who can act together, and the talk named three (slides):

  • Uncoordinated choice: participants do not coordinate, have separate incentives, and each is smaller than some stated size.
  • Coordinated choice: every participant is controlled by one agent or coalition.
  • Bribing attacker: participants are uncoordinated, but an attacker can pay them on condition that they take certain actions. The attacker’s budget is what it must be willing to pay; its cost is what it pays if the attack succeeds.

The bribing model breaks simple designs. SchellingCoin is an oracle, a mechanism for bringing an outside fact such as a price onto a blockchain, that asks participants to vote and pays a reward P to everyone who votes with the majority. An attacker can promise P plus a small extra amount, ε, to anyone who votes for the false answer if the false answer loses. Voting false then pays more whatever the others do, so everyone switches, the false answer wins, and the attacker pays nothing. Proof-of-work mining, which pays only for blocks that end up on the main chain, has the same shape. The Schelling points page covers the oracle design, and Kleros is a dispute court built on the same game. Proof of stake raises the margin because the protocol can take deposits away as well as withhold rewards; staking and slashing covers how deployed chains set those penalties.

A margin is bounded by the value at stake. Reviewing the 2014 list in 2019, Buterin pointed out that oracles were being asked to direct transfers larger than the market value of their own token (Hard Problems in Cryptocurrency: Five Years Later). The token holders then have a reason to collude on a wrong answer: the oracle’s token may collapse, but they keep the proceeds of the transfer they misdirected.

Who attacks whom

Buterin’s The Triangle of Harm (July 2017) sorts attacks by who harms whom among three parties: a minority of block producers, the majority, and the protocol’s users. That gives four attacks:

  • a minority attacking users, by spending the same coins twice before the first payment is confirmed;
  • a minority attacking the majority, by threatening to revert any block that contains transactions it dislikes;
  • a majority attacking users, the classic 51% attack, in which a majority of producers rewrites recent history; and
  • a majority attacking the minority, by refusing every block produced outside its cartel.

The design goal Buterin set for Casper, Ethereum’s proof-of-stake research at the time, was to cap the ratio of harm to victims over cost to the attacker for all four. Proof of work leaves the two majority attacks undefended. A majority can always make its own chain the main one, so its attack costs it nothing, and because difficulty adjustment, the rule that keeps the block rate steady as mining power changes, holds total miner revenue fixed, what the victims lose the attacker gains. Proof of work pays blocks that agree with the consensus and nothing to blocks that do not. Casper instead penalises equivocation, signing two conflicting messages, so a majority that reverses a block the protocol has declared final pays for it, and the minority is left untouched.

Some faults cannot be assigned to anyone. If 30% of validators’ messages are missing from a proof-of-stake chain, the protocol cannot tell whether those validators were offline or the other 70% censored them. The only way to make both expensive is to penalise both sides, which lets either side grief the other: impose losses on it at some cost to itself. Buterin measures this with the griefing factor, the victims’ loss divided by the attacker’s. Wherever that ambiguity exists, no protocol can hold the griefing factor below 1 for both sides, because if one side can grief the other at a factor x, the other can grief back at 1/x.

Tomaino sorted threats by where they land: attacks on the cryptography, attacks on consensus such as the 51% attack, and social-engineering attacks that work on people rather than code. His test for a robust system was that it should cost more to destroy than it cost to build (Antifragile Cryptoeconomic Systems, 2017).

Coordination as a defence

Some security comes from coordination costs rather than penalties. In Engineering Security Through Coordination Problems (May 2017), Buterin argued that a mining majority that changed Bitcoin’s rules, for example to raise the block reward, would still have to get users to notice, agree to follow the new chain and install new software at the same time, because users’ own nodes reject blocks that break the rules those nodes enforce. The coordination problem that makes most reforms hard protects the users here. In a centralised payment service it protects the operator, since users would all have to leave at once. This kind of security depends on users being decentralised, not miners, and it lets designers choose which rules to leave to the block producers, such as a block size limit, and which to put under users’ validation, such as the block reward.

The same friction makes wanted upgrades hard. Cathy Barrera of the economics consultancy Prysm Group modelled a blockchain upgrade as a coordination game, a game with more than one stable outcome in which players do best by choosing the same one (Blockchain and Coordination Games: Failures and Focal Points, 2018). A community can stay on the old rules, move to the new ones, or split into two chains in a hard fork. Users value being on a large chain, so many would accept rules they mildly dislike rather than end up on a small chain with rules they prefer, and without knowing what others will do they can miscoordinate into a fork. Barrera’s remedy is a focal point: a governance vote that everyone expects the community to honour tells each user which outcome the others will choose.

The design side: primitives and token engineering

Once a chain supplies a unit of value and programmable conditions, the same methods can design applications. Jacob Horne’s The Emergence of Cryptoeconomic Primitives (Coinbase blog, March 2018) named the reusable pieces. A cryptoeconomic primitive is an incentive system built into a protocol and made possible by a token: a building block that coordinates people or machines toward a shared goal, sustains itself, and would fail or work worse without its token. His first examples came from curation markets: a token-curated registry decides whether an entry is in or out of a list, while a bonding curve, which prices a token by formula from its supply, scores relevance on a gradient. Prediction markets and stablecoins, tokens designed to hold a steady price, were the others. Horne expected the field to follow cryptographic primitives, where combining primitives became a specialism of its own.

Stephanie Hurder, also of Prysm Group, observed in 2018 that few projects demonstrate that the behaviour their platform is meant to induce is an equilibrium, a state in which no participant gains by changing course while the others keep theirs (Nash equilibrium and blockchain platforms). Her checklist has three steps: list every participant’s possible actions and full payoffs, counting reputation and gains from outside the platform rather than tokens alone; verify that the intended outcome is an equilibrium; and, where there are several equilibria, work out which one will be selected. Her example is a token-curated registry of good New York restaurants, which also has an equilibrium full of spam if a larger, less discerning audience would raise the token’s value more.

Barrera treated token rewards as pay for performance: a contract that pays for results and leaves the method to the worker (Economics of Tokenized Incentives 1: Intro to Pay for Performance, 2018). The form suits Bitcoin, which cannot specify or measure how much computing power each miner should contribute. It also carries the known costs of such contracts. The payer may not get what it wanted, and Barrera reads the consolidation of mining as a case of that; contributors demand more to accept the income risk, and smaller miners have left. Where the wanted contribution can be specified, paying for it directly is more efficient. The contract theory behind this is covered under the principal–agent problem.

Trent McConaghy, a founder of Ocean Protocol, proposed turning token design into an engineering discipline. He first presented the idea as Token Design as Optimization Design at the 9984 Blockchain Meetup in Berlin on 7 February 2018, then wrote it up in Towards a Practice of Token Engineering, which defines token engineering as the theory, practice and tools to analyse, design and verify tokenized ecosystems. His framing treats the block-reward function as an objective function and the network’s participants as agents searching for reward, like the population of an evolutionary algorithm. Nothing steers them from the top, so the system’s behaviour emerges from theirs. From optimisation and circuit design he borrowed a method, stating objectives and constraints and then testing designs with simulation and verification tools before deployment, and an ethic: he used the collapse of the Tacoma Narrows Bridge to argue that engineers answer for the systems they release.

BlockScience, an engineering firm Michael Zargham founded in autumn 2017, took the route of control engineering. Zargham, Zixuan Zhang and Victor Preciado modelled blockchain economies as dynamical systems, whose state changes over time by fixed rules, recovered Bitcoin’s key properties within that framework, and proposed control-engineering tools for building economic systems with provable properties (A State-Space Modeling Framework for Engineering Blockchain-Enabled Economic Systems, 2018). Token engineering later had its own public-goods funder, the Token Engineering Commons, which its members voted to close in 2025.

Cryptoeconomics and tokenomics

Tokenomics is the narrower term. Lisa JY Tan of the consultancy Economics Design treats it as a subset of cryptoeconomics: the economics of one project’s token and the ecosystem around it, leaving out the blockchain that secures it (Crypto Economics vs Tokenomics, 2018). Brekke and Alsindi describe the same split as layers. Layer 1 is the information security of a network protocol, the domain of proof of work and proof of stake. Layer 2 is the tokens, markets and mechanisms built on a platform. A layer-2 token can carry market value while adding nothing to the security of the chain beneath it, and it can raise the payoff from attacking that chain, which they connect to ledger forks, token launches and sudden market events in decentralised finance.

Stark’s essay offers a test at the token layer: ask whether the token is part of a cryptoeconomic mechanism the application needs. He treated the answer as a guide to the token’s utility and likely value. The economics of that value are covered under token valuation and token velocity.

Where the assumptions fail

Every guarantee above depends on a model of how people respond to incentives, and writers inside the field questioned those models early. Stark conceded that mechanism design has limits and, citing Nick Szabo, that a cryptoeconomic security guarantee rests partly on assumptions about how people will react to incentives in future.

Elad Verbin and Al Esmail of Berlin Innovation Ventures argued that the field had lent Bitcoin’s track record to designs it does not cover (Behavioral Crypto-Economics, 2018). Bitcoin’s assumptions are mild. It needs no ultra-rational users, only that no majority of mining power coordinates an attack, and its miners follow the incentive by leaving a computer running. Later systems such as Steemit, Augur and Numerai pay people for judgement (writing, predicting, building trading models) across large sets of possible actions. The less automatic the task and the larger the set of choices, they argued, the more exposed the design is to cognitive biases and choice overload; they cited the ultimatum game, in which people reject offers that game theory says they should accept. Deployed systems are also hard to repair, because changes need the consent of stakeholders who benefit from the flaws. They proposed putting behavioural economists and public-policy specialists on design teams.

Shermin Voshmgir of BlockchainHub Berlin argued in March 2017 that rules written in code can handle known knowns and known unknowns, but not unknown unknowns: events nobody anticipated when the code was written (Blockchain’s Problem with Unknown Unknowns). Her cases were the Ethereum hard fork that followed the attack on The DAO, an investment fund run by smart contract, and Bitcoin’s dispute over block size. When the rules have to change, token holders depend on the few experts who understand the code, which creates a new principal–agent problem. She also pointed out that Bitcoin’s incentives assumed miners acting alone and did not anticipate mining pools, coalitions that concentrated a network designed to be decentralised.

Brekke and Alsindi add two structural criticisms. Much of the field’s economics is conventional and formalist, leaning on game theory rather than the wider literature on money and markets. And its designs promise determinate outcomes from simple rules while producing complex and unintended behaviour once deployed, with every added incentive enlarging the attack surface. The argument that payments from outside a protocol can make deviation rational, where analysis inside the protocol cannot see them, is covered on the Schelling points page.

In 2019 Buterin reviewed his 2014 list of 16 problems and found the base-layer problems shrinking slowly and the application-layer problems only beginning. His new list included oracles for real-world data, identity systems that make holding two identities much harder than holding one (see Sybil resistance), reputation systems, and governance mechanisms better than the decentralised autonomous organisations (DAOs) then running.

How Caper approaches this

A caper sits on the design side of this page. It runs no consensus of its own: it is created with one transaction from a Radix wallet (getting started), and the Radix network secures its ledger, so the security questions above are Radix’s. A caper designs only the layer-2 part: one token, one treasury and one market for one organisation. Its answer to the equilibrium question is to let the market settle any proposal that would spend: the proposal has to win a ranked ballot and then hold the token’s price through a market window, so members who think it is wrong can defeat it by selling. Every trade runs against a pool that never disappears. Any member who has voted can leave at any time with a fair share of the treasury, and a holder who never voted can still sell (leaving a caper). The two phases are set out under proposals.

References

  1. Vitalik Buterin (2014). Problems (Hard Problems of Cryptocurrency). Ethereum wiki; archived copy of October 2017.
  2. Vitalik Buterin (2017). Introduction to Cryptoeconomics. Talk at the Berlin Ethereum Meetup, 20 February 2017; recording published by the Ethereum Foundation, slides archived.
  3. Vitalik Buterin (2017). Engineering Security Through Coordination Problems. vitalik.eth.limo, 8 May 2017.
  4. Vitalik Buterin (2017). The Triangle of Harm. vitalik.eth.limo, 16 July 2017.
  5. Vitalik Buterin (2019). Hard Problems in Cryptocurrency: Five Years Later. vitalik.eth.limo, 22 November 2019.
  6. Nick Tomaino (2017). Cryptoeconomics 101. The Control, 4 June 2017; archived copy.
  7. Nick Tomaino (2017). Antifragile Cryptoeconomic Systems. The Control, 20 June 2017; archived copy.
  8. Josh Stark (2017). Making Sense of Cryptoeconomics. CoinDesk, 19 August 2017; also published on the L4 blog.
  9. Vlad Zamfir (2017). Cryptoeconomics with Vlad Zamfir. Software Engineering Daily, episode 449, 28 October 2017.
  10. Jaya Klara Brekke and Wassim Zuhair Alsindi (2021). Cryptoeconomics. Internet Policy Review, 10(2).
  11. Cathy Barrera (2018). Blockchain and Coordination Games: Failures and Focal Points. Prysm Group, 27 June 2018.
  12. Jacob Horne (2018). The Emergence of Cryptoeconomic Primitives. The Coinbase Blog, March 2018.
  13. Stephanie Hurder (2018). Nash equilibrium and blockchain platforms: a token curated registry example. Prysm Group, 4 May 2018.
  14. Cathy Barrera (2018). Economics of Tokenized Incentives 1: Intro to Pay for Performance. Prysm Group, 18 December 2018.
  15. Trent McConaghy (2018). Token Design as Optimization Design. Talk at the 9984 Blockchain Meetup, Berlin, 7 February 2018; recording published by Ocean Protocol.
  16. Trent McConaghy (2018). Towards a Practice of Token Engineering. Ocean Protocol blog, 1 March 2018.
  17. Michael Zargham, Zixuan Zhang and Victor Preciado (2018). A State-Space Modeling Framework for Engineering Blockchain-Enabled Economic Systems. arXiv:1807.00955.
  18. Lisa JY Tan (2018). Crypto Economics vs Tokenomics. Economics Design.
  19. Elad Verbin and Al Esmail (2018). Behavioral Crypto-Economics: The Challenge and Promise of Blockchain Incentive Design. Berlin Innovation Ventures, 16 March 2018.
  20. Shermin Voshmgir (2017). Blockchain’s Problem with Unknown Unknowns. Token Kitchen (formerly BlockchainHub), 12 March 2017.

Further reading

  • Cryptoeconomics.Study – a free, open-source course on blockchain protocols, built by its community from 2018: animated lectures by Karl Floersch, coding assignments in which students build the protocols and attacks, and a draft textbook led by Jinglan Wang.
  • Crypto Canon – a reading list compiled at a16z by Sonal Chokshi, Chris Dixon, Denis Nazarov, Jesse Walden and Ali Yahya, from basics through cryptoeconomics, primitives and courses; material from 2018 and 2019.
  • Awesome Cryptoeconomics – a curated GitHub list begun in 2017 by Joaquim Pedro Antunes, grouping articles, videos, podcasts, whitepapers and post-mortems of hacks by topic.
  • Token Engineering reading resources – the Token Engineering community wiki’s chronological reading list for the discipline, last edited in 2019; archived copy.
  • BlockScience on Medium – research and analytics from the firm on engineered economic systems.
FieldBuilding open networks, and applications on them, whose guarantees rest on cryptography and on economic incentives written into the protocol
OriginEthereum developer community, 2014–15
Nearest disciplineMechanism design
Security modelsUncoordinated choice · coordinated choice · bribing attacker
Design sideCryptoeconomic primitives · token engineering
RelatedSchelling points · Staking and slashing · Principal–agent problem · Curation markets