Tiny ecosystem at that point all the projects doing their own
Icos doing the 2017 phase started adopting this multi
signature wallet as well. In the long run these smart
accounts will be the solution and there's no way around smart
accounts in order to get to the user experience while still
retaining like security that is needed to to onboard like a
billion people to to or three. I would say when it comes to
cross train, smart accounts in the short term will bring new
challenges in in the long run will actually solve.
Frustrating in a way that it can make it irrelevant in what
networks you interact with what tabs, but this can be abstracted
away. This episode is brought to you
by Gnosis. Gnosis builds decentralized
infrastructure for the Ethereum ecosystem with a rich history
dating back to 2015 and products like Safe Cow Swap or Gnosis
Chain, Gnosis combines needs driven development with deep
technical expertise. This year marks the launch of
Gnosis Pay, the world's first decentralized payment network.
With a Gnosis card you can spend self custody crypto at any Visa
accepting merchant around the world.
If you're an individual looking to live more on chain or
business looking to white label the stack, visit gnosispay.com.
There are lots of ways you can join the Gnosis journey.
Drop in the Gnosis Dow Governance form, become a Gnosis
validator with a single GNO token and low cost hardware, or
deploy your product on the EVM compatible and highly
decentralized Gnosis chain. Get started today at Gnosis dot
IO Chorus One is one of the biggest node operators globally
and help you stake your tokens on 45 plus networks like
Etherium, Cosmos, Celestia and DYDX.
More than 100,000 delegators stake with Chorus One, including
institutions like Bit Go and Ledger.
Sticking with Chorus 1 not only gets you the highest years, but
also the most robust security practices and infrastructure
that are usually exclusive for institutions.
You can stake directly to Chorus One's public note from your
wallet, set up a white table note, or use the recently
launched product Opus to stake up to 8000 ETH in a single
transaction. You can even offer high yield
staking to your own customers using their API.
Your assets always remain in your custody so you can have
complete Peace of Mind. Start staking today at.
Chorus .1. Welcome to Epicenter, the show
which talks about the technologies, projects and
people driving decentralization in the blockchain revolution.
I'm Sebastian Krutio and today I'm all by myself.
I'm chatting with Lucas Shore, who's the Co founder at SAFE.
Safe is of course the leading smart account, multi sig
provider in the EVM ecosystem. They're securing over $100
billion in assets and are absolutely crushing it when it
comes to securing assets. We use SAFE at Interop Ventures
and I'm sure lots of you out there are also using SAFE.
They were spun out of Gnosis a couple years ago.
And I'm going to be talking with Lucas today about the technology
behind SAFE, but also the strategy moving forward and what
is the future of SAFE look like? Hey, Lucas, thanks for joining
us today. Thanks for having me semester.
So before we get started, how did you become part of the Safe
team? Were you previously at Nosis or?
Yeah, because I think you're like a one of the Co founders of
Safe. What's the story there?
Yeah, that's right. So safe is the spin off from
from Nosis. I joined back in 2019 as a
product manager responsible for the that Point Nosis safe
project within Nosis. Actually I was applying half a
year before that to Nosis in the in the marketing department.
I got rejected right away. That's just a fun fact on the
side. Then half a year later something
that was more relevant to my my background, the product manager
role opened up and I was jumping on that and that was luckily
successful. So I joined when the Nosy Safe
project was quite a bit early stages.
Yeah. Then took over together with
Richard and Tobias, my Co founders the the project
responsibilities and over time then the the project group and
it outgrew to some extent noses as in the kind of the team size
crew and the the the focus have expanded beyond what it's
originally meant to be and it became its own ecosystem.
And that's when we decided together with the Nosys team
that it's better off to continue the project outside.
Yeah, maybe a little bit of the history of how this project came
to begin with. So Nosys like back in 2016 was
was started to create prediction markets.
So that's a way to financially incentivize participants to
share their knowledge in order to, yeah, expose that knowledge
to the public. And that's meant to be as a as a
primitive on the film blockchain.
And Nosys went ahead and did Nico in order to fund the
project and it happened that the ICO was quite successful.
Nosys had to custody a lot of the proceedings from from that
ICO and back then the entire self custody infrastructure was
quite early on, meaning that they had to create their own
solution. So Stefan Giorgi who's the Co
founder of Gnosis wrote himself a multi signature contract which
is a way to share the responsibility of a self custody
set up with other people via multiple keys and that was used
for for the ICO funding and was open sourced.
And then it happened that all have the entire ecosystem at
that point all the projects doing their own IC OS doing the
2017 phase started adopting this multi signature wallet as well.
And that's how the team was formed as suddenly had many
projects that were using this solution and there were feature
requests coming in and people wanted to have the project
maintained. And so the the project formed,
it became its own team within Nosis and that's roughly when
when I joined. Yeah, cool.
I mean I think it bears reminding also that like you
know back then like you said there were no good solutions for
doing multi stakeholder asset custody.
Bitcoin had an on chain in protocol solution still has and
you know in Bitcoin you can create an on chain multi sig and
you know this is something that a lot of people like including
myself have used you know with Epicenter we've used this also
quite a bit in the early days when we were a a Bitcoin only
company and but yeah the even even then like it's quite
cumbersome to set up the keys and and everything but Etherium
didn't have an on protocol solution.
Do you know why that is? Like why Etherium didn't go down
the same path as Bitcoin and built build an in protocol way
to do multi stakeholder asset custody?
Yeah, I mean it's always the question what should be really
enshrined as part of the protocol and what should be then
solve the layer above from the smart contract level.
It actually happened that Etherium originally wants to
have smart accounts. So accounts that's based on
logic on smart contracts have have this natively within the
theorem it was then yeah it turned out that this is quite
complex to do and the team at the Etherium Foundation was a
bit of an in a in a time rush to to launch mainnet so that this
scope did last minute. And we since then had our have
all the infrastructure on Etherium mostly based on EO as
so externally owned accounts. These are the the accounts
everyone knows that are controlled by a single private
key usually derived from from a seat phrase, 12424 word, secret
phrase and that's where the the world infrastructure was was
built upon. I personally think that it's a
better pathway to solve as much as possible on on the smart
contract level there in terms of like logic of of an account.
Because if you look at what you mentioned the the Bitcoin multi
SEC implementation, it it it works quite nicely for certain
use cases. But it's quite limited because
you have all the logic enshrined in the in the Bitcoin protocol.
And for example that means that certain use cases such as
rotating keys is not possible with the Bitcoin multi sig.
So you once can set up your multi signature wallet.
You might have a certain threshold of signatures required
to make transactions, but then if you lose access to to one of
the keys or it gets compromised you actually have to move your
funds to complete the new Bitcoin multi sig.
And you cannot just rotate one key and and continue with with
the same wallet. These things are are solved by
just leaving the logic up to the smart contract level and
allowing different implementations to take
different optimizations and different yeah, technical
assumptions. And this creates much more
flexibility. Then and over time we will
probably see certain standards or certain best practices emerge
and potentially at some point these can be trained again in if
you're in protocol. Once once we see that these are
actually must have and have, the standardization value is higher
than the flexibility of having different implementations.
Yeah, I think the Entrime in question is one that needs a lot
of of course, reflection, and we need to be careful what we
enshrine into the protocol or not.
But yeah, taking a step back from that, let's maybe dive into
smart accounts or at least the way smart accounts are conceived
of in the Etherium space. I think most of the research is
around this ERC 4337. Yeah, Give us an overview of
what is ERC 4337 and how it aims to implement smart accounts on
EVM chains. Yeah, there's actually quite
some misconceptions still on what the ERC 457 is.
So some people think that ERC 457 is smart accounts and all
the logic, all the possibilities that are enabled through this
standard have is is due to the to the ERC 457 standard.
While most of the features such as recovery or like session keys
and so on are actually the the responsibilities of the smart
accounts. So smart accounts have existed
since since years. We have SAFE has been around
since 5-6 years and a lot of what we're now talking when we
talk about the potential of 457 has been possible before with
one exception, which is actually processing smart account
transactions in a trustless way. That's a big problem that's
solved by ERC 457. So as I mentioned the if you're
in protocol like it, it has two types of accounts, it's EOA
Externally Owned Account and Smart Contacts which can then be
used to make smart accounts. And yet a transaction actually
in order to be processed needs to originate from an EOA.
And that's that's a challenge because you have certain use
cases of smart accounts. You actually might not even want
to have an EOA involved if you use certain like new signature
schemes, passkeys or so on where where there's no EOA part of the
transaction life cycle. Yeah, but so far how it worked
is that you had to fulfil the transaction verification
requirements, be it in a multi CIC case that you collect the
different signatures from the participants.
But then still you need to have an EOA involved in in the
transaction in order to actually process that transaction on the
FION blockchain should. So usually how that worked is
that you had like everyone signed the transaction and then
the last person that was signing was, was the poor person that
actually had to pay for the transaction fee from his EOA
account. And yeah, that's now now coming
to ERC 457. So just just one one, just the
kind of put a pin in that essentially what you're saying
here is that a a smart account like SAFE can can have multiple
types of signers verifying and executing sort of signing for
the for the transaction. But at the end of the day at the
end of the transaction an EOA needs to execute that
transaction on chain and pay the gas fee.
So like we encounter this basically every time we do a
safe transaction. You know all of us sign and then
we have like one account that has just like a bunch of ETH on
it and it's just used to pay for gas.
And you know that account basically executes the
transaction and sends it on chain and that has to be an EO
account. It can't be some other sort of
signer or even another smart account.
It has to be an on chain account.
Exactly, at least so far. And it doesn't even need to be
an EOA that the user controls. So even in the past there were
relayer systems like a bichonomy or Gelato or private relayers
that are just Eoas that are funded that then are instructed
that once there's a smart account transaction that's like
fully verified and fully signed that then this relayer system
would would take with the EOA and and pay for the gas fees and
put on chain. And that's where then ERC 457
comes in where we say that the idea should be that we have sort
of like a separate man pool for the smart account transactions
where we can just add the smarter account transactions
that are fully assigned, fully valid.
And then we have a decentralized mechanism how these transactions
are then put on chain. There's actually still in EOA
involved. So that's the EOA that the
bundler in the in in the standard controls the bundlers
are just of collecting all the different smart account
transactions and are then bundling them together and and
put them on chain by paying for the gas fees and using the the
EOA. And they can then get repaid for
this gas fee expenses by paymaster which is not a
component of this standard which then allows that the the bundler
isn't sitting on the cost but actually get out net zero or
ideally with with some profit. And exactly the the standard now
allows that there's no centralized relayer involved
anymore. Users don't need to fund their
own EO AS, but they just trust that there's this decentralized
networks of bundlers that they can just throw in the
transaction and it gets executed in a trustless way.
OK, so just to recap here. So ERC 4337 uses existing smart
account or leverages existing smart account infrastructure but
offsets the execution or or sends the responsibility
execution to this bundler network.
That bundler network does the on chain execution of any smart
account transaction that is ERC 4337 compatible and that
therefore alleviates the initiators of that transaction
to have to a execute it and B pay for for the on chain gas
costs does ERC 4337 by bundling these transactions.
I suppose it also implies gas optimization because you're
bundling all these transactions together and possibly saving on
gas by doing so. There is some component of of
gas savings in the end. The ERC 457 architecture adds
some gas overhead itself. But assuming that like there's a
lot of adoption of the standard over time, that overhead
decreases and even at some points that there should be ways
to to even have better gas efficiency than just using like
a smart account natively itself. Right.
And just to come back to this signing and execution process,
So what when you you know I've encountered this a bunch of
times where like we start a transaction and then we we
realized maybe the the amount was wrong or there's like some
issue with the transaction as we're signing it.
This happened recently right, where like I had a zero too few
right on in in my amount and and so then you know you you you
have to go through this process of reverting the transaction and
that's because because you've already signed part of that
transaction at any point in the future other signers could sign
for the rest of that transaction and actually execute it.
Now when it comes to this bundler network, you know a
transaction that has been fully signed is basically ready to be
executed. Is there another step then that
the signers of that transaction have to make in order for that
transaction to be made, say, public?
Or does it remain within the hands of the signers and kind of
private until an action is taken to reveal it to anyone including
this bundle network to then execute it on chain?
There's probably 2 steps to that.
One is that after the partially signed transactions can stay
private until it's fully signed and it's sent to the to the
bundle network, yet still like others that are participating.
For example in multi signature use case have access to this
partially signed transaction. So they could complete this
transaction and send it to the bundler network at the later
point. But once it is sent to a bundler
then you need to assume that it's out there and they could be
executed at any point. But this itself is not different
than to how EO as work as well. If you sign a transaction meta
mask today, if you have too low of a gas fee and it's just stuck
in the main pool like it can be executed at any point, which you
can resolve by sending a transaction again with a higher
gas fee in order to speed up the transaction, or by replacing the
transaction on the same nonce with a different transaction.
So that would also be the case with smart accounts.
They also have a nonce. So once a transaction then is
executed at the same nonce, that means that the other partially
signed transaction or fully signed transaction is not able
to be executed anymore and can be disregarded.
But up up in that point, when the nonce is still available and
the transaction is is out there like it needs to be assumed that
it can be executed. I guess we've clarified here
that your C4337 is related to executing transactions.
Is there an EOA that is creating a standard for how smart
accounts should be conceived like in terms of the
architecture of the start smart account?
Or is that up to smart account like companies and and service
providers to decide? As long as they are compatible
with ERC 4337, they can do whatever they want on the
software side. Yeah, so ERC 457 itself has
already some requirements towards smarter cons.
For example that it requires that the smart account
transaction is starting from the account itself, which is
relevant if you think about modular smart accounts.
So you might have different execution logic for an account
and have it depending on what type of transaction it would
require a different signature scheme or or so on.
And there the transaction needs to start in the account and then
go to the to the module which contains the execution logic,
which, yeah, there's some details there that just define
how the account works. There's other ER CS that
standardize certain patterns for smart accounts, such as proxy
patterns or now more recently again with modular smart
accounts. There's certain initiatives from
the community that say the idea should be that we can create
these different modules, which you can imagine to be in a way
like apps on a smartphone. So we shouldn't go to a world
where you change your account in order to kind of add a new
feature to it, be like a session key recovery or something like
that. But instead it should be like
downloading NAP on your smartphone.
And that's enabled through these modular smart accounts, which
means that you have your base account which actually has
certain default logic and you expand that with modules.
This can be validation plug-ins, these can be certain safeguards
that are added to the account and that then extends the, the
logic of the account. And there there's no initiatives
that say we want to have, yeah, certain parts of this
architecture of this modular architecture be the same across
different smart account implementations.
Why should we do that? The idea is that you then don't
have to create these modules for different implementations
separately, but you can actually assume that they have certain
standards that they comply to. And the modules that you create
for Smart Account A works the same way also with Smart Account
B. These are yeah, there's actually
2 standards out there. As always, it's not enough to
have one standard, to have a second standard and then the
first standard to get rid of the other two and so on.
But they are the ERC 6900 which was started last summer by the
Alchemy team and you got ERC 7579 which is a collaboration
between Rhinestone by Economy, OK X and others that define
different ways how these modular smart accounts could look like
with some different technical assumptions.
Completely ERC 6900 bundles the modular architecture also with a
permissioning system. So you say you have these
different modules and you want to give certain permissions to
these modules as a security function.
And ERC 7579 is a very minimal standard that really just
focuses on the modular architecture of smart accounts
and leaves the security, the permissioning system potentially
to future ERC and just says we shouldn't overcomplicate things,
we should just focus on one thing after the other.
And yeah, these standards are in a way competing at this point
from the SAFE perspective. We actually want the SAFE Smart
account to be compatible with any standard.
So that's possible as SAFE itself has some native
modularity built in. So it already has some some ways
you can extend the the Smart account and then you can just
add an adapter in order to be compatible with ERC 6900 or add
another adapter to be compatible with 7579 which makes it just
future proof. It's still unclear how these
standards evolve. They're all they're quite early
got we have little adoption so far and they might still change
over time. So our philosophy there is that
we want to save Smart account really to be as have low level
as possible so that no matter how these standards evolve, we
can just add another adapter to to support them and we have an
account that lasts forever. Incredible.
And So what is Safe's design philosophy here?
I mean 'cause you got you guys have like Safecore which is the
the core of the of the safe product and and the smart
contract logic. And do you think that that this
should be kept as at as minimal as possible in terms of features
and all extensions sort of bring into the functionality or are
you more like this conservative approach to design or do you
have more of a a broader approach to design where this
core could also include other functionalities that are
currently being fulfilled by the plug insurance or or modules?
Yeah, I mean there's probably two key philosophies for Safe.
One is that SAFE, as the name says is is very much focused on
security. So that's just the defines
everything we do at SAFE in terms of like how we approach
upgrades to the smart account, how we approach, yeah, how we
balance for example also flexibility versus security
versus gas efficiency. So we always default more
towards the security side. And the other one is that we
want to be as use case agnostic and use a group as agnostic as
possible, meaning that the account itself, the core save
smart account should be base primitive.
But then you can expand it depending on on the use cases
and optimize then through its modular architecture to
different yeah to different ways to to use the smarter con.
And yeah that also means that we very much depend on the
ecosystem and run safe. So that's something that was was
was clear early on that if you would really want to bring web
free towards smart account adoption, if we want every
account to be a smart account which is our mission like we
cannot aim to do this ourselves. We really rely on ecosystem and
the community of builders to to help us with that.
So what the idea is that the safe smart account becomes this
very core of of this smart account tradition.
And then we have others that are building the different use
cases, speed, different types of wallets with the asset
management solutions that then have built around this, this
core primitive and extend with what what's needed for them.
Is it automations, is it session keys maybe for a gaming use case
is it more past keys if you want to build a retail wallet.
And that then have puts us into a role of of building this core
protocol and working together with the ecosystem through
ecosystem support initiatives to to target these different user
groups from their perspective. So in Safecore, there's there's,
there's multiple components. We have the smart account which
we've talked about. There's also the SDK that sits
on top of it, which allows like you said, you know wallet
developers to utilize the safe infrastructure.
But we haven't talked about the API, which I think is kind of an
overlooked aspect of of Safecore.
And the way I understand, I mean one of the roles of the API of
course is to kind of coordinate around the signatures.
So like when you're signing a a a safe transaction and that
transaction then pops up on the wallet of say your cosigner or
like another signer in the in the wallet configuration that is
happening via an API that I'm not exactly sure how it works.
So I I don't know what is NOSYS or sorry safes the company's
involvement in running infrastructure that's going to
centralized infrastructure that makes that possible or is there
an on chain component there? I'd love it if you could explain
how the API works and who are the the the third parties that
it may rely on. The smart account created, the
smart contact suite is the the core of it all.
But then we provide tooling for developers that just make it
more accessible. If you want to build an
application using smart accounts, if you want to use to
build a wallet, then things like an SDK or API just make this
more accessible, make make the transition from US easier.
And yeah, that we we just always evaluate what's the things that
we can provide to the ecosystem in order to make it easier to
build on smarter cons. And right now it's an SDK that
just allows us to have yeah to interact with the smarter cons
to craft signatures and so on, and to also work with the ERC
457 relaying network and the API as you say, that's it's
essentially an indexer. The most part is an indexer, so
it just indexes all the safe smart account transactions out
there and makes them available for developers.
So you can say you can drag different saves for example.
There's also an event service to it so you can track if there's
any updates to it, if transactions are triggered, if
any incoming assets and so on in order to display this to the
user. But it also has a component of
the signature collection, which is, especially in a multi
signature use case quite critical because you don't want
to have every signer in a multi sig sign on chain, at least in
most cases you you might want to save on the gas cost of signing
on chain and you just sign a signature, sign the transaction
off chain. But then you need a way to
exchange these partially signed transactions with other
participants of the multi sig and that's done also via the the
API. So you can just post these
partially signed transactions and retrieve them from another
user and that just allows to exchange these transactions.
Technically, it would be possible to exchange these
transactions for any other means.
Yeah, also on chain signatures of course, but also by just
downloading a file and sending it to someone else.
Obviously that's not very user friendly, but yeah, that's why
we provide this service. It's also an open source
service. So there there are projects that
they run it themselves just as a redundancy and we eventually
also want to get to a place where there's actually a
decentralized network of of indexers that participate in in
retrieving and yeah sharing these partially signed
transactions just because it's it's always better to not rely
just on a on a centralized service even though like anyone
could run the service themselves and so on.
But the the truth is that it probably would take quite some
time until some other service what's what's been up that has a
similar performance that would then have step in if if our
index will be done or so. So drafted pathway towards this
decentralized index network is is something that we are looking
into. Yeah.
OK. Interesting.
So, so currently for all of the SAFE wallet products, I guess
SAFE is running that infrastructure in a kind of
centralized way. But as a user, you can choose to
either run your own infrastructure or if you're a
company using SAFE, you can also run that infrastructure yourself
for redundancy. But but you can also share the
signatures on chain, correct? Exactly.
OK, interesting. Now that might make sense on
some networks that have like lower gas costs, but I got
Etherium that might be a bit prohibitive.
Yeah, and it also makes sense as this service is only run for a
certain set of of of networks. On that networks where the index
is not run, you can still sign on chain.
And it also is an additional redundancy.
If the the service is not available then you could just
with some little extra gas cost you could sign on chain and and
not be dependent on. It OK, great.
This is cool. Thanks for clearing that up.
On the. Yeah, on the wallet side, I'd
like to talk a little bit about the the user experience here and
what are the some of the challenges that you guys face
when building in a wallet that you know supports safe core.
And you know, I like the preface this by saying I've had my share
of moments using SAFE where I didn't really know what was
happening or where my transaction was in the queue or
whether like you know, trying to sign a transaction is not
working. And I'm getting some weird error
message. And I've actually talked to SAFE
support like two or three times when executing transaction and
they've always been very helpful and have helped to clear things
up. But yeah, how do we, how do we
come to a better user experience around around these things?
Because it's still super cumbersome, I mean especially if
you're using a Ledger and then you sign with Metamask and it
all feels very cumbersome. And I still like I still stress
every time I do a multi sync transaction because there's just
all these moving parts that need to work and it it it always
feels like a bit of a a lift to to get that transaction signed.
So yeah, what are your thoughts on on user experience generally
and how can we how can we improve all this?
It's actually interesting because there's like two camps
here. Some people say like the the
safe wallet interface is already quite user friendly and and some
still have issues. It's probably also to to some
extent if you compare where safe wallet is today compared to
where where it is 2-3 years ago. I would say there's like a
massive improvement in user experience since then, but
obviously it's still a long long way to go.
Also challenge there is that we want to have safe wallet, PS
user group and use case agnostic.
So we cannot optimize for say someone that's super technical
that wants to see like all the information and always be able
to to look under the hood of everything at the at the same
time optimize for someone that is less technical that really
wants to have everything abstracted away.
So we always try to be somewhere in in in the middle and then
actually work with the ecosystem to provide the the best
experiences for the different user groups.
So for example there's and on chain den which specialises
really on multi signature in a in a team use case and having
transactions. They say that the the the
interface that allows you to have side transactions the the
fastest and they have like some you have some notification
system behind it and so on and some some gas abstraction and
they do certain optimizations there.
And then there's others like a Nest wallet which is optimizing
more for individuals and and and retail users that allow allows
them to abstract a little bit more from the details away and
have like a more smooth user experience where maybe the trust
team collaboration part is less of a focus.
So that's really our strategy that we say say for that it's
like a baseline, it should be like an interface that people
can start using in order to get experiences with with smart
accounts to to cover certain use cases.
But then as you over time, there should really be like a wide
ecosystem of of of designated solutions that optimize for for
different solutions. Yeah, user groups.
No that's cool. I I made a note of these I think
I'll probably try them out as well this.
So you said on chain den and Nest wallet.
Yeah. I mean with like the the some of
the issues I've faced were were yeah I think like ordering of of
signing and and then you know not able to post a transaction
on chain and you know having to update that transaction with a
new nonce. Like these kinds of things are
very unintuitive I think for most people and even me.
And you know the error message really doesn't explain much of
what you need to do. So I think having kind of a in
app resolution mechanism to kind of fix this problem you know
without having to reach to support or look you know look
for things online. And the other thing is I think
there's I find there's like some inconsistencies between the way
the wallet, the mobile wallet works and the the desktop works
the kind of web version. And one thing I've never really
understood is with the with the mobile wallet and by the way the
mobile wallet's great like I typically do transactions on the
mobile wallet. I think that that's the best
user experience I think for you know for what we do and and we
have a bunch of ledgers that we signed with and I love that the
mobile wallet supports the Ledger and we can just like pull
them out and get together and and you assign things.
But there's one thing I don't really understand is like why
you need to have a it. It seems like you need to have
an on device account. So like when you create this
safe for the first time you need to have like a a seed phrase
that you have to store somewhere.
It's generated on the, it's generated in the app and I
haven't found a way to be able to sign the transactions with
anything else than that on wallet account.
I can't execute with the with the Ledger which kind of seems a
bit backwards to me. If we're going to have ledgers
to to sign safe transactions to then have to have this less safe
kind of hot wallet you know on the device.
So that's that's, yeah, I don't know, maybe I'm doing something
wrong here, but that's always been a little confusing to me.
Yeah, are you using Android? No iOS.
IOS OK because technically it should be possible to execute
also with Ledger. So the idea about the mobile
wallet is that it's it should be just a very smooth way to to
cosine transactions and you can add any kind of like wallets to
to do so like Ledger via Bluetooth for like mobile
wallets via wallet connect. And yeah, I can look into this I
think. Yeah, we'll have to talk after,
but yeah, so there's like these kind of minor UX things that I
find you know can be, can be improved.
But overall you're like I I agree with you that the
experience generally is, is is pretty good.
You know, compared to look like 10 years ago Brian and I used to
do Bitcoin transactions, electron wallet and we have to
send the partially signed transactions over slack and you
know it was a huge mess, right. I mean like this is definitely a
huge leg up from having to do this kind of shenanigans, which
you know for for people who have been in this space long enough
will will be, will be familiar with.
Yeah. And I mean that's something in
terms of user experience that's very close to my heart because I
think in general the web free space like we're we're staying
saying things since years that we're still early and at some
point we cannot allow us to to say that anymore because we it's
still quite cumbersome. If you want to do full self
custody and interact with with tabs and like that's still not
that accessible to a wide range of of people like in in the
world like even just having pretty much everything default
to English like that that's fine for certain parts of the western
world but we need to have more localized solutions but also in
general how the DX works of of wallets today there needs to be
so much more that that we should do in next year's.
And that's also why I'm so excited about smart accounts,
because I think in the long run these smart accounts will be the
solution. And there's no way around smart
accounts in order to get to the user experience while it's still
retaining like security that is needed to to onboard like a
billion people to to web free. Yeah, I think smart accounts are
are huge unlocked there and I'm really looking forward to more
broad adoption of passkey and other ways of signing.
So you know. I'll I'll tell you a little bit
about what's happening. I don't know if you're familiar
with this, but in the Cosmos ecosystem Osmosis which is the
major decks there are doing an on chain smart account.
Now of course the difference here is that they manage the
entire chain and they can really build things on chain and also
have certain types of transactions be either gas
subsidized or gas optimized. And so they the idea here is to
do a smart account on chain that you can set up using, you know
Oauth like a Twitter account or a Google account.
And then based on the on the value of the transactions you're
doing or perhaps even the value in the on the account itself.
Then you you'll be required to add a second factor
authentication. So it could be like a passkey or
or a secondary account to sign. And you know they're building
all of this infrastructure on the chain, which is, which is
great when you're doing your own chain.
And you know brings me to another question I wanted to ask
you is what's safe strategy when it comes to building it's cross
chain presence. And by cross chain, I don't mean
just EVM chains, which I know you guys are supporting very
well, but other ecosystems like Solana, like Cosmos chains, like
the MOVE ecosystem, the, you know, Aptos and Sui, you know,
are you guys looking at those ecosystems at all and thinking
of ways that SAFE can support those or is your focus really
just the EVM and you'll stick to, you know, what you're great
at? I would say when it comes to
cross chain, smart accounts in the short term will bring new
challenges in in the long run will actually solve cross chain
in a way that it can make it irrelevant in what networks you
interact with what dabs. But this can be abstracted away
through through smart accounts. But yeah, in in the short term
there there are challenges. One of them is that smart
accounts, they are, they are just very unique per chain.
So because these are smart contacts, they're deployed on a
certain network, they have the logic on that network.
Which means that while it's possible to have a similar smart
account on a different network with the same logic, potentially
even the same address through Grade 2 counterfactual
deployment, they're still very much independent accounts.
Which is a difference towards EO as which are by design because
it's kind of standardised especially in the EVM ecosystem
like you have a seat race and it's immediately and we count on
all EVM networks. So that's that's going to
change, it has to change and there are solutions that are
being worked on in terms of like key stores that are accessible
cross chain and ways to to sync the state across the chains that
will eventually solve that. There was just recently like a
spec on that from Michael from base that goes into that that
that's one thing and then the the other challenge will be that
smart accounts they are very much depend on the virtual
machine. So you can have a smart contact
that creates your your account but obviously that's very much
depend on what smart contact language you use for
implementation and all the security assumptions are depend
on the the virtual machine behind it.
So it's possible to create a similar smart account then
across non EVM chains like a Solana or or else.
But this will necessarily you remove certain technical
assumptions that you can take certain security assumptions and
you will have to build up the the trust into this smart
account from scratch. So there's similar solutions to
save on say Solana, that's like a squats that have been around
quite a while and that do similar things.
And for safe the near to mid term focus will still be EVM.
I think there's enough that can be built there.
In terms of smart account adoption on DVM itself, it's
it's a huge ecosystem and there's it just allows to move
faster if you can make the technical assumptions on the VM
virtual machine. But obviously in the long run
this should not be limited to to that and safe in in some way or
another should be also, yeah, available outside of the VM
itself. And whether that that means
integrating with some of the other implementations such such
as the squads on on other networks, that's yet to be seen.
But that's definitely in the long term, say three to five
years, something that needs to be done.
Yeah, I mean I I would love to see safe in other ecosystems
been brought mostly because like solutions I think are lacking.
Yeah, I I think that in the next one to two years we'll see safe
competitors emerge in those ecosystems like native solutions
emerge in those ecosystems which will you know half mover, first
mover advantage and likely make it difficult for SAFE to really
gain a a a foothold in in those ecosystems.
Maybe you know with the exception of like existing
customers on the safe on the EVM side that have assets there that
want to move those assets into other ecosystems.
What when it comes to the EVM ecosystem and the cross chain
compatibility, what's the progress in terms of being able
to control cross chain accounts from like a single account.
So for example you know if you had assets on or you had like a
safe account on on Polygon and wanted to control assets on
another account by signing something on Polygon.
Like is there any progress in, in the in the direction of
Interchain accounts as we call them in in Cosmos.
So these are accounts that can be controlled externally by an
account on the other chain. Is that also something that can
exist within the safe ecosystem in the EVM world?
Definitely. So that's what I mentioned
before on key stores. So that's actually something
that was proposed by Vitalik Buterin last year and now
certain teams are are looking into.
The idea is that you should have the ability to have multiple
Sparta cons but after the core validation logic or the the
logic what keys are associated with that account separated in
two separate contract which is a key store contract which then
allows you to have less of that logic in the account itself and
you just say from the account. You then make a state proof
towards that key store and then it allows you to see what's
actually the the account logic and and proof that against the
the transaction and that can then be taken cost chain as well
actually in via designated roll up.
So that could be like a keystore roll up that then contains the
logic of your account as you have your sub account so to say
on different networks. Could be EVM, could be beyond
DVM that just allow you to use a cross chain state proof against
this keystore roll up in order to prove what what keys or what
validation logic this this account has.
And then this essentially means that you will have cross chain
smarter cons that can then be allow you to think to to achieve
things like complete network abstraction where for a user or
a developer it doesn't even matter where the transaction is
starting and where it's pointing at.
But this is then exactly the way by having these questions smart
accounts. I would still say it's like
maybe 6 to 12 months out until we have first production ready
implementations of such keystone roll ups.
But there's like major teams working on that and I'm I'm 100%
sure that we are going to that direction and it's got to be
first maybe optimized for certain sub ecosystems say the
optimism ecosystem or the small ecosystem.
But over time it will expand and even go go beyond the EVM where
you can have like the keystore roll up which is based in
Etherium layer one but as a roll up in order to optimize some gas
efficiency. But then allows you to yeah,
prove that that verification state towards any other
networks. Very cool.
Yeah I mean I think that that's mostly like untapped kind of
feature in in the EVM world this, this ability to control
accounts cross chain you know again like in you know in Cosmos
we have standards for this and and it exists and we're able to
do this pretty easily but but in the EVM IT world it's I think
it's it's still needs a little bit of time in order to become
production ready. So you guys recently announced
this, I think it was last year this recovery hub.
So it's safe added all these different kind of methods to do
recovery and you have some partners there that I guess can
act as third party signers in the event of lost keys.
What does this look like, and what are the kind of trust
assumptions that users of SAFE have to make in order to be
using this recovery feature? Yeah, so the idea behind
recovery is that you may have more user friendly ways to get
keys into head to hand of of users, be it like passkey
signers or be it social login signers such as like log in with
Google or something like that. But still you want to have worst
case scenario way to recover access to your account and that
actually at least in my opinion it it's something that's very
idiosyncratic to the user itself.
So there might be different users that want to have
different ways to recover the account.
Some like trust their family and friends.
They just want to have sort of like a multi say controlled by
their family and friends controlling their account.
And if they lose their own keys they just approach these social
recovery signers and and ask them to initiate the recovery.
Others may trust an institution such as a a bank or a notary or
something like that that can execute the recovery in certain
cases even in inheritance cases worst case and Yep there's in
for others that may trust some like decentralized network of
like yeah humanity doll kind of system that then verifies the
identity of of someone that then can be used to recover the
account through some identity verification.
And how we're thinking then around what we built in terms of
the foundations for enabling these use cases is that we
created this recovery hub which is very much agnostic system to
add different recovery systems and we're working together with
partners in order to showcase some of these capabilities.
So the very base logic of the recovery hub is that you can add
a module which is like a separate Spark contract which
has access to your account as an admin key.
But then you add security guards that make sure that this admin
key is is somewhere some somewhat protected that and that
can be depending on on what the user prefers.
It's usually like a a time lock so that the user can say this
separate contract can recover my account but only by having a
time lock of like 3 months. So I can't really pre sign the
the recovery and in that three months I could cancel the
recovery if I have access to my keys and this then allows to
have less trusted system where am I may delegate this admin key
to my social recovery setup or to this institution but still
have to certainly that they cannot go rogue and just run
away with the account. There's other ways to to add
security such as Signum which is a Swiss licensed bank which is
building a recovery system for the recovery hub.
What they're doing is that they limit the capabilities of this
this recovery module to only exchanging certain signers in
the con. So the logic goes like this
recovery module can exchange signer A but not signer BC or D
and this can be then configured by the user and they can say
just this one signer which I trust signum to recover.
I set up and this then just limits what signum can do with
the account and again with some time lock.
So there's an additional protection for that.
But essentially the it's it's very open-ended what can be done
there and there can be vast amounts of different ways that
these these recovery setups are being created.
And are there any kind of best practices like so if if someone
wanted to set up a multi sig account or you know a smart
account and then have a recovery.
I think one of the things that you internally we spend a lot of
time thinking about was OK what is the key distribution setup
look like? Like who has keys, where are
they? Where are the seats stored?
You know what other third parties outside of our
organization might have access to these keys for backup or
recovery purposes. Does safe make any
recommendations or best practices recommend best
practices when it term comes to doing this kind of, you know,
smart account set up within an organization?
I mean, we usually recommend to use a threshold of more than
one, that's obvious. You want to have multi
signature, not just one out of five, where every one of the
members of the organization can do whatever they want, so
there's at least multiple people looking over a transaction.
And then we also recommend to not use a threshold that's equal
to the number of signers, so not to any five out of five schemes
because that will mean that only one key needs to be lost and the
the account is not usable anymore in case you don't have
recovery. So that's always dependent on
also what the recovery setup you use.
Obviously if you have a very trusted recovery setup then it
might make sense to have like a 55 out of five if you have this
emergency way to to recover the the account, but without that
have at least like a three out of five.
That's enough for having multiple people cosign.
But that's also allows for some people to not be available at
certain times or also certain keys to be lost and in order to
to create key rotations afterwards.
But then that's just very basic recommendations I would do.
In general it it very much depends on on the specific use
cases and like how many people are involved, like what's the
trust assumptions between these people and so on.
Yeah, that's true. Yeah.
And there's also a kind of catastrophic, you know we we
thought a lot about this this catastrophic scenario where
since the team often travels together, if there was a
catastrophic scenario where we were to all perish, how would
you know heirs or other stakeholders be able to recover
keys in that event. And so we had to think about
safeguards there as well. But yeah it it's I think for a
lot of teams that have set up multi sigs and that are managing
you know significant amounts of capital on on these accounts.
They've probably gone through similar reflections and you know
thinking about the best scenario.
I yeah I I don't think there's a one-size-fits-all solution for
everyone but certainly like you know some best practices here I
think generally would be would be useful.
I don't know if anyone's thinking about these things or
publishing anything about this but I I hadn't found anything
like those very useful for for our for our use case.
I wanted to also talk a little bit about security at Safe.
So you guys recently passed $100 billion in assets secured by the
protocol. I I guess that's that's cross
ecosystem or cross cross EBM chains, that's a lot of
responsibility on on the SAFE team.
And I would argue that if something were to happen, if
there was a bug in the SAFE smart contract that not only the
multi sig holders would suffer but I think the entire ecosystem
would probably suffer quite a bit.
Yeah. What does that evoke for you,
and what does the process look like?
The process of making sure these smart contracts are absolutely
bulletproof? I must say I was more worried in
the early years of safe than I am now because like the the vast
amount of the security comes through its linear effect.
So just having like a lot of value controlled through to
smart accounts over time without there being any issues and
especially with like the safe smart accounts we we don't
update them that often intentionally because every time
you make a change to the to the smart contract that means that
there there could be potentially any kind of risks associated
with that. So we are not kind of adding new
features just to the base contract, but we we allow this
with modules and then there's a different kind of security
assumptions that that's beyond there.
But yeah generally also because it's not just $100 billion worth
of of assets that are secured but also like critical
infrastructure be it like cross chain bridges be it restaking
protocols be it stable coins that can use safe smart accounts
under the hood in order to control certain upgrade
parameters and and so on like it.
It is quite critical that the the safe smart account is is
really bulletproof and for that we invest a lot into security.
We actually invested a lot of us into formal verification.
The the very first major version of the the Safe Smart account
was formally verified over a period of six months of of quite
some time and and financial investments that went into that.
Obviously multiple audits are always part of that having a
back bounty and the community back bounty challenge that is
associated with that and like a big part of security is also
just on like in internal processes and how the culture is
around security in the team and and so on.
But yeah the the key part is is still like the the linear effect
and that's something where I would argue at this point with
that much at stake if there would be any major issue with
the safe smart account, no one could tell.
But like I would assume this would almost be a reason to to
initiate a hard fork. And for me this is also a signal
that if if people assume this would happen at some point it
would make sense to even make certain components of the safe
smart account to be part of the theorem protocol.
So really enshrine that and make make it very explicit and say
like this is logic that we expect to to behave a certain
way and if it if it's not that case then it would be a
consensus issue and to kind of lead automatically to have fix
that or they will be like a back in a client or something rather
than a back in the smart contract.
And I would assume that eventually we will have to to
move towards that if we see that certain parts of the safe smart
contract are really ossified, we don't expect them to to change
much in the future. We should just make them part of
the protocol. Yeah, yeah, I agree that I think
that would also solve a lot of the user experience issues and
and also the, you know, so the gas issues surrounding, you
know, using safe, obviously like on Ethereum main net, like using
safe can be quite expensive and having that enshrined in the
protocol I think would make sense long term.
And also in terms of just adding new features and having smart
contracts, being able to leverage safes, I think there's
like a huge benefit of saying like, OK, this infrastructure
should be enshrined so that most, most new accounts would be
smart accounts, right. And so let's take a step back
here and talk a little bit about the Nosys ecosystem generally.
So obviously like Safe is a huge part of that.
There's also Nosys chain, there's Nosys Pay and you guys
have lots of other products and teams working on all sorts of
infrastructure. How does Safe fit in with all
this? And you know, what's the long
term vision for? I don't know if you can talk
about like Nosys generally, but yeah, the Nosys ecosystem.
I mentioned at the beginning notices originally wanted to do
prediction markets. It was quite early, it was pre
D5 summer and there was a lot of infrastructure missing in order
to even make prediction markets work.
So there was no secure way to serve custody assets, which
prediction markets would create a lot of assets which need to be
self custody. There was not a good way to
exchange assets because the prediction markets would create
different tokens and they need to be exchanged in a in a
capital efficient way and there's like a bunch of
different things that were missing and Nosis was basically
forced to to build these things out themselves and that's how in
in the end safe was created. That's also how COW swap was
created over the years and and other things also Nosis became a
DAO as Nosis Tao. So suddenly there was
infrastructure needed to really enable have community governance
over nosy style. So that's where safe Snap was
created, a way to connect a safe smart account with snapshot
space in order to have off chain voting but have on chain
execution. And that's then how the Nosy
skill team was born as a way, as a team that's optimising on
building DAO infrastructure. Then Nosy style had the treasury
which had to be managed and that's where the Kabatki team
was born, which is now I think the biggest asset manager for
for Dow treasuries and they they manage Dow treasuries like the
one from Avatar or ENS like all these were initially internal
teams but at some point became spin offs.
But obviously it's it's very much still a close ecosystem.
So the different teams collaborate quite extensively
and now like the future for Nosis is very much centred
around Nosis chain which is another project that was
actually picked up as XI in the past, which then was rebranded
to Nosis chain. It's an inside chain to Etherium
and it allows for horizontal scaling of Etherium block space.
And on on Nosis chain, there's the the payments network Nosis
pay being built out which is really the the second focus next
to Internosis chain itself which is a way to connect defy with
the traditional financial system.
Meaning that the idea is that you are able to really have your
assets on chain but able to spend them off chain and trigger
bank transfers off chain but then result into on chain
transactions and really bridge the gaps between those two
ecosystems. As a first step to hopefully
then have more and more of the the payment ecosystem actually
move on chain and not be yeah rooted still in the traditional
financial systems but then get replaced over time with really
true untrained systems. So they're also safe plays a
very critical role in in Nosys Pay as it's the underlying
account standard for for Nosys pay because something like Nosys
pay actually needs smart accounts in order to work
because it's it is meant to be like self custodial account
which then still allows you to have like a card like a
traditional Visa card associated with it which you can use to
spend off chain. And in order to bridge these
assets off chain you need to have a way that they can be
taken from the account and then put into the Visa network.
But still you don't want to just give like unlimited access of
your of your assets to some to the Nosys pay network there but
they actually want to limit that and that's that requires smart
accounts so that every Nosys card actually is associated with
a safe smart account which has like a yeah a daily limit
associated with that where any transactions that are below this
daily limit can be put into the the Noses pay network and and be
used to to pay at the merchant store.
But it's it's in a way that it's still the vast majority of your
assets are self custodial and it's just yeah this daily limit
that you get then give. And yeah the the long term
vision is really that Nosys is focusing on on building out like
this decentralized payment network that then leverages
things like safe leverages things like cow swap for for
exchange of assets and and other parts of the Nos Eco system.
That becomes really this combination of of the different
infrastructure that was built over the last years and builds
really something that can then bring as as much as possible of
of today's payment volume on chain.
Great. Well, Lucas, thanks so much for
coming on the podcast today. It's been great learning about
SAFE, understanding the the technical implementation of SAFE
and also how it fits into the broader Nosys ecosystem.
So thanks so much for coming on and look forward to having you
back on the future. Yeah, it was a pleasure.
Thank you for joining us on this week's episode.
We release new episodes every week.
You can find and subscribe to the show on iTunes, Spotify,
YouTube, SoundCloud, or wherever you listen to podcasts.
And if you have a Google Home or Alexa device, you can tell it.
To listen to the latest episode of the Epicenter podcast, go to
epicenter.tv/subscribe for a full list of places where you
can watch and listen. And while you're there, be sure
to sign up for the newsletter so you get new episodes in your
inbox as they're released. If you want to interact with us
guests or other podcast listeners, you can follow us on
Twitter. And please leave us a review on
iTunes. It helps people find the show
and we're always, I'm happy to read them.
So thanks so much and we look forward to being back next week.