• Infrastructure tokens — corresponding to Layer 1 networks (or adjacent parts of the computing stack, such as Layer 2) — have developed and widely understood economic models based on the supply and demand for block space. But for application tokens — smart contract protocols that deploy services on top of blockchains, which convey rights in “distributed businesses” — the economics are still being worked out.

• The business model of application tokens should be as expressive as the underlying software. To this end, we introduce Cashflows for Application Tokens — an approach that enables applications to create permissive, flexible models where users can choose how they are rewarded for the value they provide. This approach creates fees from legal activities in different jurisdictions, encouraging greater compliance. At the same time, it also maximizes the value accrued to the protocol while encouraging minimal governance.

• The principles we share here apply to all web3 applications — from decentralized finance (DeFi) to decentralized social applications, DePin networks, and everything in between.

Challenges with Token Models

Infrastructure tokens are subject to an embedded supply-demand dynamic: when demand increases, supply decreases, and the market adjusts accordingly. This native economic foundation for many infrastructure tokens was accelerated by Ethereum Improvement Proposal 1559 (EIP-1559), which implemented a base fee for all Ethereum transactions that would be burned. But despite sporadic attempts at buy-and-burn models, there is no model similar to EIP-1559 for application tokens.

Applications are users of blockspace, not providers, so they cannot rely on gas fees collected from others using their blockspace. That’s why they need to develop their own economic models.

There are some legal challenges here, too: the economic models of infrastructure tokens are less subject to legal risk due to the generic nature of typical blockchain transactions and the programmatic mechanisms they use. But for the economic models of application tokens, the applications involved may rely on the facilitation of regulated activities and may require the intermediation of governance token holders — which makes the economics more complex. A decentralized exchange that facilitates highly regulated derivatives trading in the United States is very different from Ethereum.

The combination of these intrinsic and extrinsic challenges means that application tokens require a different economic model. With this in mind, we propose a possible solution: a way to design protocols that compensate application token holders for services they provide while maximizing protocol revenue, incentivizing regulatory compliance, and incorporating minimal governance. Our goal is simple: give application tokens the same economic foundation that many infrastructure tokens already have, through cash flow.

Our solution focuses on solving three problems facing application tokens:

1. Challenges in governance

2. Challenges in value distribution

3. Challenges in regulated activities

1. Governance challenges

Application tokens often have governance rights, and the presence of a decentralized autonomous organization (DAO) may introduce uncertainty that infrastructure tokens do not have. For DAOs with significant operations in the United States, risks may arise if the DAO has control over protocol revenues or intermediaries and programmatically regulates the economic activities of the protocol. To avoid these risks, projects can eliminate DAO control by minimizing governance. For DAOs that are unable to do so, Wyoming’s new Decentralized Nonprofit Association (DUNA) provides a decentralized legal entity that may help mitigate these risks and comply with applicable tax laws.

2. Value Distribution Challenges

Applications must also be careful when designing mechanisms for distributing value to token holders. Combining voting and economic rights may raise concerns under U.S. securities laws, especially for mechanisms as simple and straightforward as pro rata distributions and token purchase and burn. These mechanisms look similar to dividends and stock buybacks, potentially undermining the argument that tokens should have a different regulatory framework than equity.

Projects should explore stakeholder capitalism — rewarding token holders for their contributions to a project in a way that benefits the project. Many projects encourage active participation, including operating a front end (Liquity), participating in the protocol (Goldfinch), and staking collateral as part of a security module (Aave). The design space here is very open, but a good starting point is to list all the stakeholders in the project, identify which behaviors should be encouraged from 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, although other schemes exist.

3. The Challenge of Regulated Activities

Applications that facilitate regulated activities must also be careful when designing token holder value accumulation mechanisms. If these mechanisms accrue value from unpermissioned front ends or APIs that do not comply with applicable law, token holders may profit from illegal activities.

Most proposed solutions to this problem focus on limiting value accumulation to activities that are permitted in the United States - for example, only activating protocol fees for liquidity pools involving certain assets. This constrains projects to the lowest common denominator of regulatory approaches and undermines the value proposition of global autonomous software protocols. This also directly undermines efforts to minimize governance. Determining which fee strategies are feasible from a regulatory compliance perspective is not the appropriate task for a DAO.

In an ideal world, projects should be able to charge fees in any jurisdiction where activity is permitted, without having to rely on a DAO to determine what is permitted. The solution is not to require regulatory compliance at the protocol level, but to ensure that protocol-generated fees are only passed on when the frontend or API that generates the fees complies with applicable laws and regulations in the location of the frontend. If the United States made it illegal to charge fees for a certain type of transaction facilitated by an application, even if that activity was perfectly permitted in every other country in the world, that could cause the economic value of the application's token to drop to zero. Flexibility in fee accumulation and allocation ultimately equals resilience in the face of regulatory pressure.

A Core Problem: Tracking Fees

Traceability of fees is critical to addressing the potential risks that non-compliant frontends can pose, while not introducing censorship risks or making the protocol permissionless. With traceability, applications can ensure that any fees accrued by token holders only come from legally compliant front ends in the jurisdiction where the token holder is located. If fees are not traceable, it will be impossible to isolate token holders from the value accrued 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, protocols can use a two-step application token staking system design.

Step 1: Identify the front end that generated the fee,

Step 2: Route the fees to different funding pools based on custom logic.

Mapping frontends

Fee traceability requires mapping a domain name to a pair of public/private keys. Without this mapping, a malicious front end could disguise transactions, pretending they came from an honest domain name. Cryptography allows us to "register" front ends that immutably record the mapping of domain names to public keys, proving that the domain name does control that public key and signs transactions with said private key. This allows us to attribute transactions, and therefore fees, to specific domain names.

Routing Fees

Once the source of fees is traceable, the protocol can decide how to distribute these fees, protecting token holders from receiving fees from illegal transactions while not adding to the decentralized governance burden of the DAO. To help illustrate this, imagine the range of possible designs for applying token staking, from providing a staking pool for each front end to providing a staking pool for all front ends.

In its simplest construction, each front end's fees can be routed to a specific front end staking module. By choosing which front ends to stake to, token holders will be able to decide which fees they receive and avoid any fees that could put token holders at legal risk. For example, token holders might choose to stake only modules associated with a front-end that has received all regulatory approvals in Europe. While this design sounds simple, it is actually quite complex. If there are 50 different front-ends, there could be 50 staking pools, and the dilution of fees could have an adverse effect on token value.

At the other end of the design spectrum, the fees of each front-end could be pooled together - but this defeats the purpose of fee traceability. If all fees were pooled together, it would be impossible to distinguish between fees from compliant and non-compliant front-ends - one bad apple would spoil the whole barrel. Token holders would be forced to choose between receiving no fees and staking 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 result in the system returning to the current suboptimal design where the DAO must assess where fees can be applied.

Solving Fee Traceability Issues with Sets

These complexities can be solved with sets. Consider a permissionless smart contract protocol application for which anyone can create a frontend, and any frontend can have its own staking module. Let’s call one of the frontends of this protocol application app.xyz.

App.xyz can follow specific compliance rules for the jurisdiction in which it is based. Application activity originating from app.xyz incurs protocol fees. App.xyz has its own staking module, and token holders can stake their tokens directly to that module, or to a setter who wants to individually pick the set of frontends they deem compliant. These token stakers will receive a yield in the form of fees for the set of frontends they stake. If a frontend generates $100 in fees, and there are 100 entities that have staked 1 token each, then each entity is entitled to $1. Setters may initially charge for their services. In the future, governments may require on-chain certification of compliant frontends in their jurisdictions to help protect consumers, with the side benefit of automating settling.

One ​​potential risk in this model is that non-compliant frontends may operate more cheaply due to the lack of administrative overhead of compliant frontends. They may also design models to recycle frontend fees back to traders to further incentivize their circumvention behavior. Two factors can mitigate this risk. First, most users actually expect frontends to comply with their local laws and regulations. This is especially true for large, regulated institutions. Second, governance can serve as a last resort or a "veto authority" for non-compliant frontends that repeatedly break the rules and jeopardize the viability of the application, thereby disincentivizing bad behavior.

Finally, all fees generated by transactions not initiated through the registration frontend will be deposited into a unified staking module, allowing the protocol to capture revenue generated by transactions generated by bots and others that directly interact with the protocol smart contracts.

From Theory to Practice: Putting the Method into Practice

Let's revisit the application token stack in more detail. To facilitate frontend staking, the protocol needs to establish a registration smart contract, and the frontend needs to register here.

1. Each frontend or API can add a special TXT record to the DNS records of its domain name, such as ENS DNS integration. This TXT record contains the public key of a pair of keys generated by the frontend, which once generated is called a certificate.

2. The frontend client can then call a register() function and prove that it owns its domain name. This information is stored mapping domains to certificate public keys and vice versa.

3. When a transaction is created via the client, it also signs the transaction payload with its certificate public key. This information is bundled together and passed to the application's smart contract.

4. The application's smart contract verifies the certificate, checking that it corresponds to the correct transaction subject and has been registered. If so, the transaction is processed. The fees generated by the transaction are then sent to a FeeCollector contract along with the domain information (from the registry).

5. FeeCollector allows set persons, users, validators, etc. to stake tokens directly on a domain or a group of domains. These contracts must keep track of the number of tokens staked on each domain, each address' share of that stake, and how long they have staked for. Popular liquidity mining implementations can serve as a starting point for this contract logic.

6. Users who have staked to the setter (or directly to the fee management contract itself) can then extract a corresponding share of the fees based on the number of application tokens staked to the name. This architecture may be similar to MetaMorpho/Morpho Blue.

This approach can be introduced without increasing the governance burden of the application DAO. In fact, governance responsibilities may be reduced because the fee switch can be permanently turned on for all transactions facilitated by the protocol, thereby removing DAO control over the protocol's economic model.

Additional Considerations Based on Application Type

While these principles apply broadly to application token economic models, there may be additional fee considerations depending on the type of application: applications built on Layer 1 or Layer 2, AppChains, and applications built using rollups.

Considerations for L1/L2 Applications

Applications on Layer 1 or Layer 2 blockchains deploy smart contracts directly on-chain. Fees are charged when users interact with the application’s smart contracts. This typically occurs through an easy-to-use front-end (such as an app or website) that acts as an interface between retail users and the underlying smart contracts. In this case, any fees will originate from that front-end. The example above about app.xyz illustrates how a fee system could work for a Layer 1 application.

Applications can either not rely on curators to screen frontend fees, or take a whitelist or blacklist approach to frontends that contribute to network fees. The intent here is still to ensure that token holders and the protocol as a whole do not profit or benefit from illegal activity and that jurisdiction-specific laws and regulations are followed.

In the whitelist approach, the application would publish a set of rules for frontends, create a registry of frontends that comply with the rules, issue certificates to frontends that opt-in, and require frontends to stake tokens to receive a portion of the application’s fees. If frontends do not comply with these rules, they will be slashed and have their certificates for fee contributions revoked.

In the blacklist approach, the application would not have to create any rules, but frontends launching the application would not be permissionless. Instead, the application would require any frontend to provide an opinion from a law firm proving that the frontend is compliant for their jurisdiction before enabling the frontend to use the application. Once the opinion is received, the application will issue a certificate for the fee contribution to the frontend, which will only be revoked if the application receives notice from a regulator that the frontend is non-compliant.

The fee path will reflect the examples provided in the previous sections.

Both approaches significantly increase the burden on decentralized governance, requiring the DAO to either establish and maintain a set of rules or evaluate legal opinions on compliance. In some cases, this may be acceptable, but in most cases, it will be preferable to outsource this compliance burden to the setter.

Application Chain Considerations

Application chains are blockchains for a specific application, and their validators work only for that application.

In return for their work, these validators receive payments. Unlike layer 1 blockchains, where validators are typically rewarded based on inflationary issuance of tokens, some application chains (such as dYdX) pass customer fees to validators.

Under this model, token holders must stake to validators in order to receive rewards. Validators become set stakers.

This work setup is different from that of a Tier 1 validator. Lisk validators solve specific transactions for specific applications. Due to this difference, Lisk validators may be subject to a higher degree of legal risk associated with the underlying activities they facilitate. Therefore, protocols should give validators the freedom to perform their work in accordance with 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 if its validator set is geographically dispersed.

Lisks that wish to take advantage of the benefits of fee traceability will be architected similarly to Tier 1 applications, right down to fee channels. But validators will be able to use frontend mappings to determine which frontends they wish to process transactions from. Fees for any given transaction will then flow to the active set of validators, while inactive validators who choose not to participate will miss out on those fees. From a fee perspective, validators perform the same functions as the staker module setters discussed above, and stakers on 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.

Application Rollup Notes

Rollups have their own blockspace but can inherit the security of another chain. Most rollups today have a single sequencer 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 application-specific and establish their sequencer as the sole validator, then the fees generated by transactions included by that sequencer can be distributed to stakers based on a set set of compliant frontends, or as a universal pool.

If rollups decentralize their set of sequencers, the sequencers become the de facto set stake module and the fee pipeline will reflect the state of the application chain. Sequencers replace validators in fee allocation, and each sequencer can decide for itself which frontends to accept fees from.

While there are many possible models for application tokens, providing curated staking pools is a path forward that helps solve the external challenges unique to applications. By recognizing the intrinsic and external challenges facing applications, founders can better design application token models for their projects from the ground up.

Acknowledgements: We would like to thank Porter Smith for getting this project off the ground.

The opinions expressed here are the personal opinions of individual AH Capital Management, L.L.C. ("a16z") personnel and not the opinions of a16z or its affiliates.