Projects
![]()
No projects found
Investors
New
DAO Treasuries
DATs
Lend / Borrow APRs
Chains
Categories
Spaces
Bectra Upgrade on Berachain
Recorded: June 4, 2025 Duration: 1:19:21Space Recording
Short Summary
BearChain's recent launch of Vectra introduces groundbreaking updates, including EIP 7702 for account abstraction and EIP 7002 for enhanced withdrawal capabilities, signaling a strong commitment to growth and innovation in the blockchain space.
Full Transcription
Thank you. Hello, hello.
Hello there.
I think we're just waiting for some more speakers. Thank you. Yay, multiple co-hosts.
Amazing.
Yay, Twitter tech working as intended.
Check, check.
Is this thing on?
We can hear you.
All right.
Nice. We've got people funneling in.
I think we're just waiting for Caldera. Thank you. I see Cal in the audience.
Should we come up shortly?
There we go. Alrighty. I think we have everybody
Grizzly, Cal
Rez, what's going on man
we gotta get you up here
BM, what's up
what's up Cal
hey, what's happening
we've got some nice big brained Hey, what's happening?
We've got some nice big-brained barrows on today to walk us through Vectra.
Yeah, I'll get us started.
I don't know, for some reason on my Twitter spaces, it's just showing that Rez is still a listener.
So hopefully we get him up shortly.
But let me start off just to get things going.
So hey guys, I'm Manny, Lead Developer Relations here.
Today we're going to be talking about Vectra,
specifically the new update that happened today,
exactly at 1 p.m. EST, Smooth as Butter.
We're going to be going over the topics of the new upgrades that happened today over specific questions in terms of different IPAs
and what happened in terms of new updates,
new functionality that developers, users, and validators
can kind of expect.
We're going to be holding questions
from the audience to the end,
but feel free to reply to this post
with the questions in written form so that we can also be able to take those questions as well if you don't want to come up and actually talk.
And make sure to look out for the resources.
We'll hopefully be pinning to this Twitter space as well.
There's a bunch, everything from new tutorials that some of the other dev roles have worked through,
core team in terms of very interesting updates that have come that have been implemented with bektra including blog posts so definitely look out for the pin messages
that'll be up at the top so again today's agenda 1 p.m hard fork happened which is really interesting
is that bear chain is probably one of the first evm chains to adopt all the new functionality
after a theory magnet so big recognition to to the core team for deploying so fast in such a short amount of time.
This is definitely a big kudos to them.
And the upgrades come with a bunch of EIPs.
Most notably, probably, is Valider Withdrawals, so Voluntary Withdrawals, which is really big,
and EIP 7702, which further expands on account abstraction.
So we're really going to dive into these, but I want to give it to the rest of the team
here to kind of do small intros.
So I'll ask a brief intro about who you are, what your role is, and the EIP that you're
probably the most excited about with the Backstreet Upgrade.
I have Cal at the top of my list. So Cal, I'll
give it to you first for the first intro. Yeah, what's up guys? I'm Cal. I've been working on the
core team at BearChain for a while. And yeah, I've been helping ship a lot of our EVM and
consensus layer stuff and some of the ties to proof of liquidity
and all that fun stuff.
So yeah, Pectra has been super exciting to get out finally.
We've been pretty heads down on it for a while.
So I think after working with it, I think some of the most exciting stuff
comes in the execution layer.
I'm super excited about how we have BLS verification as a possibility now in the EVM,
which it's been a long time that people have been asking for it.
And it obviously enables a lot with BLS being such a go-to signature scheme.
So yeah, I'm pretty excited about that.
There's a lot of basic permatives
that we can now do with this EIP.
Nice. Let's popcorn it to Rez.
Hey, everyone. I'm Rez.
I'm a blockchain engineer slash core engineer here at Baruchain.
I've been working as a blockchain engineer for more than five years now across various
core roles. The EIP I'm most interested with is actually EIP 7685, which is one of the
underrated EIPs, but I'm not going to spoil the beans right now. I'm going to save for
later, so I'll pass it on to the next person.
Nice. Grizzly is next up.
Yeah, hi, everyone. I'm Grizzly.
I'm the CTO of Baruchain, and I am thrilled with 7702,
so we will talk more about that in a minute.
Amazing.
So let's get into the beans, as Rez mentioned. So the first question
I probably have for you is, for just the team, is how did we manage to upgrade to Pectra support so
fast? You know, it seems like it was only yesterday. And in fact, it was probably like a few weeks in
terms of us, when the announcement for Mainnet
was going to go in terms of them deploying
and then us just getting to Pectra so fast.
So we'd love to know what went into that effort
in terms of getting it out so quickly.
Yeah, yeah.
I can talk about that a little bit.
I mean, I think it's a big representation of how we ship code at BearChain. We're pretty fast about it. We're staying on top of stuff. the execution layers one-to-one from Ethereum. So we really don't have to work on anything
on the execution side.
We just focus on making sure the consensus layer
handles all the new hard fork requirements
from the execution layer.
And then we just tie it all together.
So thanks to our amazing beacon kit design, we can just work on the consensus layer.
And I think that's super cool because we spent most of our dev time just working on enabling withdrawals on the consensus layer.
We didn't really have to think about the know, improvements and all those things. So it's a big relief for us.
And then, you know, we can just ship fast.
And, you know, that's how we got Pectra out on Testnet in just, what,
like on the same day, I think, that Ethereum launched Pectra.
So we were able to kind of just keep that speed going.
And, yeah, I mean, shout out to Core Team for shipping fast.
Nice.
And I think one of the things that came from that as well,
just because there's so many new changes that are coming,
there are specific changes that apply to Barachain.
And I did note, and I'll pin it here
in terms of Cal actually making this post just recently about
BRIPS. So I would love to know
how is this going to be different from RIPs
from specifically Ethereum? How does that relate to us? I'm really curious as to
this over direction that we may have kind of going forward too.
Yeah, well, I think the BRPs are just
trying to get our, the idea is just like EAPs. I mean, we just want to get
development in the open now, make sure that we're kind of listening
to what people want, what developers need on bear chain, what the UX
is missing, how
it can improve.
So that's the idea behind Brips.
The first one that we wanted to put out was just about some of the issues with gas and
just general EVM feel and performance.
We noticed that if we can make some tweaks to the base fee market that exists in the execution layer, we might be able to improve some of the UX for users.
So we just wanted to put out the first one is get the discussion going on.
Can we fork the execution clients and maybe improve our system?
and maybe improve our system.
That's kind of the starter,
but there's a lot to discuss
in terms of future improvements,
protocol improvements.
So yeah, it's exciting to finally get that out
and then hopefully people can start contributing as well
from the community.
Love to see that.
Nice.
And then where people can actually find
some of these BRIPS are on hub.forum.bearchain.com
so look forward to those there's probably going to be some really exciting stuff coming in
in the coming weeks or if not months of some big changes that we actually see um so we'd love to
see if you want to follow along i definitely recommend checking out the forums. So let's jump into some
of the EIPs now. You know, there's quite a few. And I just want to start off with, we'll go down
order of like preference in terms of things that are minute user experience that really improve
things in terms of just, you know, hey, everyday life in terms of quality of life to like really
bigger features like 7702. But to start off, let's talk about
EIP 2537, which is BLS precompiles. So can I ask you guys, like, maybe give a rundown? You know,
what is this? What is a precompile? And you know, how does it apply? Like, why does it matter for
users? Why does it matter for potentially validators or and or developers? Yeah, sure.
I'll jump on this one. So if people may or may not be
familiar with the EVM, precompiles are kind of this built-in code into the EVM that are generally
used to facilitate computationally complex things that otherwise you might have a hard time and run
out of gas doing basically with just straight EVM opcodes. And this EIP in particular,
2537, I won't go into all of it. It's got a lot of historical baggage to it. But the short story
on this is that the primary use for this precompile is to verify zero knowledge proofs.
And the history to it is that there actually is another precompile
that's based on a different curve called BN254
that long ago was identified as having a significant attack to it
that lowered the security level.
And this is something that the Ethereum community has waited a long time
to see the upgrade here to this BLS precompile.
And I almost think that the most significant thing is that it's evidence to the fact that Ethereum is starting to really move
much faster as well. I'll leave it at that. I won't go into too much more. But on any EVM chain
and our chain in particular, this is an unlock that allows for really secure, a bunch of different
use cases, but the primary one being ZK. And in a previous company,
I worked a lot on ZK. And I would say that it's not something that we're leveraging just yet at
Baruchin, but it's something that you can look for in the future as well, because there's a lot
of power to it. And correct me if I'm wrong, we're using, like, BLS signatures are also a part of
the valid or deposit. Isn't that right, Grizzly?
Yeah, yeah.
The odd state that Ethereum's been in a while is that BLS 12381, which is the curve system here, was identified by the community like years and years ago as being the better alternative to be in 254, more secure.
So much so that when Ethereum on the consensus layer had to pick a curve
system, they picked BLS-12 at 381, basically, to use because of the security properties
and because it's pairing friendly and some other stuff like that.
But then they were in this odd state for years where the consensus layer was using the BLS
curve, but then the execution layer only still supported this previous generation of zero
knowledge, which had, you know, not a catastrophic security weakness, but an attack was identified
against the BN curves that lowered the security to a level that was not what we wanted.
Yes. And then if I recall correctly, this will actually also help people who are starting new validators with their initial deposits to actually verify the signatures going through for their initial deposits.
Because before, if you process a transaction, it would actually only be verified on the consensus layer. So now if you send an invalid transaction for those deposits, you'll get feedback right away. And you potentially, like there's a good chance that you, well, there's not
a good chance that you will not lose funds in this case. Whereas prior, if you did mess up that
signature, there was a good chance that you will lose some funds. So I think this is a good like
guardrail for anybody considering becoming a validator in terms of initial deposits. So BLS
signatures within, I definitely recommend
checking out our contract, the 4242 contract, so OX424242 on Berescan. It should show what that
is in terms of that verification for the deposits as well. So moving on, let's talk about EIP2935,
historical block hashes.
So could somebody tell me a little bit more in terms of what it was like before and after this,
and why does it matter for developers and users?
Maybe, Rez, I can get you to kind of chime in on this.
Yeah, sure. Thanks, Manny.
So one of the things that can be really difficult to do as a smart contract developer or even on the blockchain itself is to introspect historical states.
So asking yourself the question, what was the state of the blockchain at a point in time in the past?
So as a smart contract, that's actually very difficult to view from the view that a smart contract has of the world so this is actually pseudo addressed by eip2935 where we're actually posting historical black block hashes on the chain you can prove to
a smart contract in a much better way than before what the historical state was like at a previous
point in time so this also supports the l2s that also use this in a certain way.
But yeah, generally for app developers,
it's not going to be used for everyday app developers, I'd say,
but there are several infrastructure players that can take advantage of this.
I'll wrap it up there.
Nice.
So really, really, just for developers and users,
they can really see the advantage from that longer block time in terms of being able to kind of capture that information.
If I'm not mistaken, it's 8,191 blocks.
Is that right, Rez?
Or is it before it was like 292?
And then before it was 256.
Is that right?
Yeah, yeah.
It was much shorter.
Nice.
Nice. right yeah yeah it was much shorter nice nice so let's move on to the the next one which is uh
eip 7002 exec withdrawals um so maybe i can get um cal to start on this in terms of uh walking
this through you know how are you know this is in relation to withdrawals in terms of staking
withdrawals you know how are withdrawals typically done before this implementation, you know, and what does it mean for validators and stakers?
Yeah, yeah, that's a good question. So 7002 is like, just to preface, like the previous two
EAPs we talked about were execution layer, 7002 has to do with more of the big change for us is on the consensus layer.
So previously on bear chain, before this hard fork,
you weren't actually able to trigger a withdrawal if you wanted to,
like intentionally.
Some withdrawals could still happen.
And by withdrawal, I just mean, you know, your stake balance kind of just like decreasing.
And by withdrawal, I just mean, you know,
your stake balance kind of just like decreasing.
So that could happen previously if, you know, you got kicked out of the active set, which right now I think we're at 65.
So no one's gotten kicked out yet.
And then or if, you know, you staked more than than you're allowed to on BarraChain, which is right now 10 million Barra.
So those were the only types of withdrawals.
They weren't, you know, you couldn't trigger those, like, intentionally.
You'd have to, that would just be an effect of the system.
So now with the CIP, we actually are allowing you
to trigger that from the execution layer,
which is the cool part here.
Nice. So we didn't have withdrawals before.
We do have them now.
This is the method to be able to do this.
And how does this differ from the ETH spec for withdrawals?
And is there a potential roadmap to make this more aligned?
Or is there a reason to diverge away from that?
Yeah, yeah.
I mean, so we're not exactly one-to-one with Ethereum here.
So Ethereum allowed you to basically withdraw through the beacon chain previously before they enabled Pectra.
before they enabled Pectra.
We never really implemented that mechanism
because of the beacon communication layer
that we're not fully one-to-one on that side with Ethereum.
But because of that, we don't actually support
the pre-7002 withdrawals for validators.
7002 withdrawals for validators.
So that means if you can't invoke the smart contract,
the pre-deployed smart contract for 7002 from your withdrawal credentials,
you can't basically withdraw on Baruchain.
So it's not really that big of a deal for most people
because most people set their
withdrawal credentials as an EOA. So you can always just call the contract. But if you have
it as a smart contract for maybe some liquid staking solutions, you would have to be able to
call that 7002 contract from the smart contract itself. So it's something that we're probably going to be addressing soon for anybody who is a validator
that is setting up a smart contract. Is that fair to say?
Yeah, exactly. Like if you're a new, if you're a new validator and you want to spin up,
you know, your credentials as smart contract, you can just make sure that you're compliant
with the 7002 contract specification. If you're an old one, you would just have to make sure that you're compliant with the Sends user to contract specification. If you're an old one, you just have to make sure that's possible
or we can figure something out as needed, basically.
But at the same time, this is pretty exciting because withdrawals makes it more interesting
for more LSD solutions, maybe even pool staking solutions to come out as well
because now people can deposit and
withdraw. Like what a concept, but yeah, very exciting times.
But at the same time it is like,
it's the next evolution in terms of just making sure that, you know,
withdrawals are, are working exactly. So this,
this does introduce a slew different different potential products and
functionality as well. But as it relates to this, because 7702 is very similar to,
if I'm not mistaken, 7685,
where it's an execution layer request
that is performed for a consensus layer typical functionality
in terms of getting withdrawals, in terms of its status, etc.
It's almost that abstracted request coming from the execution layer
that's really giving or making it possible for consensus functionality
to be exposed from the execution layer.
Why are we seeing these types of requests more and more?
And maybe, Rez, you can talk to this because as an amazing core dev,
you probably have touched on this quite a bit as well.
Oh, Manny, thanks. You flatter me.
So EIP 7685 is the one that I mentioned at the start as well.
So it actually, one of the reasons I like this is it actually starts to set up a pattern for the actual protocol making transactions that are special.
So for example, the withdrawal request that currently is introduced with Pectra that,
you know, Cal spoke on briefly, that is one of the execution layer requests.
And the way it's designed in the protocol is it's actually a gas-free transaction that
the protocol itself makes, you know, to the chain.
And it's treated as this
sort of special enshrined transaction and this pattern i think is actually quite interesting
because what it means is that we have this boilerplate for innovation that we can actually
capitalize on in the future so things that we can ask ourselves are what would it look like if we
enshrined other transactions using this same mechanism and treated them kind
of special and started to really differentiate ourselves from other protocols the other reason
that execution layer requests are great is that it kind of breaks this pattern that the interactions
between the execution layer and consensus layer previously had where to get information from the
consensus layer it would often require the consensus layer querying the execution layer.
And then you have this multi-way communication going on, which from a technical perspective, it basically meant that it was a fragile system.
So really what it does is it's starting to make the system much more robust, much more concrete, but also creates something that we can extend on and hopefully innovate on in the future.
And how would you differentiate this between precompiles, for instance?
You said that they don't cost any potential gas.
Obviously, precompiles are specific functionality
that would be ingrained in terms of execution clients.
How does that differ from this, out of curiosity?
Yeah, yeah, that's a great question.
So precompiles, generally, other users
or other smart contracts will actually call the precompile. But thencompiles generally, you know, other users or other smart contracts will actually
call the precompile. But then the question is, what if the protocol itself, every block called
the precompile? That's when you start to understand what an execution request is. It's effectively
self-triggering transaction that doesn't require a third party to actually interact with that contract, which is kind of an interesting paradigm shift.
Got it.
Okay, well this is actually really interesting
because it almost seems like it's very much like you mentioned,
like a template or a framework to be able to introduce
new functionality and get access to consensus,
the consensus layer from the execution client side,
which is, this is basically giving us more access
from, you know, Reth, Geth to BeaconKit
and actually effectively communicating anything,
anything from the consensus client, including state,
which is really interesting, I would assume also for,
you know, if you're trying to do, you know,
staking across chains potentially as a hypothetical,
you could try to find out what the state is of a node
via just the execution client, which is quite interesting too. So moving on to our very last
EIP that we really want to talk about, which is probably the biggest upgrade that a lot of people
have been looking forward to, which is EIP 7702, which is setting code for an EOA. So I just want to go briefly into this.
And Grizzly, maybe I can get you to chime in on this.
But, you know, what is like 7702 in your own words?
And why is it a form of account abstraction?
Like, why is it like labeled as such?
Well, yeah, it's a great question.
There's a lot of history to what's going on gone on here
um just to to kind of lay some groundwork and a bit of a history lesson i'm not sure people
aware of this but the the the core problem is the lack of flexibility of the core off primitive of
ethereum the the signature scheme and the and the way that it's incorporated. And the need to fix this, the need to improve this
was identified in the earliest, earliest days of Ethereum. So the first EIP that proposed
improving the user experience through adding account abstraction was EIP 86. And it was
proposed by Vitalik in 2016. And then nine years later,
after all the machinations,
after everything,
after the merge,
after all these big changes,
7702 is the first EIP to ever be incorporated
that directly enables better UX
for the user experience.
So that, in my view,
is both the significance
and also, you know,
it's just kind of a statement
about kind of the way that Ethereum has you know, it's just kind of a statement about kind of the
way that Ethereum has evolved to where it is right now. The core way that 7702 does this is to
introduce a very, very, very powerful primitive, which essentially just allows you to take an
existing EOA and attach arbitrary code to it. And then it's very powerful, but then
also very interestingly, in some ways, very unopinionated because the details, the standards,
the fleshing out of account abstraction will actually be done with smart contracts and standard
smart contracts with the EVM. So 7702 is just the core primitive that allows you to do
that attachment. And then very importantly, also allows you to unattach, allows you to take the
code out, which is kind of the primary difference between, again, history lesson. The other standard
that was almost made it across the goal line is 3074, which we won't go into. But I think the 7702
addresses the primary security concern that stopped the Ethereum world from incorporating
3074, which was 3074 had no way to back out. If you made a mistake, you were done, basically.
7702 allows you to unattach code as well. So that's kind of like the, you know, the gist of it. It's a
very powerful primitive that opens up the whole design space of the EVM to improve the user
experience. Got it. So what I'm hearing is, you know, prior to this, you know, again, most EOAs
wouldn't have any code associated to them. This is an interesting paradigm where now we can associate
code to them and we can actually remove it or keep it persistent.
It's definitely up to the OEA in terms of the user.
But you add all this functionality, for example,
potentially gaining access to your wallet to be able to spend ETH,
which wasn't possible before.
We have to use WRAP tokens.
So there is a lot of ways where you can kind of give permissions
to different users, right?
But you talked about something interesting,
which is like the permanence of the code
as well as the, you know,
and the impermanence of that code
in terms of, you know,
you have the option
to be able to remove that code.
How does 7702 differ
or potentially work with like 4337
as an example,
as it relates to that too?
Because 4337 obviously is the code that's relates to that too, because 4337 obviously
is the code that's actually going to be permanent here. There's no way to change that unless you
have like some sort of upgradable contracts, right? But can you talk to a little bit how,
you know, the dynamic between those two EIPs potentially work together or their differences?
Yeah, I mean, 7702 was intentionally meant to be complementary to 4337.
It's kind of an important detail, but 4337 is not technically an EIP.
It's an ERC because it's actually a smart contract standard. And very importantly, 4337 made no changes to the protocol and was almost like the best you could do to build account abstraction without changing the
protocol at all. And it had just some really core weaknesses and fundamental. It was actually very,
just very difficult to implement correctly. And I would actually offer that I don't think anybody
is actually truly implemented correctly. However, what 4337 did have is the concept of a smart
contract wallet. In other words, and this is probably like the biggest kind of conceptual change to account
abstraction is that the way this is thought of as an ideal is that it's actually a smart contract
wallet on chain that would be the entity that holds funds, the entity that owns things,
basically. And then the EOA or some other off function just essentially tells that smart
contract what to do. It tells the smart contract to, you know, to authorize an ERC-20 transfer.
It tells the smart contract to send funds to someplace else. And then 4337 actually did go
a long way towards establishing the smart contract standards that enable that. 4337 also
had a lot of flexibility, but a lot of vendors, a lot of people in the ecosystem coalesced around
like canonical definitions of user ops and kind of built out some good standard framework.
And that's actually what's necessary for 7702 as well. Like I said, 7702 is unopinionated about
the actual code, the actual smart contract itself.
And there's some subtle differences, but I think what you'll see is many of the same concepts
that were adopted for 4337 will be adopted for 7702. And I think I haven't actually worked
through it myself or haven't seen anybody do it, but i think you could actually just use 7702 to attach to an existing 4337 wallet and control it so this it's meant to be a lot of
synergy between the two standards and work together and like i said there's still a lot of work to do
to actually nail standards to the floor make things interoperable and that's actually where i think
you know we have a lot of plans for bear chain to help facilitate that in our ecosystem, but then in the whole EVM ecosystem as well.
You said something interesting there, which is the difference between, and there's a clear distinction here between EIPs and ERC, which is a core change versus a standard.
In this case, 7.702 actually, if I'm not mistaken, it introduces a new opcode specifically for set auth or set code.
I can't remember the actual opcode for this.
That's a big distinction in terms of it, but I love how you say that it's
very much unopinioned in this sense. It's like, hey, you can set any code for that
EOA. It could even be like a hello world contract, doesn't matter or whatnot.
4337 is really the standard to be able to say, hey, these are all smart accounts, should work.
This is how you give permissions. There's modularity with session keys, et cetera.
And you potentially can use like 437.
Hypothetically, you can use 437 to set the code for 7702.
So you're matching the flexibility with 7702
and the standards of how account abstraction goes with 437.
It's a really interesting dynamic in terms of marrying the two together.
And I think one of the major things that come out of it is improved UX when it comes to batch transactions.
And I think historically we have quite a few different types of batch transactions that have come over the years.
Everything from using a relayer to multicoll 3, permit you know, using 437 with bundlers and whatnot.
You know, could you give us like maybe the,
like a TLDR in terms of like, what is the comparison?
Like how does 7702 like compare to some of those
other implementations of trying to perform
or trying to get at batch transactions?
Yeah, so, yeah, it's interesting. The need for account abstraction has been so
prevalent for so long that a lot of different approaches, different kind of infrastructures
have been built out by various teams and various projects to provide better user experience. So
batch transactions, for instance, being able to submit the classic issue
of having to approve first
before you do an ERC-20 transfer,
you know, can be mitigated basically
by batching those things together.
I'd say fundamentally big difference,
and this is where 4337 started to make some progress too,
is that what we don't need in the ecosystem
are 10 different ways to do batch transactions, basically, and nothing interops together.
And that's kind of what seems to have with some of these account abstraction front ends and some of these like smart wallets and social wallets and stuff.
My concern there is like fragmentation of the standards and stuff doesn't interop together.
And then suddenly you have a wallet that works only with one chain and a wallet works with only another chain.
And then suddenly you have a wallet that works only with one chain and a wallet works with only another chain.
And I think if that's what ends up happening, then I think blockchain will have failed because you'll have like proprietary front end standards.
And that's just not acceptable. So 4337 standardized the way user ops work, standardized the way batching works.
And then 7702, I think, finally just gives enough kind of flexibility.
finally just gives enough kind of flexibility.
Like I said, it's unopinient.
It gives enough inflexibility
so that you can think of it
just being kind of enshrined
in the Ethereum protocol.
And so that becomes a canonical way to do this
as opposed to a bunch of fragmented ways to do it.
And an example of that is another proposal that's out there. It's called 5792. It's actually also, if I remember correctly, it's actually not an EIP either. It's an ERC because it's a standard, but it's a standard for wallets to submit batch transactions.
And I think MetaMask, we know, is working on it, which is great. But again, this is one of those things where we need standards to do these things so that wallets interoperate and systems interoperate together, because otherwise we'll just have fragmentation on the front end, which is kind of antithetical to the blockchain kind of ethos and what we're trying to do.
Yeah, I think ERC, my bad, 5792,
is going to be really crucial to 7.702 in terms of the front end.
Because if anybody has actually played around with 7.702
in terms of using VM or Foundry,
some of that you'll notice right away if you're trying to do it on a...
It works perfectly in terms of those libraries out of the box.
But if you're trying to implement it on a front end,
it will show you that you can't process this because JSONR PCs don't allow for that set off in terms of signing box. But if you're trying to implement it on a front end, it will show you that you can't
process this because JSONRPCs don't allow for that set off in terms of signing it. And the way that
wallet providers have gotten around this is they've implemented this new ERC called 5792.
There's actually a website that's dedicated to this in terms of a wallet call to be able to
deploy or set a batch transaction contract for your EOA, which
essentially makes it a lot easier natively to do it in your wallet. So I imagine there's going to
be a lot of other wallet providers, Rainbow, Rabi, a ton of other providers that are probably
going to follow suit in terms of this, which I think is just going to be better overall UX for
the user. It means single click to perform 10 different transactions. I think it's just going to be better overall UX for the user. It means single click to perform 10 different transactions.
I think it's really, really ideal.
And a small shout out, if you haven't seen some of the pinned tweets here,
there is actually a tutorial from Jintao who shows you how to do batch transactions.
So definitely look for that tweet.
He has a thread explaining how you can do batch transactions
and the actual code of actually doing that implementation
to be able to see what that would look like too.
So it goes into detail in terms of how you can actually play around with this yourself.
The next step is another feature of 7.702 is actually gas sponsorship.
And there's a distinction.
Again, we can compare it to 4.37 in terms of using bundlers for gas sponsorship. And there's a distinction, again, we can compare it to 437 in terms of
using bundlers for gas sponsorship. And pre-year account abstraction in terms of 437 was, we used
to use relayers as well for like meta transactions to be able to sign a transaction and hopefully
get a relay to be able to process that transaction. How does 7702 handle gas sponsorship a little bit differently?
Or how is it potentially better than these other solutions?
Yeah, so one of the core concepts of account abstraction
for a long time has been this idea of gasless transactions.
Can you submit a transaction and then an app or someone else
pays the gas on behalf of the user.
And that gets around one of like the core usability issues of like the user having to
have gas in their wallet before they can do stuff.
This is another one where interestingly, I think the way that 7.7.0.2 is a massive unlock
is that previous to 7702,
like one of the biggest kind of implementation problems
with 4337, if you know some of the details there,
is bundlers, 4337 actually essentially required
that there'd be another mempool
outside of the core Ethereum mempool
that would be used to transmit these user ops
and to create bundles.
And it created this other separate role, basically,
or at least supposed another role, basically,
of this bundler that was aggregating these bundlers
and would submit on behalf of users and pay gas and get compensated.
And it's just super, super complicated to do all this.
And the TLDR with 7.0.0.2 is that it does away with that.
Because once you set up, like once you use 7702 to set up code in your account,
then the transactions that are being submitted
and the transactions that actually end up being executed
are just effectively the same as any other transaction.
Slightly more complicated
because you are going to submit like a user op
or sign something like a user op
as opposed to a base transaction.
But then it sort of enables the same functionality of essentially the end user signing something
that then is handed off to another entity to submit it and pay the gas, but is still
as secure because the internal smart contracts implement the account abstraction, will check
signatures and do everything correctly like that. But I would almost say that the TLDR and the answer is that 7702 makes this
more canonical and standardized and therefore I think has a better chance to succeed in terms of
interop because everything kind of like goes through the same mechanisms. And I think it's
kind of interesting because if you think about it,
it almost looks at it,
if you look at it from a spectrum
from complicated setup to very easy
in terms of simplicity to get up and running,
setting up like 4.3.7 for gas sponsorship,
there's quite a few different services
that you need to set up for 7.702.
It's like you can use the actual code to be able to handle the actual gas sponsorship.
And you can actually make it potentially even more secure because you could do an off-chain signature, pass it to another wallet that will happily sponsor you in terms of the transaction.
You can verify in the code that it came from you as well. And then you wouldn't necessarily need to worry about nonce management
in terms of some of the things that are a little bit of a restriction
when it comes to relayers because if you sign transactions
and if there's a specific nonce and you process other transactions,
it might become stale and that transaction might not go through
because you've passed that nonce value.
And I think it's really interesting because you could really
essentially get at this idea where, hey, I'll sign a transaction,
pass it off to Grizzly and say, hey, I don't have any gas for this.
I've signed this transaction, but if you can sponsor me,
pay for my meal, and then if I have some ERC-20 tokens,
I might even be able to transfer that to you within it
to be able to pay you to be able to process that transaction for me.
And all in the actual contract code, I could set it up to really just say, hey, I'm proving that this is actually coming from me.
I'm not coming from a third party, et cetera.
So it can actually be more secure.
Sorry, go ahead.
Yeah, I would say 100%. And what I would kind of read that back as is that what 7702 and account abstraction will now let apps or ecosystems do is build kind of backend infrastructure that handles all the cruft of receiving away, but ecosystems can do it and provide that service
in a way that still has both the correct trust assumptions, but also the correct, shall we say,
like decentralization assumptions. That can be like a back-end service that an app provides
that they're doing on behalf of the user, but there's no compromise in terms of the sovereignty
of the user and the fact that the user owns the keys.
So it moves us closer to having that role in the system that doesn't, like I said, degrade
one of the core concepts we're after here in blockchain is to keep the sovereignty of
the user.
And I just want to also give a small shout out to Ichi, who's one of our new DevRels.
He wrote an article specifically on gas sponsorship. user. And I just want to also give a small shout out to Ichi, who's one of our new DevRels.
He wrote an article specifically on gas sponsorship. It's pinned to the spaces. It goes over the actual code. It shows you how to be able to, you know, what does that look like in terms of gas sponsorship?
How can you offer an ERC-20 to be able to pay for that gas sponsorship for the person that's
sponsoring you? Definitely look at the thread in terms of explanation. There's code examples. Definitely go through that because it's a great example.
Now getting at the last two, I think key benefits, and you kind of talked about this
a little bit, Grizzly, which is the idea of having your keys to yourself and you're actually having
full ownership and you get to control every aspect of being able to give permissions.
So there's this concept of giving, because it's so flexible
in terms of 7.702, you can program almost anything in terms of fine-grained permissions.
How would this work in terms of what kind of scenarios
could you see where this would apply, where you're just giving
all different types of permissions to different users to be
able to give access to your account.
And maybe even how does it relate to BearChain in terms of our existing ecosystem?
Yeah, I mean, there's so much design space here.
It's tough to kind of really summarize it.
But I mean, the long and short of it is that it opens up the whole EVM to design space.
And so this idea of fine grained permissions is extremely powerful.
So a way to describe it would be you could actually set up a system where, and this could
be like a log on to a game or log on to some application where I have an EOA that has kind
of non-trivial value.
And I have coins, I have NFTs, I have everything.
And for whatever reason, I need to use this account to log onto something.
Account abstraction, these type of primitives would allow me to sign a transaction
or sign a user op or some other blob of data that effectively gives an application the right to transact on my behalf,
but for a very limited scope.
I mean, you can imagine basically that it could just be the scope of an application
could just be the set of the contracts that that application provides.
So whatever type of contracts, games, or maybe it's like liquidity.
So do an individual method.
This application can call this NFT method on my behalf.
And what that would allow is the backend system to provide, since it can transact on your behalf of that limited scope, could be, shall I dare I say, a very Web2 experience. In other words, you're clicking buttons or doing something in a UI.
And then when you do that, the backend system is doing something on your behalf and paying
the gas for it.
But it's within a very scoped and narrow set of restrictions, basically, that allow it
to be safe and to still allow you to have a very unified kind of, you know, account and view of
the world. Again, that all has to be worked out in the contracts behind the scenes and the details
of it. But it's a very, I mean, it's a very powerful design space too, because it could
also allow just even, for instance, we're looking at it for POL, where there's aspects of POL where,
you know, I don't want somebody to be able to unwrap BGT on my behalf,
but I sure would like somebody to be able to take my BGT
and boost it on a daily basis for me.
And right now there's ways to work around that,
but, you know, spoiler alert,
this may be something that we end up building very soon.
How about a bot can just do it on my behalf
or how about I can delegate it
to an account that I can, it's not a hardware wallet. It just opens up this massive design
space for applications to fine tune the user experience, keep certain things very secure,
but then also make, you know, less more trusted kind of interactions on your behalf.
So this is a small alpha then Grizzlies?
So this is a small alpha then Grizzlies? Is that where we're getting at?
Is that where we're getting at?
I'll say that, I mean, your team,
the DevRel team here has done a fantastic job
of just kind of getting information out there
and talking about the power of it.
But I can tell you for a fact that,
I mean, our smart contract devs and our UI devs
are very, very interested in 7.7.0 too
and already brainstorming how to improve UX everywhere,
but also, you know, not surprisingly, improve our own UX internally
with the apps that we provide and the infrastructure that we provide.
It's kind of interesting that you talked about being able to,
there's possibilities of giving people permission over your BGT
to be able to boost specific validators.
There's potentially how you set up bribing for reward vaults in terms
of giving a proxy permission to the, there's some interesting aspects to be able to kind of automate
it without, you know, giving somebody the actual keys to your house. And, you know, just giving
them, you know, specific permissions to do specific things. I think that there's a lot of
different possibilities in terms of POL and improving the UX and even allowing for
better automation that comes with fine-grained permissions. And I guess one of the byproduct
of fine-grained permissions, and you kind of talked about this, is subscriptions potentially.
So how do you see it in terms of potentially subscriptions? How would that work in theory? And what would be the user benefits for users as well as dApps, in your opinion?
Yeah, I mean, again, you have the design space of the EVM and a subscription, like based
on what we just talked about, where you're essentially delegating to another system to
allow you to kind of operate on your behalf.
So like for a limited scope with certain contracts,
subscriptions is a similar concept, but just says that it's time-bounded.
That I delegate for the application to use,
to operate within these constraints, but then also only for half an hour. And if that sounds familiar to you, that's essentially like the Web 2 primitive.
That's how you interact, but it's inverted to Web two, right? You log on, you get logged out,
but you can imagine like this design space is such that you could go essentially build like
effectively what you could call almost like an online bank service, basically, where you could
log on to a front endend UI, delegate some restricted rights
to move your stablecoins around
basically for a limited period of time.
And then you're pushing buttons in a Web2 UI,
having it move money around for you.
And then you log off and you're done.
And then it's within a bounded period of time,
the backend service no longer has that right.
And it's kind of like the same security kind of primitives
or kind of like structure as what we think of as Web 2,
but it's inverted because you control everything
and you're just temporarily delegating.
I mean, in most cases,
like if you're going to use a service in the backend,
you trust that service within a certain like bounded way.
But then for absolute security,
you also have to, you don't want to just
kind of sign away your account and just give them full access to it. So, so you're, you're bounding
it basically, or the application is bounding it within a certain, like, just for kind of like
ideal security. But it just, and again, I think it just opens up this design space to create
very powerful, but very much more usable user interactions that also,
as we keep saying, basically don't fundamentally degrade the core concepts that we're after in
blockchain, which is user sovereignty and control basically of their assets and the ownership of
their account. So you're saying we have reached full circle in terms of Web 2.0 finally. We've reached it.
It just took, what is it, 10 years now?
Nine years or something like that.
Yeah, I think in the end state, Web 3.0 apps just more or less, most of them look like Web 2.0 apps basically.
But then they just have vastly, fundamentally different security assumptions.
And then you always have the right to
just explicitly control everything. Like you're not going to take your whole life savings, your
whole bag, basically, that's in a hardware wallet and delegate it to, you know, to, you know, some
arbitrary front end UI, but you'll, people will have sub accounts that they put stuff in, they
delegate to, and this all just has to get worked out. And this is going to take a long time to work
this out organically and get the right patterns for this. But this finally enables it. And like
I said, in a way that we can settle to shared standards and ways of doing it. Because, I mean,
a lot of this stuff already kind of exists out there with various solutions you can use as front
ends. But there's effectively just kind of Web 2, you know, solutions that sit in front of Web 3 technology.
And that's just not going to, you know, if the back end is decentralized, but the front end is
centralized, then we really haven't accomplished that much with Web 3. And this whole design space
of account abstraction is what also allows us to build front ends and, you ends and user experience that have the right tradeoff between sovereignty and usability.
You kind of just blew my mind a little bit if you think about it.
Because not only like you can set up subscriptions in terms of, hey, I'm going to set a specific amount of, you know, a frequency in terms of when it should take money out of my account.
This specific amount from this
specific contract or ERC20 token. You can set fine-grained permissions in terms of a subscription,
but I didn't think about it where you could potentially log into a site and set parameters
to say, hey, I give an automated trading bot or an AI permissions over my ERC20 tokens or my
gas tokens over a period of time.
Go to town, trade as much as you want to.
But as long as you don't go over a thousand honey, for that matter, in terms of my tokens,
you have that budget.
Go to town, see what you can make.
I've completely just abstracted that from myself.
I'm automating an AI bot to be able to go trade on my behalf.
It's coming from my account. I don't have to worry about other things. And I've set limits
from that perspective. And I don't have to transfer funds to another EOA to try to hopefully assume
that they don't rug me for that amount that I've given them. So I think it's kind of interesting
because it definitely does open up the possibility potentially also for AI and being able to get better overall control
and other features and functionality can come from 7.702 as well.
Yeah, it's pretty cool.
I don't know if anybody else had any other things that mentioned for 7.702
or some of the other EIPs if they wanted to mention them.
Otherwise, it's going to open up the floor to some questions as well.
Cal, Rez,
I see that Smokey's joined as well.
If you guys wanted to speak to anything
or even just congratulate our core team
for such an amazing job.
I will take silence as... Yeah, yeah, I think we should
when we're almost on top of time
we can definitely open up for a few questions or comments
if somebody has any
Perfect. One thing I will say as we're
moving into audience questions, I just
want to preface there are some rules here
that we are a shill-free
environment, so if you are
again, I would hope that you are
not going to shill certain things
and keep the questions on point in terms of as it relates to Bektra upgrade,
happy to kind of go over that.
If it is anything else, we'll probably kind of steer away from that
to be able to say, hey, we'll go into the next question.
So just a small guideline for that.
Let's go with internet money to start with for the first question.
First of all, can everybody hear me okay?
Yes, sir.
Well, I just wanted to say it was very exciting to listen to you guys dive in and pick apart the ecosystem from a very technical and dev-oriented perspective.
I don't think that enough ecosystems do that.
And it was very exciting to hear
that in-depth perspective from you guys
and actually get to listen to the builders
of the chain speak upon it.
So kudos to you guys for putting yourselves out there
and giving your time and energy
and educating your community.
I think that's all teams and projects should do that. So kudos. Now, I did want to say one thing
because you guys were talking about wallets. If you want to cut me off, if you feel this is too
shilly, I respect that. I just wanted to let you guys know that we are an EVM wallet that has
native Barachain support. We do a lot of cool
things for Barachain. And so if you guys are interested to know about that, I'll let you
dictate that conversation. But I just wanted to let you know that you have a wallet out there on
Android, iOS, and Chrome that's supporting what you're doing natively and making it easy for
Barachain users. So thank you guys. I'm happy to speak to for bari chain users so thank you guys i'm happy to
speak to it as much or as little as you would like well so um i appreciate that in terms of
this show so we'll probably won't talk about the the wallet specifically but maybe uh would love
to know in terms of if you're going to support 5792 as a wallet. That's probably the most important thing that we'll want to see for wallet providers.
So if you want to send me a DM as well
to kind of show me what the progress might be on 5792,
I would love to see how that kind of applies.
There's not a lot of wallets that have done this yet.
And for batch transactions, this is quite important for sure.
So again, appreciate your comments on the technical aspect.
Next up, anybody, I have Joey Roth on here as well.
Joey, did you have a specific question?
Not a question specifically.
I just wanted to congratulate the team on shipping Vectra.
From my perspective as a builder,
being able to atomically bundle multiple transactions
that you can kind of guarantee there's UX
where you're not going to get front run
doing certain things together,
just gives a lot more design freedom
and will lead to better Baruchain apps.
So yeah, congrats guys. I'm super excited to be building here.
Amazing. I love it when people come and just give us praise.
So we welcome more of that. So Joey, if you want to just praise us again,
you know, I won't stop you.
You know, there's a fine line between praise and glaze.
So I'm going to, I'm going to leave it there. But yes.
I think you actually just, you maybe just coined a term too, better barachain apps. I'm going to add it there. But yes. I think you actually just maybe just coined a term too,
better Barachain apps.
I'm going to add the B to it too.
And I'm really hopeful that this is what evolves basically
is that people start to notice that when they come to Barachains,
the apps are just better.
They just work better.
There's more kind of interoperability.
And that's kind of behind the scenes.
I think that's what 7702 is going to allow us to do it
and maybe other projects and other change
will eventually evolve
but this might be a little bit of alpha for us
that we're a little bit ahead of the game
and we're going to push that edge
Yeah, 100%
I think that the consumer experience
and ultimately the addressable market
with apps that we can build here
combined with the level of DeFi savvy interest and degeneracy
that we already have as a community
is going to be an incredibly powerful combination.
Wait, wait, we have DGents.
DeFi DGents, DeFi DGents.
We don't have the trenches yet, i'm i'm working on that very hard
so we're just optimizing ux for d5 dgens is this is what i'm saying that's what bear
chains like motto should be well i think it's two things i think it's like you want optimal
ux for d5 dgen because they're like the, you know, the little bacteria and stuff that colonize and make efficient and sort of create that perfect soil for like, you know, real, real stuff, plants and consumer products and things that have giant addressable markets to spring out of but it's not possible without creating like a playground for for dgens who are looking at farming strategies and how to optimize you know their yield on this and that and create
some carry trade you're not supposed to create so i think that you know we we're on a really good
path there um and the presence of that type of community that type of user combined with the
yeah the vector upgrade is a really good example but but just this focus on BAPS, right?
And like, what is the actual like user surface there?
Yeah, it's just a super powerful combo I don't see in other ecosystems.
I love the analogy that bear chain is growing,
fostering bacteria to grow plants, essentially.
Yeah, I think most, mostens I know, myself included,
would be honored by that description, actually.
I think that it's like, you know,
what are the pioneer organisms, right?
After some volcano pops off or there's a forest fire,
you have to colonize the blank land,
the blank slate, in order to have more complex things come in after you.
And I think that a lot of chains, a lot of protocols,
sort of leave it at that,
like just create a place for the pioneer organisms to come in.
They do their thing. And then it's like, okay, well now,
now what's happening, they tend to move on but i think on
barachain what i found both from like everything from leadership to like individual communities and
users who i interact with all day it's like we're doing this to to create this pristine
foundation this pristine soil so that we can have a ton of users who would never even think
about like farming something or doing these different strats or even using a vault directly
like it can be um yeah it can be something that uh anybody can engage with and can get value from.
But I don't think it's possible to just leapfrog directly to that
if you don't have that foundation of DeFi natives, DGens,
whatever you want to call it.
And we're on that journey currently.
Definitely agree. I definitely agree.
Let's keep making more bacteria. I also see, I just want to make sure, because we're also conscious of time as well, I want to see about getting to some of the questions in terms of threads, but I also see that Priest is up here. Priest, who's definitely been in our community for a while, do you have a question? Or if you want to start off with praise, we definitely welcome that as well.
Of course. So for
constructive praise, congratulations
to you all for keeping
back to us. I
really like the overview that you
guys gave.
I was reading some of the EIPs,
but then translating
that from a scientific
article for something that we can actually do,
I think it's great for us as a builder.
It's like you showing me a car,
but then what can I do with this?
So wait, can I move faster now?
So I think that was great.
So a lot of ideas come from you.
I'm sure the eco is going to be great,
but for the questions now, so you save your time.
I've seen, at least on the post,
that you are giving some facilitations for staking to your validator.
And specifically, you said that you have support for delegation.
Can you expand on that?
What kind of delegation is that?
Are you speaking specifically in terms of the
foundation-giving delegation, or are you speaking about how 7702 could support delegation
potentially through staking pools or other
LST solutions? Yeah, I'm reading the polls
from Beret Chain Foundation, and then you said, if you're staking or running a
validator, now you have more control
over how your capital moves.
Execution layer withdrawals
let you exit or rebalance on demand.
Validator operations are smoother
with better fee logic
and support for delegation.
I'm just in doubt what it means.
Got it.
If you don't delegate to a validator,
am I, Barrett?
Yeah, so what this is essentially getting at is
the idea that contracts can now support
a foundation delegation that's coming through
so that it can also support...
If you looked at specifically validators beforehand,
and this is before withdrawals,
I mean, this still exists right now,
you only have one withdrawal credential that's set up for a validator.
So you basically set that that's the withdrawal credential in terms of the UA.
That's one address.
Anybody can make the deposit, but you register that specific address.
So when you want to do the withdrawals, it goes to a single withdrawal address
in terms of you being able to do the withdrawals now.
As you can imagine, if Grizzly, Priest,
you guys are giving me Barra
to be able to stake towards a validator,
you kind of have to trust me specifically
to be able to give back the rewards back to you
or give you back your Barra.
There's a sense of trust that needs to be there,
but it doesn't allow a lot for parties
to be able to come out and say,
hey, I'm going to ensure that you get your money back on chain as opposed to, hey, just trust me, bro, in terms of your funds.
have, you know, account abstraction or permissions or even a pool to be able to allow for delegations
or for other people to be able to essentially to stake to the valid or to, you know, a pool.
So if you already are, you know, if you have an EOA potentially, and this is all hypothetical
in terms of what's potentially possible, you could have an EOA that is the single wallet credentials,
but you could also potentially set the code for that EOA to accept the funds and be able to kind of manage those funds
accordingly as that EOA specifically. So you could potentially say, hey, when you perform
this function for my EOA as a 7702 code, Priest, you call this particular function called stake,
which actually keeps track of it on my
side to be able to say, hey, I will take the money and actually process it for my EOA and then stake
it on your behalf because you've given me the funds. But I'm able to also keep track of that
as opposed to, there might be even a mechanism where there's a withdrawal. You call the 7702
contract, the EOA for that, and you could process a withdrawal directly from my EOA to get your funds back if you want to process a withdrawal.
There's an idea that you could do a lot of this in terms of just abstracting that withdrawal in terms of accepting delegation to make it a lot easier.
There's a possibility not only for pools, but also for existing EOAs to kind of be in place that have
been set as wall credentials to be able to figure out a way to get your funds back.
Obviously, they need to be able to have the code persist for the 7702, the actual contract
code for the EOA. But if they do, that's an interesting way where, hey, you know, you
could just apply existing code logic to existing wall credentials. So Priest, you have an EOA and you have the code.
I'm going to stake with you.
It stakes it to your validator.
I actually call the withdrawal.
It calls the withdrawal as if it was you and then returns me the funds.
So there's an interesting way where you can handle different types of staking positions
when it comes to 7702.
Again, this is a hypothetical, but it's definitely potentially
possible in terms of what's
there. Hopefully that answers your
question, Preece.
Perfect. Great.
One more question.
I've seen that on Ethereum,
they now have 0x
0x2 withdrawal credentials,
and basically that allows you to
automatically restake your ETH,
and you can consolidate validators.
How does that apply to Baruchain?
Or we don't have that yet.
Yeah, I'll let Cal kind of talk to this a bit more
in terms of how the restaking or withdrawals,
because he's definitely touched this way more,
and he's definitely a stronger engineer than myself
when it comes to this specific topic.
Well, yeah, I mean, the question about 0x0 to withdraw type
is not really relevant for Baruchain right now,
so it's something that right now we chose not to implement.
On Ethereum, the problem being that there's so many validators
that have to have been spin up for that 32 ETH requirement.
Like if you want to stake more than 32 ETH,
you just start spinning up more and more nodes.
That's not really the case here on BearChain, right?
We have nodes with much larger, you know, staking sizes.
So there's no need for, for those like some smaller nodes to just consolidate.
So that's what zero X zero two enabled.
I think in the future we may look at, you know,
if as a validator set expands or shrinks or changes over time, what type of,
you know, consolidations or new, you know, things we need to put in there. But for now,
there's no need for consolidation on bear chain. And in terms of, I mean, the restaking question,
it's slightly unrelated, but I think, you know, right now the primitive would probably be use a liquid staking solution like Infrared or Smiley or the others and get your receipt token for your Bera.
And from there you can kind of use that in other places in DeFi and stuff.
Gotcha.
Yeah, for the last question,
do we currently have a way to monitor
the validator state, the beacon state on the EVM?
I'm asking because on bearaching at least,
you can be kicked out of the active set
if you don't have enough
better and the validator stakes more than you and what happens in effect is that if you try to stake
to this validator again you effectively burn your bearer because it exited is there a way to monitor
this on the evm or you still need to rely on off-chain monitoring?
So a couple of things.
I think in terms of the first thing is you mentioned staking to a validator that gets
kicked out.
If you do send like some bearer to that validator, um, that, that validator
still exists in the beacon chain.
It's just no longer active and it can't be activated again.
That specific, um, pub key.
So you would, you would actually just be forwarding those funds to that withdrawal credentials
for that validator.
Um, so like if, if, if a validator was kicked out, you wouldn't actually lose, lose the
funds there.
Um, but you would be sending them to those credentials.
So if they're not your own credentials, then you'd have to get it from that person, um,
or contract or whatever.
And then in terms of reading the beacon chain state, um, I think the easiest way to do that
is probably through like the beacon, the, the consensus layer itself, right?
So we talk about consensus layer, execution layer.
For everyone, the context is that there's kind of like two sort of processes going.
So you would probably, the easiest thing would be to just monitor that with like a full node RPC endpoint.
So when you run a bari-chain node,
you have those two APIs open.
You have the normal ETH JSON RPC,
which you use to interact with for smart contracts,
but then you also have the consensus layer endpoint
to read beacon chain state,
like how much stake does each validator have?
Is this validator active or not?
Are they withdrawing?
Are they exiting from the active set, et cetera, et cetera.
And then finally, the last thing you asked was,
can we actually see the beacon chain state on the EVM?
And that is also possible and is also used by POL.
So POL, for example, has to distribute block rewards to the proposers of block,
which block proposer information is only available
in the consensus layer in the beacon chain.
So we use the fact that we can prove beacon chain state
in the EVM through an EIP that was enabled
in a previous hard fork on Ethereum
and also just available from Genesis on bear chain called EIP 4788.
And that basically allows you to prove beacon chain state, relatively recent beacon chain
state on the EVM.
So it's all possible.
And like with Pectra, we also got the block hashes available for the EVM.
So now you can even prove historical EVM state in the EVM as well.
So, yeah, it's all possible now.
But, yeah, hope that helps.
Thanks for the answer.
I'll take a look at it.
I'll let other people ask because I feel a lot here.
Thanks again for the upgrade the great job, guys.
For sure.
DM me or just shoot messages wherever we can talk about it.
Perfect.
Thanks, Carl.
Thanks, guys.
Awesome.
I think that there's also...
I have to double-check this,
but I think there's a possibility
that it actually exposes the state of validers through our API as well. But don't quote me on that. I'll have to double check this, but I think there's a possibility that it actually exposes the state of validers through our API as well.
But don't quote me on that. I'll have to double check.
But I think on abi.bearchain.com you can use that as a means to be able to pull that information as well.
I think that I'll just quickly skim just the text message, the replies in terms of questions.
The only thing that keeps coming back is,
can Smokey say something?
Yeah, I was going to hop in real quick before I get out of here,
which is to say, yeah, pretty happy about the way this is all gone.
So congratulations to the core team for making this happen smoothly.
I got to see a lot of it from, I guess, the benches,
which is great.
I would much rather be there than in the field on this one.
And I think that, you know,
we've got the vast majority of validators updated.
I think now there's probably last bits of service providers
switching over their nodes and whatnot.
And hopefully this just means that the Baratian ecosystem
and apps building with us as a whole
end up trending towards better and better usability.
And I think that there's a lot of folks in the ecosystem who are doing a lot of the hard work
to make sure that things are seamless, painless, and as close to a Web 2 or transparent experience as possible.
And I think this should be a pretty meaningful step in the right direction.
It's also something that Grizzly has been fired up about for a while,
so I'm excited to see him getting, you know, the deal toy, if you will.
And then I think that will have to come next is probably ways that we can make the chain even, I'd say, more optimized for POL itself over time.
And also some of the stuff that Cal and Rez have started putting up on, you know, public forums like the BRIPS.
on public forums like the BRIPS,
And I'm not even sure if that's the exact right way to pronounce it.
to pronounce it, but stuff to allow the execution layer
and Veritain as a whole to be more performant,
less congested, better for users all over.
So I hope that this kicks off one of many steps
in making Veritain better and better,
such that people don't just know us for POL
and the memes and the DeFi ecosystem,
but also even more and more general
technical excellence over time.
So yeah.
Thanks a lot for everyone for making it out.
And I think that we'll see a lot more coverage on this sort of stuff
over the next few weeks.
Awesome.
Thanks, folks, for those
last comments and for the
praise for the core team. Again, we can't
the speed at which we've done the praise for the core team. Again, we can't like the, the speed at which we've done the implementation,
the core team deserves all the praise here.
Just amazing work.
And again,
thanks for everybody that joined.
Feel free again,
look at the,
the pinned tweets that are in this spaces.
There's so many different types of articles and do so many technical
implementations going 7702 and much more.
Check out docs.beartrain.com,
including if you're already running a node yourself,
I just pinned a new tweet here,
an article in the guides actually on how to upgrade,
what are the steps to be able to upgrade to Pectra
if you haven't done so already.
Definitely take this a look.
And again, thank you to Cal, to Grizzly, to Rez, and to Sugar for also
helping coordinate this as well. I really appreciate it. And thanks everybody for coming.
Looking forward to building some more. Thanks guys.
Thank you. Thank you.
