Two weeks into the Whirlpool Builder project and we've seen a ton of subsea activity! 🐳
CheckCheck!)
So far we are delighted with the high number of applications and innovative ideas showcased. In this post, we explore the Whirlpools smart contract and future plans in a Q&A with our co-founder Yutaro!
postpost。
Speaking of which, let's put aside...
Yutaro, first: why are we developing on whirlpool?
We believe that the basic structure of the whirlpool will become the main way to create liquidity in the Solana ecosystem: it will become the dominant DEX in Solana. It's something we've been working on for the past 6 months, and we released a beta version in March.
What are the advantages of a whirlpool cell over a standard (or "constant volume product") flow cell?
In short, Vortex Pool provides users with a better trading experience: both for blue-chip tokens with high liquidity (such as SOL and USDC), and for long-tail tokens.
The reason it gives users a better experience when trading blue-chip tokens like SOL and USDC is that liquidity providers have more control over how much liquidity they provide and when traders want to trade that pair What kind of slippage do they want to offer. Most importantly this is more efficient for liquidity providers. So overall, they can allocate less money to provide a better experience for users.
The Whirlpool is a great building block of the Solana ecosystem, how robust it is, has no single point of failure, and actually requires very little maintenance, let's say, to make sure it keeps running. More specifically, it does not require administrative keys to ensure that parameters need to be tuned during extreme liquidity events.
Is Whirlpool a fork or a modification of an existing smart contract?
Everything was built from scratch, even the math library, although it was inspired by ideas introduced with Uniswap v3. If you are familiar with Uniswap v3, it will give you an idea of how it works, although there are some key differences based on our design philosophy and the unique constraints of the Solana VM.
Why did everything start from scratch? What happened to the original math library?
In the whirlpool smart contract, we need to do 256-bit calculations. Rust only supports 128-bit math by itself or in its standard library, there is actually a 256-bit library written for an Ethereum client written in Rust called Parity. Since Parity is already in mass production, the library they wrote is safe. Lots of other projects use it, but we've found it to be very expensive when using it. So, to do long multiplication or long division, it usually takes 10,000 computing units to do one multiplication or division. Now, depending on the version of Solana, there can be up to 200,000 compute units per instruction or transaction. Basically, you can only do 10 tick traversals before you run out, but you'll usually need to allocate some budget for other things.
So, we can't do as much arithmetic as we want. We did some research and found that many multiplications and divisions are not optimized. This probably doesn't matter to Parity, since it's basically compiled into something that can run directly on a computer. And for us, it needs to run on a Solana virtual machine. We tested reimplementing it ourselves, and we found that when we reimplemented the library ourselves, it was 5x cheaper and 5x more efficient. It was an interesting detour for us. The 256-bit library is actually used by many people, including the Solana library written by the people in Solana Labs, so we will definitely open source it so that anyone can use it.
What is a PDA, and how can "PDA-centric design" make a whirlpool more efficient?
PDAs are program-derived addresses, in a sense unique to Solana. All data in Solana is stored as an account, which has an address associated with it, which is essentially a pointer to the location of the account. One way to generate this address for an account is to randomly generate a private key, derive the public key associated with it, and then use that public key as the address. Another way is to use a PDA, which allows deriving addresses from the address of the program that created the account, and then seed values, which are usually defined in the program itself.
The key here is that it allows accounts (data sorted in Solana) to be derived from values contained within the program itself or defined by the program itself. We can use these as very nice and clean properties in the smart contract structure.
Usually, we assume that there is a SOL/USDC pool. In the SOL/USDC pool, we will have a specific account. The simple way is to generate an account by some random private key, then discard the private key, and then get this random account.
With whirlpool, we can derive it from the program in a deterministic way. So we can say that the SOL/USDC pool address will be derived from the whirlpool program, including the mint address of SOL and USDC. This allows someone to determine the address of any pair in a whirlpool without knowing anything other than the whirlpool program address and the paired mint address.
This is especially useful for pools that are permissionless in nature, as it enforces the invariant that there can only be one pool for any given trading pair. You don't really need this central store for every created pool, or you don't really need to scan for accounts created by the program. What you really need is the coin's mint address. You want to trade, then you get the pool address, where you can exchange.
Why open source the Whirlpool smart contract?
Open source allows developers, community members, and everyone else to first review the program themselves and understand it in order to build on it.
We consider whirlpools to be the most basic building blocks. There are many applications that can be built on top of it, and open source is the first step to make it happen. We were lucky to have Kudelski and Neodyme to audit our smart contracts, so we are lucky to be comfortable with open source contracts.
Please tell us something about the open source SDK.
Ok, I'm excited to share these too.
We've been lucky to have some great engineers, but one of our early engineers' first assignments was to create a typescript SDK for our initial AMM. He's done a great job with it, and it's great to see the unanimous feedback on how much people love it and how easy it is to use. We also see the value it can bring to us, making it more accessible to those who are interested in using AMM. We've basically doubled down on that: we've basically wrapped up a refactored Whirlpool SDK and a ton of documentation in terms of how it works, because Whirlpool internals are more complex compared to our old pool.
Another engineer of ours, who was working on the transaction confirmation logic, we've seen these network congestion issues. He started digging deeper and discovered some known issues with the way the Solana SDK sends and confirms transactions. For this he made a series of changes which are very useful. We've seen the app's responsiveness change dramatically while using it. He also added a few other things like making it more efficient to sign and send multiple transactions at the same time. There are a lot of inefficiencies in everyone's network requests.
These things we also include in our SDK, so they're not just for Orca: they're also general improvements that anyone in the Solana ecosystem can use.
What would you like to see built above the whirlpool in the next few months?
Maybe I'll start with the most executable idea, and then maybe we can spend a little time iterating or some more unrealistic idea. The most basic one is essentially an automated strategy for the SOL/mSOL pool and the SOL/stSOL pool. These are the pledged liquidity tokens of Marinade and Lido.
Essentially, the value of mSOL should always increase relative to the value of SOL over time in a fairly predictable manner. Because of this, if you provide liquidity in Whirlpools, you will get more and more SOL over time, because the lower the value of the trading pair, the less SOL you have staked.
What you can do is, it is possible to build a process so that you can get more and more pure SOL that you can stake on Marinade or Lido to get liquidity tokens and then put it back into the pool. You can do it in an automated fashion where you always provide liquidity on a minimum scale to maximize the fees you earn. This seems like a relatively simple idea. It will certainly be better than the current method, which is either providing liquidity on a larger scale or doing the conversion manually.
Another potential solution that I think is very interesting is, let's take a lending agreement, take Solend as an example. When you provide USDC or USDT, you will earn some income because you are lending the tokens out. In exchange for offering USDC or USDT, you will get this token called C. It’s essentially just a token that you put up tokens as collateral, and you’ll be able to earn income on an ongoing basis.
One possible thing is that instead of a USDC/USDT swirl pool, you could create a cUSDC/cUSDT swirl pool. Anyone who wants to trade USDC and USDT can use this pool because you can automatically take anyone who trades USDC, convert it to cUSDC, put it in the pool, get back cUSDT, and in one transaction put It splits into regular USDT. For liquidity providers, they will earn income by lending tokens and also receive transaction fees.
Why Start the Builders Program?
We said before that we think Whirlpool will be a key DEX in the Solana ecosystem. It's also a fairly flexible structure, and there are plenty of opportunities for others to build their own ideas on top of it. So we will have a builders program that will encourage and support anyone who wants to build on top of the whirlpool. To that end, we plan to have a percentage of the Orca supply back it, and of course we as the founders and the whole team will help support anyone who wants to build it. We can also provide feedback. I think I'm bound to come up with more and more ideas about what can be built. Yeah, I'm really looking forward to seeing the results.
Do you have any advice for budding builders interested in applying?
I think the first thing is to please come and have a chat on our Discord - we take developer support very seriously. We focus on things like documentation, but talking to us directly is a great way to learn about the product and any questions you may have.
I think maybe in terms of product ideas, one way to think about it is, "Is there something that can be built so that sustainable benefits can be generated more efficiently?"
Like the idea I've come up with before: they have an element that makes it easier to generate the yield that's already there, but essentially just automates it. I think there's a lot to do, especially in Solana because the deals are cheaper and there's more room for design there. I'm looking forward to seeing what ideas people come up with.
Thank you Yutaro!
We hope you enjoy our builder projects.
postpost. Happy development together! 🐳
This post is adapted from a recent episode of OrcaPod.
