For infrastructure tokens (such as L1 or L2), the economics 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 economics are still being refined.
The business model of an application token 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 legitimate activities that meet 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 of 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 utility tokens.
Applications are users of blockspace, not providers, so they cannot rely on collecting gas fees from others using their blockspace. That’s why they need to develop their own economic models.
There are also some legal challenges here: infrastructure token economic models are less susceptible to legal risks 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 the intermediary of governance 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, for example, 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 protocol design that compensates 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 solving three problems faced by application tokens:
Governance challenges
Value distribution challenge
Regulatory challenges
Governance Challenges
Utility tokens often have governance rights, and the presence of a DAO may create 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 for the protocol's economic activities and programs such activities. To avoid these risks, projects can eliminate the DAO's control rights by minimizing governance. For DAOs that cannot do this, Wyoming's newly formed Decentralized Unincorporated Nonprofit Association (DUNA) provides a decentralized legal entity that can help mitigate these risks and comply with applicable tax laws.
Value distribution challenge
Applications must carefully design mechanisms for distributing value to token holders. Combining voting and economic rights may 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 a way that benefits the project. Many projects are encouraging active participation, including operating the front end (Liquity), participating in the protocol (Goldfinch), and staking collateral as part of a security module (such as 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 could be profiting from illegal activity.
Most proposed solutions to this problem focus on limiting value addition to activities permitted in the U.S. — for example, charging protocol fees only on liquidity pools involving certain assets. This subjects projects to regulatory approaches and undermines the value proposition of a global autonomous software protocol. It also directly undermines efforts to minimize governance. It is not appropriate for a DAO to determine which fee strategy is effective from a regulatory compliance perspective.
Ideally, projects would be able to collect fees in any jurisdiction that permits such activity, without having to rely on a DAO to determine what is permissible. 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 generating 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 could drive the economic value of the application's token to zero, even if that activity is permitted in the rest of the world. Flexibility in the accumulation and distribution of fees ultimately equals resilience in the face of regulatory pressure.
A core issue: retroactive costs
Fee traceability is critical to addressing potential risks arising from non-compliant front ends without introducing censorship risk or permissionlessness of the protocol. With traceability, applications can ensure that any fees earned by token holders only come from legally compliant front ends in the token holder’s jurisdiction. If fees are untraceable, token holders cannot be protected from value accrued by non-compliant front ends, which could put token holders at risk.
To make fees traceable, the protocol can be designed in two steps:
Step 1: Identify which frontends are generating costs
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 forge transactions and pretend to be submitted from an honest domain. Cryptography allows a "registry" frontend to 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 thus fees) to a given domain.
Routing Fees
Once the source of fees is traceable, the protocol can determine how to distribute these fees in a way that shields token holders from collecting fees from illegitimate transactions and does not burden the decentralized governance of the DAO. To help illustrate this, we can consider various possible designs for applying token staking, from one staking pool per frontend to a single staking pool for all frontends.
In its simplest construction, each frontend’s fees 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, 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. Token holders would be forced to choose between receiving no fees and holding a stake in a pool where they would benefit from the illegal activities of non-compliant front ends in their jurisdiction — a choice that could deter many token holders from participating, or revert the system to its current suboptimal design where the DAO needs to assess where fees can be applied.
Solve the problem of expense traceability through management
These complexities can be solved with governance. Consider a permissionless smart contract protocol application with fees and tokens. Anyone can create a frontend for this application, and any frontend can have its own staking module. Let’s call one frontend for this protocol App.xyz.
App.xyz can follow specific compliance rules for the jurisdictions in which it operates. Application activity originating from app.xyz incurs protocol fees. App.xyz has its own staking module to which token holders can stake their tokens directly, or to curators who want to individually curate a basket of frontends they deem compliant. These token stakers will receive a payout in the form of fees from the group of frontends they stake. If a frontend generates $100 in fees, and 100 entities each stake 1 token, then each entity is entitled to $1. Curators can initially charge a service fee. 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 front-ends may have lower operating costs because they do not have the management overhead of compliant front-ends. They can also design models to recycle front-end fees to traders. Two factors can mitigate this risk. First, most users actually expect compliant front-ends to comply with local laws and regulations, especially for large regulated institutions. Second, for non-compliant front-ends that repeatedly violate the rules and jeopardize the viability of the application, governance can be used as a last resort or "veto power" to deter bad behavior.
Finally, all transaction fees not initiated through the registration frontend will be deposited into a single comprehensive 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 review the application token stack in detail. For a protocol to facilitate front-end staking, it needs to build a registration smart contract that the front-end needs to register.
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. The system will store a mapping of domains to certificate public keys and vice versa.
When a transaction is created through 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, 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 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 the curator (or directly with the fee management contract itself) can extract fees proportional to the amount of application tokens staked into the domain. The architecture may be similar to MetaMorpho / Morpho Blue.
Introducing this feature would not increase the governance burden on the application DAO. In fact, governance responsibilities could be reduced because the fee switch could be permanently turned on for all transactions facilitated by the protocol, removing any control the DAO had over the protocol’s economic model.
Additional considerations based on application type
While these principles apply broadly to application token economic models, there are other fees to consider depending on the type of application: applications built on L2 or L2+, application chains, and applications built using 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 happens through an easy-to-use front-end (such as an app or website) that acts as an interface between retail investors and the underlying smart contracts. In this case, any fees will originate from that front-end. The example above about app.xyz illustrates how the fee system can work for L1 applications.
In addition to relying on managers to filter front-end fees, applications can also adopt a whitelist or blacklist approach to filter front-ends that increase network fees. Again, the purpose here is to ensure that token holders and the entire protocol do not profit from illegal activities and comply with the laws and regulations of a specific jurisdiction.
In the 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 application fees. Frontends that do not comply with the rules will be slashed and their fee contribution certificates will be deleted.
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, which will only be removed if the application receives notification from the regulator that the frontend is non-compliant.
The 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 regarding compliance. In some cases, this may be acceptable, but in most cases, it is better to outsource this compliance burden to managers.
Application Chain
Lisk is an application-specific blockchain whose validators work only for that application.
In return for their work, these validators are paid. Unlike L1 blockchains where validators are typically rewarded through inflationary token issuance, some application chains (dYdX) pass on customer fees to validators.
In this model, token holders must stake to validators to receive rewards. Validators become curated staking modules.
This work set is distinct 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 without jeopardizing Lisk’s permissionlessness or exposing it to significant censorship risk, as long as its validator set is geographically dispersed.
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, 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 managers discussed above, and stakers on these validators can ensure that they are not receiving income from any illegal activity. Validators can also elect a manager 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 sorter. If these Rollups are application-specific and have their sorter as the sole validator, the fees generated by transactions included by that sorter can be distributed to stakers based on a select set of compliant frontends or as a general pool.
If Rollups decentralizes its set of sorters, sorters will become the de facto curated staking module, and the fee channels will be the same as the app chain. Sorters replace validators in 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 curated staking pools helps solve external challenges that are unique to applications. By recognizing the internal and external challenges that applications face, founders can better design an application token model for their project from the ground up.
Welcome to BlockBeats the BlockBeats official community:
Telegram subscription group: https://t.me/theblockbeats
Telegram group: https://t.me/BlockBeats_App
Official Twitter account: https://twitter.com/BlockBeatsAsia
