A new financial model for app tokens: How to generate cash flows

For infrastructure tokens — which correspond to a Layer 1 network (or an adjacent part of the computing stack like Layer 2) — economic models are well-developed and understood, rooted in the supply and demand for blockspace. But for application tokens — smart contract protocols deploying services on top of  blockchains that relay rights in “distributed businesses” — economic models are still being solved.  

App token business models should be as expressive as their underlying software. To that end, we introduce cash flows for app tokens — an approach that enables applications to create permissive, flexible models and users to pick and choose how they are rewarded for the value they provide. This method creates fees from legitimate activities across different jurisdictions’ regulatory requirements, encouraging greater compliance. It also maximizes value accruing to the protocol while encouraging governance minimization. 

The principles we share here apply to all web3 applications — from DeFi to decentralized social apps, DePIN networks, and everywhere in between. 

Infrastructure tokens are subject to embedded supply and demand: As demand increases, supply decreases, and markets adjust accordingly. This native economic foundation for many infrastructure tokens was accelerated by Ethereum Improvement Proposal 1559 (EIP-1559), which implemented a base fee to be burned for all Ethereum transactions. But despite scattered attempts at buy-and-burn models, there is no parallel to EIP-1559 for application tokens. 

Applications are users, not providers, of block space, so they can’t rely on the collection of gas fees from others using their block space. This is why they need to develop their own economic models.

There are some legal challenges here as well: Infrastructure token economic models are more insulated from legal risk, because of the generic nature of typical blockchain transactions and the programmatic mechanisms they use. But for application token economic models, the applications involved may depend on the facilitation of regulated activity and may require intermediation by governance tokenholders — making the economics more complicated. A decentralized exchange that facilitates trading of derivatives, a highly regulated activity in the U.S., is radically different than, say, Ethereum.

The combination of these intrinsic and extrinsic challenges means that application tokens require a different economic model. With that in mind, we present one possible solution: a method for designing protocols that compensate app tokenholders for their services while maximizing protocol revenue, incentivizing regulatory compliance, and incorporating governance minimization. Our objective is simple: to give application tokens the same economic grounding, through cash flows, that many infrastructure tokens already have.

Our solution focuses on solving three problems application tokens face relating to:

1. Challenges with governance
2. Challenges with value distribution
3. Challenges with regulated activity

Application tokens typically have governance rights, and the presence of a Decentralized Autonomous Organization (DAO) can introduce uncertainty that infrastructure tokens don’t face. For DAOs with significant U.S. operations, risks may arise if the DAO has control over protocol revenue or intermediates the economic activity of the protocol and making such activity programmatic. To avoid these risks, projects can eliminate the control a DAO has by minimizing governance. For DAOs where that isn’t possible, 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. 

Applications must also exercise caution in designing the mechanism that distributes value to tokenholders. Combining voting and economic rights may raise concerns under U.S. securities laws, particularly with simple and direct mechanisms like pro rata distributions and token buy-and-burns. These mechanisms look similar to dividends and stock buybacks, and can undermine arguments that tokens deserve a different regulatory framework from equity. 

Projects should instead explore stakeholder capitalism — rewarding tokenholders for contributions to the project in a manner that benefits the project. Many projects have encouraged positive-sum participation, including operating a frontend (Liquity), participating in the protocol (Goldfinch), and pledging collateral as part of a safety module (Aave). The design space here is wide open, but a good place to start is mapping out all the stakeholders in a project, determining what behaviors should be encouraged from each of them, and deciding what overarching value the protocol can create via that incentivization. 

For simplicity’s sake, in this post we’ll assume a simple compensation model that rewards tokenholders for participation in governance, even though other schemes exist. 

Applications that facilitate regulated activity must also be careful when designing value accrual mechanisms for tokenholders. If such mechanisms accrue value from frontends or APIs that are not operated in compliance with applicable law, tokenholders could be profiting from illicit activity. 

Most proposed solutions to this problem have focused on limiting value accrual to activity that is permissible in the U.S. — for instance, only turning on protocol fees with respect to liquidity pools involving certain assets. This subjects projects to the lowest common denominator of regulatory approaches and undermines the value proposition of global autonomous software protocols. It also directly undermines efforts at governance minimization. Determining which fee strategy works from a regulatory compliance perspective is not an appropriate task for DAOs.  

In an ideal world, projects would be able to collect fees from activity in any jurisdiction where that activity is permissible, without having to rely on DAOs to determine what is permissible. The solution is not to require regulatory compliance at the protocol level but to ensure that protocol-generated fees are passed on only if the frontend or API that originated them is following applicable laws and regulations where the frontend is located. If the U.S. made it illegal to collect fees on a certain type of transaction an application facilitated, that could drive the economic value of that app’s token to zero, even if the activity were entirely permissible in every other country in the world. Flexibility when it comes to fee accrual and distribution ultimately equals resiliency in the face of regulatory pressures.

The traceability of fees is critical to solving the potential risks arising from non-compliant frontends without introducing censorship risk or making a protocol permissioned. With traceability, an application could ensure that any fees that accrue to tokenholders only come from frontends that are legally compliant in the jurisdiction of the tokenholder. If fees are untraceable, there would be no way to insulate tokenholders from accruing value from non-compliant frontends (i.e., fees collected by non-compliant frontends), which could expose tokenholders to risk. 

To make fees traceable, a protocol could use a two-step app-token staking system design. 

Step 1: identifying which frontend originated the fees, and

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

Fee traceability requires a one-to-one mapping from a domain to a public/private key pair. 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 recording the domain to public key mapping, proving the domain actually controls that public key, and signing transactions with said private key. This gives us the ability to attribute transactions, and thus fees, to a given domain. 

Once the source of fees is traceable, the protocol can determine how to distribute those fees in a manner that insulates tokenholders from receiving fees from illicit transactions, but that also doesn’t increase the decentralized governance burdens of the DAO. To help illustrate this point, think of the spectrum of possible designs for app-token staking, ranging from one staking pool for each frontend to one staking pool for all frontends. 

In its most simple construct, the fees of every frontend could be routed to a separate frontend-specific staking module. By selecting which frontends to stake to, a tokenholder would be able to decide which fees it was receiving and avoid any fees that place the tokenholder in legal jeopardy. For example, a tokenholder could only stake to the module associated with a frontend that has received all regulatory approvals in Europe. While this design sounds simple, it is actually quite complicated. There could be 50 staking pools for 50 different frontends, and the dilution of fees could be adverse to token value.

On the opposite end of the spectrum, fees from every front end could be pooled together — but this defeats the purpose of fee traceability. If all fees are pooled together, there’s no way to differentiate fees from compliant frontends versus non-compliant ones — one bad apple would spoil the barrel. Tokenholders would be forced to choose between not receiving any fees or stake in a pool where they would  benefit from the illegal activities of non-compliant frontends in their jurisdiction — an option that could dissuade many tokenholders from participating or could revert the system to current suboptimal designs, where a DAO has to assess where fees can be applied. 

These complexities could be resolved through curation. Consider a permissionless smart contract protocol application that has a fee and a token. Anyone can create a frontend for the application and any frontend can have its own staking module. Let’s call one frontend for this protocol app.xyz.

App.xyz could follow specific compliance rules for the jurisdiction it is located in. Application activity that originated from app.xyz generates protocol fees. App.xyz has its own staking module, and tokenholders can stake their tokens to that module directly or to a curator that wants to individually pick a basket of frontends that they deem compliant. These token stakers would earn yield in the form of the fees from the set of frontends they stake to. If a frontend generates $100 in fees, and 100 entities are each staking 1 token, then each entity is entitled to $1. Curators could initially charge a fee for their services. In the future, governments could make onchain attestations about frontends being compliant in their jurisdiction to help protect consumers, with the ancillary benefit being the automation of curation.

One potential risk in this model is that non-compliant frontends could be cheaper to operate because they lack the administrative overhead of compliant frontends. They could also devise models to recycle frontend fees to traders to further incentivize their workaround. Two factors mitigate this risk. First, most users actually want compliant frontends to follow their local laws and regulations. This applies especially to large, regulated institutions. Second, governance could play a vital role as a last resort or “veto authority” on non-compliant frontends that repeatedly break the rules and endanger the viability of the app, discouraging bad behavior.

Finally, all fees from transactions that are not initiated through a registered frontend would be deposited in a single catchall staking module, enabling the protocol to capture revenue from transactions initiated by bots and other direct interactions with the protocol’s smart contracts.

Let’s revisit the app token stack in greater detail. For a protocol to facilitate frontend staking, it would need to establish a registry smart contract that frontends would need to register with.

1. Each frontend or API can add a special TXT record to the DNS record of their domain like the ENS DNS integration. This TXT record contains the public key of a key pair that the frontend generates once, called the certificate.

1. The frontend client can then call a register() function and prove that it owns its domain name. A mapping of the domain to the certificate public key, and vice versa, are stored.
2. When transactions are created through the client, it also signs the transaction payload with its certificate public key. These are passed to the application’s smart contracts in a bundle.
3. The application’s smart contracts validates the certificate, checks that it corresponds to the right tx body, and has been registered. If yes, the transaction is processed. The fees generated by the transaction are then sent to a FeeCollector contract along with the domain name (from the registry).
4. The FeeCollector allows curators, users, validators, and others, to stake tokens directly to a domain or set of domains. These contracts must keep track of the amount of tokens staked on each domain, each address’ share of that stake, and the amount of time they have been staked for. Popular implementations of liquidity mining can be used as a starting point for this contract logic.
5. Users who have staked to curators (or directly to the Fee Management contracts themselves) can then withdraw the proportionate share of the fee according to the amount of the app token staked to the domain. The architecture could be similar to MetaMorpho/Morpho Blue.

This could be introduced without increasing the governance burden of an application’s DAO. In fact, the governance responsibilities could be reduced as the fee switch could be turned on permanently for all transactions facilitated by the protocol, thereby removing any control of the DAO over the economic model of the protocol.

While these principles apply broadly to application token economic models, there can be other fee considerations based on the type of application: apps built on Layer 1s or Layer 2s, app-chains, and apps built using rollups. 

Applications on Layer 1 or Layer 2 blockchains have smart contracts deployed directly onchain. Fees would be collected when users interact with the applications’ smart contracts. Usually that occurs through an easy-to-use frontend (like an app or website) that serves as an interface between a retail user and the underlying smart contracts. In that case, any fees would originate with that frontend. The example above about app.xyz illustrates how a fee system could work for a Layer 1 app. 

Instead of relying on curators to filter frontend fees, apps could also take either a whitelist or blacklist approach to frontends contributing to network fees. Again, the purpose here would be to ensure that tokenholders, and the protocol at large, are not profiting or benefitting from illicit activity and are following jurisdictional-specific laws and regulations.

In the whitelist approach, the app would publish a set of rules for frontends, create a registry of those frontends that follow the rules, issue a certificate to frontends who opt-in, and require frontends to stake tokens to receive a portion of app fees. If frontends don’t follow these rules, they would be slashed, and their certificate for fee contributions would be removed.

In the blacklist approach, apps wouldn’t have to create any rules, but the launching of a frontend for the application would not be permissionless. Instead, the app would require that any frontend deliver an opinion from a law firm that the frontend is in compliance with its jurisdiction prior to enabling that frontend to use the app. Once the opinion is received, the app would issue a certificate to the frontend for fee contributions that would only be removed if the app receives notice from a regulator that the frontend is not in compliance.

The fee pipeline would mirror the examples provided in the preceding sections.

Both of these approaches significantly increase the burden of decentralized governance, requiring DAOs to either establish and maintain a set of rules or assess legal opinions about compliance. In some instances, this may be acceptable, but in most cases outsourcing this compliance burden to a curator would be preferable.

Appchains are application-specific blockchains with validators that work only for that application. 

In return for their work, those validators receive payment. Unlike Layer 1 blockchains where validators are often rewarded through the inflationary issuance of tokens, some appchains (dYdX) instead pass on customer fees to validators. 

In this model, tokenholders must stake to validators to receive rewards. The validators become the curated staking modules.

This work set is different from a Layer 1 validator. Appchain validators settle specific transactions from a specific application. Because of this difference, appchain validators could bear a greater degree of legal risk regarding the underlying activity they are facilitating. As a result, protocols should grant validators the freedom to perform the work they can perform according to the laws of their jurisdiction and their own comfort level. Importantly, this can be done without jeopardizing the permissionlessness of the appchain or subjecting it to significant censorship risk provided that its validator set is geographically decentralized.

The architecture for appchains wishing to take advantage of the benefits of fee traceability would be similar to Layer 1 applications up until the fee pipeline. But validators would be able to use frontend mapping to determine which frontends they wish to process transactions from. The fees for any given transaction would then go to the active validator set, with inactive validators who chose not to participate missing out on such fees. From a fee perspective, the validator performs the same function as the staking module curators discussed above and stakers to those validators could ensure they are not receiving revenue from any illicit activity. Validators could also elect a curator to determine which frontends are compliant per jurisdiction.

Rollups have their own blockspace but can inherit the security of another chain. Most rollups today have a single sequencer that is responsible for sequencing and including transactions, although transactions can be submitted directly to the Layer 1 through a process called “forced-inclusion.” 

If these rollups are application-specific and enshrine their sequencer as the sole validator, the fees generated from transactions included by that sequencer can be dispersed to stakers based on the curated set of compliant frontends or as a general pool.

If rollups decentralize their sequencer set, the sequencers become the de facto curated staking modules and the fee pipeline would mirror that of appchains. Sequencers replace validators for fee distribution, and each sequencer can make its own decisions on which frontends to accept fees from.

***

While there are many possible models for application tokens, providing curated staking pools is one path forward that helps thread a needle on the extrinsic challenges unique to applications. By recognizing the intrinsic and extrinsic challenges facing apps, founders can better design app token models from the ground up for their project.

Acknowledgments: We’d like to thank Porter Smith for starting this project. 

The views expressed here are those of the individual AH Capital Management, L.L.C. (“a16z”) personnel quoted and are not the views of a16z or its affiliates. Certain information contained in here has been obtained from third-party sources, including from portfolio companies of funds managed by a16z. While taken from sources believed to be reliable, a16z has not independently verified such information and makes no representations about the current or enduring accuracy of the information or its appropriateness for a given situation. In addition, this content may include third-party advertisements; a16z has not reviewed such advertisements and does not endorse any advertising content contained therein.

This content is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisers as to those matters. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. Furthermore, this content is not directed at nor intended for use by any investors or prospective investors, and may not under any circumstances be relied upon when making a decision to invest in any fund managed by a16z. (An offering to invest in an a16z fund will be made only by the private placement memorandum, subscription agreement, and other relevant documentation of any such fund and should be read in their entirety.) Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by a16z, and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments made by funds managed by Andreessen Horowitz (excluding investments for which the issuer has not provided permission for a16z to disclose publicly as well as unannounced investments in publicly traded digital assets) is available at https://a16z.com/investment-list/.

Charts and graphs provided within are for informational purposes solely and should not be relied upon when making any investment decision. Past performance is not indicative of future results. The content speaks only as of the date indicated. Any projections, estimates, forecasts, targets, prospects, and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others. Please see https://a16z.com/disclosures/ for additional important information