1 00:00:00,480 --> 00:00:03,560 Tiny ecosystem at that point all the projects doing their own 2 00:00:03,560 --> 00:00:08,360 Icos doing the 2017 phase started adopting this multi 3 00:00:08,360 --> 00:00:11,240 signature wallet as well. In the long run these smart 4 00:00:11,240 --> 00:00:14,880 accounts will be the solution and there's no way around smart 5 00:00:14,880 --> 00:00:18,160 accounts in order to get to the user experience while still 6 00:00:18,160 --> 00:00:22,480 retaining like security that is needed to to onboard like a 7 00:00:22,600 --> 00:00:26,280 billion people to to or three. I would say when it comes to 8 00:00:26,280 --> 00:00:30,120 cross train, smart accounts in the short term will bring new 9 00:00:30,120 --> 00:00:33,240 challenges in in the long run will actually solve. 10 00:00:33,440 --> 00:00:38,240 Frustrating in a way that it can make it irrelevant in what 11 00:00:38,440 --> 00:00:41,720 networks you interact with what tabs, but this can be abstracted 12 00:00:41,720 --> 00:00:57,200 away. This episode is brought to you 13 00:00:57,200 --> 00:00:59,880 by Gnosis. Gnosis builds decentralized 14 00:00:59,880 --> 00:01:03,880 infrastructure for the Ethereum ecosystem with a rich history 15 00:01:03,880 --> 00:01:08,760 dating back to 2015 and products like Safe Cow Swap or Gnosis 16 00:01:08,760 --> 00:01:13,240 Chain, Gnosis combines needs driven development with deep 17 00:01:13,440 --> 00:01:17,240 technical expertise. This year marks the launch of 18 00:01:17,240 --> 00:01:20,600 Gnosis Pay, the world's first decentralized payment network. 19 00:01:21,320 --> 00:01:25,840 With a Gnosis card you can spend self custody crypto at any Visa 20 00:01:25,840 --> 00:01:27,760 accepting merchant around the world. 21 00:01:28,440 --> 00:01:31,840 If you're an individual looking to live more on chain or 22 00:01:31,840 --> 00:01:35,960 business looking to white label the stack, visit gnosispay.com. 23 00:01:36,840 --> 00:01:39,840 There are lots of ways you can join the Gnosis journey. 24 00:01:40,280 --> 00:01:43,920 Drop in the Gnosis Dow Governance form, become a Gnosis 25 00:01:43,920 --> 00:01:48,160 validator with a single GNO token and low cost hardware, or 26 00:01:48,160 --> 00:01:51,600 deploy your product on the EVM compatible and highly 27 00:01:51,600 --> 00:01:56,320 decentralized Gnosis chain. Get started today at Gnosis dot 28 00:01:56,320 --> 00:02:01,440 IO Chorus One is one of the biggest node operators globally 29 00:02:01,440 --> 00:02:04,880 and help you stake your tokens on 45 plus networks like 30 00:02:04,920 --> 00:02:08,120 Etherium, Cosmos, Celestia and DYDX. 31 00:02:09,039 --> 00:02:12,520 More than 100,000 delegators stake with Chorus One, including 32 00:02:12,520 --> 00:02:14,960 institutions like Bit Go and Ledger. 33 00:02:15,440 --> 00:02:19,480 Sticking with Chorus 1 not only gets you the highest years, but 34 00:02:19,480 --> 00:02:23,400 also the most robust security practices and infrastructure 35 00:02:23,640 --> 00:02:25,920 that are usually exclusive for institutions. 36 00:02:26,800 --> 00:02:29,760 You can stake directly to Chorus One's public note from your 37 00:02:29,760 --> 00:02:32,920 wallet, set up a white table note, or use the recently 38 00:02:32,920 --> 00:02:37,680 launched product Opus to stake up to 8000 ETH in a single 39 00:02:37,680 --> 00:02:40,760 transaction. You can even offer high yield 40 00:02:40,760 --> 00:02:44,120 staking to your own customers using their API. 41 00:02:44,440 --> 00:02:47,240 Your assets always remain in your custody so you can have 42 00:02:47,240 --> 00:02:50,240 complete Peace of Mind. Start staking today at. 43 00:02:50,240 --> 00:02:54,240 Chorus .1. Welcome to Epicenter, the show 44 00:02:54,240 --> 00:02:56,000 which talks about the technologies, projects and 45 00:02:56,000 --> 00:02:58,960 people driving decentralization in the blockchain revolution. 46 00:02:58,960 --> 00:03:02,240 I'm Sebastian Krutio and today I'm all by myself. 47 00:03:02,240 --> 00:03:05,720 I'm chatting with Lucas Shore, who's the Co founder at SAFE. 48 00:03:05,880 --> 00:03:11,120 Safe is of course the leading smart account, multi sig 49 00:03:11,120 --> 00:03:15,240 provider in the EVM ecosystem. They're securing over $100 50 00:03:15,240 --> 00:03:19,200 billion in assets and are absolutely crushing it when it 51 00:03:19,200 --> 00:03:23,640 comes to securing assets. We use SAFE at Interop Ventures 52 00:03:23,640 --> 00:03:26,080 and I'm sure lots of you out there are also using SAFE. 53 00:03:26,920 --> 00:03:29,600 They were spun out of Gnosis a couple years ago. 54 00:03:29,600 --> 00:03:34,080 And I'm going to be talking with Lucas today about the technology 55 00:03:34,080 --> 00:03:37,600 behind SAFE, but also the strategy moving forward and what 56 00:03:37,600 --> 00:03:41,200 is the future of SAFE look like? Hey, Lucas, thanks for joining 57 00:03:41,200 --> 00:03:43,600 us today. Thanks for having me semester. 58 00:03:45,240 --> 00:03:49,240 So before we get started, how did you become part of the Safe 59 00:03:49,240 --> 00:03:51,800 team? Were you previously at Nosis or? 60 00:03:52,320 --> 00:03:54,520 Yeah, because I think you're like a one of the Co founders of 61 00:03:54,520 --> 00:03:56,000 Safe. What's the story there? 62 00:03:56,760 --> 00:04:00,080 Yeah, that's right. So safe is the spin off from 63 00:04:00,080 --> 00:04:04,040 from Nosis. I joined back in 2019 as a 64 00:04:04,040 --> 00:04:08,320 product manager responsible for the that Point Nosis safe 65 00:04:08,320 --> 00:04:12,040 project within Nosis. Actually I was applying half a 66 00:04:12,040 --> 00:04:15,120 year before that to Nosis in the in the marketing department. 67 00:04:15,120 --> 00:04:18,560 I got rejected right away. That's just a fun fact on the 68 00:04:18,560 --> 00:04:21,040 side. Then half a year later something 69 00:04:21,040 --> 00:04:24,080 that was more relevant to my my background, the product manager 70 00:04:24,080 --> 00:04:28,120 role opened up and I was jumping on that and that was luckily 71 00:04:28,560 --> 00:04:31,480 successful. So I joined when the Nosy Safe 72 00:04:31,480 --> 00:04:33,640 project was quite a bit early stages. 73 00:04:33,960 --> 00:04:36,760 Yeah. Then took over together with 74 00:04:36,840 --> 00:04:41,320 Richard and Tobias, my Co founders the the project 75 00:04:41,320 --> 00:04:46,000 responsibilities and over time then the the project group and 76 00:04:46,040 --> 00:04:51,600 it outgrew to some extent noses as in the kind of the team size 77 00:04:51,600 --> 00:04:56,640 crew and the the the focus have expanded beyond what it's 78 00:04:56,680 --> 00:04:59,680 originally meant to be and it became its own ecosystem. 79 00:04:59,680 --> 00:05:02,760 And that's when we decided together with the Nosys team 80 00:05:02,760 --> 00:05:05,880 that it's better off to continue the project outside. 81 00:05:06,400 --> 00:05:10,600 Yeah, maybe a little bit of the history of how this project came 82 00:05:10,760 --> 00:05:15,800 to begin with. So Nosys like back in 2016 was 83 00:05:15,840 --> 00:05:18,120 was started to create prediction markets. 84 00:05:18,400 --> 00:05:23,680 So that's a way to financially incentivize participants to 85 00:05:23,720 --> 00:05:26,680 share their knowledge in order to, yeah, expose that knowledge 86 00:05:27,080 --> 00:05:30,280 to the public. And that's meant to be as a as a 87 00:05:30,280 --> 00:05:31,920 primitive on the film blockchain. 88 00:05:32,280 --> 00:05:36,600 And Nosys went ahead and did Nico in order to fund the 89 00:05:36,600 --> 00:05:41,600 project and it happened that the ICO was quite successful. 90 00:05:42,160 --> 00:05:47,520 Nosys had to custody a lot of the proceedings from from that 91 00:05:47,520 --> 00:05:52,440 ICO and back then the entire self custody infrastructure was 92 00:05:52,440 --> 00:05:56,840 quite early on, meaning that they had to create their own 93 00:05:56,840 --> 00:05:59,500 solution. So Stefan Giorgi who's the Co 94 00:05:59,500 --> 00:06:04,000 founder of Gnosis wrote himself a multi signature contract which 95 00:06:04,000 --> 00:06:08,400 is a way to share the responsibility of a self custody 96 00:06:08,400 --> 00:06:13,720 set up with other people via multiple keys and that was used 97 00:06:13,720 --> 00:06:18,280 for for the ICO funding and was open sourced. 98 00:06:18,560 --> 00:06:21,800 And then it happened that all have the entire ecosystem at 99 00:06:21,800 --> 00:06:24,640 that point all the projects doing their own IC OS doing the 100 00:06:24,640 --> 00:06:29,800 2017 phase started adopting this multi signature wallet as well. 101 00:06:30,560 --> 00:06:34,280 And that's how the team was formed as suddenly had many 102 00:06:34,520 --> 00:06:38,720 projects that were using this solution and there were feature 103 00:06:38,720 --> 00:06:42,440 requests coming in and people wanted to have the project 104 00:06:42,440 --> 00:06:44,560 maintained. And so the the project formed, 105 00:06:44,560 --> 00:06:48,720 it became its own team within Nosis and that's roughly when 106 00:06:48,720 --> 00:06:51,200 when I joined. Yeah, cool. 107 00:06:51,200 --> 00:06:53,520 I mean I think it bears reminding also that like you 108 00:06:53,520 --> 00:06:58,000 know back then like you said there were no good solutions for 109 00:06:58,000 --> 00:07:01,720 doing multi stakeholder asset custody. 110 00:07:02,000 --> 00:07:07,560 Bitcoin had an on chain in protocol solution still has and 111 00:07:07,560 --> 00:07:11,560 you know in Bitcoin you can create an on chain multi sig and 112 00:07:11,560 --> 00:07:14,120 you know this is something that a lot of people like including 113 00:07:14,120 --> 00:07:17,440 myself have used you know with Epicenter we've used this also 114 00:07:17,440 --> 00:07:20,440 quite a bit in the early days when we were a a Bitcoin only 115 00:07:20,440 --> 00:07:23,880 company and but yeah the even even then like it's quite 116 00:07:23,880 --> 00:07:27,560 cumbersome to set up the keys and and everything but Etherium 117 00:07:27,560 --> 00:07:30,720 didn't have an on protocol solution. 118 00:07:31,120 --> 00:07:36,000 Do you know why that is? Like why Etherium didn't go down 119 00:07:36,000 --> 00:07:40,320 the same path as Bitcoin and built build an in protocol way 120 00:07:40,320 --> 00:07:42,480 to do multi stakeholder asset custody? 121 00:07:43,640 --> 00:07:47,080 Yeah, I mean it's always the question what should be really 122 00:07:47,080 --> 00:07:49,560 enshrined as part of the protocol and what should be then 123 00:07:49,760 --> 00:07:52,000 solve the layer above from the smart contract level. 124 00:07:53,120 --> 00:07:55,440 It actually happened that Etherium originally wants to 125 00:07:55,440 --> 00:07:58,640 have smart accounts. So accounts that's based on 126 00:07:58,640 --> 00:08:03,760 logic on smart contracts have have this natively within the 127 00:08:03,760 --> 00:08:09,120 theorem it was then yeah it turned out that this is quite 128 00:08:09,120 --> 00:08:14,040 complex to do and the team at the Etherium Foundation was a 129 00:08:14,040 --> 00:08:19,000 bit of an in a in a time rush to to launch mainnet so that this 130 00:08:19,000 --> 00:08:24,760 scope did last minute. And we since then had our have 131 00:08:24,760 --> 00:08:28,040 all the infrastructure on Etherium mostly based on EO as 132 00:08:28,120 --> 00:08:31,240 so externally owned accounts. These are the the accounts 133 00:08:31,240 --> 00:08:34,000 everyone knows that are controlled by a single private 134 00:08:34,000 --> 00:08:41,159 key usually derived from from a seat phrase, 12424 word, secret 135 00:08:41,159 --> 00:08:44,520 phrase and that's where the the world infrastructure was was 136 00:08:44,520 --> 00:08:47,320 built upon. I personally think that it's a 137 00:08:47,320 --> 00:08:50,800 better pathway to solve as much as possible on on the smart 138 00:08:50,800 --> 00:08:54,160 contract level there in terms of like logic of of an account. 139 00:08:54,160 --> 00:08:57,840 Because if you look at what you mentioned the the Bitcoin multi 140 00:08:57,840 --> 00:09:03,040 SEC implementation, it it it works quite nicely for certain 141 00:09:03,040 --> 00:09:05,360 use cases. But it's quite limited because 142 00:09:05,360 --> 00:09:09,080 you have all the logic enshrined in the in the Bitcoin protocol. 143 00:09:09,440 --> 00:09:13,520 And for example that means that certain use cases such as 144 00:09:13,520 --> 00:09:17,080 rotating keys is not possible with the Bitcoin multi sig. 145 00:09:17,400 --> 00:09:20,600 So you once can set up your multi signature wallet. 146 00:09:20,600 --> 00:09:24,560 You might have a certain threshold of signatures required 147 00:09:24,560 --> 00:09:29,080 to make transactions, but then if you lose access to to one of 148 00:09:29,080 --> 00:09:32,640 the keys or it gets compromised you actually have to move your 149 00:09:32,640 --> 00:09:34,760 funds to complete the new Bitcoin multi sig. 150 00:09:35,400 --> 00:09:40,040 And you cannot just rotate one key and and continue with with 151 00:09:40,080 --> 00:09:43,160 the same wallet. These things are are solved by 152 00:09:43,800 --> 00:09:46,800 just leaving the logic up to the smart contract level and 153 00:09:47,160 --> 00:09:49,680 allowing different implementations to take 154 00:09:49,680 --> 00:09:54,400 different optimizations and different yeah, technical 155 00:09:54,400 --> 00:09:56,760 assumptions. And this creates much more 156 00:09:56,760 --> 00:09:59,320 flexibility. Then and over time we will 157 00:09:59,320 --> 00:10:03,960 probably see certain standards or certain best practices emerge 158 00:10:03,960 --> 00:10:07,920 and potentially at some point these can be trained again in if 159 00:10:07,920 --> 00:10:10,680 you're in protocol. Once once we see that these are 160 00:10:10,680 --> 00:10:15,720 actually must have and have, the standardization value is higher 161 00:10:15,720 --> 00:10:19,360 than the flexibility of having different implementations. 162 00:10:21,120 --> 00:10:25,760 Yeah, I think the Entrime in question is one that needs a lot 163 00:10:25,760 --> 00:10:30,040 of of course, reflection, and we need to be careful what we 164 00:10:30,040 --> 00:10:32,160 enshrine into the protocol or not. 165 00:10:32,680 --> 00:10:36,040 But yeah, taking a step back from that, let's maybe dive into 166 00:10:36,800 --> 00:10:41,840 smart accounts or at least the way smart accounts are conceived 167 00:10:41,840 --> 00:10:46,400 of in the Etherium space. I think most of the research is 168 00:10:46,400 --> 00:10:52,480 around this ERC 4337. Yeah, Give us an overview of 169 00:10:52,520 --> 00:10:58,320 what is ERC 4337 and how it aims to implement smart accounts on 170 00:10:58,320 --> 00:11:01,800 EVM chains. Yeah, there's actually quite 171 00:11:01,800 --> 00:11:05,680 some misconceptions still on what the ERC 457 is. 172 00:11:05,960 --> 00:11:11,040 So some people think that ERC 457 is smart accounts and all 173 00:11:11,040 --> 00:11:14,360 the logic, all the possibilities that are enabled through this 174 00:11:14,360 --> 00:11:19,280 standard have is is due to the to the ERC 457 standard. 175 00:11:19,480 --> 00:11:23,880 While most of the features such as recovery or like session keys 176 00:11:23,880 --> 00:11:26,840 and so on are actually the the responsibilities of the smart 177 00:11:26,840 --> 00:11:29,520 accounts. So smart accounts have existed 178 00:11:29,520 --> 00:11:32,720 since since years. We have SAFE has been around 179 00:11:32,720 --> 00:11:37,880 since 5-6 years and a lot of what we're now talking when we 180 00:11:38,000 --> 00:11:43,120 talk about the potential of 457 has been possible before with 181 00:11:43,160 --> 00:11:46,920 one exception, which is actually processing smart account 182 00:11:46,920 --> 00:11:50,800 transactions in a trustless way. That's a big problem that's 183 00:11:50,800 --> 00:11:56,120 solved by ERC 457. So as I mentioned the if you're 184 00:11:56,120 --> 00:12:00,080 in protocol like it, it has two types of accounts, it's EOA 185 00:12:00,280 --> 00:12:03,640 Externally Owned Account and Smart Contacts which can then be 186 00:12:03,640 --> 00:12:08,440 used to make smart accounts. And yet a transaction actually 187 00:12:08,440 --> 00:12:11,680 in order to be processed needs to originate from an EOA. 188 00:12:12,120 --> 00:12:16,400 And that's that's a challenge because you have certain use 189 00:12:16,400 --> 00:12:19,080 cases of smart accounts. You actually might not even want 190 00:12:19,080 --> 00:12:23,720 to have an EOA involved if you use certain like new signature 191 00:12:23,720 --> 00:12:28,960 schemes, passkeys or so on where where there's no EOA part of the 192 00:12:28,960 --> 00:12:33,880 transaction life cycle. Yeah, but so far how it worked 193 00:12:33,880 --> 00:12:38,840 is that you had to fulfil the transaction verification 194 00:12:38,840 --> 00:12:41,800 requirements, be it in a multi CIC case that you collect the 195 00:12:41,800 --> 00:12:43,680 different signatures from the participants. 196 00:12:44,240 --> 00:12:46,920 But then still you need to have an EOA involved in in the 197 00:12:46,920 --> 00:12:51,200 transaction in order to actually process that transaction on the 198 00:12:51,200 --> 00:12:54,360 FION blockchain should. So usually how that worked is 199 00:12:54,360 --> 00:12:56,960 that you had like everyone signed the transaction and then 200 00:12:57,160 --> 00:13:00,880 the last person that was signing was, was the poor person that 201 00:13:00,880 --> 00:13:04,160 actually had to pay for the transaction fee from his EOA 202 00:13:04,160 --> 00:13:07,720 account. And yeah, that's now now coming 203 00:13:07,720 --> 00:13:11,240 to ERC 457. So just just one one, just the 204 00:13:11,280 --> 00:13:14,080 kind of put a pin in that essentially what you're saying 205 00:13:14,080 --> 00:13:20,320 here is that a a smart account like SAFE can can have multiple 206 00:13:20,320 --> 00:13:24,680 types of signers verifying and executing sort of signing for 207 00:13:24,680 --> 00:13:27,000 the for the transaction. But at the end of the day at the 208 00:13:27,000 --> 00:13:30,720 end of the transaction an EOA needs to execute that 209 00:13:30,720 --> 00:13:33,160 transaction on chain and pay the gas fee. 210 00:13:33,560 --> 00:13:35,880 So like we encounter this basically every time we do a 211 00:13:36,000 --> 00:13:39,920 safe transaction. You know all of us sign and then 212 00:13:39,920 --> 00:13:43,000 we have like one account that has just like a bunch of ETH on 213 00:13:43,000 --> 00:13:44,720 it and it's just used to pay for gas. 214 00:13:45,160 --> 00:13:47,720 And you know that account basically executes the 215 00:13:47,720 --> 00:13:49,760 transaction and sends it on chain and that has to be an EO 216 00:13:49,760 --> 00:13:52,040 account. It can't be some other sort of 217 00:13:52,040 --> 00:13:54,120 signer or even another smart account. 218 00:13:54,120 --> 00:13:55,280 It has to be an on chain account. 219 00:13:55,880 --> 00:14:00,240 Exactly, at least so far. And it doesn't even need to be 220 00:14:00,240 --> 00:14:03,920 an EOA that the user controls. So even in the past there were 221 00:14:04,440 --> 00:14:09,760 relayer systems like a bichonomy or Gelato or private relayers 222 00:14:09,960 --> 00:14:13,840 that are just Eoas that are funded that then are instructed 223 00:14:13,840 --> 00:14:16,360 that once there's a smart account transaction that's like 224 00:14:16,360 --> 00:14:21,120 fully verified and fully signed that then this relayer system 225 00:14:21,120 --> 00:14:24,520 would would take with the EOA and and pay for the gas fees and 226 00:14:24,520 --> 00:14:28,920 put on chain. And that's where then ERC 457 227 00:14:28,920 --> 00:14:33,360 comes in where we say that the idea should be that we have sort 228 00:14:33,360 --> 00:14:36,360 of like a separate man pool for the smart account transactions 229 00:14:36,800 --> 00:14:40,160 where we can just add the smarter account transactions 230 00:14:40,200 --> 00:14:42,800 that are fully assigned, fully valid. 231 00:14:43,040 --> 00:14:46,880 And then we have a decentralized mechanism how these transactions 232 00:14:46,880 --> 00:14:49,840 are then put on chain. There's actually still in EOA 233 00:14:49,840 --> 00:14:52,240 involved. So that's the EOA that the 234 00:14:52,240 --> 00:14:56,360 bundler in the in in the standard controls the bundlers 235 00:14:56,360 --> 00:14:58,880 are just of collecting all the different smart account 236 00:14:58,880 --> 00:15:02,280 transactions and are then bundling them together and and 237 00:15:02,280 --> 00:15:06,200 put them on chain by paying for the gas fees and using the the 238 00:15:06,200 --> 00:15:10,240 EOA. And they can then get repaid for 239 00:15:10,240 --> 00:15:13,080 this gas fee expenses by paymaster which is not a 240 00:15:13,080 --> 00:15:17,600 component of this standard which then allows that the the bundler 241 00:15:17,720 --> 00:15:21,680 isn't sitting on the cost but actually get out net zero or 242 00:15:21,680 --> 00:15:26,680 ideally with with some profit. And exactly the the standard now 243 00:15:27,480 --> 00:15:31,280 allows that there's no centralized relayer involved 244 00:15:31,280 --> 00:15:33,160 anymore. Users don't need to fund their 245 00:15:33,160 --> 00:15:36,280 own EO AS, but they just trust that there's this decentralized 246 00:15:36,280 --> 00:15:39,920 networks of bundlers that they can just throw in the 247 00:15:39,920 --> 00:15:42,920 transaction and it gets executed in a trustless way. 248 00:15:44,160 --> 00:15:50,520 OK, so just to recap here. So ERC 4337 uses existing smart 249 00:15:50,520 --> 00:15:54,800 account or leverages existing smart account infrastructure but 250 00:15:55,480 --> 00:16:00,120 offsets the execution or or sends the responsibility 251 00:16:00,120 --> 00:16:01,840 execution to this bundler network. 252 00:16:02,240 --> 00:16:07,120 That bundler network does the on chain execution of any smart 253 00:16:07,120 --> 00:16:12,440 account transaction that is ERC 4337 compatible and that 254 00:16:12,560 --> 00:16:16,640 therefore alleviates the initiators of that transaction 255 00:16:16,640 --> 00:16:21,760 to have to a execute it and B pay for for the on chain gas 256 00:16:21,760 --> 00:16:26,560 costs does ERC 4337 by bundling these transactions. 257 00:16:27,040 --> 00:16:31,160 I suppose it also implies gas optimization because you're 258 00:16:31,160 --> 00:16:34,000 bundling all these transactions together and possibly saving on 259 00:16:34,000 --> 00:16:37,720 gas by doing so. There is some component of of 260 00:16:37,720 --> 00:16:43,200 gas savings in the end. The ERC 457 architecture adds 261 00:16:43,200 --> 00:16:47,320 some gas overhead itself. But assuming that like there's a 262 00:16:47,320 --> 00:16:50,720 lot of adoption of the standard over time, that overhead 263 00:16:51,080 --> 00:16:55,080 decreases and even at some points that there should be ways 264 00:16:55,080 --> 00:17:00,360 to to even have better gas efficiency than just using like 265 00:17:00,360 --> 00:17:03,600 a smart account natively itself. Right. 266 00:17:03,680 --> 00:17:08,680 And just to come back to this signing and execution process, 267 00:17:08,680 --> 00:17:11,240 So what when you you know I've encountered this a bunch of 268 00:17:11,240 --> 00:17:15,599 times where like we start a transaction and then we we 269 00:17:16,000 --> 00:17:19,480 realized maybe the the amount was wrong or there's like some 270 00:17:19,480 --> 00:17:21,400 issue with the transaction as we're signing it. 271 00:17:21,800 --> 00:17:25,160 This happened recently right, where like I had a zero too few 272 00:17:25,160 --> 00:17:30,800 right on in in my amount and and so then you know you you you 273 00:17:30,800 --> 00:17:36,200 have to go through this process of reverting the transaction and 274 00:17:36,200 --> 00:17:38,880 that's because because you've already signed part of that 275 00:17:38,880 --> 00:17:44,720 transaction at any point in the future other signers could sign 276 00:17:44,720 --> 00:17:47,200 for the rest of that transaction and actually execute it. 277 00:17:47,640 --> 00:17:50,920 Now when it comes to this bundler network, you know a 278 00:17:50,920 --> 00:17:56,000 transaction that has been fully signed is basically ready to be 279 00:17:56,000 --> 00:17:58,960 executed. Is there another step then that 280 00:17:59,280 --> 00:18:04,080 the signers of that transaction have to make in order for that 281 00:18:04,080 --> 00:18:06,280 transaction to be made, say, public? 282 00:18:06,280 --> 00:18:09,680 Or does it remain within the hands of the signers and kind of 283 00:18:09,680 --> 00:18:16,080 private until an action is taken to reveal it to anyone including 284 00:18:16,080 --> 00:18:18,440 this bundle network to then execute it on chain? 285 00:18:19,360 --> 00:18:20,680 There's probably 2 steps to that. 286 00:18:21,200 --> 00:18:24,920 One is that after the partially signed transactions can stay 287 00:18:24,920 --> 00:18:28,520 private until it's fully signed and it's sent to the to the 288 00:18:28,520 --> 00:18:32,080 bundle network, yet still like others that are participating. 289 00:18:32,080 --> 00:18:35,280 For example in multi signature use case have access to this 290 00:18:35,280 --> 00:18:38,080 partially signed transaction. So they could complete this 291 00:18:38,080 --> 00:18:41,280 transaction and send it to the bundler network at the later 292 00:18:41,280 --> 00:18:44,280 point. But once it is sent to a bundler 293 00:18:44,280 --> 00:18:47,240 then you need to assume that it's out there and they could be 294 00:18:47,400 --> 00:18:51,360 executed at any point. But this itself is not different 295 00:18:51,360 --> 00:18:55,840 than to how EO as work as well. If you sign a transaction meta 296 00:18:55,840 --> 00:19:00,200 mask today, if you have too low of a gas fee and it's just stuck 297 00:19:00,200 --> 00:19:04,320 in the main pool like it can be executed at any point, which you 298 00:19:04,320 --> 00:19:07,560 can resolve by sending a transaction again with a higher 299 00:19:08,160 --> 00:19:12,840 gas fee in order to speed up the transaction, or by replacing the 300 00:19:12,840 --> 00:19:15,920 transaction on the same nonce with a different transaction. 301 00:19:16,160 --> 00:19:18,160 So that would also be the case with smart accounts. 302 00:19:18,160 --> 00:19:21,480 They also have a nonce. So once a transaction then is 303 00:19:21,480 --> 00:19:24,680 executed at the same nonce, that means that the other partially 304 00:19:24,680 --> 00:19:27,400 signed transaction or fully signed transaction is not able 305 00:19:27,640 --> 00:19:31,200 to be executed anymore and can be disregarded. 306 00:19:31,880 --> 00:19:35,440 But up up in that point, when the nonce is still available and 307 00:19:35,440 --> 00:19:38,600 the transaction is is out there like it needs to be assumed that 308 00:19:38,600 --> 00:19:42,320 it can be executed. I guess we've clarified here 309 00:19:42,320 --> 00:19:48,760 that your C4337 is related to executing transactions. 310 00:19:49,400 --> 00:19:53,720 Is there an EOA that is creating a standard for how smart 311 00:19:53,720 --> 00:19:57,480 accounts should be conceived like in terms of the 312 00:19:57,480 --> 00:19:58,960 architecture of the start smart account? 313 00:19:58,960 --> 00:20:04,560 Or is that up to smart account like companies and and service 314 00:20:04,560 --> 00:20:08,360 providers to decide? As long as they are compatible 315 00:20:08,360 --> 00:20:11,120 with ERC 4337, they can do whatever they want on the 316 00:20:11,120 --> 00:20:15,760 software side. Yeah, so ERC 457 itself has 317 00:20:15,760 --> 00:20:19,120 already some requirements towards smarter cons. 318 00:20:19,880 --> 00:20:22,240 For example that it requires that the smart account 319 00:20:22,240 --> 00:20:25,680 transaction is starting from the account itself, which is 320 00:20:25,680 --> 00:20:29,120 relevant if you think about modular smart accounts. 321 00:20:29,120 --> 00:20:33,160 So you might have different execution logic for an account 322 00:20:33,480 --> 00:20:37,120 and have it depending on what type of transaction it would 323 00:20:37,360 --> 00:20:40,360 require a different signature scheme or or so on. 324 00:20:40,880 --> 00:20:44,280 And there the transaction needs to start in the account and then 325 00:20:44,280 --> 00:20:47,440 go to the to the module which contains the execution logic, 326 00:20:48,000 --> 00:20:51,240 which, yeah, there's some details there that just define 327 00:20:51,240 --> 00:20:54,880 how the account works. There's other ER CS that 328 00:20:55,440 --> 00:20:59,840 standardize certain patterns for smart accounts, such as proxy 329 00:20:59,840 --> 00:21:05,160 patterns or now more recently again with modular smart 330 00:21:05,160 --> 00:21:08,400 accounts. There's certain initiatives from 331 00:21:08,400 --> 00:21:13,600 the community that say the idea should be that we can create 332 00:21:13,600 --> 00:21:16,480 these different modules, which you can imagine to be in a way 333 00:21:16,480 --> 00:21:21,760 like apps on a smartphone. So we shouldn't go to a world 334 00:21:21,760 --> 00:21:26,040 where you change your account in order to kind of add a new 335 00:21:26,040 --> 00:21:29,920 feature to it, be like a session key recovery or something like 336 00:21:29,920 --> 00:21:32,360 that. But instead it should be like 337 00:21:32,360 --> 00:21:34,240 downloading NAP on your smartphone. 338 00:21:34,520 --> 00:21:38,200 And that's enabled through these modular smart accounts, which 339 00:21:38,200 --> 00:21:40,640 means that you have your base account which actually has 340 00:21:40,640 --> 00:21:46,080 certain default logic and you expand that with modules. 341 00:21:46,200 --> 00:21:50,280 This can be validation plug-ins, these can be certain safeguards 342 00:21:50,280 --> 00:21:53,680 that are added to the account and that then extends the, the 343 00:21:53,680 --> 00:21:56,560 logic of the account. And there there's no initiatives 344 00:21:56,560 --> 00:22:00,200 that say we want to have, yeah, certain parts of this 345 00:22:00,320 --> 00:22:03,360 architecture of this modular architecture be the same across 346 00:22:03,360 --> 00:22:05,600 different smart account implementations. 347 00:22:06,200 --> 00:22:09,440 Why should we do that? The idea is that you then don't 348 00:22:09,440 --> 00:22:14,040 have to create these modules for different implementations 349 00:22:14,040 --> 00:22:17,520 separately, but you can actually assume that they have certain 350 00:22:17,800 --> 00:22:20,320 standards that they comply to. And the modules that you create 351 00:22:20,320 --> 00:22:23,680 for Smart Account A works the same way also with Smart Account 352 00:22:23,680 --> 00:22:26,160 B. These are yeah, there's actually 353 00:22:26,160 --> 00:22:31,520 2 standards out there. As always, it's not enough to 354 00:22:31,520 --> 00:22:34,080 have one standard, to have a second standard and then the 355 00:22:34,080 --> 00:22:37,600 first standard to get rid of the other two and so on. 356 00:22:38,000 --> 00:22:42,160 But they are the ERC 6900 which was started last summer by the 357 00:22:42,160 --> 00:22:48,160 Alchemy team and you got ERC 7579 which is a collaboration 358 00:22:48,160 --> 00:22:52,720 between Rhinestone by Economy, OK X and others that define 359 00:22:52,720 --> 00:22:55,720 different ways how these modular smart accounts could look like 360 00:22:56,240 --> 00:22:58,720 with some different technical assumptions. 361 00:22:59,000 --> 00:23:03,720 Completely ERC 6900 bundles the modular architecture also with a 362 00:23:03,720 --> 00:23:05,840 permissioning system. So you say you have these 363 00:23:05,840 --> 00:23:08,600 different modules and you want to give certain permissions to 364 00:23:08,600 --> 00:23:10,920 these modules as a security function. 365 00:23:11,120 --> 00:23:16,320 And ERC 7579 is a very minimal standard that really just 366 00:23:16,320 --> 00:23:20,280 focuses on the modular architecture of smart accounts 367 00:23:20,280 --> 00:23:24,640 and leaves the security, the permissioning system potentially 368 00:23:24,640 --> 00:23:29,520 to future ERC and just says we shouldn't overcomplicate things, 369 00:23:29,720 --> 00:23:31,840 we should just focus on one thing after the other. 370 00:23:32,160 --> 00:23:36,560 And yeah, these standards are in a way competing at this point 371 00:23:36,880 --> 00:23:41,120 from the SAFE perspective. We actually want the SAFE Smart 372 00:23:41,120 --> 00:23:43,720 account to be compatible with any standard. 373 00:23:44,240 --> 00:23:48,080 So that's possible as SAFE itself has some native 374 00:23:48,080 --> 00:23:52,680 modularity built in. So it already has some some ways 375 00:23:52,680 --> 00:23:55,720 you can extend the the Smart account and then you can just 376 00:23:55,720 --> 00:24:00,000 add an adapter in order to be compatible with ERC 6900 or add 377 00:24:00,000 --> 00:24:04,800 another adapter to be compatible with 7579 which makes it just 378 00:24:04,800 --> 00:24:07,640 future proof. It's still unclear how these 379 00:24:07,640 --> 00:24:09,920 standards evolve. They're all they're quite early 380 00:24:10,120 --> 00:24:14,840 got we have little adoption so far and they might still change 381 00:24:14,840 --> 00:24:17,640 over time. So our philosophy there is that 382 00:24:17,640 --> 00:24:22,360 we want to save Smart account really to be as have low level 383 00:24:22,360 --> 00:24:25,240 as possible so that no matter how these standards evolve, we 384 00:24:25,240 --> 00:24:28,920 can just add another adapter to to support them and we have an 385 00:24:28,920 --> 00:24:32,640 account that lasts forever. Incredible. 386 00:24:33,120 --> 00:24:36,360 And So what is Safe's design philosophy here? 387 00:24:36,360 --> 00:24:39,200 I mean 'cause you got you guys have like Safecore which is the 388 00:24:39,200 --> 00:24:42,400 the core of the of the safe product and and the smart 389 00:24:42,400 --> 00:24:48,320 contract logic. And do you think that that this 390 00:24:48,320 --> 00:24:53,240 should be kept as at as minimal as possible in terms of features 391 00:24:53,240 --> 00:24:57,480 and all extensions sort of bring into the functionality or are 392 00:24:57,480 --> 00:25:00,760 you more like this conservative approach to design or do you 393 00:25:00,760 --> 00:25:05,160 have more of a a broader approach to design where this 394 00:25:05,280 --> 00:25:09,280 core could also include other functionalities that are 395 00:25:09,280 --> 00:25:12,840 currently being fulfilled by the plug insurance or or modules? 396 00:25:14,480 --> 00:25:20,480 Yeah, I mean there's probably two key philosophies for Safe. 397 00:25:20,480 --> 00:25:24,960 One is that SAFE, as the name says is is very much focused on 398 00:25:24,960 --> 00:25:28,280 security. So that's just the defines 399 00:25:28,760 --> 00:25:31,800 everything we do at SAFE in terms of like how we approach 400 00:25:32,160 --> 00:25:35,680 upgrades to the smart account, how we approach, yeah, how we 401 00:25:35,960 --> 00:25:39,000 balance for example also flexibility versus security 402 00:25:39,000 --> 00:25:43,080 versus gas efficiency. So we always default more 403 00:25:43,080 --> 00:25:46,240 towards the security side. And the other one is that we 404 00:25:46,240 --> 00:25:51,240 want to be as use case agnostic and use a group as agnostic as 405 00:25:51,240 --> 00:25:55,400 possible, meaning that the account itself, the core save 406 00:25:55,400 --> 00:25:57,720 smart account should be base primitive. 407 00:25:57,720 --> 00:26:01,480 But then you can expand it depending on on the use cases 408 00:26:02,120 --> 00:26:06,280 and optimize then through its modular architecture to 409 00:26:06,280 --> 00:26:10,840 different yeah to different ways to to use the smarter con. 410 00:26:11,240 --> 00:26:16,560 And yeah that also means that we very much depend on the 411 00:26:16,600 --> 00:26:20,360 ecosystem and run safe. So that's something that was was 412 00:26:20,360 --> 00:26:24,520 was clear early on that if you would really want to bring web 413 00:26:24,520 --> 00:26:28,160 free towards smart account adoption, if we want every 414 00:26:28,160 --> 00:26:31,280 account to be a smart account which is our mission like we 415 00:26:31,280 --> 00:26:36,520 cannot aim to do this ourselves. We really rely on ecosystem and 416 00:26:36,520 --> 00:26:40,160 the community of builders to to help us with that. 417 00:26:40,400 --> 00:26:44,640 So what the idea is that the safe smart account becomes this 418 00:26:44,640 --> 00:26:48,200 very core of of this smart account tradition. 419 00:26:48,400 --> 00:26:50,760 And then we have others that are building the different use 420 00:26:50,760 --> 00:26:54,520 cases, speed, different types of wallets with the asset 421 00:26:54,520 --> 00:26:59,000 management solutions that then have built around this, this 422 00:26:59,000 --> 00:27:02,080 core primitive and extend with what what's needed for them. 423 00:27:02,080 --> 00:27:05,720 Is it automations, is it session keys maybe for a gaming use case 424 00:27:06,200 --> 00:27:09,360 is it more past keys if you want to build a retail wallet. 425 00:27:09,600 --> 00:27:15,040 And that then have puts us into a role of of building this core 426 00:27:15,040 --> 00:27:18,280 protocol and working together with the ecosystem through 427 00:27:18,560 --> 00:27:24,200 ecosystem support initiatives to to target these different user 428 00:27:24,200 --> 00:27:28,080 groups from their perspective. So in Safecore, there's there's, 429 00:27:28,280 --> 00:27:30,240 there's multiple components. We have the smart account which 430 00:27:30,240 --> 00:27:33,120 we've talked about. There's also the SDK that sits 431 00:27:33,120 --> 00:27:35,760 on top of it, which allows like you said, you know wallet 432 00:27:35,760 --> 00:27:38,320 developers to utilize the safe infrastructure. 433 00:27:38,480 --> 00:27:40,840 But we haven't talked about the API, which I think is kind of an 434 00:27:40,840 --> 00:27:43,080 overlooked aspect of of Safecore. 435 00:27:43,440 --> 00:27:46,960 And the way I understand, I mean one of the roles of the API of 436 00:27:46,960 --> 00:27:50,040 course is to kind of coordinate around the signatures. 437 00:27:50,040 --> 00:27:55,200 So like when you're signing a a a safe transaction and that 438 00:27:55,280 --> 00:28:00,000 transaction then pops up on the wallet of say your cosigner or 439 00:28:00,000 --> 00:28:04,000 like another signer in the in the wallet configuration that is 440 00:28:04,000 --> 00:28:07,360 happening via an API that I'm not exactly sure how it works. 441 00:28:07,360 --> 00:28:11,560 So I I don't know what is NOSYS or sorry safes the company's 442 00:28:12,160 --> 00:28:14,360 involvement in running infrastructure that's going to 443 00:28:14,360 --> 00:28:16,880 centralized infrastructure that makes that possible or is there 444 00:28:16,880 --> 00:28:19,360 an on chain component there? I'd love it if you could explain 445 00:28:19,600 --> 00:28:23,720 how the API works and who are the the the third parties that 446 00:28:23,720 --> 00:28:26,640 it may rely on. The smart account created, the 447 00:28:26,640 --> 00:28:31,160 smart contact suite is the the core of it all. 448 00:28:31,160 --> 00:28:34,160 But then we provide tooling for developers that just make it 449 00:28:34,160 --> 00:28:36,280 more accessible. If you want to build an 450 00:28:36,280 --> 00:28:39,480 application using smart accounts, if you want to use to 451 00:28:39,480 --> 00:28:44,120 build a wallet, then things like an SDK or API just make this 452 00:28:44,120 --> 00:28:48,160 more accessible, make make the transition from US easier. 453 00:28:48,880 --> 00:28:53,280 And yeah, that we we just always evaluate what's the things that 454 00:28:53,440 --> 00:28:57,120 we can provide to the ecosystem in order to make it easier to 455 00:28:57,120 --> 00:29:00,520 build on smarter cons. And right now it's an SDK that 456 00:29:00,520 --> 00:29:03,240 just allows us to have yeah to interact with the smarter cons 457 00:29:03,240 --> 00:29:09,440 to craft signatures and so on, and to also work with the ERC 458 00:29:09,440 --> 00:29:14,760 457 relaying network and the API as you say, that's it's 459 00:29:14,760 --> 00:29:18,200 essentially an indexer. The most part is an indexer, so 460 00:29:18,200 --> 00:29:21,400 it just indexes all the safe smart account transactions out 461 00:29:21,400 --> 00:29:23,960 there and makes them available for developers. 462 00:29:24,120 --> 00:29:28,320 So you can say you can drag different saves for example. 463 00:29:28,320 --> 00:29:31,160 There's also an event service to it so you can track if there's 464 00:29:31,160 --> 00:29:33,240 any updates to it, if transactions are triggered, if 465 00:29:33,240 --> 00:29:37,120 any incoming assets and so on in order to display this to the 466 00:29:37,320 --> 00:29:39,400 user. But it also has a component of 467 00:29:39,400 --> 00:29:42,720 the signature collection, which is, especially in a multi 468 00:29:42,720 --> 00:29:45,520 signature use case quite critical because you don't want 469 00:29:45,520 --> 00:29:49,800 to have every signer in a multi sig sign on chain, at least in 470 00:29:49,800 --> 00:29:53,160 most cases you you might want to save on the gas cost of signing 471 00:29:53,160 --> 00:29:57,400 on chain and you just sign a signature, sign the transaction 472 00:29:57,400 --> 00:29:59,040 off chain. But then you need a way to 473 00:29:59,040 --> 00:30:01,960 exchange these partially signed transactions with other 474 00:30:02,120 --> 00:30:06,840 participants of the multi sig and that's done also via the the 475 00:30:06,840 --> 00:30:08,520 API. So you can just post these 476 00:30:08,520 --> 00:30:11,800 partially signed transactions and retrieve them from another 477 00:30:11,800 --> 00:30:16,280 user and that just allows to exchange these transactions. 478 00:30:16,600 --> 00:30:19,400 Technically, it would be possible to exchange these 479 00:30:19,400 --> 00:30:20,800 transactions for any other means. 480 00:30:21,120 --> 00:30:24,640 Yeah, also on chain signatures of course, but also by just 481 00:30:24,840 --> 00:30:26,760 downloading a file and sending it to someone else. 482 00:30:26,760 --> 00:30:30,600 Obviously that's not very user friendly, but yeah, that's why 483 00:30:30,600 --> 00:30:33,000 we provide this service. It's also an open source 484 00:30:33,000 --> 00:30:34,560 service. So there there are projects that 485 00:30:34,560 --> 00:30:39,520 they run it themselves just as a redundancy and we eventually 486 00:30:39,520 --> 00:30:42,360 also want to get to a place where there's actually a 487 00:30:42,360 --> 00:30:46,200 decentralized network of of indexers that participate in in 488 00:30:46,200 --> 00:30:50,680 retrieving and yeah sharing these partially signed 489 00:30:50,680 --> 00:30:54,320 transactions just because it's it's always better to not rely 490 00:30:54,320 --> 00:30:57,720 just on a on a centralized service even though like anyone 491 00:30:57,720 --> 00:30:59,320 could run the service themselves and so on. 492 00:30:59,320 --> 00:31:03,040 But the the truth is that it probably would take quite some 493 00:31:03,040 --> 00:31:06,360 time until some other service what's what's been up that has a 494 00:31:06,600 --> 00:31:10,720 similar performance that would then have step in if if our 495 00:31:10,800 --> 00:31:14,720 index will be done or so. So drafted pathway towards this 496 00:31:14,720 --> 00:31:18,120 decentralized index network is is something that we are looking 497 00:31:18,120 --> 00:31:19,880 into. Yeah. 498 00:31:19,880 --> 00:31:20,640 OK. Interesting. 499 00:31:20,640 --> 00:31:25,200 So, so currently for all of the SAFE wallet products, I guess 500 00:31:25,200 --> 00:31:28,720 SAFE is running that infrastructure in a kind of 501 00:31:28,720 --> 00:31:32,880 centralized way. But as a user, you can choose to 502 00:31:32,880 --> 00:31:34,520 either run your own infrastructure or if you're a 503 00:31:34,520 --> 00:31:37,760 company using SAFE, you can also run that infrastructure yourself 504 00:31:37,760 --> 00:31:40,800 for redundancy. But but you can also share the 505 00:31:40,800 --> 00:31:43,400 signatures on chain, correct? Exactly. 506 00:31:44,160 --> 00:31:46,400 OK, interesting. Now that might make sense on 507 00:31:46,400 --> 00:31:48,640 some networks that have like lower gas costs, but I got 508 00:31:48,640 --> 00:31:51,320 Etherium that might be a bit prohibitive. 509 00:31:51,920 --> 00:31:57,400 Yeah, and it also makes sense as this service is only run for a 510 00:31:57,680 --> 00:32:02,120 certain set of of of networks. On that networks where the index 511 00:32:02,120 --> 00:32:04,800 is not run, you can still sign on chain. 512 00:32:05,040 --> 00:32:06,960 And it also is an additional redundancy. 513 00:32:07,200 --> 00:32:09,840 If the the service is not available then you could just 514 00:32:10,360 --> 00:32:13,480 with some little extra gas cost you could sign on chain and and 515 00:32:14,040 --> 00:32:17,560 not be dependent on. It OK, great. 516 00:32:17,560 --> 00:32:19,200 This is cool. Thanks for clearing that up. 517 00:32:19,200 --> 00:32:22,240 On the. Yeah, on the wallet side, I'd 518 00:32:22,240 --> 00:32:25,200 like to talk a little bit about the the user experience here and 519 00:32:25,480 --> 00:32:27,840 what are the some of the challenges that you guys face 520 00:32:27,840 --> 00:32:34,200 when building in a wallet that you know supports safe core. 521 00:32:34,640 --> 00:32:37,560 And you know, I like the preface this by saying I've had my share 522 00:32:37,560 --> 00:32:41,440 of moments using SAFE where I didn't really know what was 523 00:32:41,440 --> 00:32:45,280 happening or where my transaction was in the queue or 524 00:32:45,280 --> 00:32:47,600 whether like you know, trying to sign a transaction is not 525 00:32:47,600 --> 00:32:49,080 working. And I'm getting some weird error 526 00:32:49,080 --> 00:32:51,560 message. And I've actually talked to SAFE 527 00:32:52,000 --> 00:32:56,040 support like two or three times when executing transaction and 528 00:32:56,040 --> 00:32:59,560 they've always been very helpful and have helped to clear things 529 00:32:59,560 --> 00:33:02,720 up. But yeah, how do we, how do we 530 00:33:02,720 --> 00:33:06,080 come to a better user experience around around these things? 531 00:33:06,080 --> 00:33:10,600 Because it's still super cumbersome, I mean especially if 532 00:33:10,600 --> 00:33:14,160 you're using a Ledger and then you sign with Metamask and it 533 00:33:14,160 --> 00:33:19,680 all feels very cumbersome. And I still like I still stress 534 00:33:19,680 --> 00:33:23,360 every time I do a multi sync transaction because there's just 535 00:33:23,360 --> 00:33:26,960 all these moving parts that need to work and it it it always 536 00:33:26,960 --> 00:33:30,680 feels like a bit of a a lift to to get that transaction signed. 537 00:33:30,680 --> 00:33:33,520 So yeah, what are your thoughts on on user experience generally 538 00:33:33,520 --> 00:33:35,560 and how can we how can we improve all this? 539 00:33:37,280 --> 00:33:40,840 It's actually interesting because there's like two camps 540 00:33:40,840 --> 00:33:43,520 here. Some people say like the the 541 00:33:43,560 --> 00:33:47,080 safe wallet interface is already quite user friendly and and some 542 00:33:47,240 --> 00:33:50,360 still have issues. It's probably also to to some 543 00:33:50,360 --> 00:33:53,640 extent if you compare where safe wallet is today compared to 544 00:33:53,640 --> 00:33:55,920 where where it is 2-3 years ago. I would say there's like a 545 00:33:55,920 --> 00:33:58,760 massive improvement in user experience since then, but 546 00:33:58,760 --> 00:34:01,400 obviously it's still a long long way to go. 547 00:34:01,640 --> 00:34:05,120 Also challenge there is that we want to have safe wallet, PS 548 00:34:05,560 --> 00:34:07,120 user group and use case agnostic. 549 00:34:07,520 --> 00:34:12,120 So we cannot optimize for say someone that's super technical 550 00:34:12,120 --> 00:34:16,400 that wants to see like all the information and always be able 551 00:34:16,400 --> 00:34:18,880 to to look under the hood of everything at the at the same 552 00:34:18,880 --> 00:34:23,040 time optimize for someone that is less technical that really 553 00:34:23,040 --> 00:34:24,639 wants to have everything abstracted away. 554 00:34:25,040 --> 00:34:29,040 So we always try to be somewhere in in in the middle and then 555 00:34:29,239 --> 00:34:32,600 actually work with the ecosystem to provide the the best 556 00:34:32,600 --> 00:34:34,239 experiences for the different user groups. 557 00:34:34,760 --> 00:34:38,440 So for example there's and on chain den which specialises 558 00:34:38,440 --> 00:34:42,239 really on multi signature in a in a team use case and having 559 00:34:42,239 --> 00:34:44,679 transactions. They say that the the the 560 00:34:45,239 --> 00:34:48,840 interface that allows you to have side transactions the the 561 00:34:48,840 --> 00:34:53,560 fastest and they have like some you have some notification 562 00:34:53,560 --> 00:34:56,280 system behind it and so on and some some gas abstraction and 563 00:34:56,560 --> 00:34:58,920 they do certain optimizations there. 564 00:34:58,920 --> 00:35:02,280 And then there's others like a Nest wallet which is optimizing 565 00:35:02,280 --> 00:35:07,600 more for individuals and and and retail users that allow allows 566 00:35:07,600 --> 00:35:10,640 them to abstract a little bit more from the details away and 567 00:35:10,640 --> 00:35:15,320 have like a more smooth user experience where maybe the trust 568 00:35:15,320 --> 00:35:17,600 team collaboration part is less of a focus. 569 00:35:18,200 --> 00:35:20,800 So that's really our strategy that we say say for that it's 570 00:35:20,800 --> 00:35:24,760 like a baseline, it should be like an interface that people 571 00:35:24,760 --> 00:35:28,560 can start using in order to get experiences with with smart 572 00:35:28,560 --> 00:35:31,440 accounts to to cover certain use cases. 573 00:35:31,440 --> 00:35:35,440 But then as you over time, there should really be like a wide 574 00:35:35,480 --> 00:35:40,360 ecosystem of of of designated solutions that optimize for for 575 00:35:40,360 --> 00:35:42,720 different solutions. Yeah, user groups. 576 00:35:43,880 --> 00:35:45,920 No that's cool. I I made a note of these I think 577 00:35:45,920 --> 00:35:47,960 I'll probably try them out as well this. 578 00:35:48,160 --> 00:35:50,280 So you said on chain den and Nest wallet. 579 00:35:50,960 --> 00:35:53,320 Yeah. I mean with like the the some of 580 00:35:53,320 --> 00:35:57,720 the issues I've faced were were yeah I think like ordering of of 581 00:35:57,720 --> 00:36:01,400 signing and and then you know not able to post a transaction 582 00:36:01,400 --> 00:36:05,800 on chain and you know having to update that transaction with a 583 00:36:05,800 --> 00:36:08,360 new nonce. Like these kinds of things are 584 00:36:08,360 --> 00:36:11,240 very unintuitive I think for most people and even me. 585 00:36:11,240 --> 00:36:14,880 And you know the error message really doesn't explain much of 586 00:36:14,880 --> 00:36:19,280 what you need to do. So I think having kind of a in 587 00:36:19,280 --> 00:36:22,880 app resolution mechanism to kind of fix this problem you know 588 00:36:22,880 --> 00:36:26,040 without having to reach to support or look you know look 589 00:36:26,040 --> 00:36:27,840 for things online. And the other thing is I think 590 00:36:27,840 --> 00:36:30,560 there's I find there's like some inconsistencies between the way 591 00:36:30,560 --> 00:36:34,600 the wallet, the mobile wallet works and the the desktop works 592 00:36:35,840 --> 00:36:40,120 the kind of web version. And one thing I've never really 593 00:36:40,120 --> 00:36:43,880 understood is with the with the mobile wallet and by the way the 594 00:36:43,880 --> 00:36:46,640 mobile wallet's great like I typically do transactions on the 595 00:36:46,640 --> 00:36:49,880 mobile wallet. I think that that's the best 596 00:36:49,880 --> 00:36:53,920 user experience I think for you know for what we do and and we 597 00:36:53,920 --> 00:36:56,360 have a bunch of ledgers that we signed with and I love that the 598 00:36:56,360 --> 00:36:58,360 mobile wallet supports the Ledger and we can just like pull 599 00:36:58,360 --> 00:37:00,840 them out and get together and and you assign things. 600 00:37:01,840 --> 00:37:04,120 But there's one thing I don't really understand is like why 601 00:37:04,120 --> 00:37:08,520 you need to have a it. It seems like you need to have 602 00:37:08,520 --> 00:37:11,360 an on device account. So like when you create this 603 00:37:11,360 --> 00:37:15,800 safe for the first time you need to have like a a seed phrase 604 00:37:15,800 --> 00:37:16,880 that you have to store somewhere. 605 00:37:16,880 --> 00:37:21,120 It's generated on the, it's generated in the app and I 606 00:37:21,120 --> 00:37:24,160 haven't found a way to be able to sign the transactions with 607 00:37:24,400 --> 00:37:28,120 anything else than that on wallet account. 608 00:37:28,520 --> 00:37:32,440 I can't execute with the with the Ledger which kind of seems a 609 00:37:32,440 --> 00:37:34,200 bit backwards to me. If we're going to have ledgers 610 00:37:34,200 --> 00:37:39,400 to to sign safe transactions to then have to have this less safe 611 00:37:39,400 --> 00:37:41,760 kind of hot wallet you know on the device. 612 00:37:42,160 --> 00:37:44,880 So that's that's, yeah, I don't know, maybe I'm doing something 613 00:37:44,880 --> 00:37:46,960 wrong here, but that's always been a little confusing to me. 614 00:37:47,440 --> 00:37:50,560 Yeah, are you using Android? No iOS. 615 00:37:50,840 --> 00:37:55,480 IOS OK because technically it should be possible to execute 616 00:37:55,480 --> 00:37:58,040 also with Ledger. So the idea about the mobile 617 00:37:58,040 --> 00:38:02,000 wallet is that it's it should be just a very smooth way to to 618 00:38:02,000 --> 00:38:05,920 cosine transactions and you can add any kind of like wallets to 619 00:38:05,920 --> 00:38:08,960 to do so like Ledger via Bluetooth for like mobile 620 00:38:08,960 --> 00:38:13,800 wallets via wallet connect. And yeah, I can look into this I 621 00:38:13,800 --> 00:38:15,680 think. Yeah, we'll have to talk after, 622 00:38:16,240 --> 00:38:19,880 but yeah, so there's like these kind of minor UX things that I 623 00:38:19,880 --> 00:38:21,680 find you know can be, can be improved. 624 00:38:21,680 --> 00:38:25,240 But overall you're like I I agree with you that the 625 00:38:25,240 --> 00:38:29,000 experience generally is, is is pretty good. 626 00:38:29,720 --> 00:38:33,280 You know, compared to look like 10 years ago Brian and I used to 627 00:38:33,280 --> 00:38:35,760 do Bitcoin transactions, electron wallet and we have to 628 00:38:35,760 --> 00:38:38,800 send the partially signed transactions over slack and you 629 00:38:38,800 --> 00:38:43,160 know it was a huge mess, right. I mean like this is definitely a 630 00:38:43,280 --> 00:38:47,200 huge leg up from having to do this kind of shenanigans, which 631 00:38:47,200 --> 00:38:49,080 you know for for people who have been in this space long enough 632 00:38:49,120 --> 00:38:50,880 will will be, will be familiar with. 633 00:38:51,520 --> 00:38:54,160 Yeah. And I mean that's something in 634 00:38:54,160 --> 00:38:56,480 terms of user experience that's very close to my heart because I 635 00:38:56,480 --> 00:39:00,120 think in general the web free space like we're we're staying 636 00:39:00,160 --> 00:39:02,880 saying things since years that we're still early and at some 637 00:39:02,880 --> 00:39:06,680 point we cannot allow us to to say that anymore because we it's 638 00:39:06,680 --> 00:39:08,880 still quite cumbersome. If you want to do full self 639 00:39:08,880 --> 00:39:12,840 custody and interact with with tabs and like that's still not 640 00:39:12,840 --> 00:39:17,160 that accessible to a wide range of of people like in in the 641 00:39:17,160 --> 00:39:20,600 world like even just having pretty much everything default 642 00:39:20,600 --> 00:39:24,120 to English like that that's fine for certain parts of the western 643 00:39:24,120 --> 00:39:27,880 world but we need to have more localized solutions but also in 644 00:39:27,880 --> 00:39:31,960 general how the DX works of of wallets today there needs to be 645 00:39:31,960 --> 00:39:35,440 so much more that that we should do in next year's. 646 00:39:35,440 --> 00:39:37,880 And that's also why I'm so excited about smart accounts, 647 00:39:37,880 --> 00:39:40,800 because I think in the long run these smart accounts will be the 648 00:39:40,800 --> 00:39:43,760 solution. And there's no way around smart 649 00:39:43,760 --> 00:39:47,040 accounts in order to get to the user experience while it's still 650 00:39:47,040 --> 00:39:51,360 retaining like security that is needed to to onboard like a 651 00:39:51,480 --> 00:39:56,120 billion people to to web free. Yeah, I think smart accounts are 652 00:39:56,120 --> 00:39:59,760 are huge unlocked there and I'm really looking forward to more 653 00:39:59,760 --> 00:40:04,600 broad adoption of passkey and other ways of signing. 654 00:40:04,600 --> 00:40:06,480 So you know. I'll I'll tell you a little bit 655 00:40:06,480 --> 00:40:07,920 about what's happening. I don't know if you're familiar 656 00:40:07,920 --> 00:40:11,240 with this, but in the Cosmos ecosystem Osmosis which is the 657 00:40:11,240 --> 00:40:14,880 major decks there are doing an on chain smart account. 658 00:40:14,880 --> 00:40:16,960 Now of course the difference here is that they manage the 659 00:40:16,960 --> 00:40:21,600 entire chain and they can really build things on chain and also 660 00:40:21,600 --> 00:40:24,640 have certain types of transactions be either gas 661 00:40:24,640 --> 00:40:27,760 subsidized or gas optimized. And so they the idea here is to 662 00:40:27,760 --> 00:40:32,040 do a smart account on chain that you can set up using, you know 663 00:40:32,040 --> 00:40:34,880 Oauth like a Twitter account or a Google account. 664 00:40:34,880 --> 00:40:38,960 And then based on the on the value of the transactions you're 665 00:40:38,960 --> 00:40:42,880 doing or perhaps even the value in the on the account itself. 666 00:40:42,880 --> 00:40:47,000 Then you you'll be required to add a second factor 667 00:40:47,000 --> 00:40:49,600 authentication. So it could be like a passkey or 668 00:40:49,600 --> 00:40:52,440 or a secondary account to sign. And you know they're building 669 00:40:52,440 --> 00:40:55,520 all of this infrastructure on the chain, which is, which is 670 00:40:55,520 --> 00:40:56,640 great when you're doing your own chain. 671 00:40:56,640 --> 00:41:00,040 And you know brings me to another question I wanted to ask 672 00:41:00,040 --> 00:41:06,840 you is what's safe strategy when it comes to building it's cross 673 00:41:06,840 --> 00:41:09,560 chain presence. And by cross chain, I don't mean 674 00:41:09,560 --> 00:41:12,440 just EVM chains, which I know you guys are supporting very 675 00:41:12,440 --> 00:41:17,200 well, but other ecosystems like Solana, like Cosmos chains, like 676 00:41:17,200 --> 00:41:21,600 the MOVE ecosystem, the, you know, Aptos and Sui, you know, 677 00:41:21,600 --> 00:41:24,080 are you guys looking at those ecosystems at all and thinking 678 00:41:24,080 --> 00:41:27,680 of ways that SAFE can support those or is your focus really 679 00:41:27,680 --> 00:41:31,320 just the EVM and you'll stick to, you know, what you're great 680 00:41:31,320 --> 00:41:34,160 at? I would say when it comes to 681 00:41:34,160 --> 00:41:38,040 cross chain, smart accounts in the short term will bring new 682 00:41:38,040 --> 00:41:41,720 challenges in in the long run will actually solve cross chain 683 00:41:41,720 --> 00:41:47,200 in a way that it can make it irrelevant in what networks you 684 00:41:47,240 --> 00:41:49,960 interact with what dabs. But this can be abstracted away 685 00:41:50,640 --> 00:41:54,280 through through smart accounts. But yeah, in in the short term 686 00:41:54,280 --> 00:41:57,200 there there are challenges. One of them is that smart 687 00:41:57,200 --> 00:42:01,720 accounts, they are, they are just very unique per chain. 688 00:42:01,840 --> 00:42:04,160 So because these are smart contacts, they're deployed on a 689 00:42:04,160 --> 00:42:07,760 certain network, they have the logic on that network. 690 00:42:08,360 --> 00:42:12,520 Which means that while it's possible to have a similar smart 691 00:42:12,520 --> 00:42:15,880 account on a different network with the same logic, potentially 692 00:42:15,880 --> 00:42:18,600 even the same address through Grade 2 counterfactual 693 00:42:18,600 --> 00:42:21,600 deployment, they're still very much independent accounts. 694 00:42:21,600 --> 00:42:26,760 Which is a difference towards EO as which are by design because 695 00:42:26,760 --> 00:42:30,040 it's kind of standardised especially in the EVM ecosystem 696 00:42:30,280 --> 00:42:33,040 like you have a seat race and it's immediately and we count on 697 00:42:33,080 --> 00:42:35,960 all EVM networks. So that's that's going to 698 00:42:35,960 --> 00:42:40,800 change, it has to change and there are solutions that are 699 00:42:40,800 --> 00:42:44,560 being worked on in terms of like key stores that are accessible 700 00:42:44,560 --> 00:42:49,320 cross chain and ways to to sync the state across the chains that 701 00:42:49,320 --> 00:42:52,560 will eventually solve that. There was just recently like a 702 00:42:52,560 --> 00:42:56,960 spec on that from Michael from base that goes into that that 703 00:42:56,960 --> 00:43:00,040 that's one thing and then the the other challenge will be that 704 00:43:00,200 --> 00:43:03,400 smart accounts they are very much depend on the virtual 705 00:43:03,400 --> 00:43:06,920 machine. So you can have a smart contact 706 00:43:06,920 --> 00:43:11,560 that creates your your account but obviously that's very much 707 00:43:11,800 --> 00:43:15,000 depend on what smart contact language you use for 708 00:43:15,000 --> 00:43:18,880 implementation and all the security assumptions are depend 709 00:43:18,880 --> 00:43:21,360 on the the virtual machine behind it. 710 00:43:21,360 --> 00:43:24,960 So it's possible to create a similar smart account then 711 00:43:24,960 --> 00:43:29,600 across non EVM chains like a Solana or or else. 712 00:43:29,720 --> 00:43:33,960 But this will necessarily you remove certain technical 713 00:43:33,960 --> 00:43:36,800 assumptions that you can take certain security assumptions and 714 00:43:36,800 --> 00:43:40,280 you will have to build up the the trust into this smart 715 00:43:40,280 --> 00:43:43,920 account from scratch. So there's similar solutions to 716 00:43:43,920 --> 00:43:47,760 save on say Solana, that's like a squats that have been around 717 00:43:48,000 --> 00:43:50,160 quite a while and that do similar things. 718 00:43:50,160 --> 00:43:54,920 And for safe the near to mid term focus will still be EVM. 719 00:43:55,240 --> 00:43:57,480 I think there's enough that can be built there. 720 00:43:57,480 --> 00:44:00,720 In terms of smart account adoption on DVM itself, it's 721 00:44:00,720 --> 00:44:04,240 it's a huge ecosystem and there's it just allows to move 722 00:44:04,640 --> 00:44:07,800 faster if you can make the technical assumptions on the VM 723 00:44:07,800 --> 00:44:10,160 virtual machine. But obviously in the long run 724 00:44:10,160 --> 00:44:15,200 this should not be limited to to that and safe in in some way or 725 00:44:15,200 --> 00:44:19,480 another should be also, yeah, available outside of the VM 726 00:44:19,480 --> 00:44:21,360 itself. And whether that that means 727 00:44:21,360 --> 00:44:24,320 integrating with some of the other implementations such such 728 00:44:24,360 --> 00:44:27,720 as the squads on on other networks, that's yet to be seen. 729 00:44:28,080 --> 00:44:31,160 But that's definitely in the long term, say three to five 730 00:44:31,160 --> 00:44:32,360 years, something that needs to be done. 731 00:44:34,040 --> 00:44:38,480 Yeah, I mean I I would love to see safe in other ecosystems 732 00:44:39,160 --> 00:44:41,840 been brought mostly because like solutions I think are lacking. 733 00:44:42,120 --> 00:44:46,880 Yeah, I I think that in the next one to two years we'll see safe 734 00:44:46,880 --> 00:44:51,360 competitors emerge in those ecosystems like native solutions 735 00:44:51,360 --> 00:44:55,560 emerge in those ecosystems which will you know half mover, first 736 00:44:55,560 --> 00:45:00,320 mover advantage and likely make it difficult for SAFE to really 737 00:45:00,320 --> 00:45:03,640 gain a a a foothold in in those ecosystems. 738 00:45:03,760 --> 00:45:06,040 Maybe you know with the exception of like existing 739 00:45:06,040 --> 00:45:09,520 customers on the safe on the EVM side that have assets there that 740 00:45:09,520 --> 00:45:11,680 want to move those assets into other ecosystems. 741 00:45:12,160 --> 00:45:16,120 What when it comes to the EVM ecosystem and the cross chain 742 00:45:16,120 --> 00:45:20,360 compatibility, what's the progress in terms of being able 743 00:45:20,360 --> 00:45:25,080 to control cross chain accounts from like a single account. 744 00:45:25,080 --> 00:45:30,040 So for example you know if you had assets on or you had like a 745 00:45:30,040 --> 00:45:35,520 safe account on on Polygon and wanted to control assets on 746 00:45:35,520 --> 00:45:37,560 another account by signing something on Polygon. 747 00:45:37,560 --> 00:45:42,440 Like is there any progress in, in the in the direction of 748 00:45:42,640 --> 00:45:44,920 Interchain accounts as we call them in in Cosmos. 749 00:45:45,000 --> 00:45:48,920 So these are accounts that can be controlled externally by an 750 00:45:48,920 --> 00:45:52,080 account on the other chain. Is that also something that can 751 00:45:52,080 --> 00:45:54,360 exist within the safe ecosystem in the EVM world? 752 00:45:55,520 --> 00:45:57,640 Definitely. So that's what I mentioned 753 00:45:57,640 --> 00:46:01,520 before on key stores. So that's actually something 754 00:46:01,520 --> 00:46:05,320 that was proposed by Vitalik Buterin last year and now 755 00:46:05,480 --> 00:46:08,200 certain teams are are looking into. 756 00:46:08,200 --> 00:46:12,080 The idea is that you should have the ability to have multiple 757 00:46:12,120 --> 00:46:18,040 Sparta cons but after the core validation logic or the the 758 00:46:18,040 --> 00:46:21,880 logic what keys are associated with that account separated in 759 00:46:21,960 --> 00:46:25,840 two separate contract which is a key store contract which then 760 00:46:25,840 --> 00:46:28,840 allows you to have less of that logic in the account itself and 761 00:46:28,840 --> 00:46:31,520 you just say from the account. You then make a state proof 762 00:46:31,520 --> 00:46:35,800 towards that key store and then it allows you to see what's 763 00:46:35,800 --> 00:46:39,480 actually the the account logic and and proof that against the 764 00:46:39,880 --> 00:46:43,840 the transaction and that can then be taken cost chain as well 765 00:46:43,960 --> 00:46:46,520 actually in via designated roll up. 766 00:46:46,760 --> 00:46:49,640 So that could be like a keystore roll up that then contains the 767 00:46:49,640 --> 00:46:53,520 logic of your account as you have your sub account so to say 768 00:46:53,520 --> 00:46:57,200 on different networks. Could be EVM, could be beyond 769 00:46:57,200 --> 00:47:01,720 DVM that just allow you to use a cross chain state proof against 770 00:47:01,720 --> 00:47:07,240 this keystore roll up in order to prove what what keys or what 771 00:47:07,680 --> 00:47:09,720 validation logic this this account has. 772 00:47:10,240 --> 00:47:13,720 And then this essentially means that you will have cross chain 773 00:47:13,720 --> 00:47:17,520 smarter cons that can then be allow you to think to to achieve 774 00:47:17,520 --> 00:47:20,560 things like complete network abstraction where for a user or 775 00:47:20,560 --> 00:47:23,520 a developer it doesn't even matter where the transaction is 776 00:47:23,520 --> 00:47:25,560 starting and where it's pointing at. 777 00:47:25,560 --> 00:47:29,560 But this is then exactly the way by having these questions smart 778 00:47:29,560 --> 00:47:32,480 accounts. I would still say it's like 779 00:47:32,640 --> 00:47:37,200 maybe 6 to 12 months out until we have first production ready 780 00:47:37,360 --> 00:47:39,400 implementations of such keystone roll ups. 781 00:47:39,640 --> 00:47:45,200 But there's like major teams working on that and I'm I'm 100% 782 00:47:45,200 --> 00:47:47,720 sure that we are going to that direction and it's got to be 783 00:47:47,720 --> 00:47:51,480 first maybe optimized for certain sub ecosystems say the 784 00:47:51,880 --> 00:47:54,240 optimism ecosystem or the small ecosystem. 785 00:47:54,480 --> 00:47:59,040 But over time it will expand and even go go beyond the EVM where 786 00:47:59,240 --> 00:48:01,960 you can have like the keystore roll up which is based in 787 00:48:02,200 --> 00:48:05,320 Etherium layer one but as a roll up in order to optimize some gas 788 00:48:05,320 --> 00:48:08,040 efficiency. But then allows you to yeah, 789 00:48:08,040 --> 00:48:11,520 prove that that verification state towards any other 790 00:48:11,640 --> 00:48:13,960 networks. Very cool. 791 00:48:13,960 --> 00:48:18,080 Yeah I mean I think that that's mostly like untapped kind of 792 00:48:18,080 --> 00:48:22,760 feature in in the EVM world this, this ability to control 793 00:48:22,760 --> 00:48:26,480 accounts cross chain you know again like in you know in Cosmos 794 00:48:26,480 --> 00:48:28,560 we have standards for this and and it exists and we're able to 795 00:48:28,560 --> 00:48:33,240 do this pretty easily but but in the EVM IT world it's I think 796 00:48:33,240 --> 00:48:36,720 it's it's still needs a little bit of time in order to become 797 00:48:36,720 --> 00:48:39,280 production ready. So you guys recently announced 798 00:48:39,280 --> 00:48:42,200 this, I think it was last year this recovery hub. 799 00:48:42,200 --> 00:48:46,280 So it's safe added all these different kind of methods to do 800 00:48:46,280 --> 00:48:50,800 recovery and you have some partners there that I guess can 801 00:48:50,800 --> 00:48:54,760 act as third party signers in the event of lost keys. 802 00:48:55,320 --> 00:48:57,800 What does this look like, and what are the kind of trust 803 00:48:57,800 --> 00:49:01,960 assumptions that users of SAFE have to make in order to be 804 00:49:02,160 --> 00:49:07,080 using this recovery feature? Yeah, so the idea behind 805 00:49:07,080 --> 00:49:11,320 recovery is that you may have more user friendly ways to get 806 00:49:11,320 --> 00:49:14,320 keys into head to hand of of users, be it like passkey 807 00:49:14,320 --> 00:49:19,520 signers or be it social login signers such as like log in with 808 00:49:19,520 --> 00:49:23,480 Google or something like that. But still you want to have worst 809 00:49:23,480 --> 00:49:27,680 case scenario way to recover access to your account and that 810 00:49:27,680 --> 00:49:30,920 actually at least in my opinion it it's something that's very 811 00:49:31,560 --> 00:49:33,920 idiosyncratic to the user itself. 812 00:49:33,920 --> 00:49:36,400 So there might be different users that want to have 813 00:49:36,400 --> 00:49:38,040 different ways to recover the account. 814 00:49:38,240 --> 00:49:41,520 Some like trust their family and friends. 815 00:49:41,520 --> 00:49:44,280 They just want to have sort of like a multi say controlled by 816 00:49:44,280 --> 00:49:47,280 their family and friends controlling their account. 817 00:49:47,280 --> 00:49:51,840 And if they lose their own keys they just approach these social 818 00:49:51,840 --> 00:49:55,160 recovery signers and and ask them to initiate the recovery. 819 00:49:55,440 --> 00:50:01,000 Others may trust an institution such as a a bank or a notary or 820 00:50:01,000 --> 00:50:04,880 something like that that can execute the recovery in certain 821 00:50:04,880 --> 00:50:10,520 cases even in inheritance cases worst case and Yep there's in 822 00:50:10,920 --> 00:50:15,880 for others that may trust some like decentralized network of 823 00:50:16,800 --> 00:50:22,040 like yeah humanity doll kind of system that then verifies the 824 00:50:22,040 --> 00:50:25,520 identity of of someone that then can be used to recover the 825 00:50:25,520 --> 00:50:28,720 account through some identity verification. 826 00:50:29,640 --> 00:50:34,120 And how we're thinking then around what we built in terms of 827 00:50:34,360 --> 00:50:37,120 the foundations for enabling these use cases is that we 828 00:50:37,320 --> 00:50:42,120 created this recovery hub which is very much agnostic system to 829 00:50:42,360 --> 00:50:45,280 add different recovery systems and we're working together with 830 00:50:45,280 --> 00:50:48,880 partners in order to showcase some of these capabilities. 831 00:50:49,480 --> 00:50:53,240 So the very base logic of the recovery hub is that you can add 832 00:50:53,240 --> 00:50:55,800 a module which is like a separate Spark contract which 833 00:50:56,000 --> 00:50:58,520 has access to your account as an admin key. 834 00:50:58,760 --> 00:51:03,920 But then you add security guards that make sure that this admin 835 00:51:03,920 --> 00:51:08,880 key is is somewhere some somewhat protected that and that 836 00:51:08,880 --> 00:51:11,560 can be depending on on what the user prefers. 837 00:51:11,600 --> 00:51:16,240 It's usually like a a time lock so that the user can say this 838 00:51:16,240 --> 00:51:20,200 separate contract can recover my account but only by having a 839 00:51:20,200 --> 00:51:23,320 time lock of like 3 months. So I can't really pre sign the 840 00:51:23,480 --> 00:51:26,320 the recovery and in that three months I could cancel the 841 00:51:26,320 --> 00:51:30,560 recovery if I have access to my keys and this then allows to 842 00:51:30,560 --> 00:51:35,680 have less trusted system where am I may delegate this admin key 843 00:51:35,680 --> 00:51:39,320 to my social recovery setup or to this institution but still 844 00:51:39,320 --> 00:51:42,280 have to certainly that they cannot go rogue and just run 845 00:51:42,280 --> 00:51:45,480 away with the account. There's other ways to to add 846 00:51:45,840 --> 00:51:49,600 security such as Signum which is a Swiss licensed bank which is 847 00:51:49,600 --> 00:51:52,160 building a recovery system for the recovery hub. 848 00:51:52,400 --> 00:51:56,120 What they're doing is that they limit the capabilities of this 849 00:51:56,320 --> 00:52:00,720 this recovery module to only exchanging certain signers in 850 00:52:00,720 --> 00:52:03,640 the con. So the logic goes like this 851 00:52:03,800 --> 00:52:08,080 recovery module can exchange signer A but not signer BC or D 852 00:52:08,600 --> 00:52:11,920 and this can be then configured by the user and they can say 853 00:52:11,920 --> 00:52:16,120 just this one signer which I trust signum to recover. 854 00:52:16,640 --> 00:52:21,200 I set up and this then just limits what signum can do with 855 00:52:21,200 --> 00:52:23,320 the account and again with some time lock. 856 00:52:23,320 --> 00:52:25,320 So there's an additional protection for that. 857 00:52:25,520 --> 00:52:28,720 But essentially the it's it's very open-ended what can be done 858 00:52:28,720 --> 00:52:32,280 there and there can be vast amounts of different ways that 859 00:52:32,760 --> 00:52:35,240 these these recovery setups are being created. 860 00:52:36,680 --> 00:52:40,880 And are there any kind of best practices like so if if someone 861 00:52:40,880 --> 00:52:45,360 wanted to set up a multi sig account or you know a smart 862 00:52:45,360 --> 00:52:48,280 account and then have a recovery. 863 00:52:48,280 --> 00:52:51,200 I think one of the things that you internally we spend a lot of 864 00:52:51,200 --> 00:52:55,320 time thinking about was OK what is the key distribution setup 865 00:52:55,320 --> 00:52:57,760 look like? Like who has keys, where are 866 00:52:57,760 --> 00:53:00,000 they? Where are the seats stored? 867 00:53:00,640 --> 00:53:03,440 You know what other third parties outside of our 868 00:53:03,440 --> 00:53:07,200 organization might have access to these keys for backup or 869 00:53:07,200 --> 00:53:10,280 recovery purposes. Does safe make any 870 00:53:10,280 --> 00:53:13,720 recommendations or best practices recommend best 871 00:53:13,720 --> 00:53:17,960 practices when it term comes to doing this kind of, you know, 872 00:53:17,960 --> 00:53:20,080 smart account set up within an organization? 873 00:53:21,680 --> 00:53:24,440 I mean, we usually recommend to use a threshold of more than 874 00:53:24,440 --> 00:53:26,240 one, that's obvious. You want to have multi 875 00:53:26,240 --> 00:53:29,880 signature, not just one out of five, where every one of the 876 00:53:30,280 --> 00:53:33,240 members of the organization can do whatever they want, so 877 00:53:33,240 --> 00:53:36,280 there's at least multiple people looking over a transaction. 878 00:53:36,520 --> 00:53:40,120 And then we also recommend to not use a threshold that's equal 879 00:53:40,560 --> 00:53:44,680 to the number of signers, so not to any five out of five schemes 880 00:53:45,040 --> 00:53:48,160 because that will mean that only one key needs to be lost and the 881 00:53:48,320 --> 00:53:52,800 the account is not usable anymore in case you don't have 882 00:53:52,800 --> 00:53:55,040 recovery. So that's always dependent on 883 00:53:55,040 --> 00:53:56,520 also what the recovery setup you use. 884 00:53:56,880 --> 00:54:00,880 Obviously if you have a very trusted recovery setup then it 885 00:54:00,880 --> 00:54:03,600 might make sense to have like a 55 out of five if you have this 886 00:54:04,320 --> 00:54:08,640 emergency way to to recover the the account, but without that 887 00:54:09,560 --> 00:54:11,360 have at least like a three out of five. 888 00:54:11,520 --> 00:54:14,520 That's enough for having multiple people cosign. 889 00:54:14,920 --> 00:54:17,880 But that's also allows for some people to not be available at 890 00:54:17,880 --> 00:54:22,960 certain times or also certain keys to be lost and in order to 891 00:54:22,960 --> 00:54:24,720 to create key rotations afterwards. 892 00:54:25,200 --> 00:54:28,320 But then that's just very basic recommendations I would do. 893 00:54:28,480 --> 00:54:31,640 In general it it very much depends on on the specific use 894 00:54:31,640 --> 00:54:34,240 cases and like how many people are involved, like what's the 895 00:54:34,600 --> 00:54:36,600 trust assumptions between these people and so on. 896 00:54:37,520 --> 00:54:38,520 Yeah, that's true. Yeah. 897 00:54:38,520 --> 00:54:41,240 And there's also a kind of catastrophic, you know we we 898 00:54:41,240 --> 00:54:44,600 thought a lot about this this catastrophic scenario where 899 00:54:44,960 --> 00:54:48,160 since the team often travels together, if there was a 900 00:54:48,160 --> 00:54:52,640 catastrophic scenario where we were to all perish, how would 901 00:54:52,840 --> 00:54:55,480 you know heirs or other stakeholders be able to recover 902 00:54:55,480 --> 00:54:59,200 keys in that event. And so we had to think about 903 00:54:59,200 --> 00:55:03,560 safeguards there as well. But yeah it it's I think for a 904 00:55:03,560 --> 00:55:06,640 lot of teams that have set up multi sigs and that are managing 905 00:55:06,640 --> 00:55:10,920 you know significant amounts of capital on on these accounts. 906 00:55:11,040 --> 00:55:14,320 They've probably gone through similar reflections and you know 907 00:55:15,320 --> 00:55:16,760 thinking about the best scenario. 908 00:55:17,320 --> 00:55:21,600 I yeah I I don't think there's a one-size-fits-all solution for 909 00:55:21,600 --> 00:55:25,640 everyone but certainly like you know some best practices here I 910 00:55:25,640 --> 00:55:27,920 think generally would be would be useful. 911 00:55:27,920 --> 00:55:29,960 I don't know if anyone's thinking about these things or 912 00:55:29,960 --> 00:55:32,760 publishing anything about this but I I hadn't found anything 913 00:55:32,760 --> 00:55:37,040 like those very useful for for our for our use case. 914 00:55:37,440 --> 00:55:40,840 I wanted to also talk a little bit about security at Safe. 915 00:55:41,240 --> 00:55:46,360 So you guys recently passed $100 billion in assets secured by the 916 00:55:46,360 --> 00:55:49,000 protocol. I I guess that's that's cross 917 00:55:49,000 --> 00:55:53,960 ecosystem or cross cross EBM chains, that's a lot of 918 00:55:53,960 --> 00:55:56,680 responsibility on on the SAFE team. 919 00:55:57,160 --> 00:56:00,760 And I would argue that if something were to happen, if 920 00:56:00,760 --> 00:56:05,080 there was a bug in the SAFE smart contract that not only the 921 00:56:05,840 --> 00:56:08,920 multi sig holders would suffer but I think the entire ecosystem 922 00:56:08,920 --> 00:56:10,240 would probably suffer quite a bit. 923 00:56:10,600 --> 00:56:12,000 Yeah. What does that evoke for you, 924 00:56:12,040 --> 00:56:14,560 and what does the process look like? 925 00:56:14,560 --> 00:56:18,360 The process of making sure these smart contracts are absolutely 926 00:56:18,360 --> 00:56:23,000 bulletproof? I must say I was more worried in 927 00:56:23,000 --> 00:56:27,520 the early years of safe than I am now because like the the vast 928 00:56:27,520 --> 00:56:30,600 amount of the security comes through its linear effect. 929 00:56:30,800 --> 00:56:33,720 So just having like a lot of value controlled through to 930 00:56:33,720 --> 00:56:38,120 smart accounts over time without there being any issues and 931 00:56:38,520 --> 00:56:42,920 especially with like the safe smart accounts we we don't 932 00:56:42,920 --> 00:56:45,600 update them that often intentionally because every time 933 00:56:45,600 --> 00:56:48,880 you make a change to the to the smart contract that means that 934 00:56:48,880 --> 00:56:51,880 there there could be potentially any kind of risks associated 935 00:56:52,000 --> 00:56:55,920 with that. So we are not kind of adding new 936 00:56:55,920 --> 00:56:59,520 features just to the base contract, but we we allow this 937 00:56:59,520 --> 00:57:03,160 with modules and then there's a different kind of security 938 00:57:03,400 --> 00:57:04,800 assumptions that that's beyond there. 939 00:57:05,040 --> 00:57:09,800 But yeah generally also because it's not just $100 billion worth 940 00:57:09,800 --> 00:57:13,360 of of assets that are secured but also like critical 941 00:57:13,360 --> 00:57:17,720 infrastructure be it like cross chain bridges be it restaking 942 00:57:17,720 --> 00:57:23,000 protocols be it stable coins that can use safe smart accounts 943 00:57:23,200 --> 00:57:26,480 under the hood in order to control certain upgrade 944 00:57:26,480 --> 00:57:28,640 parameters and and so on like it. 945 00:57:28,640 --> 00:57:32,200 It is quite critical that the the safe smart account is is 946 00:57:32,200 --> 00:57:35,920 really bulletproof and for that we invest a lot into security. 947 00:57:36,360 --> 00:57:40,320 We actually invested a lot of us into formal verification. 948 00:57:40,520 --> 00:57:44,480 The the very first major version of the the Safe Smart account 949 00:57:44,480 --> 00:57:48,720 was formally verified over a period of six months of of quite 950 00:57:48,720 --> 00:57:51,440 some time and and financial investments that went into that. 951 00:57:51,760 --> 00:57:55,200 Obviously multiple audits are always part of that having a 952 00:57:55,680 --> 00:57:59,520 back bounty and the community back bounty challenge that is 953 00:57:59,520 --> 00:58:02,880 associated with that and like a big part of security is also 954 00:58:02,880 --> 00:58:08,080 just on like in internal processes and how the culture is 955 00:58:08,080 --> 00:58:10,680 around security in the team and and so on. 956 00:58:10,920 --> 00:58:14,600 But yeah the the key part is is still like the the linear effect 957 00:58:14,600 --> 00:58:18,760 and that's something where I would argue at this point with 958 00:58:19,040 --> 00:58:21,760 that much at stake if there would be any major issue with 959 00:58:21,760 --> 00:58:23,880 the safe smart account, no one could tell. 960 00:58:23,880 --> 00:58:28,040 But like I would assume this would almost be a reason to to 961 00:58:28,040 --> 00:58:31,680 initiate a hard fork. And for me this is also a signal 962 00:58:31,880 --> 00:58:34,880 that if if people assume this would happen at some point it 963 00:58:34,880 --> 00:58:37,760 would make sense to even make certain components of the safe 964 00:58:37,760 --> 00:58:40,720 smart account to be part of the theorem protocol. 965 00:58:40,960 --> 00:58:44,120 So really enshrine that and make make it very explicit and say 966 00:58:44,400 --> 00:58:47,920 like this is logic that we expect to to behave a certain 967 00:58:47,920 --> 00:58:52,320 way and if it if it's not that case then it would be a 968 00:58:53,520 --> 00:58:58,960 consensus issue and to kind of lead automatically to have fix 969 00:58:58,960 --> 00:59:01,880 that or they will be like a back in a client or something rather 970 00:59:01,880 --> 00:59:03,440 than a back in the smart contract. 971 00:59:03,680 --> 00:59:06,320 And I would assume that eventually we will have to to 972 00:59:06,320 --> 00:59:09,680 move towards that if we see that certain parts of the safe smart 973 00:59:09,680 --> 00:59:14,400 contract are really ossified, we don't expect them to to change 974 00:59:14,640 --> 00:59:17,760 much in the future. We should just make them part of 975 00:59:17,760 --> 00:59:21,520 the protocol. Yeah, yeah, I agree that I think 976 00:59:21,520 --> 00:59:25,680 that would also solve a lot of the user experience issues and 977 00:59:25,760 --> 00:59:30,160 and also the, you know, so the gas issues surrounding, you 978 00:59:30,160 --> 00:59:33,400 know, using safe, obviously like on Ethereum main net, like using 979 00:59:33,400 --> 00:59:36,640 safe can be quite expensive and having that enshrined in the 980 00:59:36,640 --> 00:59:38,360 protocol I think would make sense long term. 981 00:59:38,360 --> 00:59:41,120 And also in terms of just adding new features and having smart 982 00:59:41,120 --> 00:59:43,440 contracts, being able to leverage safes, I think there's 983 00:59:43,440 --> 00:59:46,200 like a huge benefit of saying like, OK, this infrastructure 984 00:59:46,200 --> 00:59:50,360 should be enshrined so that most, most new accounts would be 985 00:59:50,360 --> 00:59:54,400 smart accounts, right. And so let's take a step back 986 00:59:54,400 --> 00:59:57,880 here and talk a little bit about the Nosys ecosystem generally. 987 00:59:57,880 --> 01:00:00,080 So obviously like Safe is a huge part of that. 988 01:00:00,080 --> 01:00:03,560 There's also Nosys chain, there's Nosys Pay and you guys 989 01:00:03,560 --> 01:00:07,640 have lots of other products and teams working on all sorts of 990 01:00:07,640 --> 01:00:10,560 infrastructure. How does Safe fit in with all 991 01:00:10,560 --> 01:00:13,000 this? And you know, what's the long 992 01:00:13,000 --> 01:00:15,960 term vision for? I don't know if you can talk 993 01:00:15,960 --> 01:00:20,480 about like Nosys generally, but yeah, the Nosys ecosystem. 994 01:00:21,360 --> 01:00:23,640 I mentioned at the beginning notices originally wanted to do 995 01:00:23,640 --> 01:00:26,720 prediction markets. It was quite early, it was pre 996 01:00:27,240 --> 01:00:31,760 D5 summer and there was a lot of infrastructure missing in order 997 01:00:31,760 --> 01:00:33,320 to even make prediction markets work. 998 01:00:33,880 --> 01:00:37,480 So there was no secure way to serve custody assets, which 999 01:00:37,480 --> 01:00:40,080 prediction markets would create a lot of assets which need to be 1000 01:00:40,120 --> 01:00:43,240 self custody. There was not a good way to 1001 01:00:43,480 --> 01:00:47,800 exchange assets because the prediction markets would create 1002 01:00:47,960 --> 01:00:50,640 different tokens and they need to be exchanged in a in a 1003 01:00:50,640 --> 01:00:52,840 capital efficient way and there's like a bunch of 1004 01:00:52,840 --> 01:00:56,680 different things that were missing and Nosis was basically 1005 01:00:56,680 --> 01:01:02,840 forced to to build these things out themselves and that's how in 1006 01:01:02,840 --> 01:01:06,000 in the end safe was created. That's also how COW swap was 1007 01:01:06,000 --> 01:01:11,960 created over the years and and other things also Nosis became a 1008 01:01:11,960 --> 01:01:14,120 DAO as Nosis Tao. So suddenly there was 1009 01:01:14,120 --> 01:01:19,160 infrastructure needed to really enable have community governance 1010 01:01:19,160 --> 01:01:23,000 over nosy style. So that's where safe Snap was 1011 01:01:23,000 --> 01:01:26,240 created, a way to connect a safe smart account with snapshot 1012 01:01:26,240 --> 01:01:29,920 space in order to have off chain voting but have on chain 1013 01:01:29,920 --> 01:01:32,960 execution. And that's then how the Nosy 1014 01:01:32,960 --> 01:01:38,480 skill team was born as a way, as a team that's optimising on 1015 01:01:38,480 --> 01:01:42,760 building DAO infrastructure. Then Nosy style had the treasury 1016 01:01:42,760 --> 01:01:46,840 which had to be managed and that's where the Kabatki team 1017 01:01:46,840 --> 01:01:50,800 was born, which is now I think the biggest asset manager for 1018 01:01:50,840 --> 01:01:54,560 for Dow treasuries and they they manage Dow treasuries like the 1019 01:01:54,560 --> 01:01:58,880 one from Avatar or ENS like all these were initially internal 1020 01:01:58,880 --> 01:02:01,480 teams but at some point became spin offs. 1021 01:02:02,160 --> 01:02:05,840 But obviously it's it's very much still a close ecosystem. 1022 01:02:05,840 --> 01:02:08,480 So the different teams collaborate quite extensively 1023 01:02:09,120 --> 01:02:13,840 and now like the future for Nosis is very much centred 1024 01:02:13,840 --> 01:02:17,560 around Nosis chain which is another project that was 1025 01:02:17,560 --> 01:02:21,320 actually picked up as XI in the past, which then was rebranded 1026 01:02:21,320 --> 01:02:25,120 to Nosis chain. It's an inside chain to Etherium 1027 01:02:25,120 --> 01:02:29,080 and it allows for horizontal scaling of Etherium block space. 1028 01:02:29,480 --> 01:02:34,680 And on on Nosis chain, there's the the payments network Nosis 1029 01:02:34,680 --> 01:02:39,520 pay being built out which is really the the second focus next 1030 01:02:39,520 --> 01:02:45,160 to Internosis chain itself which is a way to connect defy with 1031 01:02:45,160 --> 01:02:48,000 the traditional financial system. 1032 01:02:48,560 --> 01:02:52,840 Meaning that the idea is that you are able to really have your 1033 01:02:52,840 --> 01:02:57,880 assets on chain but able to spend them off chain and trigger 1034 01:02:57,880 --> 01:03:01,040 bank transfers off chain but then result into on chain 1035 01:03:01,040 --> 01:03:04,200 transactions and really bridge the gaps between those two 1036 01:03:04,200 --> 01:03:06,760 ecosystems. As a first step to hopefully 1037 01:03:06,760 --> 01:03:10,360 then have more and more of the the payment ecosystem actually 1038 01:03:10,360 --> 01:03:14,560 move on chain and not be yeah rooted still in the traditional 1039 01:03:14,560 --> 01:03:18,520 financial systems but then get replaced over time with really 1040 01:03:18,520 --> 01:03:21,760 true untrained systems. So they're also safe plays a 1041 01:03:21,760 --> 01:03:25,800 very critical role in in Nosys Pay as it's the underlying 1042 01:03:26,760 --> 01:03:31,000 account standard for for Nosys pay because something like Nosys 1043 01:03:31,000 --> 01:03:33,600 pay actually needs smart accounts in order to work 1044 01:03:34,000 --> 01:03:37,680 because it's it is meant to be like self custodial account 1045 01:03:37,680 --> 01:03:42,120 which then still allows you to have like a card like a 1046 01:03:42,640 --> 01:03:45,080 traditional Visa card associated with it which you can use to 1047 01:03:45,080 --> 01:03:47,960 spend off chain. And in order to bridge these 1048 01:03:47,960 --> 01:03:52,120 assets off chain you need to have a way that they can be 1049 01:03:52,200 --> 01:03:55,360 taken from the account and then put into the Visa network. 1050 01:03:55,760 --> 01:04:00,160 But still you don't want to just give like unlimited access of 1051 01:04:00,160 --> 01:04:03,480 your of your assets to some to the Nosys pay network there but 1052 01:04:03,480 --> 01:04:06,200 they actually want to limit that and that's that requires smart 1053 01:04:06,200 --> 01:04:10,720 accounts so that every Nosys card actually is associated with 1054 01:04:10,720 --> 01:04:14,960 a safe smart account which has like a yeah a daily limit 1055 01:04:14,960 --> 01:04:18,760 associated with that where any transactions that are below this 1056 01:04:18,760 --> 01:04:23,000 daily limit can be put into the the Noses pay network and and be 1057 01:04:23,000 --> 01:04:24,960 used to to pay at the merchant store. 1058 01:04:25,400 --> 01:04:31,160 But it's it's in a way that it's still the vast majority of your 1059 01:04:31,160 --> 01:04:35,840 assets are self custodial and it's just yeah this daily limit 1060 01:04:35,840 --> 01:04:39,360 that you get then give. And yeah the the long term 1061 01:04:39,360 --> 01:04:43,600 vision is really that Nosys is focusing on on building out like 1062 01:04:43,600 --> 01:04:47,120 this decentralized payment network that then leverages 1063 01:04:47,120 --> 01:04:51,800 things like safe leverages things like cow swap for for 1064 01:04:52,000 --> 01:04:55,400 exchange of assets and and other parts of the Nos Eco system. 1065 01:04:55,640 --> 01:04:58,680 That becomes really this combination of of the different 1066 01:04:58,880 --> 01:05:01,840 infrastructure that was built over the last years and builds 1067 01:05:01,840 --> 01:05:05,440 really something that can then bring as as much as possible of 1068 01:05:05,440 --> 01:05:08,200 of today's payment volume on chain. 1069 01:05:09,480 --> 01:05:11,280 Great. Well, Lucas, thanks so much for 1070 01:05:11,280 --> 01:05:13,920 coming on the podcast today. It's been great learning about 1071 01:05:13,920 --> 01:05:19,760 SAFE, understanding the the technical implementation of SAFE 1072 01:05:19,760 --> 01:05:23,640 and also how it fits into the broader Nosys ecosystem. 1073 01:05:24,080 --> 01:05:26,560 So thanks so much for coming on and look forward to having you 1074 01:05:26,560 --> 01:05:29,240 back on the future. Yeah, it was a pleasure. 1075 01:05:31,440 --> 01:05:33,200 Thank you for joining us on this week's episode. 1076 01:05:33,560 --> 01:05:35,120 We release new episodes every week. 1077 01:05:35,800 --> 01:05:38,560 You can find and subscribe to the show on iTunes, Spotify, 1078 01:05:38,600 --> 01:05:41,600 YouTube, SoundCloud, or wherever you listen to podcasts. 1079 01:05:42,040 --> 01:05:44,760 And if you have a Google Home or Alexa device, you can tell it. 1080 01:05:44,760 --> 01:05:47,840 To listen to the latest episode of the Epicenter podcast, go to 1081 01:05:47,840 --> 01:05:50,960 epicenter.tv/subscribe for a full list of places where you 1082 01:05:50,960 --> 01:05:53,200 can watch and listen. And while you're there, be sure 1083 01:05:53,200 --> 01:05:55,680 to sign up for the newsletter so you get new episodes in your 1084 01:05:55,680 --> 01:05:58,760 inbox as they're released. If you want to interact with us 1085 01:05:59,080 --> 01:06:01,480 guests or other podcast listeners, you can follow us on 1086 01:06:01,480 --> 01:06:03,360 Twitter. And please leave us a review on 1087 01:06:03,360 --> 01:06:05,000 iTunes. It helps people find the show 1088 01:06:05,240 --> 01:06:06,360 and we're always, I'm happy to read them. 1089 01:06:07,160 --> 01:06:09,720 So thanks so much and we look forward to being back next week.