Projects
![]()
No projects found
Investors
New
DAO Treasuries
DATs
Lend / Borrow APRs
Chains
Categories
Spaces
Astroport Community Call with Warp
Recorded: June 30, 2023 Duration: 1:06:00Space Recording
Full Transcription
Hello, hello.
Can I get a quick mic check?
Yeah, mic check.
How's it going?
Can you hear me?
Yeah, I can hear you loud and clear.
Awesome.
I'm good.
I also asked, are you getting any like background audio right now?
I just want to make sure that...
I think the tiniest bit, but not too much.
Okay.
Okay.
All right.
Let's see.
I want to make sure we get everyone up on stage.
Looks like we got Danny in the crowd here.
Here you are.
Here now, let's hear you.
Here now, let's have a chair.
Okay, looks like we've got everyone up on stage.
Yeah, I'm just making sure here.
Got Warp.
Yeah, you guys tracking anyone else coming up?
Yeah, we got Georgie coming up, and I think Danny as well should be.
Oh, you're right.
Yeah, I don't believe I have permissions right now to invite them up.
I know, Sandra, you can help with that.
Welcome, Georgie.
Welcome, guys.
Just getting some spaces logistics sorted here.
I'm not sure if Danny is still in the crowd.
Do you all see him?
Yeah, I see him.
Yeah, he's there.
Are you on mobile?
Are you on mobile?
Are you on mobile?
Because you have to be on mobile to speak.
So I know the over to Ash report on the account, they sent him another invite.
I'm not sure.
But I think it sounds like we're going to go ahead and get started here.
Unless there's any, any arguments there from the rest of the team.
No, let's go ahead.
Okay, great.
Yeah.
Hello, everyone.
DebsDefi here.
Happy to be your host on this Ash report space today, Ash report warp space today.
I may have a little bit of background audio.
So if at any time it gets overwhelming, just let me know.
And I will put myself in another location to make sure everyone can hear loud and clear.
But I think a good place to start would be just introductions.
Maybe let's just go around the horn and introduce yourself.
You know, maybe just talk about the team you're a part of.
Sure.
Yeah.
Let's, let's start with Astro since they're the hosts.
Go ahead.
All right.
Um, hi everyone.
I'm Stefan.
I think you know me from previous spaces.
Uh, I'm a contributor at Delphi Labs.
Um, specifically I'm contributing to Ash report governance, trying to make things happen,
trying to, uh, I ping builders to help, um, kind of create proposals so that we can then
vote on them.
Um, and then just coming up with different ideas to improve Ash report and hopefully launch
their own other cosmos chains.
Cool.
Awesome.
Um, we'll just, we'll just let Danny introduce himself when he's able to join.
Um, but I'll go ahead and introduce myself.
I'm Vlad.
I'm Vlad.
I'm the apps team lead at TFL.
Um, and here at TFL, um, we're core contributors to an app that, um, that we created called warp.
Um, and warp.
Um, and warp for those of you that are unfamiliar, perhaps maybe just coming from the Ash report
side of things.
Um, warp is kind of like, uh, a programming language that enables automations online.
Um, we'll just, we'll just, we'll just, we'll just let Danny introduce himself when he's
able to join.
Um, but I'll go ahead and introduce myself.
Um, but I'll go ahead and introduce myself.
Um, and here at TFL, um, we're core contributors to an app that, um, that we created called warp.
Um, and warp for those of you that are unfamiliar, perhaps maybe just coming from the Ash report
side of things.
Um, warp is kind of like, uh, a programming language that enables automations on chain.
So it's like an automation engine, um, that contains a permissionless and decentralized
network of keepers and job creators, um, that allow you to schedule jobs for the future
based on, um, you know, whatever conditions you set.
Um, and in particular for Ash report, um, that would be limit orders.
So once your condition for price is set, that limit order gets executed.
Um, and you're able to essentially pre-sign what you want to do.
Um, and I also work on contracts for warp.
Great.
And I, oh, oh, sorry.
Looks like we got one more.
The newest member of the community call.
Uh, hi guys.
My name is Georgie.
Um, and I'm one of the core devs at TFL.
Um, I currently work on warp protocol and actually warp is something that Vlad and I engineered,
like back in the day when we were working on fountain.
And warp basically was like the next evolution of that protocol.
If, if people remember it, um, I work on many different things.
Like I am, uh, literally a full stack developer.
So I work on like smart contracts, web apps, SDKs, indexers, what have you.
Um, I also worked on anchor.
If people remember that protocol, the famous one.
Um, so yeah, nice, nice to see all of you here.
Yep.
Great.
Uh, great to have you.
And thank you for the introductions.
Uh, and so I think, you know, Vlad, you, you touched on it there.
I think it's a good place to start.
Um, and if you don't mind, maybe we just go back a little bit and just rehash that like
a very basic summary of warp, right?
I know you talked about, um, you know, the jobs and the keepers, uh, but if you were
to really like break it down very simply for our audience, what, what would you say is
the, the purpose of warp?
What can you do with warp?
All right.
So I'll go ahead and speak about the problem that we encountered, um, as, as kind of a
preface to why we created warp.
Um, so we realized that, you know, a lot of protocols and a lot of users have needs to
execute proposals in the future.
Um, like for example, recurring executions that you see on like a liquid staking derivatives
that happens every 24 hours, um, or for limit orders, right?
Like you have to wait for a price to hit.
Um, or for fountain, the idea was, you know, every X amount of time, um, you'd have a payment
that would be like streamed over.
Um, and so we realized that, um, to do this, um, to do these executions, um, you only have
really two options of how you can do that.
You can either sit there, um, personally at your computer and wait for these conditions
to, to become true.
So if you want to do a limit order, uh, per se, you just have to sit there and wait for
the price to happen and then, and then do an Insta swap, um, at, at market price when
the price hits, um, or your other alternative would be to run a bot.
Um, and these bots would have to be programmed by, by you, by the user.
Um, and they would have to run.
So the way bots work is they run basically 24 seven, they check the conditions they check,
you know, um, for the case of limit orders.
They check the price every, you know, X amount of seconds.
And then when it hits, it executes.
Um, so obviously the problem with, with option number one is that nobody really sits at their
computer for 24 hours a day.
Um, just waiting for things to happen.
Um, so that's off the table.
Um, and then for bots, um, number one, it's kind of inaccessible to the general user.
Um, like not everybody has the ability, um, or the willpower to go ahead and create a bot.
Um, and, um, number two, it could be quite expensive and tricky to maintain the infrastructure for that.
So typically, um, you'd either run it on your own servers or, um, you'd go ahead on like, you know, some, some cloud service and you'd run your bot there.
So, um, either way, um, you as the user or the protocol, if it has automations, it would have to run a bot.
And so we decided that, you know, there has to be a better way.
Um, and initially we had a use case for fountain and fountain was purely time-based.
So it was like, okay, every, you know, hour we want to send, um, you know, this amount of Luna to a user.
Um, and then that way we would stream payments.
And so warp became like, um, this, this product that, you know, based on time, it would send like recurring transactions where you sign it the first time.
And then, and then from then it moves on.
Um, and then we decided, you know what, there's, there's so many other conditions that aren't time-based that might still happen in the future.
Why don't we make warp possible, um, to execute basically any condition or any set of conditions, um, that you can think of.
Um, and so we began designing a protocol that, you know, no matter what happens on chain, um, you can pre pre-define that.
Um, and then you basically create a job with that condition.
And then once that condition hits, it automatically gets executed for you.
So you no longer need a bot, um, because you have this keeper network monitoring it for you.
Um, and you also don't need to sit there at your computer.
Yeah, no, and that's, um, that's very interesting.
So if a good summary, I just want to make sure Rini you correct, right.
It would be something on the lines of a decentralized network of people that can post jobs with conditions.
Right.
Right.
Um, particularly time-based, uh, and then, you know, a decentralized network of people, um, protocols, bots that can execute them.
Correct.
Um, yeah.
Yeah.
So not just time-based, the, the, the really cool thing about work is that you can set your condition to be literally anything that happens on chain.
So it could be a time-based, you know, mixed with, um, a price, for example, like you could do DCAs, um, DCAs mixed with price.
So like the time has to be a week from now and the price has to be, you know, less than this for me to buy.
Um, and so it's basically so generalizable that you can have any set of conditions be executed for you when it happens.
Yeah.
And I, and I think that's great.
And, um, I think you definitely touch on really kind of the user experience side.
Um, and, and why as a user, uh, that, you know, warp is optimal.
Um, and because we're on the call with Astroboard and I know, I know the topic is limit orders.
I'd be curious to pick your brain a little bit about, um, you know, the other side of it, which is protocols.
If you can expand on that a little bit.
Um, yeah, sure.
So, um, for, for, yeah, there's obviously the side for the users, right.
Um, and then for protocols, it's pretty useful because protocols don't have to run their bots either.
Um, so one pain point with protocols, right.
Especially protocols that want to be fully decentralized.
Um, is a lot of times they have to rely on, you know, running bots.
And then when you run bots, your entire protocol is dependent on these bots to stay up.
Right.
And then if something happens, um, you know, you're, you're responsible for, for, for going ahead and fixing those bots.
And there becomes a single point of failure.
Um, and the interesting thing with warp is that once you create a job, right.
That's like pre-signing a transaction for the future.
Um, anybody, um, is able to execute that job for you.
Um, so what we mean by, by a network of keepers is that literally anybody could be a keeper.
It's fully permissionless.
Um, and the only requirement for executing a job is that those conditions are correct.
So if you see, you know, the, the, the price is corresponding to someone's condition, you or I, or any other keeper, which is typically going to be, you know, a bot.
If someone wants to get those quicker, they would run it.
So instead of having a single point of failure, which could be your server or, or your bot that you wrote a protocol is now, you know, um, relying on an entire network of, of actors that want to execute it.
Yeah, it, it, it totally makes sense.
Um, obvious use case there for, for both users and protocols.
Um, and maybe we want to kick this over to the Astroport team, um, for a second here.
Uh, I know that limit orders aren't necessarily a new thing on Astroport.
Um, however, warp is, you can expand a little bit on why you chose warp.
For sure.
Um, so the main reason we picked warp, uh, is that besides limit orders, um, kind of coming back to what Vlad said,
we can do way more than that.
One example that I would personally love to see on app.astroport.fi, um, is related to liquidity providers.
So for example, you could, um, set up a job on warp, um, to LP your assets in a specific pool.
Once the, uh, pool price, uh, hits a certain like limit, for example, in the Luna USDC pool, Luna needs to be like, let's say $1.
Um, and at that point you're willing to LP like 10 Luna and, uh, yeah, like another 10 USDC, for example.
Um, or, uh, on the other hand, you can also like program, um, like warp, a job on warp to withdraw your liquidity at a specific point.
So for example, you don't want to incur, um, too much IO.
You might want to withdraw from a specific pool, like tokens, ABC and USDC when token ABC, like crashes by let's say 50%.
Um, so you can like set up a job on warp to do that for you.
And you don't need to kind of monitor, uh, that pool at all times to kind of do that.
Um, so the idea with warp is that initially it made it easy for, uh, as support builders to add a limit orders on, on, um, the as support app.
Um, but later down the line, it makes it even easier to add other features that the community might want.
So, yeah, no, it sounds like a pretty key piece of this is, is, is not only the functionality right now with limit orders, but the flexibility, um, to build different things, uh, you know, both through protocols and decentralized through other people.
Um, that's very interesting.
I am curious, uh, you know, while we, while we're on the topic, uh, are, are there any other, um, applications, even, even if they're not necessarily on the roadmap now, but just exciting things that you think could be done with warp?
Yeah.
So, um, along, along what, what Stefan was just saying, um, you know, warp, warp is so exciting because you can literally do anything with it.
And as he was, you know, saying this idea, um, I literally just came up with another one where it's like, how cool would it be if you have like a, a, a set of LPs, right?
A set of liquidity pools that have, you know, a certain APY to them.
You could basically use warp to migrate your liquidity to the highest APR.
So you can set your condition to be, you know, I, I, I like these three LPs, right?
Like, uh, Luna USDC, uh, Luna Astro, um, and then Astro USDC.
Um, except you want to delegate to the one with the highest APY.
You can set up a warp job that continuously monitors these three pools and then basically does that for you.
So automatically delegates and, and, and stakes LPs.
Um, so that's just something I came up with right now.
And I think that's like the super exciting thing about warp is that you can literally do anything as long as the data on chain is available for it.
Um, but going back to your question, um, some things that we did think about, um, there's a couple.
So right now, um, I know Aris was using the beta and they're going to be migrating over to, um, over to main net Astro port.
They do, um, restaking.
So, um, for their protocol for, um, liquid staking derivatives, the way it works is I think it's every 24 hours.
There is, um, like withdrawal of staking rewards, and then it automatically gets, um, redeposited.
So auto compounded, um, you could build auto compounders.
Um, and then in particular also for enterprise, there's two use cases.
So one would be automatic proposal executions.
So, um, when a user typically right now, when you submit a proposal and the voting finishes, someone has to go ahead and execute that proposal.
So, uh, the message actually gets sent off from the DAO.
You could automate that using work where once the timeline ends, the voting is over.
It automatically gets executed.
Um, and then again, in, in, in enterprise, we see another use case where, um, we're seeing protocols and, and DAOs, um, you know, auto, auto distribute rewards.
Um, you could set that up through work.
So like every 24 hours or every week, you automatically distribute the rewards to, to all the users in your DAO.
Um, I always like to pause, make sure no one else wanted to chime in there, but no, that's really interesting.
And, um, you know, Vlad, when you were talking, when you were talking about this, the idea that you just came up with, right.
It almost reminded me a little bit of game of Alliance, right.
Where people would bounce around and try to find the best APY.
Um, but with warp in this scenario, uh, it, that's kind of interesting, you know, kind of just bouncing around to different pools to, to make sure you earn the highest rewards.
Yeah, exactly.
Yeah.
So it's like, you know, people usually ask, you know, what does warp do?
Right.
Like that's, that's the first question.
Um, and, and the answer is like basically whatever you want it to do.
Like you can think of it almost like a programming language where it's so generalizable and so composable that you can attach any protocol or any combination of protocols and whatever, whatever you're able to imagine.
Um, if that data is all found on chain, you could basically execute it using warp.
I actually have two questions here.
Um, so the first one is, is it, I guess it's possible, um, to provide liquidity one sided in a stable swap pool using warp, right?
Like, let's say, um, let's take the example of ST Luna Luna.
And let's say someone tries to manipulate that stable swap and make it super imbalanced, like manipulate the ST Luna price in order to wreck LPs.
Um, is it possible for someone to provide like only ST Luna or only Luna, uh, through warp, through a warp job in that pool when the pool price hits a specific target?
That's, I guess my first question.
Yeah. So in, in that case, your condition would be, um, probably the balance of the pool.
Right. Um, and then in that case, your, your message.
So a job typically, uh, it contains two main components.
It has the condition and it has, uh, the list of messages.
So in your condition, it would be like, okay, the pool balance has to be, uh, this amount.
And then my message is I want a single stake ST Luna, um, when the pool is, is out of balance by this much.
And so since both of those things are on chain, obviously you can check the pool balance using, um, um, using the query through Astroport.
Um, and then you just send off the message, uh, using Astroport as well.
All right. Um, the second question is related to IBC.
Do you see a future where you deploy work on multiple cosmos chains?
And for example, I send a message from Terra to whatever neutron injective saying, Hey, um, I want to swap like these tokens cross chain using two different Astroport deployments.
And I want to swap like Luna from Terra to, I don't know, some token ABC on neutron.
Is that possible?
Right. So, um, it's technically possible.
I think the, the, the question now lies in like the way you implement that.
So if you wanted to do it right now, um, there's a way like using, um, interchain accounts and then using interchain queries as well.
Um, where you could, uh, send it over already, um, using warp, using, um, using interchain accounts.
So you send over your assets to your interchain accounts.
Once they get there, you do something, um, after you query that would probably require a little bit of work due to how, you know, IBC, ICA works.
Um, so it would be like a question of like optimizing how you would do that.
But as of now, um, warp is available, um, with it is compatible actually with IBC.
So IBC messages are, um, are available.
So if you want to do like kind of a, a send and forget type of thing, um, you could already use warp to do that.
Um, but if you want to do some more complex actions, uh, that would require a bit more brainstorming, um, and then setting up like kind of outposts and contracts on the, on, on different chains.
Um, but what we are looking to do is complete warp deployments on, on different chains.
So what you could do here, um, for this case in particular is imagine we have warp set up on, on Terra and then warp set up on, um, on Neutron, for example.
Right. And you want to send over some assets from Terra to Neutron and then swap them on Astrofort, um, which, which would be found on Neutron.
Um, once we have the entirety of the warp deployment set up, um, on Neutron, what you're able to do is create like a second warp account for that user on Neutron.
Um, have those assets sent from account on Terra onto the account on, on Neutron.
And then you could set up a warp job, kind of like preset a warp job on Neutron that would detect when these assets arrive.
And once they do, it would complete the strategy from the Neutron side of things.
Gotcha. I see.
And, um, I guess, sorry, bonus question.
Um, do you think it's possible, like if warp is really like a programming language, I would expect it to work across, not just cross chain, but cross ecosystems.
Um, and in this, in this, um, case, I'm imagining like a potential integration between Cosmos and Ethereum, where you send the message from, um, Cosmos and it gets bridged over to Ethereum and something happens on the other side.
Um, do you see like a, this like scenario happening for warp?
Um, I, I see it being possible.
Um, but in that case, I think we would need to write up the contracts using solidity, um, do the same thing on Ethereum.
Um, so it would require a bit more work.
But again, I believe that if you really wanted to play around with it right now, you could probably use, um, Axelar's generic, uh, message passing to get to Ethereum and then also do something with that.
So right now, I, I, I think you could do like kind of a fire and forget, uh, kind of, kind of like what you do right now when we only have warp deployed on Terra.
Um, I think you could do that using GMP.
Um, I'd have to make sure, but eventually, um, if we're capable of, of, you know, writing the warp contracts in solidity and deploying it on Ethereum, then you would use a combination of Axelar's GMP to get it over there.
And then once those assets are over there, the Ethereum version of the warp deployment would, um, would act the same way as it would on, on, on a Cosmos chain.
Um, yeah, yeah.
I hope that answers your question.
Very cool.
I, I, I think I read a quote on Twitter just a couple of days ago where someone said, every chain is a Cosmos chain.
Some just aren't connected to IBC yet.
Um, implying that, you know, in the future ETH, ETH will also be a Cosmos chain, uh, connected, um, connected through IBC.
Um, yeah, it's interesting, uh, bold statement, but we like that.
We like that on spaces.
Um, I mean, I, I, there are, I know there are several projects right now kind of working on bringing, um, IBC cross.
I want to say composable was one of them and there's a few others as well.
So maybe you'll be, maybe you'll be right, Vlad.
Uh, as long as we're, we've kind of settled on this topic, I want to make sure I'm not, um, taking anything away from it.
I am kind of curious from just like basic.
So some of the, maybe the more basic reasons why, um, a protocol would, uh, use warp.
Uh, and, and tell me if I'm, you know, off base here, but I, my assumption is that it also can reduce costs.
Right. Is that one of the things that I can do?
Um, so for, for protocols, absolutely, because protocols are now not required to run their own bots.
Right.
And so instead of, you know, the, the protocol paying for all the automation, all of their own keepers, um, instead the user would pay the, the warp reward, which is basically what the, what the keeper gets for executing that.
And then, um, and then instead of the protocol, you know, fronting all the costs, it would be distributed, um, in smaller portions among the users.
I can let, um, I can let Ash report speak a little bit about that as well, because I think that's relevant.
So the only thing I have in mind right now is, um, actually another question.
I'm wondering if it's possible to build some kind of abstraction so that, um, a DAO or whatever, some kind of mechanism pays on behalf of users for everything that they do on warp.
Because adding a, a, even a fixed cost on top of what they already pay to interact with a specific chain is not ideal.
Right.
So right now, um, we don't have plans of changing the theme mechanism, but we could definitely take some, some suggestions for the community.
Um, if they have any ideas on, you know, how, um, on, on like more efficient theme mechanisms as well.
All right. Yeah. Because, uh, right now people who, um, use limit orders on ask reports, like, as you said already, uh, they need to pay by themselves for the execution of each job on warp.
Um, so ideally we find a workaround around that, like a workaround for that.
Um, yeah, I'm, I'm definitely open to discussing that.
And, um, you know, if any ideas fly our way, we definitely take a look and, um, and, and, and, and, and see what we could do for that.
I think a question that, um, conceptually has been bugging me and maybe other audience members maybe don't have a full grasp of it as well as, so the keeper bots are obviously essential in making sure that this protocol works and runs as intended.
Um, so is there a big market for keeper bots right now?
Um, do you see this being very profitable for users, uh, that set these up or protocols that set these up?
I'm just curious your thoughts on that.
So I think as long as work jobs are profitable for the keeper, there will be keepers in the market.
So, um, currently, um, I'm running a keeper and I'm finding that, you know, for some jobs I'm actually getting beat out.
Um, and I have no idea who these other keepers are, right?
Like I'm not coordinating, um, with them.
It could literally be anybody.
Um, and I think as long as, you know, something will be profitable, there will be bots that come in and do that.
And for a job to be profitable, the reward has to be, um, slightly greater than the, uh, than the gas it takes to run that execution.
And so the reason I think that there will be bots, um, if they're like, like keeper bots, if, if, if there will be profit is because, um, in the past.
And even now, um, if, if you snoop the chain a little bit, you'll see that there's a lot of arbitrage happening.
Um, and a lot of the times the profit that is made by these arbitrage bots is, is very minimal.
Like sometimes you see a few cents at a time, yet people are still doing it because over time that compounds, and then you see people making profits.
And so I think over time, we're going to see kind of like the, the open market, uh, take hold and determine the most efficient, uh, prices for both, um, for both jobs and then, and then methods for execution.
So, um, to, to wrap back around, I think, yeah, if there is profit there, there's the incentive for, for people to run, run their own keeper bots.
And like, what's also interesting about warp keepers is that they are like very lightweight programs.
So essentially, uh, you can run it on a phone if you want, or like whatever device you have, maybe on a fridge.
Yeah.
So actually during beta testing, I had, I had my keeper bot running on my Raspberry Pi, which for those of you that don't know, has very limited processing power.
Um, like four gigabytes of RAM.
Um, so yeah, super lightweight.
You can basically run it on anything.
That's awesome.
Yeah, no.
And, and I, I find that fascinating, right?
That we're going to, um, it's almost like there's going to be, like you said, price realization, almost the way you would see with tokens, right?
Where you, you kind of have to let the market decide what the price is going to be.
It's going to be interesting to see, you know, how jobs are priced in, obviously in accordance a little bit with the gas, like you're saying, making sure they're profitable.
Yeah, yeah, exactly.
So like over time, um, just based on my predictions, I would predict that, um, eventually job creators are going to, are going to price their jobs very close to what gas is.
And then you're going to have to kind of have the market decide like how much profit is enough profit for a keeper to run.
I think that's going to take a bit of time, a bit of experimentation.
Um, and you know, if, if a job doesn't get run, um, it either means that, you know, the job isn't profitable or isn't profitable enough.
And then it's up to the job creator to kind of add reward and, um, and figure out, you know, what, at what point will my job actually be run?
I just want to, um, yeah, and, and that, and that totally makes sense.
Um, I just think that the whole dynamic of it is going to be very interesting to see.
Um, I, I do want to remind the audience though, right now, um, at any point, uh, you know, this is a community space, right?
So go ahead and raise your hand.
If you have a question, um, I will see you.
And then eventually in about five minutes or so, we'll kind of open it up to, to start bringing people up here to ask your, uh, your questions.
So please don't be shy.
Uh, you know, friendly space.
We're happy to have you up and answer your questions.
Uh, I, I did actually want to, and I feel like we're going to talk a little bit.
And I feel like we're giving you a lot of speaking time right now, glad.
So we're going to have to kick it over to Astroport soon.
But, um, I saw a tweet that you, uh, from a couple of days ago and you were talking about abstraction on Astroport and how, you know, this was a perfect example of it with limit orders.
And I was curious with the vision of warp, do you see, um, abstraction kind of like primarily being, uh, the end state or the goal, or do you think there's going to be a mix of some jobs?
Abstracted and then others just directly from the job board.
Uh, does that question make sense?
Yeah.
Yeah.
So I think, I think there might be people that create jobs using the job board and kind of manage it from there.
But the goal eventually is to make warp so invisible that people don't even know they're using it.
Um, so unless you look at the transactions and you know, it's going from warp, you don't really know that it's actually going through warp, right?
Like you don't want your users knowing that like, oh, I'm using AWS or Google Cloud or Azure, right?
Like nobody actually cares about that.
Um, so what users care about is that, um, you know, these protocols are now enabling them, um, to, to have new experiences that they couldn't have before.
And it just works.
And so the goal for that is going to be complete abstraction.
And I think Astroport did a fantastic job with that.
Um, so if, if you guys, if you guys actually submit a limit order on Astro, you'll see that, um, they integrated their own like limit order board.
Um, you could see the price and, and the rate at which you're planning to buy.
You can see, um, the time at which you submitted it and you can see the status for it as well.
Um, and they, they did that using labels.
Uh, so you're able to label each job with whatever labels you want.
And then they brought that in to their own UI so that you can control your job.
Um, meaning you can cancel or modify it, um, right from their dashboard.
So you don't even have to go on warp at all.
Um, and you're able to use full warp functionality.
We, uh, just actually pinned it to the top in case you haven't had a chance to read.
Uh, and maybe I'll just kick it quickly over to the Astroport team.
So, um, just how, how do you think that, you know, warps deployment, um, is going to have an effect on Astroport.
Keeping it pretty open ended.
Uh, but maybe you can start with limit orders.
And then some of the other functionality that you're excited about.
Like, how do you think it's going to positively impact Astroport?
Yeah, I kind of alluded to this, uh, through my previous questions.
Um, one potentially impactful area is just cross chain communication, right?
Like allowing people to easily swap between Astroport deployments.
Um, that would be really cool.
Or for example, if someone just wants to temporarily bridge some tokens from let's say injective to Terra.
And then at some point bring them back, uh, they don't want to handle like all the, like confusing, um, IBC denoms, uh, that you see when you like, I, when you bridge the token from another chain to like Terra, for example.
Um, you don't want to handle all of that.
So you might just want to schedule a work job, um, that kind of bridges a token on your behalf.
And then, um, uh, LPs that token on the Terra side.
And even like at some point you might want to schedule a job from injective.
So not from Terra.
Cause for example, you only have INJ kind of pay for gas.
So you want to schedule something from injective and send that message to Terra so that in, let's say a week from now, these tokens come back to your wallet.
Um, and through like that job being executed on Terra.
Um, so kind of all this like cross chain communication part, uh, if work can kind of simplify that, it will make everyone's lives a bit easier.
Especially when, when it comes to, uh, for example, a DJ and that wants to jump from chain to chain to do different like things, LP, uh, provide liquidity, lend and so on.
Yeah.
And the one other thing I'd like to add here is that also like the work, the warp web app, like kudos to the guys for what they build.
Cause the other thing is like, you don't really need to be a dev to create like these jobs.
Um, it's really easy and that's gonna allow for like a lot of experimentation with like all these ideas that we've discussed.
Like you can create jobs and templates and they've done it in a really, really nice fashion.
Uh, thanks a lot, sir.
Um, I got a question for the Astro team.
Um, so you guys are working on the shared liquidity AMM model.
Is that correct?
Uh, or not actually it's still in the idea stage, but go on.
Um, do you see warp being like the, the groundwork, um, mechanism for like being the shared liquidity manager for Astro?
Yes.
That would actually help the R and D phase a lot because, uh, right now you correctly like identify the pain point with that model with shared liquidity AMMs.
The cross chain communication part is the trickiest one.
Um, uh, and in, in, uh, inside cosmos, it's especially tricky because IBC transactions can fail.
For example, um, they might time out after 10 minutes, uh, from the moment you like initiate the transaction.
And if you want to bridge tokens, for example, uh, these tokens come back to you.
And at that point, if that you in this scenario is a smart contract, instead of a person, um, the smart contract needs to have some logic to, so that it can retry the transaction.
So it would be really nice if instead of handling all of that on the like smart contract sides, um, each protocol could delegate kind of that part to warp.
That's interesting.
Like you could create what Vlad mentioned earlier, like a century job, which would just keep track of the trace you're waiting for and like retry stuff.
And like, yeah, it's, it's, it's interesting because like, uh, people already like, uh, open source people already integrated warp with Otzi.
So essentially you can give warp jobs permissions for your own wallets and like do specific actions, um, on specific token transfers, be it IBC or whatever transfer it is.
Um, six stuff guys, let's, let's cooperate on that.
Yeah, there's actually another way to make sure that IBC transactions don't revert is, um, making sure that each channel, like an IBC channel between any two chains remains active.
Uh, cause I think at this point, if I'm not mistaken, if, if a channel is not used, uh, I guess, depending on how it's configured, if it's not used at least once or twice, once per day or once every two days.
Uh, it goes inactive.
Uh, it goes inactive.
So one potential use case for warp would be to, um, gonna send a heartbeat, uh, between any, like two chains through a specific channel to make sure that channel stays active.
Oh, you're about to say something, Vlad.
I know you were.
Yeah, man.
No, no, no.
It's just fascinating to hear.
It's like things I never even thought about with warp.
Every time I talk about warp with, with someone, um, especially people with like a technical background, they, they always come up with, with situations.
And it makes me think like, you know, I, I have no idea what people are going to come up with.
And that's just like the most exciting part for me.
Um, yeah, it's, um, it's really fascinating.
And I, and, and so far my, my head has exploded a couple of times this space.
So, um, you guys are doing a pretty good job at that with coming up stuff on the fly.
Um, I, I was wondering, uh, can, can you, can the Ashport team maybe expand on or not expand, summarize, um, the slam model just really quickly?
I understand it's an idea, right?
Uh, but for people in the audience, if you could just give a quick summary of that.
Yeah.
So, um, I'll kind of present the pain point through, I guess, a story.
Um, I think many of you know about Uniswap on Ethereum, right?
It's the largest AMM in the world at the moment.
Um, especially if you count the, like the several versions that they released over the years.
Um, the problem with Uniswap is that, well, it's also kind of a curse and a blessing at the same time.
They expanded across multiple, um, chains.
So they are, for example, on Polygon, they are on Ethereum L1 and so on.
Um, the problem is that, um, for example, you might have a lot of liquidity on Uniswap.
On, uh, Ethereum L1, you might have like 6 billion or whatever, uh, amount they have right now.
But you might only have like a hundred million in, uh, the Polygon version of Uniswap V3.
And let's say you have the exact same two tokens on these two Uniswap deployments.
Let's say, um, you have a, an East USDC pool.
Uh, the problem is you might, you might go to Polygon.
You might be a Polygon user and you want to swap in the East USDC pool.
But the price impact when you want to swap, especially like a large amount of tokens might be significant compared to the same pool like ETH USDC on, um, on ETH L1.
Where you have like, let's say a billion, uh, or maybe a bit less, but let's say in this case a billion worth of liquidity in that pool.
And even like a $10 million swap is not that big of a deal for that, for that, uh, version of the pool.
So what, um, what we proposed with SLAM was, and this is for like Astroport, the potential future for Astroport is kind of solve this problem of wanting to swap the exact same tokens,
but on different, uh, chains, uh, or actually want a different, like a version of the same protocol, but on a different chain.
And we said, okay, well, uh, what if we could somehow combine the liquidity from, in this case, Polygon and Ethereum.
And if, even if you swap, um, in ETH USDC on Polygon, you get the same price impact or the same like quote as you would on Ethereum L1.
So, um, you get way better price execution than you would have otherwise if you didn't use this like shared liquidity AMM model.
And the idea is that we assume that on each chain where an AMM is deployed, all the liquidity from all the chains.
So in this case, Polygon plus Ethereum, uh, exists on each chain.
So in this case, let's say Ethereum, uh, Uniswap on Ethereum has like 6 billion on Polygon.
It only has a hundred million.
So in this case, we assume that on both Polygon and Ethereum on the versions of Uniswap on each of these chains, there is 6.1 billion worth of liquidity.
So when you swap, um, in the ETH USDC pool, we assume that all the liquidity from both Ethereum and Polygon, um, is on that pool.
So you get way better price execution.
Uh, even if you swap on Polygon, you, we kind of assume that you swap on Ethereum L1 instead of assuming that you only use the liquidity from Polygon.
And the way we do that is we kind of fake the fact that there's all this liquidity on all the chains at, at all times.
And every, every, let's say 24 hours, um, the two deployments in this case, like let's say Uniswap, the two deployments would communicate with each other and they would settle, um, kind of liquidity between the two outposts.
So for example, if a lot of people swapped a lot of ETH USDC on Polygon, that the real amount of liquidity, like the real amount of tokens on that ETH USDC pool is really imbalanced.
Like there might be a ton of ETH on the Polygon side and the, in ETH USDC and a very little, uh, USDC.
So that pool should be arbed.
Um, so someone should kind of come and, um, kind of sell a bunch of USDC and get some ETH out.
So the way that's done is some of the real liquidity from Ethereum L1 in this case gets bridged over to, to Polygon, uh, and it gets added in the ETH USDC pool to kind of balance the, that pool, that version of the pool on Polygon.
So that it's at par, like it has like about the same kind of price, um, compared to like the, the same pool on, on Ethereum.
Uh, so in a way, like the, every, like in this case, every 24 hours, all the deployments on all the chains of where Uniswap is kind of balance each other out.
Like tokens get moved between these kind of deployments between these outposts.
Um, and the protocol kind of self rebalances in a way.
Yeah, it's really fascinating.
And I know I asked you like a really hard question to answer.
Um, cause there's a whole paper about it.
If you haven't read it, um, it's worth a read.
I would pin it, but it's somewhere in my bookmarks.
Um, and maybe I can ask just a quick follow up question.
I know we're getting a little bit close on time here, but there's the other side of it too, if I'm not mistaken, you can, uh, doesn't the liquidity provider also benefit from being able to have their liquidity kind of benefit from the different, um, I guess the, the different demand cross chain, if that's a good way of saying it.
Yeah.
So the idea in this case is, uh, again, you might only have, um, and I'll continue with the Uniswap example, cause it's slightly easier than Cosmos.
Um, but you only have ETH on Ethereum L1 and you can only pay gas fees with ETH.
Um, and you cannot, for some example, for some reason, you cannot pay gas on Polygon, but you still want to participate in Uniswap.
So you would still want to be an LP.
You still want to get fees from all the training activity that happens on Uniswap.
And you want to get a kind of slice of the pie from Polygon as well, but without actually interacting with Polygon.
You want to LP on Uniswap on Polygon without actually interacting with that chain.
So the way, uh, you do that in, in SLAM is the only LP on Ethereum L1.
And when this rebalancing happens, like in this case, every 24 hours between Ethereum and Polygon, some of your tokens from Ethereum get automatically transferred to Polygon in order to balance out all the changes that from the swaps that happened in the last 24 hours.
So in a way you become an LP on all the chains that are connected through the SLAM model.
That's kind of the advantage, but the disadvantage is that in case one of these chains blows up.
So for example, Polygon halts for some reason, uh, your liquidity might get stuck.
So that's the disadvantage of like sharing liquidity.
Well, this is, I mean, across the board, this really been a fascinating conversation.
Um, and, uh, I, I guess you heard it here first, right?
Um, I guess we can only call it an idea, right?
Slam, right.
But, uh, Ashport and Warp are talking about it and potential integrations together with this idea.
Uh, I would like to just take the last few minutes.
Uh, we did have one person that requested to speak, but I don't see their hand anymore.
Um, maybe a little bit of a shy audience today, but give you all a chance, uh, to give any like final words, uh, call to actions.
Oh, wait.
Oh, wait.
We just got the request.
All right.
And it's gone.
Oh, no, wait.
No, they're bringing them up.
Okay.
Great.
Hey, go ahead.
Whenever you're ready.
Ask your question, man.
Hey, hey, hey.
Uh, can you guys hear me?
Yep.
Nice.
Okay.
So, uh, first question is, I guess, to ask for part.
So is there any plan to open source the front end?
So like more community member can play with it or like build more function into it?
Cause we are building, we're playing, uh, we're trying to build limit holder and DC on top of Warp and AstroPort.
But, uh, because AstroPort front end is not only source.
So we have to build our own front end and it's, uh, it's a very ugly one.
So the front ends that you see on app.astroPort.fi is maintained by Delphi Labs.
Um, I think it will stay private for now, but we are thinking of potentially dockerizing that front end.
So dockerizing the codes that anyone can, um, run that front end locally if they want to.
Um, so that kind of is a way to make sure that anyone can like step in and like run the AstroPort
app in case something like happens to app.astroPort.fi.
I see.
Yeah, that makes sense.
Okay.
Um, another question is, uh, so in terms of the protocol paying the reward on behalf of the
user or job creator, I want to know how do you guys feel about like protocol owning the
Warp account.
So right now, I guess, uh, if I go to AstroPort and I create a limit holder, I need to create
my own Warp account first.
And, uh, like if I'm gonna swap Luna to USDC at a certain price, my Luna will stay in my
own Warp account.
But, uh, if AstroPort, uh, basically AstroPort governance, uh, maintain a Warp account and
it holds all the users found using for those limit orders there.
And you can also like, uh, deposit reward into that account.
In that, in that case, like user don't need to, uh, like pay the job reward.
I guess that's one solution I can think of now.
I wanna know how do you guys feel about it?
Yeah.
So honestly, I think it'd be up to the protocol, um, to decide how they want to do that.
That is like a possibility.
Like if AstroPort wants to do that, they can route it through, um, a Warp account created
by Astro governance.
Um, and then Astro governance would have to decide to, you know, fund, fund the rewards
for that.
So definitely a possibility.
I would say it's, it's up to the protocol to determine, um, you know, the approach they
make, whether they want to, um, outsource the, the cost of, of running that to the individual
user or, you know, have governance front, front the cost and make it, make it less of a load
on the user.
I see.
I see.
Uh, I don't have other questions.
Hey, thanks for coming up.
Really appreciate it.
It's always better when we get a little bit of a community engagement.
So thanks for your questions.
Uh, just want to throw it back to the, uh, call to action.
We'll just go around.
Cause I know we're getting close on time.
Any final words alpha you want to drop roadmap.
Time is yours.
Uh, so we can go ahead and start with Warp.
Anything you want to say?
Yeah, I just want to give quick shout out to to BOC or Bok and, and his friend, Luke.
Um, I'm been super, super active within the Warp community.
Um, playing around doing some really cool things.
some really cool things.
So it's super exciting to see, you know,
community members step up and, you know,
experiment a little bit and play around.
So shout out to them for that.
Anything you want to say, Georgie?
I can close this off with a very cringe line.
I like to, like, why people use blockchains.
It's a software you can trust, right?
It's a synchronous software you can trust with your money
and you can only perform synchronous actions,
which goes by with, like, synchronous state modifications
via execute messages or, like, function calls or Ethereum.
What Warp is, actually, is bringing a synchronous nature
to all of that.
So by default, blockchains are synchronous in nature
and trustworthy.
Warp makes them asynchronous and trustworthy.
That's it.
Ashport, floor is yours.
Anything you guys want to say?
I'm just waiting for Warp to launch
on all possible, like, Cosmos chains.
So I guess I'll just finish, like, with when Cosmos chains,
when launch everywhere.
And once that happens,
I would love to, like, focus a bit more
on cross-chain use cases.
Yeah, so super soon.
It's, like, right at the top of the priority list
is getting it across to all chains
that have a use case.
So very soon.
Working night and day on that.
Yep, that's all I have for now.
Yeah, I guess from my end,
just, yeah, congrats, Warp, on the launch.
And I'm excited to see all the jobs
that people can come up with.
Thanks, guys.
I'm excited to see what you guys come up with as well.
Well, this has been a terrific space.
Really easy and natural conversation,
which is always good,
where I don't have to jump in
and ask too many questions.
So I just want to say thank you
to all the speakers for being here today.
I know you're taking time of your busy day
working on protocols
to come and speak to the community,
which means a lot to all of us
and giving us some precious alpha there.
So that's always great.
And then thank you to everyone here
for tuning in.
You know, shout out to you all.
Obviously, Terra ecosystem
has been through a lot.
And so it shows a lot
when people stick around
and still interested in the tech
and what's being built,
even as it takes on
a greater cross-chain role,
which I think is exciting.
But other than that,
I'm going to go ahead
and give just a shout out
to all these guys up here.
If you're not following them right now,
go ahead and do it.
They're way smarter
than probably most of us.
But and they're definitely worth
keeping an eye on
as well as their protocols,
Astroport and Warp.
Make sure you're following them,
keeping up to date.
Maybe go try out limit orders
on Astroport
and see what that was all about.
But other than that,
I just hope everyone
has a really great weekend
and you enjoy the holidays
if you're in the United States.
So thanks again for everyone here.
Thanks, Steve.
Thanks, everyone.
Thanks, guys.
Appreciate you volunteering your time
and hosting this as well.
It's been a blast.
OK, it's always a blast.
Thanks.
Thanks, Vlad.
Thanks.
Thanks, Vlad.
Thanks.
Thanks.
Thanks.
