Swim’s Design

What’s our goal?

To build a capital highway for the multi-chain world

While various thought leaders and projects have attempted to tackle this problem, the challenge still remains on how to facilitate the movement of assets across chains to help alleviate the fragmentation across ecosystems. Let’s dive into how we approached this problem.

Our Design

Our design offers users the ability to interact with Swim’s liquidity pool with native assets on multiple chains.

Initially, only stable asset pools will be created on Ethereum, BSC, and Solana to facilitate trading between these chains. The pools on either chain are connected via Wormhole, which helps to relay transaction requests across chains. When a transaction is received by the Swim smart contract, an algorithm will determine the slippage based on the size of the trade and the pool’s composition, providing an execution price.

Please refer to our past Medium post for more details

What do we value?

In the long run of adoption, our team most values a design that would lead to the highest level of throughput, decentralization (and/or trustlessness), and usability. (Read more here)

1. High Throughput

On high throughput, imagine scaling TVL to a few billion (Curve’s 3pool sits at $4.2B TVL at time of writing). Now consider which design would be able to facilitate cross-chain asset mobility on a massive scale? We’ve seen big players exchange stablecoins eight figures at a time on Curve and have also seen Curve facilitate large movements of capital from Ethereum to other ecosystems (i.e. when $1B was withdrawn from Curve’s Eth pool and moved to Arbitrum). An ideal multi-chain capital highway should be able to facilitate both instances in a seamless and efficient manner.

Liquidity Fragmentation

Under the current wrapped token paradigm, there’s a considerable amount of fragmentation of the native asset. When bridging via wrapped tokens from the source chain (where the native collateral is held) to the destination chain (where the wrapped token is being sent), the wrapped token will be swapped for the native token via different liquidity pools. If we assume that in the long run, the DeFi ecosystem runs on each respective chain’s native stablecoin asset, there will be numerous different liquidity pools, ultimately fragmenting liquidity. In other words, for every wrapped asset protocol in the space, we would need chain*(chain — 1) pools to make an interconnected network. For instance, 10 chains would consist of 90 different liquidity pools!

In the event of serious adoption, let’s suppose one billion native USDC SPL is provided as liquidity to a bridge protocol. Ideally, that bridge protocol would be able to make the most of that liquidity.

For instance, a user needs to bridge assets urgently across chains and they have decided that the opportunity they are trying to capture means they are willing to pay at most 10bps for swapping stablecoins across chains. With Swim’s current Hexapool structure and amp factor, that would be about 100m USDC that the user can bridge at this slippage. Now if a bridge protocol happened to have one billion native USDC SPL split throughout numerous different pools, each facilitating wrapped assets from a variety of source chains and wrapped methods, this fragmentation cuts down the user’s bridge throughput dramatically.

Pool Constituents

Our design was built with the following considerations in mind: we wanted (a) only native assets and (b) consolidated liquidity for each asset (meaning the assets only show up in one pool). The next step was deciding what assets to choose to place into that pool. Ideally, the top stablecoins by market cap will command the deepest liquidity on local chains and will continue to be superior in the future.

One natural heuristic is to gauge which assets are popular by market cap — at time of writing on March 7, 2022, the market cap of various stablecoins are as follows:

We decided to include USDT, USDC, and BUSD in our Hexapool as these are the most dominant stablecoins in the ecosystem by market cap, with low probability of becoming irrelevant in the future. Now admittedly, our pool composition was chosen months ago before the meteoric rise of UST and we’re super excited for everything that’s going on in the Terra ecosystem! For now, we’ll be including UST into the Swim network via metapools but we’ll be on the lookout if the landscape changes.

2. Decentralization

Wormhole

When considering cross-chain communication methods, an important factor to weigh is the quality of nodes, the entities that pass messages between different blockchains, at stake. We won’t go too much into alternative solutions, but when comparing Wormhole’s nodes (a subset of the Solana Guardians) to other cross-chain communication methods’ nodes, Wormhole’s Guardians have the strongest “trustless” forces in place. This is in large part due to the SOL they have at stake from validating the Solana network.

Pool location

So now that we’ve decided on pool constituents and the bridge technology, where do we put this pool (where do the backend calculations take place)? For the pool to function during multi-chain race conditions it has to live in one place in order to run all transactions in a series. Since we’ve opened up product testing to our Discord community, one question we have received is: “Why do I have to go through Solana to transfer from Ethereum -> BNB Chain” The short answer is that it’s complicated. The longer answer is: that it’s a byproduct of prioritizing (a) high throughput and (b) decentralization, but that’s not very eye-opening. If we wanted to route ETH, BSC, SOL pairwise directly, we would have to put the pool on a server (off chain) and that is very, very much not decentralized, but it is faster. For now, we’ve decided to put the pool on the fastest chain Solana. See one of our upcoming projects for swapping from ETH -> BSC without needing a Solana wallet (Doc on Relayers coming soon)

3. Usability

While we do prioritize high throughput and decentralization, we’re aware that in order for Swim to actually be the capital highway between chains, people should actually enjoy using it. We’ve approached this regard from two different angles:

Streamlined UI

We’re launching with our initial proof of concept of our bridge status to streamline the cross-chain workflow for the user. If the instability of communicating across chains breaks on the user, our bridge status feature shows the user where their funds are. In the event that their money is stuck, Swim will prompt the user to push their funds through the process with a click of a button.

[Read more here]

Composability

We’re working towards a larger project, the relayer, which is a trustless and sustainable way to perform cross-chain calls. This enables a user to initiate a transaction on the source chain with one transaction while also with an encoding of any desired transactions on the target chain. The relayer “cranks” through the encoded instructions on the target chain. One contract call on the source chain is quite powerful! It makes cross-chain composability way easier.

Cross-chain swapping, borrow-lending, staking, yield rebalancing… you name it

(Doc on Relayers coming soon)

Ending Notes

Every design has its pros and cons and we’re quite happy with the aspects that we’ve optimized for in building out our design. As the space grows and new technologies enter the toolkit, we’re always looking for ways to improve upon our protocol. If you have any suggestions, please don’t hesitate to reach out via Discord