BUILDERS PROGRAM

Exploring the Whirlpools Builders Program

Why Whirlpools, why now? The answers lie in the deep…

Two weeks into the Whirlpools Builders Program, and we’re already seeing plenty of activity beneath the sea! 🐳

(If you’re new to the pod, we’re issuing grants of up to $200,000 in ORCA to builders developing apps on Whirlpools, our concentrated liquidity pools. To get up to speed, check out the Program launch post here!)

We’re delighted by the number of applications we’ve received so far and the innovative ideas on display. In this post, we’ll be exploring the Whirlpools smart contract and the future of the Program with our co-founder Yutaro Mori in a Q&A!

We’ll be into a lot of detail in this interview, so if you’re not already familiar with concentrated liquidity, we recommend you read our introduction post here.

With that said, let’s cast off…

Yutaro, first off: Why are we building on Whirlpools?

We are confident that the basic structure of Whirlpools is going to be the main way that liquidity is created in the Solana ecosystem: It’s going to be the dominant DEX in Solana. It’s something that we’ve been building for the last six months, and we launched it in beta back in March.

What are the advantages of Whirlpools compared to standard (or “constant product”) liquidity pools?

In a nutshell, Whirlpools give users a better swap experience: Both for the blue chip tokens where there’s a ton of liquidity to be expected (like SOL and USDC), but also long-tail tokens.

The reason why it gives users a better experience when swapping blue-chip tokens like SOL and USDC is because liquidity providers have a lot more control over how much liquidity they provide, and what kind of slippage they want to provide when traders want to trade against the pair. And the key point is that it’s more efficient for liquidity providers. So overall, they have to allocate less capital to provide users a better experience.

What makes Whirlpools a great building block for the Solana ecosystem is how robust it is in the sense that there’s no single point of failure, and there’s actually pretty much no maintenance that’s required from, let’s say, the Orca team in order to ensure that it continues to function. More specifically, it doesn’t require admin keys to make sure that parameters need to be adjusted in an extreme liquidity event.

Is Whirlpools a fork or a modification of an existing smart contract?

Everything is built from scratch, including even the math library, although it was inspired by the ideas introduced by Uniswap v3. If you are familiar with Uniswap v3, it’ll give you a sense for how it works although there are a number of key differences based on our design philosophy and also based on the unique constraints of the Solana virtual machine.

Why build everything from scratch? What was wrong with the old math library?

In the Whirlpools smart contract, we need to do 256-bit math. Rust only supports up to 128-bit math natively or in their standard library, and there’s actually a 256-bit library that was written for a Ethereum client written in Rust called Parity. Given that Parity is in production, the library itself that they wrote is secure. It is used by a ton of other projects, but what we found when using it was that it was incredibly expensive. So, doing long multiplication or long division, it oftentimes cost 10,000 compute units for a single multiplication or division. Just to get a sense of scale, right now, the maximum amount of compute units that is possible in Solana is 200,000 per instruction or transaction depending on the Solana version. So basically, you can only do 10 tick traversals until you run out, but you usually have to allocate some of that budget for other things as well.

So, we couldn’t really do a lot of the arithmetic that we wanted to do. We looked into it turned out that a lot of the multiplication, division wasn’t really optimized. It probably didn’t matter for Parity because it’s compiled essentially into something that could be run directly on a computer. Whereas for us, it needs to be run on the Solana virtual machine. We tested out re-implementing it ourselves, and we found that it was I think around five times cheaper or five times more efficient when we’ve re-implemented the library ourselves. That was kind of a fun detour for us. The 256-bit library is actually used by a lot of folks including the Solana program library the Solana labs folks have written, so it’s something that we’ll definitely open-source so that anyone can use.

What are PDAs, and how does “PDA-centric design” make Whirlpools more efficient?

So PDAs are Program Derived Addresses, something unique in some sense to Solana. All data in Solana is stored as an account, and the account has an address associated with it which is essentially kind of 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 as the address. The other way is using PDAs, and that allows the address to be derived from the address of the program that creates the account and then seed values which are usually defined in the program itself.

The key point here is that it allows accounts (which are the data that’s sorted in Solana) to be derived from values that are contained in the program itself or defined by the program itself. We can use these as really nice and clean properties for the structure of the smart contract.

Normally, let’s say we have a SOL/USDC pool. In the SOL/USDC pool we will have a specific account. The simple way to do it is for the account to be generated from some random private key, and then we discard the private key, and then you get this random account.

With Whirlpools, we can derive it from the program in a way that is deterministic.So we can say the SOL/USDC pool address will be derived from the Whirlpool program, including the mint addresses of SOL and USDC. That allows someone to determine the address of any arbitrary pair in Whirlpools without knowing anything other than the Whirlpool program address and the mint address of the pair.

Where this gets particularly useful is for essentially permission-less pools, because it enforces this invariant that for any given key pair there can only be one pool. You don’t really need this centralized repository of every single pool that’s been created, or you don’t really need to scan accounts created by a program. All you really need is the mint address of the tokens. So you want to trade, and then you get the pool address, and you can just swap there.

Why open-source the Whirlpools smart contract?

Open-sourcing allows developers, community members, and everyone else to first vet the program themselves and understand it so that they can build on top of it.

We see Whirlpools as this very basic building block. There’s a lot of applications that can be built on top of it, and open-sourcing is a necessary first step for that to happen. We’ve been fortunate enough to get Kudelski and Neodyme to audit our smart contract, so we’re fortunately in a position where we feel pretty good about open-sourcing the contract.

Tell us a bit about open-sourcing our SDK.

Yeah, I’m excited to share that as well.

We’ve been fortunate to have some awesome engineers, but one of our earlier engineers, his first task was to build a typescript SDK for our original AMM. He just knocked it out of the park, and it’s been great to see consistent feedback on how great it is, how easy to use it is. We’ve also seen the value that it can bring to us in terms of making it easier for people that are interested in using an AMM to use it. We’ve essentially doubled down on that: We’re basically wrapping up a refactor of the Whirlpool SDK and plenty of documentation in terms of how it works given that Whirlpools is more complicated internally compared to our old pools.

Another one of our engineers, he was hacking around with the transaction confirmation logic as we’ve seen these network congestion issues. He went off and dug into things, and he saw that there were these known issues with the way that the Solana SDK had been sending out transactions and confirming transactions.

He went ahead and implemented a series of changes to do that, and it’s incredibly useful. We’ve seen huge changes in the responsiveness of our application just from using it. He also added a few other things like making it a lot more efficient to sign and send multiple transactions at a single time. There are a lot of inefficiencies in the network requests everybody made there.

These are things that we’ve included in our SDK as well, so they’re not just specific to Orca: They’re also just general improvements that anyone in the Solana ecosystem can use.

What would you like to see built on top of Whirlpools in the coming months?

Maybe I’ll just start with the most executable ideas, and then, maybe we can spend a little time riffing or something on more pie in the sky ideas. The most basic one is essentially an automated strategy for the SOL/mSOL pool and the SOL/stSOL pool. Those are the staked liquid tokens for Marinade and Lido.

Essentially, the thesis is the value of mSOL should always increase relative to the value of SOL over time in a way that is fairly predictable. Because of that, if you provide liquidity in Whirlpools, over time, you’ll get more and more SOL because that’s the less valuable of the pair and then less of the staked SOL token.

What you can do is, it’s possible to set up a process so that as you get more and more of just the pure SOL, you can just stake it on Marinade or Lido to get the liquid stake version back and then put that back into the pool. You can just do it automatically in a way where you always are providing liquidity in the tightest range to maximize the amount of fees that you’re earning. That seems like a relatively simple idea. It would definitely be something that would be superior to the current approach which is either to provide liquidity across a wider range or manually do that conversion.

Another potential one that I think would be interesting is, let’s take a lending protocol, say Solend. So when you provide USDC or USDT, you earn some amount of yield because you’re lending out the token. In exchange for providing USDC or USDT, you get this token in return that are called C tokens. It’s basically just a tokenized version of the tokens that you provided as collateral, and you’re going to continue to earn yield there.

One thing that’s possible is instead of a USDC/USDT Whirlpool, you can create a cUSDC/cUSDT Whirlpool. That pool can be used by anyone that just wants to trade USDC and USDT because you can atomically take whoever’s trading their USDC, convert it into cUSDC, put it into the pool, get cUSDT back, and unwrap that into regular USDT in a single transaction. And then for LPs, they will be earning yield on both lending out the token and then also earning the swap fees.

Why launch the Builders Program?

We said before, we feel like Whirlpools is going to be the key DEX in the Solana ecosystem. It’s also a fairly flexible construction, and there’s a lot of opportunity for others to build their own ideas on top of it. So, we are going to have a builders program that will encourage and support anyone that wants to build on top of Whirlpools. For that, we plan on having some percentage of the Orca supply to support it and then of course us as founders and the entire team will help support anyone that wants to build. We can also provide feedback. I think I will definitely propose more and more ideas in terms of what can be built. Yeah, I’m really excited to see how that plays out.

Do you have any advice for budding Builders interested in applying?

I think first thing is please hang out at our Discord — we do take developer support seriously. Documentation and such is something that we will lean into, but just talking to us directly is a nice way to get a feel for the product and any kind of question you may have.

I guess maybe in terms of product ideas, one way of thinking about it is like “Is there anything that can be built that enables sustainable yield to be generated more effectively”?

Like with the ideas that I proposed earlier: They have an element of making it easier to generate yield that was already existed, but essentially just automating it. I think there’s a ton that could be done there especially on Solana where the design space larger just because transactions are cheaper. I’m really excited to see what kind of ideas people can come up with.

Thanks Yutaro!

We hope you enjoyed this deep-dive into our Builders Program.

If you’d like to apply for a grant in our Builders Pro, or are simply interested in learning more, check out our launch post here. Happy building! 🐳

This Medium post is an adaptation of a recent episode of OrcaPod — t

Disclaimer: The content of this communication is not financial advice and should not be relied on by any persons as financial advice. This communication has not been provided in consideration of any recipient’s financial needs. We have not conducted any financial assessment based on the personal circumstances of any recipients. Before using the protocol, carefully review all relevant documentation and consider risks including total loss of funds.