In the last article we discussed the rise of DeFi on Ethereum and how it led to the need of a more scalable blockchain. We also discussed the emergence of the layer 2 landscape. We saw that when dealing with all these different layer 2 networks it becomes a lot harder to provide liquidity in an efficient way. As in the early days of the internet, we see the emergence of different layers in the blockchain world. We think these layers should be abstracted away from liquidity providers, just as today’s users of the internet don’t care which infrastructure layer they interact with. Derby.finance offers a solution to this problem for liquidity providers. In this article we’re going to look at how other protocols are tackling this problem and how Derby.finance distinguishes between them.

We qualify a liquidity optimiser as a protocol that completely abstracts away the existence of different chains and layers where DeFi protocols can be deployed on. A user can deposit wherever he or she wants and always gets an exposure on multiple chains and layers. Ideally, we have a liquidity optimiser that satisfies the following features:

• Exposes the Liquidity Provider (LP) to yields on multiple chains and layers no matter where the LP deposits its liquidity.

• Rebalances periodically over the different chains and layers, but also over the different DeFi protocols that are deployed there.

• Has a wide exposure on different DeFi protocols.

• Is not managed by a centralised entity.

• Is as automated as possible.

• Has low overhead costs.

Currently, there are already a lot of yield aggregators in DeFi. However, we can’t really qualify most of them as layer 2 liquidity optimisers as they don’t abstract away all of the different chains and layers. Furthermore, they usually have a few other design choices that can be improved upon.

Although most DeFi protocols nowadays are deployed on different chains and or Layer 2s, most of them are completely isolated from each other. This means that a liquidity pool on one layer 2 does not communicate with another liquidity pool on another layer 2. For the outside world they act as 2 completely different Liquidity Pools despite the fact that they belong to the same DeFi application.

A way to manage liquidity between all the different protocols on all the different chains and layers would be to start a company that does this. The company would attract smart and experienced people to perform the job of carefully weighing risks and returns to optimally distribute capital over the different DeFi applications in the market. The company would resemble a bank’s capital management division closely by attracting capital and allocating this capital over the different DeFi applications. However, there’s one problem. This solution would be centralised, because it consists of just a normal centralised company offering this service.

Another solution currently observed in the market is to construct some sort of an index, program this index into a smart contract and let all the liquidity be divided over the DeFi apps accordingly. In Traditional Finance there are a lot of investment products based on indices. However, they are usually meant for asset management products (equities etc). Also, the Traditional Finance market is much more mature which is a requirement for these things to function well. In DeFi, yields vary a lot over different protocols, over time and over different chains and layers.

There is another type of yield aggregator in DeFi that gained some traction in the last year. These are custom built smart contracts that contain yield harvesting strategies. Per strategy, they usually focus on just a few underlying DeFi applications at the most and they often use extended leverage to optimise the yield harvesting opportunities. Because of the niche these strategies focus on and also because we don’t know if yield harvesting incentives will always keep existing in DeFi this is not the type of solution we are looking for.

Derby.finance utilises the collective knowledge of its token holders to solve layer 2 liquidity optimisation in DeFi. It does this via a simple investment game with a few unique incentives built into it, which we will describe in our next article: Derby.finance, the game. It is also one of the first truly cross-chain apps, where the users don’t have to worry about on which chain they enter one of the Derby vaults or on which chain the best yields in DeFi are made at that point. The Derby vaults take care of all the cross-chain bridging and communication. With all of these features we think we are getting a lot closer to our vision of the ideal liquidity optimiser. We are solving a real problem in DeFi with a truly novel application that enriches the DeFi ecosystem.

In the next article we will discuss the Derby.finance game.

In the last article we discussed the rise of DeFi on Ethereum and how it led to the need of a more scalable blockchain. We also discussed the emergence of the layer 2 landscape. We saw that when dealing with all these different layer 2 networks it becomes a lot harder to provide liquidity in an efficient way. As in the early days of the internet, we see the emergence of different layers in the blockchain world. We think these layers should be abstracted away from liquidity providers, just as today’s users of the internet don’t care which infrastructure layer they interact with. Derby.finance offers a solution to this problem for liquidity providers. In this article we’re going to look at how other protocols are tackling this problem and how Derby.finance distinguishes between them.

We qualify a liquidity optimiser as a protocol that completely abstracts away the existence of different chains and layers where DeFi protocols can be deployed on. A user can deposit wherever he or she wants and always gets an exposure on multiple chains and layers. Ideally, we have a liquidity optimiser that satisfies the following features:

• Exposes the Liquidity Provider (LP) to yields on multiple chains and layers no matter where the LP deposits its liquidity.

• Rebalances periodically over the different chains and layers, but also over the different DeFi protocols that are deployed there.

• Has a wide exposure on different DeFi protocols.

• Is not managed by a centralised entity.

• Is as automated as possible.

• Has low overhead costs.

Currently, there are already a lot of yield aggregators in DeFi. However, we can’t really qualify most of them as layer 2 liquidity optimisers as they don’t abstract away all of the different chains and layers. Furthermore, they usually have a few other design choices that can be improved upon.

Although most DeFi protocols nowadays are deployed on different chains and or Layer 2s, most of them are completely isolated from each other. This means that a liquidity pool on one layer 2 does not communicate with another liquidity pool on another layer 2. For the outside world they act as 2 completely different Liquidity Pools despite the fact that they belong to the same DeFi application.

A way to manage liquidity between all the different protocols on all the different chains and layers would be to start a company that does this. The company would attract smart and experienced people to perform the job of carefully weighing risks and returns to optimally distribute capital over the different DeFi applications in the market. The company would resemble a bank’s capital management division closely by attracting capital and allocating this capital over the different DeFi applications. However, there’s one problem. This solution would be centralised, because it consists of just a normal centralised company offering this service.

Another solution currently observed in the market is to construct some sort of an index, program this index into a smart contract and let all the liquidity be divided over the DeFi apps accordingly. In Traditional Finance there are a lot of investment products based on indices. However, they are usually meant for asset management products (equities etc). Also, the Traditional Finance market is much more mature which is a requirement for these things to function well. In DeFi, yields vary a lot over different protocols, over time and over different chains and layers.

There is another type of yield aggregator in DeFi that gained some traction in the last year. These are custom built smart contracts that contain yield harvesting strategies. Per strategy, they usually focus on just a few underlying DeFi applications at the most and they often use extended leverage to optimise the yield harvesting opportunities. Because of the niche these strategies focus on and also because we don’t know if yield harvesting incentives will always keep existing in DeFi this is not the type of solution we are looking for.

Derby.finance utilises the collective knowledge of its token holders to solve layer 2 liquidity optimisation in DeFi. It does this via a simple investment game with a few unique incentives built into it, which we will describe in our next article: Derby.finance, the game. It is also one of the first truly cross-chain apps, where the users don’t have to worry about on which chain they enter one of the Derby vaults or on which chain the best yields in DeFi are made at that point. The Derby vaults take care of all the cross-chain bridging and communication. With all of these features we think we are getting a lot closer to our vision of the ideal liquidity optimiser. We are solving a real problem in DeFi with a truly novel application that enriches the DeFi ecosystem.

In the next article we will discuss the Derby.finance game.