0:00

The entire ecosystem at that point, all the projects

0:02

doing their own ICOs during the 2017 phase

0:06

started adopting this multi-signature wallet as

0:08

well. In the long run,

0:11

these smart accounts will be the solution and

0:13

there's no way around smart accounts in order

0:15

to get to the user experience while

0:18

still retaining security that

0:20

is needed to onboard a

0:22

billion people to Web3. I

0:25

would say when it comes to cross-chain,

0:27

smart accounts in the short term will

0:29

bring new challenges. In the long

0:31

run, we will actually solve cross-chain in a way

0:33

that can make it irrelevant

0:36

in what networks you

0:38

interact with, what dApps, but this can

0:41

be abstracted away. This

0:56

episode is brought to you by Gnosis. Gnosis

0:58

builds decentralized infrastructure for the

1:01

Ethereum ecosystem. With a

1:03

rich history dating back to 2015 and

1:06

products like Safe, Cowswap, or Gnosis

1:08

Chain, Gnosis combines

1:10

needs-driven development with

1:13

deep technical expertise. This

1:15

year marks the launch of Gnosis

1:18

Pay, the world's first decentralized payment

1:20

network. With Gnosis Card,

1:22

you can spend self-custody crypto

1:24

at any Visa accepting merchant

1:26

around the world. If

1:28

you're an individual looking to live more

1:30

on-chain or a business looking to

1:32

white-label the stack, visit

1:35

gnosispay.com. There are

1:37

lots of ways you can join the Gnosis

1:39

journey. Drop in the Gnosis

1:41

DAO governance form, become a

1:43

Gnosis validator with a single GNO token

1:46

and low-cost hardware, or

1:48

deploy your product on the EVM-compatible

1:50

and highly decentralized Gnosis Chain. Get

1:54

started today at gnosis.io.

2:00

Node operators globally and help you

2:02

stake your tokens on 45-plus networks

2:04

like Ethereum, Cosmos, Celestia,

2:07

and DyDX. More

2:09

than 100,000 delegators stake with

2:11

Chorus One, including institutions like

2:13

BitGo and Ledger. Staking

2:15

with Chorus One not only gets you the

2:18

highest years, but also

2:20

the most robust security practices

2:22

and infrastructure that are usually

2:24

exclusive for institutions. You

2:27

can stake directly to Chorus One's public node

2:29

from your wallet, set up a white label

2:31

node, or use the recently launched product,

2:33

Opus, to stake up to 8,000 ETH

2:37

in a single transaction. You

2:39

can even offer high-year staking to

2:41

your own customers using their API.

2:43

Your assets always remain in your

2:45

custody, so you can have complete

2:47

peace of mind. Start staking today at

2:50

Chorus.one. Welcome

2:53

to Epicenter, the show which talks about

2:55

the technologies, projects, and people driving decentralization

2:57

in the blockchain revolution. I'm Sebastian Cuchur,

3:00

and today, I'm all by myself. I'm

3:02

chatting with Lucas Shor, who's

3:04

the co-founder at SAFE. SAFE is, of course,

3:07

the leading smart

3:10

account multi-sig provider in the

3:12

EVM ecosystem. They're securing

3:14

over $100 billion in assets

3:16

and are absolutely crushing it

3:18

when it comes to securing assets.

3:21

We use SAFE at Interop Ventures, and I'm

3:23

sure lots of you out there are also

3:25

using SAFE. They were

3:27

spun out of Gnosis a couple of years ago, and

3:30

I'm going to be talking with Lucas

3:32

today about the technology behind

3:34

SAFE, but also the strategy moving forward

3:36

and what does the future of SAFE

3:38

look like. Hey, Lucas, thanks for joining

3:41

us today. Thanks for having

3:43

me, Sebastian. Before

3:46

we get started, how did you become

3:48

part of the SAFE team? Were you previously at

3:50

Gnosis? Because

3:52

I think you're one of the co-founders of SAFE.

3:54

What's the story there? Yeah,

3:57

that's right. SAFE is the spin-off

3:59

from... from Gnosis. I

4:01

joined back in 2019 as

4:04

a product manager responsible for

4:06

the, at that point, Gnosis safe

4:08

project within Gnosis. Actually, I was

4:11

applying half a year before that to

4:13

Gnosis in the marketing department. I got

4:15

rejected right away. That's just a fun

4:17

fact on the side. Then half a

4:19

year later, I saw that was more

4:21

relevant to my background, the product manager

4:23

role opened up and I was jumping

4:26

on that and that was luckily successful.

4:28

So I joined when the Gnosis

4:31

safe project was quite its early

4:33

stages. Then took

4:35

over together with Richard

4:37

and Tobias, my co-founders,

4:40

the project responsibilities and over

4:42

time then the project

4:44

group and it outgrew to

4:47

some extent Gnosis as in the kind

4:49

of the team size

4:51

grew and the focus

4:55

expanded beyond what it's originally meant to

4:57

be and it became its own ecosystem.

4:59

That's when we decided together with the

5:02

Gnosis team that it's better off to

5:04

continue the project outside. We have

5:06

maybe a little bit of the history

5:08

of how this project came to

5:10

begin with. So

5:13

Gnosis, like back in 2016

5:15

was started to create prediction

5:18

markets. So that's a way

5:20

to financially incentivize participants

5:22

to share their knowledge in order to

5:25

expose that knowledge to the public

5:28

and that's meant to be as a primitive

5:30

on the firm blockchain and Gnosis

5:33

went ahead and did an ICO in order

5:36

to fund that project and it

5:39

happened that the ICO was

5:41

quite successful. Gnosis had to

5:43

custody a lot of the

5:46

proceedings from that ICO and

5:49

back then the entire self custody

5:51

infrastructure was quite early on

5:54

meaning that they had to create their

5:56

own solution. So Stefan Bjorgge was the

5:59

co-founder of Gnosis. wrote

6:01

himself a multi-signature contract, which

6:04

is a way to share

6:06

the responsibility of a self-cast wallet

6:29

as well. And that's

6:31

how the team was formed. Sunday

6:33

had many projects that were using

6:36

this solution and there were feature

6:38

requests coming in and people wanted

6:40

to have the project maintained. And

6:42

so the project formed, it became

6:44

its own team within

6:46

Gnosis and that's roughly when, when I

6:48

joined. Yeah, cool.

6:51

I mean, I think it bears reminding also that

6:53

like, you know, back then, like you said, there

6:55

were no good solutions

6:57

for doing multi

6:59

stakeholder asset custody.

7:01

Bitcoin had an

7:04

on-chain in protocol solution, still

7:06

has. And, you know, in

7:08

Bitcoin, you can create an on-chain multi-sig.

7:11

And, you know, this is something that a lot

7:13

of people, like, including myself, have used, you know,

7:15

with Epicenter, we've used this also quite a bit

7:17

in the early days when we were a Bitcoin-only

7:20

company. But yeah,

7:22

even then, like, it's quite cumbersome

7:24

to set up the keys and

7:26

everything. But Ethereum didn't have an

7:29

on-protocol solution. Do

7:31

you know why that is? Like,

7:33

why Ethereum didn't go down the

7:35

same path as Bitcoin and build

7:38

an in-protocol way to

7:40

do multi-stakeholder asset custody? Yeah,

7:44

I mean, it's always the question what should

7:46

be really enshrined as part of the protocol and

7:48

what should be then solved a layer above

7:50

on the smart contract level. It

7:53

actually happened that Ethereum originally wanted to

7:55

have smart accounts. So

7:57

accounts that based their logic on smart

7:59

contracts. have

8:02

this natively within the theorem.

8:05

It was then, it turned

8:08

out that this is quite complex to

8:10

do and the team at the Ethereum

8:13

Foundation was a bit of a

8:15

time rush to launch Mainnet. So

8:18

the Discord did last minute and

8:21

we since then had

8:23

our wallet infrastructure on

8:25

the theorem mostly based on EOAs.

8:27

So externally owned accounts. These are

8:30

the accounts everyone knows that are

8:32

controlled by a single private key

8:35

usually derived from a seed phrase,

8:37

12-24 word

8:40

secret phrase and that's

8:42

where the wallet infrastructure was built upon.

8:44

I personally think that

8:46

it's a better pathway to solve as much

8:48

as possible on the smart

8:51

contract level there in terms of like logic

8:53

of an account because if you look at

8:55

what you mentioned the Bitcoin

8:57

multisig implementation it

9:01

works quite nicely for certain use

9:03

cases but it's quite limited because

9:05

you have all the logic enshrined

9:07

in the Bitcoin protocol and

9:09

for example that means that certain

9:12

use cases such as rotating keys

9:15

if not possible with the Bitcoin multisig. So

9:17

you once can set up your multi

9:19

signature wallet you might have a

9:22

certain threshold of signatures required to

9:24

make transactions but then if

9:26

you lose access to one

9:28

of the keys or it gets compromised you

9:31

actually have to move your funds to have

9:33

complete the new Bitcoin multisig and

9:35

you cannot just rotate

9:37

one key and continue with

9:40

the same wallet. These things are

9:42

solved by just leaving

9:44

the logic up to the smart contract

9:46

level and allowing different

9:48

implementations to take different optimizations

9:52

and different technical

9:54

assumptions and this creates much more

9:56

flexibility then and over time we

9:58

will probably see certain certain standards

10:01

or certain best practices

10:03

emerge and potentially at some point these can

10:05

be enshrined again in the

10:07

Ethereum protocol once

10:10

we see that these are actually must-haves and

10:13

if the standardization value is

10:15

higher than the flexibility of

10:17

having different implementations. Yeah,

10:21

I think the enshrine in question is

10:23

one that needs a

10:25

lot of, of course, reflection and we

10:28

need to be careful what we enshrine

10:30

into the protocol or not. But

10:33

yeah, taking a step back from that, let's maybe

10:35

dive into smart accounts or

10:37

at least the way smart

10:40

accounts are conceived of in the

10:42

Ethereum space. I think most of

10:44

the research is around

10:46

this ERC 4337. Yeah,

10:50

give us an overview of what is ERC 4337 and

10:53

how it aims to implement smart accounts on

10:58

DBM chains. Yeah,

11:00

there's actually quite some misconceptions still on

11:03

what ERC 4337 is. So

11:06

some people think that ERC 4357

11:08

is smart accounts and all

11:11

the logic, all the possibilities that are enabled

11:13

through this standard is

11:16

due to the ERC 4357 standard

11:18

while most of the features such

11:21

as recovery or accession keys and so

11:23

on are actually the responsibilities

11:26

of the smart accounts. So smart

11:28

accounts have existed since years. Yeah,

11:31

safe has been around since five, six years

11:34

and a lot of

11:36

what we are now talking when

11:38

we talk about the potential of

11:40

4357 has been possible before with

11:43

one exception, which is

11:45

actually processing smart account transactions in

11:47

a trustless way. That's

11:49

a big problem that's solved by ERC 4357. So

11:54

as I mentioned, the Ethereum protocol,

11:56

it has two types

11:58

of accounts, it's EOA. externally owned

12:00

account and smart contracts, which can then

12:02

be used to make smart accounts. And

12:06

yet transaction actually in order

12:08

to be processed needs to originate from

12:10

an EOA. And

12:12

that's a challenge because you have

12:14

certain use cases of smart accounts, you

12:17

actually might not even want to

12:19

have an EOA involved if

12:21

you use certain like new

12:23

signature schemes, keys or so on,

12:26

where there's no EOA part

12:28

of the transaction lifecycle. But

12:32

so far, how it worked is that you

12:34

had to fulfill the transaction

12:37

verification requirements, be it in a

12:39

multi-sig case that you collect the

12:41

different signatures from the participants, but

12:44

then still you need to have an EOA involved

12:46

in the transaction in order

12:49

to actually process that transaction on the

12:51

film blockchain. So usually how

12:53

that worked is that you had like

12:55

everyone signed the transaction and then the

12:57

last person that was signing was the

12:59

poor person that actually had to pay

13:02

for the transaction fee from his EOA

13:04

account. And yeah, that's

13:06

now coming to ERC 457. So

13:10

just to kind of put a pin in that,

13:13

essentially what you're saying here is that a

13:15

smart account like SAFE

13:19

can have multiple types of

13:21

signers verifying and executing,

13:23

sort of signing for the transaction. But at the end

13:25

of the day, at the end of the transaction, an

13:28

EOA needs to execute that

13:30

transaction on chain and pay the gas fee.

13:33

So like we encounter this, basically every time we

13:35

do a safe transaction, all

13:37

of us sign and then

13:39

we have like one account that has just like a

13:41

bunch of ETH on it and it's just used to

13:43

pay for gas. And

13:46

that account basically executes the transaction and sends it on chain

13:48

and that has to be an EOA account. It

13:50

can't be some other sort of signer or even

13:52

another smart account. It has to be an on-chain

13:54

account. It's actually at

13:57

least so far And it doesn't

13:59

even need to. In you a that to

14:01

use a controls so even in the

14:03

past there were a relay A systems

14:05

are like a bike on me or

14:07

to not to or a private to

14:09

be layers that I just you wasted

14:11

are funded that them and are instructed

14:13

at once. Does this might a conscience

14:15

Actions it's like for the every fight

14:17

and to her. For the science

14:19

that and displays system which will take fifty

14:21

you a and and pay for gas fees

14:24

and put on chain. And right now.

14:26

That's where the and yes you foresee for some

14:29

comes in My we say that to. Get.

14:31

Yes, be that the half. Sort. Of

14:33

like a separate men pool for the smart a

14:35

conscience saxons. At where we can

14:38

just add dead my to concerts

14:40

actions are for the signs are

14:42

has fully that it and then

14:44

the has a decentralized mechanism are

14:46

these transactions or then puts on

14:48

same as actually still enjoy in

14:50

both so that's a to you

14:52

a doctor Bundler India in India

14:54

standard consoles to bundler such as

14:56

as collecting all different smarter Concerts

14:58

actions and are done at bundling

15:00

them together and and put them

15:02

on chain of by paying for

15:04

gas fees and using data you

15:06

eight. And state and and

15:08

get her repeat for discuss the

15:10

expenses by paymaster which is another

15:13

component of the standard. At.

15:15

Which them as I was data to

15:17

ponder isn't sitting on the costs but

15:19

actually it get out. Next. Year over

15:21

I did he miss Be some forfeit. As

15:24

and. Exactly the to standard

15:26

now. And allow such as

15:28

know. Taft. Centralized Three, they

15:30

are involved anymore used on the to

15:32

fund their own. Yeah, oh Ace, but

15:34

it just trust at there's this decentralized

15:36

network of bundlers that they can just

15:39

throw in added says action and he

15:41

gets executed in the justice way. Okay,

15:44

So just to recap years yet

15:46

ear see four, three, three, seven.

15:49

Uses existing smart account. For

15:51

Leverage is existing smart account infrastructure.

15:54

By. ah offsets the

15:56

execution or or sense

15:58

of responsibility execution to this

16:01

Bundler network, that Bundler network

16:03

does the on-chain execution of

16:06

any smart account transaction that

16:09

is ERC 4337 compatible

16:11

and that therefore alleviates

16:14

the initiators of that transaction

16:16

to have to, well, a, execute

16:18

it and b, pay for the

16:21

on-chain gas costs. Does

16:24

ERC 4337 by bundling these transactions,

16:27

I suppose it also implies gas

16:30

optimization because you're bundling all these transactions together

16:32

and possibly saving on gas by doing so?

16:36

There is some component of gas savings.

16:39

In the end,

16:41

the ERC 457 architecture adds some gas

16:43

overhead itself, but assuming

16:46

that there's a lot of

16:48

adoption of the standard over time, the

16:50

overhead decreases and even at

16:52

some points that there should be ways

16:55

to even have better gas

16:58

efficiency than just using a smart

17:00

account natively itself. Just

17:05

to come back to this signing and

17:07

execution process, so when you

17:09

have encountered this a bunch

17:11

of times where we started

17:13

transaction and then we realized

17:16

maybe the amount was wrong or there's

17:18

some issue with the transaction as we're

17:20

signing it. That happened recently,

17:22

where I had a zero too

17:24

few in my amount. And

17:29

so then you have to go through this

17:31

process of reverting

17:34

the transaction and that's

17:36

because you've already signed part

17:38

of that transaction at any point in

17:40

the future. Other signers

17:43

could sign for the rest of

17:45

that transaction and actually execute it.

17:47

Now when it comes to this bundler

17:49

network, a transaction that

17:51

has been fully signed is basically

17:55

ready to be executed. Is

17:57

there another step then that the... Diners

18:00

of that transaction. Have

18:02

to make in order for that transaction

18:04

to be made say public or does

18:06

it remain within the hands of the

18:08

signers and kind of private. Until.

18:12

And. Actions taken to reveal it

18:14

to anyone including this bundle network

18:16

to then execute on same. There's.

18:19

Probably two steps to that a plan.

18:21

This studs. After the partially sighted,

18:23

transactions can stay private until it's

18:25

fully signed on, it's censored or

18:27

to the Panda Network, yet still.

18:30

Like others that are participating for something

18:32

a multi signature use case have access

18:34

to this party sign transaction so they

18:36

could complete his sons action and send

18:38

it to the bundle network. At

18:41

a later point. but once a day

18:43

is center bonded and you need to

18:45

assume that is out there and it

18:47

could be executed at any point. but

18:49

this itself is. Not. Different tend

18:51

to how you a smirk as month

18:53

if you sign a transaction. Met him

18:55

asked today if you have her to

18:57

though for guess he and this just

18:59

suck and mm pool it's like it

19:01

can be executed at any point. Which.

19:04

Are you can resolve by. Sending.

19:06

It's was action again this a higher

19:08

Agassi in order to speed up the

19:10

transaction or by replacing the transaction on

19:12

the same nonce with a different transaction.

19:14

So that would also be the case

19:16

with Smart a constant. Also have an

19:19

aunt and so once a transaction dennis

19:21

executed at the same nonstop means that.

19:23

The. Other partially centers action or for the

19:26

cents action is not able to be

19:28

executed anymore and can be disregarded and

19:30

that are up into point when the

19:32

nazis still available as it was acting

19:34

as is out there like it needs

19:37

to be assumed that it can be

19:39

executed. I

19:41

guess we've cliff. I hear that your

19:43

see four three three Seven is related

19:45

to. A executing transactions

19:48

or is there any away? that

19:50

is. I creating a

19:52

standard for how smart accounts should.

19:55

not be conceived i got in terms of the

19:57

architecture of the starts mark out or is that

19:59

up to smart account

20:01

like companies and

20:03

service providers to decide

20:06

as long as they are compatible with ERC

20:08

4337 they can do whatever they want on

20:10

the software side. Yeah

20:13

so ERC 457 itself has already

20:16

some requirements to more

20:18

smart accounts. For example

20:20

that it requires that the smart account

20:22

transaction is starting from the account itself

20:25

which is relevant if you think

20:27

about modular smart accounts we

20:29

might have different execution logic

20:32

for an account and have it

20:34

depending on what type of transaction

20:36

it would require a different signature

20:38

scheme or so on and

20:41

there the transaction needs to start in

20:43

the account and then go to the

20:45

to the module which contains the execution

20:47

logic which yeah there's some

20:50

details there that just define how

20:52

the account works. There's other ERCs

20:54

that standardize certain

20:56

patterns for smart accounts such

20:58

as proxy patterns or

21:01

now more recently

21:03

again with modular smart accounts

21:06

there's certain initiatives from

21:08

the community that say the

21:10

idea should be that we

21:12

can create these different modules which you can

21:14

imagine to be in a way like apps

21:17

on a smartphone so we

21:20

shouldn't go to a world where you

21:22

change your account in order to

21:25

have add a new feature to it be

21:27

it like a session key recovery or something

21:29

like that but instead it should be

21:31

like downloading nap on your smartphone and

21:35

that's enabled through these modular smart

21:37

accounts which means that you have

21:39

your base account which actually has

21:41

certain default logic and you expand

21:43

that with modules this

21:46

can be validation plugins these

21:48

can be certain safeguards that are added

21:50

to an account and that

21:52

then extends the logic of the con and

21:55

there there's no initiatives that say we

21:57

want to have yeah certain parts of

21:59

this architecture of this model

22:01

architecture be the same across different

22:04

smart account limitations. Why

22:06

should we do that? The idea is

22:08

that you then don't have to create

22:10

these modules for different implementations

22:12

separately but you can actually assume that

22:15

they have certain standards that they comply

22:17

to and the module that you create

22:19

for smart account A works the same

22:22

way also with smart account B. There's

22:25

actually two standards out there as

22:28

always it's

22:31

not enough to have one standard, you have a second

22:33

standard and then the first standard to get rid of

22:35

the other two and so on but

22:38

there is ERC 6900 which was started

22:41

last summer by the alchemy team and

22:43

you got ERC 75 79 which is collaboration

22:47

between rhinestone by economy, okx

22:50

and others that

22:52

define different ways how these modular smart

22:54

accounts could look like with

22:56

some different technical assumptions. Completely

22:58

ERC 6900 bundles the modular architecture

23:02

also with a permissioning system so you say you

23:05

have these different modules and you want to give

23:07

certain permissions to these modules

23:10

as a security function and

23:12

ERC 75 79 is

23:14

a very minimal standard that really

23:16

just focuses on the modular architecture

23:19

of smart accounts and leaves

23:21

the security the permissioning system potentially

23:24

to future ERC and just says we

23:26

shouldn't over complicate things we should just

23:29

focus on one thing after the other

23:31

and these

23:33

standards are in a way competing at

23:35

this point from the saves

23:38

perspective we actually want

23:40

the saves smart account to be

23:42

compatible with any standard so that's

23:44

possible as safe itself has

23:46

some native modularity

23:49

built-in so it already has some

23:52

some ways you can extend the smart account and

23:54

then you can just add an adapter in order

23:56

to be compatible with ERC 6900 or as another

24:00

adapter to be compatible with 75

24:03

79, which makes it just future proof. It's

24:06

still unclear how these standards

24:08

evolve. They're all quite early,

24:11

got little adoption so far, and

24:14

they might still change over time. So our

24:16

philosophy there is that we want to save

24:18

smart account really to be as low

24:22

level as possible so that no matter how these

24:24

standards evolve, we can just add

24:26

another adapter to support them. And we

24:28

have an account that lasts forever. Incredible.

24:33

So what is safe design philosophy

24:35

here? I mean, because you guys

24:37

have like safe core, which is

24:39

the core of the safe

24:41

product and the smart contract logic.

24:45

Do you think that

24:48

this should be kept as minimal

24:51

as possible in terms of features and

24:53

all extensions sort of bring

24:55

into the functionality or are you

24:57

more like this conservative approach to

25:00

design or do you have more

25:02

of a broader approach to design

25:04

where this core could

25:06

also include other functionalities that

25:08

are currently being fulfilled by

25:11

the plugins or modules? Yeah,

25:14

I mean, there's probably

25:17

two key philosophies for

25:20

safe. One is that safe, as

25:22

the name says, this is very much focused

25:24

on security. So that's

25:27

just defined everything we

25:29

do at safe in terms of like how we

25:31

approach upgrades to the smart account,

25:33

how we approach, how we balance,

25:36

for example, as a flexibility versus

25:38

security versus gas efficiency. So we

25:41

always default more towards

25:43

the security side. And the

25:45

other one is that we want to be as

25:48

use case agnostic and use the group as

25:50

agnostic as possible, meaning that

25:53

the account itself, the

25:55

core safe smart account should be based primitive,

25:57

but then you can expand it

25:59

depending on the user. depending on the use cases

26:02

and optimized and full

26:05

its modular architecture to different ways

26:09

to use the smart account. That

26:12

also means that we very much

26:15

depend on the ecosystem around

26:17

safe. That's something that was

26:20

clear early on that if

26:23

you really want to bring Web3 towards

26:26

smart account adoption, if we want every account

26:28

to be a smart account, which is our

26:30

mission, we cannot aim

26:33

to do this ourselves. We really

26:35

rely on the ecosystem and the

26:37

community of builders to help us

26:39

with that. What

26:42

the idea is that the safe smart account

26:44

becomes this very core of

26:46

this smart account transition and then we have

26:49

others that are building the different use cases,

26:51

be it different types of wallets with the

26:54

asset management solutions that then have

26:56

built around this core primitive and

26:58

extend with what they did for

27:00

them. Is it automation? Is it

27:02

session keys? Maybe for a gaming

27:04

use case? Is it more

27:06

past keys if you want to build a retail

27:09

wallet? That then

27:11

puts us into a role of

27:14

building this core protocol and working

27:16

together with the ecosystem for ecosystem

27:19

support initiatives to

27:23

target these different user groups from

27:25

their perspective. In Safe Core, there's multiple

27:27

components. We have the smart account, which

27:29

we've talked about. There's

27:32

also the SDK that sits on top

27:34

of it, which allows, like you said,

27:36

wallet developers to utilize the safe infrastructure.

27:38

We haven't talked about the API, which

27:40

I think is an overlooked aspect of

27:42

Safe Core. The

27:44

way I understand it, one of the roles of

27:46

the API, of course, is to coordinate around the

27:49

signature. When you're signing a safe

27:53

transaction and that transaction

27:55

then pops up on the wallet

27:57

of, say, your co-signer or a

28:00

like another signer in the

28:02

wallet configuration, that is happening

28:04

via an API that I'm not exactly

28:06

sure how it works. So I don't know what is

28:09

NoSys's or sorry, SAFE's the company's

28:12

involvement in running infrastructure, it's gonna centralize infrastructure

28:14

that makes that possible. Or is there an

28:16

on-chain component there? I'd love it if you

28:18

could explain how the API works and who

28:21

are the third parties that it may

28:23

rely on. The smart

28:26

account with the smart contacts

28:28

suite is the

28:30

core of it all, but then we provide tooling

28:32

for developers that just make it more accessible. If

28:35

you want to build an application using smart accounts,

28:37

if you want to use to build

28:39

a wallet, then things

28:41

like an SDK or API just

28:44

make this more accessible, make the

28:46

transition from EOAs easier. And

28:49

yeah, we just always evaluate what's the

28:52

things that we can provide to the

28:54

ecosystem in order to make it easier

28:57

to build on smart accounts. And right now

28:59

it's an SDK that just allows to have,

29:01

to interact with the smart account, to craft

29:04

signatures and so on, and

29:07

to also work with the ERC 457 relaying

29:09

network and

29:12

the API, as you say, that's, it's

29:14

essentially an indexer, the

29:17

most part is an index, so it just

29:19

indexes all the safe smart account transactions out

29:21

there and makes them available for developers. So

29:24

you can say, you can

29:26

track different saves, for example,

29:28

there's also an event service to it. So

29:30

you can track if there's any updates to

29:32

it, if transactions are triggered, if any incoming

29:35

assets and so on, in order to display

29:37

this to the user. But it also has

29:39

a component of the signature collection, which is

29:41

especially in a multi-signature use case quite critical

29:44

because you don't want to have every

29:46

signer in a multi-sign on-chain. At

29:49

least in most cases, you might want to

29:51

save on the gas cost of signing on-chain

29:53

and you set your signer signature, sign

29:56

the transaction off-chain, but then you need a

29:58

way to exchange these. partially signed

30:00

transactions with other participants of the

30:03

multi-sig and that's done also

30:05

via the the API so

30:07

I can just post these partially signed transactions

30:09

and retrieve them from another user

30:12

and that just allows to exchange

30:15

these transactions. Technically it would be

30:17

possible to exchange these transactions for

30:19

any other means. They have

30:21

also on-chain signatures of course but also

30:23

by just downloading a file and sending

30:26

it to someone else obviously that's not

30:28

very user-friendly but yeah that's why

30:30

we provide this service. It's also an open

30:32

source service so there are projects that run

30:34

it themselves just as a redundancy

30:37

and we eventually also want

30:39

to get to a place

30:41

where there's actually a decentralized

30:43

network of indexers that participate

30:46

in retrieving and we

30:48

have sharing these partially signed

30:50

transactions just because it's

30:52

always better to not rely just on

30:55

a centralized service even though like

30:57

anyone could run the service themselves and so on but

31:00

the truth is that it probably

31:02

would take quite some time until some other service

31:04

would spin up that has a

31:06

similar performance that would then have

31:09

step in if our indexer

31:11

would be done or so so

31:13

we have to pathway towards this decentralized

31:15

index network is something that we are

31:17

looking into. Yeah

31:19

okay interesting so currently for

31:22

all of the safe wallet products I

31:25

guess safe is running that infrastructure in

31:27

a kind of centralized way but as

31:29

a user you can choose to either

31:32

run your own infrastructure or

31:34

if you're a company using safe you can

31:36

also run that infrastructure yourself for redundancy but

31:39

you can also share the signatures on

31:41

chain correct? They correct. Okay

31:44

interesting now that might make sense on

31:46

some networks that have like lower gas costs but

31:48

on Ethereum that might be a bit

31:50

prohibitive. Yeah and it also

31:52

makes sense as

31:55

this service is only run for a certain

31:57

set of networks. on

32:00

that network where the index is not run,

32:03

we can still sign on chain, and

32:05

it also is an additional redundancy if the

32:07

service is not available, then you could just,

32:10

with some little extra gas cost, you could

32:12

sign on chain and not

32:14

be dependent on it. Okay,

32:17

great, this is cool. Thanks for clearing that up. On

32:19

the, yeah, on the wallet side,

32:22

I'd like to talk a little bit about

32:24

the user experience here and what are some

32:26

of the challenges that you guys face when

32:29

building in a wallet that supports

32:31

SafeCore. And

32:35

I like to preface this by saying I've had

32:37

my share of moments using Safe

32:39

where I didn't really know

32:41

what was happening or where my

32:43

transaction was in the queue or whether

32:46

trying to sign a transaction is not working and

32:48

I'm getting some weird error message. And I've actually

32:50

talked to SafeSupport like

32:53

two or three times when executing a transaction

32:55

and they've always been very helpful. And

32:58

have helped sort of clear things up, but yeah,

33:01

how do we come to

33:03

a better user experience around

33:05

these things? Because it's still

33:08

super cumbersome. I mean, especially

33:10

if you're using a ledger and then you

33:12

sign with MetaMask and it all

33:14

feels very cumbersome and

33:17

I still stress

33:19

every time I do a multisig transaction because

33:22

there's just all these moving parts that

33:24

need to work. And it

33:26

always feels like a bit of a lift

33:29

to get that transaction signed. So yeah, what

33:31

are your thoughts on user experience generally and

33:33

how can we improve all this? This

33:37

is actually interesting because there's like two

33:40

camps here. Some people say like

33:42

the Safe Wallet interface is

33:45

already quite user friendly and some

33:47

still have issues. It's probably also

33:49

to some extent, if you compare where Safe

33:52

Wallet is today compared to where it is

33:54

two, three years ago, I

33:56

would say there's like a massive improvement in user experience since

33:58

then, but obviously it's still... long

34:00

way to go. Also challenge there is that we

34:02

want to have say for the P as user

34:05

group and use case agnostic so we

34:08

cannot optimize for say someone

34:10

that's super technical that wants to see

34:14

all the information and always be able

34:16

to look under the hood of everything

34:18

at the same time optimize for someone

34:20

that is less technical that

34:22

really wants to have everything abstracted away so we

34:25

always try to be somewhere in the

34:28

middle and then actually work with

34:30

ecosystem to provide the best experiences

34:32

for the different user group so

34:35

for example there's an on-chain

34:37

den which specializes really on

34:39

multi-signature in a team use

34:41

case and having transactions they

34:43

say that the interface that

34:45

allows you to have signed transactions

34:48

the fastest and they have

34:50

like some notification

34:53

system behind it and so on

34:55

and some some gas abstraction and

34:57

they do certain optimizations there and

34:59

then there's others like a Nest

35:01

wallet which is optimizing more for

35:03

individuals and retail users

35:05

that allow allows them to

35:07

abstract a little bit more from the

35:09

details away and have like a more

35:12

smooth user experience where maybe

35:14

the trust team collaboration part is less

35:16

of a focus so that's

35:18

really our strategy that we say say for that

35:20

is like a baseline it should

35:22

be like an interface that people

35:24

can start using in

35:26

order to get experiences with smart accounts

35:29

to to cover certain use

35:31

cases but then as you over

35:33

time there should really be like

35:36

a wide ecosystem of designated solutions

35:38

that optimize for for

35:40

different solution yeah

35:42

user groups that's cool I

35:44

made a note of these I think I'll probably

35:46

try them out as well this so you said

35:49

on-chain den and nest wallet yeah

35:51

I mean with like the some

35:53

of the issues I faced were yeah I

35:56

think like ordering of signing and

35:58

and then you know not able

36:00

to post a transaction on Chain and having

36:03

to update that transaction with

36:05

a new nonce. These kinds of things are

36:08

very unintuitive, I think, for most people and

36:10

even me. The error message

36:12

really doesn't explain much of what you

36:14

need to do. So I think having

36:18

kind of an app resolution mechanism to

36:20

kind of fix this problem without

36:23

having to reach to support or look for

36:26

things online. And the other thing is

36:28

I think there's I find there's like some

36:30

inconsistencies between the way the wallet, the mobile

36:32

wallet works and the desktop works, the

36:36

kind of web version. And one

36:39

thing I've never really understood is with the

36:41

with the mobile wallet, and by the

36:43

way, the mobile wallet is great. Like, I typically

36:45

do transactions on the mobile wallet, I think that

36:47

that's the best user

36:50

experience, I think for, you know,

36:52

for what we do. And we have a bunch of

36:54

ledgers that we sign with. And I love that the mobile

36:56

wallet supports the ledger, and we can just like pull them

36:58

out and get together and you know, sign

37:00

things. But there's one thing

37:02

I don't really understand is like why you need to

37:04

have a it seems

37:07

like you need to have an on device

37:09

account. So like when you create the save

37:11

for the first time, you

37:13

need to have like a seed phrase that you

37:15

have to store somewhere it's generated on the it's

37:18

generated in the app. And I haven't

37:21

found a way to be able to

37:23

sign the transactions with anything else than

37:25

that. On wallet

37:27

account, I can't execute with with

37:29

the ledger, which kind of

37:31

seems a bit backwards to me if we're going

37:34

to have ledgers to to sign save transactions to

37:36

then have to have this less

37:38

safe kind of hot wallet, you know, on

37:41

the device. So that's that's, yeah,

37:43

I don't know, maybe I'm doing something wrong here. But that's always

37:45

been a little confusing to me. Yeah, are

37:48

you using Android? No,

37:50

iOS. Okay, because

37:53

technically, it should be possible to execute also

37:55

with ledger. So the idea about the

37:57

mobile wallet is that it's it

37:59

should be just a very smooth way to cosign

38:02

transactions and you can add any kind of

38:05

wallets to do so like lecture via Bluetooth

38:07

or mobile wallets via WaluConnect

38:09

and Yeah,

38:12

I can look into this. I think yeah,

38:14

we'll have to talk after but yeah, so

38:16

there's like these kind of minor UX

38:19

things that I find, you know can be can

38:21

be improved but overall You're

38:23

like I agree with you that the experience Generally

38:27

is is is pretty good You

38:29

know compared to look like ten years ago

38:31

Brian and I used to do Bitcoin transactions

38:34

electron wallet and we have to send the

38:36

partially signed transactions over slack And you know,

38:38

it was a huge mess, right? I mean

38:40

like this is definitely a

38:42

huge leg up from having to do

38:45

this kind of shenanigans Which

38:47

you know for people who have been this based

38:49

long enough will will be will be familiar with

38:51

yeah And I mean that's something

38:53

in terms of user experience That's very close to my

38:56

heart because I think in general the web free space

38:58

Like we're staying saying things since yes that

39:01

we're still early and at some point we

39:03

cannot allow us to say that

39:05

anymore because we it's still quite cumbersome

39:07

if you want to do full self custody and

39:10

interact with with taps and like that's

39:12

still not that accessible to a wide

39:14

range of of people in

39:17

the world like Even just

39:19

having pretty much everything default to English

39:21

like that's fine for certain parts of

39:23

the Western world But we need to

39:25

have more localized solutions, but also in

39:27

general how the DX works of wallets

39:30

today There needs to be

39:32

so much more that we should do in

39:34

next years and That's also why I'm so excited

39:36

about smart accounts because I think in

39:39

the long run these smart accounts will be just

39:41

a Russian And there's no way around smart

39:43

accounts in order to get to the user experience while

39:46

still retaining like security That

39:49

is needed to to onboard like a

39:51

billion people to to a tree Yeah,

39:55

I think smart accounts are huge unlock

39:57

there, and I'm really looking forward to

39:59

more broadly adoption of PASCE

40:02

and other ways of signing.

40:04

So I'll tell you a little bit about what's happening.

40:06

I don't know if you're familiar with this, but in

40:08

the Cosmos ecosystem, Osmosis, which

40:10

is the major DEX there, are

40:13

doing an on-chain smart account. Now, of course, the

40:15

difference here is that they manage the entire chain

40:17

and they can really build

40:19

things on-chain and also have

40:21

certain types of transactions be either

40:24

gas subsidized or gas optimized. The

40:27

idea here is to do a smart account on-chain

40:29

that you can set up using

40:31

OOS, like a Twitter account

40:33

or a Google account, and then based

40:36

on the value of the transactions you're

40:38

doing, or perhaps even the value on

40:42

the account itself, then you'll be required

40:44

to add a second factor

40:46

authentication. So it could be like a PASCE

40:49

or a secondary account to sign. They're

40:52

building all of this infrastructure on

40:54

the chain, which is great when you're doing your own

40:56

chain. Another

40:58

question I wanted to ask you is, what's

41:01

SAIF's strategy when it comes to

41:04

building its

41:06

cross-chain presence? By

41:08

cross-chain, I don't mean just EVM chains, which I

41:11

know you guys are supporting very well, but

41:13

other ecosystems like Solana, like

41:15

Cosmos chains, like the move

41:17

ecosystem, the Aptos

41:20

and SUI, are you

41:22

guys looking at those ecosystems at all and thinking of

41:24

ways that SAIF can support those? Or is your

41:26

focus really just the EVM and you'll

41:29

stick to what you're great

41:31

at? I would

41:33

say when it comes to cross-chain, smart accounts

41:35

in the short term will bring

41:37

new challenges in the long run and will

41:40

actually solve cross-chain in a way that it

41:42

can make it irrelevant

41:44

in what networks you

41:46

interact with, what dApps, but this

41:49

can be exacted away through smart

41:52

accounts. But in the

41:54

short term, there are challenges. One of

41:56

them is that smart accounts, they are

41:58

just very unique

42:00

per chain. Because these are smart contracts,

42:03

they deployed on a certain network, they

42:06

have their logic on that network, which

42:08

means that while it's possible to

42:10

have a similar smart account on a different

42:13

network with the same logic,

42:15

potentially even the same address through

42:17

grade two counterfactual deployment, there's still

42:19

very much independent accounts which is

42:22

a difference towards EOAs, which

42:24

are by design, because it's

42:26

kind of standardized, especially in the VM

42:28

ecosystem, like you have a seed phrase

42:31

and it's immediately an account

42:33

on all the VM networks. So that's

42:35

going to change, the task to change.

42:38

And there are solutions that

42:40

are being worked on in terms of like key

42:42

stores that are accessible cross-chain

42:45

and ways to sync

42:47

the state across the chainsable.

42:49

Eventually solved that, there was just recently

42:52

like a spec on that from Michael

42:54

from base that goes into that.

42:56

That's one thing and then the other challenge

42:58

will be that in smart accounts, they are

43:01

very much dependent on the

43:03

virtual machine. So you can have

43:05

a smart contract that creates

43:08

your account, but obviously

43:10

that's very much dependent on

43:12

what smart contract language

43:14

use for implementation and all the

43:16

security assumptions are dependent

43:18

on the virtual machine behind it.

43:21

So it's possible to create a

43:23

similar smart account and across non-EDM

43:26

chains like the Solana or

43:29

else, but this will necessarily

43:31

you remove certain technical assumptions

43:34

that you can take certain security assumptions and

43:36

you will have to build

43:38

up the trust into this smart

43:40

account from scratch. So there's similar

43:43

solutions to save on say Solana that's

43:45

like a squat that have been around

43:47

quite a while and that do similar

43:50

things and for safe the new

43:52

term midterm focus will still be EDM.

43:54

I think there's enough that can

43:57

be built there in terms of smart account adoption on

43:59

the EDM itself. It's a

44:01

huge ecosystem and it just

44:03

allows to move faster if you can

44:05

make the technical assumptions on the Fermi

44:07

virtual machine. But obviously in the long

44:09

run this should not be limited to

44:11

that and safe in

44:14

some way or another should be also

44:17

available outside of the VM itself

44:19

and whether that means integrating with

44:21

some of the other implementations such

44:23

as the squads on

44:26

other networks that's yet to be seen but

44:28

that's definitely in the long term say three to

44:30

five years something that needs to be done. Yeah,

44:34

I mean I would love

44:36

to see safe in other

44:39

ecosystems mostly because solutions I think

44:41

are lacking. Yeah, I think that in

44:44

the next one to two years

44:46

we'll see safe competitors emerge in

44:48

those ecosystems like native solutions emerge

44:51

in those ecosystems which will

44:54

have first mover advantage

44:56

and likely make it difficult for

44:58

safe to really gain a

45:01

foothold in those ecosystems maybe you know

45:03

with the exception of like existing customers

45:05

on the safe on the EVM side

45:07

that have assets there that want to

45:09

move those assets into other ecosystems. When

45:12

it comes to the EVM ecosystem

45:15

and the cross chain compatibility what's

45:18

the progress in terms of being

45:20

able to control cross chain accounts

45:23

from like a single account? So

45:25

for example, if you had

45:27

assets on or you

45:29

had like a safe account on Polygon and

45:32

wanted to control assets

45:35

on another account by signing something on

45:37

Polygon like is there any progress

45:40

in the direction of interchain accounts as

45:42

we call them in Cosmos. So these

45:45

are accounts that can be controlled externally

45:48

by an account on another chain. Is that

45:50

also something that can exist within the safe

45:52

ecosystem in the EVM world? Definitely.

45:56

So that's what I mentioned before on key

45:59

stores. So that's actually something

46:01

that was proposed by Vitalik Buterin last

46:03

year. And now some

46:06

teams are looking into the

46:08

idea is that you

46:10

should have the ability to have multiple Spark

46:12

accounts, but have

46:15

the core validation logic or

46:17

the logic what keys are associated with that

46:20

account separated into a separate contract, which is

46:22

a key store contract, which then allows you

46:24

to have less of that logic in the

46:27

account itself. And you just say from the

46:29

account, you then make a state proof towards

46:31

the key store, and

46:33

then it allows you to see

46:35

what's actually the account logic and

46:38

proof that against the transaction. And

46:41

that can then be taken cost chain

46:44

as well, actually via designated rollup. So

46:46

that could be like a key store

46:48

rollup that then contains the logic of

46:50

your account as you have your subaccounts,

46:53

so to say on different networks, could

46:56

be EBM, could be beyond EBM that just

46:58

allow you to use a cost chain state

47:00

proof against this key store rollup in order

47:03

to prove what keys

47:05

or what have validation logic

47:07

this is a contest. And

47:10

then this essentially means that you

47:12

will have cost chain smarter cons that

47:14

can then be allow you to think

47:17

to achieve things like complete network abstraction

47:19

where for user or developer, it doesn't

47:21

even matter where the transaction is starting

47:23

and where it's pointing at.

47:26

But this is then exactly the way by

47:28

having these cost chain smarter cons. I

47:30

would still say it's like maybe six to

47:32

12 months out until we

47:35

have first production ready implementations of

47:37

such key store rollup. But there's

47:39

like major teams working on that.

47:42

And I'm 100% sure that

47:44

we're going to that direction. And

47:47

it's going to be first maybe optimized

47:49

for certain sub ecosystem say the

47:51

optimistic ecosystem or the scroll ecosystem.

47:54

But over time, it will expand and

47:56

even go beyond the EBM where you

47:58

can have like you T-Store roll-up, which

48:00

is based in the film layer one, but

48:03

as a roll-up in order to optimize some

48:05

gas efficiency, but then allows you

48:07

to prove that verification

48:09

state towards any other network.

48:11

Very cool. Yeah,

48:14

I mean, I think that that's

48:16

a mostly untapped feature

48:20

in the VM world, this ability

48:22

to control accounts across

48:24

chain. Again, in Cosmos, we have standards for

48:26

this and exist, and we're able to do

48:28

this pretty easily, but in

48:31

the VM world, I think

48:33

it still needs a little

48:35

bit of time in order to become production ready. So

48:38

you guys recently announced this, I

48:40

think it was last year, this recovery hub.

48:42

So Safe added all these different

48:44

methods to do recovery, and

48:46

you have some partners

48:49

there that I guess can act as

48:52

third party signers in the event of lost

48:54

keys. What does this look like,

48:56

and what are the kind of trust assumptions

48:58

that users of Safe have to make in

49:01

order to be using this

49:03

recovery feature? Yeah,

49:06

so the idea behind recovery is that

49:08

you may have more user-friendly ways to

49:10

get keys into how to

49:12

handle users, be it like passkey signers

49:15

or be it social login

49:17

signers such as like login with Google or

49:19

something like that, but still you

49:21

want to have a worst case

49:23

scenario way to recover access

49:26

to your account. And that actually, at least

49:28

in my opinion, it's something that's very idiosyncratic

49:32

to the user itself. So there might

49:34

be different users that want to

49:36

have different ways to recover the account. So

49:40

trust their family and friends, they just want to have sort

49:43

of like a multi-seat controlled by their family and friends,

49:45

controlling their account. And if they

49:48

lose their own keys, they just

49:50

approach these social recovery signers and

49:52

ask them to initiate a recovery.

49:55

Others may trust an institution

49:57

such as a bank or... a

50:00

notary or something like that that can

50:02

execute the recovery in

50:04

certain cases, even in inheritance cases,

50:07

worst case. And

50:09

there's even for others

50:11

that may trust some

50:14

decentralized network of humanity

50:18

DAO kind of system

50:20

that then verifies the identity of

50:22

someone that then can be used

50:24

to recover the account through some

50:27

identity verification. And

50:30

how we're thinking then around

50:32

what we built in terms of the

50:34

foundations for enabling these use cases is

50:36

that we created this recovery hub, which

50:38

is very much a agnostic system

50:41

to add different recovery systems and

50:43

we're working together with partners in

50:46

order to showcase some of these

50:48

capabilities. So the very

50:51

base logic of the recovery hub is that

50:53

you can add a module, which is like

50:55

a separate smart contract, which has access to

50:57

your account as an admin key, but then

51:00

you add security guards that make sure that

51:02

this admin

51:04

key is somewhat

51:06

protected. And that

51:09

can be depending on what the user

51:11

prefers. It's usually like a time lock.

51:13

So that user can say this

51:16

separate contract can recover my account, but only

51:18

by having a time lock of like three

51:20

months. So I can have me super signed

51:22

the recovery and in that three months I

51:25

could cancel the recovery if

51:27

I have access to my keys. And

51:30

this then allows to have less trusted

51:32

system where am I may delegate this

51:34

admin key to my social recovery setup

51:36

or to this institution, but still have

51:38

to certainly that they cannot go

51:41

wrong and just run away with the

51:43

account. There's other ways to add security

51:46

such as Signum, which is

51:48

a Swiss license bank, which is building

51:50

a recovery system for the recovery hub.

51:52

What they're doing is that they limit

51:54

the capabilities of this recovery

51:56

module to only exchanging

51:59

certain signers in the con.

52:01

So the logic goes like this recovery

52:04

module can exchange signer A but not

52:06

signer B, C or D and

52:08

this can be then configured by the

52:11

user and they can say just this

52:13

one signer which I trust the Sycam

52:15

to recover I set

52:17

up and this then just limits

52:20

what Sycam can do with the con

52:22

and again with some time locks that

52:24

there's an additional protection through that but

52:26

essentially it's very open-ended what can be

52:29

done there and there can be amounts

52:31

of different ways that these recovery

52:33

setups are being created. And

52:36

are there any kind of best

52:39

practices like so if someone wanted to set

52:41

up a multi-sig

52:43

account or a smart

52:45

account and then have a recovery

52:47

I think one of the things that you internally

52:49

we spent a lot of time thinking about was

52:52

okay what is the key distribution

52:54

setup look like like who has

52:56

keys where are they where the

52:58

seats stored you know

53:01

what other third parties outside of our

53:03

organization might have access to these keys

53:06

for backup or recovery purposes

53:09

does safe make any recommendations or

53:11

best practices recommend best practices when

53:14

it comes to doing this

53:16

kind of smart accounts

53:18

set up within an organization. We

53:22

usually recommend to use a threshold of more

53:24

than one that's obvious you want to have

53:26

multi-signature not just a one out

53:28

of five where every one of the members of

53:30

the organization can do whatever they want so

53:33

there's at least multiple people looking over

53:35

a transaction and then we also recommend to

53:37

not use a threshold that's

53:39

equal to the number of

53:41

signers so not to any five out of

53:44

five schemes because that will mean that only

53:46

one key needs to be lost and the

53:48

account is not

53:50

usable anymore in case

53:52

you don't have recovery so that's always dependent

53:54

on also what recovery setup use obviously

53:57

if you have a very trusted recovery

53:59

setup up, then it might make sense

54:01

to have like a five out of five if

54:03

you have this emergency way to

54:06

recover the con, but without that,

54:09

at least like a three out of five, that's

54:11

enough for having multiple people

54:13

cosine, but that also allows for some

54:16

people to not be available at certain

54:18

times, or also certain keys to be

54:21

lost in order to create

54:23

key rotations afterwards. But

54:25

that's just very basic recommendations I would

54:27

do. In general, it is very much

54:29

depends on the specific use cases and

54:31

like how many people are involved, like

54:33

what's the transfer sources between these people

54:35

and so on. Yeah,

54:37

that's true. Yeah. And there's also kind of

54:39

catastrophic. You know, we thought a lot about

54:41

this, this kind of specific scenario

54:44

where since the team often

54:46

travels together, if there

54:48

was a catastrophic scenario where we were

54:50

to all perish, how would, you know,

54:52

heirs or other stakeholders be able to

54:55

recover keys in that event? And

54:57

so we had to think about safeguards

54:59

there as well. But

55:01

yeah, it's I think for a lot

55:04

of teams that have set up multisigs

55:06

and that are managing the significant amounts

55:08

of capital on these

55:10

accounts, they've probably gone through

55:12

similar reflections and thinking

55:15

about the best scenario. I don't

55:18

think there's a one size fits all

55:21

solution for everyone, but certainly like,

55:24

you know, some best practices here, I think generally

55:26

would be would be useful. I don't know if

55:28

anyone's thinking about these things or publishing anything about

55:30

this, but I hadn't found anything like

55:33

those very useful

55:35

for our use case. I

55:37

wanted to also talk a little bit

55:39

about security at SAFE. So

55:41

you guys recently passed $100 billion

55:43

in assets secured by

55:46

the protocol, I guess that's cross

55:49

ecosystem or cross cross EBM

55:52

chains. That's a lot of responsibility

55:54

on on the SAFE team. And

55:57

I would argue that if something

56:00

where to happen if there was a bug in the

56:02

safe smart contract that not only

56:04

the multi-sig holders

56:06

would suffer, but I think the entire ecosystem

56:08

would probably suffer quite a bit. Yeah,

56:11

what does that evoke for you? And what

56:13

does the process look like, the process of

56:16

making sure these smart contracts are

56:18

absolutely bulletproof? I

56:20

must say I was more

56:22

worried in the early years of safe than I

56:24

am now, because the

56:27

vast amount of the security comes

56:29

through its linear effect, so just

56:31

having a lot of value controlled

56:33

through the smart accounts over time

56:35

without there being any issues,

56:37

and especially with the

56:40

safe smart accounts, we

56:42

don't update them that often intentionally, because

56:44

every time you make a change to

56:47

the smart contract, that means that there

56:49

could be potentially any risk

56:51

associated with that. So we are

56:54

not adding new features

56:57

just to the base contract, but we allow

56:59

this with modules and then there's a different

57:02

kind of security assumption that's

57:04

behind there. But generally, also

57:06

because it's not just a hundred billion dollars

57:09

worth of assets that are secured, but

57:11

also critical infrastructure,

57:14

be it like cross-chain bridges, be

57:16

it restaking protocols, be it stable

57:19

coins that use

57:21

safe smart accounts under the hood

57:23

in order to control certain upgrade

57:26

parameters and so on. It

57:29

is quite critical that the safe

57:31

smart account is really bulletproof. And

57:33

for that, we invest a lot

57:35

into security. We

57:37

actually invested a lot of

57:39

us into formal verification. The very first

57:42

major version of the safe smart account was

57:44

formally verified over a period of six months

57:47

of quite some time

57:49

and financial investments that went into that. Obviously,

57:52

multiple audits are always part of

57:54

that, having a back bounty and

57:56

community back bounty challenge that is

57:59

associated with that. with that. And like

58:01

a big part of the security is also just on like

58:03

in internal processes and

58:06

how the culture is around security in

58:09

the team and so on. But yeah,

58:11

the key part is still like the

58:13

the Lindy effect. And that's something where

58:15

I would argue at this

58:17

point with that much at stake, if there

58:20

would be any major issue with the safe

58:22

smart account, no one could tell. But like, I

58:25

would assume this would almost be a reason to

58:27

to initiate a hard fork. And for

58:30

me, this is also a signal that if

58:32

people assume this would happen, at some point,

58:34

it would make sense to even make certain

58:36

components of the safe smart account to be

58:38

part of the theorem protocol.

58:40

So really enshrined that and make make

58:42

it very explicit and say, like,

58:44

this is logic that we expect to to

58:47

behave a certain way. And if it

58:49

if it's not that case, then they

58:51

would be a consensus consensus

58:53

issue and they kind of would lead

58:56

automatically to fix

58:58

that or they would be looking for a buck

59:01

in a client or something rather than a buck

59:03

in the smart contract. And I would assume that

59:05

eventually we will have to move towards that. If

59:07

we see that certain parts of the

59:09

safe smart contracts are really justified,

59:11

we don't expect them to to change

59:13

much in the future, we should just

59:16

make them part of the protocol.

59:19

Yeah, no, I agree that. I

59:21

think that would also solve a lot of the user

59:24

experience issues and and also

59:26

the, you know, so the

59:28

gas issues surrounding using

59:30

safe obviously, like on the theory of mainnet,

59:32

like using safe can be quite expensive and

59:34

having that in trying the protocol, I think

59:36

would make sense long term. And also in

59:39

terms of just adding new features and having

59:41

smart contracts being able to leverage safe. I

59:43

think there's like a huge benefit of saying

59:45

like, okay, this infrastructure should be enshrined. So

59:48

that most most newer accounts are any smart

59:50

accounts, right? And let's

59:53

take a step back here and talk a little

59:55

bit about the notice ecosystem generally. So obviously, like

59:58

safe is a huge part of that. There's

1:00:00

also a Gnosis chain, there's Gnosis Pay,

1:00:03

and you guys have a lot of

1:00:05

other products and teams working on all

1:00:07

sorts of infrastructure. How does SAFE

1:00:09

fit in with all this? And

1:00:12

what's the long-term vision for,

1:00:14

I don't know if you can talk

1:00:16

about like Gnosis generally, but

1:00:18

yeah, the Gnosis ecosystem. I

1:00:21

mentioned it at the beginning, Gnosis originally wanted to

1:00:23

do prediction markets. It was quite

1:00:26

early. It was pre-T5 summer.

1:00:28

But there was a lot of

1:00:30

infrastructure missing in order to even make

1:00:32

prediction markets work. So there was

1:00:34

no secure way to self-custody assets, which

1:00:36

prediction markets would create a lot of

1:00:38

assets, which need to be self-custody. There

1:00:42

was not a good way to

1:00:44

exchange assets, because the prediction

1:00:46

markets would create different tokens that need to

1:00:48

be exchanged in a capital efficient way. And

1:00:51

there's like a bunch of different things that

1:00:53

were missing. And Gnosis was

1:00:56

basically forced to build

1:00:58

these things out themselves. And

1:01:01

that's how, in the end,

1:01:03

SAFE was created. That's also how Cowswap

1:01:05

was created over the

1:01:08

years and other things. Also

1:01:10

Gnosis became a

1:01:12

DAO as Gnosis DAO. So

1:01:14

suddenly there was infrastructure needed

1:01:16

to really enable community governance

1:01:19

over Gnosis DAO. So that's where

1:01:21

SAFE Snap was created, a

1:01:23

way to connect a safe smart account

1:01:25

with snapshot space in

1:01:27

order to have off-chain voting but have

1:01:29

on-chain execution. And that's then

1:01:32

how the Gnosis Guild team was born as

1:01:35

a team that's

1:01:37

optimizing on building DAO

1:01:39

infrastructure. Then Gnosis DAO

1:01:41

had the treasury, which had to be managed. And

1:01:44

that's where the Karpatky team

1:01:46

was born, which is now, I

1:01:48

think, the biggest asset manager for

1:01:50

DAO treasuries. And they

1:01:53

managed DAO treasuries like the ones from

1:01:55

Aveda or ENF. All

1:01:57

these were initially internal teams, but at some point,

1:01:59

we had to do that. became spin-offs.

1:02:02

But obviously it's very much still a

1:02:04

closed ecosystem, so the different

1:02:07

teams collaborate quite extensively. And

1:02:09

now, like the future for Gnosis

1:02:12

is very much centered around Gnosis Chain,

1:02:15

which is another project that was actually

1:02:17

picked up as Ix-Dye in the past,

1:02:19

which then was rebranded to Gnosis Chain.

1:02:23

It's a side chain to Ethereum and allows for

1:02:26

horizontal scaling of Ethereum

1:02:28

block space. And on

1:02:30

Gnosis Chain, there's the payments

1:02:33

network Gnosis Paint being built

1:02:35

out, which is really the

1:02:37

second focus next to into

1:02:39

Gnosis Chain itself, which

1:02:41

is a way to connect DeFi

1:02:44

with the traditional financial system,

1:02:48

meaning that the idea is

1:02:50

that you are able to

1:02:52

really have the assets on-chain, but

1:02:54

able to spend them off-chain and

1:02:57

trigger bank transfers off-chain, but then

1:02:59

result into on-chain transactions and really

1:03:02

bridge the gaps between those two

1:03:04

ecosystems as a first step

1:03:06

to hopefully then have more and more of the

1:03:09

payment ecosystem actually move on-chain and

1:03:11

not be rooted still

1:03:13

in the traditional financial systems, but

1:03:15

then get replaced over

1:03:18

time with really true on-chain systems. So

1:03:20

there also safe plays a very critical

1:03:22

role in Gnosis Paint, as

1:03:25

it's the underlying account

1:03:27

standard for Gnosis Paint, because something

1:03:29

like Gnosis Paint actually needs smart

1:03:31

accounts in order to work, because

1:03:34

it is meant to be like a

1:03:36

self-custodial account, which then allows it

1:03:39

to have a

1:03:42

traditional Visa card associated with

1:03:44

it, which you can use to spend off-chain.

1:03:46

And in order to bridge these assets off-chain,

1:03:48

you need to have a way

1:03:50

that they can be taken from the

1:03:52

account and then put into the Visa

1:03:54

network, but still you don't want to just

1:03:57

give unlimited access. of

1:04:00

the fee of assets to some to the notice pay

1:04:02

network there. But they actually want to

1:04:04

limit that and that's that requires smart account so

1:04:06

that every notice card

1:04:08

actually is associated with the

1:04:11

same smart account, which has

1:04:13

like a data limit

1:04:15

associated with that, where any

1:04:17

transactions that are below this daily limit

1:04:19

can be put into the notice pay

1:04:21

network and be used to pay at

1:04:23

the merchant store. But it's it's

1:04:26

in a way that it's still the

1:04:30

vast majority of your assets are self

1:04:32

custodial. And it just, you

1:04:34

have to stay in the mid that you get

1:04:36

and give. And yet the

1:04:39

long term vision is really that no,

1:04:41

this is focusing on building out like

1:04:43

this decentralized payment network that

1:04:46

then leverages things like safe

1:04:48

leverages things like housework for

1:04:51

for exchange of assets and other parts

1:04:53

of the no seeker system that becomes

1:04:55

really this combination of the

1:04:58

different infrastructure that was built over the

1:05:00

last years and builds really something that

1:05:02

can then bring as much as possible

1:05:05

of today's payments, volume

1:05:07

on train. Great.

1:05:09

Well, Lucas, thanks so much for coming on the

1:05:11

podcast today has been great learning about

1:05:14

safe understanding the

1:05:16

the technical implementation

1:05:18

of safe and also how

1:05:20

it fits into the broader

1:05:22

no system. So thanks so much

1:05:24

for coming on and look forward to having you back on

1:05:26

the future. Yeah, it was a

1:05:28

pleasure. Thank

1:05:31

you for joining us on this week's episode. We

1:05:33

release new episodes every week. You

1:05:36

can find and subscribe to the show

1:05:38

on iTunes, Spotify, YouTube, SoundCloud, or wherever

1:05:40

you listen to podcasts. And if

1:05:42

you have a Google Home or Alexa device, you can tell

1:05:44

it to listen to the latest episode of the epicenter podcast.

1:05:47

Go to epicenter.tv slash subscribe for a full list

1:05:49

of places where you can watch and listen. While

1:05:52

you're there, be sure to sign up for the newsletter.

1:05:54

You get new episodes in your inbox as the release.

1:06:00

You can follow us on and please leave

1:06:03

a review on. I can help you find

1:06:05

the shots and we're always happy to meet

1:06:07

the definition and will upload. Be back next.