Good evening, Aaron. How are you, man?
Hey, glad to be here. Who's speaking from Notional? Is this Juffrey? I think Dung and Kang and Vroom will be attending too, but Dung has been working on fee abstraction a lot.
Ah, gotcha, awesome. J'affois, what's, how's it going over in Vietnam? Oh, very good, the weather is amazing. And I found some good protein now. So when you come back, I'll show you the good spots.
Yes, I require high quality protein, sir. And how are you doing back in America, right? Yep, yep. Here for a little bit good. Just really doing nothing but working.
Or you're going to Paris, right?
Yeah, for Osmacon we're having it in pairs. Oh, if you could let Cat Shark and GNAD 13 if you could let him
that will be awesome. Or maybe they have to request Kang and then can you request to speak? I think I just invite them to come up with you.
Just gonna wait another minute or so to get started. Just keep the chance to join and then we can get started.
I'm going to give some update about our implementation of the F-straction module. For now we have mostly
completed the module. We have been making some changes from using a wasm contract to using the
packet middle way the ABC packet middle way to using the path unwiding of osmosis so you know it's safe to say that we have developed many versions
of the FIA abstraction module to adapt with multiple IBC applications. So there's been three versions that we have developed.
Thanks, Katzhar, for that summary. I think before we dive into the extraction and Cosmos swap as well, I just wanted to give a brief update on the Osmosis grants program.
So yeah, over the past month, we've approved 10 grants for a total of $700,000 in funding, which brings the total funding amount to around 3.7 million distributed amounts, 73 different projects. And this includes batch
13, which was announced in partnership with Axlar, a CAF, this Moses Foundation, and the Atom Accelerator for the development of mesh security, as well as batch 14, which was the second largest batch of grants we've done today, largely due to the renewal of our
Paul, Paul, the poor purchase with Oaks security and other high impact initiatives like funding mystic labs to integrate cosmos with Maks-Maks and research related initiatives around threshold depression and IBC rate limits. We've also
witnessed a number of grantees compete their projects such as a fully self-posted front end for osmosis powered by Erbit, map of zones finish receiving their operational support, and fee abstraction and cosmos swap which will hear more from very short
We're also still accepting applications for a few high priority RFPs. These include interactive cosmos and tutorial, cosmosis, merge stores, quasar, bolst, phoroosmosis, and devile adapters.
continue to share regular detailed updates about the OGP, what deals most community through monthly, Twitter spaces such as this one, regular Discord office hours and transparency reports. In fact, you can find more details on
most recent updates in a quarterly report which was published yesterday in the blog section of our website where we recap the past three months of the OGP, including funding breakdowns, grantee updates, and data into operational expenses.
So yeah, with these updates out the way, try to a bit more about the abstraction task.
of refoverty, but can you explain really what the abstraction is and how it will benefit other chains for those who are not familiar?
Yeah, so FIA abstraction is a module that that have to improve the user experience.
So when any users on GNA, for example, could use any tokens that they want,
for their transaction. So if TNA implement the FiatSraction module, then an user can use token from, for example, chin B.
to pay for the transaction on Cheney. Basically, that's the whole idea of the fee abstraction module. And with the help of IBC, that we can realize that idea.
And so the way we do it is whenever an user submitted a transaction,
that is a non native fee token will use IBC application to basically swap out the non native token.
to get the date of token via osmosis stacks.
And then use the token that we got from the Swath to pay for the user fee. This whole process is going without the user knowing it.
So, if the user don't have to worry about any of that, which is great because we want to improve the UX.
Yeah, in sense, and which tokens could I like, how does it work from a user perspective? Like, how do they decide which token they can use to
to be able to pay via the abstraction is that the chain that whole native toll that native token has to have the
So if user on chin-a wants to pay a token on chin-b, sb, then chin-b has to have a packet forward mid-away.
So that's the requirement. Make sense. And they can use any IPC token support or the HANA's most of the right.
these transaction fees. They can select whether they want to pay fees in USDC, Osmo, in Applum, or any other token that's available on this Mosif. Yeah.
And so you spoke briefly about this earlier, but there are a couple of different versions of the field abstraction module. Can you dive into these differences and why there are different versions of this module?
Oh, yeah, so in our process of developing the module, we firstly work with the...
the IBC contract. So the idea is that right now any change has well, cousin wasm. So if you want to do the IBC swap,
then we might as well do it on a smart contract.
Yeah. And then we move to the second version.
which is using the packet forward middle way. We want to do so because the packet forward middle way is getting adapted by almost like every chain nowadays.
And it is according to the IBC standard. And then the version 3 is requested by the Osmos system because they want to
they want us to use the IP
path unwitting that is developed by Osmosis team.
meaning that osmosis will handle some of the logic for the fear-straction module so that anything that implement that
that import the Fiat section module will have to import less logic. So basically that's the 3 version.
So like the main differences here is that the first version will allow customer change to be APs and any IBC token available on a
osmosis using like T-wap data from osmosis but not necessarily swap those out back into donated tokens and they may choose to do this if they want to
You know, cheaper portion of tokens from other chains. The version 1 is used for a chain that has cause and wasn't.
Because they used the IBC contract.
And yeah, to do the IBC Swap.
And so for a change specific implementation, like how often do these tokens get swapped back on those moses? How does that process work?
It will not be swapped in every transaction. It will be gathered together. So the fee token will be gathered and be swapped in batch.
The chain can configure the time that they send the batch out to swap.
make sense. So we understand how this will benefit users on other chains because it will give them multiple options in terms of fee tokens. But how will this benefit
osmosis and the osmosis community directly. So the way that it will benefit osmosis, first of all is the increase of
dependency on North Moses. And then second is obviously the increase in the swath volume.
in values that brings to the DEX. Yeah, it makes sense because this will
by additional bargaining to the debt. And so what do you think will be the biggest challenges of implementing the Fiat strategy?
and module on other chains. I think it's like how we from the technical perspective is how we how we handle the packet
To do an IBC Swap, you have to do a MutiHolf IBC transaction, which is IBC transaction sent to a chain, then it trigger a neither packet to another chain.
Basically that so if you want to for example We send a packet to chain from chain 8 to chain B then That packet will trigger another packet from chain B to chain C And so the problem here is that
There's some failure in the middle.
then we have to do all the logic to handle that failure.
make sense. And to implement the abstraction module, this will require these other chains to undergo a governance upgrade, like approval and upgrade through governance. Yes.
And so now that the module is complete, what are the next steps here to get it implemented on other chains?
I think we already got one chain to implement the F-straction module.
we just tap to do an upgrade for that chain and you'll handle that carefully so that don't be don't mess up anything.
And which chain is this one we're talking about? I remember the name, Dan, can you tell me the name of the chain?
I can find it once again.
No worries if you don't follow.
Hmm. "T" sunny. I don't remember exactly.
Okay, now where's I guess like what will the governance process look like exactly so we know that like there needs to be an upgrade and it needs to be approved by governance but what are the steps here involved to make this happen?
We also have to update the code to import the module and the upgrade handler.
you know all the technical stuff that we have to do for the cut then we will proceed on a normal chain upgrade
Just that. Yeah. Just to jump in here. So that totally makes sense. And what are the sort of decisions that these other chains will need to make in the implementation? You know, I know with Osmosis, it's, you know, we've, I've had a couple of
proposals now to decide to add basically more assets to be eligible. So I'm guessing chains will need to think about which assets they should make eligible for this. And then is there anything else that they'll need to decide like how often they want to do these these bad
swaps back to their native staking token. I'm just curious to hear if you only thought so like how they should think through these decisions. Yeah, I think this the patch the batch swap period should be
One or two days it should not be too often It should not be done too frequently since air will cause a lot of IBC fees
for the real years. Also it should not be done to rarely, like I don't know, one month a time is not good.
since the price will fluctuate in causing potential.
and what is your questions? You have two questions right? No, that makes sense. So the frequency makes sense because if you do it too often,
I'm guessing whatever costs are required comes out of really the yield that goes to spakers from transaction fees. And then to your point, if you don't swap frequently enough, you take on basically a lot of price risk.
Is that fair to say? Yeah, yeah. That's basically what I'm saying. And yeah, and then the other piece was just, you know, I remember with Osmosis, we had proposals that, you know, speak to which assets should be supported. And so,
So do you have any thoughts on what an appropriate number of gas assets should be, maybe to start off with for these chains, or should chains just feel comfortable implementing as many options as possible?
The fee abstraction module doesn't need
implementing, I mean you don't have to implement
anything to use a new gas token. So, you know, it comes with the whole pack. Okay, so you don't need a new chain upgrade every single time you add a new gas token. Yeah, to be able
Yes. Okay. That's great. But does governance decide, you know, which, you know, they would prefer users to use? Or do they have a way to, you know, block the use of risky assets?
No, we don't have any way to glove. Risky, yeah, says yet. Got it. Yeah. So I assume that part is
more up to front ends, right? Which ones they decide to display as options like what it's and that kind of stuff. Whereas the field structure module allows you to these front ends
So basically give users any options available. Yeah, we could leave that to different end.
Do you guys have any other questions? I think that's all I have. I'm not sure if I have anything else but... No, no, that's...
It's great. Yeah. Maybe last thing, why can people learn more about the abstraction and the specific implementation? Oh, um, we have a repo.
for the F-straction and that's where we put all the documents and you can also watch this video from the Osmos system. They pitch about the ideas of the F-straction module. So
This is worth noting that this is an idea that comes from the osmosis team. We are the one that implemented. Perfect. Thank you so much.
cat fart. I think yeah we'll now add Nabilon to chat about CosmosWorth and then open it up for our skins at the end. Hello everyone, thank you for this space. Hi Georgia. Hi Vlety, good to meet you.
Thank you. How are you? I'm doing great. I'm sorry you're doing. I'm doing great. Thank you. Cool. Yeah, maybe to sort of, can you tell us a little bit more about NABLA and how you got involved in the Cosmos ecosystem?
Yeah, yeah, yeah, thank you. So, NABLA is a new company that want to provide services to companies, to other companies, and want to use the MAP3 and the blockchain technology in this concept.
to provide the services that was not, for example, all what it was not possible to provide them through Web2 or in Web3 it makes it better. For example, all the management for the TIGGAR Corruption
For example, all the tokens that must be unique, for example. And so all the things that could be improved through Web3, or could be provided only through Web3, for example,
are used in our services to provide a feature to companies that can be used for their customers. And for this reason, we arrived in Cosmos since we married
the idea of IDCA, we think that the concept of single-purpose chains is very important and we agree with this type of operation.
And in this concept, in this context also, we started to see what was happening in the ecosystem. And we saw that, for example, you in the smallsies were looking for something like
front end for one of your service. And since we are a group of enthusiasts with a good background in front end, in backhanding webtooth services, we started with
with this and for sure we have also a good background we can say in Web Tree we are studying we are participating in all the activity in open source we love these models of RAND in some sense
Perfect. Thank you so much for that answer. Okay. Thank you. Can you give us a brief overview of CosmosWap and the work you've done on the front-hand implementation? Yeah, sure. So you can think about CosmosWap as the ZWap
up for the world cosmos. As you know Osmosis is the best in class decks for the intent of blockchain and in this concept it's important to keep in mind that it is not useful to reinvent
they will every time. So with this concept in mind, as you know, one of the most important actions that must need to be performed inside an Internet of Blockchain, so where you have different blockchain that have their own purpose is the
swap of the token. For example, let's create an environment, a virtual environment. So I'm a user, I join the IBC through, for example, Bitsongor, Dasmus, for example, because they are, in some sense, a gateway
for the users. And once I arrived in the IBC, I saw for example that there is osmosis for exchange token, but also for example, Juneau for deploys my contracts and a lot of other blockchains for sure. In this concept and also in this
set in context, you know that if I want to use other blockchain, I need probably the Eurotron to, for example, pay for the fees. Even if there are some other services like for example the P-Share
modules and so on that are also the users to pay with other fees, not only with the field of the specific chain, but for example, if you want to deploy right now, I don't know, my contract on Juneau,
probably you want some Juno and there are different ways to perform to allow the user to perform these whoops. One is to create a new Dex on Juno and let the users to deposit their
or they bits and then swap to these new decks. Another way is to move on osmosis, perform the swap and then go to Juno. Another possibility that can improve the user experience
for any user is to add one new Dex that is more or less the first version, but with all the first version of the story I'm presenting, but with all the future and improvements of the second version, so the user boasts Moses.
And this is a combination of the two ways. So we in some sense create a new Dex, but these Dex uses a sort of infrastructure as a service level of the Osmosis services. So you have Osmosis as the backend.
in some sense and a DAX that is branded with, for example, June interface and so on for any change for sure. And this is the concept of outpost. So there are different outposts. Any chain could create
its own outpost and CosmosWop is a collector of all these outposts. So, I'll allow any chain to create a outpost and here you can swap the token, for example, from your chain to another chain.
And we call that together with those Moses guys, we call that cross-chain swap. So you can swap token from multiple chain. I will give you, for example, more example later on if you want to
make it simpler in your mind how the tokens are transferred from a chain to another and which kind of swap you can perform. But the most important thing, so I think I want to highlight is that the
First goal, the most important goal of the realization of CosmosWop is the improvement of the user experience for any of the user that is inside the Cosmos ecosystem. I hope I answered more or less correctly at whether you were working
Yeah, no, that was a great explanation. So, yeah, I agree that the aim of this is really to improve the user experience for user development also to reduce the need for other chains to build their own taxes, right?
where there's already a bet with so much liquidity and support for so many of the small costless ecosystem. So exactly. To zoom in into the user experience point, what will using Consumers will look like for users?
Like if you were a user from their perspective, like how do they use Cosmos? Yeah, okay. So as you say, they want to also highlight that the advantage of using Cosmos Wop is that, for example, for the Outros chain, let's assume a chain B that creates its own Outros.
that even the fact that they don't have the programmers don't have to create a Dex really, but only to in some sense configure affront that is already made up. Moreover, the trained don't have to
think to, for example, create the funding, the liquidity and providing all the stuff that are needed for index. Okay, so coming back to the user experience, you have to think that right now, if you want, for example, to swap, I don't know,
to get a token A in token B and token A and token B are not Osmo. What you have to do is jump on Osmosis, deposit to get A, choose if there is a pool or a route of pools that are lo this warp.
perform the trade, so exchange token A for token B and then to get back the token on your chain you have to do to perform a withdraw, okay? So you have to perform the first transaction that is deposit, perform the second transaction
that is a trade, perform the third transaction that is a withdrawal. With the cost most of all, you will do more or less everything in a single transaction is everything if everything goes well. So what I mean, I mean that you are in the
A&A environment. You perform an ABC transaction to the Osmos blockchain. So you perform an ABC that triggers some smart contract on the backend that is realized by the Osmos' guys.
with the single transaction that triggers through IBC, those most is smart contract, then there is a chain of smart contract that are triggered among others. And the result of these
trade is returned directly back to the Shane A. So here you have only one transaction and this transaction also allow you for example to trade I don't know
Adam, for example, could be on your June, let's assume that you have some Adam on your June account. Through CosmosWop, you will be able to exchange to trade your Adam, for example, to, I don't know, there's no sorbids on what the rent.
directly with one operation without transaction for you and get back the result directly on your account, on your June account or on your other example that is for example the other account that is for example I don't know the bits on accounts and so on to perform all this trade
and these swap back in some sense. We make use also of the Paget module, middleware. That is the same thing that used the guide before for use.
a sort of breuder that is a middle-wing in this case, the specific case that takes a packet and then forward it to another chain, okay, without having to contact directly an account on that chain. So in this sense, we
move it to only a single transaction where the fee of the transaction are paid in the in the token of the chain where you are performing the outpost. So for example, if you are performing this WOP on the June outpost you will pay
in Juneau. Okay. And yeah, I think that up to this point it is a good improvement on the UX. But moreover, you can follow the full chain of swap and movement of the token.
from all the chains through a state manager that is something like a small page where you can access and see for example where are in this moment my tokens they are on a chain on a smooth chain I am performing for example the
swap and if any error happens for a car during the swap you can see where the tokens are in any moment and in some moments it could be necessary for you to
action to recover this token, for example, from the contract on those Moses chain. Or if they, for example, failed, the operation failed before this warp, the tokens come back automatically to your account. So it's smoother in some sense.
So the idea is that instead of users having to perform all of these actions manually, touchy, like the swap they're looking for and get it back to the chain, they were on, they can just use CosmosWop to do this and one click transaction.
Yeah, yeah. And so for a perspective chain that's looking to implement this solution as well, like what sort of considerations to make and how can they make this happen basically? Okay, so with the
regard with the front end part, it's very easy to implement an outpost because we will push together with the guys from Osmosis. We will push a documentation that can help you anyone in
create your own version of the of the outpost both from the design part and from the development part because our designer Johnny who which is very impressive created a big my version of the
that is publicly available and you can clone this big model. Customize all the data inside this design and see which will be the result at the end of the modification.
So when you selected the palette and so on and later on, once you are happy with the result, you obtain it on the design, you can move forward and implement this modification also on different
So you have to select and to edit an M5 that is provided by our best developer, David. And from this environment, so you can set the variables, the type, for example, the color for the palette and so on.
both for the style part, for example, I say the color of the theme, and from the logic part, for example, you have to set some of your PC for the scene you are using. And once you have
set up a name file, more or less. You can run your post on your computer and see that it's working. So we provide you the orientation and also for sure you can contact us in our discord or in the discord of Osmos.
So, this is the support that we would want if we were using the service. So, we are trying to provide you the same support we want in some sense.
So other chains could basically modify this front implementation to like change the branding to match their own brand.
also be front end widget that projects on these chains could directly implement into their own web apps, right? Yeah, yeah, yeah, we also provided, as you said, thank you for
or disreminder, we also provided a component that is compatible with, for example, React. And you can use it to attach embed in some sense, this widget inside your existing application.
Yeah, so the idea here is that users don't even need to be the applications from them and they can just screw up on those Moses as long as the web app and that's the widget into their website. And then there will also be like a standalone
and website were called Mosswell, right? Where people can navigate to.
Like there will also be a standalone Cosmos web site where people can navigate to and like select the chains they want to swap on and stuff like that. Yeah, sure. There is a version that is also provided.
For example, we are working together with the Osmos disguise to provide you a ready to use in some sense version that will be hosted with the name of Cosmos whoop. So any user will directly interact with
the specific outputs of the chain that you want to see. So there is this sort of collector of different outputs. We are working on it together with the guys from Osmos.
Perfect. Yeah. And I guess apart from the front end stuff, on the back end, the only stuff that's required for chain to use CosmosWap and be supported by CosmosWap is basically
the cost most of the cross chain contractings to be deployed on that chain, right? And if that chain is permissionless, like it doesn't require any governance approval or anything like that.
Yeah, I think that it could be also simpler in some cases. So for this specific information on the smart contract, I think that I could provide you some wrong information. So it's probably better to
talk with Nicolas, for example, from Osmosis, because we only work at different than. So I don't want to give you some information that could be not so correct. Yeah, no worries.
But yeah, we've been testing out the front end and I'm kind of sure that it looks really great. So I'm really excited for it. Thank you. Cool. Yeah. I think that's
That's all from me. We can open it up to the community for any questions if anyone has any. If you have any questions feel free to request to speak and I'll invite you on here.
Okay, it doesn't seem like there are any questions. I think you can end it here unless anyone else wants to say anything. Yeah, thank you so much, George, Katzhar and Jeffrey for joining the CIR today.
having us more about peer extraction and cost muscle for two really exciting projects going live soon. Thank you for having us. Thank you. See you guys later. Have a good day. Thanks. Have a good day, everyone. See you all next. Thanks. Have a good day. Bye.