Good morning, good afternoon, and good evening, good sirs. Welcome to the fourth episode of
the lookout. We'll be proceeding with the introductions later. So this week we've got
our very good guest Sam Hart, a hair product at Skate Protocol, and as well as our Devrel
Angus and myself. So we're going to be starting it in a bit.
Wait, hold on. Have I been muted the whole time?
Oh my goodness. Right, I've just been speaking into my phone for about three minutes
and I was on mute so I guess it was a good rehearsal. Did you did you hear my bit about
I did not. Oh my goodness. It was gold. It was like, right, anyway, okay, here we go.
Start again this time. So I thought I was, I'm gonna have to check that next time that I'm not
on mute. We've only wasted three minutes. Welcome everyone to the lookout. Sorry that I was on mute
for the first few minutes. I won't make that mistake again. I said, you know, we're going
to start more promptly this time, which is what I did, but on mute because Sam's actually
sandwiched this between two calls and he said he had a hard stop to me and I thought,
well, hard stock could be a good name for a Hollywood movie. Like, you know, hard stock,
one man has 60 minutes to save the world because he has to attend the weekly spread planning session
at three. So I thought it could maybe be a funny, you know, name for a movie. But anyway,
today on the lookout, we've got Sam who's the head of product slash strategy or strategy slash
product at skip protocol. We can discuss the differences between those two things as well
later. Welcome. The lookout is a kind of giant platform that is in a geostationary orbit above
the planet where Dragon Ball Z takes place and sometimes characters sit on there and kind of
look down at the action. I don't actually know, to be honest, I've not seen the show in enough depth
to actually know what they do on it, but that's what this space is though, right? We take a high
level kind of overarching bird's eye look at everything going on in the blockchain space.
We invite people, builders, leaders, people with a lot to say, to talk about technical topics
every Thursday on the same network, X account. I'm your host, Angus, along with Terry who does
dev rail with me. So let's get into it. We've got Sam Hart here from skip protocol. Sam, could you
first of all test your microphone, make sure you're not muted, and you can give a quick
introduction of yourself, please. Yeah, of course. Hope everybody can hear me. So I'm Sam. Like Angus
said, I'm the head of product and strategy at skip. I'm also a co-founder of a project called Time
With. And at skip, we build kind of transaction infrastructure. So we have an API that does
cross chain routing. We do kind of like the plumbing behind IBC. We have a an interface
called IBC dot fun, which is kind of a demonstration of some of that infrastructure.
So you can do cross chain swaps and transfers through that interface. And then we have some
blocks based products. We have an in protocol MEV auction called the block SDK. And then we have a
new product called Slinky, which is a in protocol Oracle that can do some some pretty fancy things.
And then just briefly, Time Wave is a project that came came out of the Adam 2.0 kind of
initiative. It's kind of evolved pretty significantly since then. But basically, it's,
there's two kind of core products. One is a treasury management system for DAOs.
And then the other is a way to do chain to chain or DAO to DAO agreements,
starting with liquidity sharing agreements. So happy to get into any and all of that.
That's a lot of stuff that you just just mentioned. I mean, I had it in mind, and I
teased this as well in a couple of tweets I did. I wanted to ask you once and for all, right,
a start, what are we talking about here? Is it the Cosmoverse or is it called the Interchain?
Because I've talked to different people, they've described the kind of Cosmo's
blockchain ecosystem as those two different things. What do you think it is?
Yeah, I think that both are kind of acceptable. So this is just me personally, but I typically
think of Cosmo's as a design pattern. So it's basically like a consensus protocol,
an application that you're that you're validating with that consensus, and then a networking
protocol, IBC. So it's almost like if people in web who are familiar with web two know like the
Jamstack. It's a software pattern that actually doesn't have any specific constraints on the
implementations of those those components. So you can like swap them out. But it's like a way of
building blockchains. That's how I think about it. But, you know, I don't want to speak for everyone.
And then the Interchain, you know, that word kind of
came. It's supposed to be kind of nearing the internet. And it is the kind of like set of all
interconnected blockchains. So, you know, it's similar to how there are Jamstack applications
that like plug into the internet, like, you know, there are Cosmos applications that like plug into
the Interchain. Makes sense. The internet is an interconnected set of networks, and not the
international network, as someone has suggested before. And then the Interchain is a kind of
collection of interconnected blockchains. Makes sense. I think one of the things when I came into
the Cosmos, the Cosmos ecosystem, having to get my hands on and into the guts of a Cosmos blockchain
was IBC was kind of a first class citizen of the whole thing, which I'd worked for a project before
that had launched the blockchain and then had plans to kind of add on IBC as a kind of
retrofit it to the blockchain. And one of the things I remember hearing some of the engineering
discussions around that was that it was going to be really, really difficult to make work. And I
think working with Cosmos, I can really see the vision, like the future with IBC, like, Interchain
communication, like transfers between blockchains with IBC, it's a really compelling idea, and I can
see the vision, the future of it. But I think one of the things that also struck me was the complexity
of IBC. I think, you know, I sometimes make a joke, you know, to devs, oh, if you're bored of
debugging on one blockchain, use IBC and now you can debug on two, three or four blockchains
simultaneously. Now, I wanted to talk to you a bit about IBC and IBC.fun and the skip API.
As far as I understand, it's something that kind of basically abstracts away some of the
more technical aspects of running these IBC transfers, right?
Yeah, that's right. So you can you can move from one blockchain to another and perform an IBC
transfer. And then we also aggregate over some of the main DEXs in Cosmos, say should be coming
very soon. There's, there's like one thing that say chain needs to add to make that work.
But yeah, it kind of gets you from A to B in, you know, starting from the asset that you have
and going to the asset that that you want.
Yes, and the IBC.fun interface is much easier to use than other ways of doing IBC from what I've
explored. So I think, I think that's something that is necessary to make IBC more accessible
to people. I know that on an infrastructure level, there's a lot of different, basically,
you have different blockchains, and they could be running different versions of protocols or
different implementations, and that can result in issues. Another thing that I wanted to get your
opinion on was in a blockchain ecosystem, there are various different groups of people
who want different things, and they play different parts of the ecosystem. So we have the validators
who run the nodes, we've got people who run infrastructure, people who build apps, users
who use apps. And so one of the things about IBC is that it requires kind of intermediary
infrastructure, which are called relayers, that relay these kind of messages. So you have a one
blockchain, it can send a message, it goes via a relayer, which kind of passes the messages that
do these transfers between the blockchains. And something that I've noticed is that,
and this is from talking to people in the community who are running these relaying nodes,
they're saying that it's not really been thought through yet, or kind of
balanced to incentivise these people to run the infrastructure. And also, they're at quite high
risk of when basically they have to spend a lot of tokens on transaction fees, because they
generate a lot of messages and transactions doing these IBC operations. So I was wondering if you
have an opinion on that, how to make IBC more sustainable in future by maybe incentivising
the relayers or figuring out a different way or improving the current way we have of passing
these messages between the chains. Yeah, happy to talk about that. This has been
under discussion for years, so not a new topic. So when we were developing IBC,
there were a lot of questions about the topology of the network, who the actors
were going to be that would actually be performing, relaying,
just what kind of businesses or transaction flows would be happening.
And it was kind of an explosive decision to not include an incentivisation scheme in IBC. And
this was really so that we could see the network evolve and kind of meet the needs of that network
from a kind of economic incentivisation level. And if you think about it, this is how TCPIP
works too. IBC takes a lot of inspiration from TCPIP. It costs money to run an exchange point
and to run cable from the ISP to your home and to make sure that the
router infrastructure is up to date. There's actually a lot of maintenance there, there's
costs involved. But there are businesses built around the TCPIP protocol that services needs.
So that's kind of how I think about it is there are businesses that are built or should be built
around IBC. And that actually already is starting to happen. There are some relayers who they'll
work with chains or foundations to have a service contract. It is a little bit cumbersome at the
moment. So there's a lot that could be done there. But we're still very early in understanding
what the application patterns are. And the way I see this playing out is there will be a set of
kind of coincident monetisation schemes that are built on IBC. So the existing one where relayers
maybe set up a service contract with a foundation or they use it as a loss leader to solicit
delegations also pretty common. That could still exist. But a DeFi app may want to have a kind of
premium service and maybe they would kind of contract directly with a relayer to relay their
packets. There's still some lower level stuff that needs to be worked on that I've done a bunch of
work on. So basically like having an internal representation of fees that's like queryable.
That's something that we've done at skip. And then being able to pay fees in non-native tokens
using that in protocol price. Also something that I've worked on that should be coming in
an upcoming SDK release. So yeah there's a lot of low level stuff that I think even to really
build a robust cross-chain service you kind of want in place. And I think it's really going to
take the next year or so for all those pieces to fall into place. A couple of interesting
points in there that I wanted to pick up on. First of all I think it's a really good
informative answer. I think I'm still trying to get my head around IBC on pretty much every level
of it. And so when you mentioned you know possibly some application might want a premium
service right. So there's a phone going off in the background for me. Hopefully it'll
I don't know if you can hear it. So is it possible that you could kind of analogize that to
basically like someone running a kind of premium RPC node for you. Like if you're
a project that needs access to blockchain data you would possibly hold on one second.
Yeah I can just kind of answer your question already. I kind of know where you're going.
Yeah you may want a lower latency response time from your RPC service. Similarly if you
purchase an internet service plan the home plan that you have you know just for your
your apartment probably going to look you know that looks a lot different than the like gigabit
ethernet plan that you get for you know your racked server somewhere. And like both of those
kind of service different customer segments and just have different there's different expectations
from from the customers on like what good service quality looks like.
Yeah that makes sense. And it's helping me to kind of visualize the role that a relayer might play
and the services that they might offer to different customers. Now I wanted to kind of
also use this opportunity to steer the conversation in a different way. You mentioned
MEV earlier and there was you know time wave that makes kind of tooling that does among other things
MEV type operations. Now I was I was wanting to propose to you an idea or something to discuss
is that as a IBC relayer is there is it going to be possible that that would possibly you could
use that as a kind of if you ran relayers for example and you were dealing with IBC transactions
would that give you an advantage to harness you know to take advantage of of MEV that might be
available if you get IBC transfers first and also possibly running a relayer in conjunction with
one or more validators on on chains. Is that something that could help you get an edge in MEV?
Yes so this is a relatively deep question but yes absolutely. So just as an example
one can so say you're on say and you want to swap say token to Adam you can
send an ICS20 packet that includes a a little tag at the end in the memo
that has an instruction to swap your save token to Adam on osmosis and if the
the relayer has that that information and so they could potentially back run the transaction on
osmosis. This is a little bit of a
side note but like one of the other things that skip built was an automatic backrunning service
for osmosis that like tries to perform exactly that operation so that so that MEV searchers
can't extract that value basically it's a return to the osmosis protocol
but it doesn't get everything so there definitely are this this form of kind of advanced information
that that is extractable through relaying and there's other forms as well but basically
because these are all state machines that are with different pricing information you
if you have kind of advanced information advanced information about prices in one
one domain you can leverage that to perform some some kind of arbitrage.
As you said a very deep topic that's what we're here for though on the lookout we want to go deep
last week we actually had someone called Max Resnick come on he's the head of research at
special mechanisms group and they do economic research mainly focusing on on things like MEV
and the mechanisms around that on on Ethereum and I think one of the takeaways that I had with
my conversation from my conversation with Max was that MEV is extremely complex both technically
but also yeah it goes very deep into a kind of theoretical
realm as well and kind of any design choices you make will have an impact on on how MEV kind of
what the opportunities are. I think now I'm talking with you about it I'm realizing wow okay
interchain MEV is kind of a level up from that in complexity and yeah so it's interesting to
talk to you about it. I think we were discussing last week so I was discussing with Max the
differences between Cosmos and you know Ethereum MEV and I was wondering yeah do you have can you
give an explanation of how it's different on Cosmos not interchain but just on a single chain
I think because the kind of the block payout is a bit different isn't it the validators aren't
necessarily paid you know just their blocks it's kind of split up and according to some sort of
formula between all the active validators or something right? Yeah there are a couple differences
I mean one difference is that there is orders of magnitude more liquidity and
kind of opportunities for single domain MEV extraction on Ethereum so you know we're talking
they're kind of different ballgames right now I mean one would hope that
Cosmos has a lot more volume in the near future and things definitely seem to be trending up
but I want to I want to like preface this by giving a benchmark for where Cosmos is at
from a technical standpoint Cosmos chains are they use Comet VFT so it is a fast finality chain
and the block times range anywhere from six seconds to on say they're they're super fast
and you know it's like sub second wondering
I like got a little bit of that I don't know if that's me or you but you're kind of breaking up
it might it should be my connection but I was saying say has less than 400 millisecond
block types if anyone was wondering yeah super impressive super super impressive
but after 400 milliseconds you have finality which is also very cool and that means that
you can design protocols with that in mind so after that 400 milliseconds you can say okay
well that that was the you know this is the state of the world I can like take action on that state
and it also gives arbitrageurs or market makers additional certainty that when they get a response
from the chain that something's been finalized that that position is locked in so they can
perform like ARBs against other chains or other DEXs like it with a lower cost of capital
and they can kind of move out of that position after they have have this kind of finality
there are some other things that we have worked on that that we think are pretty
unique for cosmos chains so one is we have this
the system called the block SDK which has a basically dedicates a portion of the block
specifically for arbitrageurs and we run a credible auction at the top of the block so
basically all of the validators share information about their mempool about the bids in their mempool
for this top of block slot and we can we can kind of aggregate the snapshots of the mempool to
determine an inclusion list of bids which are then sorted and the top bid makes it into the block
and the reason that this is important is it removes discretion from the validator
with regard to which bid is chosen and this is a big problem in ethereum because
basically the an ethereum proposer when they're when they're creating the block they can
um remove a transaction from their mempool silently um this is this isn't an accountable
process uh and so um that that monopoly basically gives them monopolistic power to um extract rent
from from this auction um by removing the discretion of the validator to uh to selectively
include or exclude uh bids um the protocol can internalize um those revenues from from the
auction so um that's definitely a cosmos chain superpower for sure that's a very interesting
approach we discussed in some length the kind of the proposer builder separation
mechanic last week and how you know the the people the the validators who won the right
to build the block sold the kind of yeah wait so the proposer wins the right to propose the block
and then you know basically there's an auction for the right to kind of build put the transactions
together in the block and then somebody else gets to so so you can so yeah basically there's this
auction where where people bid on on what they want to have included in the block and so then
this is different though because is it the the case that the validator on that that uses this
cosmos mechanism has to accept the highest bids they can't choose to not accept some bids even
if they have a higher higher you know cost associated with them yeah that's right i can
summarize so in ethereum they have proposer builder separation the proposer is the validator
it's the validator that is proposing the block and the builder is um basically the market maker
it's the off-chain actor who is constructing you know a a dex trade or whatever and um in ethereum
the uh the builder bids on um the right to for their built block to be submitted by the proposer
but the proposer has you know these the power to um kind of arbitrarily uh deny that um
that block uh so that gives them the ability to extract rent um and in cosmos we remove that
ability um we basically say okay here's all of the bids for this block portion um it's actually
slightly different we we we allow um just a portion of the block to be auctioned off which has some
some benefits so it's just the top of the block that's that's built by an independent party and
for the top of that block all bids are are included we have insurance that all bids will
make it into the block and in this way the proposer really cannot do anything the the only
thing that they are able to do is not make a block at all in which case you the tenorment round or
the comet bft round advances and the next proposer can only submit uh a block that corresponds to
the one that the protocol tells them to so um that means that the the protocol can um can
absorb that that auction revenue rather than the proposer
yes okay that makes sense and that was a great summary so thank you i think
i got confused and i've just thought it out right now i feel like building something to me seems
quite uh solid like that's quite a uh a definite action whereas proposing something to me seems
quite you know uh preliminary right whereas it's actually the wrong way round the way i'm
thinking about it you build the block and then you can do that to your advantage and then someone's
got to propose the block and the consensus mechanism so the person proposing actually has
all the power but i was just thinking about the wrong way around yeah the distinction is like the
the builder is um is kind of a sophisticated entity that is tracking chain state
they're also probably like trading on binance or you know other chains and
they're they're doing other things on these chains that like counter trades
and then they build a candidate block um the candidate block is passed to the proposer and
then the the proposer like terminology comes directly from this like the consensus scheme
like comet bft so they are proposing a can a candidate block for the consensus protocol
which is then voted on by my comment yes i'd like to mention for the record as though i've traded
on binance and i'm certainly not a sophisticated actor um but it's interesting that we're
discussing these kind of um the the the similarities and differences between
the the the core blockchain of ethereum and you know one built using what's called the interchange
stack of the cosmos sdk now something that's happening soon right is say we'll integrate
the evm into the blockchain and so that's been something that that i told you i wanted to talk
to you about sam um and so the idea of of integrating in in the interchange stack you've got
cause and wasm which is you can write smart contracts and you can run them on your blockchain
but now there's a bunch of projects um including evmos say obviously um bear a chain who are kind of
implementing in one way or another the evm in either alongside cause and wasn't um
or instead of it right and so i was wondering what you thought about that
you know implementing other execution environments right and smart contract
programming languages um on platforms in the stack
yeah i'm all for it um i mean this is what cosmos is good for is like
this modularity gives the ability to experiment with different combinations
um i would like to see one of every prominent um virtual machine built on cosmos um and most of
them are here so i mean there's there's a wasm virtual machine there's an evm uh there is a move
virtual machine um i am not 100 sure if there's an svm virtual machine um just yet but like uh at
risk also not 100 sure there's one yet but yeah i would like to see all of those kind of flourish
and cosmos um in my mind it's it's similar to you know i made this jamstack analogy before
like okay well uh if you want to um swap out the like static rendering layer with like a
you know from a javascript one to like a ruby one it's like great like you know that allows you to
have like ruby devs you know building jamstack applications like same same idea um i would i
would love to see them all uh you know interoperate with each other so actually like using ibc um
that would be that would be my kind of one preference i think uh the what what do you
want to see in interoperating with ibc the different oh just like each of these instantiations of
of like chains with new virtual machines like it'd be nice to be able to talk to them by ibc
ah yes okay so yeah so it could be because if you have two different vms running on the same
chain in the same client then that wouldn't necessarily need ibc but if they want to yeah
but what i was wanting to ask you because this is something that we actually had a couple of guests
on from a podcast called vm wars which just started recently i highly recommend everyone to
go and check it out and also sam you might want to uh you know take a look at it yourself um both as
a listener and possibly as a future guest because those guys are really interested to talk to
they like move um we had a really good discussion about the evm as well and and you know there's
kind of a two different i think we're pretty much at a fork in the road right now in terms
of people's opinions some people say right evm it's the future it's got the momentum and it's not
going anywhere some people say okay um evm is going to get superseded by these other newer
more superior you know more update up-to-date better technologies um like moves cosm wasm so
what i was wondering was if we see a kind of proliferation of evm functionality into the
interchain right into the cosm reverse um what do you think that means for cosm wasm as well
because i know people who are into cosm wasm are really into it right there's a lot of people who
are really really enthusiastic about cosm wasm but from what i hear from a lot of the devs that
i talk to is that it's quite a steep learning curve um and it's quite difficult to get into so i think
i've got the feeling that like if the evm is available for a lot of these devs they're just
going to go with that right and i don't know what that means for kind of cosm wasm and the
community i'd also like to say before sam you answer that question if people have questions
for a q&a section please submit them now because we're going to do that um in the next five ten
minutes and we're going to finish on the hour sharpish today so um if you've got questions
put them into the chat or tweet box or whatever it is now so yeah sam what do you think proliferation
of evm and cosmos what does it mean for cosm wasm etc yeah i mean i don't think that any cosm wasm dev
would want to touch the evm again it's like not a very fun thing to interact with um
people kind of begrudgingly use the evm um primarily because they there are integrations
into existing d5 protocols and the tool chain is really good um so i would like to see you know
the tool chain improve a lot for cosm wasm um yeah i don't i don't think that cosm wasm is going
anywhere um i also think that like we are the very beginning stages of this whole thing like
none of these are actually the end state none of these have privacy like like the end goal is to
have private blockchains like we cannot stop until we have we have like actual user privacy
um so like we have to like view these as uh projects that are in their infancy and until
we're getting to that stage um so i think that there will continue to be a role for
evm that will continue to be a role for cosm wasm um there's also just like a lot of very
interesting things um with like just-in-time compiling that i'm like starting to see now
so yeah there's just there's just like a lot of uh pretty cool unlocks i think in the the virtual
machine realm okay interesting i think yeah i'm i'm merely an observer in this process um and i
think as well it's a bit like watching a river flow you can't really influence where it's going
too much you kind of just got to watch where it goes and go with the flow um it's a very exciting
thing to be in and around and involved with um i suppose and so yeah i can i can kind of see
both futures um i think as the vm wars podcast title suggests i think we're going to see
you know some some healthy competition between the the different vms um in future i think
i think i usually liken it to cloud software uh cloud hardware providers right um like cloud
services you know developers don't fight each other um you know conferences aws versus azure
versus google cloud right it's like if you're a cloud architect or engineer you get a certificate
in all three because then you can do more jobs and you know you can give the client what they
want and i think you know in in blockchain i think probably something similar will happen
where if you're an engineer it will just make sense to to learn you know vms if there's demand
for people who want you to build apps on the vms right so yeah i can kind of see also a ton of
opportunities for um like uh languages that compile down to different vvms like intermediate
languages um a vm is actually like well first of all very very few people like know how to use the
evm like you're not writing in like evm bytecode like you're writing in solidity and um you could
actually compile solidity to another vm if you wanted to or you could um there there are like
intermediate languages like yule for instance that like you can compile um you know move to yule that
then compiles down to like um to dvm bytecode this is all to say like um we we haven't even like
started the uh this like progression towards abstraction um and um yeah just don't don't call
it too early like we're we're very uh far away from from like the state that we should be um
with the development experience and um really like the the level of abstraction that
that um mechanism designers d5 protocol designers are are working in yeah
i've i know what you mean i've heard that before right with with wasm i think basically we are so
early to quote the crypto meme we are so early with wasm i think um i know just to give you an
example like the like apple switched from like x86 to arm right and like you didn't even realize
you had no idea like you just like got your new macbook and then you're like now you're on arm
and then like you you're you have your icloud update and it's like everything's back back like
it was like you you don't notice that you're using arm now um like that is the level that
we're talking about here like virtual machine like risk is literally a like a machine architecture
um so uh i i have like high degree of confidence that um there will be innovation there um and
that there will be kind of like further um uh kind of isolation from the development experience
to allow for developers to like have you know better ergonomics more safety features um
and just like better reasoning capability about about their application
yeah i i think it's good to mention as well that one of the strengths you brought up of the evm was
the tool chain and i think when you're talking about that lower level um
you know architecture the tool you know the tool chain is very important right and and so
if you've got to write your smart contracts in like c++ or rust or something that
can can be a bit of a barrier to to developers versus something like javascript right but then
you know someone's got to write the the tool chain or the middleware to get from from javascript
towards them and yeah obviously i noticed when i went from x86 to arm but but i i take your point
is is that one wouldn't notice most people wouldn't have noticed um i think it's a it's
a good point as well that this is really under the hood stuff right but that's what we're here for
on the lookout so um we're coming to 10 minutes ago i think as well it's worth mentioning that um
the title of this is discussing app chains and modular chains and we haven't really
discussed either of those so i will put a question into you now sam about app chains
insofar as what i meant when i when i wrote that out was um what one of the kind of
theses um that was kind of going around the the cosmoverse was that the idea of app chains like
you know you'd build your own you'd you'd have this toolkit to build a blockchain um that would
make it a lot easier than than it was current like before like rolling your own coding your own
writing your own blockchain so then you have this kit so if you want to build an app rather than
running it on top of somebody else's blockchain you kind of spin up your own chain and then it's
right there for you you've got your whole uh your own whole blockchain to run your app on but
as we've talked about right ibc is still in a very early stage um in the grand scheme of things
and you know other things like liquidity access to liquidity um and interoperability between these
chains can make the experience of building stuff in an app chain slightly um less easy than it is
building on on a kind of you know one chain so i was wondering if you had any thoughts about the
future of of the app chain thesis you know each app having its own blockchain yeah um yeah i mean
one one thing that is not part of the app chain thesis is like that it is going to be easier than
deploying a smart contract um like no one's claiming that um really app chain thesis
can be summed up as uh there will be some latent demand for vertical integration like
it's very simple like if you're a successful app you will want to
increase your margins and capture value from layers below you so you know those things include
um mev like we were discussing before uh which is a whole realm of um a kind of value leakage and
and potential value capture um and then uh you know various forms of order flow um if you want
to experiment with your own you know uh with like certain efficient efficiencies so you want to have
a new uh virtual machine or um uh there's a whole bunch of kind of functionality benefits that you
could um kind of cut out third party so this is one of the things that the oracle um product that
we recently developed at skip does it's like a an oracle that is owned by your chain rather than
like interacting with third party um so yeah all these things are like they they kind of increase
your margin and allow you to have you know a very kind of sculpted user experience um
you know your app works just the way just the way you want um you know say is is an app chain
like you just you decided not to build say on ethereum right it's like well we're gonna do
something else and like that is the app chain thesis in a nutshell so everything is an app chain
basically ethereum is an app chain yeah it's an app chain that like you know where its functionality
is to provide this smart contract um platform but if you have a you know an enormously successful
application on say i mean i'm you know it pains me to say this but like they will have an incentive
to build their own chain because there will be value leakage to to say and there are ways to
retain customers like that but you know this is just like how business works is like um once you
get to a certain level like you you want to you know optimize the um your costs and
um you know build some kind of moat around your business which often requires building custom
functionality well so i think in that case the future of app chains is very bright um by our
definition of everything as an app chain i think i agree with you um people who become
projects which become successful uh you know they might think well we can have a pop at this how hard
can it be let me tell you as someone who's been around this happening for several years building
an l1 is not as easy as you think it is um it takes a lot of effort a lot of um work there's a
lot of moving parts but yeah i think i'm i'm with you sam i think people are still going to try it
when they have something that's successful um so we're coming up to five minutes to go now
did you have anything else that you wanted to speak about sam just because i know you've got
a hard stop sorry um i mean i i feel kind of obligated to plug um ibc.fun so you guys should
mess around with you know using cosmos and swapping and stuff on ibc.fun everyone wants to
use ibc.fun uh also follow sam on x follow me as well follow say network follow all the speakers
um check out slinky as well the oracle product that's very interesting as well really yes plug
in that's that's very important i sometimes forget to do the plugging it's very very important though
yeah but it's it's been a great conversation and i'd like to thank you as well at this point for
coming on it's been really good uh we should probably rename the lookout to the mev lookout
because that seems to be a kind of common theme but it is it's just such a broad and deep topic
uh with so much complexity yeah i'm surprised we had this much audience retention with me
just rambling on about mev for 20 minutes well i mean i have my uh blame in that situation as
well because i started it but i think um we are building a a dedicated audience of people who
um they are interested in this stuff right um and i think that's what we're trying to do here is
just provide a place where we can talk about technical things um do a little bit of plugging
sure but really yeah kind of be free to to explore ramble off you know onto technical topics um
and i'm sure you know i think we're going to be hearing more about mev on cosmos blockchains i
think i think you're right i think one of the reasons that it's been the focus has been on
ethereum is because of of the defi there and the higher value in terms of tvl um you know if if
if those things go up if there's more interest uh more usage more volume more apps on cosmos
sdk blockchains in future i think we'll see some of these people figuring out how to do mev in weird
and wacky ways in future as well um i guess you know do we get our own jared from subway that is
the question oh my god i guess i guess that's what success looks like that would be yeah the
ultimate sign of success um okay so i i've kind of not really been paying too much attention to the
the chat i'm gonna have you want to pick one one question before you go from the audience
yes but to be honest right and i'm kind of showing my ineptitude here with
this particular strain of technology i don't really know how to there's been kind of like
some tweet replies um but i think we've not really got any um questions uh that anyone wants to ask
in particular um but so in lieu of making one up for you i think you know um i think we can just
close there unless you know do you want to ask me any questions uh no i mean i'm i'm really grateful
for you having me on um should also mention that uh skipp's going to be integrating with say like
very very soon so um i'm super excited to kind of learn more about the say ecosystem it seems like
you guys are growing super quickly and there's just like lots of lots of fun stuff kind of coming
coming up that's great to hear we will obviously be delighted to welcome you on board
it's going to be interesting to take a look at slinky as well um and yeah you know thanks for
coming on um tell tell other people about the lookout both as a listener and a guest perspective
we're always interested in hearing from people who have something to say um technically uh as you've
as you've just experienced we don't always just talk about say it's about kind of anything
technical in the blockchain space um so yeah thanks so much for coming on sam i'm going to
leave you with a minute spare so you can prepare for your next call thank you everyone for listening
tune in again next week we've actually got a really good guest booked in i've just finalized
today you'll be excited keep an eye out on my twitter feed um and the say network twitter feed
as well so obviously follow me follow say network follow sam hart tune in next week we've got a
really good guest and also we've got developer office hours every wednesday if you're building
something and you've got any questions so thank you very much everyone goodbye thanks all bye