sablier v2: https://github.com/sablier-labs/v2-core/tree/main
paul on twitter: https://twitter.com/PaulRBerg
sablier on twitter: https://twitter.com/Sablier
pauls ethcc talk: https://www.youtube.com/watch?v=V6KBy8QQnCo&t=1053s

Welcome to the Bytecode, where we look at smart contracts with the people who wrote them.

I'm Irosh Shafoo and to get today's guest is Paul.

Today's episode is going to be about Sabler v2, which just launched 2 weeks ago, right?

So Paul, why don't you briefly introduce yourself, introduce Sabler and then just jump into the repository.

I'm a co-founder and CEO of Saviour Labs.

We're building a protocol, a money streaming protocol called Saviour.

We first launched Saviour v1 in 2019 and quite recently after a long development cycle of a few years, we announced Xavier V2 2 weeks ago.

It's a protocol entirely built with Foundry, and we're quite excited about that.

We basically, all of our backend is built with Foundry.

In terms of the features we have, we are the pioneers of what we call lockup streaming.

Lockup streaming means making a one-time deposit in a smart contract.

And then every second, a small portion of that deposit gets allocated towards the recipient.

And this creates a streaming effect where you can monitor your streams from real time.

You just have to make like a one-time withdrawal and then you can spend them as they come into your recipient wallet.

We also have quite a few bells and whistles in V2, which are pretty cool.

We have NFTs for recipients and they are visually represented as hourglasses.

If you see our logo here, we basically have an NFT SVG for every single stream in V2.

It's similar to Uniswap V3 positions, if you guys are familiar with that.

That's more like a marketing play with the design, but the NFT actually has real utility because it's a financial NFT.

Each NFT in State Barrier 2 is backed by the underlying stream tokens.

So for example, if you have a 10, 000 USD stream, the NFT represents ownership over those 10, 000 USDC.

And the other big feature worth mentioning in D2 is nonlinear streaming.

To my knowledge, we are the first protocol startup in the world, not just crypto, but in the entire world to build a nonlinear streaming model whereby the payment rate per second, whereas in V1 and in most of our competitors is the same over time, in the same year V2 you can do things like say that in the second year, the payment rate will slowly increase.

And in the third year, it can more rapidly increase.

And the use case is exponential investing plans, for example, where you give more tokens, more compensation to your employees or DAO contributors, the longer they stay with you.

And we are quite excited about that because we think it unlocks a new design space in Web3 where people can create new kind of nonlinear payment structures.

And yeah, those are the 2 main pillars of the v2 system.

Actually sablier means hourglass in French.

no awesome dude Thanks for the introduction.

Do you want to share your screen and we just jump into the code.

Let me start by showing you our V2 core repository.

This is the place where we store our core protocol logic.

As I've said, it's 100 percent built to foundry.

If you can see the languages here, it's only solidity and some shell scripts, which they don't count of course.

And we also have another repository called v2-periphery.

This design has been inspired by the units of v3-core and v3-periphery.

In our v2-periphery, we have certain functions which are not necessary for the core logic.

For example, we have functions for batch creating multiple streams, And they live in the periphery.

But on this podcast, we will go over the V2 core because this is where the magic happens with with the streaming and I think a good place to start would be the, what we call this lockup linear contract.

Let me switch gears to VS Code to get the syntax highlighting.

Yeah, Paul, can you maybe zoom in a little bit?

Actually, let me start with the brief overview of the contracts that we have.

We have the lockup linear, which is the simple linear streaming model, where seeing them visually would help.

So lockup linear is this basically, you can the same payment rate per second until the end of the stream.

You can also have clefs, but these 2 are basically the only models permitted by Lockup Linear.

We also have something called Lockup Dynamic, which is our specialty non-linear streaming contract, which enables the non-linear streaming designs I talked to before.

In the UI, we only allow a few custom streaming curves, but with time we will add more.

And at the contract level, you can actually create any mathematical function using the lock on that on the contract.

And we'll look forward to your feedback if you guys have a look at this and have an idea for a good, a non-linear streaming curve.

We're all yours to hear your feedback on that.

But Anyway, to come back to the overview, so we have these 2 lockup, linear and lockup dynamic.

Lockup comes from what I said before about the fact that you have to make a one-time deposit.

And the linear and dynamic is what I explained before.

It's a modern, fresh implementation in Solidity version

using very modern features of Solidity like string concat for contenting strings.

But yeah, this is basically like a constant.

It's just producing the dynamic SVG based on user data.

Finally, we have the controller, which is like our place where we store protocol fees and basically configuration for the entire protocol.

So let me start with the lockup linear contract.

Here the idea is that you have the same parameter per second, and there's no non-linearity basically.

Here's the streamed amount of function, which shows you the simple mathematical function that gives you a specific point in time.

For example, you have 3 years stream and after 1 year, a third of the deposit would be stream.

You can notice that all of our functions are commented with Nats by comments.

We care a lot about documentation, source code documentation.

We believe this is very important because of smart contract immutability.

And every single member in this contract is documented with comments, every parameter is explained, and so on and so forth.

We're using headers to separate constant functions from events, and most importantly, from non-constant functions.

And you can see here there are 2 ways to create streams and lock up linear.

You can create a stream by using the create with durations functions, which What it does, it sets the start time to block time step.

So whenever the transaction is included in a blockchain, the block time step will be used as the start time of the stream.

And the end time is sum of the block time step and params duration dot total, which is a parameter which I can show you in a bit.

Okay, so you can see here, these are the parameters that go with the function.

We had to use structs to avoid stack to deep.

But the idea is you provide these parameters, and the sender who creates a stream is a recipient who receives these streamed assets.

The ERC-20 asset contract and a cancelable, which says that the stream is canceled or not cancelable, a duration struct which gives you the duration of the stream which will be dynamically computed at the execution part, and finally the broker.

This is actually a feature for making integrations.

So if you're, for example, building a custom UI for Sabler, then you can specify a broker address and a fee, which is a fixed rate number, which means a percentage.

And you can monetize your app with Stable Ab2 by using this broker struct.

By the way, if you have any questions along the way, feel free to stop me.

And the other way to create streams is, you know, create with range.

The difference is that with range you have to specify a start time and an end time.

And that gives you determinism in terms of when the stream will start and when it will end.

And Yeah, it basically works exactly the same as primitive iterations.

At the end, when this function gets executed, a stream will start, and every second from there, a small amount will go to the recipient.

And you can see here the same math that comments with, we have this requirement section where we explain every single rule that has to be mapped for the function execution to pass.

And yeah, this is pretty much lockup linear.

So lockup linear inherits from the Sabre virtual lockup, which is the shared interface between lockup linear and lockup dynamic.

And here is where the cancel and the withdraw functions are shared.

Also, these functions for renounce means to make a stream non-cancellable after you made it cancellable initially.

This is an admin function for changing the anti-descriptor, the design, if we ever want to do that.

Otherwise, it's just like boring getters.

These parameters are all passed in the create functions I showed you before.

This is an important function because it gives you the current status of a stream.

It can be pending, which means that the stream was created, but it's not streaming yet.

It can be streaming, which obviously what it means.

Second, all assets have been streamed, but the recipient is due to withdraw them.

Some assets remain to be withdrawn by the recipient and finally depleted where the recipient has withdrawn all the assets from the stream.

And there's that, there's a stream the model function, which is also very important, it gives you how many tokens were streamed up until a specific point in time, when you call it.

This function of course uses log timestamp to calculate that And here we have the non-constant functions for avoiding the NFT after the stream has become depleted.

What I said before that a stream can be made non-cancellable after it was made cancellable at the start, an admin function for changing the descriptor of the NFT, a withdraw function for recipients to claim their streamed assets, a withdrawmax which withdraws the entire available amount at the time of the transaction.

And 2 more utility functions, variants of the withdraw function that this, this function gives you the ability to withdraw all the assets and then transfer the NFT to somebody else.

But yeah, this is pretty much it of the lockup linear.

It's a simple but powerful system for on-chain streaming.

Basically, if you're watching this and you're thinking about writing your own investing contract, don't.

There are many different ways, even like a simple payment contract can go wrong on Chain.

And we've thought about all those possible ways to advance, we secured this.

I will show you in a bit how our tests look like for all these functions.

But yeah, I also want to go over the LockupDynamic contract.

This is the sister contract that enables the magical non-linear streaming, and you have basic events.

But what you have different from lookup linear is this notion of segments.

Segments are, it's basically you split the function, the streaming function into multiple components, parts, which have, If I go back here and show you the segment, that'll be easier.

A segment has an amount, an exponent, and a milestone.

The amount is how much money is allocated for that particular segment.

The exponent gives you the, this is the secret sauce which makes the nulling and stringing possible.

It's basically a fixed point number which specifies the speed of the string.

In local linear, all exponents are implicitly 1.

Here, the exponent can be greater than 1 or lower than 1, and depending on what value you set, the payment rate will increase faster or it will increase slower.

And This is what gives the magical non-linearity of lockup dynamic as the segments which you can compose.

Then you have a milestone which says when the segment stops.

This is an aspect which explains the mathematical representation of the segments, how they are used to compute the current streamed amount of in all-com dynamic stream.

But I want to briefly show you the docs because that will greatly simplify this presentation for you guys.

So if you go to traditional lock, each segment on this graph here, this line, is an on-chain segment that specifies this is where it stops, and the exponent is some number which gives the growth of the tokens at that particular point in time.

You can use this to basically create any mathematical function as I've said.

You can use it to create strings, which they vast only at the very end.

So, you know, imagine it's only down and then goes up like this.

And yeah, it's all available for Rockhop Dynamic.

Let me briefly show you the create functions Sure,

yeah, you guys make sure when you create a dynamic stream that all segments line up to the amount?

Because if you have a start and an end, wouldn't you need to make sure that all the segments stream the exact amount that you put in?

Great question, and we do, we actually do.

Let me open the place where we do that computation.

If you look here, this function is check the input parameters provided by users.

So in lockup dynamic, we have creative deltas and creative milestones, which are the equivalent functions for the log-hop linear and creative durations and creative range.

You have basically multiple milestones of the segments.

Deltas is the same notion of multiple end times for each segment, but the start time is set to block time step.

In the input validation for those functions, if we go, I think it's here, check segments.

This is used by both creative duration, the Deltas and creative milestones.

The idea is that, yes, we're performing a sum.

Every segment amount is a sum here in a for loop and then at the end we check that the deposit amount that the user provided matches the segment amount sum because if it doesn't then the contract will remain with some leftover tokens.

Okay, just out of curiosity, how many segments can I have before I run into gas issues?

Again, we actually spent a few days researching this.

And it varies a lot based upon the chain that you're using.

A conservative figure that we set, we actually have a max segment count in the Sabre Virtual Lockup Dynamics Streaming.

So if you go here, we have this max segment count, which is initialized when the contract is constructed with the purpose of not allowing that state to occur.

We don't want to users to accidentally create streams, which, you know, then when they're calculated, after they're created, then they take more than the broadcast limit to be computed.

So we have this mutual here and we set it to 300.

And it's the same across all of our current chain deployments.

We said to start there just as a precaution.

You know, if we see interest in this feature and people say, oh, but I want 1000 segment, and we'll make another deployment and offer multiple segments.

But we think that for now, 300 segments should be enough for most use cases.

I mean, even like for 300, the gas cost will be insane.

Would it be helpful to go over the actual implementation of those functions that I showed you in the interfaces?

Let's first go over the simpler, or if we are in dynamic, let's remain in dynamic.

So we're using this inherit doc feature of Solidity to inherit an aspect, so we can keep it only in the interface and use it in multiple places.

Say you have creative milestones, The user here will specify the parameters and instruct.

And then we have the internal function, which creates stream.

You have the check and calculate fees function.

So what this does is that it calculates what is the current protocol fee.

The protocol fee is similar with the Uniswap global fee, if you guys are familiar with that.

It's a fee switch, which we can set to a non-zero value.

Currently, it is 0 and it will remain 0 for a long time.

Then we also have the broker fee, which is the creator of the stream.

For example, again, suppose you're building an integration receiver and you're creating streams, you can monetize your integration by passing this broker fee.

That is revenue that goes to the integrator and it's a win-win.

We get TVL, they get to make revenues by just using Xavier.

So that's what this function does, it calculates the fees and checks that the fees are not too high, they don't overflow.

Then we have the check create with monostone parameters.

1 of those are the, actually these are the most complicated checks in the check segments functions, but if you go here, create with monotones, just basic checks like don't provide 0 segments, don't be above the max segment count, which will allow, no 0 deposit amount, you can't stream 0 tokens.

Great, So once all checks have been made because we're using checks effect interactions, we proceed with creating the stream object in storage.

This is basically just parsing the user parameters and putting it into the struct which manages the stream.

And Yeah, just like pushing the segments in a storage array.

We actually do this because you can't just assign a memory array to a storage array and insulate it.

But yeah, Anyway, then what we do is calculate the protocol revenues.

If this is non-zero or currently 0, so this will always be 0.

We transfer the assets, the ERC20 tokens, and from the sender, master sender to the contract address.

If it is non-zero, then we also transfer that from, actually we transfer it directly to the broker account.

The idea is that we don't want to first make a big payment here and then another transfer, let's not do directly the same thing.

This is how stream creation works in Sable Ruby to look up dynamic.

As you can see, we have everything explained in English, every single step, we have an OCD about this.

Everything has to be tightly explained in natural language.

This also helps us with development and testing because we can see, okay, what is this part of the code doing or if there's a bug, what did we want that part of the code to do?

So it really helps a lot to explain our code the way we do.

Yeah, that's interesting, Paul, because I wanted to ask that question.

So for example, line 561, for example, it's like obvious, you know what I mean?

It's like, So I wanted to ask that question, do you guys really are trying to comment every single line of code?

Because in the helper, it's also, so if you switch back into helper, it checks the deposit amount of zeros.

yeah, you should know what that if does, if you're a developer.

Really this, so Some explanations are actually pretty damn useful.

For example, here I'm adding a link to a GitHub issue.

I'm explaining why unchecked arithmetic is safe, because adding 1 basically can never overflow in Ethereum until the end of time.

However, you're right, some comments are superfluous.

It's really more of a matter of visual aesthetics.

So, you know, if we remove this, then, you know, it will look, so what I mean, it's a small thing, Maybe we should just never mind these, but the comments are here, we'll keep them this way.

So what I like to do is if you remove that comment, line 90 and remove comment on 95, and then I make it a 1 liner, you know, I make 1992 a 1 liner That's what I almost always do I make it 1 line

oh this way oh, yeah, I'm not a big fan of this Because Maybe just my my brain is slow.

But what's what's what I so I I like to first parse and internalize the if block.

So again, this might be a silly example, but like, you know, ifs are important in smart contracts.

And I just want to really see it clearly and then, you know, separate it on a different line, what the actual if does.

Again, a very small thing in the grand scheme of things.

In vast majority of cases, it's really more like a habit than like the rational choice.

See all shafu transcripts on Youtube

The Bytecode #5 - Paul Razvan Berg - Sablier v2