Risk Management — The Introduction of Technology Regulated Funds
Melon funds are intended to be technology regulated funds. By this, we mean the smart contract code that makes up each fund should prevent the embezzlement of any investments made.
In the same way you don’t need an accountant to check the balances of the Bitcoin blockchain — you shouldn’t need a fund administrator (an entity that enforces the rules set by a regulator) when using a Melon fund. Of course, you could still use a fund administrator with a Melon fund if you wished to, but we’re here to try and improve upon what already exists.
All assets that exist within a Melon fund are held inside aMelon Vault. From there, we can code a set of rules into the Melon Vault determining how one can manage those assets.
We term this rule set as risk management, as one of its primary objectives among others is to minimize the risks an investor might face from embezzlement.
Risk management comes in the form of two Boolean functions which are inserted into the Vault in the form of an interface:
pragma solidity ^0.4.11;interface RiskMgmtInterface { function isExchangeMakePermitted(
uint orderPrice,
uint orderQuantity,
uint referencePrice
) returns (bool); function isExchangeTakePermitted(
uint orderPrice,
uint orderQuantity,
uint referencePrice
) returns (bool);
}
The code behind these interfaces will be run after the fund manager sends a transaction to the Vault contract specifying the order details (termed trade intention), and before the assets of the trade get sent to the pre-selected exchange (termed trade execution).
There are countless examples of different types of risk management with each of them having their advantages and disadvantages.
Below we categorized the most common types of crypto exchanges and discuss how risk management can be implemented for them.
Decentralised Exchange — Exchanges with on-chain settlement and an on-chain order-book
Examples of exchanges that fall under this category are OasisDex as well as Kyber or Bancor which include an on-chain pricing mechanism.
The power of exchanges in this category is that because they are on-chain, they can deeply integrate with to such an extent that embezzlement of funds becomes exceptionally difficult. The reason for this is that Melon can enforce the trade intention directly on the blockchain. This means that trade intention and trade execution becomes one.
The rules that are coded into the risk management module become unavoidable and can be enforced strictly, immediately and on each trade in real time.
For example, risk management can be implemented in a way that prohibits trading of any asset pair worse than the reference price (which is published on-chain by an oracle service such as Oraclize/CryptoCompare). This could be considered as enforcing the best price execution principle and is how traditionally unfavorable trading is prevented.
Another approach would be to allow trading no worse than 5% away from a reference price and assert that only 10% of the average 30 day, 24 hour volume of this asset pair can be traded on any given day. This is intended to give investors enough time to redeem their shares should it become apparent that the manager is trading poorly. At the same time, this allows the manager to have a great deal and more freedom in possible trade selection.
Yet another example would be to consider market impact of each trade and restrict trading to only have up to 5% negative market impact.
Hybrid Exchange — Exchanges with on-chain settlement and an off-chain order-book
Examples in this exchange category are 0xProject, EtherDelta, Swap, RaidEx and could include Ethfinex, OmegaOne and OmiseGo depending on their chosen settlement option.
Usually, exchanges in this category use some sort of state-channel-like approach to harness the efficiency of off-chain and security of on-chain.
As we have very strong security guarantees when interacting with decentralised exchanges, we want to replicate these for this type as well.
This works for any take order, since we have on-chain settlement. This means that when a Melon Manager takes an existing order from the orderbook, we can lookup all the parameters of this order and enforce that trade intention and trade execution are actually the same.
All checks can be done for example by submitting an orderHash (see for example 0x) — trade intention and trade execution become one again.
/// @dev Fills the input order.
/// @return Total amount of takerToken filled in trade.
function fillOrder(
address[5] orderAddresses,
uint[6] orderValues,
uint fillTakerTokenAmount,
bool shouldThrowOnInsufficientBalanceOrAllowance,
uint8 v,
bytes32 r,
bytes32 s)
public
returns (uint filledTakerTokenAmount)
{
...
}However, the challenge here is that there is no conclusive way of enforcing that the trade intention and the trade execution are the same when it comes to making orders with this exchange type.
The way Melon can solve this problem is by keeping track of each trade intention using an internal accounting system within the Vault, and then requiring the Melon manager to be staked in shares of their own fund.
Should the trade intention differ from the trade execution (in an way that is unfavorable for investors) then the Melon manager risks losing their stake.
The proof for above can be submitted on-chain using a “Proof of Embezzlement”.
Proof of Embezzlement
Simply put the proof of embezzlement for a given asset pair is whenever one of the following is true
- Has there been more sold than intended?
- Has there been sold at a worse price than intended?
When such a proof is successfully submitted, the fund automatically shuts down, which means that all trading and subscription activities are made unexecutable.
Whoever submits such a proof (this group of economic actors is commonly referred to as Fisherman) will receive the stake of the Melon manager.
Note that in case of Fisherman and Melon manager being the same person. While a Melon Manager wouldn’t necessarily lose any money in this case, they do stand to lose reputation — as embezzlement has been proven.
The nice thing about the Proof of Embezzlement is that it also works in the situation where a Melon fund gets hacked. In the case of a hacked Melon fund, the internal accounting system would inevitably be out of order with the actual holdings of the fund and thus Fishermen can trigger the Proof of Embezzlement function and shut down the fund. This would help mitigate longterm issues associated with such a smart contract (like with The DAO) where there was no way to stop additional malicious activity even though the reentrancy bug had been found and exploited.
Using the above staking concept and a simple on-chain submittable proof of bad behavior, we can now allow Melon managers to take assets out of the Vaults’ custody and even outside of the reach of any blockchain. As the Value of the Stake is always at least as large as what has been taken outside there is always an economic incentive to settle any open trading positions.
Centralised Exchange — Exchanges with off-chain settlement and off-chain order-book
Examples of exchanges in this category are Kraken, Bitfinex, Poloniex and many more.
Usually this type of exchange is coined as a centralised exchange.
The power of the previous approach is that there is no need anymore for any kind of lookup call for the on-chain settlement part (trade execution) when making an order. This is because all the accounting is done within the Melon Vault. This means that by using the same approach as in second exchange type — make orders — we conclude that Melon integrates natively with all the currently existing centralised exchanges as well!
Including Initial Coin Offerings (ICOs) in Melon Funds
Now… (as if the above wasn’t revolutionary enough) we have one more treat for you. Using a price feed that can dynamically add new assets, such as the asset to be issued by an ICO smart-contract, where the price of this asset would be the pricing function of the ICO smart-contract, we see that there is actually no difference in terms of security between trading on a centralised exchange and participating in a initial coin offering! This means that a Melon fund can itself participate in an ICO should it wish.
We thus also see a need for price feed modules specific for ICOs.
Reto Trinkler
Melonport’s CTO, Co-Founder and Chairman, Reto, is blockchain developer with background in mathematics from the world renowned ETH Zurich. He started developing Ethereum smart contracts immediately after their launch in 2015. He previously worked as a smart-contract developer at Brainbot Technologies (which is building the high-speed Raiden Network) and is host of Zurich’s Blockchain Hacklab. Before this Reto developed a profitable trading algorithm for sport betting exchanges in C++.
Github: https://github.com/retotrinkler
Twitter: https://twitter.com/reto_trinkler
