Melonomics Part 2: The Melon Engine

The importance of getting Melonomics right

We have already discussed project and token alignment in our previous blog post Melonomics Part 1. It is our view that having one common asset management token is beneficial to all users in that it reduces friction and cost on the network, whilst also aligning the interests and incentives of strong developers and teams by giving them the possibility to be funded with new MLN tokens or swap existing asset management tokens into new MLN tokens. Most importantly however, it creates potential for a strong network effect.

In order to ensure that this is possible though, it is crucial to ensure that the Melon token has integrity and desirability as a crypto asset, and a value which adequately incentivizes the user and developer needs of the network. In other words, it is important to get Melon token economics (Melonomics) right!

To do this we have to understand what drives the token value. So let’s think more carefully about token design.

When designing a utility token one must fundamentally understand the dynamics underlying that token’s use. Ideally, we’d want to keep the value of the token in line with the usage of the network so that we can incentivise developers to contribute to the development of the protocol on the one hand and encourage people to use the Melon software on the other. But which factors affect token price? Ultimately, this is like asking what factors drive token use.

Therefore, in what follows, we draw on basic economic theories to explore the relationship between the price, supply and demand for money. Using this framework, we will debunk some of the common myths which surround today’s discussions about token prices. We then explain how this understanding of price dynamics has shaped our thinking about Melonomics and underpinned our new buy-and-burn model — the Melon Engine. In distinction to most token designs we know of, our mechanism gives a number of benefits which solve the problem of aligning the value of MLN tokens with the actual usage of the network.

A bit of theory: MV = PQ 101

If you are already familiar with MV=PQ, please skip this section but we strongly recommend a refresher!

Our starting point is the quantity theory of money (also referred to as velocity theory of money¹) expressed in its original form as:

[eqn 1]

Where:

V = the velocity of a currency/token for all transactions in a given time frame ( ie the number of times an average token is used by the community, or “turns over” in a given time frame)

P = the price level of the goods purchased by the community (or the price in native token terms of the digital resource being provisioned by the community)

Q = the total quantity of the resources being purchased (ie the digital resource being provisioned in a crypto community)

M = the total nominal amount of money in circulation in the community (ie the number of tokens in issue)

This equation states very simply the identity that the amount of times a money is used by a community over a period of time (the left hand side of the equation: MV) must equal the total value of goods purchased by that community (the right hand side of the equation: PQ).

Before using this equation to inform token design, let’s first clarify a few important points.

(i) Understanding the difference between “price level” and “price”

The “P” in the equation refers to the price level in the currency in question, not the price of that currency per se. It is important to understand the difference. The term price level to an economist is usually something like the CPI (Consumer Price Index) ie. the prices of goods and services denominated in the currency in question. As a consequence, the price level of a currency has an inverse relationship to the purchasing power of that currency.

Suppose the price of a watermelon increases from $1 to $2. The price level (P) for this dollar token has now risen. Therefore, the purchasing power of that 1$ has fallen. Whereas $1 used to buy a whole watermelon, it now only buys half of a watermelon. Rearranging the equation of exchange for price level, we get:

[eqn 2]

This shows that P is inversely correlated with Q (quantity of goods being transacted) and positively correlated with both M (total supply of token) and V (velocity of circulation tokens).

If we are interested in the purchasing power of the currency, which is inversely related to P, we can use Vitalik Buterin’s notation for C

[eqn 3]

This might be more intuitive way to look at the token’s dynamics: the purchasing power of the community’s currency C, is positively related to Q (quantity of goods being transacted ) and inversely related to M (total supply of tokens) and V (velocity or speed of circulation of that currency).

(ii) Understanding the nature of Velocity

In a token economy, we can consider the native token of the economy as the currency. Melon is the native currency in the on-chain asset management economy. Asset management gas units (amgu’s) are the only digital resource available in the Melon economy, and therefore the only goods the Melon community can use the Melon token to transact in. The price level (P) for the Melon community is therefore the price in MLN of one amgu.

Many of these high velocity token models have been vocally criticised by Vitalik Buterin and others² for the supposedly inherent velocity problem. The nature of this criticism arises from the relationship between Q and V. In particular, for a given supply of tokens, higher quantity of amgu consumed in a community can be supported by that token simply changing hands at a faster rate. There need be no effect whatsoever on the price of the token. Rearranging equation 2 shows this very clearly:

[eqn 4]

One would intuitively expect that the total network value would appreciate with increased usage; however given the linear relationship of V to Q in the payment token model it is not necessarily the case.

In high velocity token models³, the typical model goes something like this: a user buys native token (Q = 0, V = 0) to pay for the use of the software (Q = 1, V = 1). Tokens are received as a “fee” by operators. Operators need to sell the tokens (Q = 1, V = 1), to pay their bills or purchase other goods and services. These tokens are then recycled back into the network. So another user again buys the same token (Q = 1, V = 1) to pay for the software (Q = 2, V = 2) and so on and so forth. As a consequence, increased network usage means the token follows this cycle again repeatedly by using the same tokens over and over. As network usage goes up, the quantity of transactions/resource purchased (Q) goes up, but since the fixed supply of tokens (M) circulates more rapidly, with each token being used to support more and more resource purchases, we see commensurate increases in V, not C.

We should point out that we believe there are counter-critiques of the Velocity problem. In particular, we think that V being perfectly and linearly related to Q might only be a special case (not a general one) of such token models when one considers the timing of community quantity of resource purchases which make up Q. But that is not the focus of this blog. For now, let us be clear that the network value (MC in equation 3) is not necessarily correlated to its usage (Q in equation 3) and that the closer the relationship between V and Q the more likely it will be that the token value is left behind, even when network transactions grow.

How can this happen? Primarily because the payment token model doesn’t provide a compelling reason for anyone to hold the token for more than a few seconds since it’s value is not linked to usage of the network. The problem to solve, therefore, is of designing a token model which closely links usage of the network to the value of the token, and which community members do want to hold. If a token design model could achieve this it would have a dampening effect on V simultaneously by providing an incentive to hold the token for anyone who believes in network growth. From equation 3, as Q increases, V also increases but proportionally more. Therefore, C decreases to balance the equation.

This is precisely what has underpinned our thinking around Melonomics.

2. Melonomics in practice

Now that we have a better understanding of the key economic characteristics of a token, we can think about a suitable Melon design. Our goals for Melonomics are therefore:

1. Reducing friction, inconvenience and costs to the user
2. Linking the token value to user adoption of Melon, thus providing proper incentives for future developers and maintainers of the protocol

In Melonomics 1, we talked about how we could reduce friction by sharing one common asset management infrastructure under the umbrella of one token which would also enhance reliability and network effects. However, as long as Melon remains on Ethereum, some friction still exists. Users are forced to own both Ether and Melon tokens in order to use Melon on Ethereum. This is unnecessarily suboptimal and over-complicated design, and already one token more than we would like!

To solve problem 1 therefore, we introduced the idea that users would now only need to hold and transact in Ether to interact with the Melon Protocol. We achieve this by charging users an initial fee (Network Transaction Fee) in Ether to cover both Ethereum gas costs and the costs of using Melon’s asset management software. The Network Transaction Fee would be split into two components:

1. The Ethereum gas — the required amount of gas to transact which is paid to the Ethereum network for it’s computing power (charged at the Ethereum gas price)
2. Asset management gas — the required amount of asset management gas to transact which is paid to the Melon network for amgu’s (charged at the Melon gas price).

The Ethereum gas goes to the miner as usual and the asset management gas would be sent to a special smart-contract forming part of the Melon Protocol, the Melon Engine.

The Melon Engine

The Melon Engine serves two purposes:

• The first is to collect the asset management gas in Ether and convert it from Ether into Melon. It does so by bidding for Melons with the collected Ether. If the bids are not being hit, the Melon Engine can increase the bids until the price is high enough that someone eventually hits the bid.
• The second purpose of the Melon Engine is to simply burn the acquired Melon tokens. In other words, the Melon Engine smart-contract would be permanently and irreversibly sending the tokens it just bought to an Ethereum Address which is provably inaccessible, effectively removing the tokens from the total token supply.

This helps us solve problem 2, linking token value to user adoption. Firstly, it creates a native “buy” demand for the Melon token which is linked purely to usage of the network. Note in passing that by increasing the liquidity of the token, or the ease with which it can be sold, the incentive to hold the token is (somewhat paradoxically) increased. Secondly, the Melon engine reduces the total supply (M) of Melon token according to the level of usage of the Melon protocol by providing a token sink⁴. This also has the effect of dampening the velocity (V) since tokens which have been burned can’t re-circulate.

One interesting and adjustable variable in this model is the Melon gas price, or in other words, the price of one amgu expressed in MLN. The total asset management gas paid is determined by the number of asset management gas units used in the function being called⁵ multiplied by the Melon gas price⁶.

This can be adjusted by protocol maintainers in the Melon Engine contract based on protocol usage levels and the price of MLN (in fiat terms). This flexibility ensures that usage fees are cheap enough to drive usage growth on the Melon protocol (cheaper than traditional asset management alternatives) whilst at the same time incurring a reasonable enough cost to incentivize maintainers, support innovation and benefit token holders.

Earlier we explained that there are benefits to designing a token model which aligns the value of the token with the usage of the network, whilst addressing the velocity issue. With the Melon Engine, we align the value of the token with the network usage because the burn rate is directly linked to the number of amgu’s consumed, therefore decreasing the total supply (M) accordingly. Absent speculation, if the network is used at full capacity, the design of the Melon Engine naturally caps velocity because of the existence of a token sink. Re-introducing speculation, the Melon Engine model also provides incentive to hold the token if one believes protocol adoption will increase, further reducing velocity (ie. longer holding period). In particular, managers may want to hedge the gas price risk (ETH/MLN exchange rate) by holding MLN in their portfolios.

In the Melon Engine model, despite the user having no interaction with the Melon token, a strict and powerful mechanism aligns the value of the network with its usage.

Let’s walk through a simple example to better illustrate these dynamics.

Example

The following numbers are provided exclusively for illustration purposes and should not be considered indicative of future forecasts.

In this example, we will try to use basic assumptions to illustrate how the Melon Engine links usage and network value. For simplicity, this model assumes no speculation and no inflation although these are both factors that would exist in practice.

In Year 1, let’s consider an asset management economy where there are 500 active Melon funds. The Melon (MLN) token allows you to purchase units of asset management gas on the Melon network. To be clear, in the Melon economy’s “basket of goods”, only one good is being produced and considered. That good is the “asset management gas unit”.

The total supply (M) of currency in the Melon economy is 1,002,000 MLN tokens. Each Melon fund consumes asset management units of gas when they interact with the Melon network (which they pay using ETH).

For quantity of digital resources being provisioned (Q), we will model our data from real Melon funds which have been deployed to estimate the units of gas required to interact with Melon funds at the following levels:

Example of Melon smart contract functions:

• setupFund requires approx 3,490,520 units of gas
• requestInvestment requires approx 202,196 units of gas
• executeRequest requires approx 281,133 units of gas
• redeemAllOwnedAssets requires approx 38,547 units of gas

Our assumption is that setupFund is required once per fund, a fund receives on average 10 investments per year (and executes this request subsequently 10x). We assume average number of redemptions per year is three. This amounts average number of twenty four functions called for the first year on a Melon fund. It is assumed here that no asset management gas is collected on trading functions.

In other words, total amount of gas units per fund in Year 1 is estimated at:

3,490,520 + (10 * 202,196) + (10 * 281,133) + (3 * 38, 547) = 8,439,451 gas units ( we will round this to 8.4mn for simplicity)

Let’s assume the initial asset management gas price at 0.00001 (MLN/amgu). In other words, the Ether equivalent of 0.00001 MLN is needed to consume one unit of asset management gas.

We can simulate our model taking the following assumptions:

M = 1,002,000 MLN tokens

Q = 500 * 8,400,000 = 4.2bn asset management gas units

P = 0.00001 MLN / asset management gas unit

V will be expressed as a function of the variables above.

From this table, we can deduce that in year one, 42,000 worth of MLN token will be collected and burnt by the Melon Engine smart-contract. (We can see here that V is contained)

In Year 2, the price of asset management gas stays the same, but demand for the platform doubles. We can see that the number of MLN burnt increases non-linearly. This is because Melon funds that already existed in Year 1 incurred a one-off setupFund step which does not need to be re-counted in Year 2. The result of doubling the usage on the platform is a reduction in total supply of MLN. The link we have created between utility of the network and burn rate/token supply is very important to note here.

In Year 3, the number of funds increased by 500%. As a result, the network can afford to lower the gas price whilst still benefiting token holders because the purchasing power of MLN is higher and the burn rate continues albeit at a slower pace.

The reduction in the asset management gas price in Year 3 is made possible due to noticeably strong growth rate in protocol usage.

At the same time, the velocity of the token is contained at reasonable levels because it does not grow linearly with Q. As we can see the velocity is not increasing at a linear pace (year 3 illustrates how we could slow down the pace of the velocity increase by lowering the price level).

In conclusion, this simulation shows us how protocol maintainers, users and token holders can all be aligned. Protocol maintainers and token holder’s incentive will be to reach an optimal balance between:

• Maximizing the burn rate (how many MLN are burned as a function of platform usage)
• Adjusting the cost of using the platform ie. the Melon gas price, based on demand and market volatility (MLN market price), while keeping it affordable for users.

As far as we can tell, this mechanism achieves these goals whilst also dampening the rate at which V increases with growth of the network. More interestingly, as network usage grows, we can afford to decrease the price level of asset management gas units (in MLN) whilst maintaining a healthy burn rate.

Conclusion

In contrast to models in which V grows linearly with Q, the Melon Engine uses a buy-and-burn mechanism to dampen velocity, increases the incentive to hold the token, and therefore creates a strong link between the usage of the network and the token’s value.

With the Melon Engine, we aim to ensure that once Melon governance is fully rolled out, there will be:

• A demand for the token which is directly proportional to protocol adoption and to computational requirements of the asset management functionalities on the Ethereum network.
• A burn rate (token sink) linked to the usage of the network which lowers token velocity and can be adjusted through periodic re-setting of the Melon gas price.
• Greater token liquidity, which will also be a function of network usage.
• An incentive towards a longer holding period of the token, for people who genuinely want to have exposure to the value of the network or its adoption.
• A network effect, based on the desirability of our native Melon token, to facilitate innovation and growth across the whole blockchain-based asset management industry.

In future iterations, one can additionally imagine staking use-cases at the protocol level or by applications built on top of Melon or off-chain services. This is something we may explore further in future blogs.

This piece was co-authored by Mona El Isa and Jenna Zenk

We invite you to provide constructive feedback and comments. Please especially reach out to us if you think we’ve made a mistake in our thinking or simply want to provide feedback. This model is subject to further research and therefore will most likely evolve over time.

A special thanks to Dylan Grice, Gavin Wood, Matthew Di Ferrante (ZK Labs), William Peets (Passport Capital), Ella Papanek (Passport Capital) & Jon Kol (Passport Capital), Russ Newton (GABI), Dean Eigenmann (ENS and ZK Labs), Luke Duncan (Aragon), Alex Lindgren (LloyLaw), George Hallam, Julie Simon, the Melon team and Ryan Zurrer (Polychain Capital) for their feedback and discussions on this topic. Any remaining mistakes are our own.

And additionally a special mention to Mike Salls (Coinbase) and Vitalik Buterin for their insightful writings on the subject too.

This blog post is subject to change as the research & development phase is ongoing. Melonport will aim to update blog-posts regularly to represent our latest thinking on a best-efforts basis but there may occasionally be time-lags between latest thinking and updated documentation. With this in mind, the author of this blog assumes no responsibility or liability for any errors or omissions in the content of this blog.

Subscripts:

1. The best explanation we have found so far has been Mike Sall’s blog post “Valuing cryptoassets from the ground up”. See also Milton Friedman’s “Quantity Theory of Money”
2. https://vitalik.ca/general/2017/10/17/moe.html

If you want to understand how this velocity issue has affected (high velocity) payment token and medium of exchange token models, we encourage you to read:
- Valuing crypto assets from the ground up ❤, by Mike Sall
- Medium of Exchange by Vitalik Buterin
- Understanding Token Velocity by Kyle Samani
- The velocity thesis section in On value, velocity and monetary theory by Alex Evans

3. Read more on token sink: https://vitalik.ca/general/2017/10/17/moe.html

4. In this context, it is important to understand the difference between gas unit, gas price and transaction fees in order to understand this model. You can read more about this here: https://hudsonjameson.com/2017-06-27-accounts-transactions-gas-ethereum/

5. Note here that this is the current thinking and that it is subject to change during implementation phase.