Methods for implementing a stabilized token economy

Michele Mostarda
Feb 9 · 9 min read

This article presents some possible technical solutions to stabilize the economy of a token, even with a reduced market cap and therefore more subject to market manipulation and instability. Different approaches will be analyzed, the main proposal is based on the introduction of the concept of friction, i.e. the reduction controlled by the Smart Contract of the velocity of the token during the transfer between the wallets.

Some of the ideas proposed are inspired by the analysis of curation markets, where the value of a decentralized asset is mainly determined by the interaction of the token holders with the same and not by the external market.

The theoretically analyzed approaches are able to mitigate the effects of market alteration techniques such as pump & dump, situations linked to the nervousness of investors such as FOMO (Fear Of Missing Out) panic sales and all the other problems that have afflicted token markets in the first phase of the ICOs, and which may plague the secondary STO market.

The methods described below can be applied to both utilities and security tokens. Tokens implemented with these methods can be more easily exchanged on DEX (DEcentralized Exchange) but also remain compatible with centralized exchanges.

To correctly use these methods with token utilities underlying decentralized digital services, it must be possible to distinguish between user exchange transactions (buying and selling) and use of the service. This can be easily achieved through whitelisting address or by defining token consumption methods.

Market manipulation methods

Many tokens have a market cap small enough to be manipulated by a few or a single token holder, in more sophisticated cases token whales can coordinate to perform manipulations, synchronizing their strategies.

One of the most famous methods of market manipulation is pump & dump, a fraud historically applied to security markets which involves artificially inflating the price of a stock through the release of false positive information in order to be able to sell the stocks purchased at a lower price. In the world of cryptocurrency with unregulated markets and with the token price purely established by the trading volumes, pump & dump can be achieved with contained risks.

The phenomena of manipulation of a token economy can however be mitigated by introducing a mechanism for limiting the volumes of tokens moved, in part similar to those implemented by the regulated stock markets, where the excess and fall of a stock price determines the suspension of the same.

Moving tokens between accounts in a trade determines a token price and what is called a token velocity.

In order to obtain a stabilizing effect for the economy of a token, there can be two approaches:

  • Velocity Stabilization: the velocity of the token is controlled through negative feedback on the volumes that adjusts the transfer costs, this solution can be self contained in the Smart Contract of the token;
  • Price Stabilization: the Smart Contract monitors the average price on the exchange and intervenes by suspending the transferability of the token if the token price changes exceed a predetermined threshold, this solution requires access to the token price, necessarily provided by one or more oracles.

The stabilization of the token economy can occur through two feedbacks:

  • friction: a factor that determines the proportional loss of tokens (friction loss) during the transfer, the greater the friction the greater the amount of tokens that are lost if you want to lead to end the operation;
  • suspension: the token transfer is suspended for a period of time and no one can trade.

Both types of feedback have cons, let’s examine which ones. The friction is more complex to implement and integrate with the exchange but also more equitable in terms of the token holder treatment because it does not give priority to those who perform multiple transaction attempts but to those who offer greater loss.

The suspension is easier but instead opens the way to subterfuge based on the prioritization of transactions, that can be partially mitigated with a control on the Smart Contract.

In case of feedback based on friction, part of the transferred tokens are lost by the sender, these tokens can have two destinations:

  • token burn: the tokens sold are immediately destroyed, causing an increase in the value of the remaining ones;
  • token redistribution: the tokens transferred are accumulated and at regular intervals redistributed proportionally to the token holders. In the long term, this method prevents depletion of the number of tokens in circulation, ensuring sufficient granularity but is more expensive to implement.

Velocity Stabilization

The first, simpler, self-contained approach in the token management Smart Contract and compatible with existing standards, consists in inserting a logic of friction on the volume of tokens that can be moved in the unit of time.

Since many speculative schemes on tokens are based on the movement of large volumes in close time intervals, if you need to move volumes that exceed the allowance on a time basis you must be willing to accept a token loss proportional to the velocity with which you want to move, in this way it is possible to convert harmful behaviors of some stakeholders, in a price gain (in case of token burn) or redistribution toward less speculative holders.

For example, a Smart Contract that implements velocity stabilization, could accept total token transfers up to a cumulative volume of 5% of the circulating base within 30 days. Any attempt to move volumes greater than 5% of the token during the same time span would entail the request for a percentage loss on the transaction, gradually increasing on the volume moved over the time span.

Price Stabilization

The second proposed approach consists in performing a control, operated by the Smart Contract managing the token, of the price fluctuations of the token itself, activating automatic suspensions of transferability in order to counteract any uncontrolled volatility.

This approach entails the need to provide token pricing to the Smart Contract, which requires for centralized exchanges the usage of oracles.

Fee escalation

The adoption of the described approaches could determine token holder fee escalation scenarios which, in order to ensure a transfer slot in the available time window, would be incentivized to use very high fees in order to prioritize their transactions. However, for small markets and sufficiently large time windows, this risk can be mitigated with an appropriate dimensioning of the restriction parameters. For more complex scenarios, control criteria could be introduced to discourage this escalation: the Smart Contract could measure the deviation between the fees applied by a transaction for a transfer and the current average fee of the underlying network, even if to obtain the latter information would require an oracle. At this point the Smart Contract could impose a rule according to which transactions with fees above the average must, in order to be accepted, increase the loss percentage of the transferred tokens.

Technical details on the control of the Market Value

In this paragraph we will deepen some technical details on the velocity and price stabilisation methods for the Market Value.

One of the fundamental parameters that influence the market value of a token is velocity.

The token velocity is defined as the ratio between the volume of tokens moved in the unit of time (for example 30 days) and the average value of the token (whose instantaneous value is the market cap).

Velocity = Total Transaction Volume / Average Token Value

From this definition we deduce that the average value of the token depends on the ratio between the average value of the token

Average Token Value = Total Transaction Volume / Velocity

This equation can be rewritten as:

Where

M = value of the basic asset token in the unit of time

P = the price of the token in the unit of time

Q = the amount of token handled in the unit of time

V = the average amount of times that a token is handled in the unit of time

From this formula it is clear that the average value of a token is inversely proportional to the velocity of the same, and therefore in order to stabilize the value of the asset base market, it is necessary to contrast the increase in velocity with negative feedback that leads to an increase in price (Velocity Stabilization).

Velocity Stabilization implementation. In fact, suppose that the Smart Contract monitors the Q / V ratio, i.e. the average amount of tokens moved per transaction, and that it calculates a friction parameter that establishes how much percentage of the tokens must be lost in a transaction in order for it to be accepted.

Token holders who want to perform transactions with high volumes (Q) in moments of high friction, contribute to increasing the Q / V parameter, but are forced to loose proportional higher percentages of tokens to complete their operations, the destruction of these tokens will result in an increase in the P price, balancing the total economy.

In Velocity Stabilization we therefore work by observing Q / V and we intervene with a loss that influences P in order to stabilize the market economy.

Price Stabilization implementation. Alternatively, you can leave the velocity free and intervene directly with the suspension of the exchanges when the fluctuations of the price P exceed the preset values.

In Price Stabilization we therefore work by observing P and we intervene with suspensions that influence Q / V to stabilize the market economy.

Integration problems with exchanges

The methods proposed in this article must be able to integrate to token exchanges, which can be centralized or decentralized.

Decentralized exchanges don’t present particular problems, in fact each exchange is regulated on chain and the Smart Contract can exercise direct control over the atomic swaps of the token.

Centralized exchanges, on the other hand, since they have an off-chain operating phase, must be compatible with the friction logic. Centralized exchanges usually operate on chain only during deposit and withdrawal phases, all exchange operations performed between users are virtualized, all movements are compensated and finally made available to the holders. In order to be compatible with friction, centralized exchanges should queue and defer their users during the withdrawal phase based on some priority or allow users to specify a loss to speed up their operations.

The Smart Contract

In this paragraph we mention how Smart Contracts could be technically implemented to be able to operate the strategies illustrated above and their compatibility with the main existing standards.

Compatibility with ERC20

Compatibility with ERC20 can be guaranteed by extending an interface that implements the following methods.

  • A method friction function () public view returns (uint) that returns a percentage value ([0, 100]) that indicates, given the current volumes, the minimum amount of tokens of a transaction that need to be lost for it to be successful, the higher the loss percentage, the higher the priority the transaction receives.
  • A method function transferFrictioned(address recipient, uint tokens, uint loss) public returns (bool), where the token holder can specify, in addition to the classic destination address (recipient) and the amount (tokens), also the maximum amount of token that he is available to lose (loss) to guarantee the transaction , depending on the friction.
  • A method function transferFromFrictioned (address spender, address recipient, uint tokens, uint loss) public returns (bool) that allows the token holder to make a delegate transfer, with loss logic.

The use of transferFrictioned and transferFromFrictioned does not compromise the semantics of the ERC20 interface, which can also reimplement the methods transfer and transferFrom to use the corresponding friction methods by applying standard friction, as shown below:

transfer (address recipient, uint tokens) public returns (bool) {

uint frict = friction();

uint loss = SafeMath.mul(SafeMath.div(tokens, 100), frict);

return transferFrictioned(recipient, tokens, loss);

}

transferFrom (address spender, address recipient, uint tokens) public returns (bool) {

uint frict = friction();

uint loss = SafeMath.mul(SafeMath.div (tokens, 100), frict);

return transferFromFrictioned(to, tokens, loss);

}

Compatibility with ERC777

The ERC777 improves the usability of ERC20 by introducing the Operator.

Again it is sufficient to define three new methods which can then be implicitly invoked in standard methods.

function friction () public view returns (uint256);

function sendFrictioned (address to, uint256 amount, uint256 loss, bytes calldata data) external;

function operatorSendFrictioned (address from, address to, uint256 amount, uint256 loss, bytes calldata data, bytes calldata operatorData) external;

Compatibility with ERC777 also guarantees compatibility with ERC1400 and derivatives.

References

Understanding the Dangers of Token Velocity

Introducing Curations Markets

Michele Mostarda

Written by

Blockchain advisor and entrepreneur, software engineer with strong experience in startups, crowdfunding, big data and machine learning.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade