Participation & Protecting Participants
Lowering barriers to entry by closing attack vectors
Recently, we’ve taken time to review the investment mechanism behind the Melon protocol.
In particular, we considered how to protect both managers and investors from particular situations that bad actors may attempt to exploit. This post will focus on how individuals will participate in a Melon portfolio, and our recent upgrades to this process.
Special attention is given to one attack vector, its nature, and our plan to eliminate it.
How participation works right now
As it stands, the main investor interactions with a Melon portfolio are to subscribe and redeem.
“Subscribing” is allocating shares to an investor, in exchange for digital assets.
“Redeeming” is the withdrawal of digital assets in exchange for an investor’s shares.
Note that investors are free to perform these actions at any time, within the limits imposed by the manager (e.g. whitelisting, or maximum portfolio size).
From here, we will give the name participation to the combined subscribe/redeem abilities.
Melon (MLN) as a native usage token
In discussing the changes described here, we elaborated on our decision to give MLN the “usage token” role on our platform. In other words, the default usage token used to participate in a management strategy (i.e. subscribe ) will be Melon tokens, and share prices will therefore default to being calculated in terms of MLN.
This further establishes MLN as a usage token.
With this out of the way, let’s commence our dive into a practical problem, and how to fix it.
Subscribe/redeem arbitrage attack (getting more technical)
Now, consider that the share price must be provided for an investor to be able to transact. This share price is automatically calculated from the collective prices of the assets under management. Thus, price data for these assets is needed to allow investors to participate in a fund.
The present on-chain nature of a fund means that participation occurs with a maximum time resolution equal to the block time. That is, the quickest one can invest or redeem is by the next block. Also understand that pricefeed oracles bring price data onto the blockchain at regular intervals, allowing for re-calculation of share price.
If we consider the reality that, the instant after on-chain price data is updated anyone may simply look up more current data from a real-time pricefeed, then it becomes apparent that individuals have an information advantage over the fund, until prices are updated again.
In the image to the left, the orange lines denote pricefeed updates. Thus, between these updates the share price stays the same.
Now, look at the green line. We can see that, at this point, the share price (red 1) is much higher than the actual value of a share (blue).
By redeeming their shares here, a dishonest stakeholder could benefit from knowing the true price before it arrives on the blockchain and lowers the effective share price (red 2).
Note also that a similar attack could be performed via subscribing, where the participant buys shares that he knows are more valuable than their effective price form the last pricefeed update.
Further, these subscribe/redeem arbitrage attacks are not limited to investors, as the manager can invest in her own fund as well, and be dishonest in the same way as regular investors.
This behavior resulting in an unfair advantage is unacceptable, of course, and would lead to distrust between participants, not to mention a wholly ineffective pricing mechanism. Moreover, this behavior would have a negative effect on the fund’s actual value as well, so fixing this problem would protect all staked parties — both investor and manager alike.
Closing the information gap & preventing such an attack
We can mitigate the impact of this attack insofar as we can narrow the information gap between the participant and the blockchain.
That is to say, if an attacker has no foreknowledge with respect to the blockchain, then no attack can occur, and less-advanced knowledge makes for a proportionally weaker attack.
One way to achieve this is to have the subscribe and redeem functions perform a kind of committed limit preorder, where funds are (1) locked into an order which is (2) filled automatically when (3) the price is within the limit, and (4) at least one full “pricefeed interval” has passed (i.e. two orange lines are passed on the diagram further above).
Locking funds into the order is necessary, as the participant might send out dozens of uncommitted orders at differing prices, with no intention to execute most of them.
Combined with automatic execution, this means the manager cannot simply refuse to send a transaction to initiate an unfavorable dishonest trade.
The traditional limit order functionality is present to protect honest participants, since the order will be executed in some time, and there is an inherent risk to this.
Finally, pacing the orders with the pricefeed ensures that the participant and fund are on equal footing when it comes to price information, which was the foundation of the attack.
But execution isn’t automatic!
Indeed, the above solution depends on the ability to automatically run code in response to some state change (e.g. a time interval passing).
Here we arrive at another interesting watermelon helmetproblem: how do we do this when an agent is not incentivized — or is even disincentivized — to initiate some contract code.
Thankfully, this is not a new problem, and there is already discussion and implementation on the subject. Looking into the future, there is also promise in the virtual workers paradigm, proposed by 1protocol (e.g their snow worker).
In the end…
We have discussed a potential attack angle for dishonest participants in the form of subscribe/redeem arbitrage. We analyzed the nature of the attack, and one way to implement participation which would mitigate its effects. Finally, we briefly mentioned some potential solutions for automatic code execution, which our implementation would likely depend on.
There will almost certainly be some changes to the way we intend to mitigate this problem, but our solution is still likely to follow the paradigm described herein.
Concerns over usability, practicality, and security may appear to conflict as we move forward, but building a platform where these interests are not mutually exclusive is the engineering challenge we promised to undertake.
Travis Jacobs — Developer at Melonport
For previous reference around Melon usage functionality and design you can refer to this blog. As always, this blog details the team’s latest thinking around the Melon Project may change throughout the course of development.
