a16z: How do protocol tokens generate cash flow?

Written by: a16z Crypto

Compiled by: Pzai, Foresight News

For infrastructure tokens—corresponding to Layer 1 networks (or adjacent parts of the compute stack, such as Layer 2)—their economic models have been well-developed and understood, rooted in the supply and demand of block space. However, for protocol tokens (App Tokens)—smart contract protocols that deploy services on top of the blockchain and inherit rights within "distributed businesses"—the construction of economic models is still being explored.

The business model of protocol tokens should be as expressive as their underlying software. To this end, we introduce the cash flow of protocol tokens—this approach allows protocols to create loose, flexible models where users can choose how to be rewarded based on the value they provide. This method generates fees from compliant activities according to regulatory requirements in different jurisdictions, thereby encouraging higher 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 anywhere in between.

Challenges Facing Token Models

Infrastructure tokens are influenced by intrinsic supply and demand: as demand increases, supply decreases, and the market adjusts accordingly. EIP-1559 accelerated the native economic foundation of many infrastructure tokens, implementing a base fee burn for all Ethereum transactions. However, despite sporadic attempts at buy-and-burn models, there have been no comparable attempts for protocol tokens.

Protocols are users of block space rather than providers, so they cannot rely on others using their block space to collect gas fees. This is why they need to develop their own economic models.

There are also legal challenges here: due to the generic nature of typical blockchain transactions and the programmatic mechanisms they use, the economic models of infrastructure tokens are less susceptible to legal risks. But for protocol token economic models, the protocols involved may depend on the facilitation of compliant activities and may require the involvement of governance token holders, complicating their economics. Decentralized exchanges facilitating derivatives trading, for example, are highly regulated activities in the U.S., which is starkly different from Ethereum.

The combination of these intrinsic and extrinsic challenges means that protocol tokens require different economic models. With this in mind, we propose a possible solution: a method of designing protocols that maximizes protocol revenue, incentivizes regulatory compliance, and incorporates governance minimization while compensating protocol token holders for their services. Our goal is simple: to provide protocol tokens with the same economic foundation that many infrastructure tokens already possess through cash flow.

Our solution focuses on addressing three issues faced by 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 decentralized autonomous organizations (DAOs) can introduce uncertainties that infrastructure tokens do not face. For DAOs with significant operations in the U.S., risks may arise if the DAO controls protocol revenue or intervenes in the economic activities of the protocol, making 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.

Value Distribution Challenges

Protocols must also be cautious when designing mechanisms to allocate value to token holders. Under U.S. securities law, combining voting rights and economic rights may raise concerns, especially for straightforward mechanisms like proportional distribution and token buy-and-burn. These mechanisms resemble dividends and stock buybacks and can undermine the argument that tokens should be subject to a different regulatory framework than stocks.

Instead, projects should explore stakeholder capitalism—rewarding token holders for their contributions to the project in ways that benefit the project. Many projects encourage positive engagement, including front-end operations (Liquity), participation in protocols (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 stakeholders in the project, determine what behaviors should be encouraged for each, and decide what overall value the protocol can create through these incentives.

For simplicity, in this article, we will assume a simple compensation model that rewards token holders participating in governance, even if other plans exist.

Compliance Activity Challenges

When designing value accumulation mechanisms for token holders, protocols facilitating compliant activities must also be cautious. If such mechanisms never generate value from a front-end or API operating in accordance with applicable laws, token holders may profit from illegal activities.

Most proposed solutions to this issue focus on limiting the value accumulation of activities permitted in the U.S.—for example, charging protocol fees only for liquidity pools involving certain assets. This confines projects to the lowest common denominator of regulatory approaches and undermines the value proposition of globally autonomous software protocols. It also directly undermines efforts for governance minimization. From a regulatory compliance perspective, determining which fee strategies are effective is not a suitable task for DAOs.

In an ideal world, projects would be able to charge fees from activities in any jurisdiction that allows such activities without relying on DAOs to determine what is permissible. The solution does not require compliance with regulations at the protocol level but ensures that fees generated by the protocol are only passed on when the front-end or API initiating the fees complies with the applicable laws and regulations of its location. If U.S. regulations deem it illegal to charge fees for a certain type of transaction facilitated by the protocol, this could reduce the economic value of the protocol token to zero, even if that activity is fully permitted in every other country in the world. The flexibility in fee accumulation and distribution ultimately equates to resilience in the face of regulatory pressure.

A Core Issue: Fee Traceability

The traceability of fees is crucial for addressing potential risks arising from non-compliant front-ends while not introducing censorship risks or requiring the protocol to obtain permission. Through traceability, protocols can ensure that any fees generated by token holders come solely from compliant front-ends in the jurisdictions where those token holders reside. If fees are untraceable, it becomes impossible to derive value from non-compliant front-ends (i.e., fees charged by non-compliant front-ends), which could expose token holders to risk.

To make fees traceable, protocols can employ a two-step protocol token staking system design.

• Step 1: Identify which front-end generates fees
• Step 2: Route fees to different pools based on custom logic

Mapping Front-Ends

Fee traceability requires a one-to-one mapping from domains to public/private key pairs. Without this mapping, malicious front-ends could spoof transactions and pretend they were submitted from honest domains. Cryptography allows us to "register" front-ends, immutably recording the mapping from domain to public key, proving that the domain indeed controls that public key, and signing transactions with the corresponding private key. This enables us to attribute transactions to a given domain, thereby attributing fees to that domain.

Routing Fees

Once the source of fees is traceable, protocols can determine how to allocate these fees, shielding token holders from illegal transaction fees while not increasing the decentralized governance burden on DAOs. To illustrate this, consider the potential design range of protocol token staking, ranging from a single staking pool for each front-end to a single staking pool for all front-ends.

In its simplest structure, fees from each front-end could be routed to a separate specific front-end staking module. By choosing which front-end to stake, token holders would be able to decide which fees they are receiving and avoid any fees that might place them at legal risk. For example, token holders could only stake modules associated with front-ends that have received all regulatory approvals in Europe. While this design sounds simple, it is quite complex in practice. Fifty different front-ends might have fifty staking pools, and the dilution of fees could adversely affect token value.

On the other hand, fees from each front-end could be pooled together, but this would contradict the purpose of fee traceability. If all fees are pooled together, it becomes impossible to distinguish between compliant and non-compliant front-end fees—a single bad apple could spoil the whole bunch. Token holders would be forced to choose between not receiving any fees or holding shares in a pool that benefits from illegal activities of non-compliant front-ends in their jurisdiction—this option could deter many token holders from participating or could revert the system back to the current suboptimal design where DAOs must assess where fees can be charged.

Addressing Fee Traceability Issues Through Curation

These complexities can be addressed through curation. Consider a permissionless smart contract protocol that has fees and tokens. Anyone can create a front-end for the protocol, and any front-end can have its own staking module. We call one front-end of this protocol app.xyz.

App.xyz can follow specific compliance rules for its jurisdiction. Protocol activities originating from app.xyz generate protocol fees. App.xyz has its own staking module, where token holders can directly stake their tokens or stake tokens to curators who wish to selectively choose a basket of front-ends they believe are compliant. These token stakers will earn fees from the front-ends they stake. If a front-end generates $100 in fees and 100 entities each stake 1 token, each entity is entitled to $1. Curators may initially charge fees for their services. In the future, governments could conduct on-chain proofs to demonstrate the compliance of front-ends within their jurisdictions to help protect consumers, with the added benefit of automating curation.

One potential risk in this model is that the operating costs of non-compliant front-ends may be lower because they lack the overhead of compliant front-ends. They may also design models that recapture front-end fees for traders to further incentivize their solutions. Two factors can mitigate this risk. First, most users actually want compliant front-ends to adhere to local laws and regulations, especially large regulated institutions. Second, governance can play an important role in preventing non-compliant front-ends that repeatedly violate rules and jeopardize the viability of the protocol, serving as a last resort or "veto" against bad actors.

Ultimately, all transaction fees initiated by non-registered front-ends will be deposited into a comprehensive staking module, allowing the protocol to derive revenue from bot-initiated transactions and other direct interactions with the protocol's smart contracts.

From Theory to Implementation: Putting the Approach into Practice

Let’s delve deeper into the protocol token stack. For protocols facilitating front-end staking, it needs to establish a registry smart contract that front-ends must register with.

1. Each front-end 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 front-end, referred to as a certificate.
2. The front-end client can then call the register function and prove it owns its domain, storing the mapping from domain to certificate public key and vice versa.
3. When transactions are created through the client, it will also sign the transaction payload with its certificate public key. These are passed to the protocol's smart contract in a bundled form.
4. The protocol's smart contract verifies the certificate, checks that it corresponds to the correct transaction entity (the front-end), and is registered. If so, it processes the transaction. The fees generated by the transaction are then sent to the FeeCollector contract along with the domain name (from the registrar).
5. The FeeCollector contract allows curators, users, validators, and others to directly stake tokens to a domain or a set of domains. These contracts must track the number of tokens staked on each domain, the share of each address in that stake, and the time they have been staked. General implementations of liquidity mining can serve as a starting point for this contract logic.
6. Users staking to curators (or directly to the fee management contract itself) can extract a proportionate share of fees based on the amount of protocol tokens staked to the domain. This architecture may resemble Meta Morpho / Morpho Blue.

This mechanism can be introduced without increasing the governance burden on the protocol DAO. In fact, governance responsibilities could be reduced because we can permanently open the fee switch for all transactions facilitated by the protocol, eliminating any control the DAO has over the protocol's economic model.

Additional Considerations Based on Protocol Type

While these principles broadly apply to protocol token economic models, there may be other fee considerations based on the type of protocol: Layer 1 or Layer 2-based protocols, application chains, and protocols built using Rollups.

Considerations for L1/L2 Protocols

Protocols on Layer 1 or Layer 2 blockchains deploy smart contracts directly on-chain. When users interact with the protocol's smart contracts, fees are charged. This typically occurs through a user-friendly front-end (such as a protocol or website) that acts as an interface between retail users and the underlying smart contracts. In this case, any fees will come from that front-end. The example above regarding app.xyz illustrates how the fee system applies to Layer 1 protocols.

Protocols can also filter front-end fees through whitelisting or blacklisting, rather than relying on curators to filter front-end fees. Similarly, the goal here is to ensure that token holders and the protocol as a whole do not profit or benefit from illegal activities and comply with the laws and regulations of specific jurisdictions. In a whitelisting approach, the protocol publishes a set of rules for front-ends, creating a registry for front-ends that follow the rules, issuing certificates to whitelisted front-ends, and requiring front-ends to stake tokens to receive a share of protocol fees. If a front-end does not comply with these rules, they will be penalized, and their fee contribution certificate will be revoked.

In a blacklisting approach, the protocol does not need to create any rules, but the front-ends initiating the protocol will not be permissionless. Instead, the protocol will require any front-end to provide a legal opinion from a law firm, proving that the front-end complies with its jurisdiction before allowing that front-end to use the protocol. Once the opinion is received, the protocol will issue a certificate to the front-end for fee payment, which will only be revoked if the protocol receives notice from regulators about the front-end's non-compliance.

The fee channels will reflect 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 assess legal opinions regarding compliance. In some cases, this may be acceptable, but in most cases, outsourcing this compliance burden to curators would be preferable.

Considerations for Application Chains

Application chains are blockchains specific to a protocol, with validators that are exclusive to that protocol. In return for their work, these validators receive compensation. Unlike Layer 1 blockchains, validators are typically rewarded through the inflation issuance of tokens, while some application chains (dYdX) pass customer fees on to validators.

In this model, token holders must stake to validators to receive rewards. Validators become carefully curated staking modules. This working set differs from Layer 1 validators. Application chain validators settle specific transactions from specific protocols. Due to this difference, application chain validators may bear a greater degree of legal risk in the underlying activities they facilitate. Therefore, protocols should empower validators to execute their work according to the laws of their jurisdictions and their own comfort levels. Importantly, this can be done without jeopardizing the permissionless nature of the application chain or exposing it to significant censorship risks, provided that its validator set is geographically decentralized.

The architecture of application chains hoping to leverage the advantages of fee traceability will resemble Layer 1 protocols until there are fee channels. However, validators will be able to use front-end mapping to determine which front-ends they wish to process transactions from. Then, the fees for any given transaction will go to the active validator set, while 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 mentioned above, ensuring that their stakers do not derive income from any illegal activities. Validators can also elect a curator to determine which front-ends are compliant in each jurisdiction.

Considerations for Protocol Rollups

Rollups have their own block space but can inherit the security of another chain. Nowadays, most Rollups have a sequencer responsible for ordering and including transactions, although transactions can be directly submitted to Layer 1 through a process called "forced inclusion."

If these Rollups are protocol-specific and have their sequencer as the sole validator, the fees generated from transactions included by that sequencer can be allocated to stakers based on a selected set of compliant front-ends or as a general pool.

If Rollups decentralize their sequencer set, then the sequencer becomes a de facto curated staking module, and the fee channels will reflect the revenue channels of application chains. The sequencer replaces validators in fee distribution, and each sequencer can decide from which front-ends to accept fees.

Conclusion

While there are many possible models for protocol tokens, carefully curated staking pools can help address the external challenges unique to protocols. By recognizing the intrinsic and external challenges faced by protocols, founders can better design protocol token models for their projects from the ground up.