Max Resnick - Solana's Path to Decentralized Nasdaq - TOKEN2049 Dubai 2025

Hi everyone, Max Resnik. I'm the lead economist at Anza. And Anza, I guess the simplest way to say what we do is we make IBRL happen. So we develop the core agave client which runs most of Salana. And today I'm going to talk about what the future of the tech in Salana is.

I'm really really bullish about what we're working on and I think after you see this talk you're going to be with me on that. So the title of this talk is how do we make decentralized NASDAQ happen on Salana and that's not something that is new in any way. So since the very beginning of Salana we've been 100% focused on making sure that order books are competitive on chain. So it started out with Serum. Today it's things like Phoenix, Openbook, Drift.

All of these are order books on Salana. But we're still not at the point where we're competing in terms of volume, in terms of spread, in terms of these core metrics with NASDAQ, which is our core target. There's a common misconception that Salana was built to kill Ethereum. Absolutely not. Tuli was way more ambitious than that.

He wanted to kill NASDAQ. And this is a talk about how we're going to do that. So the first step is of course increasing bandwidth. We have today less capacity than NASDAQ does. NASDAQ does about 70,000 TPS and we're doing about 12,000 real TPS.

We have capacity for more like 5,000 uh with the votes that we have on there. But in order to get to a world where we're dominating NASDAQ, we need to dominate them in every metric. and bandwidth is one of those. So, we're targeting a million TPS eventually. You've probably heard that a lot.

But what are we actually doing and how is that actually coming along? So, earlier like about a month ago, we activated the feature flag for SIMD 207, which was, as Tony put it, a CU limit increase for ants. And we did this just to check that if we change the CU limit, nothing breaks. So we we successfully activated that. Nothing broke.

And now uh Brennan from our team at Anza has introduced 256 which is code complete which is in Agave 2.2. It's the last feature flag on the release schedule right now. And we've committed at ANZA to be at a million TPS by the end of the year. And we want to keep doubling or sorry not a million TPS 100 million CU by the end of the year.

And we want to keep doubling that every year. And and that's our commitment. and there's a lot of really smart people working on it. The other thing we want to do is obviously reduce latency. So the Genesis block we started out with Bitcoin at a 10 minute uh block time.

Ethereum today is about 12 seconds. They've said with Beamchain they want to go to 4 seconds. It's going to take them 5 years apparently. Uh but we're already at 400 milliseconds. actually more like 380 because Agave made some performance improvements and we we didn't know what was going to happen but block time actually went down to 380 milliseconds but the next stage after that is 20 millisecond block time and this sounds so crazy and probably people are going to make fun of me on Twitter for saying this but it's actually really possible thing to do and it comes from one of the core ideas that has unlocked a ton of the performance improvements in Salana so far just applying it to consensus And that's called pipelining.

So we have this idea async execution where we completely separate the execution and the consensus. And what that allows us to do is uh do consensus on more than one block at the same time. So we can do things like have 20 millisecond blocks. Maybe it takes 300 milliseconds to do the whole consensus, but we can work on 15 blocks at the same time. And so just like in uh factory you work on one piece of the block and you work on one piece of the car and you turn them out as they come.

This is the same idea here. We're going to pipeline everything and we are actually able to cut consensus down to much lower than say round trip from New York City to Tokyo which is about 200 milliseconds which is uh awesome. So on the reducing latency side, we think we have way more juice to squeeze. Even though it seems like we're at 380 and you know, you need at least two or three rounds for consensus. It seems like we're kind of pushing up against the physical limits there.

But actually, we've figured out that you can do this pipelining stuff and you can get even shorter tick time. So the next thing that we're working on, and this is going to be kind of the majority of what I spend my talk on today because it's the majority of what I work on as an economist, is the thing we really need to do to compete with NASDAQ is to provide better prices than NASDAQ. And what do we mean by better prices? We mean this little gray interval here. We want that to be as tight as possible.

So, I'm showing SoulUSDT on Binance uh from earlier this month. And yeah, we have some crazy volume in crypto. So, you can see that the prices don't really match up with what they are today. But this was from like maybe two or 3 weeks ago. Uh and in the middle there's the difference between the best bid and the best ask.

And that's the spread. And that's really the price that you're getting. And if we want people to use Salana over NASDAQ, we need to give them a better price than NASDAQ. So this is the only equation I have on here. I promise I color coded it for you guys.

There's two sides of this equation. One of them is how much retail flow do you have? The more retail flow you have, the more market makers make the tighter they can set their spreads. On the other side is what we call this adverse selection cost. When the prices move and your prices are stale, somebody like Jane Street or Citadel, they know about the price better than you and they can get there first.

They pick you off and you lose money. We often say market makers pick up pennies and lose dollars. The reason for that is, you know, you you you're going along, say the price looks like in the blue over here. It's moving along inside the Bass spread. You're not super exposed.

and you're just making a little bit tiny bit of money, half a bipundth of a percent on every trade. But when the price goes crazy like on the right, and these are from the same day, just about 12 hours removed, you can have big dislocations massively outside the bid spread. And in this case, this dislocation was around 30 basis points. So you're making half a basis point on each retail trade. And in the case that there's a big jump, you might be losing 30 basis points on all of your levels that you have put out there.

And so what we're trying to do is give app developers the tools to mitigate these losses. In Trafi, when a jump like what I just showed you happens, the cancels win the race about 13% of the time. So what does that mean? There's you're your market maker. You're putting your quote out.

The price jumps and there's a big race that happens and whoever gets there first wins either the cancel or gets to pick you off. And if you cancel, you don't lose money. If they pick you off, they get your money. So there's this big race that happens here. Taker one got there first.

So taker one is going to win. The problem is on Salana today we don't get the same behavior. So they have a 13% cancel rate which is not great but it's not zero. And the market structure on Salana today we're closer to zero. And the reason for that is it's not Jet's fault, but it's just the the architecture of the blockchain makes it so that we have this batching and we have this natural batching and auction period, which means that whoever pays the most, who arrives in this window gets to take or cancel.

So you might think this is okay because now the market maker can bid more and he can cancel. But this is actually also a loss for the market maker. In this example, he's paying $6, whereas if he cancels in the first come, first- serve order book, he cancels for free. So, this turns out not to be a great market structure for building NASDAQ on chain. So, we're going to need to switch things up.

One idea of how to switch things up is to put the cancels first. So, if the cancels win, the market makers don't lose money, and as a result, they can tighten their spreads. So this sounds great. We'll just put the cancels first. This is actually kind of how Hyperlid works for those of you familiar and then we'll have the market makers protect it.

Unfortunately, uh Salana is a pretty decentralized network and we have a lot of validators who can do whatever they want. So we can give them the client that puts the cancels first and uh they might just decide not to put the cancels in the block. And I suspect this will happen on Hyperlid too as they're decentralizing. Uh but basically this problem of censored cancels is pretty hard to get around in a blockchain that works like Salana does today with a single leader. But if we add multiple leaders, you might send your cancel to three different leaders.

If one of them includes you, you'll make it in. And then in replay, we'll put your cancel first. So that's what we're going to try to do, but it's not going to be the easiest to make it work. Otherwise, somebody would have done it already. So the first thing we talk about with multiproposer is suppose we have multiple blocks.

The first question I always get, how do you merge those together? And it's actually way simpler than you might think. We just have three blocks. Each of them have some transactions. We put all those transactions into a big pool.

And then we order them by their priority fee. So the higher priority fee you pay, the more you will have priority in the execution block. which is that the applications need to be able to read the priority fee as well. So once you let the applications read the priority fee, you actually give them a ton of flexibility with which to reorder transactions as they would like to see them. So I have on the your right I guess an example here where an application wants to put the cancels before the takes.

So what they do is they set a minimum threshold above which all the take orders will fail. So now if you want to put a take order in you have to set below 100 uh lamp ports of priority fee. And that gives you basically the same control as if we gave them full application specific sequencing. So this is great. It means we can do a very simple rule and we can get a very rich set of results for our uh apps and honestly like apps are the most important thing to build for users first apps then uh our devs are after that.

So we really want to give as much flexibility to apps so they don't move offchain in uh so here's going to be the more technical part of the talk where we talk about how to actually do this. This is my favorite part of the Salana protocol. It's called turbine and it's used to get the block from the leader to the rest of the network as quickly as possible with as little failure risk as possible. The way it works, we take a block which is represented by this things from 1 to eight up there and we shred it. So what does it mean to shred it?

We cut it into pieces and then we compute some eraser coding. Uh and so we pad with some extra eraser coding. What that does, it adds redundancy. If one of these little shreds doesn't get to validator 7 up here, that's okay because we have redundancy built into the system. And it also uh decreases the latency to get from point A to point B because we don't have to go along the longest path.

We can go along sort of the 50th percentile path. And this is a overview of like a single layer turbine, but actually we have slightly more layers. One of the things we're going to be doing is moving to a single layer tree which will reduce latency. So how do we modify that for the multi-leer regime? So the first thing we do, we have multiple leaders here.

Each of them take their block and shred it just as before. And then they send their shreds to the relays. So as they're doing that, uh they're basically making sure that relay one R1 has uh three pieces, one from each block. And same for really two, rele three, really rele four and so on. Now the consensus leader is basically the leader that we have today, a single leader.

And he receives I have messages. So that says I have shred one from leader one, shred one from leader two, shred one from leader three. What he's going to do is take those I have messages and pack them into a block. Okay, so this is basically telling the network that the consensus leader has received enough messages that say these blocks are available in the network. So we're doing this so that we can hide the contents of the block until it's it's time to reveal them.

It's super important for preventing things like sandwiching, for making the market structure good, for preventing adverse selection. And that's what this whole construction is for is basically hiding the blocks until we're ready to reveal them. After this, we're going to do a round of normal consensus as we would and you know that's our 20 millisecond consensus we were talking about earlier in the talk. So once consensus concludes we can spray out all the shreds from the relays reconstruct that and then execute according to this uh merge rule. So that's basically how we do multiple leaders on Salana and uh we're working really hard on building it.

Let me as a final point do a little review here for you. So at ANZA we're working on IBRL and we're working on fixing the market structure because we want to bring uh NASDAQ on chain. We're working on a million TPS and you saw the actual like sims that are actually going in from our team right now on that. We're working on getting the block times down further below even the roundtrip New York City to Tokyo with pipeline async execution. We're working on improving turbine and turning it into multiler turbine so we can have multiple concurrent leaders.

What that does is it lets us defend against toxic flow. And the result of defending against toxic flow is that the market makers win more often, the spreads are tighter, and then hopefully we can compete with NASDAQ. That's all I had for you guys today, but uh thanks for listening to me. And I I had one equation, so sorry about that. Hopefully that wasn't too post-traumatic for you guys.