Written by: a16z Crypto
Compiled by: Pzai , Foresight News
For infrastructure tokens — corresponding to layer 1 networks (or adjacent parts of the computing stack, such as layer 2) — the economic models are well developed and understood, and are rooted in the supply and demand of block space. But for protocol tokens (App Tokens) — smart contract agreements that deploy services on the blockchain and inherit rights in “distributed businesses” — the construction of economic models is still being explored.
The business model of a protocol token should be as expressive as its underlying software. To this end, we introduced cash flows for protocol tokens - an approach that enables protocols to create loose, flexible models where users can choose how to be rewarded based on the value they provide. This approach generates fees from compliance activities based on regulatory requirements in different jurisdictions, thereby encouraging greater compliance. It also maximizes the value generated by the protocol while encouraging minimal governance.
The principles we share here apply to all Web3 protocols — from DeFi to decentralized social, DePIN networks, and everywhere in between.
Challenges of Token Models
Infrastructure tokens are subject to intrinsic supply and demand: as demand increases, supply decreases, and the market adjusts accordingly. The native economics of many infrastructure tokens were accelerated by EIP-1559, which implemented a base fee burn for all Ethereum transactions. However, despite sporadic attempts at buy and burn models, there has been no comparable attempt to EIP-1559 for protocol tokens.
Protocols are users of blockspace, not providers, so they cannot rely on charging gas fees to others using their blockspace. That’s why they need to develop their own economic models.
There are also some legal challenges here: infrastructure token economics are less susceptible to legal risk due to the generic nature of typical blockchain transactions and the programmatic mechanisms they use. But for protocol token economics, the protocols involved may depend on the facilitation of compliance activities and may require the involvement of governance token holders, which makes its economics more complicated. Decentralized exchanges that facilitate derivatives trading are a highly regulated activity in the United States, very different from, for example, Ethereum.
The combination of these intrinsic and extrinsic challenges means that protocol tokens require a different economic model. With this in mind, we propose a possible solution: an approach to designing protocols that compensates protocol token holders for their services while maximizing protocol revenue, incentivizing regulatory compliance, and incorporating governance minimization. Our goal is simple: provide protocol tokens with the same economic foundation through cash flow that many infrastructure tokens already have.
Our solution focuses on addressing three issues facing protocol tokens related to: governance challenges, value distribution challenges, and compliance activity challenges.
Governance challenges
Protocol tokens often have governance rights, and the existence of a decentralized autonomous organization (DAO) may introduce uncertainties that infrastructure tokens do not face. For DAOs with a substantial presence in the U.S., risks may arise if the DAO controls protocol revenue or intervenes in the economic activities of the protocol and makes such activities programmatic. To avoid these risks, projects can eliminate DAO control by minimizing governance. For DAOs that cannot do this, Wyoming’s new Decentralized Unincorporated Nonprofit Association (DUNA) provides a decentralized legal entity that may help mitigate these risks and comply with applicable tax laws.
The challenge of value distribution
Protocols must also tread carefully when designing mechanisms for distributing value to token holders. Combining voting rights and economic rights can raise concerns under U.S. securities laws, especially for simple and straightforward mechanisms like pro rata distributions and token purchases and burns. These mechanisms can look similar to dividends and stock buybacks, and can undermine the argument that tokens should receive a different regulatory framework than stocks.
Instead, projects should explore stakeholder capitalism — rewarding token holders for their contributions to a project in a way that benefits the project. Many projects incentivize positive-sum participation, including front-end operations (Liquity), participating in the protocol (Goldfinch), and staking collateral as part of a security module (Aave). The design space here is open, but a good starting point is to map out all the stakeholders in the project, determine what behaviors should be encouraged for each of them, and decide what overall value the protocol can create through such incentives.
For simplicity, in this post we will assume a simple compensation model that rewards token holders for participating in governance, even if other schemes exist.
The challenges of compliance activities
Protocols that facilitate compliant activities must also be careful when designing value-accruing mechanisms for token holders. If such mechanisms generate value from a front end or API that does not operate in compliance with applicable law, token holders could be profiting from illegal activities.
Most proposed solutions to this problem focus on limiting value accumulation to activities permitted in the U.S. — for example, charging protocol fees only for liquidity pools involving certain assets. This subjects projects to the lowest common denominator of regulatory approaches and undermines the value proposition of globally autonomous software protocols. It also directly undermines efforts to minimize governance. Determining which fee-charging strategies are effective from a regulatory compliance perspective is not an appropriate task for a DAO.
In an ideal world, projects would be able to collect fees from activity in any jurisdiction that permits that activity, without having to rely on a DAO to determine what is permitted. The solution is not to require compliance with regulations at the protocol level, but to ensure that fees incurred by a protocol are only passed on if the front end or API that issues the fees complies with applicable laws and regulations in the location of the front end. If the United States made it illegal to charge fees for a certain type of transaction facilitated by a protocol, this could drive the economic value of the protocol’s tokens to zero, even if that activity is perfectly permitted in every other country in the world. Flexibility in how fees are accrued and distributed ultimately equals resilience in the face of regulatory pressure.
A core issue: cost tracing
Traceability of fees is critical to addressing potential risks arising from non-compliant front ends without introducing censorship risk or making the protocol permissionless. Through traceability, protocols can ensure that any fees incurred by token holders only come from legally compliant front ends in the jurisdiction where the token holder is located. If fees are untraceable, token holders cannot be attributed value generated from non-compliant front ends (i.e. fees collected by non-compliant front ends), which may put token holders at risk.
To make fees traceable, the protocol can be designed using a two-step protocol token staking system.
Step 1: Determine which front end is incurring charges
Step 2: Route fees to different pools based on custom logic
Mapping front end
Fee traceability requires a one-to-one mapping from domains to public/private key pairs. Without this mapping, a malicious frontend could spoof transactions and pretend they were submitted from an honest domain. Cryptography allows us to "register" frontends, immutably record the mapping of domains to public keys, prove that the domain actually controls that public key, and signs transactions with said private key. This allows us to attribute transactions, and therefore fees, to a given domain.
Route Fees
Once the source of fees is traceable, the protocol can determine how to distribute these fees in a way that protects token holders from illegitimate transaction fees, but also does not increase the decentralized governance burden of the DAO. To help illustrate this point, consider the range of possible designs for protocol token staking, ranging from one staking pool per front end to one staking pool for all front ends.
In its simplest structure, each frontend’s fees could be routed to a single, specific frontend staking module. By choosing which frontend to stake, a token holder would be able to decide which fees it is receiving and avoid any fees that put the token holder at legal risk. For example, a token holder could only stake modules associated with a frontend that has received all regulatory approvals in Europe. While this design sounds simple, it is actually quite complex. With 50 different frontends potentially having 50 staking pools, the dilution of fees could have an adverse effect on token value.
On the other hand, fees from each front end could be pooled together, but this defeats the purpose of fee traceability. If all fees were pooled together, there would be no way to distinguish between compliant and non-compliant front end fees — one bad apple can spoil the whole bunch. Token holders would be forced to choose between receiving no fees or holding a stake in a pool where they would benefit from the illegal activities of non-compliant front ends in their jurisdiction — an option that could deter many token holders from participating, or could revert the system to the current suboptimal design where the DAO must assess where fees can be collected.
Solving the expense traceability problem through curation
These complexities can be solved with curation. Consider a permissionless smart contract protocol that has fees and tokens. Anyone can create a frontend for the protocol, and any frontend can have its own staking module. Let's call a frontend for this protocol app.xyz.
App.xyz can follow specific compliance rules for the jurisdictions in which it operates. Protocol activity originating from app.xyz generates protocol fees. App.xyz has its own staking module, to which token holders can stake their tokens directly, or with curators who want to individually select a basket of frontends they deem compliant. These token stakers will receive a payout in the form of fees from the set of frontends they stake. If a frontend generates $100 in fees, and 100 entities stake 1 token each, each entity is entitled to $1. Curators can initially charge fees for their services. In the future, governments can perform on-chain attestations of the compliance of frontends in their jurisdiction to help protect consumers, with the added benefit of automation of curation.
One potential risk in this model is that non-compliant front ends may have lower operating costs because they lack the administrative overhead of compliant front ends. They can also design models to recycle front end fees to traders to further incentivize their workarounds. Two factors can mitigate this risk. First, most users actually expect compliant front ends to comply with local laws and regulations, and this is especially true for large regulated institutions. Second, for non-compliant front ends that repeatedly break the rules and jeopardize the viability of the protocol, governance can play an important role as a last resort or "veto power" to stop bad behavior.
Finally, all transaction fees not initiated through the registration frontend will be deposited into an all-encompassing staking module, allowing the protocol to generate revenue from bot-initiated trades and other direct interactions with the protocol’s smart contracts.
From theory to implementation: putting the approach into practice
Let’s dive back into the protocol token stack in more detail. For a protocol to facilitate staking on the front end, it would need to build a registry smart contract that the front end would need to register with.
Each frontend or API can add a special TXT record to its domain's DNS records, such as ENS DNS integration. This TXT record contains the public key of a key pair generated once by the frontend, called a certificate.
The front-end client can then call the register function and prove that it owns its domain name, storing the mapping of domain to certificate public key and vice versa.
When a transaction is created through the client, it also signs the transaction payload with its certificate public key. They are passed to the protocol's smart contract in the form of a bundle.
The protocol's smart contract verifies the certificate, checks if it corresponds to the correct transaction principal (frontend), and is registered. If so, the transaction is processed. The fees generated by the transaction are then sent to the FeeCollector contract along with the domain name (from the registry).
FeeCollector contracts allow curators, users, validators, and others to stake tokens directly to a domain or a group of domains. These contracts must track the amount of tokens staked on each domain, each address' share of that stake, and how long they have been staked. A general implementation of liquidity mining can serve as a starting point for this contract logic.
Users who stake with curators (or directly with the fee management contract itself) can extract a pro-rata share of fees based on the amount of protocol tokens staked with the domain. The architecture could be similar to Meta Morpho / Morpho Blue.
This mechanism can be introduced without adding any governance burden to the protocol’s DAO. In fact, governance liability can be reduced because we can permanently turn on the fee switch for all transactions facilitated by the protocol, removing any control the DAO has over the protocol’s economic model.
Additional considerations based on protocol type
While these principles apply broadly to protocol token economic models, there may be additional fee considerations depending on the type of protocol: protocols built on Layer 1 or Layer 2, application chains, and protocols built using Rollups.
L1/L2 protocol considerations
Protocols on a Layer 1 or Layer 2 blockchain deploy smart contracts directly on-chain. When users interact with the protocol's smart contracts, fees are charged. This usually happens through an easy-to-use front-end (such as a protocol or website) that acts as an interface between retail investors and the underlying smart contracts. In this case, any fees will come from this front-end. The example above about app.xyz illustrates how a fee system can work for a Layer 1 protocol.
Instead of relying on curators to filter front-end fees, protocols can also adopt a whitelist or blacklist approach to filter front-end fees. Again, the purpose here is to ensure that token holders and the entire protocol do not profit or benefit from illegal activities and comply with the laws and regulations of a specific jurisdiction. In the whitelist approach, the protocol will publish a set of rules for front-ends, create a registry for front-ends that follow the rules, issue certificates to front-ends that opt in, and require front-ends to stake tokens to receive a portion of the protocol fees. If the front-ends do not follow these rules, they will be slashed and their fee contribution certificates will be deleted.
In the blacklist approach, the protocol would not have to create any rules, but frontends launching the protocol would not be permissionless. Instead, the protocol would require any frontend to provide an opinion from a law firm certifying that the frontend is compliant with its jurisdiction before allowing the frontend to use the protocol. Once the opinion is received, the protocol would issue a certificate to the frontend for payment of a fee, which would only be removed if the protocol received notice from a regulator that the frontend was non-compliant.
Fee channels would mirror the examples provided in the previous sections. Both approaches significantly increase the burden of decentralized governance, requiring the DAO to either establish and maintain a set of rules or evaluate legal opinions regarding compliance. In some cases this may be acceptable, but in most cases it would be preferable to outsource this compliance burden to a curator.
Notes on application chains
Lisk is a protocol-specific blockchain whose validators work only on that protocol. In return for their work, these validators receive compensation. Unlike Layer 1 blockchains, where validators are typically rewarded through inflationary issuance of tokens, some Lisks (dYdX) pass on customer fees to validators.
In this model, token holders must stake with validators in order to receive rewards. Validators become curated staking modules. This work set is different from Layer 1 validators. Lisk validators settle specific transactions from specific protocols. Because of this difference, Lisk validators may bear a greater degree of legal risk in the underlying activities they facilitate. Therefore, protocols should give validators the freedom to perform the work they can perform according to the laws of their jurisdictions and their own comfort level. Importantly, this can be done without jeopardizing the permissionlessness of Lisk or exposing it to significant censorship risk, provided that its validator set is geographically decentralized.
The architecture of application chains that wish to take advantage of fee traceability will be similar to Layer 1 protocols until there are fee channels. But validators will be able to use frontend mappings to determine which frontends they wish to process transactions from. The fees for any given transaction will then go to the active set of validators, and inactive validators who choose not to participate will miss out on such fees. From a fee perspective, validators perform the same function as the staking module curators described above, and stakers of these validators can ensure that they are not receiving income from any illegal activity. Validators can also elect a curator to determine which frontends are compliant in each jurisdiction.
Notes on Protocol Rollups
Rollup s have their own block space but can inherit the security of another chain. Today, most Rollups have a sorter that is responsible for ordering and including transactions, although transactions can be submitted directly to Layer 1 through a process called "forced inclusion."
If these Rollups are protocol-specific and have their collator as the sole validator, then the fees generated by the transactions included by that collator can be distributed to stakers according to a curated set of compliant frontends or as a universal pool.
If Rollups decentralize their set of sorters, then sorters become the de facto curated staking module, and fee channels will reflect the revenue channels of the application chain. Sorters replace validators in fee allocation, and each sorter can decide for itself which frontend to accept fees from.
Summarize
While there are many possible models for protocol tokens, staking pools, if carefully curated, can help address protocol-specific external challenges. By recognizing the intrinsic and external challenges facing a protocol, founders can better design a protocol token model for their project from the ground up.
