Thank you. Hey everybody, pleasure to be here.
I just would like to ask for everyone to wait a couple of minutes just to get more people in the space and all
the crew members join and we figure out the role and the participation. Thank you. Thank you. Okay, so we're starting to pack the space up.
So without further ado, let's go forward with it.
I'm Ivan, one of the co-founders here at Novas.
I will be your host today and we'll try to make the space as relevant as possible for all listeners,
just to kind of catch up what we've been doing in the last couple of months,
what are our actual achievements and of course where we head at.
But before we start, I would like to give the stage to Kamen, who can actually
provide more details about how's the protocol progressing in terms of usage and in terms of,
of course, the key metrics that we follow and how's the growth going going Kiamen would you like to hop in here
hey guys nice to see you here
that we are making this August edition
everything has been very stable in the past couple
of months which is actually
we have expected more because the market is currently like on edge and not moving very fast
we can see that in the metrics of other DEXs and other perp contracts so it's basically around, we are around 4 million of TVL. We have seen 700,000 USDC flowing in into the protocol in the past 45, 50 days.
We are still experiencing and having ATOM as the largest lease position.
It has been mostly trusted by people, currently probably taking around 60 percent i mean
staked atom and atom all together and we are seeing new grants new walls new leases
being stable compared to the past four five months we don't see more in terms of value, but we see more in terms of people.
What it means is that we see lower amounts on average, loans, that are actually being given to more people, a positive note again, especially the outs, I believe more people would be willing to take more risk as time progresses.
So we are hoping to see those 4 million reaching 6, 7 million in next year.
early next year and of course this is not only due to the market we currently have but also to
the market that we would be pushing out in markets that we would be pushing out in the future in
terms of this was the borrowing part in terms of blending everything is again being stable stable
we're around perfect utilization or the targeted utilization which
means that currently we are at around 11 11.5 percent apy for our stable coin pool which is
pretty awesome pretty good i believe that this is where we want to target and i hope that we stay
around that level not going towards higher utilization than 70%, 80%.
I believe this currency is the perfect example of a stable,
and this is what we were aiming at at the very beginning
with this targeted efficiency ratio,
is to be at that level that has sufficient funds to cover new loans,
that provides sufficient APY to current usbc holders
and it is actually staying pretty much on that level in the past weeks which makes me happy
i believe this is like a very brief summary of what the numbers are currently
numbers are currently. Ivan? Yeah, I just have one question here. It's great that we are seeing
stability in the protocol. Regarding liquidations, do we have any interesting events happening in
the last, I would say, 40 to 50 days? Because from what we've seen on the market, there were either big liquidation
events on both sides, shorts and longs.
And I'm just curious to get your point of view because I know you went through the data.
And of course, did we manage to save any positions with the latest edition of safeguarding features
Yeah, actually this is pretty to the point.
We haven't experienced any liquidations,
And indeed what we have probably two or three months accomplished
to see Mac in working has actually saved a couple of positions in the past
inefficiency in a current
below the liquidation trigger
but then returned pretty rapidly
due to probably arbitrage bots and stuff.
And the map that we have implemented has actually used that into the advantage of the user
by not liquidating them during that time, but rather saving their position.
Amazing. Thank you. that time but rather saving their position. Amazing thank you I'm glad to see our tech
working and helping people rather than taking out their their money out of their
pockets because in the end of the day if people win and they're happy from from
their gains the protocol is also happy at the end of the day.
It should be synergetical between the actions of the protocol,
should be synergetical with the ones from the users.
So glad to hear that this is working well on our end.
And in the last 50 days, probably more, first we hadn't got the chance to make any spaces,
which is the reason being is that we were pretty much in, I would say, deep diving into
enhancing the technology that we provided.
We wanted to make room for the upcoming updates and to make room for the project LX itself to, and for us to
However, of course we had some outstanding updates that we had to perform, but of course
by now they are all kind of in the past, they've already been implemented and I just want to get back on
what we've actually implemented in terms of money market updates and blockchain updates.
And for this I will give the mic to Mehta who can actually speak more on what were the latest enhancements
on the money market and why those are great features for users in the end of the day.
And of course, what are the benefits for us as sort of, I would say, guardians of the protocol itself and what does this gives us as an option to
kind of go forward and better maintain the code structures and as well as the
protocol itself. Thanks, Simon. So yeah, on the smart contract update side, last week we rolled out the latest update,
which included several interesting and pretty useful features.
So one of them is the removal of this manual claiming step that each user who has opened a margin position and has repaid manually
either manually their debt or partially closed their debt but hasn't fully closed their position
yet. Now this step is fully gone. It's whenever you like uh make this uh debt repayment now uh on your
position uh you don't need to do anything else the funds simply arrive in your world
and uh it's something that yeah may also uh some users especially at the beginning they kind of
were confused uh about uh why would they need to like additionally claim their funds well that's now in the past
and we also with this update we introduced the feature to to transfer to transfer both
the loan and the collateral that the borrower initially provides in a single transaction,
rather than like two separate messages or two separate transactions.
Because, and yeah, this of course leads to faster opening times.
You might have already noticed that then it's kind of further contributes to our goal to really minimize this open opening and closing
times of positions both yeah so and the last last but not least with this the
break we introduced a feature to close automatically close inactive
markets and this is an especially useful feature because with we did we kind of make room for the
first week make room for the protocol to maintain it more easily.
With each new market, there's a set of contracts that need to be published on chain
and then maintained via migrations, etc.
And if that market isn't that utilized by the users and they don't find it that interesting,
it doesn't make sense to actually
continue supporting it and that was the case for example with the st atom short market which had
like a little less than six six hundred dollars deposited worth of st atom in the lending pool
and zero margin positions opened so what what this functionality allowed us was to push out the proposal to
close that, to deprocate or close that market and to automatically distribute
those idle funds that are in the lending pool back to the depositors.
So if some of you have like deposited some ST atom in that market,
you simply needn't do anything.
Once that market gets close, you would have received your full deposit amount with the accumulated interest in the meantime.
So I think that's a pretty powerful feature. feature and uh yeah we will be uh uh continue we'll continue monitoring the the other markets
and see like uh which ones would make sense to kind of deprecate it would be like markets
that have zero zero active positions uh in them um definitely and yeah, that's like on the, how to say that, the three main things that were introduced
Yeah, just to add here, so to summarize it, 30% faster lease openings, no redundant states,
which we had to kind of, we had to have them in the contracts because we had some, let's say,
shortcomings that we need, that they covered.
However, this is all already in the past.
And last but not least, as Metoli mentioned, this, let's call it the administrative feature
will kind of help us push forward to new markets and of course
deprecate old markets, for example, like Acceler USDC markets that are not actively used in
the protocol and kind of maintain its health and organization much easier and much better.
So for us, this is kind of a big thing because it gives us the flexibility to just with a
governance proposal to maintain the protocol in good health without having any, let's say,
And it's pretty, pretty cool.
Apart from that, we also pushed a couple of more updates that are more focused on, I would say, on the backend side of things.
As you know, NOLAS being a fully cross-chain reliant protocol, the NOLAS team needs to make sure that we have have a hundred percent of time without no downtime.
So in order to achieve that, we run a full scale infrastructure on our end.
Just to kind of get the perspective of what a full, fully pledged infrastructure looks like.
This means like we're currently running more than 30 nodes, not only analysis ones, but also ones that are for, for relaying
and needed for, for other operations. For example, osmosis nodes and neutron nodes, they all have
Now they all have like redundancy by two by three.
So in the end of the day, we are like, I would say, a powerful validator that runs all the
infrastructure by itself, as well as running as well as having the infrastructure run by
external third party validators or external third party relayers and etc.
But this was kind of a burden for the team, especially for the developers, because we
kind of took 20% out of the developers' time in order to maintain this infrastructure up
So, what we've decided to do is to fully automate all the processes on having the infrastructure
up and running, but also maintaining it in a good health because I'm not sure how aware
we view, but most nodes, depending on their use case, they need to be treated differently.
For example, we currently run like seven or eight nodes that are used only for RPC provisioning
They do not need to provide any historical data, but rather to be snappy and fast in
order to get transactions and execute them and redirect them to validator nodes.
So for this to be done, they have to have a minimum set of database in terms of size.
So this is one of the things that was the first that we automated was to prove the database
of those RPC nodes and keep it as small as possible in order for the nodes to be quick
in terms of providing the data that the web application needs to kind of serve to users
and to be snappy when times comes for executing transactions. This is probably not something that people see in terms of
performance in the web application, but looking at the times for how fast the app actually
gets operationally ready from hitting the address in the Omnibox.
We've seen something like 20% faster loading times compared to previous measurements, which
is something which is great because we are now somewhere around, I would say, one second until all the UI is loaded and ready for operation.
So this is something that we're pretty stocked about.
Apart from that, we've also introduced a good amount of automation and I would say some structural changes in terms of how we manage relay notes.
And we're also seeing some performance enhancements there.
I mean, transactions are flowing much faster now, which of course, in the end of the day should result in a better, better, I would
say execution times for end users.
Apart from that, I think the other big things that we kind of did, but of course were something
in the, in the background where we introduced a lot of small updates to the web application.
Some were provided feedback from users or others were just small, let's say, fixes or
enhancements that are not seen with the naked eye at first, but in the end of the day, make the user experience a little better.
So this is something that we are striving to do on the long run, just to provide a really great user experience
and packed with a really great service.
with a really, packed with a really great service.
Yeah, I think these are the kind of the big things
that we did under the hood in the last two months.
However, we've also started something that is,
I think is pretty interesting.
We've also started working on the next,
on the next iteration of upgrades for the money market.
And they are focused on scalability rather than features.
And I would like to give the stage to METO
just to kind of walk us through what project X is
and what's the motivation of working on it for the last year and how did we come to the
final reasoning of why we need to continue developing the scaling solution by ourselves,
but rather using something that should come with at some point with IBC v2.
should come with at some point with IBC v2. Of course so yeah as you as you all
know guys we like Novos is utilizing IBC to at the moment the version one to
facilitate trading with established decentralized exchanges in Cosmos. So we are utilizing interchain accounts to register an account for margin position
and that accounts simply buys and sells assets on this taxes.
Always well at this point.
But we realized that the market is bigger than just Cosmos.
There's other ecosystems out there, and for those ecosystems,
the current version of IBC that we're using hasn't been developed to establish this cross-chain communication. And two, IBC has like a
newer version which is much more efficient and much more simplified in
terms of architecture, but it's still lacking the some components that are
necessary for trust minimized communication and also the the relaying
service that manages this this transferring the packets between two
two chains isn't isn't broadly available so this these components are still yet to
be developed and we as a team decided that we should be the ones taking the reins in this case
and kind of pushing forward in that direction to kind of build out these components
so that Moe's can continue working as it is but uh be able to reach out faster to uh other ecosystems
out there which uh with more with more liquidity more volume so that the protocol can grow economically
and uh yeah i think that's like the the core motivation behind Project X.
So yeah, we've already started working on that.
And yeah, over the next months, there will be updates on that project.
Great, thank you. Thank you for this brief kind of outline was the motivation behind
Project X. Historically speaking, I think this is something that we've been tinkering
around for more than a year. Correct me if I'm wrong again, but from my perspective, I think this should give the protocols a match in terms of faster go-to-market
The good thing here is that in terms of design, everything will be IBC compatible, every component.
Of course, we will be contributing all the development we do with the team behind
that are currently developing IBC. Hopefully they find some merit in what
we develop and can use it and of course speed up their development as
well. But again there are a couple of components that need to get aligned in
order for the scale for IBC to start scaling outside Cosmos properly.
Mehto, would you like to kind of outline which are the next components that we need
to focus on our development in terms of giving knowledge the scalability that it needs for
interchain accounts for for example to grow outside cosmos and to be usable there and which
are actually the the the components that we currently see uh see uh unavailable for IBC and for our use case, of course, because it's pretty, I would say,
narrow in terms of how we use IBC.
So in its core, IBC simply relies on light client verification for ensuring that the
communication between the two chains and the transfers are trust minimized,
meaning that there aren't any multi-sig wallets responsible for transferring or holding the bridging assets,
but rather the security lies in the validator sets of the two given chains.
Now for Cosmos, because Cosmos chains are basically...
they've all been developed on the same stack, right?
They have all the underlying infrastructure,
and if you develop a light client for one Cosmos chain,
then you could easily spawn a light client for another Cosmos chain.
But for other ecosystems or chains out there, like let's say Solana or Ethereum, you would
need to develop a light client for those chains.
And that's something that is missing as a component in the current IBC state,
in the live version of IBC v2 with Eureka.
So this is like one component that absolutely needs to be done to ensure this
to just minimize the communication style.
And the other component is the relaying software.
And this is like a third-party service that's responsible for safely transferring packets between two chains.
So if, let's say, now you open a position on Novos, you basically, in the background, the relaying
service sees that this is like a cross-chain action and processes that packet on the corresponding
support chain and that in that way kind of facilitates the opening, closing or liquidating of a given position,
or even could be like a simple cross-chain transfer.
And that relaying software for the second version of the IBC
isn't broadly available, so you cannot just run it on your own and participate in relaying alongside other independent relay providers.
So this is something that we also need to take care of and work on to kind of make sure that Nose has these necessary components to fill in
the gaps for this just minimized communication.
Thank you, Metodi. You kind of nailed it. Yeah, but in the end of the day the
whole idea behind Nose and one of the reasons why we focused on building on the Cosmos stack is not only preserving sovereignty and, of course, just adding an extra layer of security, not only by doing it with Wasm contracts, but rather isolating the whole functionality on a semi-permission blockchain.
The reason why we were highly motivated to start building on Cosmos was again the division
and the option for us to scale knowledge on various chains and not wait for, let's say, users to come to knowledge, but rather proactively for knowledge
And unfortunately, the IBC development has been pretty slow in the last couple of years.
We kind of had a lot of talks with the team there in order to, let's say, show them some inefficiencies.
We've also actively wanted to make a second version of Interchain accounts and we also
propose that we can do it pro bono and provide everything in terms of code base to and push it to
their official public repository. However, they have a different vision how this should go.
So in the end of the day, we decided that we have enough resources at the moment and enough, I would say, expertise to kind of follow along and
make it make NOLOS to be the one of the first to go to market with IBC and interchain accounts
out outside of Cosmos. So yeah, I guess in the next common upcoming months, we'll actually see how this plays out, but hopefully we'll be able to support another non-native chain fully by the end of the year.
I believe that this has been the vision of ours since the beginning, right?
So it was a matter of time of how to do it I believe
it was much slower than me personally anticipated uh but it's coming to to that means right so it's
it's it doesn't matter how many hardships we have seen on the road. Me personally, I expected more of, let's say, the stack itself, the core
technology driven people behind to be more active. But in the end, we'll do it ourselves. We'll do it
with our own efforts. I mean, it would be as good as any other. As long as it works and it works
seemingly fastly, which we expect to do.
I think it would be about time to see such an expansion in Novos. Not only in Novos, but with IBC as a whole.
This is exactly what we're trying to achieve here.
We're not trying to migrate Novos to a different ecosystem or to kind of the couple
the couple knows from from the cosmos sdk or or the superior stack that we've already
been using however we want to just to help um figure out how to fast how to scale it faster and
probably this would be beneficial for the whole ecosystem in the
end of the day yeah and to the users uh themselves because uh segregation is not good for for any
business but for the crypto community especially so so i don't want to really push it but i don't
want to see some people being on one ecosystem other people on second ecosystem
and the other are cosmos related third people right everyone has the right to let's say going
to one app it doesn't matter what the app does uh but in this case you know and actually
participate from different markets different decks that's why we have always been using different DEXs
and connectivity to those DEXs.
Now, the only thing that changes now
is that these DEXs won't be built with Cosmos SDK
or on Cosmos rather than we'll try to expand
to another DEX that's on another blockchain.
It's that simple in my view
I fully agree with you so um I think this is the update from from us for uh for up until now if you
guys have any questions you could either raise your hand or just ask them in uh in the comments i'll try to follow along and
give you some time in the next couple of couple of minutes to
to go forward with your code your questions i'm just trying to find where the post was. Okay, I don't see any questions here, so let's wrap it up for today.
Expect a lot more from us in the upcoming months. We have we are also working on some interesting features
that for now are in, I would say, in testing. We're not sure whether they will go to production.
It depends whether how the support of these features goes forward and if they're stable enough.
But if they do, I think we'll make everybody's lives much easier and make the whole experience
on Novas even better in terms of how users interact with the protocol itself and the
network itself. That's from us for today.
I hope you have a great Friday and great weekend ahead and talk to you in the next one.
Bye-bye everybody. Thank you for joining. Cheers. Bye-bye. Cheers. Thank you.