a16z: Starting from the token model challenge, how to design a new economic model to unlock cash flow and compliance

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

Original source: a16z

Original translation: Felix, PANews

For infrastructure tokens (such as L1 or L2), their economic models are well developed and understood, rooted in the supply and demand for block space. But for application tokens (smart contract protocols that deploy services on the blockchain), the economic model is still being perfected.

The business model of application tokens should be as expressive as its underlying software. To this end, this paper introduces the concept of cash flows for application tokens. This approach enables applications to create loose, flexible models where users can choose how to be rewarded for the value they provide. This approach can generate fees in legal activities that are subject to regulatory requirements in different jurisdictions, thereby encouraging greater compliance. In addition, the value of the protocol can be maximized while encouraging minimal governance.

The principles shared in this article apply to all Web3 applications — from DeFi to decentralized social apps, DePin networks, and everything in between.

Challenges with Token Models

Infrastructure tokens are subject to inherent supply and demand: as 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 burn mechanism for all Ethereum transactions. While there have been sporadic attempts at a buy and burn model, there is no model similar to EIP-1559 for application tokens.

Applications are users of blockspace, not providers, so they cannot rely on collecting gas fees from others using their blockspace. This is why they need to develop their own economic models.

There are some legal challenges here too: Infrastructure token economic models are less susceptible to legal risk due to the generic nature of typical blockchain transactions and the programming mechanisms they use. But for application token economic models, the applications involved may rely on regulatory activities and may require intermediaries to govern token holders - which makes the economics more complex. For example, a decentralized exchange that facilitates derivatives trading (a heavily regulated activity in the United States) is completely different from, say, Ethereum.

These internal and external challenges mean that application tokens require a different economic model. With this in mind, this article proposes a possible solution: an approach to designing protocols that compensate application token holders for their services while maximizing protocol revenue, incentivizing regulatory compliance, and incorporating governance minimization. The goal is simple: provide application tokens with the same economic foundations that many infrastructure tokens already have through cash flow.

The solution focuses on addressing three issues facing application tokens:

· Governance Challenges

· Value Allocation Challenges

· Regulatory Challenges

Governance Challenges

Application tokens often have governance rights, and the presence of a DAO may introduce uncertainties that infrastructure tokens do not face. For DAOs with significant operations in the United States, risks may arise if the DAO controls protocol revenue or acts as an intermediary and programmatic for the protocol's economic activities. To avoid these risks, projects can eliminate the DAO's control rights by minimizing governance. For DAOs that can’t do this, Wyoming’s newly formed Decentralized Unincorporated Nonprofit Association (DUNA) offers a decentralized legal entity that can help mitigate these risks and comply with applicable tax laws.

Value Distribution Challenges

Applications must carefully design mechanisms for distributing value to token holders. Combining voting and economic rights can raise concerns under U.S. securities laws, especially for simple and straightforward mechanisms like pro rata distributions and token buy-and-burns. These mechanisms look similar to dividends and stock buybacks, and may undermine the argument that tokens should be subject to a different regulatory framework than stocks.

Projects should explore stakeholder models — rewarding token holders for their contributions in ways that benefit the project. Many projects are incentivizing active participation, including operating a front end (Liquity), participating in the protocol (Goldfinch), and staking collateral as part of a security module (like 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, this article will assume a simple compensation model that rewards token holders for participating in governance.

Regulatory Challenges

Applications that facilitate regulated activities must also be careful when designing value-added mechanisms for token holders. If such mechanisms derive value from a front-end or API that does not comply with applicable law, token holders may profit from illegal activities.

Most solutions proposed to this problem focus on limiting value accretion to activities permitted in the United States — for example, charging protocol fees only on liquidity pools involving certain assets. This subjects projects to regulatory approaches and undermines the value proposition of globally autonomous software protocols. It also directly undermines efforts to minimize governance. It is not appropriate for a DAO to determine which fee strategies are effective from a regulatory compliance perspective.

Ideally, projects would be able to charge fees in any jurisdiction that permits such activities, without having to rely on a DAO to determine what is permitted. The solution is not to require compliance at the protocol level, but to ensure that fees generated by a protocol are only passed on if the front end or API that generates those fees complies with applicable laws and regulations in the region where the front end is located. If the United States prohibits charging fees for a certain type of transaction facilitated by an application, it may reduce the economic value of the application's token to zero, even if that activity is permitted in other countries around the world. Flexibility in fee accumulation and distribution ultimately equates to resilience in the face of regulatory pressure.

A Core Problem: Traceability of Fees

Traceability of fees is critical to addressing the potential risks arising from non-compliant front-ends without introducing censorship risk or permissioning of the protocol. With traceability, applications can ensure that any fees earned by token holders only come from legally compliant front-ends in the jurisdiction of the token holder. If fees are not traceable, token holders cannot be protected from the value accumulated by non-compliant front-ends, which may put token holders at risk.

To make fees traceable, the protocol can be designed in two steps:

· Step 1: Identify which front-ends generated the fees

· Step 2: Route fees to different pools based on custom logic

Mapping Frontends

Fee traceability requires a one-to-one mapping from domains to public/private key pairs. Without this mapping, a malicious frontend could forge transactions and pretend to be submitted from an honest domain. Cryptography allows a frontend to "register", immutably record the mapping of domain to public key, prove that the domain actually controls that public key, and sign transactions with said private key. This allows us to attribute transactions (and thus fees) to a given domain.

Routing Fees

Once the source of fees is traceable, the protocol can determine how to distribute those fees in a way that shields token holders from collecting fees from illegitimate transactions but also does not burden the DAO's decentralized governance. To help illustrate this, we can consider various possible designs for applying token staking, ranging from one staking pool per frontend to a single staking pool shared by all frontends.

In its simplest construction, fees from each frontend can be routed to a separate frontend-specific staking module. By choosing which frontend to stake to, token holders will be able to decide which fees they collect and avoid any fees that put them at legal risk. For example, token holders could stake only to modules associated with frontends that have 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 frontend could be pooled together — but this defeats the purpose of fee traceability. If all fees are pooled together, it would be impossible to distinguish between fees from compliant and non-compliant frontends. Token holders will be forced to choose between receiving no fees and holding a stake in a pool where they will benefit from illegal activity by non-compliant frontends in their jurisdictions — a choice that could deter many token holders from participating, or revert the system to its current suboptimal design where DAOs need to assess where fees can be applied.

Solving Fee Traceability Problems with Governance

These complexities can be solved with governance. Consider a permissionless smart contract protocol application with fees and tokens. Anyone can create a frontend for the application, and any frontend can have its own staking module. Call one frontend to this protocol App.xyz.

App.xyz can follow the specific compliance rules of the jurisdiction in which it is based. Activity on the application originating from app.xyz incurs protocol fees. App.xyz has its own staking module, where token holders can stake their tokens directly to it or to curators who want to individually curate a basket of frontends they deem compliant. These token stakers will receive revenue in the form of fees from the group of frontends they stake. If a frontend generates $100 in fees, and 100 entities stake 1 token each, then each entity is entitled to $1. Curators can initially charge a fee for their services. In the future, governments can prove on-chain that frontends in their jurisdiction are compliant to help protect consumers, with the added benefit of automating administration.

One potential risk of this model is that non-compliant frontends may have lower operating costs because they do not have the administrative overhead of compliant frontends. They can also design models to recycle frontend fees back to traders. Two factors can mitigate this risk. First, most users actually expect compliant frontends to comply with local laws and regulations, especially for large regulated institutions. Second, governance can be used as a last resort or "veto power" to deter bad behavior for non-compliant frontends that repeatedly break the rules and jeopardize the viability of the application.

Finally, all transaction fees not initiated through the registration frontend will be deposited into a single integrated staking module, enabling the protocol to generate revenue from bot-initiated transactions and other direct interactions with the protocol smart contracts.

From Theory to Implementation: Putting the Approach into Practice

Review the App Token Stack in detail. For a protocol to facilitate frontend staking, it needs to establish a registration smart contract that frontends need to register.

Each frontend or API can add a special TXT record to the DNS record of its domain, 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 frontend client can then call the register() function and prove that it owns its domain name. The system will store a mapping of domains to certificate public keys and vice versa.

When a transaction is created via the client, it also signs the transaction payload with its certificate public key. These are passed to the application's smart contract in the form of a bundle.

The application's smart contract verifies the certificate, checks if it corresponds to the correct tx body, 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 registry).

The FeeCollector allows managers, users, validators, etc. to stake tokens directly to a single domain or set of domains. These contracts must track the number of tokens staked on each domain, the staked share of each address, and the time of staking. Popular implementations of liquidity mining can be used as a starting point for this contract logic.

Those who have staked with managers (or directly with the fee management contract itself) can extract fees proportional to the number of application tokens staked to the domain. The architecture may be similar to MetaMorpho / Morpho Blue.

Introducing this feature will not increase the governance burden on application DAOs. In fact, governance responsibilities can be reduced because the fee switch can be permanently turned on for all transactions facilitated by the protocol, removing any control the DAO has over the protocol's economic model.

Additional considerations based on application type

While these principles apply broadly to application token economic models, there are additional fees to consider depending on the type of application: applications built on L2 or L2, application chains, and applications built with rollups.

L1/L2 Applications

Applications on L1/L2 blockchains deploy smart contracts directly on-chain. Fees are charged when users interact with the application’s smart contracts. Typically, this occurs through an easy-to-use frontend (such as an application or website) that acts as an interface between retail investors and the underlying smart contracts. In this case, any fees will originate from that frontend. The example above about app.xyz illustrates how the fee system works for L1 applications.

In addition to relying on curators to filter frontend fees, applications can also adopt a whitelist or blacklist approach to filter frontends that increase network fees. Again, the goal here is to ensure that token holders and the protocol as a whole do not profit from illegal activities and comply with the laws and regulations of a specific jurisdiction.

In a whitelist approach, the application will publish a set of rules for frontends, create a registry of frontends that comply with the rules, issue certificates to opt-in frontends, and require frontends to stake tokens to collect a portion of the application fees. Frontends that do not comply with the rules will be slashed and their fee contribution certificates will be removed.

In the blacklist approach, the application does not have to create any rules, but the launch of the application frontend is not permissionless. Instead, the application will require any frontend to provide an opinion from a law firm that the frontend complies with its jurisdiction before allowing the frontend to use the application. Once the opinion is received, the application will issue a fee contribution certificate to the frontend, and the certificate will only be removed if the application receives notice from the regulator that the frontend is non-compliant.

Fee channels are similar to the examples provided in the previous sections.

Both approaches significantly increase the burden of decentralized governance, requiring the DAO to 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 is better to outsource this compliance burden to managers.

Appchains

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

In return for their work, these validators receive compensation. Unlike L1 blockchains where validators are typically rewarded through inflationary issuance of tokens, some Lisks (dYdX) pass on client 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 L1 validators. Lisk validators process specific transactions from specific applications. Because of this difference, Lisk validators may bear a greater degree of legal risk related to the underlying activity they are facilitating. Therefore, protocols should grant validators the freedom to perform the work they can perform under the laws of their jurisdiction and of their own will. Importantly, this can be done as long as its validator set is geographically dispersed without jeopardizing Lisk’s permissionlessness or exposing it to significant censorship risk.

Application chains that wish to take advantage of fee traceability will be architected similarly to L1 applications. However validators will be able to use a frontend mapping to determine which frontend they wish to process transactions from. Fees for any given transaction will go to the active set of validators, 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 discussed above, and the 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.

Rollups

Rollups have their own blockspace but can inherit the security of another chain. Most Rollups today have a single collator. If these Rollups are application-specific and have their collator as the only validator, the fees generated by transactions included by that collator can be distributed to stakers based on a curated set of compliant frontends or as a general pool.

If Rollups decentralize their set of sorters, the sorters will become the de facto curated staking module and the fee channels will be the same as the application chain. Sorters replace validators for fee allocation, and each sorter can decide for itself which front end to accept fees from.

While there are many possible models for application tokens, providing a curated staking pool helps solve external challenges unique to applications. By recognizing the internal and external challenges facing applications, founders can better design application token models from scratch for their projects.

Original link

欢迎加入律动 BlockBeats 官方社群：

Telegram 订阅群：https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方账号：https://twitter.com/BlockBeatsAsia