TL;DR Check this back end and front end solutions for delegated transactions. It is universal for any token which supports the delegation of its functions. Read more below.

This mostly technical article provides a universal framework and a working solution for Ethereum tokens and applications that eliminates the need to pay fees in Ether, a problem that is practically killing the user experience of many blockchain applications.

Imagine spending dollars and then being asked to also hand over some Hryvnias as a transaction fee. That's how Ethereum tokens work so far.

In other words, for example, to transfer any Ethereum token (like Tether, DAI, BAT, DREAM, etc.), the user has to also spend some Ether (internal Ethereum platform currency). This introduces a big inconvenience that prevents the mass adoption of DApps: users have to purchase multiple currencies instead of just one to interact with the blockchain network.

The Problem

Tokens, as we imagine them today are just fuel for applications and services on top of blockchain networks. Organizations create their own tokens (using ICOs, IEOs, etc) and run services/applications that utilize them, introducing their own micro-economy (widely known as a token economy). But almost every token turns out to be quite a complex currency itself. By design of how blockchain networks work, in order to do something with your tokens, you also need another currency — often Ether (for Ethereum) to be able to transfer tokens.

To illustrate the problem, let's look into how users come to use different blockchain-powered services and applications like:

• Trickle - where you create secure, hourly-based contracts with an untrusted party in any token
• Loom - where you use Loom tokens to create sidechains in Loom Network
• Cryptokitties.co - where you breed, trade and transfer kitties (ERC721 tokens)
• Others (there are a lot!)

All these applications use tokens, as well as they require you to purchase Ether. The complexity of using crypto tokens as we know them today is one of the biggest reasons why 99% of crypto startups fail (or avoid adopting real crypto, for example, by replacing it with virtual coins).

As you may already know, the harder it is to use the application, the fewer users it will get right from the beginning. This is something known as The User Onboarding Funnel, which is still a big pain for blockchain-powered applications and services:

The typical user onboarding funnel of a decentralized, blockchain-based application

To understand why I put 0.001% of users prior to the service use, let's see what exactly purchasing some Ether means:

• Creating a crypto wallet
• Registering on Exchange (and learning all the exchange rules, including country policies!)
• Passing KYC (though it's getting easier, still, many countries have limited access to exchanges)
• Purchasing a minimum allowed amount of Ether (usually, it's whopping $50 while you need just nearly $0.05 to perform one or two transactions)
• Withdrawing Ether to your wallet
• Not to mention reading lengthy guides on how to perform all these steps properly

Instead of just:

• Creating a crypto wallet

Of course, it highly depends on how the application or service is made. But, so far, there was no better simplification of the onboarding flow as just cutting crypto tokens from there, or making them fake, "virtual" currency with deposit and withdrawal function. Unfortunately, the latter approach is now the common one across all startups and companies adopting crypto, for many good reasons. Another reason could be a monetization strategy, but this is another big story worth a dedicated article (Interested? Comment out!).

Getting back to the transaction fees problem, we can state the following, which is hard to argue with.

It is natural for the user to purchase only the cryptocurrency they really need (for instance, tokens: Tether, DAI, BAT, DREAM, etc.), and they would normally expect to pay any transaction fees in this cryptocurrency.

So why not just allow them to do so? Because it's quite complex indeed. Let's see why, and how this has just got easier with our open-sourced solution (at least for Ethereum).

Existing Approaches

From the very beginning of blockchain existence, there were a couple of solutions that could simplify the user onboarding flow to the flow depicted below, avoiding the step of purchasing an intermediate currency like Ether. Still, creating a blockchain wallet is not an easy step, but some users who do understand the value of the application/service go through this step quite well.

The user onboarding funnel with delegated transactions

The solution which allows to avoid using intermediate currencies (Ether for Ethereum) is called "delegated transactions", or "meta transactions".

In short, delegated transaction, or "meta transaction" in blockchain is the type of transaction which performs an intended action on one account's behalf, while it is conducted (published) by another account (delegate), who actually pays fees for the transaction.

There are multiple approaches around the internet of the generalized concept of delegated transactions I am presenting in this article. But it seems that none of them are still widely adopted, as these approaches are quite complex by its nature, very specific as for the implementation, as well as some of them are quite complex to standardize. To be more constructive, existing approaches can be divided into 3-4 groups: those which use proxy smart contracts, those which embed delegation into a smart contract itself and, theoretically, there is an opportunity for the blockchain-native implementation (say, Ethereum 2.0).

1. Delegated transactions approaches which use proxy-contracts

Proxy contracts, or, in this context, identity contracts are tiny contracts deployed to replace the user account which wants to avoid paying fees. This smart contract is programmed to act as a wallet, as well as a "caller" (sender) of other smart contract's functions. The key is that it is a delegate account that triggers all the actions, while the true "owner" of this smart contract is another user. The user just generates correct signatures in order to control their funds stored on a smart contract address (= in their wallet).

A visualization of how identity contracts look like

Pros of this approach:

• It works with any tokens and contracts which are already deployed to the network

Cons of this approach:

• Users don't see tokens in their wallet, because they are physically on an identity smart contract
• As a result, a need to develop custom UIs and custom tools/wallets
• Identity smart contract deployment and assignment initial fees, as opposed to no fees at all
• Requires a comprehensive standard to be widely adopted

2. Semi-delegated transactions via "Operator" pattern (ERC777)

There is a token standard that describes this approach — ERC777. In short, any token holder can authorize any other account to freely manage their tokens. I won't call it delegated transactions but nevertheless, I need to mention that, as here we somewhat delegate control over your tokens to other accounts.

A visualization of ERC777 standard's "operator" pattern

Pros of this approach:

• Standardized

Cons of this approach:

• Highly centralized around the "operator" accounts
• Weak security due to operators have 100% control over your tokens
• Initial fees for approval transaction
• Requires additional UIs/tools development

3. Delegated transactions embedded directly into a (token) smart contract

Just the same as it is possible to implement custom fees in a proxy smart contract, paying fees in tokens can be implemented directly in a token smart contract. For example, using the approach I described in my previous article, it is possible to implement a function in a smart contract, which will transfer tokens accepting the user's signature, instead of requiring the user to call this function directly. We have implemented this approach in our DREAM Token, which is used on our dreamteam.gg platform.

A visualization of how embedding delegation into the token contract looks like

As you may notice, in contrast to the previous approach there is no identity contract anymore, and there is an optional way to call other smart contracts directly from the token contract.

Pros of this approach:

• Users see their tokens as usual on their wallet's balance
• No initial fees for account initialization
• May not even require a standard (continue reading)

Cons of this approach:

• If you have a (token) smart contract that is already deployed to the network, you cannot apply this approach to it directly. While you can always deploy a new token and, for example, a "migration" utility, which will allow other users to swap tokens (burn the old token and mint a new one)
• Because a standard for this approach is yet not well-defined, implementation can drastically vary
• A need to develop custom UI/tools for delegated transactions (continue reading — solved!)

4. Delegated transactions on the (blockchain) platform level

This is far the best one of all the described approaches above but also the one which is not implemented anywhere yet (by anywhere I mean the most popular blockchain platforms). There is a hope that its support comes with Ethereum 2.0 release, or at least I've heard from Vitalik that they are in progress with something cool there.

Theoretically, we can imagine this approach as being able to make an "offline" signature of two transactions at a time: one which does something useful for the signing account which wants to avoid paying fees (for example, transferring tokens) and another one which does something useful for the delegate (for example, paying fee in tokens to the account which executes these two transactions).

A visualization of how platform-native delegated transactions could look like

But the problem is, regarding Ethereum 2.0, this feature has a chance to land only in 2022 or even later. I also suppose that this feature will still require a dedicated back end (similar to the one which is introduced within this article), as it is hard to imagine how miners will accept fees in tokens. Simply put, if some of them refuse to accept fees in tokens than it makes little sense to do it on a "mining" level at all, not to mention how much would it take to track all token prices and volumes across exchanges, in a decentralized manner.

Pros of this approach:

• No need to change smart contracts that were already deployed
• No initial fees for account initialization
• May not even require a custom UI/tools if standardized

Cons of this approach:

• Most likely, will still require a centralized back end (the "delegate")
• Not yet implemented on a platform level (as of 2019)

The Solution

From the four approaches above, except for the platform-level approach which is yet to be implemented and standardized in 2022+, the most appealing one is the third approach, where we embed delegated functions directly to the token smart contract. Thus, we save the standard token paradigm allowing wallets to normally work with the smart contract and have no need to wait until delegated transactions will land natively in one of the top blockchain platforms. We will stick to this approach and make it universal just below.

Delegated transactions support programmed right in the token smart contract is awesome. But how to deal with its cons? In fact, the only problem which is tough to deal with (as you cannot modify existing smart contracts), you will need to deploy a new token smart contract if you have already deployed it without delegated functions (for instance, standard ERC20 or ERC721 tokens). The next step, in this case, would be adding a way to migrate tokens from one smart contract to another. For example, you can decide to implement one more function in the new smart contract that will allow token holders to migrate their assets from the old smart contract.

Token migration function implementation can vary, starting from implementing receiveApproval in the new token, if the previous token supports approveAndCall, or ending with utilizing approve + transferFrom framework if you have just a bare minimal ERC20 (the user _approve_s tokens to the new token contract address and then calls a function in the new contract which burns old tokens and mints new ones — but this requires a standard fee for the user for the approval transaction). Actually, there is more: you can decide not to burn old tokens but to "lock" them on a new token smart contract, minting new tokens — this opens an opportunity to implement two-sided token migration, which is awesome — you won't need to list the "new" token on the exchange, while the users will still be able to send the old token to exchanges without fees in Ether! If you are interested, please fill the issue here if you want to know more details on how to do it, because this approach is worth a whole new article.

In my previous article, I provided an example of the token smart contract which supports delegation of such functions like transfer, transferFrom, approve and approveAndCall. Exactly these "delegated" functions allow users to pay fees in tokens, instead of Ether.

How delegation works in Ethereum, in short. Read more in this article.

But that wasn't enough to start the mass adoption. In this article, I am providing a complete universal back end solution (Transaction Publisher in the picture above), as well as a configurable widget (check it here), which allows you to replace Ether fees for token fees today.

Some key points before we dive in:

• This delegated transactions back end is made to be universal, or standard-free, meaning that you can have any implementation of delegated functions and use any signature standard(s) in your token. From the back end standpoint, you just need to write a manifest file for your token, describing its usage.
• Currently, converting collected fees in tokens back to Ether is a manual action on exchanges. But it could be a potential improvement for automation in the future (if needed).

The Concept Behind the Universal Solution

What does it mean that the token supports delegated transactions? Let's look at it using the ERC20 standard token as an example.

Smart Contract

As for the token smart contract, the approach is quite straightforward. In addition to every method like transfer(to, value) which we want to be "delegatable", we add a companion function which, instead of inspecting msg.sender, accepts the signature of a user and does the same what the original function meant to do by validating this signature inside the smart contract. Thus, for example, for transfer(to, value) function we can add transferViaSignature(to, value, ...aditionalParams) function. As you know from public-key cryptography, no one can create a valid signature except private key owner, so that's why this approach is as secure as Ethereum itself.

And the coolest part is that the delegated function implementation, as well as its signature doesn't matter much, from the delegate back end standpoint. You can even decide to implement one "call by signature" function for all other functions that the smart contract supports. Delegate back end just need to know how to call this function, which is solved by providing an off-chain contract manifest for the delegate back end. For example, the argument additionalParams in transferViaSignature can vary and can include anything from this list, if not more: fee, fee recipient address, expiration timestamp, a signature standard used, a signature itself, nonce number or any other unique delegated transaction ID and so on. Regarding the smart contract design, in order to understand why exactly these arguments, read my previous article.

We also want to allow "delegates" to earn something in order to cover their Ether spending, as well as to be profitable. Thus, we have to add a fee, but a much more natural fee than Ether: a fee in the token itself. So that, for example, if you need to transfer 100 tokens, you pay 3 more tokens to the delegate depending on its price and network conditions to perform a transfer, and this should be preserved in a smart contract logic.

Back End

All right, now we have a token that allows transferring someone else's tokens by using their signature. Now, the crucial part is to automate the process of requesting and publishing such transactions. And here where our open-sourced back end (and a front end) kicks in.

Below is the sequence diagram describing how front end (client) communicates with the back end from the delegated transaction request to its publishing to the network:

1. (hidden on the diagram) The client requests information from the delegated back end to understand which contracts does it support, as well as which functions can it delegate.
2. The client requests a particular smart contract's function to be delegated. Most importantly, the back end returns the fees it charges and a data to be signed by the client.
3. The client signs the data in their wallet. Signing is a free operation, unlike publishing transaction to the network.
4. The client sends their signature back, thus confirming their intent to perform this particular delegated transaction. The back end validates this transaction against the current network.
5. Finally, the back end publishes a transaction to the network.
6. (hidden on the diagram) The client constantly polls the back end for the delegated request status until it receives a mined status. Note: it is important to poll the back end instead of using a transaction hash to understand when the transaction is mined. It is a very common case when the gas price suddenly increases, and, in order for the transaction to be mined quickly, the back end may republish it with a higher gas price. Though it is currently not implemented, it is very likely to be implemented soon.

Sequence diagram representing the simplified flow of how delegated transaction is delivered to the network

This approach is universal, and only requires the manifest file for the back end to understand how to calculate fees and which signature standard to use on the client side. Here is another visualization of the components of the system and their interaction sequence:

Component diagram

We've provided a comprehensive documentation for this solution. You can check how the back end API is structured, as well as find the token manifest file which describes how to work with a particular token contract. We encourage you to contribute your own tokens there!

And you don't need much setup: it's already there with the universal front end!

Front End

Open-sourced front end part of the delegated transactions is the user interface which is set up for every token: just run your delegated transactions back end and you are ready to go!

What it looks like

It is made to be an embeddable widget, which will guide the user through the procedure of sending tokens. You can plug any back end, token or call any token function with it by utilizing additional URL parameters you can specify.

Using this widget, and by implementing something similar to widely used, but not standardized approveAndCall function in your token smart contract, you will be able to call other smart contracts with arbitrary data by paying fees in tokens!

Here is a quick guide for you if you want to play with this UI yourself:

1. Access the widget via this link.
2. It will ask you to switch to the Kovan test network.
3. Get some test Ether using any available Kovan faucet.
4. Use test Ether to mint some test tokens: call mintTokens function in a token smart contract which will give you 10 test tokens.
5. Now, get back to the widget and try to transfer these tokens!

If you open up the browser's developer tools, you may notice that there are a couple of back ends connected by default — they provide the front end with all required information to make a delegated request according to given widget URL parameters. All backends are requested during the widget load and, if any of them can provide a delegation for a particular contract's function, then the widget requests additional information: fees, supported signatures, etc. If there are multiple back ends which can delegate the same contract function, all of them are requested and the back end which provides the best fee will be used for the transaction.

Transaction mining time is seemingly fixed, but it can vary because of the network conditions. The back end uses an actual network fee when calculating the token fee, however, it may change before the user decides to execute the transaction. Thus, the "underpriced" transaction is submitted to the network and can be pending for a while. While the back end is currently not programmed to deal with this case, it might be implemented in future — transactions will be republished with higher gas fees in case of the network fee increases. But, we will also need to count this into the token fee.

Signature Standards

The last question which you may be wondering is — which signature standard to use for your token. There are several available: _ethsign (deprecated), _ethpersonalSign (note that old Trezor and Ledger produce a different signatures because of ambiguity in a standard, so you may want to include both), _ethsignTypedData (deprecated), _eth_signTypedDatav3 and so on. I would recommend supporting at least two: ageless _ethpersonalSign and new _eth_signTypedDatav3 (as of 2019).

Signature standards comparison — what the user sees

The front end is programmed to always prefer the user-readable standard like eth_signTypedData_v3 to any others eth_personalSign. So if your token supports many signature standards, and you added all of them to the manifest file of your token, it will display eth_signTypedData_v3 prompt first.

Conclusion

Delegated transactions are great: they solve one of the biggest problems of blockchain application adoption, which eases the mass adoption of crypto overall. I will put a couple of thesis in a Q&A format here for you to answer the last questions that you may still have after reading this article:

• Our open-source solution is free to use and production-ready, feel free to apply it to your applications or tokens!
• The described approach does not compromise security nor centralization. Think this way: the centralized back end is only a helper for someone who wants to transfer tokens without fee in Ether. If the back end is hacked, or it is just unavailable, there's no problem to interact with the network just as it was before, by paying fees in Ether. As well as the back end cannot harm or trick the user to steal their tokens when a proper signature standard is used (it's up to your token implementation).
• There is a way to support delegated transactions for existing, already-deployed tokens. However, it requires the additional Ether-consuming step to migrate existing tokens to a new token contract. And, by programming a new token contract properly, as well as designing your application to work with both tokens you can even avoid a need to list a new token on exchanges.
• By using the existing tokens as an example, which is available in delegated transactions back end and front end repositories, you can produce your own manifest for your own token.
• Read the instructions on how to set up your own back end for a token, and then add it to the URL of your widget (or commit to the open-source repository).
• Have a token which already supports delegated transactions? Plug it into our UI with these three quite simple steps: (1) create a manifest for your token and put your token abi file while setting up the delegate back end, (2) run this back end, exposing a public API URL and (3) use URL parameters in a widget to reference your back end or commit it directly to our open-source repository. Read more about it in GitHub's readme file.

I hope that was a really helpful piece of information for all the searchers of incredible. Feel free to contact me or fill the issue here if I missed something. Have fun, let the token economy be simple!

As an analyst at Amazix, I spend a large portion of my time reading through hundreds of projects’ whitepapers and analyzing their token economic models to discern whether or not they’re adequately capturing the value created by the project.

This is extremely important because the value captured by a token is essentially its utility or intrinsic value which is also what ensures that the token’s price grows alongside adoption/success of the underlying project. A token lacking utility will see its price supported only by speculation and is very likely to fail in the long-run.

For more on this, see my earlier blog, in which I discussed the importance of token economic models in ensuring a token’s long-term value.

In part 1 of this series, I covered the problem of misaligned incentives caused by projects which have both equity and tokens, suggesting there’s an inverse relationship between the value of a project’s equity and the value of its token in that they are effectively competing to capture the value created by the project. I also suggested some potential solutions to this issue.

In this blog, I’ll discuss the second most common problem we see with token economic models: the velocity problem facing “Medium of Exchange” tokens. I’ll begin by giving a brief background of what token economics is before describing what the velocity problem is, why it matters and some of the solutions we recommend to our clients.

What is a token economic model and why does it matter?

If you’re a seasoned crypto investor or understand what a token economic model is, feel free to skip this part.

Before we start talking about token economic models, it may be wise to start at the very beginning with what is a token and what makes up its value.

A token is a crypto-economic unit of account that represents or interacts with an underlying value-generating asset. A token’s value is made up of its intrinsic value, the percentage of the token’s value that derives from demand for the underlying asset, and its speculative value, the percentage of the value of the tokens that derives from demand due to an expectation of future price increases. While speculation is nice, it is hard to control/predict and puts projects at the mercy of short-term-oriented investors, like our friend below:

Rather than focus on speculative value, we recommend investors focus on intrinsic value. A token’s intrinsic value is dependent on two factors: the value created by the underlying asset and the percentage of this value which is captured by the token.

The token economic model is what determines the latter — how much of the value created by the platform is captured by the token. As such, it’s one of the primary determinants of a project’s utility value and long-term success.

Medium of Exchange tokens and the velocity problem

A pure Medium of Exchange token is a token whose sole or at least primary use is as payment for some utility on the project’s platform or protocol. There are various incarnations of this, from marketplaces such as Signals Network where the token is the sole currency used to buy services on the platform, to SaaS type projects like BitStation where customers can only access the platform’s utility by paying the company a fee in the native token.

The general problem with MoE tokens is that they suffer from extremely high velocity. This has been well documented by many, including Vitalik, James Kilroe and Kyle Samani.

Basically, given the MoE token’s only use is payment for a service on the platform, there’s no incentive actually to hold tokens and incur price risk vs FIAT.

Buyers of the platform’s utility will simply acquire tokens for the purposes of a specific transaction (holding it for as little time as possible). On the other hand, sellers of the platform’s utility (whether this be users on a marketplace as in the case of Signals or the company behind the project in the case of Bitstation) will instantly sell the tokens they receive for FIAT rather than incur price risk vs FIAT.

This will result in high velocity for the token, as the increase in demand driven by buyers acquiring tokens will always be quickly matched by a corresponding increase in supply from sellers converting these tokens to FIAT.

Effectively, high velocity acts as an increase in circulating supply and is thus inversely proportional to the value of the token (although a certain base level velocity is necessary for the token to have any value, as pointed out by James Kilroe). We can see how this works using the Equation of Exchange, which has famously been adapted to crypto by both Chris Burniske and Vitalik.

To use Burniske’s definition:

MV=PQ

Where:
M= size of the asset base
V= velocity of the asset (the number of times that an average coin changes hands every day)
P= price of the digital resource being provisioned. This is not the price of the cryptocurrency but rather of the resource being provisioned by the network (i.e. price in $ per GB of storage in the case of Filecoin)
Q= quantity of the digital resource being provisioned (GBs of storage provided)

As Burniske tells us, in order to value the coin, we solve for M, where:

M = PQ/V.

M is the size of the monetary base necessary to support a cryptoeconomy of size PQ, at velocity V. In order to find the token price, we simply divide M by the total token supply. As we can see, the higher the velocity the lower the coin’s value.

Or, if we prefer to use Vitalik’s definition:

Vitalik takes MV=PT and in order to simplify the analysis of cryptocurrencies recasts it as MC=TH, where:

M= total money supply (or total number of coins)
C= price of the cryptocurrency (or 1/P, with P being price level)
T= transaction volume (the economic value of transactions per time)
H= 1/V (the average time that a user holds a coin before using it to make a transaction)

Therefore, the left part of the equation (MC) is simply the market cap (total supply*price) whereas the right side is the economic value transacted per time period (T) multiplied by the average time a user holds a coin (H).

To solve for the token price, one must therefore solve for C:

C=TH/M

Once again, we can see that the higher the velocity (or the lower the holding time H), the lower the token price.

Vitalik impress

In both Burniske and Vitalik’s definitions, it is apparent that the velocity of the coin is inversely proportional to the value of the token, That is, the longer people hold the token, the higher the price of each token. As James Kilroy tells us:

“This is intuitive, because if the transactional activity of an economy is $100 billion (for the year) and coins circulate 10 times each over the course of the year, then the collective value of the coins is $10 billion. If they circulate 100 times, then the collective coins are worth $1 billion. Thus, understanding and calculating the velocity in any token economy is extremely important.”

To see the drastic effects that velocity can have on a token’s value capture and market cap, see the following analysis of the effects of velocity on Ethereum’s market cap by John Pfeffer:

“In a protocol-land where protocol usage is managed by capital-efficiency optimising intelligent bots (which seems likely), let’s assume for simplicity the absolute floor on 1/V is the block time of the chain in question. Let’s then take ETH with a 2.5 minute block time as an example (highly theoretical, just to make a simple maths point). This implies each token could be used (assuming fixed block times, which in fact will likely shorten) 210,240 times a year. Buterin, Choi, etc. talk about, say, 10% of ETH being staked (let’s assume staked tokens never move at all). That would bring V down to 189,216 per year. Assume 50%, then V=105,120. Multiply this last number by $50b of network value (i.e., ETH just maintains its current value, and you’d need $5.25 quadrillion of economic activity denominated in ETH (i.e., excluding any ERC20/ ERC721-denominated economic activity), that is to say, 65x the current global GDP of $80 trillion. These numbers are all just varying shades of silly. That’s the point. As long as some of your tokens are circulating at a high V, your overall V is high.”

Solutions to the velocity problem

The most commonly used solutions to this problem all involve designing token economic models that provide incentives for people to hold the token — basically turning it into an asset (or “Store of Value”) rather than a currency. This can be done in several ways:

(1) Ensure token model has a “sink” in it

This one was initially suggested by Vitalik and has been widely adopted since. Basically, it involves designing token models with “buy-and-burn” mechanisms in which the project charges transaction fees and then uses some or all of the cash flows generated by its platform to purchase its own tokens and destroy them. The decrease in supply raises the value of all remaining tokens by the percentage of total supply destroyed. Effectively, the project is distributing its cash flows to its token-holders, very similar to how equity distributes cashflows to its stockholders through a dividend.

An example of this is Iconomi, a digital asset management platform which burns preset percentages of all fees collected and also produces quarterly reports outlining the number of tokens burned (crypto quarterly earnings reports).

Since, as we previously mentioned, velocity acts as an increase in circulating supply which reduces the value captured by the token, a buy-and-burn mechanism has the opposite effect of ensuring each additional transaction (i.e. increase in velocity) on the platform reduces the total supply of tokens, thus counteracting the increase in velocity with a deflationary force.

This should also reduce velocity by giving people a reason to hold the token, namely the expectation that it will be more valuable in the future due to the deflationary force created by the token burn.

The Joker reducing $ velocity

(2) Implement a “profit-share”

This one was initially suggested by Kyle Samani of Multicoin. It is very similar in spirit to the “buy-and-burn” in that it is providing the token with a yield and turning it into an asset that generates cash flows.

An example of this is Augur which pays REP holders for performing work for the network. REP tokens are like taxi medallions: you must pay for the right to work for the network. Specifically, REP holders must report event outcomes to resolve prediction markets. Other examples of “profit-share” tokens include FOAM , Sharpe Capital and also Ethereum once it has switched to Proof of Stake.

Once again, a profit-share reduces token velocity by forcing people to hold the token in order to have the right to generate cash flows by providing work to the network.

(3) Encourage users to lock up tokens

This can be done through mechanisms such as Proof-of-Stake which encourage users to lock up a certain amount of tokens, verify transactions and receive a yield in return (this also has the added benefit of acting as a profit-share). DASH, NEO and Navcoin are all examples of coins that have implemented proof of stake models.

Users can also be encouraged to lock up tokens through clever gamification — providing users with rewards (financial or otherwise) for locking up tokens. For instance, Alluma, a crypto exchange targeting Asian markets, offers different membership levels and fee discounts based on users staking different amounts of tokens:

• Gold memberships offer 35% discounts in exchange for staking 2500 LUMA for 30 days, and
• Platinum memberships offer 50% discounts in exchange for staking 10,000 LUMA for 90 days (source: page 28 of Alluma whitepaper).

For another example, we can look at YouNow, a live streaming app which allows users to tip content creators in its native token PROPS.

While content creators could immediately convert PROPS to FIAT, they are incentivized to hold onto it as their content is ranked higher by YouNow’s algorithm based on how many tokens they hold. Since discoverability leads directly to more tips, YouNow is effectively turning PROPS into an asset by ensuring users who hold it are able to generate cash flows.

Donald Duck’s masternode

Conclusion

Token economic model design is an extremely important and underrated area for both investors and founders of cryptocurrency projects to think about. A project with a weak token economic model may see its token price fail, even as the project itself succeeds, simply because the token is not capturing any of the value created by the project.

Velocity is one of the biggest problems with current token economic models and many established projects such as Civic, Storj and Po.et have recently revamped their token models to address this issue. If you believe your project may also suffer from high velocity and are interested in having your token economics audited or discussing this further, feel free to get in touch with me through here or on Twitter.

As part of the senior analyst team at AmaZix I spend a large part of my time reading through hundreds of projects’ whitepapers. I do in-depth due diligence to determine whether or not their tokens will be good investments. In doing this, one of the most important factors we look at is the project’s token economic model. This is to discern how much of the value created by the project is being captured by the token.

This is extremely important. The value captured by a token is essentially its utility or intrinsic value. This ensures that the token’s price grows alongside adoption/success of the underlying project. A token lacking utility will see its price supported only by speculation. It is very likely to fail in the long-run. For more on this, see my earlier blog, in which I discussed the importance of token economic models in ensuring a token’s long-term value.

In this blog and the next, I’ll discuss the two most common problems we see with token economic models. I will also explain why they matter and also some of the solutions we recommend to our clients.

What is a token economic model and why does it matter?

If you’re a seasoned crypto investor or understand what a token economic model is, feel free to skip this part.

Before we start talking about token economic models, it may be wise to start at the very beginning. What is a token and what makes up its value?

A token is a crypto-economic unit of account that represents or interacts with an underlying value-generating asset. A token’s value is made up of its intrinsic value and its speculative value. The intrinsic value is the percentage of the token’s value that derives from demand for the underlying asset. The speculative value is the percentage of the value of the token that derives from demand due to an expectation of future price increases.

While speculation is nice, it is hard to control/predict. It puts projects at the mercy of short-term-oriented investors, like our friend below:

Rather than focus on speculative value, we recommend investors focus on intrinsic value. A token’s intrinsic value is dependent on two factors: the value created by the underlying asset and the percentage of this value which is captured by the token.

The token economic model is what determines the latter — how much of the value created by the platform is captured by the token. As such, it’s one of the primary determinants of a project’s utility value and long-term success.

Problem 1: Projects where equity is “stealing” value from the token

In my earlier blog, I suggested that there was an inverse relationship between the value of a project’s equity and the value of its token. They are effectively competing to capture the value created by the project.

This is because a company/protocol generates a fixed number of value/cashflows. This can be distributed to equity holders in the form of a dividend. It can also be distributed to token-holders in the form of a token burn/profit-share mechanism.

As such, ignoring speculation, if a project’s equity is valuable, then it’s capturing value for shareholders at the expense of token-holders. If a project’s token is valuable, then it’s capturing value for token-holders at the expense of shareholders.

Most of the biggest projects such as Bitcoin and Ethereum aren’t companies. They do not have shareholders. They only have token-holders instead. As such, there is no conflict of interest. Their token economic models seek to maximize value for token-holders.

However, this is not the case for many ICO’s which are limited companies, often with investors. They possess both shareholders (venture capitalists and founders) as well as token-holders (ICO investors and founders).

This creates a moral hazard. The founders of these projects will also possess both equity and tokens. They will often possess a higher percentage of the total equity than of total tokens. (A traditional seed round is 10–25% whereas an ICO is generally 40–60%).

More importantly, founders have a legally enforceable fiduciary duty to their investors. They are obligated to act on behalf of their shareholders (read: maximize value for their shareholders) without a conflict of interest.

Together, these factors create a perverse set of incentives. Founders are encouraged to prioritize the interests of shareholders over token-holders. They distribute the value created by their platforms to shareholders rather than token holders. (For an example of this, see my earlier piece on Ripple.)

This is a serious and overlooked issue, especially when ICO’s are making capital investments that benefit shareholders using the millions of dollars they raised in an ICO but then distributing the returns on those investments to shareholders rather than token-holders.

The way this most commonly manifests is through projects charging their customers some kind of fee (either in FIAT or in the project’s native token). Then using the revenue generated by this fee “to pay for the maintenance of the project”.

The word “maintenance” implies salaries and operational costs. There is nothing to prevent these fees being paid out as dividends to the company’s shareholders. (And the fact that investors continue to invest in blockchain companies’ equity indicates they believe these cash flows are or will eventually be paid out as dividends).

Bitcoin cash maintenance funds being put to good use

Another way in which this manifests is in companies using ICO proceeds to purchase cash flow generating assets which are however not legally owned by token-holders, leaving them with little downside protection.

For instance, most blockchain real-estate fund tokens use ICO proceeds to purchase real estate pay token-holders a given yield on these assets. Shockingly, this yield is generally comparable to the yield received on purchasing equity or bonds in similar publicly listed real estate funds. However, the yield on the token should actually be much higher than the yield on equity/bonds as token-holders, unlike equity and bond holders, have no downside protection.

Indeed, it’s worth remembering that these funds are legally owned by their shareholders. In many cases, these funds will also take on additional debt to finance purchases and will therefore also have obligations to bondholders. Thus, in a scenario in which these companies are facing bankruptcy and go into liquidation, bondholders and equity-holders will be paid first with token-holders either being paid last (in which case they will receive pennies on the dollar) or not being paid at all.

Many of these funds tout themselves as being “real estate backed”. But unless they are a structured security token offering which specifies the legal status of token-holders, investors in these funds’ token would be better off investing in real estate bonds or equities where they can enjoy similar upside with added downside protection.

This doesn’t only apply to real estate funds but also to cloud mining projects, projects developing commercial IP, and generally any projects using funds from an ICO to make capital investments into assets which will be legally owned by shareholders rather than token-holders.

Solutions

Solutions here all involve tweaking the token model such that value is transferred from the company’s equity to its token and aligning incentives between founders and token-holders. This can be done in several ways:

(1) Add a buy-and-burn or profit share mechanism

Both of these involve giving the token a “yield” and transferring value from the equity to the token.

In the case of the token “buy-and-burn”, this was initially suggested by Vitalik and has been widely adopted since. Basically, it involves designing token models with “buy-and-burn” mechanisms in which the project uses some or all of the cash flows generated by its platform to purchase its own tokens and destroy them. The decrease in supply raises the value of all remaining tokens by the percentage of total supply destroyed.

Effectively, the project is distributing its cash flows to its token-holders, very similar to how an equity distributes cashflows to its stockholders through a dividend.

An example of this is Iconomi, a digital asset management platform which burns preset percentages of all fees collected and also produces quarterly reports outlining the number of tokens burned (crypto quarterly earnings reports).

A profit-share is very similar in spirit to the “buy-and-burn” in that it is providing the token with a yield and turning it into an asset that generates cash flows. This was initially suggested by Kyle Samani of Multicoin.

An example of this is Augur which pays REP holders for performing work for the network. REP tokens are like taxi medallions: you must pay for the right to work for the network. Specifically, REP holders must report event outcomes to resolve prediction markets.

Ideally, token models should ensure that companies burn/profit share as high a percentage as possible of the cash flow they’re generating in fees in order to ensure the value they’re creating accrues to the token.

(2) Founders should be paid alongside token-holders

Projects raising money in ICO’s should not be paying dividends to shareholders, as this poses a significant conflict of interest.

In an ideal scenario, founders of a crypto project should not receive salaries either but rather be paid through the yield generated by their token ownership.

This is the case with Rialto, for instance, in which both team members and token-holders are paid through a bi-yearly dividend. While this is ideal as it maximally aligns incentives between founders and token-holders, it’s not always possible. Some crypto projects, like startups, will take time to reach profitability and the team must be able to survive in the meanwhile. In this case, transparency becomes paramount, which brings me to my next point.

(3) Transparency

Companies that raise money through ICO’s should be extremely transparent about all aspects of their project, including investors associated with the project, whether these investors received equity or tokens, how much they received, salaries they intend to pay themselves and any other operational costs they’ll be paying out.

For an example of this done well, check out page 26–30 of Essentia’s whitepaper. It’s worth remembering that all costs must be deducted from the cash flows generated by the platform in order to arrive at the value which actually accrues to the token. After all, cashflows going towards paying salaries/rent are cash flows that are not being distributed to token-holders through a token burn/profit share.

This information should be provided in the whitepaper (similar to the information a VC would expect in a seed/series A round) and should also be updated regularly once the ICO is completed.

Hopefully, in the future, a standard will emerge for ICO’s, similar to the GAAP accounting standards for quarterly earnings reports that govern public companies. In them, ICO’s would be forced to update investors in a given format on key aspects of the project’s performance.

Until that time comes, we must self-regulate this by voting with our money and rewarding projects with better transparency with higher valuations. For an example of a project doing it right, check out Iconomi’s quarterly reports.

In the case of real estate funds and other security type offerings, these should be avoided unless they’re legally recognized security token offerings that clearly specify the token-holders’ legal status. This is particularly true in the case of bankruptcy or liquidation and as relates to other stakeholders such as bond and equity holders. Investors should also demand additional transparency from these types of projects, such as regular balance sheet updates.

(4) Good governance models

Many of these issues can also be resolved by having good governance models built into the token that allows token-holders to vote on key issues, including asset allocation.

For instance, a project’s assets can be held in escrow in a smart contract allowing token-holders to vote to liquidate and distribute all assets pro-rata to token-holders.

While this is currently impossible for assets other than cryptocurrencies, there are many projects working on registering and “tokenizing” real estate, gold, intellectual property and all sorts of other assets which will then be able to be placed into smart contracts.

Conclusion

The token economic model design is an extremely important and underrated area for both investors and founders of cryptocurrency projects to think about. A project with a weak token economic model may see its token price fail, even as the project itself succeeds, simply because the token is not capturing any of the value created by the project.

Stay tuned for my next blog where I’ll cover the other biggest problem with token models: high velocity.

If you’re interested in having your project’s token economics audited or discussing this further, feel free to get in touch with me through here or on Twitter.