In the last couple of articles (Hello Derby.finance, Derby.finance in the DeFi landscape, Derby.finance, the game, Derby.finance, the vaults) we talked about Derby.finance as the layer 2 liquidity optimiser. In this article we will explain how Derby.finance was implemented on multiple chains and layers.

The rise of open blockchains and cryptocurrencies is often compared to the rise of the internet. The early internet was also slow, hard to use and a lot of technical expertise was required to use it. This is also the case with open blockchains today. Where the internet grew to a multi-layered infrastructure called the OSI, we nowadays see the rise of blockchain interoperability and layers on top of primary layer 1 blockchains. Users of today’s internet really don’t care on which layer of the OSI model they connect, which network they’re on or which server they are connected to. All of this is abstracted away from them, in favour of the useability of interactive websites and applications. We expect open blockchains will ultimately follow the same path. That’s why we made Derby.finance completely chain agnostic and fully cross-chain. In this article we will explain what we mean by this and how we did this. First we will give a background on the current state of the cryptocurrency platforms, we will then zoom in on the various cross-chain technologies that are used for interoperability between open blockchains. Lastly we will explain how Derby.finance uses these technologies to create one of the first true cross-chain DeFi applications.

After the launch of Ethereum in 2015 the cryptocurrency sector exploded in number of users, use cases and market capitalisation. A smart contract enabled blockchain like Ethereum is often referred to as a layer 1 smart contract platform. Because Ethereum got so popular, and blockchains are not really meant to scale due to their distributed nature, the price of running programs on Ethereum rose sharply making its use cases somewhat limited again. There are multiple solutions to solve this problem of blockchain scalability. They can roughly be divided into two categories: alternative layer 1 smart contracts that sacrifice some of their decentralisation and security for more scalability (Examples: Binance Smart Chain, Avalanche, Polygon, Fantom) and layer 2 platforms (Examples: Arbitrum, Optimism, ZkSync, Starknet) that execute the bulk of transactions and programs off chain and only occasionally settle these on the layer 1 blockchain (usually Ethereum). Both solutions give rise to a new problem, these networks are still largely unconnected. This hurts composability and fragments liquidity between chains and layers. For example, what is really one of the most powerful features of DeFi applications, their ability to programmatically interact with each other without permission, does not automatically work when we have different layer 1s and layer 2s. Luckily the development of blockchain bridges presents a solution here. Blockchain bridges make it possible to move funds and send data between separate blockchains. Whereas the first generation of bridges were not very secure and hacked a lot, today’s bridging technology is getting a lot better in terms of security and ease of use. We will give a short overview of how blockchain bridges work in the next section, before explaining how Derby.finance utilises these technologies to always follow the best and latest yield trends in DeFi, no matter on what chain or layer they are deployed.

Blockchains are distributed networks of computers, also called nodes, where each node performs a similar set of calculations. The network basically serves as a distributed ledger. With this in mind, try to picture a message that has to be sent from one blockchain to another. This basically means that all nodes in blockchain 1 have to send this message to all nodes in blockchain 2. With each extra blockchain added to this multichain universe this problem gets exponentially harder. Apart from sending messages, one would also want to send value across these blockchains. A token that represents value on one blockchain does usually not represent anything meaningful on another and they are usually just incompatible. This led to the need for so-called blockchain bridges. Intermediary networks of nodes that monitor a set of different blockchains and pass messages and value between them.

The first generation of blockchain bridges (e.g. Wormhole) usually combined the functionality of sending funds and messages into one protocol. Funds were usually sent between blockchains by following the so-called “mint-and-burn” mechanism. For example, an Ether gets locked on Ethereum to a predefined contract, an intermediary network observes this and mints a token representing this Ether on another blockchain. We call this token a wrapped token. The other way around the wrapped token gets “burned” on the other blockchain and the Ether on Ethereum gets released again from the smart contract.

The problem with the first generation of blockchain bridges is that they were not thrustless. With that we mean that the intermediary network could steal funds by misbehaving, i.e. send wrong messages between nodes or an attacker was able to impersonate the intermediary network nodes and unlock the locked Ethers.

The second generation of blockchain bridges (e.g. Connext) tries to separate value transfers from sending messages where the value transfers follow the “atomic swap” principle. Usually only native tokens will be used, no wrapped tokens. An example here is a natively issued stable coin on two different blockchains (i.e. USDT or USDC). These native tokens can be swapped between two blockchains by swapping the coin on one chain with a coin on the other. This swapping procedure is done again by an intermediary network and either completely executes or, if something goes wrong, nothing happens. That’s why it’s called an atomic swap. This is a completely trustless way of bridging value between blockchains. Hence, the nodes from the intermediary network cannot steal the funds. By separating this way of bridging value from sending messages a big security gain is made. Messages in this setup can be done following a few different methods which are beyond the scope of this article. In short, we like the “optimistic” way to bridge messages where it is assumed a message is correct and during a dispute period anyone may disprove the correctness and can receive a locked bond if it has done so.

As we have described in the above sections we have:

• A fast growing infrastructure of blockchains and layer 2s similar to the development of the early internet.

• The rise of a more secure way to make all those blockchains and layer 2s interoperable.

For Derby.finance this means that this is the perfect timing to go fully multichain in a way that is totally abstracted away from the end users. What does this mean?

We know that users (could be end users, institutions or other DeFi applications) all have a different preference for which blockchain or layer 2 they like to interact with. We also know that on each of these blockchains or layer 2s there are different DeFi applications with yield opportunities. These opportunities may vary from time to time and there’s really no way of predicting where the best opportunities will arise in the future. Therefore, the ideal liquidity optimiser would let users connect from everywhere they want to and expose them to yield from where at that moment the best opportunities lie. That is exactly what Derby.finance does with its vaults. It attracts liquidity from all kinds of users on all kinds of chains to give them a true multi-chain exposure.

The Derby.finance game is a little bit more restricted. It will only live on Ethereum layer 2. The reason being that we don’t like to bridge our tokens to a wrapped version in another ecosystem. We don’t like wrapped tokens purely because history has presented us with too many hacks concerning those types of tokens. Also, having just one deployment of the game contract greatly reduces complexity.

To recap, we have the Derby.finance vaults deployed on a set of different layer 1 and layer 2 ecosystems. And we have our Derby.finance game deployed on Ethereum layer 2. In this section we will give a high level overview of how we implemented our cross-chain vision into the Derby.finance vaults and game. The most important elements are the redistribution of funds among the different vaults on different chains and the cross-chain controller contract on Ethereum layer 1. This contract basically keeps track of all funds and all allocations on the different chains and layers. Once per rebalancing period (once per two weeks) funds need to be re-distributed according to the allocations in the cross-chain controller, which were determined by the game. After that, each vault can rebalance its funds among the underlying DeFi apps. The redistribution of funds among the different chains and layers contains the following steps:

• First of all the allocations are set in the game on Ethereum layer 2.

• Once in two weeks a snapshot is made for each vault and the game. The total allocations and information about the total funds in the vaults are sent as a cross-chain message to a cross-chain controller contract living on the Ethereum mainchain.

• This cross-chain controller calculates which vaults on which chains and layers have excess funds and which vaults on which chains and layers have a shortage of funds.  The cross-chain controller then sends a message to the vaults with excess funds.

• These vaults transfer the excess funds to the cross-chain controller on the Ethereum mainchain.

• The cross-chain controller transfers funds to the vaults which have a shortage of funds. Now all the vaults have exactly the right amount of funds according to how the game has determined them.

• Now in each vault on each chain or layer a rebalancing function is triggered to deposit and withdraw the correct amount of funds to the underlying DeFi apps on that chain.

Hopefully this article clarified the need for Derby.finance to be a fully cross-chain application.

In the last couple of articles (Hello Derby.finance, Derby.finance in the DeFi landscape, Derby.finance, the game, Derby.finance, the vaults) we talked about Derby.finance as the layer 2 liquidity optimiser. In this article we will explain how Derby.finance was implemented on multiple chains and layers.

The rise of open blockchains and cryptocurrencies is often compared to the rise of the internet. The early internet was also slow, hard to use and a lot of technical expertise was required to use it. This is also the case with open blockchains today. Where the internet grew to a multi-layered infrastructure called the OSI, we nowadays see the rise of blockchain interoperability and layers on top of primary layer 1 blockchains. Users of today’s internet really don’t care on which layer of the OSI model they connect, which network they’re on or which server they are connected to. All of this is abstracted away from them, in favour of the useability of interactive websites and applications. We expect open blockchains will ultimately follow the same path. That’s why we made Derby.finance completely chain agnostic and fully cross-chain. In this article we will explain what we mean by this and how we did this. First we will give a background on the current state of the cryptocurrency platforms, we will then zoom in on the various cross-chain technologies that are used for interoperability between open blockchains. Lastly we will explain how Derby.finance uses these technologies to create one of the first true cross-chain DeFi applications.

After the launch of Ethereum in 2015 the cryptocurrency sector exploded in number of users, use cases and market capitalisation. A smart contract enabled blockchain like Ethereum is often referred to as a layer 1 smart contract platform. Because Ethereum got so popular, and blockchains are not really meant to scale due to their distributed nature, the price of running programs on Ethereum rose sharply making its use cases somewhat limited again. There are multiple solutions to solve this problem of blockchain scalability. They can roughly be divided into two categories: alternative layer 1 smart contracts that sacrifice some of their decentralisation and security for more scalability (Examples: Binance Smart Chain, Avalanche, Polygon, Fantom) and layer 2 platforms (Examples: Arbitrum, Optimism, ZkSync, Starknet) that execute the bulk of transactions and programs off chain and only occasionally settle these on the layer 1 blockchain (usually Ethereum). Both solutions give rise to a new problem, these networks are still largely unconnected. This hurts composability and fragments liquidity between chains and layers. For example, what is really one of the most powerful features of DeFi applications, their ability to programmatically interact with each other without permission, does not automatically work when we have different layer 1s and layer 2s. Luckily the development of blockchain bridges presents a solution here. Blockchain bridges make it possible to move funds and send data between separate blockchains. Whereas the first generation of bridges were not very secure and hacked a lot, today’s bridging technology is getting a lot better in terms of security and ease of use. We will give a short overview of how blockchain bridges work in the next section, before explaining how Derby.finance utilises these technologies to always follow the best and latest yield trends in DeFi, no matter on what chain or layer they are deployed.

Blockchains are distributed networks of computers, also called nodes, where each node performs a similar set of calculations. The network basically serves as a distributed ledger. With this in mind, try to picture a message that has to be sent from one blockchain to another. This basically means that all nodes in blockchain 1 have to send this message to all nodes in blockchain 2. With each extra blockchain added to this multichain universe this problem gets exponentially harder. Apart from sending messages, one would also want to send value across these blockchains. A token that represents value on one blockchain does usually not represent anything meaningful on another and they are usually just incompatible. This led to the need for so-called blockchain bridges. Intermediary networks of nodes that monitor a set of different blockchains and pass messages and value between them.

The first generation of blockchain bridges (e.g. Wormhole) usually combined the functionality of sending funds and messages into one protocol. Funds were usually sent between blockchains by following the so-called “mint-and-burn” mechanism. For example, an Ether gets locked on Ethereum to a predefined contract, an intermediary network observes this and mints a token representing this Ether on another blockchain. We call this token a wrapped token. The other way around the wrapped token gets “burned” on the other blockchain and the Ether on Ethereum gets released again from the smart contract.

The problem with the first generation of blockchain bridges is that they were not thrustless. With that we mean that the intermediary network could steal funds by misbehaving, i.e. send wrong messages between nodes or an attacker was able to impersonate the intermediary network nodes and unlock the locked Ethers.

The second generation of blockchain bridges (e.g. Connext) tries to separate value transfers from sending messages where the value transfers follow the “atomic swap” principle. Usually only native tokens will be used, no wrapped tokens. An example here is a natively issued stable coin on two different blockchains (i.e. USDT or USDC). These native tokens can be swapped between two blockchains by swapping the coin on one chain with a coin on the other. This swapping procedure is done again by an intermediary network and either completely executes or, if something goes wrong, nothing happens. That’s why it’s called an atomic swap. This is a completely trustless way of bridging value between blockchains. Hence, the nodes from the intermediary network cannot steal the funds. By separating this way of bridging value from sending messages a big security gain is made. Messages in this setup can be done following a few different methods which are beyond the scope of this article. In short, we like the “optimistic” way to bridge messages where it is assumed a message is correct and during a dispute period anyone may disprove the correctness and can receive a locked bond if it has done so.

As we have described in the above sections we have:

• A fast growing infrastructure of blockchains and layer 2s similar to the development of the early internet.

• The rise of a more secure way to make all those blockchains and layer 2s interoperable.

For Derby.finance this means that this is the perfect timing to go fully multichain in a way that is totally abstracted away from the end users. What does this mean?

We know that users (could be end users, institutions or other DeFi applications) all have a different preference for which blockchain or layer 2 they like to interact with. We also know that on each of these blockchains or layer 2s there are different DeFi applications with yield opportunities. These opportunities may vary from time to time and there’s really no way of predicting where the best opportunities will arise in the future. Therefore, the ideal liquidity optimiser would let users connect from everywhere they want to and expose them to yield from where at that moment the best opportunities lie. That is exactly what Derby.finance does with its vaults. It attracts liquidity from all kinds of users on all kinds of chains to give them a true multi-chain exposure.

The Derby.finance game is a little bit more restricted. It will only live on Ethereum layer 2. The reason being that we don’t like to bridge our tokens to a wrapped version in another ecosystem. We don’t like wrapped tokens purely because history has presented us with too many hacks concerning those types of tokens. Also, having just one deployment of the game contract greatly reduces complexity.

To recap, we have the Derby.finance vaults deployed on a set of different layer 1 and layer 2 ecosystems. And we have our Derby.finance game deployed on Ethereum layer 2. In this section we will give a high level overview of how we implemented our cross-chain vision into the Derby.finance vaults and game. The most important elements are the redistribution of funds among the different vaults on different chains and the cross-chain controller contract on Ethereum layer 1. This contract basically keeps track of all funds and all allocations on the different chains and layers. Once per rebalancing period (once per two weeks) funds need to be re-distributed according to the allocations in the cross-chain controller, which were determined by the game. After that, each vault can rebalance its funds among the underlying DeFi apps. The redistribution of funds among the different chains and layers contains the following steps:

• First of all the allocations are set in the game on Ethereum layer 2.

• Once in two weeks a snapshot is made for each vault and the game. The total allocations and information about the total funds in the vaults are sent as a cross-chain message to a cross-chain controller contract living on the Ethereum mainchain.

• This cross-chain controller calculates which vaults on which chains and layers have excess funds and which vaults on which chains and layers have a shortage of funds.  The cross-chain controller then sends a message to the vaults with excess funds.

• These vaults transfer the excess funds to the cross-chain controller on the Ethereum mainchain.

• The cross-chain controller transfers funds to the vaults which have a shortage of funds. Now all the vaults have exactly the right amount of funds according to how the game has determined them.

• Now in each vault on each chain or layer a rebalancing function is triggered to deposit and withdraw the correct amount of funds to the underlying DeFi apps on that chain.

Hopefully this article clarified the need for Derby.finance to be a fully cross-chain application.