Liquidity pipes
In this article, I want to talk about the different ways to move liquidity between blockchains and why we are focused on a particular way to do this for our new product — the dReservoir.
Liquidity is the lifeblood of any financial system, not least blockchain networks. Its utility is maximized if it can be easily moved to the places where it is needed most. For blockchain networks, this typically means using a “bridge” — the preferred metaphor for something that moves tokens from one blockchain network to another.
Pipes not bridges
As an aside, if I am to talk about moving liquidity in terms of metaphors, I really want to avoid using the term “bridge” because I don’t think it conjures the correct image for what’s really happening.
I like to think about liquidity in terms of some kind of liquid, or fluid, or solution — I think that’s reasonable.
Liquidity naturally forms a fractal system of pools (See the cool AI generated image above for an algorithm’s perspective on that). One can think of a blockchain network as hole in the ground for a pool of liquidity, and this liquidity, in turn, is accessible to the various applications and services running on said network — each with their own set of pools (E.g. Moonbeam > Stellaswap > XYZ pool).
Liquidity can flow from one pool to another via pipes and whilst it can flow downhill easily, it must be pumped up hills — and that requires work.
What determines the topology of this hypothetical landscape? Well… High yields would imply a lower altitude, so liquidity will readily pool there. Lower yields imply a higher altitude and thus liquidity must be helped by way of a pump to get there — or, it just doesn’t go there. Regardless of the altitude, the common denominator is a pipe. A pipe! I think that’s a good metaphor for something that helps to move a liquid-like thing from one place to another.
So unless we are talking about bridges in terms of aqueducts, I’d rather talk about pipes.
What is a liquidity pipe?
A liquidity pipe is a thing which moves liquidity between two separate or disjoint pools.
Why are they necessary?
Liquidity pipes exist because the financial world we interact with everyday comprises a series of pools, each with their own set of issued financial instruments, which can only exist in their native form inside that pool. For liquidity to flow where it is needed, there must to be a way to move an instrument which originated in one pool to another where it can be put to use.
So more specifically, a pipe is a thing which allows someone to transfer value represented by a token issued on one blockchain network to value represented by another token on a different blockchain network.
Let’s get blockchain specific. There are two approaches to pipes: custodial and non-custodial. It’s worth noting that custodial in this sense really means “legal custody”.
The custodial approach
As expected, this approach requires some kind of custodian. Whilst somewhat antithetical to the principles of decentralisation, using a custodian to custody a token and re-issue it (or a representation of it) on another blockchain network is one the most straightforward approaches. Crypto examples are WBTC and arguably most crypto exchanges, which allow you to deposit and withdraw tokens using multiple blockchain networks. Furthermore, one can find this approach used in many places in finance today:
- Fiat collateralised stable coins are pipes from a country’s banking system to one or more blockchain networks. It involves the locking of collateral by way of bank deposits and the issue of a new token as a claim on the bank deposit collateral.
- In traditional finance, depositary receipts are issued by a bank representing shares in a foreign company traded on a local stock exchange. I.e. US shares in the UK.
The clear downside of using a custody based approach is that you become legally responsible for your customer’s funds and, quite rightly, that results in a fair degree of regulatory oversight (or at least should do).
Regardless, history would tell us that not all people responsible for custody other people’s money should actually be doing it — evidenced by numerous thefts which have happened over the years.
The non-custodial approach
Non-custodial pipes are middleware which sits between a set of blockchain networks. The principal component of this type of pipe is a persistent message queue or relayer which consumes signed messages from a source blockchain network, verifies them, and then forwards them on to a destination network where some other operation is performed.
The signed messages manifest as blockchain transactions and the block header of the block the transaction is included in. These messages are difficult to forge which mean they are good candidates for conveying information securely from one blockchain network to another.
An end-to-end token pipe operation requires a transaction on a source network to lock or burn (this distinction becomes important later) some amount of tokens. This transaction is wrapped into a message and forwarded on to the persistent message queue for verification and relaying to the destination blockchain network. The destination blockchain network will post a subsequent transaction to mint new tokens, if and only if, the source transaction was valid (It was included in a block of height M with N confirmations…)¹.
The nice thing about this approach is that it doesn’t require any legal custody. Arguably, in some cases there are still tokens locked up in a smart contract, and one could call that custody of tokens, but crucially it doesn’t require legal custody and assuming a sensible and secure setup of the smart contracts doing the locking or burning, then the maintainers of the protocol cannot unilaterally take control of customer funds.
The middleware can be operated by a single organisation (collusion risk! They could convince a destination blockchain network to accept a fake message or just simply censor incoming messages from source blockchain networks) or a collaboration of organisations. The intuition being that a collaboration of two or more organisations results in more secure middleware. At a bare minimum the middleware requires two collaborators: one to relay messages and another to perform message verification.
All non-custodial “bridges” — regardless of implementation — must use this messaging approach, described above, in their design.
Depositary receipts, or lock-and-mint
Most pipes involve the movement of tokens which have not been initially developed with a multi-chain world in mind. Indeed, the ERC20 interface doesn’t contain any code regarding cross-chain transfers.
And so, the only way feasible way to move one of these tokens is to lock them up as collateral on a source blockchain network and create a depositary receipt on the destination blockchain network representing a claim for the collateral on the source blockchain network. In crypto, these depositary receipts are referred to as wrapped tokens. This approach requires contracts deployed to each desired blockchain network and the middleware, described above, configured to verify and relay messages between them.
Native tokens, or burn-and-mint
However, if the organisation building the pipe is the same organisation which issues the token in question, then it’s possible for them to build some functionality into the token contract for moving the token to other blockchain networks.
Just as above, this approach requires deploying a ERC20 token contract to each blockchain network the developer wishes to support. However, for the native token approach, some additional functionality must be added in addition to the ERC20 implementation. Specifically, there must be a way to burn some amount of token and send a message to the pipe middleware that an equal amount of tokens should be minted on a specified destination blockchain network.
The effect of calling this additional function allows holders of the token to move it to any other blockchain network. To depart from water-like metaphors for a moment, this approach allows the user to effectively teleport their token from one blockchain network to another. Indeed, the tokens only exists in one place at once — there’s no requirement for a locked representation of it inside the pipe or token contracts.
In short, we like this approach.
Why do we (the DAM team) like burn-and-mint?
Let’s start with why we don’t like lock-and-mint:
- The smart contracts require the locking up a large pool of liquidity at either end of the pipe and this becomes a target for hackers.
- The close proximity of the locked tokens to the middleware logic usually means that any vulnerability exploited in the middleware and smart contracts, result in the locked tokens being immediately stolen.
This can result in a definitively worse situation than relying on potentially unscrupulous actors to custody a pool of tokens. Indeed, if there is a contract vulnerability to be exploited, then it likely will be, and security of the protocol becomes an all-or-nothing binary outcome — the whole locked pool of tokens can be drained with zero accountability for the attackers.
With burn-and-mint, an attacker cannot steal tokens but they could potentially mint unbacked tokens. However, I think fraudulently minting tokens is difficult to do successfully for the following reasons:
The use of effective detective controls
Under normal circumstances, mint operations on a destination blockchain network must follow a burn operation on a source blockchain network. This is a protocol invariant, and so any mint operation observed in isolation can be immediately flagged as illicit.
Burn and mint events can be monitored in real-time by a guardian, which would be highly available and provide coverage for all networks the token is deployed to.
In the event the guardian encounters an illicit mint, it would pause the token contract in question so an investigation can be carried out. In the case of a collateral backed token, the collateral contracts can be paused — this would prevent an attacker using fraudulently minted tokens to redeem collateral.
Furthermore, other applications or services using the token in question can subscribe to security alert messages regarding the token. For example, consumers of these messages may wish to freeze liquidity pools for the token in question if there is reason to suggest fraudulently minted tokens might be deposited.
We call this the “dGuardian” and it is a key detective control to ensuring the d2O stablecoin remains a safe and secure medium of exchange for its users.
Whilst our token contracts have been audited and we are confident in their integrity, I think it makes sense to rely on additional controls as there is always a no-zero chance of an attacker finding an exploitable vulnerability in any of the software stack used to implement the token.
The message is clear — try to steal this token and it’s likely you won’t get far for your efforts.
The use of effective preventative controls.
Transaction amount limits can be applied on mint values such that the maximum amount which can be minted in any single transaction must be below some specified amount. This cap can be lifted for “power users” for moving large values. However, it is safe to assume the vast majority of transactions will fall below the threshold e.g. $1m.
Mint amount limits effectively cap the amount which can be stolen in a hypothetical attack. Furthermore, once a first attack has been detected, the Guardian will prevent any further illicit activity by pausing the contracts involved.
DAM Finance goes multi-chain
A couple of months ago, we unveiled d2O, a crypto-collateralised stablecoin, whereby users can mint d2O collateralised by their crypto portfolios. Whilst we remain committed to building out this product (we’ve already had the smart contracts audited), in the midst of the bear-market we identified a new and more pressing requirement — providing liquidity to emerging blockchain eco-systems.
And so, we are building pipes between multiple blockchain networks with the intention of making it easy to move liquidity from places where it is abundant, to places where it is less readily available.
We are doing this because we want to see up-and-coming networks prosper and we know that one of the key ways to realise this goal is to make it easy for liquidity to flow to places where it is needed.
Enter the dReservoir
Reservoir — a big pool of liquidity which can be piped (or pumped!) to wherever it is needed.
We have augmented the d2O token with the ability for it to be easily “teleported” from one blockchain network to another. We like the verb “teleport” because that’s literally what happens — d2O is burnt on one blockchain network and re-minted on another. And in case you were wondering, teleportation is just a means of piping liquidity from one place to another!
Starting with Ethereum and Moonbeam, users will be able to mint d2O on Ethereum (via approved stablecoin collateral), which can then be piped to Moonbeam in a matter of minutes.
On Moonbeam, users will receive a native d2O token, which can be used within the Moonbeam eco-system or piped back to Ethereum where it can be redeemed for the pledged collateral.
The great thing about this approach is that we can add d2O to other blockchain networks by simply deploying the d2O contract there. The caveat is that we need the inter-blockchain middleware configured to accept and receive messages from the blockchain networks in question. We are working with partners to ensure the necessary coverage and can cover the technical details in another post.
Furthermore, no wrapped tokens are required and so no large pools of liquidity sit within the bridge contracts themselves. And finally, in the background, we will have the dGuardian, ready and waiting to take action if anything looks suspicious.
We look forward to unveiling d2O on testnet in the coming days.
[1]: The bridge protocol and middleware must provide a set of guarantees to be useful:
- A message from a source network can only be delivered to a destination network if and only if a transaction containing the message was committed on the source network. This is required so that the middleware and destination blockchain network know that the intention of the source transaction submitter was genuine.
- A message from a source network will only be forwarded to a destination network if it is valid per the protocol rules. Meaning that the block containing the transaction has the required amount of confirmations, for example.
- A message from a source network is guaranteed to be eventually received by the destination network. Meaning that, given any valid message, the protocol will ensure it is eventually delivered to the destination blockchain network and that the desired operation is carried out. For example, if initial delivery fails, then delivery should be retried until it succeeds.
Post updated on Dec 5th with new naming of DAM stablecoin to d2O
