NEAR

| Flow 1. Fee split for dApp use

‍
How do NEAR developers and validators both benefit from demand for dApps?

• Users interact with a dApp deployed by a developer. There is a contract interaction and the user pays a gas fee.
  
  
• 30% of the gas fee is distributed back to the contract, while 70% is burned. An increase in demand for dApps directly benefits the developers through this kickback, and directly benefits all token holders through the token burn.
  
  ‍

| Flow 2. Compensation for computation

Validators, who service the network’s computations and security, do not directly benefit from an increase in demand beyond the burn component. They would benefit from any resulting increase in token price, as they earn a share of the fixed token inflation (4.5% of Supply).

As the user flow illustrates, validators are compensated for network computations and security in part through the issuance of new tokens (90% of the 5% perpetual issuance goes to block rewards) and, inclusive with all token holders,  in part through the burning portion of the transaction fee (70% burned). These two sources of validator rewards are somewhat at odds, as data on token supply and utility (summarized below) helps contextualize, as the rate of new token issuance coupled with low transaction fees means NEAR requires a high demand for transactions to become deflationary. 

Token Utility Findings

Token utility classifications  answer the question ‘what can the asset owner do with this asset’, and focus on benefits to end-users rather than benefits to the protocol. All classifications are based on a token utility typology of discrete utilities developed from corollaries from non-crypto environments. Classifications are based on implemented vs roadmap functionality, are non-exclusive, and are relative to the time of publication. 

NEAR has three forms of utility:

One familiar with NEAR might wonder if governance utility was omitted from these findings, or not a consideration in classifying utility. Governance utility is a form classified, and the lack of governance utility reported here is rather a matter of current implementation.

Though NEAR has a governance forum, that forum  is currently purely for signaling. Assets accrue to the treasury from inflation, yet the treasury is controlled entirely by the NEAR Foundation. This is to be eventually replaced by a more decentralized model, as to be partly designed by the newly formed NEAR Digital Collective (NDC), which itself will have a community representative. Should the NEAR token come to play a more meaningful role in allocating treasury funds, it would be  re-classified as having governance utility.

Following conventions used in the design and maintenance of virtual economies, token supply is explained via three questions. How assets were issued, how much of it, and under what conditions is answered via initial distribution findings. How the asset supply expands over time is answered via source findings. How liquid asset supply shrinks over time, either through usage and burn, is answered via sinks findings, with the hard/soft distinction indicating which types of sinks temporarily lock up supply v. which permanently reduce it.

These supply findings suggest that NEAR would require a very high number of transactions per day to become deflationary – roughly 17k TPS at base gas prices, more than it can technically handle at its current state. Assuming ~500k transactions per day at the time of writing, the burn mechanism as a whole is currently largely negligible.

Having reviewed NEAR’s methods for incentivizing dApp development, the tradeoffs that stood out in NEAR’s approach were as follows: 

1. Treasury and Grants. Managing an effective grants program can be challenging: administrators frequently need to estimate how feasible proposals are, how capable is the team executing them, whether funds requested are reasonable for work to be performed, and likewise need to monitor progress and hold fundees accountable. Involving a broader community may lessen or increase this challenge: community brings its own perspective on which projects are most interesting and value adding, which may or may not be informed by the work of fully assessing proposal materials.
   
   While NEAR’s choice to support grants is ‘messy’ in this regard, incentivizing development through grants in addition to fee splitting has some advantages that would be lost if NEAR only supported fee splitting. Grants provide promising dApp projects capital up front, enabling the development of dApps that might not otherwise get built. Similarly, communities would ultimately have less input on which dApps should be developed if NEAR’s incentives were purely usage based.
   
   
2. Fee-Splitting. NEAR’s fee-splitting mechanism serves a similar purpose of incentivizing dApp development, but without the same level of administrative challenges as a grants program. Whereas ‘promising’ or ‘value-adding’ are, for grants, defined largely through administrators’ conceptions, fee-splitting operationalizes success in terms of dApp transaction volume. In some respects, this supports  a level-playing field for developers competing for funds — developers not interested in persuading grant administrators (who may be biased) that their dApp is worth funding still have the option of build a dApp that generates demand and receive 30% of the gas fee used to call it.
   
   
3. Stake Farming. Stake offers yet another way for developers to finance their projects. Projects that distribute native tokens to validators, often at a premium, in exchange for a share of the NEAR that the validators would have otherwise earned, are in essence borrowing from validator's the reward fee in exchange for a future token they would develop.
   
   
4. Guilds. Guilds can give developers, among other communities,  additional access to protocol resources and mentorship, while retaining some accountability to the NEAR Foundation, who manages applications.
   
   
5. Programming Language and Interoperability. Supporting widely-used programing languages and interoperability largely removes barriers to developer adoption, rather than offering an independently sufficient reason to build on NEAR. This area of support is more meaningful in combination with NEAR’s other methods for incentivizing development.
   
   

Whether this set of mechanisms will ultimately demonstrate success in generating enduring demand for the network is a question still too early to answer definitively. Other questions surfaced in research worth further consideration include: Will this fee-splitting mechanism lead to NEAR exclusive dApps that premise their business model on the split? And is there a fundamental tension between the network goals of having extremely low transaction costs and design of a cryptoasset that accrues value on logic of a commodity, or can those be made to harmonize?