The core value proposition of blockchains is programmable ownership. This ability to imbue explicit and verifiable rights to a digital asset has created a Cambrian explosion of innovation. Along with this innovation, the blockchain industry, which we refer to as Web3, has also seen unprecedented wealth creation. In 2021, just 13 years after the launch of bitcoin, the entire industry had a market capitalization of almost three trillion dollars. DAO treasuries are now measured in the billions, with Uniswap alone controlling over $10B in assets.
This incredible wealth creation brings new problems to tackle. As an industry, we now have the resources of a nation state we can put to use in building out our decentralized future, but we also have the responsibilities of a nation state to manage those assets in a way that allows us to weather any storm in the future. In other words, Web3 now needs to get as good at asset management as we are in distributed systems engineering.
We can, of course, look to the traditional finance world for inspiration, but we should be wary of incorporating old ideas too readily. The legacy financial system was designed for a pen and paper world that hardly even exists anymore and has a questionable track record at best. So, while there are lessons to be learned from the traditional financial system, a more sensible approach would be to design natively for the Web3 ecosystem, using all the tools we now have at our disposal. That is what we have attempted to do.
Vanilla is a decentralized asset manager for Web3. It uses a prediction market-like mechanism (Juicenet) to dynamically assign and modify portfolio weights in a Balancer Managed Pool (Vanilla Investment Pool). Juicenet users take synthetic long and short positions in tokens, and the aggregate weights of these positions form target portfolio weights for the Vanilla Investment Pool. The system is self-improving in that it rewards Juicenet users (Juicers) who contribute positions that generate a positive return with more influence over the system while removing influence from users who contribute unprofitable positions. The system is also permissionless, and thus anyone can participate in Juicenet or contribute their capital to the Vanilla Investment Pool to be managed by Juicenet.
Image 1: Vanilla in a nutshell
Vanilla uses a dual token system to achieve the desired incentives. Juicenet users stake JUICE to take long and short positions, where profitable positions earn more JUICE, while unprofitable positions lose JUICE.
VNL is the governance token of the Vanilla system. Holders of VNL operate the Vanilla protocol and control the treasury. The treasury receives fees from the Vanilla Investment Pool and uses the fees to invest in the ecosystem and incentivize JUICE holders.
In 2016, TheDAO was the first attempt at decentralized asset management. It gained notoriety due to the vast amount of crowdsourced funding it received and the major exploit that caused a third of the funds to be locked, leading to an Ethereum hard fork to reclaim the funds. While the outcome was less than ideal, TheDAO demonstrated significant demand for decentralized asset management. Since then, many projects have attempted to tackle the problem in various ways.
Post-TheDAO, venture-capital-style asset management was pioneered by MolochDAO and later MetaCartel Ventures. These entities are comparable to syndicates, whereby a group of individuals or organizations pool their capital and vote on investments from the pool. These structures work well for small groups of people making a limited amount of due diligence heavy investments into mainly non-liquid tokens. However, they are not permissionless nor automated.
Enzyme Finance and TokenSets have focused on building out infrastructure for on-chain asset management, whereby anyone can effortlessly launch an on-chain, non-custodial (and in most cases permissionless) fund, which can invest in liquid tokens. These technologies make it easier to pool capital under a single entity responsible for managing the assets, but they do not provide any solutions for making asset management decisions.
Finally, there has been a lot of progress in automating and yield-optimizing lending activities. Projects such as Yearn Financeand CREAM allow investors to passively invest in “yield farming” strategies that programmatically allocate capital to wherever the highest yields are to be found. These services help optimize existing portfolios, but they don’t assist in portfolio construction or provide solutions for asset management.
A largely unexplored area is a decentralized asset manager for liquid tokens, which could automatically construct and manage a dynamic portfolio of assets. While there are already assets, which resemble index funds, such as DeFi Pulse Index, they are not automated and use static techniques for determining portfolio weights, such as weighting by market cap. We imagine a dynamic system where portfolio weights are automatically determined using as much information and nuance as is available in the market, which, if successful, should yield considerably higher returns while maintaining a similar risk profile to static techniques.
The Vanilla decentralized asset manager is composed of three distinct systems:
Vanilla Juicenet is a synthetic marketplace, which functions a bit like a prediction market. Juicenet users (aka “juicers) take synthetic long and short positions on tokens using JUICE. These positions are then aggregated to form a token-weighted portfolio. The Vanilla Investment Pool uses this portfolio as target weights and rebalances the pool continuously as the aggregate portfolio weights change in Juicenet.
The system rewards users whose synthetic positions are profitable by minting JUICE and punishes those that make a loss by burning JUICE. By doing this, the system slowly provides users who consistently make profitable synthetic trades with more influence over the weights of the Vanilla Investment Pool.
Juicers take synthetic long and short positions on tokens with JUICE - similar to traders who buy and sell in the market. A position is opened by staking JUICE, and it is closed by unstaking. Like investing in real tokens, profit and loss - measured in USDC - are calculated continuously for all open positions based on the price movement of the underlying token. Upon withdrawal, JUICE is minted/burned according to profit/loss made.
For a position on a token opened at a time , the return at a time is calculated as:
For example, a juicer might stake LONG UNI with 100 JUICE. When the price of UNI subsequently increases 50%, the user’s stake is now worth 150 JUICE.
For short positions, return is calculated as an inverse: Let’s assume the juicer has staked SHORT UNI with 100 JUICE. If the price of UNI increases 50%, the juicer’s stake is worth 50 JUICE. If the price increases 100%, the juicer has lost the entire stake. In traditional markets, short positions can theoretically have an unlimited downside if the trader keeps adding collateral. In Juicenet, juicers cannot add collateral, and thus the maximum that a short position can lose is 100% of the initial JUICE stake.
The purpose of Juicenet is to generate target portfolio weights for the Vanilla Investment Pool. The weights are generated by aggregating the individual token-weighted positions in the following way:
Juicenet has juicers and tokens. For a token , summing across all juicers, we define:
Therefore, when summing across all tokens in Juicenet, we get:
As short positions are not yet available for most assets, the Vanilla Investment Pool cannot replicate the Juicenet portfolio 1:1. Thus we need to convert the Juicenet portfolio into the Pool’s portfolio in a way that makes tradeoffs between how accurately the Pool’s portfolio reflects token-specific net sentiments (= how bullish or bearish Juicers are towards a token on average) versus the total net sentiment (= how bullish or bearish they are towards the market). In this conversion, the loss of some information (alpha) is unavoidable.
Since crypto-markets are very volatile, the initial configuration of the Vanilla Investment Pool will track the market first and individual tokens second. This will be accomplished by the following three rules:
Rule 1: The total % invested in longs equals the market exposure of the Juicenet portfolio if the exposure is positive. If the market exposure is negative or zero, the weight for longs is zero.
Here, market exposure refers to the percentage of the portfolio that is exposed to market volatility. For example, assuming that portfolio of assets move hand in hand with the market (equal betas), if 75% of Juicenet stakes are in longs, and 25% are in shorts, the market exposure is 50% (=75%-25%), and thus e.g. a 20% drop in the market, will decrease the portfolio value by only 10% (=50%*20%). Similarly, if 25% of stakes are in longs, and 75% are in shorts, the market exposure is -50%, and thus e.g. a 20% drop in the market, will increase the portfolio value by 10%.
Rule 2: The total % invested in stablecoins (USDC) equals what’s left after allocating to longs.
Rule 3: Allocation to longs is distributed between net long tokens according to their volume-weighted net sentiment. Here, volume weights are used to measure confidence: we have more confidence in the net sentiment of a larger volume token (e.g. ) than in that of a smaller volume token (e.g. )
Therefore, we get:
These aggregate weights are then passed on to the Vanilla Investment Pool as target weights of the portfolio.
Table 1: Illustrative portfolio weights at time t created by the Juicenet for the Vanilla Investment Pool
|Input from Juicenet||Output to Vanilla Pool|
|Net sentiment |
|*Market exposure: N/V = 75/225 = 33.3%. Thus, 33.3% to longs, the rest to stables:||+66.7%||STABLES|
The Vanilla Investment Pool is a Balancer Managed Pool controlled by Juicenet. Anyone can contribute their capital to the pool to be managed by the Vanilla system. In exchange, they get LP tokens of the pool, which they can trade freely on DEXs and other venues.
Balancer Pools work with internal portfolio weight targets. When the target weight of an asset increases, the pool offers a higher price to buy that asset. If the target weight of an asset goes down, it offers to sell the asset at a lower price. By doing this, the pool creates an incentive for arbitrageurs to balance the portfolio. Balancer also allows pools to specify a time period over which the pool slowly raises or lowers prices to achieve the desired weights.
The Vanilla Investment Pool continuously updates its target weights according to the aggregate weights in Juicenet and specifies a gradual rebalancing period (e.g. two weeks) for achieving the weights. This rebalancing period resets every time new target weights are submitted, leading to a dynamic where the Vanilla Investment Pool is continuously “catching up” to Juicenet. By specifying a rebalancing period to achieve the target weights, the Vanilla Investment Pool avoids making dramatic short-term moves while still reacting to changes in Juicenet’s aggregate weights promptly. This mechanism also makes the system considerably harder to manipulate or front-run as any aspiring front-runner is subject to the whims of the market while simultaneously competing with other arbitrageurs to try to extract value from the system.
In the initial configuration, the Pool will hold a maximum of 50 tokens in its portfolio, comprised of tokens with the largest volume () in Juicenet.
The VanillaDAO is the governing entity of the Vanilla system. It is controlled by VNL holders and has the following functions:
Vanilla’s VNL token is the governance token of the Vanilla system. The value of VNL is a function of three features: the value of VanillaDAO governance, its assets under management, and its future fee streams from the Vanilla Investment Pool. The current supply of VNL is ~13 million tokens. It is distributed between different stakeholders in the following way:
VNL has had no pre-mine. All VNL in circulation has been created via profit-mining except for those minted for the DAO by the community.
Profit mining is the mechanism used in Vanilla v1, by which the VNL governance token is created and distributed to miners according to their investment performance. Users trade tokens via the Vanilla interface and mint VNL when their trades make a profit.
Profit mining will continue until the community decides to phase it out, and thus the supply is likely to continue growing. However, as with most mining mechanisms, profit mining becomes more challenging over time, and thus the increase in the supply will be less and less significant.
Vanilla’s JUICE token is used to take synthetic long and short positions in Juicenet and, by doing so, generate the aggregate weights used by the Vanilla Investment Pool.
JUICE gets minted or burned based on the profitability of Juicenet users: if juicers in aggregate make X% of profit, the supply increases by the same X%. Similarly, if juicers in aggregate have a negative return of Y%, the supply decreases by that same Y%. Due to this dynamic, the supply of JUICE is expected to be highly volatile. For example, when many people profit against the USD during bull markets, the JUICE supply can increase rapidly. On the other hand, during periods of low profitability, the JUICE supply could shrink.
Given that the greatest JUICE rewards are earned by users who consistently make the most profit, we expect the supply to inflate on average over time. Due to the expected inflationary nature of the JUICE token, holding JUICE without participating in Juicenet is likely a poor strategy. The VanillaDAO will periodically purchase JUICE from the market and use the purchased tokens to provide liquidity to incentivize users to participate in Juicenet. Since the VanillaDAO will not sell JUICE, this action will increase the value of JUICE and thus create an incentive to participate in Juicenet while simultaneously increasing the token’s liquidity.
The community plans to airdrop JUICE to VNL holders 1:1 alongside the launch of Vanilla v2. The VanillaDAO will not receive JUICE in the airdrop.
The initial configuration of the Vanilla system will be entirely on-chain, and the actions taken by participants are public.
This section breaks down foreseeable unhealthy situations that result from the system’s public nature and presents strategies for resolving them.
It’s worth noting that these situations may never occur, and the mere existence of a viable and publicly known antidote may prevent them from occurring.
Table 2: Summary of attacks and their impact on Vanilla stakeholders
|Front-running Juicenet||No impact||Low impact||No impact|
|Oracle Delay Abuse||Unfair JUICE minting||No impact||No impact|
|Price Manipulation||No impact||Low impact||Low impact|
|Leeching||Low impact||No impact||Less fees|
Front-running is a term generally used for a circumstance where some entity acquires prior knowledge of a trade happening and can execute the same trade faster than the original trader. This entity then hopes to sell the asset they’ve purchased directly or indirectly to the original trader at a profit.
Front-running an on-chain trade is relatively trivial in principle. Every trade executed on a decentralized exchange like Uniswap involves submitting an Ethereum transaction, which first appears in the mempool before being confirmed. Anyone can watch the mempool and thus gain prior knowledge of trades, which they can then front-run by submitting the same trade but applying a higher gas fee to the transaction, hoping that their transaction will be processed by miners faster than the first one. Once the original trader’s transaction has been confirmed, the front-runner immediately sells the asset back to Uniswap at a profit. This is known as a sandwich trade.
In Vanilla, a similar kind of front-running is also possible, albeit not very effective. A front-runner could watch the mempool for Juicenet transactions, which update the target weights of the Vanilla Investment Pool, and quickly purchase those assets. However, the Vanilla Investment Pool doesn’t immediately buy an asset from the market, which would raise the price, but rather slowly begins to increase the price at which it is willing to buy the asset over the rebalancing period (e.g. two weeks) until it achieves its target weight or the target weight is updated again. The front-runner, then, cannot immediately sell the assets it has purchased for a profit but needs to wait for the price to increase, during which market volatility may render the trade worthless. Furthermore, the target weights might update again at any moment in the opposite direction, causing the same outcome for the front-runner. In fact, a sufficiently large front-runner could even be the cause of a target weight adjustment: the price increase might lead Juicers to close positions in an asset before the Vanilla Investment Pool has adjusted the price by any meaningful margin.
Finally, if a Juicenet transaction in the mempool would cause the market to move, it would create an incentive for Juicers to begin “front-running” their own Juicenet transactions. In essence, Juicers would purchase an asset before submitting a Juicenet transaction, knowing that prospective front-runners will push the price immediately when the transaction is visible in the mempool. Once the price was pushed up, the Juicer would sell the assets they’d purchased at a profit. Given the slow reaction to target weight changes, this situation would have a relatively negative impact on the Vanilla Investment Pool. Yet, it would negatively impact the prospective front-runner, who would consistently pay a premium for assets only to see his assets drop in value moments after.
Oracle delay abuse refers to front-running the Chainlink oracles Juicenet uses to calculate net profit. On-chain oracles update their price with a slight delay relative to the off-chain market, creating a window of opportunity for the prospective oracle front-runner. To execute this, a Juicer would watch for a significant discrepancy between the off-chain market price and the on-chain oracle price and attempt to get a Juicenet position submitted before the oracle updates, knowing the updated price will be higher, guaranteeing a profit measured in JUICE terms.
Abusing the oracle in this way has no direct impact on the Vanilla Investment Pool since the entire event happens in a very short window of time. However, if left unchecked, it provides an avenue for generating risk-free JUICE, which is unhealthy for the system. The Vanilla system prevents this behavior with a simple mechanism: fixed minimum profitability must be achieved before any JUICE is minted. This means that a prospective abuser must find a dramatic discrepancy between the on-chain price and the market price. This situation could occur but is quite unlikely given the speed and frequency of oracle price updates happening on Polygon.
We don’t anticipate oracle delay abuse to be a meaningful issue, but if it were to become one, we could mandate a minimum holding time for positions in Juicenet. This mechanism wouldn’t prevent oracle abuse, but it would prevent the abuser from easily profiting from it, given they would be at the mercy of the market for the duration of minimum holding time.
In Vanilla, price manipulation refers to a situation where a Juicer alters the target weight of a token to either purchase that token at a discount or sell that token for a premium to the Vanilla Investment Pool. Essentially the Juicer is attempting to manufacture an artificial arbitrage opportunity, which it plans to exploit.
While price manipulation is possible, it is challenging to execute successfully in practice. As with front-running, the difficulty arises from the fact that the Vanilla Investment Pool doesn’t immediately purchase or sell the assets into the market, but rather slowly adjusts the spot price over the gradual rebalancing period (e.g. two weeks) to eventually achieve the desired portfolio weights.
For the Juicer to succeed in exploiting the arbitrage opportunity, they must first wait for the price to adjust while competing with all other arbitrageurs to capture the value of the arbitrage. During this period, the Juicer is at the mercy of market volatility and thus has no guarantee that the arbitrage will succeed.
In theory, the AUM of the Vanilla Investment Pool could become so large that any trade initiated could move the market so dramatically that all the volatility is in effect “swallowed up” during the rebalancing period, ensuring a near-guaranteed profit for the Juicer. However, given that the tokens available in Juicenet are among the most liquid assets available and arbitrage opportunities can be executed using any available liquidity pools, whether centralized or decentralized, this scenario corresponds to a truly staggering scale. If this scale was indeed achieved, some minor adjustments would need to be made to ensure Juicenet positions don’t become self-fulfilling prophecies. Either the minimum holding period of Juicenet positions would need to be extended, or the minimum profit at which JUICE is minted would need to be increased to correspond to the immediate impact the Juicenet position has on the market or both. Furthermore, Juicenet has an existing mechanism that provides some defense against this sort of behavior: shorting. By taking short positions on a token, Juicers can effectively nullify the influence of a long position on any given token.
Even with these adjustments, it’s likely that this ability to move markets would cause a bidding war for JUICE, but this would have little to no impact on the Vanilla Investment Pool, given the Juicenet system always rewards influence to better investors over time. Let’s say a large treasury was buying JUICE to stake on their own token. They could do this and cause the Vanilla Investment Pool to purchase this token, but if the position were ultimately unprofitable, they would lose the influence that allowed them to take the position in the first place. Of course, they could combine this with front-running their own Juice position and thus benefit from the increase in market price, external to Juicenet. Still, assuming a long enough minimum holding period in Juicenet, this would quickly become prohibitively expensive unless the positions they were taking in Juicenet ended up being profitable.
Leeching refers to the act of extracting value from the Vanilla system while providing nothing in return. In practice, this means replicating the Vanilla Investment Pool portfolio outside of the Vanilla system and thus avoiding paying fees to the VanillaDAO. This setting is similar to front-running Juicenet as described in section 4.1, as in both cases, information about Juicenet trades is being used outside of the Vanilla system.
However, leeching is not equivalent to front-running. A small-scale leecher with a long-term investment horizon could benefit from replicating the portfolio weights without resorting to any short-term manipulation. For example, a leecher could simply maintain a relatively equivalent portfolio of assets as the Vanilla Investment Pool without interfering with the operations of the Vanilla system. Nevertheless, it allows the leecher to benefit from the market insight generated in Juicenet while avoiding paying fees to the VanillaDAO.
A larger-scale leecher could set up a competing Balancer Managed Pool and a keeper system, which watches for Juicenet events and then submits equivalent target weight changes to this side pool. The transaction costs, which in the Vanilla system are paid by the Juicers, would need to be paid by the leacher in addition to the costs of building out the keeper infrastructure. Thus it’s likely that the pool would need to charge higher fees than the Vanilla Investment Pool. Therefore, it seems unlikely that a competing Balancer Pool would enjoy widespread popularity unless Vanilla Investment Pool fees were too high, in which case the simple solution would be to lower them to a sustainable level.
Furthermore, even if such a competing pool achieved a degree of popularity, the existence of such a pool would effectively increase the total amount of capital that Juicenet is managing. If the amount of capital leeching were relatively modest, it would likely have almost no effect on market pricing and thus also on the Vanilla Investment Pool. It would, however, mean lower fees for the capital managed by Vanilla.
Given that the amount of capital leeching in this scenario is modest, the fees lost would not be significant. If the capital were substantial, we would arrive at the same outcome as described in section 4.1, where Juicers begin to front-run their own trades, knowing that the simple act of submitting a transaction to Juicenet positively impacts the price.
Suppose all the measures described above to mitigate manipulation, abuse, and leeching in the system were to fail. In that case, the Vanilla system has a fallback plan: hide the portfolio weights generated by Juicenet and auction them to a small group of users, who can then utilize them in whatever way they wish. In essence, this means the portfolio weights would be used mainly off-chain, likely in centralized exchanges.
Here we describe a simple example scheme for hiding portfolio weights and auctioning them to a limited set of users (subscribers). The method combines public-key cryptography with a commit-reveal scheme to conceal the portfolio weights from the public and share the weights with the subscribers. To achieve this, Juicers publish encrypted weights on-chain, accompanied by a JUICE stake, to create a verifiable track record of weight changes. Once the Juicer wishes to withdraw their JUICE, they reveal their private key, thus revealing their weight change history. This allows the Vanilla system to compute the rewards or penalties and settle the JUICE stake.
Each slot for receiving the portfolio weights in real-time is auctioned periodically. Each user participating in the auction submits the proposed payment for the period and shares their public key. Once the subscribers have been identified, each Juicer publishes their weight changes on-chain, encrypted with each of the subscribers’ public keys.
This mechanism allows the effective hiding of the portfolio weights from the public while allowing subscribers to receive weights in real-time, which they can then use to manage a portfolio.
Hiding and auctioning the weights would be an unfortunate outcome as it would outprice smaller investors from benefiting from the market insight generated by Juicenet. Smaller inventors could still pool their money and collectively purchase the Juicenet portfolio weights. Still, it would be considerably more complicated than simply contributing capital to the Vanilla Investment Pool.
We expect that the existence of a viable plan to hide the weights, combined with the various unfavorable outcomes for bad behavior described in the previous sections, will be enough to prevent such behavior from happening altogether.
Furthermore, the emergence of private computing environments will eventually allow us to implement a system that hides the portfolio weights while allowing anyone to participate.