Welcome to Game of Notes, a weekly podcast on the cosmos from independent validator teams.
Hello everybody, welcome to Game of Notes, the podcast by independent validators of the
cosmos.
So today we have Sunny coming to join us but he's running a little bit late.
So introductions of our regular participants that are here today.
So we've got Yussepa and Shilty and myself Null.
And Sunny is joining us, he's just running a little bit late so we thought that we would
start the show.
And we would just do a few follow up questions, talk a bit of shit and discuss random questions
from the audience if you guys have any.
So sorry about the delay but let's get down to it.
So do either of you guys have any questions that have been asked this week that you think
we should be looking into?
Maybe the validator comments, Yussepa.
Maybe do we want to touch on the two groups that have sort of formed in the last week
or so and then maybe discuss a little bit about some benefits and pitfalls of going down
this route?
Yeah, we can.
So Shilty and I were both actually just in a call with the Validator Commons group which
is, I'm not sure what the origins are of that.
Actually I just met one of the principals from that this morning.
It's actually in the town where I live which is pretty fascinating.
It's always interesting to run into people like in the crypto space in real life when
it's not like a giant show and things like that.
I tell you, there's some weird thing about Pennsylvania and crypto.
There could be, I don't know.
I've read it with so many people that are from Pennsylvania and do crypto.
We should share Andrew's books.
I like to meet more folks.
So anyway, I think the Commons group, there's some really large and prestigious validators
and like Corus one is in there and Stakefish and there's others in there as well.
And that group is, I don't want to speak for them because you can go look at, I think
it's Validator.
Do you know what this is?
Let me find the, I'll find the link as we talk about it.
But they try to work on solving some different problems and trying to be able to provide
some research and other types of data sources to the cosmos.
I think it's a good way of saying it.
And they also, I think the background of that group is outside of even crypto where
starting to talk about just governance in virtual worlds and then now the cryptocurrency
piece has really kind of driven that a lot since we've had, I'm not just in the cosmos
across the whole space around different types of governance and kind of ownership components
and challenges, right?
And how do you start building up a governance structure that makes sense?
So that group, I think originally might have started a little bit more around the balance
of Validator groups and maybe project foundations and just kind of project leadership areas.
And then that's one team that's been discussing, I think for a while.
And then recently, we had another group that's formed really more grassroots.
And then a whisper node really drove this and also, help me out guys, who else drove
that initially?
Thiborgh was also a big proponent of it.
Thiborgh as well.
And so that started a group called Cosmos Validators, which has a discord.
And actually, there's a decent amount of Cosmos Validators in that discord.
Not right?
There's a bunch of people in there.
And that I think is also talking similar types of areas, just maybe a little bit different
focus.
That focus, I think, has been, we talked about a little this last week, but that focus has
been a little bit more around almost like Validator self-policing or finding ways to
be able to better share Validator information out the delegates and others, which is, again,
I think everybody wants the same goal.
It's just different ways of talking about that in different areas of the problem.
And now these groups have been starting to discuss more and there's opportunities for
maybe finding better ways to communicate and build some structure around it.
And I think I don't think anybody's trying to necessarily change the structure of governance
completely.
I think both groups, and I don't know if I'm fair enough on this conclusion yet, but I
would say that the Cosmos Validator group is kind of focusing more around providing
delegates better information and allowing validators to be able to provide other information
than just voting power on how they might choose to delegate with someone, which I think is
totally valuable because there's so many great projects that validators do that you would
never, unless you're in this business like 100% of the time, you would never know what
that is, right?
And how do you see some of those just by accident, right?
And then on the comment side, I think they're trying to find ways to be able to work with
foundational groups to better say, what does a healthy validator set look like and what
are some of the proponents of that and how do you work it from that angle?
So I don't know.
The reason I'm kind of hesitating and being more specific is because I don't think any
of this has been figured out, right?
We're just kind of in the early part of the process.
Yeah.
So I mean, I don't know too much about the Validated Commons yet.
I haven't looked into that.
I was talking to Jake yesterday morning and he actually asked me what I thought about
it, but I misunderstood and thought he was talking about the Cosmos Validators League
and then so started to ramble shit about that for 20 minutes.
So I think what the Cosmos Validators League, if that's what it's called, or maybe it's
just called Cosmos Validators now.
I think it changes this Cosmos Validators now.
Yeah.
So I think what they're trying to do that has some merit.
I think that the way validators are presented to the public needs to be improved specifically
like when you go to any of the major staking platforms, they're just ranked by power, right?
And inherently because of conditioning of other things, when users come and they see
a list and they're uneducated about validating or how proof of stake works, they think bigger
is better and I want to be on the big boat because it's got less chance of sinking and
my funds are more safe.
Whereas that's wholly not the case.
Most validators sound throughout most of the Cosmos.
There's a small percentage that get jailed occasionally, right?
So as far as getting your funds slashed, it's a reasonably low risk across the board.
And like you say, there are so many validators that do so much for the networks they validate
on and that's not all of them.
Some don't do anything.
They just turn on their validator and sign blocks and that's fine as well because that's
the job.
People who add extra value are going above and beyond, right?
So the big question is how is it presented to the public and how do you get the public
to recognise the value from other people?
That's the hard part because the staking platform is like an intermediary between the user and
the network, right?
So you're introducing like a point where there can be manipulation for profit and any ranking
system is going to be subjective.
So I mean, you've got on-chain metrics which are not that subjective.
You can, you know, they're calculable.
But I mean, even if you use those, even you want to give certain things a certain weighting,
they can even be manipulated to improve the score of, you know, certain validators.
Like say if, for example, you put a high weight to providing ancillary services like RPCs,
LCDs, relaying that type of stuff, right?
Then those validators are going to get a higher score, right?
If you put a lower rate, they're going to get a lower score.
If you put a higher weight on voting, validators that vote will get a higher score against
others.
So everything you pick and choose and do in there is subjective and it's all manipulatable
to make certain validators look good and other validators look bad.
So if they do go down that route and if it does become a popular way of selecting validators,
they really need to be sure that what they're providing is something that is simple and
doesn't, it's not too like exclusionary to people who just want to sign blocks.
And yeah, I just think it's a very important thing to make sure that you get right.
Otherwise, you might as well just have the current system.
I think you make a lot of really good points.
To a certain extent, I kind of see what Crescent did it as the ideal situation.
Not exactly because what they do is if you use their platform to stake, they'll stake
with the top 11 and wants to get anything below that.
So that's not ideal.
That means there's just focusing simplization.
But the idea that if you stake through their platform, it kind of chooses from a variety
of validators and kind of weights them and stuff, such that effort can be put into other
areas rather than just marketing what you do.
I think it's a really compelling way of handling distribution.
And I think that the idea that going with the top 11 is the safest is actually a really
interesting idea because if you think about staking rewards, like let's take Juno, right
now, I think 90 or 100%, if you're slashed, you lose 0.01% of your staking rewards, right?
Or of your stake.
That means you're losing like an hour and a half of your stake.
So the fact that you're choosing someone so high up in order to be safe is you're saving
an hour in order to focus floating power higher.
And so it's this really weird dynamic that is kind of unexpected.
People talk about all these slashing, a downtem slashing, but the penalty for that is so low.
It's almost not even worth talking about.
Right.
That's what I think.
Sorry, just to cut in.
So Sunny's actually joined us here.
I'll bring him up here.
Yeah.
Sunny, we're talking about some other stuff, but we will introduce you and get going on
with the show.
But I think it's still pretty interesting to continue on with here.
So welcome, Sunny.
Hey, Sunny.
I've not thought about that.
You are really, really quiet, man.
Can barely hear you.
Yeah, see if you can bump it up.
Is this better?
Test, test.
Yeah, a little bit higher.
Higher, higher, higher, higher, higher.
Perfect.
Okay, good.
Cool.
Okay, there you go.
Perfect.
Yeah.
Yeah, cool.
Sorry, I'm late.
I took a nap and then lost track of time by accident.
But sorry about that.
You guys are talking about valid or decentralization?
Yeah.
So everybody, this is Sunny.
Sunny's from Osmosis.
We'll get an introduction, a self-introduction from him a little bit later on.
We'll just continue the conversation we were having from Shilty.
And Sunny, the way this format works is we just sit here and talk shit until we get sick
of talking shit.
So if you want to jump in and you've got any good insight or comments about what we're
talking about, then just jump in and have at it.
So, yep.
All right, Shilty, continue.
I mean, I think that was basically what I had to say is that downtime slashing is almost
irrelevant in the greater scope of staking rewards.
So trying to focus your stake higher up in order because it's so much safer.
It's kind of not fallacy, but it's kind of misguided.
One thing I think that would, you know, a proposal that we had very, like a while ago
in Osmos, I don't know if it ever got finished to be implemented, but like the slash should
really be proportional to the size of the validator or the amount of nodes, like power
that's offline.
So if you are like delegated to a 10% validator versus a 1% validator and that 10% validator
goes offline, then really that slash should be like 10x more than if you were delegated
to a 1% validator that went offline.
So I think that kind of will help smooth it out so that way, you know, not just the amount
gets is more, but it's like, you know, kind of like a square kind of thing almost like.
Yeah.
And these are the ideas.
No, I was going to say these are ideas that, like, that's a great idea.
Like there's a lot of these types of things where you can make some either governance change
or other types of things to drive specific behavior.
So what we were talking about today before you joined was there's a kind of a group called
Validator Commons that we've been talking to a little bit and like, I think Jake's been
on there and Chelsea and I were on there today a little bit just kind of understanding with
kind of what the goals are there.
And you have great validators and like, of course, Juan and Steakfish and those types
of things.
And then you have this, we were just talking about the Cosmos Validators Discord group,
which is from Fiborg and Whispernodes really driving and just having kind of more conversations
there.
That's a little bit more grassroots from like validators just talking about other validators
and things like that.
But I think the goal is, and what we were saying before is what a Null's concerns was, like
if you start building ranking on things that are very qualitative, right?
And what you said like Null is like, how do you weight like these different contributions
to the ecosystem?
You just get into another bad ranking system, right?
And then you also have another UX issue, like one of the goals of these teams was to
say, all right, so if we don't do ranking, what we could do is just be able to provide
more data to the delegator to make proper decisions around what value has been applied,
right?
But if I think about that, and if you have a hundred and I forget what is an osmosis, right,
150 or 135 validators, and if I have an Excel spreadsheet of 135, and that's how many rows
are, and if I look at 12 columns across, because everyone's talking about RPC nodes
and what projects they've done, and I did a pull request on a doc site one time, then
you have this information overload where you can't really build UX around that to help
people make decisions anyway, right?
So there's problems on both sides of this, which is there's a lot of, it's difficult
to bring and kind of build a non-ranking system, but there's also so much information
to provide that a delegator who's trying to make a decision might not, you know, you
can't absorb all that might not care to absorb all that anyway.
So things like that were like that slashing concern, it's 10x or, you know, we've been
talking about other ways of saying, is there a top limit on how much percentage or voting
power a validator can get?
And beyond that, you can't bond to them or other types of things to try to say, I want
to try to avoid crazy spikes, which I know like, I know on the liquid staking side,
I don't know if you guys, if that, if when you guys enabled liquid, did it, did it change
dramatically the kind of the curve associated to the validator kind of distribution curve
or did it not make that big of a deal?
I don't think the superfluid really had a big impact as far as I can tell.
I guess one thing that made superfluid a little bit different is like, just because of some
time reasons we made it so you can only superfluid delegate to one validator instead of like
to multiple at once.
Yeah, I said no, if that would, if that, if that looking back would have said, if I
have only one to choose, I'm going to choose somebody in the top 10, right?
I'm not going to, I'm not going to put all these eggs into number 98 on the list because
there's this idea that quote unquote less secure, like that risk or, you know, what's
all these other types of things that come up with that, which is not really true.
Instead of ranking, so one of the things that we actually want to do on Osmosis to like
kind of change a little bit of how the UX of staking works is currently it's very annoying
that like every time you want to like redelegate your awards or something, you have to go
like manually go to every single validator say, okay, I want to delegate, you know, 50
Osmo here, 20 here, 30 here, whatever.
And that's like very annoying process.
What, what instead what we want is actually, we want to like have this thing called validator
set preferences where on chain, you basically say, Hey, I want to do 50% King nodes, 25%
lavender five, 25% rhino or something, right?
And then it'll be like, and then I just click one button every time I want to delegate my
rewards, it's a click delegate and it will automatically do it to that distribution.
And then I think once you have that kind of thing, then you can have these like sort of
like, I don't know, validator like suggestion, like groups, right, where we can be like,
Oh, here's a, here's a bunch of validators that run relays.
You know, here's a proposed, you know, you can say you click that and it'll import that
as your validator set preference.
So you can be like, here's a bunch of, you know, geo, graphically distributed validators
and you click that and it'll import them as your preference kind of thing.
So I was talking with Jake about this, like on chain stuff, right?
So I think like the best thing is to be able to control this would be like protocol level
controls, right?
Because anything that you introduce outside of the network that is then controlled by
someone else, right, and it's a central point of failure that can be manipulated.
So I like, I like that as a, as a way to select your, your validator sunny, but like that
would in my mind be able to be implemented at a network level as well, it'd probably
be difficult and it would involve things like, you know, maybe people have to as a multi
sig or as a group vote on which validators provide what services, etc.
So another thought that I had was, and this, this has been talked about in various ways
before in terms of like limitation of the amount of stake that a single validator can
get because I don't necessarily mind that a validator get more stake, right?
So that's, that's not a problem to me.
Like if you look at OA on evMOS, right?
I was probably a little bit ahead of my understanding when I was like giving them a hard time on
Twitter, but they are one of the biggest, well, not, they're not a company, but they're
one of the biggest entities doing anything on evMOS, right?
And they're probably providing the bulk of value to evMOS and they probably deserve to
have a lot of the stake in evMOS, right, to support their business.
So I don't necessarily have a problem with that.
The problem is, is the, the security in the chain and it's not just, it's voting, but
it's more so, you know, if validators get too much weight and they fall over, then it
can halt the network, right?
So that's the real problem in my sense is the fact that say at the moment there's, on
some networks, it will only take the top two validators to fall over and then the network
stops, right?
On evMOS, it's the top four or five.
So say if coincidentally they were all in the same data center and something happened
to that, right?
Then the network shuts off and that's it.
So an idea we had was that if you could find a way to make sure that the stakes distributed,
but still provide like an allowance for people who market themselves and provide extra value,
like incentivize good behaviors and value building, then that's a good avenue to go
through as well.
So for example, we thought that say if you take the total available stake and divided
it by the amount of validators, right?
It's not fair to say that every validator gets the same amount of stake, but you could
then apply like a multiplier, which could be a parameter on the, on the network that,
you know, the maximum amount that any validator can have more than any other validator.
So you say you've got a multiplier by six and you say they can have six times more
stake than what anyone else can have.
And then that way you still might get more power at the top, you know, there will be
a curve where maybe the top 40 validators have more power than the rest of the network
rather than the top four.
So, but there's so much stuff that comes along with that, like, you know, what happens
when people try to stake over that amount or how do you control that and all that various
stuff.
But that was some ideas we were thinking about.
Does anyone have like any comments on that type of implementation on a way to control
it rather than like an external body doing the control for you?
I'm not kind of like the idea, it kind of falls within the idea of, you know, CEO should
only make, let's say 100 times how much their, their lowest level of employees should make.
You know, you've heard that thrown around all over the place.
That's kind of the idea of what you're saying, right?
Is that everyone starts at this multiplier of one and it's acceptable for the top person
to be at a little bit higher of a multiplier.
Well, well, not necessarily everyone starts with yes.
So basically, if you set a multiplier of six, right, then that is the maximum they can have.
So say, if you divided, I think I did some quick maths and said, like, if you've got
a hundred available tokens and you divided them by 135 and had a multiplier of six, then
like, you know, for the example, the top validator can't have more than three or 4% of the network
weight.
And if, so I thought about some ideas about what might happen if they did, like, you know,
for example, instead of limiting the delegation, you might limit the amount of rewards that
a single validator can, can get.
And any rewards over that might get diverted to the community pool.
And so their delegators will get like a lower amount of relative rewards compared to people
who aren't over the limit, or you could just redistribute it to the excess rewards to the
rest of the set, or you could just directly stop people from being able to delegate above
a certain amount.
And you know, there's other things like what happens if the set expands or contracts, you
know, you then have to impose those same rules against those.
Say if the valid, if the set expands right, then the percent would reduce.
So then you would have to still impose those penalties, even though people didn't, I mean,
directly go on stake above their limit.
That'd be a good thing though, right?
Because then you'd immediately incentivize those that are staking with the high people
to then go out of the new newcomers, right?
So then it would kind of level out that, that voting power and that security almost immediately.
Yeah, exactly.
So people, you know, they'd say immediately realize that they're getting like a lower
percentage of the rewards and then they'd go and distribute their stake down to some
other validators.
Yeah.
So that was just me musing, you know, while I was taking a crap.
But I imagine something along those lines could work.
And to me, that's like a more robust system than relying on other people to make subjective
decisions on people's value.
Yeah.
I'm, go ahead.
No, I was going to say, I do think, aside from secret points, in the chat as well, he
said capping profits is really not a good idea.
And I do agree with that because I think the one challenge with delegators, maybe, you know,
who knows what UI that they're actually looking at that shows in that data.
So we might have something on Minscan that says, hey, you know, or I don't know, on Kepler
that says, hey, when you delegate here, your rewards might be lower because of XYZ.
But there's nothing saying that the Cosmo Station wallet would do that or, you know,
paying or there's so many ways to stake that.
So you can get in a situation where a delegator is just picking a name out of a hat and then
they're getting lower rewards and they don't know why.
Right.
And so because you don't have not every UI is being able to show that.
So that I think that's, that's a bit unfair.
Now blocking the transaction and the transaction fails and you have an error message there
and then that's a little bit more actionable, right?
They can do something about that.
But I agree.
I think, you know, the, I don't know, it's such a tough problem because you also want
to leave it as a free market, right?
You want to be able to, you want to be able to say, hey, this is, you know, there's, who
says it's 4% and could it be 5% of the VP or is it 8% or like, is it, is it mattered
by chain, right?
And there's so many, there's so many decisions related to that that would, that even a decision
on chain A might not make a difference or it might not be the same as on a different
project, right, because of, you know, specific reasons.
Sonny, I have a question for you as, as a, you know, we, I don't think we asked other,
I don't think we've asked other project, I don't know what your title is, but as project
leadership, let's say, or somebody who is heavily invested, right?
But so this, this idea of, of like delegation spread, right, in the, in the curve of, of,
of VP and those types of things, how much of a concern is that to the osmosis ecosystem
as from a project perspective?
Is it something that, why is it a concern?
And like, like specifically, like, like, and, and, and I think the biggest question for
me is, what does a perfect distribution look like?
Like what would you, if you get to say, all right, we get to lay it all out and we think
this is what we, what we think is be the best thing for the project long term.
Do you guys have a, do you have a definition of what that would be?
Like is, what does that look like?
You want me?
Yeah.
I think that like the, you know, I don't think necessarily a perfectly even distribution
is what's like needed, right?
You want the values, certain values to be able to have more because if they're, you
know, contributing more to that network, they should be able to, that should be represented
somehow.
But I think what, you know, the biggest risk factors is just like, you know, I think, like,
like you mentioned, like who gets, like how, how many validators have to go down for the
chain to be able to like be paused or something, especially around upgrade times.
That's when it gets kind of annoying when there's like, when you sometimes have like
very large validators with a lot of voting power, but there's, you know, they're just
consistently the ones that are MIA when you need them and stuff.
And so like that's sort of a problem and like being able to make sure that like we don't
have those like points of failures on just a handful of validators is important.
The yeah.
Yeah.
So I think like, I mean, here's actually another one mechanism you could use.
This is actually something Polkadot came up with early on.
I don't know if they actually did it or not.
I haven't looked at it, but I remember they had this early idea of like, you, everyone
selects the validators that they are okay with delegating to like you, here's a list
of like all, you know, 20 validators that I are on my trust list.
And then it will automatically shuffle stake around to be maximally decentralized with
everyone, it'll take into account everyone's preferences and try to calculate a result
that will be like, okay, here's a way that we can put everyone's only delegating to
validators that they are okay with, but then it's still maximizing like, you know, how
trying to make it as equal as possible.
Wow.
That's interesting.
That's totally speaking my language.
Approval voting is my favorite voting form.
So if you're already reading that, that's the way I want to do it.
So do you guys worry about it from a governance perspective?
I mean, the opposite side of the, the obvious perspective is probably actually the thing
we worry the most about is, but I think for that, we just need to make it so people can
like, you know, you shouldn't be having your validators take over all of people's votes.
Like it's, and even like if they do take over some of it, I think what it should do is like,
you know, maybe like 25% of your vote gets given to the validator can use 25% of your
voting power, but then if you come vote, you use 100%.
So that way there's even still an incentive to, even if you agree with the way that your
validator voted, you, the still then like, you should still go vote yourself as well,
because that way you could use the full 100% of the voting power.
See, now you're speaking my language because that's one of the areas that I've always had
really just, I don't know, it's like the validator power trip, I think in some areas.
But this idea that I get to vote non-voting shares at 100% always seems to be, honestly,
in my eyes, it just never made sense to me.
Like I think voting at a lesser percent, that makes that makes total sense or some sort
of balance there because I think my delegators vote is as important as my viewpoint on it.
And so I'm glad that when we both vote, we're both equal, but if they don't vote and I vote
100% of their shares, that always seemed like a little bit of a, I don't know.
Yeah.
I think somebody who votes has more, should have more weight than my opinion on somebody
who's not voting.
So, you guys mentioned, worried about having this stuff happen at outside the protocol,
I guess.
So I mean, one of the things, for some of this stuff, for example, being able to delegate
your vote to other people other than your validator, right?
This is something we've wanted to do in the governance module forever, but it's just
something that we, on our priority stack, just hasn't been able to get that high up.
And but now with like, actually off the Z, you can actually do a lot of this stuff off
chain.
And I was talking to Tom from EcoStake and like, you know, so he builds restake.app.
And he was, you know, he was just like brainstorming like, oh, what are other cool things you could
do with it?
One of them was like, hey, should he build a thing where like you can, let's say you
want to delegate your voting power, your governance to someone who's not a validator or not your
validator, you should be able to like, can I just give off Z access of my governance thing
and they could build a service that does that.
So do you guys think it's like dangerous to put this kind of stuff in these like, you
know, let someone like restake.app build this as sort of like a centralized service that
you makes use of off Z kind of stuff.
Or do you think that it's like, it is very important to have this like natively on chain.
No, you're like, all Z is still in my opinion on chain and auditable, right?
So if you have, yeah, so if if restake.app included some sort of, you know, governance
or that you could delegate someone to do your governance for you, right?
Or say there's like, you know, this multi-sig that's super wrinkled brain and everyone
wanted to give them their vote because they always make good decisions, right?
There could be another platform that audits that they could have like, you know, something
that's an interface where it picks up the vote and what was done through off Z and verifies
like it's just just listed says they voted this and this is the wallets that were voted
and this is the vote percent or something like that.
So I mean, if it is on chain, it is auditable, right?
So whilst it might be through a centralized web interface, it's still on chain effectively
and you're still making those transactions to give that authorization on chain.
So that, yeah, in my opinion, it's still on chain, not off chain, but yeah, I mean, everything
is accessed.
There's probably 98 to 99% of transactions on chain are accessed through a GUI that's
developed by someone.
It's not like, you know, Tom and Terry, Pharma doesn't come in and buy Osmosis on the CLI
and then do some voting.
So yeah, I guess everything, you know, unless you're a validator or a developer, you're
probably not going to use the CLI to do anything.
So every other avenue into the blockchain is through a third party bill tool of some
description.
I guess any of the use case there would be that you might have governance groups that
form.
It's almost like a DAO at that point, right?
You're almost getting to the point where you're, I'm off seeing my vote to some sort
of group or individual that says, hey, the way this person is going to vote or this group
is going to vote, I want to vote, right?
So we have similar ideals and those types of things.
So which I guess somewhat happens today on the validator side, but maybe not quite, right?
It's kind of the idea that's what's supposed to happen on the validator side.
I think other use cases for Authy, I think are great.
I think that I always feel that anything that encourages voters to get involved is and make
their own decisions and vote is obviously better than trying to either Authy that out
or letting a validator vote their shares.
But if that means that you have more involvement and people are more active around picking
groups or individuals that they're providing that responsibility to, then maybe that's
a good thing.
I mean, yeah.
Ultimately, it is a little bit difficult.
If you concentrate any amount of vote into any one hand, right, then that hand can then
be bribed or have their nails pulled out or anything like that.
So I suppose, for example, and Jacob would completely agree with me on this if he was
here, one of the big problems with having a concentrated governance vote is being able
to rob the community pool.
There is a big incentive to be able to rob the community pool, right?
So if you've got the voting power in the hands of two or three entities, it's not beyond
belief that if that's a high value community pool that someone could just go to their house
and hold their family at gunpoint and pull their fingernails out and make them vote the
way they want to vote, right?
It's not even necessarily that they might be a bad actor.
It's that there is enough vote there to do meaningful damage one way or another.
So it's the same if you delegate that vote to John and John lives in Kansas and he's
like doxxed, then someone can just go around the John's place and make John vote the way
they want John to vote.
So I think any concentration of voting power anywhere is dangerous to me.
No matter where you are.
I think that your point is apt, but I think that you're kind of, I would say you're missing
the force of trees a little bit.
You're talking about like violence getting to people and stuff, and I think that's true,
but I think that just a social aspect of this is really simple.
If you have the vote spread across 100 people, you have to convince 100 entities.
You have to convince 100 entities to vote a certain way, right?
If you have three people, you can just mention them in DMs and say, hey, this is my project.
It's pretty cool.
And just being friendly, that's very convincing to people, right?
So just sending a DM would be enough to sway their vote whenever before they were going
to vote.
So yes, there's the violent aspect, but it's so much simpler than that.
And I think that's kind of the scariest part to me.
Yeah.
So I guess my example was probably a bit of an extreme in that, you know, I guess the
point of that was that it would make the whole of the community pool more vulnerable than
if it was distributed.
But definitely there is the social point of view.
And I get people in my DMs trying to convince me of stuff when there is votes on things.
I just say, look, don't DM me because ultimately I'm going to do my research and vote the way
I want anyway.
So you DM me in me is not an influence.
So just stop.
But I imagine you'd get the same thing, Sonny, like with governance proposal.
I imagine that before people put governance proposals up, you get a lot of people, you
know, trying to talk to you about them and stuff like that.
So.
But yeah, so you surfer, we had plenty to talk about other things this week, right?
I think we've kind of talked about this a fair bit now.
I think we all agree that, you know, there are some issues that need to be sort of like
looked at in a serious way.
But I think the way forward is not really clear to anyone yet.
Probably requires a lot more discourse and discussion throughout various discords and
Twitter and whatever else.
So I mean, I'm hopeful that we find a decent way to move forward with that.
It doesn't penalise people for being active and providing extra value.
But also like at least tries to distribute the weight in the like the stake weight.
So I did actually bring up just there before was a graph from Blockpane's website that
just shows the locations of validators.
So I'm just going to pull it up again because I think this is quite interesting.
I don't know how many people are aware that this exists.
But this is Osmosis.
So I mean, there are so many different things that can happen with the Internet, right?
So this is Hetzner.
Hetzner holds a lot of the validators for Osmosis.
So if something catastrophic happened to the Hetzner system, I'm almost certain that Osmosis
would cease to function until they sorted that out.
And if you look at any of these locations over here like Germany and the US, you know,
if there was something catastrophic that happened to the Internet at either of those locations,
then I'm almost certain that it would stop working.
To be fair, this is not validators.
This is all nodes, right?
So like this is all nodes that are participating.
So it's not a validator specific thing.
I think it's all nodes.
So but still, I mean, I'm guessing it'd probably be in a similar ratio.
And we'll put a link to the show notes for people can check that out.
Yeah, that is a good point.
So you said let's talk about more pointed Osmosis things.
All right.
Do you want to lead us through that?
Yeah, Sunny, do you want to introduce yourself?
Yeah, sure.
Now that was 46 minutes in.
Sure.
Yeah.
Hey guys, my name is Sunny.
I'm one of the co-founders of Osmosis.
I've been working in Cosmos for about five years now.
I started in summer of 2017 as an intern at the company previously known as AIB and then
Tendermint and then Ignite and then now something else.
I don't know what it is anymore.
But yeah, so I've been working on Cosmos SDK and IBC and Tendermint for a long time.
Kind of built out a lot of the tooling, these core tools.
And once all of them were ready, we were like, well, let's try to build an actual application
with them.
And that's kind of started working on Osmosis as sort of the first obvious thing to build.
Yeah.
I think one of the things that we were slightly talking about before was like this role of
governance and taking action, those types of things.
And this podcast, we've talked a lot about Juno Prop 16 and actually making a meetable
change to something that occurred.
And then what I was going to say, what Null just said around, look, these groups and these
validator conversations and this governance conversation will continue.
And I hope it continues quickly because this is the time to do it when there's not like
an emergency in front of you, right?
Where you don't really have a bill of rights or a group or some things, like some specific
rules that I think there's agreed upon, there's validators or chain operators, et cetera.
So you guys, we just had a halt.
We saw each other in consensus.
And like that night before, we saw the war room pictures and like all the things that
were going on.
And I think you guys were also, if I remember correctly, there's four counts.
I think we talked about this before, four counts that were kind of larger numbers and
two of them came forward and there's another two.
And was there some talk about making a change, state change or anything else associated that?
Or that, did every guys, do you guys even talk about that and saying, what do we want
to do about this or not really in that sense?
Not really.
I mean, I think for us, we kind of highly valued the immutability of the chain.
I mean, I guess we were, there was some talk, I guess, about potentially like freezing accounts
that not like seizing assets from the accounts, but just making it so those accounts couldn't
transfer and then like letting governance figure out what it wants to do or at least giving
them.
But it's just got very messy for us because like it was unclear to us like, by what authority
do we as the dev team get to decide to freeze these accounts?
And a couple options that we were floating around was potentially just restarting the
chain with only governance enabled and all other functionality is disabled.
And then governance can figure out what it wants to do from there.
Other options were we put out multiple copies of the code, one that has account frozen, one
that doesn't, and then we just let validers decide which version of the code they want
to run and we don't make any recommendations.
In the end, yeah.
What are you talking about with four accounts, four big accounts, what happened there?
So yes, maybe I need some background.
Yeah, sorry.
Yeah.
So, you know, there was a bug on the V9 upgrade of Osmosis that basically allowed LP, every
time you join a pool, it gave you more LP shares than you were supposed to have.
Oh, we're talking an overtaking.
Yeah.
And a handful of accounts, more than four, those are actually like six or seven that
exploited the bug where they would add, withdraw, add again, withdraw and basically cycle that
and get a lot of assets out.
A lot of the funds had actually been fully returned.
But yeah, so I don't know, I guess, yeah, I mean, we like floated the idea, but I think
what we were realizing was it's like, you know, at the amount that was lost, which was
like, you know, about $5.5 million, I think we valued the immutability of the chain higher
and we were like, we would rather actually the foundation cover that full cost than like
go make irregular state changes to the chain.
That's also, but that's also kind of a, there's some timing that worked out in that favor
as well, right, because this is last week and where we are from in this winter that
we're living in, it's equipped to win or it was so bad that even Nell had to put a
coat on for this, for this call.
That's how cold it is here.
So but if we were not in that situation, right, and we were 10x where we are, would that decision
change?
I think it's a big, yeah, I mean, if it was 10x where we are, I don't think the, the
foundation would not be able to, there's an amount that the foundation has a treasury
of that it can cover.
The other thing though as well is it's also, I think it's more important as a percentage
of the network of the liquidity, right?
Like, you know, the hack was, you know, it's high, but realistically it was actually less
than like 2.5% of the TVL of osmosis.
And so is doing in a regular, I don't think it, at any point, I don't think it's a good
idea to do that.
But I think it was like an existential, like, threat to osmosis.
Right.
If it was like, you know, if we're talking it was like 50%, 75% of osmosis is TVL.
Then yeah, I think, you know, at that point, there's like an existential threat to osmosis
that maybe then does justify more drastic action.
Yeah.
Well, and I think that in that, like there's some, so there's some, there's some decisioning
there, right?
And so now, like that helps you look back.
I think as we talk to these governance type of things, like, like, what would be that
percentage?
Like, where does it become, where does it become a threat where we would, you know, kind of
stuff that it's, it's always interesting to have like a viewpoint and some kind of guidelines
around this.
But there's at some point, I think all those guidelines sometimes go out the window, right?
Because there's just so much of a threat that needs to happen.
So I know, I know you went through a bit, a bit of a root cause at OsmoCon.
There's a YouTube video of that up and you kind of talked a little bit around that.
So you guys published like a, like an in-depth root cause analysis of what actually failed.
And I think the follow up to that is like, what can validators do?
You know, like, like how we talked about, I think also back on the Juno issue with Prop
20 when there was a mistake on the burn address or not the burn address, but the transfer
address in the contract and like how do, how does, how do we build like better processes
for making sure that those types of things don't happen?
Right.
So we'll do a proper like, we're still working on like a full bug report that kind of explains
like, Hey, here's exactly what went wrong.
I mean, it was kind of simple.
It was what was happening was when you, when you do an ad liquidity, basically it does,
it does what it does is it takes, you know, you have two assets, but they're not exactly
at the same ratio as the spot price of the pool.
So what it would do is it would do two steps.
It would first take 50%, you know, it would match the even amount based off of the smaller
asset and then it would take the excess and then do a trade against the pool to like get
it to a 50-50 and then add the rest in.
And just in that calculation, we double counted the larger side basically.
And so that's what caused it to have slightly more, that's what caused it to give out 50%
more LP shares.
This was, you know, I mean, I, I mean, there's the bug itself, but I think what's more important
is like how, why the bug got in.
I think that there's like a lot of, you know, I think part of it was like, I mean, I'll
admit that I think our team was rushing quite a bit in the last like one month ever since
like the terror collapse.
Basically there's been this like, on like new slew of like developers coming on to
Osmosis and we were kind of, you know, the, we kind of rushed this v9 upgrade because
we wanted to get the token factory module in so that way these developers could start
doing stuff with it.
And I think we, so we didn't go through like the normal testing processes we normally do
or like we, you know, we never, we didn't connect the front end to the test map in the
way, right?
How we, how we normally would.
Right.
And so yeah, there's all these sort of things that like, you know, we kind of get into properly
and then in general, I think the biggest thing that that's important going forward though
is like making sure these, we have more better documentation and like understandability of
the code.
Like I think right now, you know, there's the Linus Torval code about like giving enough
eyes all bugs are shallow and like right now it's hard to get more eyes on the code just
because it is sort of not as well documented as we would like.
There, and so we try one thing we did with the validators on the v10 upgrade was we kind
of like offer, we did a zoom call where we walked through like, Hey, here's all the changes,
here's the bug, here's all the changes that we're making as part of this upgrade.
And that's like really helpful because like it just gives more people are able to ask
questions, the one of the validators who used to be an auditor, he was like providing some
feedback of like, Hey, I think you can improve your like the way you do like the tests here
and stuff.
So that was really helpful.
And this in general, like I think having better code comments and stuff is like, so when other
people are doing code reviews, when we're emerging PRs, I think that's like, you know,
without these like comments and stuff that's hard to do proper code reviews.
So basically, we're doing a couple of sprints right now where we're not like working on
new features or anything, we're just like spending the next couple sprints just on improving
our docs and comments and test coverage and stuff.
So sunny, just on like testing and and code commenting, right?
And I mean, unless you're like a bit of a gun on go, it's basically unreadable to anyone.
So like, I, I started to learn coding like back when I was before uni, right?
And when they were teaching me, like, they used to teach that, you know, without comments,
you know, things are very hard to come back and look at later on ends, and you know, structuring
code and all that type of stuff.
Do you think that nowadays, that's not really that prevalent that people are looking at
their code from the point of view of other people being able to read it later and being
able to work on it later and commenting and and providing like context for other modules
and stuff that interacts with and that type of stuff?
I mean, it's not like we're not doing it.
I think we could definitely be doing a better job at it.
Yeah.
And some of the modules that we've written, you know, I think it'll be very difficult
for someone else to come pick it up and like start.
It's very difficult.
And part of it is, I think the Cosmos SDK has a lot of room for improvement on just
like, this is so much boilerplate code in the Cosmos SDK that makes it very hard to
like review things and like follow along with what's going on.
Like removing a lot of that boilerplate, I think is like a big sort of design goal for
that for the Cosmos SDK.
So could you maybe just walk us through a little bit about the design process that is
Osmosis because you guys are obviously all in the same, well, mostly probably all in
the same area and and work out of a location, right?
Do you know where we're like fully geo distributed across everywhere?
So do you guys do like, do you develop like pseudo code and flows and stuff before you
actually start coding?
Like is there a process about how you look at what you want to do and then, you know,
modularize it and do various bits and pieces and organize it before you start coding?
I mean, you guys just straight into it and then debug.
Well, usually try to write a spec, like be like, okay, here's the general messages that
we want the but it's definitely not as low level as a, you know, definitely nowhere close
to like pseudo code and like here's what what we'll be doing.
It's more of like sort of interface design first and then going and implementing stuff.
So, you know, these are things that we're going to be trying to improve on and like
oftentimes like, yeah, I think there was, I think we've just been putting a lot of emphasis
on like velocity and just like speed of getting things shipped.
And I think that we need to like it a little bit slower on that and like make sure we're
spending that like ideally we want all these like workflow and everything but like we just
didn't have them because of that, you know, we were trying to get stuff out faster basically.
So correct me if I'm wrong, but the upgrade that had this issue, there was quite a big
ray factor that went on in that module.
Yeah.
So that was sort of a generalization of the AMM module where currently earlier version
of the AMM module, like it was only for like the current balancer style AMMs, but then
we basically made an interface for AMM so that way we can add other pool types like
the stable swap and things like that.
So that's sort of why.
Yeah, so then we actually removed the stable swap code from the upgrade because we realized
that we didn't have enough time to like test it properly.
But we didn't, we kept the actual refactor itself of the AMM when that wasn't really
the main part of the thing was like that wasn't really the main focus of this upgrade.
We had spent like, which is why we, you know, the main thing was the token factory and stuff
and that's what we had spent a lot of time testing.
And then even within the refactor, like we made big changes to how single-sided liquidity
adding works.
And so we had a lot of tests written for that, but not for like the very simple things which
we thought like, hey, you know, we did actually change the functionality here.
Right.
Yeah.
Okay.
So going forward, like especially on big refactors and added like functionality, do you guys plan
to like have a gateway process where, you know, you have to meet certain criteria before
you're going to push things to the main net?
Like, you know, for example, going to your test net, getting, you know, a certain amount
of volume of testing on certain functionality before you even think about pushing it to
a main net rather than reducing the YOLO approach a little bit.
Yeah.
We're definitely going to have like more, you know, have the test net running for longer.
Like I think this time the test net was running for like a day or two before we did the upgrade.
And like I said, we didn't connect the front end to it.
So it's kind of hard to, it was hard for me to really test against it.
On top of that, yeah, you know, just working like thinking about like new like test, testing
models to make sure things are tested.
You know, one of our advisors was telling us about this, like thing called mutation
testing where what it does is it like modifies your code and checks to make sure that tests
should break if it modifies your code.
And so that's like a way of testing to make sure your test frame, your test, your, your
test actually had enough coverage.
Yeah.
Because it would be quite difficult to build like a test suite to automatically test like
all the, all the different scenarios in, in like these networks and it'd be really hard
and it would break every time you like made an upgrade.
One thing that we kind of, a tool that's like in our toolkit that we kind of have, you know,
haven't used because basically I think the SDK needs to like go, we need to go like
improve it again, which is the simulator.
So the simulator basically allows you to like, you know, it'll automatically spam different
transactions and you can set invariants that will check that like, Hey, these are invariants
that should be broken.
We, you know, early, you know, early on we were using it pretty heavily, but then it
just became sort of like unwieldy and unmaintainable that we kind of like stopped using it.
And so I think we need to go spend time on like, like fixing the problems that we had
with the simulator so we can make it so we can start using it again.
A simulator is some.
Oh, we'll ask them.
I think that you would need to build.
You wouldn't be able to leave it.
You couldn't say you couldn't do a month of development and then go back and, you know,
if you really want your simulator to be robust, you would need to pretty much do it in parallel
with your code development, in my opinion.
Yeah.
Like, I mean, based on what we would do is make it so anytime PRs are merged, it has
to come with like, you know, the proper simulator changes as well.
Right.
Yeah.
Yeah, for sure.
So keep in mind, all this I'm talking, I'm not a coder.
I'm just, I'm only talking about what I know about.
So I'm going to sit back and see if Shilty or Yusuba have any more to say on that particular
subject.
I'm definitely a little curious.
I know, Sunny, you and the Osmosis team have gone a little bit flack for not having a test
coverage.
I'm curious what test coverage looks like in the blockchain space right now.
And if there's like, if there's any sort of like QA process that's normalized, if there's,
you know, like, I don't think I've ever seen a blockchain test engineer, right?
Is that just considered kind of uncommon at this point at this time in the, in the blockchain
ecosystem?
I'm not really sure like how other chains do it, but I mean, yeah, like, you know, like
I said, we're going to be adding like, you know, we're hiring someone to just do QA,
like in the sense that like, hey, you know, just playing around like with the test net
basically and like using the UI and like just trying to find bugs, not just on the chain
side, but also like on the front end side and make sure those bugs are like found before
they go to prod basically, like, you know, we did that big giant like front end refactor
and like, you know, it went pretty smoothly.
But like, you know, even once we pushed the prod, there was like all these like, you know,
got a lot of bug reports and stuff that we were able to fix.
But like having that stuff like be found before then is important.
Yeah, I'm not sure what like what the standards are on other chains, to be honest.
I mean, part of it is that like, you know, we we've been trying to move faster than like
other chains where, you know, things like Ethereum have these like really long development
life cycles where they like upgrade once, you know, a year at best and and I know they
spent a lot of time testing everything they have like months and months of test nets before
anything goes live.
So, you know, I think, yeah, we're probably gonna want to like slow down.
You know, I think we've done an almost we've been trying to aim for like one almost like
one upgrade every one and a half months.
And so we have to figure out how to like either slow that down or be like figure out how to
like, yeah, like just kind of like planning for like what goes into upgrades better.
And now that the functionality is growing, we'll talk, we can switch gears and talk a
little bit about the future as well.
But then functionality is going to keep growing.
So this idea of a growing regression test, test suite should absolutely needs to be there.
Right.
I mean, you know, you're gonna have these, these modules are not independent, right?
Now there's a lot more integration between modules and you're gonna have lending and
all these other types of things that we're talking about and they're gonna have integration
across the board where even the simple like you said in this one, this was like a, you
were testing new parts of that, of that, of that bonding, but not the very simple use cases,
right?
That's just a, that's just a, that's a regression test, right?
That's all that is.
And so now, I know that then then you that that's starting to be building into into those
release plans and everything else.
It's like turning into a big company, right?
So yeah.
All these growing paint type things.
But we were, we talked about this a few weeks ago too.
And when, I think when the, when Juno Prop 20 or 21 came around and we, I think of the
conversation with here is it, is it better to, to move fast and break things or is it
better to write and be able to fix things as they come?
Or is it better to, you know, have really long breaks in there where you're, you know,
doing months and months of testing?
And I think, I think every, every chain will find the balance between those two, right?
Like just depending on what you guys are doing and what's going on.
Yeah.
So switching gears, go ahead.
I'll say, please.
I was just saying, I think, well, I kind of kind of kind of relate to the, while you're
like the future stuff, but it's like, I think one thing, a nice thing with like the bear
market is like, you know, we can spend, we can move a little bit slower and like, I feel
and then they kind of relate to like future development as well in the sense that like,
there's also, there's all these like features that like we've wanted to build, but we know
these are like long timeframe things they take, they, they're going to take on the order
of like three to six months, but we had to, we kept prioritizing the one or two months
like faster wins instead of those like longer term things.
And but now we can go spend time on these like more long-term things.
Let's talk about this long-term things.
So you want to talk about like what's coming up next and, and some of the, some of the
plans and thoughts related to that.
I know these guys had some questions related to that too.
Yeah, sure.
So we have, you know, a couple of things coming up, you know, one, for example, is the threshold
encryption, right?
That's like a long-term thing that like, that was actually the original reason why Osmosis
was started was we wanted to build like privacy in the mempool so that way there's no front
running that could happen.
And so we designed this whole threshold encryption solution.
And then we've start build out pieces of it, but like it's just something we know is a
six month long project.
So we haven't been able to dedicate fully towards like, you know, making sure that's
like what we're shipping.
So that's one.
But then there's also like order books, definitely, you know, I think that passive AMMs are good
for the tail end and bootstrapping of new markets, which is what a lot of the Cosmos
ecosystem has been right now, but that as we bring in assets like ETH and WBTC and all
these like larger assets, you know, we need more cuts that are use of the liquidity than
like AMMs can provide and traditionally AMMs can provide.
So definitely going down like building an order book style system.
So look, and it's going to end up looking more like Unisop v3 more than like what your
people, that's like Unisop v3 is the right way to build on chain order books basically.
So that's kind of we're going to be building that out.
So describe, take a second to describe that that's you're basically creating a swap situation
between it's almost like a limit order, if I understand it correctly, right?
You're setting like a boundary to say I'm okay to swap as long as that it's within this
area, right?
So I'm not, is that, is that right?
Is that layman's version of that?
Yeah.
So what it is is, so how Unisop v3 works is when you put a you know, normal AMM you put
your liquidity, you're basically putting your liquidity on this like full range.
You can imagine like on, yeah, you're basically putting it full range where like you're saying
that, hey, your market making, no matter what the price goes to, you want to maintain some
ratio 50-50 ratio at all prices.
What the concentrated liquidity would say is, hey, you know, it's like, let's say this
is a pool for a stablecoin, stablecoin pair, right?
You know, we have our stable swap that should be coming much sooner, but like another way
you could do it is you can just say, hey, I'm going to put all my liquidity in this
tight band of between like 95 cents and a dollar five cents.
And that way, what will happen is if the, you're basically using all your liquidity
there that decreases the slippage in that bound, but if the price goes outside of that
band, you end up holding all of one of the assets.
So the less work.
And so this is actually, and what will usually happen is, you know, market makers will like,
you know, keep readjusting which bands they're providing liquidity over.
But if you want to be more passive, you can do that as well.
You can say, hey, I want to be a liquidity provider over a wider band or even full range
if you want.
One thing you could do though is you can, these things are kind, if you notice it's
kind of like a limit order where if, let's say the price is at $1, you have a band from
like $1, five cents or $1.10.
And then if the price goes up to $1.20, you end up holding all of the token at that $1.10
price.
But the price goes back through the other direction, you end up undoing that trade because, you
know, you're LP, you're making the market on both sides.
What you could do is if you wanted to, you could have it act more like a limit order
where you say, okay, once it passes through the tick one time, remove liquidity from that.
If you wanted to, you can have it automatically removed from that pool and that it acts like
a limit order basically.
And so it's nice because it basically is a way of building these like kind of limit
orders on top of an AMM.
Now the reason this is better than like a traditional order book is like, it's unclear
whether traditional order books can actually scale on blockchains, right?
Like even your centralized exchanges, though they're like clusters of GPUs at times of
peak throughput and they struggle to keep up, right?
And like on Solana, serum works at normal times, but unclear if it works at peak times.
You know, I mean, DYDX, you know, we saw that they just announced that they're coming to
class.
So, I mean, what they're doing though is to solve this, is they're actually not running
the order book on chain.
They're going to be running order books in the mem pools.
Every validator sort of has their own mem pool order book and then only settled trades
go on chain.
I think that actually probably will help solve a lot of the scalability problems.
I think that comes with a huge host of MEV problems.
But the concentrated liquidity design is how you, what it allows you to do is it allows
you to do bigger tick sizes.
So let's say instead of like 0.1 cent ticks, it will be 1 cent ticks, but because intra
tick there is built in slippage.
So it'll basically is a way of making on chain order books more scalable.
So with that, would you have been able to protect yourself in some fashion from the
Terra Luna drop if you had said it such that if Terra goes from $90 to $85, you exit automatically?
Is that a potential thing you could?
That would actually be a little bit different.
That would be more like a stop order, not a limit order.
A limit order would be worse because you would have, let's say you, let's say you were a
limit order in the, let's say there was a USDC, USD pool, or let's say there was the
USD Euro pool, right?
You might have been on a much tighter bound and you could have actually lost more because
you were, you concentrated your liquidity more there.
Stop orders are slightly different, which there is a team building them on Osmosis right
now called autonomy.
And I think stop orders will get better, especially when you can start to put them, you can put
them on chain with like threshold encryption.
The problem with putting them on chain directly right now is there's people are going to go
stop order, stop order hunting where, you know, they're going to see the kind of like
what's happening on the theorem right now with all these like liquidation hunting.
It's going to be like similar with like the stop orders as well.
Okay.
And what's, what's beyond that, Sonny?
What's next after that?
Oh, yeah.
Some other stuff, you know, more like better UX features around like wallet and custody
basically, like, you know, things where, you know, session keys, for example, where you
should have like different keys that all for the same account, but they have like different
capabilities to them, right?
Where, and like all sort of like using off Z, but you can be like, Hey, this key has the,
you know, it can be in the browser rather than in the wallet, but it like, it can do
trades but only up to like 5% of your net portfolio.
Otherwise, it, you know, requires a signature from the wallet and that way, so you don't
have to like pop out your ledger every time you want to do a single trade or something
like that.
So I think that UX experience is like really important.
There's also going to be things like, you know, like better look to smart wallet integrations
like social recovery style stuff.
So yeah, I think that that's one.
And then also just like new user flows basically, like currently, Osmosis is very much like
the centralized exchange experience, which is like, Hey, you come deposit assets, you
do your trade and then you withdraw.
Yes.
But we want the native, we want, we also want like the shape shift style experience, which
is like, Hey, I have ETH on Ethereum, I want Avax on Avalanche.
How do I do that in a single click?
Not have to do like all these multiple hops, especially if these users don't even have
Kepler or something installed, they, all they have is like Metamask.
So that's something we're working on with the Axlar team of building that out as sort
of like a full joint project product together.
So would that also be within the Cosmos?
Like could you?
It would be the same where like, Oh, look, you know, you have Juno on Juno and you want
stars on Stargaze.
So, you know, that should all just be a single click.
Me trying to explain the difference between Juno's native chain and Juno on Osmosis to
my brother-in-law is like, that's like a four day conversation, right?
Like I'm depositing it.
I'm depositing it.
Like even in the same thing with I think another thing you were talking about before
was on Ramp, which is going through the whole process of getting into Adam and then bringing
that in.
What does it mean to deposit and everything else?
Like that's, you have to get over, there's some real mental hurdles there to get over.
I think lowering those barriers, I think opens up a giant swath of population, right?
I think that one of the things kind of holding back the communication there is just how cheap
it is to IBC.
I was trying to explain what depositing was someone and they just thought, you know, change
wallets.
Well, if you're talking about depositing from like Ethereum to Avax, then we're talking
$10.
Now suddenly there's like an impact, right?
Right, right.
It's just really, and just weird like dissonance.
We've been spoiled by how good the UX of IBC is where it's like, oh, okay, you know, every
time you have to produce a bridge thing, it's like, oh, it's so cheap and fast.
It doesn't really matter.
Right.
And then it's like, well, we're trying to like deposit from Ethereum.
It's like, oh man, I have to wait 20 minutes and like,
I gotta think about this.
Yeah.
I really gotta be planful.
Am I moving this or not?
So I guess, yeah, like definitely with IBC coins, the web of IBC coins is like just going
to get more and more confusing to people.
We're like unwinding.
So we've talked about this before, Sunny, where IBC is very much a thing where you need
to go back and forth across the same bridge between chains.
Otherwise, it really starts to get like convoluted in terms of if you send an IBC, say from Juno
to, so you send a Juno from Juno chain to Osmosis chain and there you've got an IBC
Juno coin on Osmosis specific to that channel.
And then you send it to like the Cosmos through another channel on another relayer, then you
start to end up with the thing that you need to unwind at some point, which I think has
been avoided like 100% to this point through UI's only really being able to withdraw a deposit
back through those original chains.
But so with your plan of making like improving the user experience and being able to, for
example, one click have a Juno come from Juno chain to become a star on Stargazerite.
To me, that actually sounds like quite a complex operation.
And would that be the kind of thing that you'd want to achieve through like ICA or is that
something that would be a chain of events?
Because approving a chain of events like that, if you use a ledger would probably be an enormous
pain in the arse.
And even if you're just using Kepler, you'd be sitting there pressing the friggin button
like 10 times.
Yeah.
No, no, no.
So this would be the idea.
It would be a single transaction that you make and then it like sort of encodes the
rest of the actions in that initial transaction.
So it would be like you make your first transaction on Juno and the entire transaction execution
path is like there where it's like, okay, IBCD Osmosis swap for stars, take however
much stars you get out and send it to this address on Stargazerite.
So it'll be like a full end to end sort of thing.
So just so my chicken-fillip brain can understand this, right?
So would this be a process whereby you give your custody, you give your token custody to
like a smart contract or something that would undertake those actions or is this some sort
of module that can now do that?
This would just be all the client side where we would just, so what it would do is we would
create a new ICS, a new interchange standard, which is for this.
So your website or front end you're interacting with, it will just generate the entire transaction
and it will get you to sign it once and then it will do the rest of the action.
So this shouldn't require a Cosmoisome or anything like that.
Yeah, okay.
That's interesting.
I'd very much like to like.
So have you already written a spec for that or?
No, this is something that I think the...
So right now we're not starting with the IBC version, we're starting with the Axelar version
just because the Axelar team is sort of building out a lot of that actual swap system because
they actually have a lot of that sort of, a lot of the prerequisites for that already
built because that's how they do their deposit addresses already where how it works is like,
you know, Axelar has this feature where you can say, hey, I want to send coins to like
this Osmosis address, but then it will generate an address and you just send coins to it.
And what it does is it maps the address that you send to with the user flow, the action
that you want, which is send to Osmosis.
But what they're able to do then is they can map that address to something even more complicated,
which is like do a swap and then send to some destination address.
So we're going to be sort of piggybacking off of their infrastructure that they've built
right now for the Axelar thing.
And then after that, we'll have it work on like native IBC stuff as well.
Cool, man.
It sounds like a very difficult and complex project to undertake.
Yeah.
We're excited to be doing it.
I think the Axelar team has built the right infrastructure to make it possible.
Unless someone else wants to jump in, I had like a brief question you touched on earlier,
Sonny, about the, I can't remember the term used exactly, but like anonymity in the mempool
so that you can't be front run.
Is that to do with bots?
Yes.
So you're like introducing some improvements to be able to try and stop the bot front running
that's going on at the moment.
Yep.
Has there been much bot front?
Have you noticed bot front running on Osmosis?
I'm curious to see if anyone's doing it.
I've heard about it.
I've heard complaints about it draining pools.
But, you know, I'm not, I don't look into the transactions enough to be able to verify
anything myself, but I've certainly heard some people complain about it draining pools.
So, yeah.
So I think that there probably is people doing bot stuff on Osmosis.
Oh, sorry.
So I think like wherever there's an opportunity to do bot stuff, people will do bot stuff.
And that's just, you know, where there's an opportunity to profit from something people
will be out there trying to profit from it.
So yeah, wallet is, there he goes again.
Freaking Australia.
The internet froze over there, you know, I think so.
Like that's it.
I think he's back.
He's back.
In general, I think I'm happy, you know, I'm, I think I'm fine for people to start running
these bots and stuff right now because, you know, we shouldn't rely on the altruism of
people to solve it, you know, we need to fix the stuff at the protocol layer through things
like threshold encryption.
And, you know, I think in a funny way, it might be good for people to do some front
running on Osmosis.
So that way, once we solve it with threshold encryption, people like the solution where,
you know, there's no pain, there's no point of pain killers.
So, you know, we need to show people that okay, this MEV issue is actually a big issue.
And then look, here's the solution.
Here's the name of the episode, usurper, pain killers for bot stuff.
Right.
The other thing that's kind of funny is I think it's a delay or something else, but
when you, when you say bot stuff, it sounds like butt stuff.
And so that's even, that's even, it's a little bit of accident there.
So pain killers for bot stuff might be, I don't know, we make it flag for that one,
though.
Now you may not have been on purpose.
All right.
Should we wrap up?
Yeah, so we're getting real close to where we want to be.
So, yeah, let's, let's wrap up, you sir, but you're good at this.
Well, is there, maybe we could do a, what are you guys excited about?
So one thing we kind of wrap up with is a simple question, like, what are you excited
about in the Cosmos ecosystem this week?
Are there any coming up in the next, here between now and the next Wednesday or so?
I'm excited about the pixels on Osmosis.
Yeah, if you guys have seen that.
Yeah, we didn't talk about it.
While I'm on this chat, I'm also like on side drawing a little wasming tin on the
pixels as well, like every 30, waiting for the, every minute of just like making one
dot.
It's, it's addicting and kind of fun.
So yeah, you know, it's always kind of fun.
And also just saying, you know, it was supposed to be like, you know, I mean, what, it was
our birthday surprise for Osmosis.
So, you know, it was our one year anniversary.
So that was really, you know, just exciting to see how far we've come in the last year
and just excited to be going further.
Yep.
So firstly, I'm disappointed that we have to end this because I've still got just like
probably a list of stuff that I could sit here and keep asking.
So damn it.
But so my, my thing that I'm excited about this week is it'll be close to the heart of
80% of the validators out there and I don't know if it's going to be done in the next
week, but our friend BlockPain is building TenderDuty V2 and that was funded, I believe,
from an Osmosis grant and whatever it was, it wasn't enough.
Yeah.
This is probably the one tool that I think is commonly used just across so many validators
across so much of Osmosis.
And that's sorry, of Cosmos.
And we saw a preview yesterday.
Shilty, you said for myself would have seen our little snippet of a preview from it yesterday
and it's looking real nice and I'm excited for that.
Yeah.
Really cool.
Shilty?
Yeah.
So I'm in the InterChain's Developer Academy right now and tomorrow is the completion of
it.
And so the final exam starts, but I don't know.
I guess I'm just really excited I've been a part of it because I've been having a lot
of really great developer discussions with people and potentially going out for grant
work or...
What is the InterChain Developers Academy?
I'm actually not too familiar.
Yeah.
So the ICF is funding, I think there's 150 developers to go through this course.
Oh.
I think it's academy.cosmos.network and they just provide a step-by-step way of building
your own chain, running Cosmos and messing with CosmJS.
There's tests, there's dedicated teachers and can you have a question?
You can just ask a question and dedicate chats.
Really fantastic.
I really enjoy it.
And this isn't really for next week, but I'm just really excited to have been a part
of it.
It was a really great experience.
Nice.
Can you flunk it?
You can flunk it.
So the first two weeks.
Really?
Yes.
So there's two tests in the beginning and then there is a final exam.
I think the final exam is the only one you can flunk.
And the first two are more of gates for whether you actually are engaged in the academy or
not.
There's also a pre-test to get in so you actually have to have some developer experience to
be accepted.
Wow.
That's a great job.
You can.
And part of that is because they'll help you get a job.
Once you've actually graduated, so if you pass the final exam, you do the final project,
then they're going to actively...
There's already job interviews going on and stuff.
Cool.
Very cool.
Well, if anyone from there is listening and wants to...
We're definitely still hiring at Osmo says so reach out.
Well, there might be some...
I think there's plenty of people hurting at the moment with busted financials.
So it could be a lot of people looking for jobs.
So just before we jump to you, Aserpa, I just want to touch on this from Adam Burke.
What does TenderJudy do?
So really quickly, TenderJudy is just a...
It's at the moment, it's a Docker container or just a daemon that runs and it will connect
to a RPC node somewhere.
So it'll just connect to the network and it'll basically just ask the network every single
block, did the validator sign that block and you give the program the validator address.
It's a really simple program.
It just asks every block, did he vote, did he vote, did he vote?
And if it doesn't, it returns and says he didn't vote, then it sends an alert through
a very commonly used alerting system called pager duty.
And you get that alert on your phone.
You can set a threshold.
So you can say, if I don't sign five blocks, send me an alert.
And it's a really good early warning system for validators if they start to not vote.
So a lot of the other systems that we use is more reactive later on where we might be
getting high memory usage or something like that.
Some of them, some of the other systems we use might give us early indicators.
Other things might be catastrophic indicators that are like, something's failed, but TenderJudy
specifically monitors your signing.
So as soon as you stop signing, you can be straight onto it.
And that might be that your node exploded or it might be that there's some other issue
with your sign or something like that, but it gives you an avenue to start getting there
straight away and start looking at the cause of the issue.
So you, Serpa, are you excited about it, brother?
You're going to rug me here, aren't you?
That's okay.
You're more than welcome to.
One more thing on the TenderJudy.
The one thing I think that everybody, at least who runs it, really appreciates about it is
that it's the lowest level you can get to having a notification that something is actually
wrong.
There's no other points of failures and other things like Grafana or Xabix or you have an
agent or you have all this kind of crap, you have a network outage and all this type
of stuff.
If you can run multiple of these as well, which I do, I run one in our colo and one outside
our colo, things like that where you get a pretty, if that thing is going off, something's
wrong, it's time to get off your butt.
That makes it extremely, extremely valuable.
So I'm really glad that Todd has received that from you guys at the Osmosis Foundation.
Is that right?
And it's going to be awesome.
So I'm really excited about it.
It's just going to help up time, I think, across the board.
Thank you from the Osmosis Grants Program, not from the Foundation.
I knew it was the wrong term.
I was just going to say that.
Yeah, please.
Oh, sorry.
Just on that, Grant.
I have to say that Todd is so honorable that when you put in for that grant, he said no
payment until delivery.
Yeah.
Almost every, well, I think every other grant I've seen in there is some upfront and then
some on delivery.
And this guy is so honorable that he said, nothing until I deliver the product.
So that's how it would have, like, and he's hurting at the moment and he's still happy
to do that.
So sorry to continue.
That's OK.
Plus, I gave him hell because he's building a $100,000 product for a 10K grant.
I was like, yeah, I've got to work in this over time.
Like, what he's building, I think it's going to be awesome.
So I don't have much in terms of test nets or the types of stuff that's going on in the
ecosystem.
I think everything's been moving pretty smoothly.
There's a lot of projects that are starting to kind of fire up new test nets and things
like that.
I think the only thing that's exciting about this week, I think we're kind of led the
conversation around with the governance piece of things and just starting to have better
conversations both with Jake at the Juno and Liz Validate, your comments saying and everything
else.
I think there's a lot of just conversation around it.
So I think this is a good topic for us to keep bringing up on gaming nodes with everybody
who comes out because I think there's so many valid viewpoints in here.
It's tough to even quantify the problem, much less talk about solutions.
But the more little solutions you hear, like what Sunny said earlier around the slashing
idea or other types of things.
Those are just good solutions to throw into the pot.
As a problem gets identified, I think start pulling those things up to say, okay, what
do we have from this bag that works?
That's cool.
I think it's really good.
So just finally, there is a couple of networks launching in the next week, I'm pretty sure.
So there's T-grade, which goes live, I think on the 27th.
I'm pretty excited about that actually.
And there is also, I think Kujira is going to be launching imminently.
I think it's maybe a week within the next week.
So two more that we're excited about.
So thanks everyone for coming on and thank you, Sunny, for joining us, mate, even though
you were late.
Thanks Sunny.
But it's been really good to be able to talk to you and pick your brain on various things.
And we'd love to have you back again sometime because I'm sure we've still got just thousands
of questions to ask.
Absolutely.
I'm sure, I'm afraid, we'll get into some deep philosophical, philosophical conversation
about some random guy from 2000 years ago that decided about something.
So thanks everyone for coming on and thanks everyone for watching.
And I'll see you all next week.