Economics Design

Welcome, subscribers! Thank you for subscribing. What will be shared today and the days ahead are alpha from our Economics Design's researchers. Please keep these mails secret and do not share them with any one because these alpha are confidential. Enjoy your reading.

Why do blockchain projects feel responsible for getting smart contracts audited, but omit getting an independent view on their token economies design?

Introduction

This article aims to analyze the necessity of Audit and Assurance to obtain an independent view on token economy resilience and robustness, its inherent ability to accommodate and adapt to changing market conditions and events. Token based systems have evolved over the past reaching $2.8 trillion in market capitalization before Terra crash and attracting more than $25b in VC funding in 2021. Despite large funding involved when talking about blockchain projects and their resilience people mostly think about smart contracts and hack as the main and only risk. There is now the whole culture of responsible projects who are doing smart-contract audits.

But there is another elephant in the room – token economy, that is equally important to get an independent view on and understand the risk, but usual response in crypto space – DYOR. Token economics – designs the model used to influence the use of tokens in the decentralized ecosystem, through incentive mechanisms and a defined token environment.  That is not something that is possible to cover with a smart contract audit, that by substance is an analysis of areas that could be manipulated by hackers, or examining code that goes against common convention.

Recent collapse of UST/LUNA, can become something similar to once Enron’s collapse, and trigger the next step in crypto maturing and be a call for a more responsible attitude by projects’ teams towards their investors and community not only on the tech and cybersecurity side but also getting independent view on the loopholes in token economy design.

What is audit in essence – according to Flint the audit function has evolved in response to a perceived need of individuals or groups in society who seek information or reassurance about the conduct or performance of others in which they have an acknowledged and legitimate interest. Flint argues that audit exists because interested individuals or groups are unable for one or more reasons to obtain for themselves the information or reassurance they require.

This research is not aimed to blame or criticize Terraform Labs, UST, LUNA or any people associated with the project but rather seed to readers minds how UST/LUNA crash could have been prevented in the first instance if token economy assurance (similar to smart contract audits), blockchain projects would have the insights and flexibility to fix their tokens in the design of the economic system.

Assurance mandating parties and Intended users

Before doing an assurance project, it is worthwhile to clearly distinguish between customers and interested parties, where former are parties paying for assurance and latter are parties representing stakeholders or potential stakeholders of the reporting project.

Mandating parties of assurance assignments:

Interested parties:

• Protocol & Community:

  • Protocol governance

  • Governance token holders

  • Non-governance token holders

• Investors:

  • Institutional Protocol investors

  • Institutional & Private token investors

• Financial intermediaries:

  • Asset managers

  • Financial advisors

• Regulatory & Statutory stakeholders:

  • Prudential & Conduct Regulators

  • Marketplace supervisors

Basic concepts and assumptions

Token economy is a fairly new and complex concept. Well-designed token economics, with rules and incentives, can define the long-term outcomes of token ecosystems. Poorly designed ecosystems can lead to the collapse of the ecosystem.

In order to eat a whale in chunks, we need to understand where to look and what to look for. In absence of industry wide assurance assertions applicable for token economies to test against, we suggest to use Economics Design Framework to slice token economics into four pillars:

What is the structural design of the ecosystem where the Protocol’s business case lives? What are the types of participants, which of those are human and which are algorithmic, what are the governance structures, what are the possible asset types, what are the possible transactions, and how are they executed in terms of on-chain tokens and other representations of value? What are the off-chain legal repercussions of transaction execution and token/asset exchanges? How are the types of participants affected by said repercussions? How is the Protocol governance aligning with them? 

What are the rules and incentives driving the behaviour of Protocol participants? How where they conceived and calibrated in the first place? Which of those are notionally well designed in alignment with the whitepaper, and which may have unintended consequences? What is the role of tokens in this normative framework? What are the risks and the corresponding control and stabilization mechanisms? Which of those are purely algorithmic and which are hybrid? What is their actual behavior as per transactional experience? What are the off-chain legal repercussions of insufficient or erroneous execution of the afore-mentioned control and stabilization mechanisms?

What is the constellation of native and foreign tokens allowed in the Protocol? How do they implement the intended transactions? How are they created (minted), how are they exchanged, how are they taken out of circulation (burned)? What are their valuation drivers, and how do they help the Protocol monetize its use case? What is the effective monetary policy for each of them, and how does it translate to actual token liquidity profiles? How is their supply controlled (inflation, deflation), what are their underlying property rights (e.g., for NFTs and other security tokens), and how robust are they described? Are there any other economic support structures (e.g., on-/off-chain reserves involved)? What are the mechanisms (e.g., smart contracts) affecting their use in Protocol transactions, and how sensitive are those in reference to individual token attributes? 

How are primary markets of individual Tokens implemented? What are the features and calibration parameters of the precise mathematical algorithms describing token and asset exchanges? What are the same for other mathematical algorithms governing the use of Tokens in material Protocol processes (staking, voting, investing, etc.)? How were these algorithms conceived and parameterized originally, what is their effective sensitivity to market regimes, what does the Protocol “sense” transitions among said regimes, and what are the processes in place to revisit and adapt algorithmic calibrations? How do these processes align with the other aspects of market, mechanism and token design?

Typical Assurance project at pre-launch stage can be focused on 2nd,3rd and 4th areas that give answers to questions: What is the token economy’s capacity to evolve its own structure to balance short-term effects and long-term stability? What is the token economy’s ability to grow, develop and ultimately sustain itself using just retained earnings? What is the token economy’s ability to optimally balance value flows and within its sub-systems. While Market design is representing a more abstract layer of economy frame, Mechanisms and Token Designs define transactional and asset levels that can be tested under different assumptions and scenarios and provide project team or other intended users an independent opinion on associated risks.

As the blockchain ecosystem is in its early stages and there are no common risks typology, assurance objectives for each and every project would depend on the responsibility of a project team or customer’s objectives, but conceptually can be aggregated to below groups.

Source: Economics Design

In order to get different level of assurance about risk level and quantify it, token economy assurance practitioners can apply range of techniques available from traditional audit:

• Data inspection – Inspection of public-domain data (both on- and off-chain) relevant to protocol design and operations

• Document inspection – Inspection of public-domain documents (exhibiting varying degrees of reliability, depending on their nature and provenance) relevant to protocol design and operations

• Observation – Reviewing protocol policies, procedures and design specifications applicable at a given point in time.

• Inquiry – Seeking targeted information from knowledgeable persons within the protocol community.

• Testing – Engaging with the protocol and testing mechanisms for actual alignment to design specifications.

• Reperformance – Engaging with the protocol and replicating the outcome of specific operational processes under controlled test conditions.

• Benchmarking – Comparing features and outcomes of mechanisms against known benchmarks.

• Analytical procedures – Inferring trends and performing scenario modeling to compare outcomes under different assumptions. This can range from sensitivity analysis to creating agent based models and further MonteCarlo simulations.

Report standards

Outcome of any assurance engagement needs to be a clear report, that should be understandable to customers and intended users and outline identified risks, severity of those risks and quantification where applicable.

As the minimum Assurance report should contain:

• Title

• Provider name

• Addressee

• Introduction about what report represents and how it should be read

• Scope of work

  • Timeline of doing assurance procedures

  • Sources of information used

  • Limitations of procedures

• Responsibilities

• List of risks, their severity level and quantification where applicable

Conclusions

It is inevitable that with the increase of adoption and more financial collapses in blockchain ecosystems, regulation will be mirroring what already exists in traditional markets to protect investors and reduce risk of having fraudulent or poorly designed token economies. Having said that, until there is no regulation in place and common standards, projects should already start the practice of taking responsibility in front of their stakeholders and seeking for an independent view on their economies, the same as they already do for smart contracts auditing. While on the other hand assurance practitioners need to start creating common standards for conducting such independent reviews.