The Orbs Liquidity Nexus protocol introduces CeFi liquidity to DeFi.
Now, take any DEX, whether it’s SushiSwap or PancakeSwap, and choose a popular pool like ETH/USDC or BNB/BUSD.
The CeFi capital provides the stable side — USDC or BUSD. The DeFi capital provides the crypto side — ETH or BNB. Now, let them farm together.
Read part 1 and part 2 of this series first.
···
The concept of DeFi vaults was popularized by Andre Cronje under yearn.finance and was an instant hit with the DeFi community. The idea is simple — allow multiple farmers to supply liquidity together and manage the position automatically through smart contracts in order to increase yield efficiency with actions like compounding (taking the daily rewards, selling them back to the base liquidity assets and increasing the position to generate compound interest).
A notable vault project that followed is harvest.finance which expanded on the idea with a holistic token economy. Harvest’s staking token FARM captures 30% of the farming profits as a fee, but is also used to incentivize more farmers to participate by distributing it in addition to the underlying yield to increase total APY.
Aggregated yield farming vault products have become very popular on BSC as well, with notable projects like acryptos and autofarm.network — the leader of the pack with over $1.5 billion of mind-boggling TVL at the time of writing.
So what does a classic double-sided vault look like? Let’s take one that is farming ETH/USDC liquidity rewards on Uniswap/SushiSwap/1inch:
The idea we’ve been building towards in this series of posts is single-sided farming. One of the potential methods to introduce this concept to relevant target audiences is through a vault. Since vaults cater to Type A participants (see previous posts for definition), the vault will only represent one of the sides — the ETH side.
The other side, USDC in our example, is provided by Type B participants. Since they’re not frequent travelers in DeFi space, we can rely on the Liquidity Nexus protocol to bridge them in.
What would that look like?
If you have experience with DeFi, you probably know that ETH-only strategies are not common. Even when they’re found, they usually offer low APYs. This is the current ETH-only strategy on harvest.finance:
As you can see, the internal APY of the vault is quite low — only 0.41% (the rest is FARM rewards incentive to participate). The straightforward strategy employed by this vault is supplying the ETH as collateral to Compound, and earning both the supply interest and the COMP rewards. This also explains why the APY is relatively low, lending ETH doesn’t pay very much.
Using the Liquidity Nexus protocol, we can develop a new type of ETH-only strategy that generates much higher APY. The APY should be even higher than double-sided farming of ETH/USDC on Sushi. Why? Because our single-sided tokenomics favor the ETH side in rewards and give it more than half, in exchange for taking more of the IL risk — see the previous post if this point is unclear.
This result is quite attractive for existing vault projects like harvest.finance since chasing the highest APY for their users is exactly their bread and butter.
The result is also quite attractive for the Type A DeFi players, because the strategy is single-sided and requires a core crypto asset they normally hold a lot of (ETH) — without the annoying balancing act of acquiring USDC in equal value.
And last but not least, the result is also quite attractive for the Type B CeFi players, because the strategy from their side requires USDC only and minimizes exposure to crypto volatility — while providing APY that is significantly higher than normally received in CeFi.
Another advantage of this approach is that it requires zero changes to the underlying DEX. The method supports the existing versions of Uniswap, SushiSwap, 1inch, PancakeSwap and many others right out of the box.
Now that we have a clear architecture in mind, it’s time to dive into the implementation. We are going to implement the yellow section of the above diagram — the Liquidity Nexus contract.
As the rekt leaderboard has taught us, vaults are delicate and subject to nuance. Successful vaults can manage millions if not hundreds of millions of dollars in value, making them prime targets for manipulation.
From our experience, exploits can roughly be divided to 2 types:
It seems that the first type is the more successful as of late, which leads us to believe that many implementations often overlook the economics and jump into the bits and bytes a tad too quickly. To counter, let’s dedicate the first phase of our implementation to a pure economic simulation.
The Github repo is available here: https://github.com/defi-org-code/single-playground
What makes a successful simulation? First of all — rapid prototyping. Writing a simulation should be easier and faster than writing the real thing. Since we want to focus on logic alone, we can choose any language. It wouldn’t make much sense to rely on a strict and safe language like Solidity because its defensive nature makes development too slow. We need a language that cares less about the details and will let us focus on the big picture instead.
JavaScript comes to mind.
The second challenge of a simulation is modeling the world around us. Since we’ll be implementing the yellow section of the above diagram — the Liquidity Nexus contract — we need to mock everything else. This sounds like a complicated task but it really isn’t. Let’s take Sushi for example. There’s no need to accurately implement Sushi in all its glory, a rough behavior will do.
Consider this short and sweet simulated version of Sushi — sushi.js
The power of a simulation comes from giving the developer convenient tools to experiment with various attacks. We’ve already mentioned flash loans as something to be careful of. But what would an attacker use a flash loan for in our case? It could serve as a way to manipulate ETH price for a short while in the Sushi ETH/USDC pool. Instead of spending a few hours modeling a flash loan and everything it entails, let’s take advantage of our simulation and do something much simpler — let’s give our attacker a direct way to change ETH price. This will allow us to model attack vectors easily via automated testing.
The repo has 3 branches that are interesting to explore:
There are multiple interesting things we’ve learned from performing these simulations. I’ll expand on them in a different post though, as they require some background and a lot more detail.
The Github repo is available here: https://github.com/orbs-network/nexus-sushiswap
Now, that the economic simulation is complete, the result of phase 1 provides us with a better understanding of the economics and a clear specification for the contract logic.
The next phase would be to take this logic and implement it in Solidity. This process is a little slower because you never want to rush Solidity code. This will be the production code that manages significant amounts of money, so a defensive coding style is advised.
Integration with the outside world is much easier in this phase since we can use the actual mainnet implementations of all third-party contracts we rely on — like SushiSwap ETH/USDC pair. This means we don’t need to mock anything, even for tests.
Testing is a little more cumbersome in this phase since we’re testing directly on Ethereum mainnet. Test scenarios may take more work to implement, but the added benefit is that we’re testing the real thing — as close as possible to what production will look like if the contract was actually deployed to mainnet. This is possible due to Ganache’s awesome mainnet forking ability which can also be easily activated on Hardhat.
Our team has a fetish for E2E testing — there’s no better way to prove your code works than showing a passing test. Take a look at the extensive test suite.
This test for example demonstrates that using strategy 1 (defined in the previous post), the USDC supplying side withdraws the same amount of USDC it originally deposited, even if ETH price moves:
The sharp-eyed among you may ask how changeEthPrice works in this phase, because it can’t be as easy to implement as in the simulation. It actually works the hard way, by swapping over and over until the price actually moves in the desired amount — you can see the implementation here.
If you’re curious about what we’re working on and don’t mind seeing work-in-progress that hasn’t been properly announced yet, feel free to follow us on Github:
···
Notes
This document details a project which is currently being researched by the Orbs team and ecosystem contributors. The project is currently in concept mode and is being portrayed herein as currently envisioned by the Orbs team.
Orbs is a decentralized project driven by community contribution and guidance. The product and functionality detailed in this document therefore constitute a mere proposal assembled from community feedback and are subject to change continuously as new requirements arrive. This document provides no guarantee that any offering, product or specific feature will become fully or partially developed.
The information contained in this document shall not form the basis of, or be relied upon in connection with, any offer or commitment whatsoever in any jurisdiction.
We use cookies to ensure that we give you the best experience on our website. By continuing to use our site, you accept our cookie policy.
