Thanks so much for having us.
and that's not all the same things.
We know you feel like we work out there.
We have some conversations and works around integrations like that, and you can expect that
of feature completeness over time. At the same time, in a new ecosystem, you might as well throw
out the standards from Solana L1. For example, Metaplex is the NFT standard in the Solana ecosystem,
and that's actually caused them a lot of grief, given that this is a centralized company
that controls the upgradability for the NFT standard that underpins their entire NFT ecosystem.
So in some sense, there are some of the classic things that developers might be used to on Solana
L1 that are missing, but that's also a benefit because we can learn from the mistakes of more
organic ecosystems, and we can think about from the ground up what actually makes sense for a
fresh SVM environment. That actually makes a lot of sense. Are there any changes you have to make
like to the SVMs? Because obviously, you know, Solana virtual machines are a very integrated
environment historically. So I'm just curious if there was any, you know, modularity changes,
or maybe I should say things to increase its modularity, you know, or anything specific
that you had to do to make it kind of a more flexible as a standalone virtual machine?
Well, one is that the data is published. So by default, Solana obviously wouldn't post its
data somewhere else. So now we publish those transactions to the layer one, whether it's
Injective or Celestia, some of these details, it's subject, it's somewhat subject to, to being defined.
But yeah, so you get to publish the data, we built a rate of verifiers, so you could reexecute
everything. And as far as like how we connect to Injective, right now we're going to be using,
we tentatively, some kind of full node bridge, which would be replaced by a fully validating bridge,
whenever we feel like it, I guess. So those are the main changes compared to Solana L1.
So it's basically a question of how do you guarantee the safety and liveness of this chain?
While Solana L1 uses its own quorum, the Injective SVM roll-up uses a variety of other
mechanisms to provide those same guarantees.
Todd, thank you. I think maybe I'll go to Eric for my next question. Although Neil and Matt,
if you, if you, you know, have any thoughts, feel free to jump in as well. But obviously,
like Injective, you know, started off as a premier DeFi environment for Cosmos and developers,
but clearly you felt the need to also want to offer, you know, SVM and EVM capabilities for
your community of developers as well. So I'm just curious with the integration of these two roll-ups,
are there any like DAP use cases you envision or hope to see being built out,
maybe things that weren't possible before, but you think could really be able to leverage,
you know, the new technology you've just integrated?
Yeah, I kind of mentioned before, basically, one of the most important part is that the smart
contracts, even if you're, you know, like a mature project that has already, you know, found success
within deploying on top of INVM or INSVM, and, you know, have gotten familiar with Cosmosy,
there's still a very, very strong reason for you to, you know, deploy and, you know, keep the
application on top of INVM and also INSVM. Namely, number one is that there could just be cost
differences. So basically, for the Cosmosy environment, there are certain, you know, computations
and, you know, types of transactions that are more expensive than a roll-up. And as a matter of fact,
typically, almost all transactions relating to, you know, smart contract executions are likely going
to be more expensive than any type of transaction that's happened within INSVM and INEVM in the long run.
And on the other hand, what you will end up seeing is probably this class of application
that acts as kind of like this outpost or kind of this, you know, executioner on top of the
injective chain as a Cosmosy contract that, you know, takes in instructions or takes in something
that's computationally intensive but not latency sensitive and executes it on top of the injective
chain. Now, it could be, you know, computing different types of signals over like an hourly
duration or over like a, you know, daily duration that can allow for like an on-chain strategy
that is probably like the most basic potential approach for it. Or it could be something,
you know, much, much more advanced that we haven't even thought about.
Great. Yeah, no, thank you for that. I guess, like, I know we actually kind of touched upon this
a little bit already about, you know, kind of how we're going to have this ecosystem where
all these different smart contract platforms can now interact with each other. But I'm wondering
if we can dive in a little bit deeper about like what specific interoperability solutions you will
be using to facilitate communication between INEVM and INSVM, not only with injective, you know,
base chain, but with other blockchains outside of it as well. I don't know,
maybe Eric, you have, you know, thoughts on this that you want to you want to kick it off or we can
go to Matt or Neil on it as well. Yeah, I mean, the most native and natural interoperability
is kind of already taken care of by making it compatible with IBC, which is actually, you know,
what's been primarily the workload and challenge behind it. Being able to, you know, have like,
IBC compatibility for, you know, package transfer about the same time, you know,
making it symmetrical or close to the security guarantee of, you know, the role of itself.
Because, you know, once you have this kind of like IBC integration and this IBC interface,
you can basically have full interoperability with injective, thanks to, you know, not only just the
message passing aspect, but also things on top of it, like, you know, package for middleware,
ICA, et cetera. So yeah, like, I would say like that, that actually very easily comes out of box.
Once, you know, there's a full like IBC integration, but obviously, on top of that,
I would say that more and more bridge solutions and more, you know, access to assets within different
type of multi-chain environment, it will overall, you know, boast in the kind of like liquidity
that's available on top of injective. But, you know, we'd love to have them, you know,
elaborate about like their specific approaches, et cetera.
Yeah, totally. Matt, is there any, you know, specific approach any VM is taking?
Yeah. So truthfully, we, we're still kind of ironing out the final details here. As Eric mentioned,
like the gold standard is making this as IBC compatible as possible. That's the interoperability
standard in the Cosmos ecosystem. The injective chain is, you know, is able to interoperate with
that. And, you know, there's just so much development happening around IBC that that's
the end goal. Generally, I think your specific question was on the interoperability as well
between any VM and SVM. I'll also let Neil touch upon this as well. But Neil alluded to this earlier,
using some form of shared sequencing, I think is going to allow that faster interoperability.
But the space currently around shared sequencing is quite nascent. So I'll feel free to pass it over to
Neil for his thoughts. Yeah, for interoperability in general, I could use regular bridges. There's
obviously IBC, which is the most native way to do it in Cosmos. And like Matt was talking about,
with shared sequencers, the concern with the SVM in particular is just that there's an extra hop
required for a transaction to be submitted and confirmed given, like, let's say we use Espresso
or Astri or one of these well-known shared sequencers. They're probably not going to run the SVM
RPC. So different VMs or different environments have different types of ways of interacting with
them. So Ethereum has, Ethereum's JSON RPC, then Solana has its own separate JSON RPC. So they
probably wouldn't implement that. So we'd have to receive the transaction, send it to Espresso,
it'd be ordered, and then they'd send us back the ordering for us to execute it. And that additional
hop, given that these block times are so short, and we're used to like very quick confirmations
with the Solana VM, that might impose some additional latency. But the reality is that
there might not be any other way to achieve short range censorship resistance other than
like a full decentralized quorum like that. So this is still something that we're exploring the tradeoffs
for. It's possible that like NSVM doesn't necessarily need like ultra short, ultra low latency in the same
way that Solana itself does. So I think that would somewhat defeat like some of the purpose behind
the SVM. So we're still weighing the tradeoffs. Yeah, that makes sense. And we're kind of, you know,
pushing up against the extent of my full technical knowledge at this point. So I'd be curious to get
your guys' opinion on it. But it also sounds like if you did implement some type of shared sequencer
solution in terms of interoperability between an EVM and an SVM. I mean,
similar to like what shared sequencers do in just one particular stack, like OP stack, like would that
allow you then to achieve like cross chain atomic composability between an EVM and an SVM execution
layer? And if that's the case, like, I imagine it would be the first time that we would see that
actually the blockchain ecosystem overall. I'm just wondering if that could potentially lead to
anything interesting. Yeah, there's like, I think some economic challenges that are unsolved there.
But the idea behind a shared sequencer is like one big block builder for all the rollups that subscribe
to that shared sequencer. So the idea is that if I wanted to bridge to from any an SVM to an EVM,
I'd have one transaction that's being, that's locking tokens on the NSVM side, and another
transaction that's minting tokens on the NEVM side. And what we don't want is a situation where
one of those transactions is included, but the other is not. So it's okay if both of them are
included, of course, that means that the bridging went through successfully. And it's fine if neither
of them went through, but you don't want, you don't want them to have a non atomic inclusion.
So that's what a shared sequencer provides for. But in practice, in order to actually like provide
that atomic inclusion, you need to be able to execute both chains. And the reason for that is
you need to know whether, you need to know the state of each chain, and whether either of those
transactions will revert when you try to include it. So that's effectively the challenge. And at some
point, you have to either have a quorum that says, yeah, this, we executed everything for both chains,
and, and we can sign off and attest that neither of these transactions will revert, or you need to
trust someone, which is not an ideal case, or you need to have some sort of economic guarantee. So
maybe someone puts up a bunch of stake. And if you can demonstrate that, actually, one of the
transactions did revert, and the other went through, then you'd be able to slash them and capture that
stake. But, but that introduces all kinds of game theoretic problems. So it's, it's like an,
that's why it's so tricky. It's like, that last solution is, is the solution that I think shared
sequencers are most seriously exploring. So there are other shared sequencers like Rome Protocol,
for example, which lean toward the first direction that I was hinting at, which is you have some very
large quorum, such as the Solana L1. And they're basically using the Solana L1 as a shared sequencer.
So this is all like, like Matt was saying, it's all pretty early. And none of them are in production,
at least not for mainnet at this point.
Got it. No, that's, I mean, that's a really good answer. And then this is, this was my final,
I'm going to pass the ball to Chris in a second here, and he'll ask some of like hackathon specific
questions before we wrap up the space. But I do want to ask, and I'm not sure maybe which of you maybe has
a stronger opinion on this, but does, you know, if you're, if you're running roll ups on top of
injective, I think you mentioned having, you know, a canonical validating bridge at some point.
But at the very least, you have, you know, your one canonical bridge back down to injective base
layer. I mean, does this, depending on what token you're using for gas, I also guess, does this
introduce some type of capital inefficiency problem where, you know, I mean, maybe this is similar to
just ETH roll ups in general, but you have tokens locked in the bridge, not really doing anything.
Or, you know, is this, is this something that, you know, is not actually a problem?
Well, if you look at Gnosis chain, which has a bridge directly to Ethereum L1, they're quietly
generating millions in ARR just by lending out that money that's locked in the bridge. So you can,
like take on, you can, you can prevent yourself from taking on that opportunity cost.
But then the question is just, is that worth the risk? Like all yield implies some level of risk.
So for a bridge, I don't know, I don't know if that's really worth it. But, but yeah, you're right.
If you're ever locking assets in a bridge, then you should be thinking about the capital
efficiency of whatever you just architected.
Okay, cool. No, that's a good answer. All right. I'd like to introduce my associate,
uh, Chris, uh, who's also a colleague of mine at Dora hacks, um, who's keeping a keen eye on this
hackathon and helping run it internally from our side as well. Um, we'll, we'll wrap up with a couple,
uh, you know, more additional hackathon related questions.
Sure. Thank you very much, Brian. And hi guys, this is Chris.
Um, uh, thanks for all of the like wonderful explanation on the technical, uh, details.
And right now, uh, I want to, uh, just ask some specific questions for Illumina and hackathon
specifically. Uh, I guess, uh, Eric, uh, feel free to jump into the answer, but also, uh, Neil and, uh, Katz.
Uh, so I guess my first question is that like, what is the best path, uh, for either SVM, EVM,
or Cosmos builders to actually start, uh, building on injective, uh, doing the hackathon? And like, uh,
what are some of the most important factors that a builders should, should be, should be aware of?
Uh, we can start from Eric.
Yeah, it's a, quite a general question. Um, I think it's, first of all, you know,
figure out, uh, your understanding and, you know, the stack that you're most familiar with,
uh, or, you know, your, uh, uh, your expertise, quote unquote. Um, so, so there are, you know,
different classes of application with different types of, uh, distribution of, uh, you know, various,
uh, uh, you know, kind of, uh, uh, disciplines. Um, there are a lot of, you know,
applications like, uh, uh, that, that doesn't require really any backend, uh, that doesn't
really require really, you know, um, um, um, any like smart contract, uh, or, you know,
it could be the other way around where, you know, it could be like a purely like a, uh,
smart contract based tool, uh, and, you know, Cosmosm rather than, uh, having any front end.
And so first of all, figuring out, you know, what you're good at, you know, your, uh, your,
you know, knowledge spectrum. And, and then with that in mind, you can come up, uh, with
kind of your, uh, expertise or join like, uh, you know, like a team, uh, or, you know, find like a
project or a class of project, um, that fits the best with your, uh, capabilities. And let's say,
you know, you only know front end and nothing else. Uh, one of the easiest way. And, you know,
one of the interesting part about objective is that you can create, um, an exchange application,
um, with a matter of minutes without any type of backend knowledge. And then you can go through
API docs and stuff like that to have your own interesting, you know, uh, takes on it. Um, and then there
are, you know, different, uh, um, team, uh, if, if you're a team, you can under, uh, you can get
an understanding of, you know, uh, um, what, what all the members know, uh, and coming up with a
project that fits best with their, uh, you know, strengths. Um, and I think that that would be like
the best tip is that, you know, there's a lot of, uh, uh, ideas and, uh, um, kind of, uh, approaches
on building, you know, projects within the injective ecosystem and our idealists kind of
tries to cover, um, you know, different types of potential scenarios on, you know, what you're
good at, uh, to basically allow you to build any type of application or, you know, build an application
despite your, uh, you know, lack of understanding. And for example, smart contracts, uh, Rust, et cetera.
Um, yeah. And of course, uh, thanks to INDB and SBM. Now, you know, if you don't, uh, if you don't
know Rust, if you don't know Go, um, you know, it makes it much easier to build, uh, uh, in Solidity
or, you know, within a Solana environment.
Yeah. Amazing. Thank you very much, Eric. Um, and I'm not sure if, uh, Nier or, uh,
Cass, you have anything that wants to be added here, uh, specifically, specifically for, uh, builders who
want to, uh, adopt, uh, in EVM and in, uh, SVM.
Yeah. I'll jump in here quickly, um, and just, uh, you know, help, help, uh, give like, uh, some quick
tips, quick tips on just like getting started with the in EVM in specifics. Um, so we currently have
a website live, in EVM.caldera.dev. Um, the link is, we can put the link somewhere. Um, that's kind of,
like our hub page for the in EVM. People can, you know, instantly add the chain to their metamask.
They can request funds from the faucet. They can take a look at, uh, our block explorer,
our documentation, et cetera. Um, and then they can just take the RPC URL we have on that site and
plug it into the familiar Ethereum developer tools that they have. So, um, it's probably like the
fastest way to just get something up and running. You can take something from third web or open Zeppelin,
et cetera, deploy it to any VM, uh, and get started there. I'm sure people don't need like big
explanations on how to do Ethereum development, but because the chain is EVM compatible,
it's compatible with almost all Ethereum developer tooling, hard hat, foundry, forge, et cetera,
Ethereum, smart contracts, and all the tutorials that people can find online for developing,
uh, applications on Ethereum or EVM chains. Um, so for folks who are just trying to find a place to
get started, I think that that might be a good place, uh, to kick things off.
Agreed. Yeah. I think that for most developers probably makes sense to start with the EVM.
And then if you, uh, hit some kind of constraint or if you're trying to build something that
requires really low latency or maybe something consumer facing, then worth trying out in SVM.
Great. Thank you. Thank you both. Uh, I think these are very, uh, great answer.
Uh, okay. For the next, uh, questions that we have, uh, what do you think, uh,
are the most exciting or most needed ideas or pro type of the projects, uh, that do you think,
uh, that is, uh, for injective right now or like, what are some most exciting ideas that you have seen
recently, uh, uh, uh, like in, uh, in the injective ecosystem or, uh, for the future injective ecosystems?
Uh, we can start from Eric on this as well.
Yeah. I'll, I'll, I'll, I'll think of one that's a pretty easy to build. Um, I, I think that would be
probably like, uh, uh, you know, uh, especially for new developers that are not too familiar with, uh,
injective, um, it would be the, you know, Ethereum, uh, uh, AMM or, you know, any type of, uh, LP position,
uh, hedging tool. So basically, uh, if you want to LP within, you know, AMM pools on top of Ethereum
or perhaps on, you know, any other chain, um, you are, uh, you know, uh, um, kind of exposing yourself
to impermanent loss. And as a result, you know, with a lot of, you know, downside risks, uh, beyond the
yield that you're generating, but, uh, with, uh, you know, injectives, uh, on chain derivatives,
um, as well as, you know, having the capability to automate, uh, the execution, uh, without users kind
of, uh, uh, risking their, uh, funds, it basically allows you to create a very simple tool. That's
actually more Ethereum or, you know, uh, uh, EVM user facing that allows, uh, you to, you know,
provide the server to users, uh, where if you have an, uh, AMM position, uh, basically
uh, there is a service that can, you know, bridge it over to injective, um, and then
kind of hedge against that specific LP position exposure.
Amazing. Uh, so before we go to the Q and A front audience, uh, Neo and Katz, uh, do you have
any, any, any ideas on these questions or we can, uh, move on?
Uh, I'll quickly give a shout out to the prediction markets idea that I saw on the ideas list for the
hackathon. I'm a huge fan of prediction markets, so I would love to see what, uh, you know, what
people build in that category. Uh, but aside from that, nothing to add.
Yeah. Agreed with all the above. Cool. So, uh, I know that we are a little bit, uh, tied on, on
the timing. So, uh, we will do, uh, a very quick Q and A sessions from audience. So for all of the
audience, if you have any questions for any of the speakers today or any specific questions for the
hackathon, uh, hackathon, uh, it's the time for you to jump in. Uh, I will start with the first audience. Um,
Uh, I'm not sure. It... It seems like, okay, so the first first audience is connected. Uh,
the the the name is in eminent do you have any questions for for any of the
speakers today that you want to bring up
or yeah maybe like one block crypto if you have any questions here i just want to ask what what
makes injective better than other new blockchains our own yeah i guess that's the questions for
eric to answer yeah sorry uh um against what blockchain what makes injective better than
other other new blockchains that run oh yeah um uh by a new blockchain could you elaborate
and give me some example yeah maybe say sui or a for example
yeah i i think for injective's case it's you know uh specialized in uh you know financial
applications especially with these type of native modules uh with you know uh being the largest uh
finance focused blockchain and you know the most mature one um it certainly you know um has
already evolved a lot since its first uh inception and will continue to improve
and this means that you know any type of development against compared to like you know
generalized environment uh will be focused towards uh developing or you know optimizing
uh for any type of application use cases for the you know financial uh kind of sector
and over time obviously um no matter what is the you know latest and uh greatest thing uh or you know
some new primitive that comes out um injective can you know evolve and adapt and make it you know
uh um more kind of tailored to financial applications and this allows basically injective to you know
always be at the forefront of you know new primitives and at the same time you know ensuring that
um these class of applications will always uh consider you know injective the best destination to do so
great um thank you for the thank you for the uh questions uh and we move to the next uh audience
today i guess it's uh amir uh the twitter name is solid web3 guy uh you are a speaker right now and
feel free to ask any questions that you have in your mind right now
hello um can you hear me uh i think like if uh this is i think it's the great time for
you to any ask any questions that you might have um so don't waste this uh uh great chance uh okay
two more audience jump in and uh there will be the final uh audience to ask questions so um
hello the new audience uh that enable as a speaker can you do you want to ask any questions from your
side i think the twitter name is hard hard token dot ing seems like a enthusiast of injective ecosystems as
um um um um i don't really have um much question to ask i just want to ask if um um um
arts are inductive you they have some kind of interest and uh
oh i'm sorry i didn't catch that
uh uh yeah same here actually do you mind to repeat your questions again
okay okay never mind uh i think um like if you have any questions that uh didn't got chance to ask
this uh doing this twitter space always feel free to reach out to any of the speakers or their team i
believe they're more than happy to uh i believe they're more than happy to answer uh the questions
that you might have in your mind in the future um and i think uh we are a little bit over time and we
can pop up here uh i'm sorry my network was all bad i think i'm back now
so can i okay yeah feel free to uh last last shot yeah actually i don't have a question to ask but i
don't know if i'm permitted to like uh discuss about uh i talking indexive like just a few minutes or seconds
i don't know if i don't know if i'm permitted to do that
oh sorry uh uh uh what kind of uh stuff
i can't hear you sir what do you say
i'm really sorry i'm having trouble um sorry could you could you say again i said i don't really have a
question to ask but i don't know if i i have the floor to discuss about a token if i'm permitted to
do that uh actually i think uh it's not allowed to do like anything else if it is unrelated about
today's uh three space topic so maybe you can reach out to uh the teams later after this twitter space
but uh we want to keep focus on the uh questions that is related to the topic uh if that's okay for you
uh i'm sorry for asking that i i can't think since our token is kind of our inductive uh community
of projects so that's why i asked uh for the permission to like introduce it so but if i'm not
permitted no problem i can actually like find a way sometimes yeah no worries you can always ask in
the telegram chat and of course i've always been a big fan and i've been following your
charity efforts for the longest time so really appreciate it okay so no problem no problem thank you i
really appreciate thank you uh yeah and i think we can walk up here uh i would like to appreciate all of
the uh audience again for joining us for today's to the space uh and of course uh thanks all of the
speakers today to give such a wonderful uh uh talk not only about the technical details but also about
the hackathon itself uh just like brian mentioned that the very very early there are still like
around two weeks left for the submissions uh of illuminate hackathon so uh if you are uh trying to
build something uh around injective uh please definitely see size's chance to join uh one of the
most vibrant uh ecosystem right now in the blockchain space um yeah uh and uh don't forget to uh check
the hackathon page on the rahax website you can actually uh either upvote or follow or even donate
some of the uh funds to support uh the hackathon uh teams actually uh through our website so don't forget
to show some love and support uh for this uh villains uh developers and early stage teams and uh yeah uh
uh eric uh kaz neo anything that wants to be added here uh before we wrap up
no really appreciate it thank you so much
uh sure i mean it's just like a little proposal can we in the future maybe have a
a ninja game for the ambassador program would be very cool yes oh yeah sure yeah we'll we'll look into
it it's actually something we've been thinking about yeah thank you
uh great yeah uh that would be the last questions from audience actually uh and yeah uh thank you
everyone for joining us uh definitely uh keeping uh uh definitely keep your eyes on the uh hackathons
and there will be more uh more exciting announcements uh following up uh and yeah uh thanks guys for joining us
us today thank you very much for your time and uh looking forward to meet you all in the injective