Alphakey: https://twitter.com/alphaK3Y
Cover: https://github.com/poolshark-protocol/cover

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

I'm Rosh Shafoo and today's guest is Alpha Key.

Alpha Key, thanks for taking the time, man.

I've been catching up on some of the episodes you've been doing and fantastic content so far.

So yeah, Alpha Key wrote something he calls cover, which if I look at the GitHub description is a liquidity tool to protect against direction risks such as impermanent loss, which I found interesting.

So yeah, AlphaKey, why don't you very briefly introduce yourself and introduce cover.

And then yeah, AlphaKey is going to present like a high-level overview of Cover, which I think is useful first, and then we're going to jump into the code.

I've been doing software development for many years.

It got really addicted to trading back in like

It definitely became a very frequent topic at the office for me, just like opening up my brokerage account.

I was actually trading the cannabis legalization event for Canada.

I think it's really interesting, a lot of the parallels that exist between crypto and that industry.

You know, it's very much the growth of it is very much bound by regulation, you know, is to sort of move forward.

You need the regulation and the market gets stretched a lot in both directions.

So, you know, the the psychology of the markets can kind of turn people upside down sometimes to where it's, you know, when the market's doing really well your perspective gets shifted to, oh, you know, NFTs have all these use cases, everybody's gonna use NFTs or, you know, whatever the product or protocol is that seems like it's getting mass adoption.

And then when the market's down, you're like, is anybody actually going to use this stuff?

And that's sort of the arena that we find ourselves in now and things get very psychologically and also price action wise, stretch the downside and that psychology really messes with you.

And I've definitely had my own struggles with that myself.

And so coming back into this space in early 2021, you know, I'm thinking like, okay, how can I make this?

How can I actually walk away with more than that I put in?

And I was looking at Glassnode, I was looking at Glassnode Analytics and seeing what all of the whale wallets were doing and thinking, Oh yeah, this is a really great way to actually kind of determine where the market's headed, perhaps.

And then started really getting interested in automated trading on centralized exchanges, playing around with the platform that some people might be familiar with called 3 commas.

And you know, you can basically open up a bunch of small trades.

Each trade has both a, what is called a take profit.

So like you're gonna sell above the price that you entered and then also a stop loss where you're going to sell below the price that you entered if the trade doesn't work out how you expect.

So then coming on-chain, I'm kind of looking for that same thing.

I'm looking for like, how can I do this same sort of strategy that I was doing on decentralized exchanges, but kind of bring that on chain and started playing around with the old farms?

The first immediate problem to me is like, hey, well, if you're going to get more liquidity on AMMs, on decentralized exchanges, Like you have to have some clear and obvious solution for impermanent loss, which is obviously just kind of the short-term opportunity costs of basically having sold too early.

As the price of ETH moves up, you're selling out of your ETH position and therefore you'll have sold at an average price that was lower than whatever the market price is.

So basically thinking how do you hedge for this potential opportunity cost And then from there, that was like February 2021.

So then from there begins the whole like two-year journey of trying to figure out like, how do we improve slash scale this exchange experience that we had back then.

When Uniswap v3 came out, I thought, okay, this is interesting, but this didn't really solve the problems that I was wanting to solve.

And yeah, I think that really began the journey for me.

And, okay, so 1 solution trying to tackle this is cover, right?

So initially back in 2021, I very naively thought that, well, maybe you can just pull the liquidity before you start experiencing the impermanent loss.

But of course, that's not an option for, you know, if you're bootstrapping the liquidity for your own token, that's not really an option, right?

So you need to be able to have the continuous liquidity there, just kind of as it has been for the last couple of years now, people bootstrapping their own markets through AMMs, cover is really a way to kind of offset that opportunity cost.

So as you would normally sell ETH on the way up, this allows you to create a position that is going to buy ETH on the way up.

And of course, you have to protect against the possibility of flash loans, of any sort of manipulation.

But basically, it will just unlock liquidity, sort of like the TWAP price moves somewhere and then, okay, we're going to unlock that liquidity and then it's going to do these little Dutch auctions to actually find the natural market price because we can't just sell something at a flat price and assume that that's going to get filled.

I think the presentation would be really helpful to get like a high level overview before we jump into the code.

So, I'll just go through our slide deck a bit.

So this is the solution that we were discussing just now, which basically looks like a stop loss because when a certain price is hit you're going to

Sorry to interrupt you but I can only see a black screen is that what you're saying?

I thought maybe it's like a dramatic introduction or something.

Let me just share my entire screen and see if

So imagine that on the left, this could be your Univ-3 position, your curve position, etc.

And effectively, you're going to sell out into DAI.

So you're going to sell ETH into DAI as the price increases, right?

die per ETH, you will effectively have sold your ETH at about, let's say like, it's like

So the opportunity cost is of course between that 3, 800 and the

So, effectively, on the right side, this is what Cover does.

It will actually buy ETH on the way up, and it will purchase that ETH at an average price of

assuming you were using the same curve math.

Currently, the cover uses constant product, so classic x times y equals k, to do the curve calculations.

And it will buy that an average of 3, 800.

So basically, you can dynamically rebalance your position.

If you're using something like an option, then it's not directional, but here you're able to work with the naked asset.

So instead of having to resort to using an option or derivative, you can just hold the actual asset.

In this case, it'll be ETH or start world DAI, which is going to be used to buy ETH.

And you don't have to work with any extra derivative asset to dynamically rebalance.

And then the other solution we're working on, We're not going to get to it today because sort of 2 different code bases kind of have to pick 1 to deep dive on, right?

But we're also working on this limit pool protocol which will allow you to basically have a one-way position.

So it would trade the same way that your AMM positions would trade today, but it actually locks the position in.

So this is really important for asset pairs that you don't necessarily want to put up a two-sided position on.

So for example, something like an option token where you're very much worried about the price of the option token going to 0.

So therefore you could still have a marketplace where you can trade those assets, but nobody is having to take 2 sided risk.

And also you could do cool stuff like, hey, I wanna sell ETH from like

to 10, 000 DAI per ETH, right, and you can pay a fixed transaction cost for that.

So the TLDR here is instead of trying to do conditional swaps off-chain, we are able to express ourselves doing a one-way position on-chain, and therefore, we're not trying to do what we do today with limit orders and stops where it's like off chain and it's a single swap.

And we try to like shove a circle in a square a little bit because it's better to have the liquidity on chain before the price actually moves there, rather than reacting and then potentially having to deal with getting front run and all of those things.

So yeah, that's pretty much it as far as the deck goes.

We're definitely talking to liquidity management protocols because something like cover, if they're very confident that a position is going to go out of range, they can take a hedge position on that without having to resort to using something like an option or a derivative, which may be a little harder to explain to the users.

Any questions about any of this stuff before we dive into the code?

Yeah, there's quite a lot there, so let me try to start from the very inception of 1 of these pools and kind of walk you all the way through it.

So, there's a few choices that I'll probably change before we actually launch it, namely the fact that we're deploying bytecode each time, but really tried to obey a lot of the standards that people expect, like token 0, token 1.

Those tokens, for anybody that's not familiar with AMMs, those are usually sorted by address.

So, if you have 0xA and 0xB, 0xA will be token 0 and 0xB will be token 1.

Yeah, can you zoom in a little bit maybe?

Now I've got like red lines on the screen.

So either that comes from, you know, a liquid source like, for example, Uniswap V3 or Curve, and hopefully in the future our own pools will be able to use our own pools as a TWAP source.

And then we also, you'll notice here that there's this mention of volatility tiers, and essentially this tells us how fast the position can unlock at most.

And this is 1 of the mechanisms in the protocol to protect against really widespread manipulation of an asset, you can basically put a rate limit on how fast the price can move.

So you say, well, at most I expect it to move

And so that's why these tiers exist is to to have that that rate limit.

And so, yeah, nothing crazy here beyond launching the pool.

And as we set up this pool, we first just set the immutable arguments.

As far as I'm aware, in the newest version of Solidity, you actually don't have to set the immutable variables in the constructor.

You can set them outside of the constructor.

But for anybody that's not familiar with the immutable keyword, essentially, this will allow you to put a value in the bytecode And that makes it basically 0 cost, because you're reading directly from the bytecode to access that value.

If you are putting something in storage, it's going to cost you 20, 000 gas units to initialize it, and then 2, 100 to read that value.

So if you have a value that you don't expect to change quite good.

It's a constant that you set at deploy time.

Yes, and like I said, in the newest version of Slidi, you'll actually be able to set that outside of the constructor if, for example, maybe you have an initialize method.

So, the way that this is actually, the contracts are laid out, is that we're going to make a call.

This is done to actually split out the bytecode because in this protocol there's about 100 kilobytes of bytecode.

Comparison to something like Uniswap v3, that's somewhere in the ballpark of 30 kilobytes of bytecode so this is quite a bit more and thus the reason that we split these out.

You'll also notice that this is its own call as well.

Essentially what this does is every time the TWAP moves, we're going to sync up what's happening in the pool.

And there's always only 1 active auction at a given time, depending on where that TWAP price falls, right?

let's say 2000 di per eth, we will unlock a tick spacings worth of liquidity which might be something like 10 or 20 basis points or 0.1 or

So on each 1 of these methods, we pretty much sync up the pool, then we're going to do a call to do a mint, and then we're going to save the state.

So now we can go into the mint call and like I said the benefit of doing it this way is that you split out the bytecode and everything here is built specifically for Arbitrum so we're really trying to focus on reducing the amount of call data that's passed around.

So we just do 1 external call here and here.

So all these functions that you see inside of here, these are all internal calls.

So then we don't have to pay for that call data on L2.

You kind of have this trade-off between L1 and L2, where L1 ETH, the call data is going to be the cheapest thing and then the storage is going to be really expensive.

And then on L2 it's kind of the opposite where you know when there's a lot of activity on the L1, the call data on the L2 is going to be really expensive.

So you really want to pay attention to how you're packing your call data.

And so thus the reason to use something like a struct.

Well you want to use a struct so that it will compress all the call data down and then yeah that decreases the gas cost for the user.

So, here what we do is we only allow the user to place a position on 1 side of the TWAP.

And the TWAP here you're going to see that it's referred to as latest tick.

So, if we go into this positions library, You'll see first we check are these valid ticks, then we initialize this cache.

We check if they're minting an empty position, and then we enforce what's called this safety window.

Maybe we'll get to this later, but essentially this is done so that to reduce the impact of anybody being able to see the current state of the pool and also perhaps know where the price is going to go.

Because as we know, AMMs often lag behind centralized exchanges.

So this effectively stops someone from seeing that, hey, you've accumulated all this filled amount, I'm just going to stick my position in.

And even if, you know, the next auction doesn't get filled, I'll still get part of the previous fill.

But there's also this cool effect in this pool of like if if there is a lot if if the auctions are getting filled frequently it reduces the risk of somebody who's creating a new position that they won't get filled.

They'll still, everything will be split pro rata, just like it is in any AMM.

And the reason that we do that is so that we never have any arrays that we have to loop through.

So here we essentially, based off of whatever their initial range is, we're gonna calculate the liquidity that they would mint.

Okay, wouldn't you want to do line 73 at the start of the function to fail quicker?

I think it's like the fastest thing that could fail.

So yes, this could definitely be moved up above the cache so that it fails sooner.

And then someone who...is it likely that the user is going to send a mount 0?

Like They pretty much grief themselves if they are trying to create a position with a mountain 0.

But yes, for sure, it's good to follow the principle of failing somebody as soon as possible so that they don't burn extra gas.

And that makes the experience better for all the other users on that chain.

I find the require statements interesting.

Yes, so I initially I was using custom errors And the problem that I ran into was that I couldn't actually see the revert message on EtherScan.

And this is something that's been known for a while that it's an issue.

Now, If you call a contract directly, I believe it will give you the custom revert string.

So you could do revert and then whatever your custom error is.

However, If you call a contract which calls another contract, then it will not bubble up the custom error.

This is ultimately the issue that I ran into, And require does use more bytecode than custom errors.

So the way that I get around that is I do the if check to like if we should revert.

And if that string is true, then I just force the revert by require false.

And then I pass the string as the revert string as well and this makes it so that I can actually see that someone can see the error on EtherScan.

Yeah it's a bit of an unfortunate thing, Etherscan.

There's there has been people prodding at Etherscan to go and fix this issue.

But they they haven't quite gotten around to it yet, unfortunately.

But, you know, custom errors have been around for a really long time.

And I also, I was having some back and forth with Paul Rosvanberg, who's the developer for Sablier.

And I was like, yeah, I think I'm just gonna do this because at least it works for now.

I think probably your AirPods ran out of memory or something.

Okay, So while we're waiting for Alpha Key to get his mic back, So I personally like to use custom errors.

I just think it's, it looks better when you look at the code and it's more expressive.

The syntax used by AlphaKey is like, I get it because of the tooling, but I don't think it's the nicest thing to look at, but definitely interesting to see.

I'm probably gonna timestamp when AlphaKey's when Alpha Key's mic is gonna come back, because I have no clue how to edit videos.

okay okay so we're gonna stop this recording, create a new 1 and continue from there.

I'm Hirosh Shafu and today's guest is Alpha Key.

So yeah, Alpha Key wrote something he calls Cover, which if I look at the GitHub description, is a liquidity pool to protect against directional risks such as impermanent loss, which I found interesting.

So yeah, AlphaKey, why don't you very briefly introduce yourself and introduce Cover.

And then, yeah, Alfaki is going to present a high-level overview of Cover, which I think is useful first, and then we're going to jump into the code.

Definitely became a very frequent topic at the office for me just like opening up my brokerage account.

But sort of post doing a couple trading, so I was actually I was trading the cannabis legalization event for Canada, And I think it's really interesting a lot of the parallels that exist between crypto and that industry, you know, it's very much the growth of it is very much bound by regulation, you know, is to sort of move forward, you need need the regulation.

And the market gets stretched a lot in both directions.

So you know, the the psychology of the markets can kind of turn people upside down sometimes to where it's, you know, when the market's doing really well your perspective gets shifted to, oh, You know, NFTs have all these use cases, everybody's going to use NFTs or, you know, whatever the product or protocol is that, you know, seems like it's getting mass adoption.

And that's sort of the arena that we find ourselves in now.

And things get very psychologically and also price action-wise stretch the downside and that psychology really messes with you.

And I was, you know, looking at Glassnode, I was looking at Glassnode Analytics and seeing what all of the whale wallets were doing and thinking, oh, yeah, this is a really great way to actually kind of determine where the market's headed, perhaps, and then started really getting interested in automated trading on centralized exchanges, playing around with the platform that some people might be familiar with called 3 commas.

And, you know, you can basically open up a bunch of small trades.

Each trade has both a what is called a take profit.

So like you're going to sell above the price that you entered and then also a stop loss where you're going to sell below the price that you entered if the trade doesn't work out how you expect.

So then coming on chain, I'm kind of looking for that same thing.

The first immediate problem to me is like, hey, well, if you're going to get more liquidity on AMMs, on decentralized exchanges, like you have to have some clear and obvious solution for impermanent loss, which is obviously just kind of the short-term opportunity costs of basically having sold too early.

So basically thinking, how do you hedge for this potential opportunity cost?

And then from there, that was like February, 2021.

You know, when Uniswap v3 came out, I thought, okay, this is interesting, but this didn't really solve the problems that I was wanting to solve.

And okay, so 1 solution Trying to tackle this is cover, right?

See all shafu transcripts on Youtube

The Bytecode #7 - Alphakey - Cover