Projects
![]()
No projects found
Investors
New
DAO Treasuries
DATs
Lend / Borrow APRs
Chains
Categories
Spaces
Introducing Whisk, Protocol 23: Scaling the Stellar Network
Recorded: Sept. 4, 2025 Duration: 0:39:24Space Recording
Full Transcription
The End Thank you. how's it going everyone my name is gabby I work at the SCF in our marketing department.
We're going to get started pretty quickly. Give us about a minute or two just to get a few more
folks in here. And Justin, our head of ecosystem, is going to kick us off.
Awesome. Thanks, Gabby. Yeah, so we'll wait a minute here, maybe one more minute to let
people join, and then we'll get started. That music was really nice. Really set the tone
here, framed this up. But anyway, yeah, for those of you who are joining, this is about to be a Twitter space,
or I guess it has already started, about the new protocol release that is now live on Stellar
Mainnet. It's been live on Testnet for a few weeks before, and we're going to talk it through.
So I'm going to officially start in one more minute. Right now, this is just vamping.
Vamping since the music stopped. I did try to get it back, but it's just not,
it's not wanting to. Sorry, Justin. Oh, no, I understand. I understand.
In the meantime, maybe we could do a really quick tech check with our speakers. Garen,
are you here? Yes. Hellolly hello hello fabulous and dima
you may just have to click the unmute button
i see you as a speaker but I'm not hearing you.
Is anyone else hearing Tima?
I am not.
Okay. not okay and it looks like the can't hear us either.
So we're going to have him try to join through a different browser. okay
okay Okay.
Alrighty, Dima, did that help?
I do see you unmuted now, but we cannot hear you. Okay.
Okay, well, while Dima gets that figured out, Justin, why don't we get started and I'll
Okay.
have him try to join from a different browser.
Okay, great.
Thanks everyone for joining.
This space is about WISC protocol 23, scaling the stellar network.
And first I just want to talk about WISC protocol 23, scaling the Stellar network. And first, I just want to talk about WISC.
WISC is a name which is obviously different
than what we've called protocols in the past,
which is just a number, WISC, WISC.
So why does this protocol have a name?
I mean, I think it was actually long overdue
to start naming protocols.
Protocols introduce features and improvements
that change the way the entire Stellar network operates.
They ripple throughout the stack and have implications on sort of the efficiency, the functioning, the guts of Stellar, but also on developer experience and ultimately on
end user experience.
And each protocol bundles a bunch of these features and changes.
And it's kind of hard to keep track of them over the past 22 protocols.
There have been a lot of times when it's like sort of would be easier to talk about or think about
or reason about or remember all the changes that are bundled to update Stellar
if we just had a simpler way to describe them, hence a name, WISC.
WISC is an everyday tool and it starts with the letter W.
W because that's the 23rd letter in the alphabet and WISC because we are going to be
naming subsequent protocols after Everyday Tools and each one will sort of correspond with the
letter and we get to the end of the alphabet we'll start back over at A. Everyday Tools is something
that we chose because it's catchy, it's memorable, it's short. It's also a namespace that not a lot
of other people have entered into yet but it's pretty fitting for a protocol because each protocol actually introduces useful things that make everyday building on Stellar better.
So WISC, Protocol 23, that we're here to talk about. What does it do?
There are a couple of things that are pretty major that are introduced in WISC.
There are kind of under-the-hood improvements
and ergonomic improvements.
Under the hood, it really improves execution time.
It introduces parallel transaction processing,
which we're going to talk about in a minute,
as well as state moves in memory.
And it has all these other improvements with caching
that help boost throughput and ultimately keep costs low for transactions on Stellar.
It also introduces some big DevX improvements.
There's unified events make it so that now you can actually build on Stellar
and reckon with the results of transactions and the data that they produce
using a single system instead of having to think about two different systems,
classic and smart.
I think the implications of all of that is that it makes it a lot easier using a single system instead of having to think about two different systems, classic and smart.
And I think the implications of all of that is that it makes it a lot easier for people that are already building on Stellar to incorporate smart contracts into classic applications.
And it also makes it so that new people building on the network will have a much faster time to integration.
So these are kind of the major things that happen under the hood improvements that allow for scalability
and ergonomic improvements that make it a lot easier to develop on Stellar.
And we are going to talk through all those things.
But we're going to talk through them from an engineering point of view, because behind the scenes, all this work took a lot of engineering.
And we have with us several engineers from the Stellar development engineering team who work on different parts of the stack who are going to talk through things.
And I guess we'll start out by just letting them introduce themselves.
Let's start with Garen. Garen, can you just talk about, just say who you are and what you do and
sort of what you worked on for Protocol 23? Yeah, sure. So I'm a core engineer here at
Stellar Development Foundation. And I guess my two focuses on this particular protocol were with the kind of storage and state layer.
So that's all the state archival things
and the in-memory cache that we'll talk about here in a bit.
And then I've also been working on some of the timing issues,
so particularly CAP70, and working on ways
to get our block times and finality down
in a little bit quicker. Awesome. Thanks. And we'll sort of hand it to you to talk about scalability issues and
what you've been working on. Let's see. Dima, I think we were having some technical issues
with, but now we're going to try again. Dima, are you here?
Can you hear me?
Yes, there you are. Dima, same thing. Can you just talk about sort of what you worked
on for Protocol 23 WISC and what you generally sort of do on the engineering team at SDF? And for protocols, my district specifically, I spent most of the time working on various resource
and peer-related issues in all the caps
we have introduced here.
And I have also worked on the parallel contract execution,
which also helps with the scalability
in one of the dimensions.
Great, thank you.
And finally we have Molly from our platform team.
Molly, same thing, can you talk about what you do
and what you did for protocol 23, WISC?
Sure, so I'm a senior engineering manager
on our platform team.
That's the team that kind of maintains
and manages like products like RPC, Horizon, Galaxy,
so downstream of core.
Being that I'm a manager, I mostly take credit for other people's work. But my team, I think,
Protocol 23, most of what we worked on, right, was optimizing the experience for downstream,
right? So you'll hear a lot about unified events, how bettering of the user experience with things like auto restore,
taking advantage of a lot of the performance improvements in core and how we wrapped that
into RPC and things like that. So generally kind of developer first, developer first experience.
Awesome. Thank you. So yeah, now that we've got a little bit of an overview and you can tell that we have sort of different parts of the engineering organization represented here, I think let's dig into each of those a little bit and talk a little bit more about how they worked, what they mean, and how these changes sort of impact builders on Stellar and actually even end users of Stellar.
And I think let's start with Garand.
Garand, I know you worked a lot on the state archival stuff and also on the in-memory state
stuff for WISC. Can you talk through both of those and sort of what impact they have?
Yeah, so I guess these are the sort of natural conclusion to the Stair Archival story,
which we started all the way back when the smart contracts launched back in Protocol 20.
So before I get into actually what kind of these two features are, let me talk a little bit higher
level about Stair Archival for a little review. So basically, blockchains have this issue,
all public blockchains, including Stellar, where there's lots of bloat
and spam. There's lots of meme coins and, you know, assets that no one's actually really actively
using. And the issue is, once these things are uploaded, they can't actually be deleted by the
blockchain. And so what you have in practice is you have these very large databases that have all
this information, most of which is never actually used. And then the small subset of data that you actually do frequently interact with,
think assets like USDC or DEX, routers, things like this, they're actually being used,
kind of suffer because they're in the same bucket and in the same database as all of the rest of this unused storage. And so it's essentially the spam and
the memes slow down the network in the database for all of the other assets that are actively
being used. And so this is the problem that State Archival seeks to address. So essentially what it
does is that instead of letting everything be live forever, it charges a rent fee. And so for every piece of state that's on the network, it has to routinely pay a small fee to continue to be live.
If it doesn't pay that fee, it becomes what we call archived.
Now, archived state isn't gone forever.
You can, of course, restore it and use it so that there's, you know, no loss of data.
know, no loss of data. But what this allows us to do is kind of in a fair and decentralized way at
the protocol level, actually distinguish this sort of useful live state versus state that's not being
used very much. And this is our end goal. You know, we don't want to, you know, pick specific assets
or contracts that we deem as the useful stuff, you know, that's not very decentralized. And so
this sort of rent fee allows us to organically
determine the useful state versus the not useful state in an economic manner. And so that's kind
of what we did all the way back in protocol 20. Now what we introduce here is actually using that
information. So we've added the interface and I'm sure the developers on the call know that you've
been paying rent and doing restores for a while now.
But starting with WISC, we actually distinguish and make optimizations based on data that is useful and live versus the not used archive data.
And so first, what we have is a CAP62, which is called Livestate Prioritization.
And basically what this does is just keeps everything in two separate databases.
So we have a kind of smaller, faster database, or at least in theory, it will eventually
become smaller and faster, which is called our live state.
And this contains all the information
that's actively paying rent.
So this is the stuff that people deem useful enough to pay for.
And then we have a second database
called the Hot Archive database.
And this is a larger and slower database.
And this stores all of the stuff that people aren't paying rent
for.
And so this essentially allows us to kind of solve
the needle in the haystack problem.
We can move all of our needles, all the useful state,
to one centralized location inside the validator database.
And then all the stuff that's not being used and people
aren't paying rent for goes into the hot archive now there's a couple of interesting properties of the stay
archival system that lets us actually do a little bit more than that though and so one thing about
stay archival is that there's a network config setting um that lets us essentially limit the
amount of live state that can exist on the network at any given
time. And so in protocol 23, that limit is currently one gigabyte, I think, but it can be
changed in the future. Now, what this means is that we have this system where all of the live
state that we actually are going to use and care about is in one database. And we know that that
live state can never exceed one gigabyte. And so because we
have this specific location and because the size of the data is bounded, what we end up doing is
just throwing everything in memory. And so this is what happened in CAP66, which is the Sorbonne
in-memory read resource. And so what this means is that whenever you invoke a smart contract,
starting in protocol 23, all of the data that a smart contract, starting in protocol 23,
all of the data that that smart contract needs lives in memory, or the contract data at least,
which means we don't actually have to do any disk reads. This not only greatly increases the speed
and efficiency of the contracts, but also means it can be a lot cheaper. So because memory reads
are so cheap, we essentially don't charge fees and don't have limits on the amount of read or the bytes you read.
And so to kind of use an Ethereum or Salon example, this is essentially having a gasless disk or access to an entry state.
And so it's a very powerful primitive.
It unlocks a lot of new use cases for developers that were kind of limited by the amount of entries they could read.
It makes everything cheaper.
Fees go way, way down and just makes the network faster as a whole. Do any other blockchains
have, or do other blockchains have a bounded state? No, so this is actually kind of a very
unique thing to Stellar, that because of stare archival, we have a known upper bound on the
amount of memory. And so if you look at other
networks, you know, some have tried to do sort of this in-memory caching, but it's optimistic,
which means that sometimes there are cache misses and they have to do disk reads.
And so what this results in is you can't actually remove the fee, because if you removed the disk
fee and then you had cache misses, it'd be possible for an attacker to sort of
abuse that edge case from a fee perspective. And so because we deterministically know exactly
that all state will be cached and that we can bound that amount, we are able to do things with
fees and limits that other blockchains that just use kind of optimistic database level caches cannot
And what's the impact in the long term as Stellar continues to scale? Like, how does this how will this play out at scale?
Yeah, so I think the thing that we've observed is that even blockchains that have very large databases,
like your Ethereum that has, you know, several hundred gigabytes of ledger state, very, very small amounts of that state is used at a given time.
And so essentially, this just allows,
even as Stellar becomes more used
and has more state attached to it,
the amount of live state will probably scale,
but it won't scale nearly as fast
as the amount of overall state.
So for instance, I think the numbers are maybe six months old,
but Ethereum has like 330 gigs of state.
And then on a daily basis,
I think like a hundred megs is actually used.
And so, you know,
I think even if we achieve very, very significant scales
and volume, the actual amount of live state being used
on a regular basis will still be quite small
such that it can still be maintained in memory
and be very fast for the foreseeable future.
That's pretty awesome.
So in-memory state and bounded state
is something that is really going to help Stellar,
like sort of differentiate Stellar,
especially as it scales.
Also, we're the only blockchain
with something called the Hot Archive,
which is, I like one a t-shirt that says Hot Archive. I feel like it's
a good, it's a bockative. Okay, anyway. Dima, let's talk a little bit about what you've been
working on. I think let's start by talking about parallel execution. Can you explain what parallel execution is and what it means
that it's now live on the network? Yeah, sure. So I will again start, as Garand did,
from the beginning of Soroban. And I want to say that Soroban has been designed with parallel execution in mind. And this is the reason why every smart contract
transaction needs to include so-called footprint, which is the list of the entries the transaction
is going to access, separated by the red-only entries and read-write entries. And this was a very intentional design choice, because if we know which data
is accessed by every transaction, we can basically tell which transactions are completely independent
of each other and can be executed in parallel, and which transactions may depend on each other's data and that have to be serialized.
Now, different possible approaches to the parallel execution
and the approach we took is approach
where we actually know the upper bounds of the time
it is going to take to execute a given set of transactions.
Because the thing is that imagine that yes, we know which transactions depend on each other,
but we do not do anything at all about
grouping these transactions together.
And the situation we may end up with is that
from time to time
we will get a ledger where all the transactions depend on each other and execute series and
the ledger close time would go up proportionally to the number of threads we would be dedicated
to executing this transaction so for example if you had eight threads we could have up to
eight times execute up to eight times longer ledger close time,
which is really not acceptable and truly susceptible to the dock of the network.
That's why what we did in protocol 23 is a standardized way of building transaction sets that can be deterministically for which we can
deterministically estimate the execution time. And the way we do
this is pretty simple. For every set of transactions, for every
ledger, we prepare a set of transactions. And for every set of
transactions, we basically group transactions together by so-called clusters of
transactions that may depend on each other, but that definitely do not depend on transactions
in different clusters. And these clusters are very easily mapped to actual physical threads.
For example, we have four different clusters of transactions and the protocol guarantees
that transactions in any cluster do not depend on transactions in any other cluster.
And that's why a validator machine or a captive core machine may spawn for physical threads,
execute these transactions in parallel and not worry about any side effects impacting
each other.
And the great thing about it is that protocol also guarantees that in each cluster, it will not execute more than a given configured amount of instructions.
And this is what actually gives us upper bounds on the execution.
And for example, if you say that every cluster may have
only up to 500 million instructions,
then we have four physical threads executing these clusters and we have 500 million models
instructions for executing all four of them in Perl as an upper bound. Now we also do another
cool thing which is that sometimes data needs to be serialized,
but it is not highly interconnected.
A simple example would be, for example, an Oracle contract.
Imagine there is some Oracle contract that has a data entry that tracks cost of some
assets.
And then imagine you have a bunch of contracts that depends on this oracle in one way or another
but usually the dependence on an oracle means that well i want to read the price from the oracle
now imagine the oracle updates the price so what you will end up with is one transaction that writes
a data entry and then a lot of transactions are free from it. And if we just mainly did sequestering
as described before,
then what we might end up with is that
this single transaction that writes data
makes a lot of read-only transactions to TRIs
and only be executable to QuenChiely.
And in order to prevent this behavior,
an additional thing that protocol does is that besides looking at the transactions by clusters, we have these so-called stages that execute sequentially.
So every stage has multiple clusters that execute in parallel, dedicate the right one stage and then execute all the reads in a different stage in parallel.
And in practice, well, of course, we don't need to get our data from the PubNet, but on the experiments we did evaluating this approach seems to solve this sterilization problem for a lot of the scenarios
that we anticipate.
Of course, it cannot solve scenarios when everyone
writes the same entry, but this scenario where entries
need to be read and written, you actually can
effectively distribute them between the stages,
still execute them in parallel,
and thus the lecture capacity will remain with time.
So this is what we did for the parallel execution.
And I guess, I can talk about the impact.
Yeah, yeah.
What's the impact of all of that work?
Like what does parallel execution mean
in the long term? What possibilities does it open up?
Right. So it is important to note that Keller has a multi-dimensional resource model, meaning
that there is no single gas unit that is somehow needed for a ledger. Instead, we have several different dimensions, such as
instructions, entry rights, amount of entries written, or amount of bytes written,
but also the transaction in the ledger and so on. And pro-execution unlocks one of these
dimensions, which is instructions. it allows us to scale the
number of instructions educated pro edgework multiplicatively with the number of course
on low data machines and um so this is several times like eight ten maybe more times depending
on the machines um what this means in practice until we uh lift other limits is that the first thing is that we can do more resource or computationally intensive transactions.
Like we can include more transactions that require a lot of instructions into the same lecture. And for the network, for the developer who sends transactions to the network,
it means that the market pressure will likely be lower because now we can include more transactions into ledger
and there is no need to pay the search pricing fee.
I must know that there is a caveat that other research
dimensions. So for example, if we have a lot of tiny transactions that write a lot of data,
polarization will not help. But in the long term, as Stellar looks into more advanced cryptography, zero knowledge and so on.
We think that there will be more demand actually for the computational resources, for instructions
and pro execution is one of the steps that will help us enable that in the future and
make it so it is possible to do multiple complex transactions in the same ledger,
just increasing the GPS for this sort of workload.
Great.
So I think these under the hood improvements,
that parallel execution that sort of set up
the future of Stellar where it can handle
a lot more transactions and more complex transactions,
as well as like the sort of in-memory state and bounded state. But all of these things like sort of set up Stellar so that it will be able to scale to handle a lot more transactions, a lot
more complexity, and to do it without increasing fees significantly. So I think these are really great changes
to kind of the engine that drives Stellar.
But Wisk also includes some pretty cool developer experience
changes that will be visible and sort of usable
to people building on Stellar immediately.
And Molly, I'm hoping you can tell us a little bit about those.
Yeah, definitely.
I mean, I think the biggest change, right, in protocol 23 is
this, right? It's how kind of signals a shift in how we think about developer experience and data
on Stellar. Those concerns, not only in Stellar historically, but in a lot of other chains,
they're typically secondary to things like performance, scalability,
et cetera, right? But this is really the first time we're kind of attacking this at the protocol
level as opposed to somewhere downstream. So it's kind of like us saying, like, hey,
we think of this as a first-class citizen, and we're really kind of putting our money
where our mouth is, so to speak. So specifically what I'm talking about is this term that we've coined unified events. in order to get a full picture of everything going on across classic and smart contract land.
So you'd be in for quite a clunky mess
if you were trying to do that on your own,
and chances are you'd still get a lot of things wrong.
If you want to see how painful this was before,
you can actually check out some code we built around this
to do this parsing called the token transfer processor in our docs. But now with protocol 23, all the transfers of value on the network
emit the same exact event schema, right? So there's one clearly defined, easy to understand
standard format for the whole ecosystem to use. This is a huge win for analytics, data providers, really anybody building
any kind of downstream integrations, anybody reading data on Stellar,
which is probably everybody or most people.
They get to now kind of just pretend there's no classic,
there's no Sorbonne or smart contracts, right?
no Sorbonne or smart contracts, right?
There's just Stellar.
They're just stellar.
There's Stellar events.
And the other big thing about unified events
is that they're retroactively applied to ledgers,
which is kind of subtly huge, right?
Like in most protocol releases,
we really only start emitting new meta or new data
on a go-forward basis.
But we really chose to kind of go the extra mile here
so that people can now re-ingest past ledgers
all the way back to Genesis
and see these events show up, right?
So you can pretend there was never a difference
between Classic and Soroban if you really wanted.
And on top of that, I think that's probably the biggest thing,
but there's a bunch of quality of life improvements
that we've made to downstream products
to kind of complement this as well.
So, and some of the things that were built in core, right?
So you just heard Garen speak,
spoke a lot about state archival.
If previously you had tried to interact with archived entries in RPC, you'd kind of get
an error during simulation.
You'd have to submit a separate operation to restore that to the live ledger and then
simulate again.
It was kind of like a back and forth, back and forth, obnoxious process.
If you've ever had to do that before, you know how annoying it was.
Now that's kind of handled all for you behind the scenes in simulations or something we call
auto-restore. So ideally, you don't even really know that's happening. Hopefully,
you know, State Archive will give us all the goodies we want from performance scalability
perspective, but we don't want it to harm the developer, the operator experience in any way. And this pushes us a long way there.
A bunch of other smaller improvements in kind of RPCs APIs to kind of complement unified events. You
can go read about all those. They're kind of minor in the release notes, but there's two really big
improvements as well that I think are the most exciting. The first being the kind of minor in the release notes, but there's two really big improvements as well that I think are the most exciting.
The first being the kind of performance, durability improvements to how ledger entries are retrieved from RPC.
So under the hood, we have actually removed kind of this duplicity of local storage.
this duplicity of local storage.
So now RPC kind of proxies directly to core,
which was made possible by all these performance improvements,
parallel execution on core side.
So again, really complementing each other,
taking advantage of that.
But the other huge thing that really complements
unified events RPC side is that RPC can now act
as an archival node, which is a long requested feature,
meaning it supports full history. Now, this is limited actually in the endpoints that it
supports right now, but more will be coming soon. And that's pretty major because combined with the
unified events at the protocol level, this means someone,
anyone that's already integrated with the RPC interface in their backend, in their wallet,
in whatever, they can now just use RPC to re-ingest unified events across all of history.
They don't have to go to Hubble, go to an analytics source, or take three months plus to ingest it all themselves.
It's all just there, all available.
And actually this morning, just today, actually the LightSail network launched kind of the first ever free public version of this in the ecosystem.
So that's incredibly exciting that that got together
so quick. And really, it means that anybody can now go out there and start playing around with
Unified Events back to Genesis for free today, which is crazy. So yeah, all these features
together, like really, takeaway is they all really amplify the impact of one another, right?
Like we're making the developer experience better
because of a lot of these changes that are available in core,
and just building on that.
Amazing, thank you.
Yeah, it's pretty amazing to see how much work goes in
throughout the entire stack to update the protocol, to release
WISC. It requires this very thoughtful design from the core side, as well as that helps with
the underlying engine that drives Stellar. It helps make sure that there's speed and scalability,
that there's improvement in throughput, and that it all happens in a way that bounds state so that
it doesn't grow and become impossible to maintain the network.
And then on the sort of platform side and the developer experience side,
there's all this thought that goes into making it
so that people can access those features
and so that all the pain points that make it hard to build on Stellar
get removed, right?
And I think when you actually look at what Molly was just talking about,
this light cell network that launched today, you realize that the speed that that opens up for development really does change things. support scale and to just function better. But also, it is so much faster to be able to build
on and to acquire data, to interact with events. And it's pretty cool that you can actually just
sort of look back, you can just change your entire world, your view of history and look back at
ledgers from the sort of dawn of Stellar into now through this new sort of clearer way of
understanding what's happening on the
network. But I think all of these improvements, they really were built with the ecosystem in mind.
They were built so that developers on Stellar have a better experience, so that as their products
find traction, they'll be able to acquire users and push transactions without running into walls
or negative impacts and without overburdening
the network or causing costs for validators to go away.
And all of that balancing is something that really happens because all this thoughtful
engineering is driven by input from the ecosystem, by a long-term vision of what Stellar can
be and how it can reach out and have an impact on real-world, everyday financial transactions.
And it's really impressive to see.
So WISC, there you have it, Protocol 23, WISC. If this was interesting to you, you should join
the discussion. You should go on to Discord. The StellarDev Discord is where we have all the
discussions about what's happening in new protocols. There's also a StellarDev mailing
list that you can find there where you can sort of get, you'll be informed about new discussions
and proposals for core advancement proposals,
which is how these new features start
before they're integrated into a protocol.
And as you follow along,
we really do want to hear if you have pain points,
if you have ideas,
if you have requirements for something that you're building
and you believe that there's a change to the protocol
that is necessary to unlock some potential, we want to hear from you. And so
please join the Discord, join the mailing list, get involved, follow along. All of this is built
out in the open. And I guess my final request to you, it made so much sense to name these
protocols. And it makes sense that this is protocol 23 to start with W. We also created a unique challenge for ourselves because that means the next protocol version
is going to be an everyday object that starts with x. So it's like the most challenging
letter in the alphabet is our next naming obstacle. So if you have an idea for an everyday
object, everyday tool that starts with an X, please let me know.
That's my final call to action.
Thanks so much, everyone, for listening.
Thanks, Garand and Molly and Dima
for sharing your insights.
And thanks for your hard work
just making this protocol release come to life.
It's really, really amazing.
