t1 Protocol: Unifying Ethereum's L2 Liquidity Through Real-Time Proving - Can Kisagun. Ep. 605

Transcript

a rollup or like a state machine that's running inside a trusted execution environment and over time we decentralize this and make it permissionless. The idea is the TE's provide real-time proving and the rollup itself provides programmability. It would be very cool to have a rollup that would settle instantly back on the L1 such that you know like we could have a like this fast and cheap execution environment that is for L1 assets with the T the proving is instant because I mean obviously it's a different trust assumption right however as we're running the runtime inside the trust execution environment we can create an attestation from the TE and prove to you

know whatever platform that we want this This is the this is the execution that took place instantly. When you enhance this proving capability with actual programmability, you unlock a lot of cool use cases and applications that just pure proving does not give you. And this way you can, you know, go towards being more of a hub rather than just like a proving network if that makes sense. Welcome to epicenter the show which talks about the technologies projects and people driving decentralization in the blockchain revolution. I am Frederick Ans and today I'm speaking with Chan Kisagun who is the CEO and co-founder of T1 a real time proving roll up that tries to eliminate

fragmentation in Ethereum. Before the interview I'd like to tell you about our sponsors this week. If you're looking to stake your crypto with confidence look no further than Chorus 1. More than 150,000 delegators, including institutions like BitGo, Panta Capital, and Ledger Trust Cororus One with their assets. They support over 50 blockchains and are leaders in governance or networks like Cosmos, ensuring your stake is responsibly managed. Thanks to their advanced me research, you can also enjoy the highest staking rewards. You can stake directly from your preferred wallet, set up a white label node, restake your assets on Igen layer or symbiotic, or use the SDK for multi-chain staking in your app. Learn more at chorus.1 and start staking

today. This episode is proudly brought to you by Nosis, a collective dedicated to advancing a decentralized future. Nosis leads innovation with circles, Nosis Pay, and Metri. Reshaping open banking and money. With Hashi and Nosis VPN, they're building a more resilient privacy focused internet. If you're looking for an L1 to launch your project, Nosis Chain offers the same development environment as Ethereum with lower transaction fees. It's supported by over 200,000 validators, making Nosis Chain a reliable and credibly neutral foundation for your applications. Nosis DAO drives Nosis governance where every voice matters. Join the Nosis community

in the Nosis DAO forum today. Deploy on the EVM compatible Nosis chain or secure the network with just one GNO and affordable hardware. Start your decentralization journey today at nosis.io. Welcome to the podcast, John. It's a pleasure to have you. Hi, Fred. It's a pleasure to be on. Super nice. Maybe before we kind of talk about T1 and um uh what kind of problem you're trying to solve, which actually ties in really nicely with um the previous episode um that we did on um Ethereum recently with um Tomas and um Shawei. Um maybe let's talk about you for just a little bit. Um

so you're here to talk about T1, but before T1 you did um Enigma. Um, tell us about that. Yeah, so um I got into the space in 2015. At the time I was a grad student at MIT and um read the Bitcoin white paper, got really hooked into it and even though I was uh in the business school, I was like, "Okay, let me learn as much as I can." And that was my first introduction through the Bitcoin club there. Um and then um um a friend from those that circle um had this research paper called Enigma.

Um after graduation I joined him as a co-founder um in 2017 and um yeah our goal was to bring smart contract privacy to Ethereum using multipation. we were looking to be like a layer 2 back in the day when uh these things didn't really exist. Um fast forward a while, we pivoted into using trusted execution environments. At the time there is only intell as early as 2018 because we realized in a permissionless and adversarial setting NPC has some problems mainly being if people colludes uh off off

chain uh there's no way to detect it and and therefore punish people or slash people. Um so we worked on you know with TE's for a while. Around 2020 we pivoted our naming and our tech stack. We became a Cosmos SDKbased layer 1. Uh renamed to Secret Network. We launched private smart contracts back in September 2020. At the time we were the only smart contracting platform on Cosmos Land after Terra. uh we all know how that went and yeah we introduced primitives like uh privacy preserving tokens like private ERC20s

um private AMMs uh and and really tried to build a a privacy first DeFi ecosystem. Um I during my time there um which was until like late 21 I um led most of the fundraising efforts, product direction, uh business development and ecosystem growth efforts and um and yeah like towards the end of 21 I um I decided it was time to you know step down of that journey. Um took some time off. I was quite burned out and um eventually got back into the building modes. Um at the time, Flashbots have

made a lot of cool work with trusted execution environments and EVMS. And from my days at secret, one of the big things for me was I wanted to be close to the Ethereum ecosystem. Um and we were we were not. So I was very interested um through talking to like te uh gurus like Andrea Miller. I was like okay let me look into this flash things a bit more. I did a research project with them uh mostly exploring the application design space with TE's and and you know and Ethereum um and then considered building with flashbots for a while but but then they were really

focused on block building and what I wanted to do was was different and that kind of how that's kind of how T1 got started. So, Enigma or later the secret network kind of like you started off as kind of like trying to build this network on top of Ethereum and then move to Cosmos. So, kind of like while there were, you know, quite a number of projects that kind of moved that way, what precipitated that move for you guys and why what was it that kind of pulled you back in the end?

Well, I mean to be quite frank, we were focusing on building a privacy platform and um in the beginning we're trying to solve two problems. One was the privacy or private execution component and the other one was uh like consensus components cuz back in 2017 like nothing came out of the box. You could just like fork Ethereum and there were like a ton of projects that did that. But I want to say around like early 2020, Cosmos SDK or Tenderment SDK um was uh robust enough. Um at the time um I'm blinking on the name. Polka dots was

coming up with their, you know, own architecture and and we decided to focus on not rebuilding the whole consensus framework uh from scratch uh which you know um we tried and and that resulted in a lot of tech debt and we wanted to get to market fast and and build something that worked. So then we we decided like let's just like take this thing that works and and then uh you know run smart contracts um inside tees where we could use the like the the Cosmos SDK for the layer one consensus and do the computations inside tees.

Okay. Yeah. No, that that makes sense. after your break, you kind of came back to Ethereum and you found um things somewhat lacking. So, what um problem uh are you looking to solve with um T1? Now when I was getting back into things, one thing that really bothered me was I had to go to centralized exchanges to trade because when you are selling large quantities, the difference in execution like is significant. So I was like I've been building in this space since what like four seven eight years now and like

I should not be trading uh on a centralized exchange and then withdraw my f funds back instantly right and thinking about like why this is a problem. I like got into the DEX realm, the DEX problems, all that stuff. And to me, the solution was we need something that is cheap and fast in terms of execution, but is not fully removed from L1 assets, which is where DeFi takes place, right? You can have cheap and fast uh AMMs on rollups, but because the liquidity is lacking, like you know, it just like doesn't make too much sense.

And that was my first let's say uh hint uh that you know it would be very cool to have a rollup that would settle instantly back on the L1 such that you know like we could have a like this fast and cheap execution environment that is for L1 assets. uh that's how uh I started thinking about like what I should be working on or what what problem I should be solving and then quickly I realized you know this is not just a DEX thing this applies to the broader DeFi ecosystem and like going down that rabbit hole it also became clear to me that like hey okay um this is cool however we also have already

like you know tens of rollups that are out there and the cat is out of the bag if you know if that makes sense. And and like why don't we have a solution that kind of like abstracts like what platform you're running on but focuses on the application experience. Like the example I I give is if I'm taking an Uber to go from A to B, like I don't care where the Uber is running. I just care to go to my destination. And and I think that's what crypto is lacking today. And that's kind of what we want to bring back.

Okay. So maybe if I kind of repackage this a little bit. So kind of if you look at um the liquidity um in the Ethereum ecosystem today kind of depending on kind of like what you're looking to do kind of you'll do it on uh base or arbitum or or elsewhere. Um and then kind of you you might want to do something else. So you kind of need to bridge your assets kind of like from arbitum to base and or the other way around which will take a long time right. So kind of you still you you have this um fragmented liquidity in a way and often kind of um the solution to fragmentation is kind of having some

sort of standard in terms of kind of like how does message passing work? like how how how do you kind of um how do you communicate um more or less synchronously between the different rollups right um but then kind of like when you look at standards I mean I'm sure you know kind of like this this old engineering joke right so when you have 14 competing standards someone says let's make universal one and unify them all and then you have 15 standards right so how how do you go about that let me put it this way. We're taking a very pragmatic approach and we're not in the business of creating necessarily

standards. We follow what the um EF um like L2 interact working groups are working on. However, one thing that's important for us is everything we built needs to be fully permissions. And what I mean by that is like if we look at the journey of like you know solving fragmentation on Ethereum over the past 2 years um you know people were really excited about shared sequencing and shared sequencing requires rollups to you know participate or like you know forgo their centralized sequences therefore their sequencing revenues and participate in this shared sequencing uh construct.

And while that sounds excellent on paper, it did not pick off or it didn't work because the incentives did not align. So, you know, all of the shared sequencing companies over the years have pivoted one by one. What we're saying is we can build an infrastructure uh and uh have this infrastructure enable crosschain interactions, user experiences, whatever you name it without the buying of a single roll rollup or without the buying of a single application. Obviously, if these like you know stakeholders buy into it, it's more robust. But we are focused on like I am a D5 user. I suffer from this

problem on a daily basis. I'm interested in making the lives of people like me and myself better without like dealing or yeah without you know burning down in these like bureaucracy BD circles if that makes sense and I'm happy to unpack what that means. Yes, I think you'll have to. So um I'm I'm a little confused here. So kind of if you look at T1 is is this kind of is this primarily a rollup in its own right or is it primarily kind of an interoperability solution?

So what we have is we have a um a rollup or like a state machine that's running inside a trusted execution environment. Um at first and over time we decentralize this and make it permissionless. Um the idea is the TE's provide real-time proving and the rollout itself provides programmability. This is in a way different because you know a lot of companies are let's say doing zero knowledge proving however they do not focus on programmability.

They just focus on proving something that happened on A to B. However, when you enhance this proving capability with actual programmability, then you you unlock a lot of cool use cases and applications that just pure proving does not give you. And this way you can, you know, go towards being more of a hub rather than just like a proving network if that makes sense. Okay. I think you'll have to kind of um give us an example here. So kind of what kind of thing can't you prove um kind of um just via um ZK but can kind of address with um and with a TE. Yeah. So like um for

example, yeah, let's just like talk through use cases and maybe that's easier. Um intent bridging is huge today, right? This is the also EF's preferred solution to short-term interrupt uh across uh who you know we uh are in close conversations these days is using their optimistic oracle to prove um or let's take a step back. Let's let's rewind a bit. How does intent bridging work? Uh let's say you want to go from an origin chain to destination chain. You lock your tokens in the origin chain.

um some market maker or solver who sees that you've locked your tokens send you the funds you want to receive on the destination chain. Then there's a process of proving that this solver paid you step took place and once this happens then the solver can withdraw the funds that you escroed on the origin chain. Right? So this there's a proving stage in the middle. Uh there are different ways you can prove this like you know across the most popular bridge use their optimistic oracles it takes 60 minutes you know you can do like a multise proving which is like you know really trusted um you can do as your knowledge proving which would take you know on the order

of minutes and we can do this proving with te that would take like you know on the order of seconds now uh proving that the solver paid you and then therefore allowing the solver to unlock your funds is just you know passing proofs. Um another thing you can do uh while you have proving and also smart contract smart contracting capability is uh like this is a completely different use case that we're very interested in. Um and like the use case is crosschain vaults like today we love uh earning yields via vaults in a single chain. Walts allow us to get the highest yield for a token

that we're holding, right? That's like what's uh why earn kind of like um uh started back in 202021. Um let's consider this scenario. Let's say you have USDC on a on optimism. From a risk perspective, there's no difference realistically having your USDC on either optimism, arbitrum or base. And the yields between these uh rollups or a USDC yields between these rollups vary a lot. Um and you know no one bothers with this because the the user experience of you know manually tracking the yields and then when you

know different rollup gives you higher yields withdrawing from the original one then going to a bridge then bridging then waiting for the funds to arrive and then deposit is so painful that no one does it right. And when we have not only proving but also programmability what we can do is we can create logic let's say like an individual vault for you which you know chooses which yield protocols you are okay with and which rollups you want to have exposure to such that we can monitor in an automated way inside a T1 state machine where your funds should be based on the yield and and reshuffle

your funds in a in a completely non-custodial and an automated way. And this requires programmability. This is not something you can do just by passing proofs. Okay. I mean, in principle, I could set up um a um a vault on Ethereum mainet that kind of looks at all of these different yield opportunities on the varying L2s and kind of withdraws and deposits automatically, right? I don't see why in principle that's that that is I shouldn't be able to program that, right? No, but but Ethereum cannot read

uh the yield on base or arbitrum. So I would kind of so the the the thing is kind of like I would need some sort of uh oracle, right? And these exist, right? Yes, you would need some sort of oracle. But also how do you um like move your funds from your EOA on Ethereum to a on base uh with uh you know in an automated and non-custodial way like that doesn't exist. But if you have a if you have a smart contract wallet, it could exist, right? because you can kind of row these transactions together and well you can with a smart contract wallet allow someone to deposit your

funds to the base bridge contracts uh and then once your funds are on base yeah then you need another wallet to kind of handle it on that side. Okay. Okay. I think I'm beginning to understand yet understand now. So um kind of the tagline of T1 is that kind of like you you um do real time proving right? Um so how much does that differ from other systems? So how um how long would it take on a different system to kind of do the same thing? Sure. So I think there are uh some metrics on uh eat proofs.org or on um how long it takes to prove um an L1 block and I

think it's currently on the order of like singledigit minutes of I I want to say fiveish I'm not fully sure uh with the t the proving is instant because I mean obviously it's a different trust assumption right so uh we're fully acknowledging that however as we're running the the you know the the runtime inside the trust execution environment we can create an attestation from the TE as this you know as computation is run and and prove um to uh you know whatever platform that we want this is the this is the execution that took place instantly.

Okay. But you still need something kind of akin to a sequencer or literally a sequencer right? It it really depends. Um you if you want to run a smart contracting platform like we want to do, yes, we need a sequencer and you know if uh you were like alluding to oracles uh like you know if you just want to have an oracle uh uh network then then not necessarily but yeah in our case there's a sequencer.

Okay. So, um, can you can you walk me through the sequencer setup and how it works inside the TE? So, I'll start with like what's coming up uh short term and then what the long-term vision is. We have uh both me and my co-founder or um his background is scroll um so he knows the ZK rollup land really well. We have this, I guess, guiding principle that we want to be very pragmatic with what we're building and we want to be solving problems that exist today. And as a result, our first stab at T1 is a is akin to a centralized sequencer that we have today in the

market, but the centralized sequencer is running inside a trusted execution environment. Um what we do differently um than other rollups is T's are already like you know beefy um uh node infrastructure. So we run inside our trusted execution environment um full nodes of partner rollups or what we call partner roll-ups. So imagine a full nodes of full node of base a full node of arbitrum. This allows us to read from those rollups in addition to reading from Ethereum aggregate their states on T1 and and prove the aggregate states on uh on L1. So that's how we're

we're we're reading um let's say the state of other rollups or or Ethereum included in the same node infrastructure. So it's the same trust assumptions uh versus having like a smart contract based uh oracle if if that makes sense. Um um so uh so that's like a V1 uh basically a user can send a transaction uh to T1 uh the T1 sequencer like you know uh base or optimism or arbitum sequencer um sequences these transactions executes them and the results can be um you know um T1 state updates and uh We can have

withdrawal requests go back to L1 or we have at least what we call proof of reads. Um this is basically uh you know uh more like an oracle call like saying like hey this like um happened this like let's say market maker Phil happened on base uh in going back to like this intent bridging kind of scenario if that makes sense. Um and uh and update the states. So that's how our system works. So we have uh the differences to recap is we run our sequencer uh inside a TE and we have full notes of other rollups and we have deposit contracts not only on Ethereum

like the current rollups do but also on other uh on other um rollups as and we can accept deposits from other roll-ups as well. Okay. how how do you deal with the fact that um the other rollups are not necessarily finalized, right? So, kind of like they are only finalized kind of like once they've been committed to L1 um or kind of they've been kind of proven. So, kind of like in the kind of like for for an optimistic rollup who kind of do you guys absorb the risk or how how does this work kind of in terms of trust assumptions? Yes. So um great question. um we when we look at uh

data on like um let's say arbitrum reorgs I want to say in the last four years arbitrum reorg less than 20 times uh and these reorgs are usually like one two block heights which for arbitum is less than 2 seconds right so we think uh or our approach is this is an insurance problem like you know in real world we have insurance against these HK cases and there's no reason why we cannot uh treat these situations um like um you know like an insurance on T1 as well. we can have different parameters for different rollups as to when they finalize.

But yeah, like um the the the short answer is yeah, we we parameterize that risk based on historical um reor uh potential and and and kind of absorb that risk to give users better UX. Okay. Uh yeah, that's that's super interesting to hear. So kind of like if you look at the spectrum of L2s kind of the um security models vary a lot right so kind of it's kind of the question kind of like how is it architected in the first place um h how do they go about um data availability how often do they commit to L1 do they have do they have fraud proofs um do they do they

even post um data to L1 or are they um validium and then you kind of have these uh these sovereign rollups that aren't really rollups at all, but that kind of like that never kind of check in with Ethereum. So, kind of um do you um do you kind of do the risk underwriting for all of these by yourself? So, or if I kind of want to bridge to um a rollup that you don't have that you you haven't done this for, I'm I'm out of luck, right? So, kind of say I because in principle I can set up a rollup tomorrow. um how do I get integrated into T1? Uh sure. So to be very honest like right now we're looking at base

arbitum. We have a a base full node that's running inside our node infrastructure in our like DevNet environments. We're adding an arbitum one. I uh our focus in the short term will be uh optimistic roll-ups and and most likely OP stack plus arbitum. Um okay we are not interested in validiums in in the short term and with the optimistic rollups like our our thinking is um as soon as the blobs go into the L1 and they're finalized because of the current trusted sequencer assumption or

like the the world we live in we can deem things finalized. So the the in-flight risk for T1 is, you know, let's say the 2 minutes for optimism to post the blob and then the 13 minutes for L1 to finalize. We think this is only going to get better with like, you know, the three slots finality discussions that we have on Ethereum and um and and all that. Uh but we don't have uh like we haven't looked into how to deal with validiums now at this point. We already think that there's a big enough market just to go after actual like you know rollups and you already alluded to the fact that kind of like while right now kind of

you're running in a single trusted execution environment you will increase the number of trusted execution environments in due time and will this ever become fully permissionless? So can can I run a trusted execution environment for you guys? That's the goal and uh as I mentioned like um our goal is to like we have identified a couple of use cases uh you know like some of these I alluded to earlier on um that make the lives of existing users and existing crossian applications significantly better. Our goal is to prove in a trust minimized by tees in a trust minimized setup that

these actually make sense and people want to use them. um and only then uh you know embark in this journey of getting things fully permissionless because it is a lot of money it is a lot of effort and I think uh and having been in the space for a while I don't want to build something that like you know is cool but like no one uses right so um the goal is to get there but the goal is to first prove that what we're you building um you know has actual demand Um and we also have to like you know introduce additional um let's say defense and depth uh measures as we go fully permissionless

uh because in the early days like you know e either a foundation runs a te or like you know a set of trusted actors run the te and uh the the main attack vector with te's is uh is physical access um and um you know we can trust that uh these entities are not going to you know physically break into like I I think people if when people can prove that they're running their TE's in cloud like a Google cloud kind of environment uh it's very um I would almost assume it's unrealistic to break into the the TE um but like when things are

permissionless uh this was especially a problem with the earlier generation of TE's SGX which you could run in your like Lenovo laptop uh but physical attack becomes possible. So when we make things permissionless we have to introduce additional defense in depth measures to ensure that our system is still robust. But then kind of like you're forcing people to kind of rely on cloud infrastructure providers and kind of like we've seen them kind of um uh revolt to people running nodes right so for instance Hznner has deplatformed everyone running nodes on the infra

infrastructure yeah I mean I'm not aware of that um um infrastructure company and at the like the the reality is in the long term we don't have to yet. These like new uh let's say generation trust exection environments are like not your computers. So even if you buy the bare metals um and and and you you run it like you know in your own data server um it is uh like it's not going to be the Ethereum vision of like you know let's verify with our Raspberry Pies. So um and and the the only reason why we have to add additional defense and depth uh

measures is because when we make it permissionless we don't have to uh limit it into into cloud but in the early days when it's like let's say a foundation running it there's already some trust uh assumed and and the and and that that trust could be further I guess um limited by or like strengthened by running things uh let's say in Google cloud and and like you know ensuring that we're not going to have physical access to it. Yeah. Um so there's a number of attack vectors here, right? So kind of like there could be the TE could be um compromised or kind of like there could be some sort of back door that

kind of lets people access the trusted execution um environment. you could also kind of um run modified software, right, instead of the software you're meant to run. Um is is there a way of proving that you're actually that you're actually running the right software? Yeah, I think that's called like reproducibility. And the whole idea uh with the TE's is um you when you're setting your environment up, you attest to the bite code that's running inside the T and you create a signature. Um that signature is what's attesting to the bite code you're running. And every

time you do a computation, you also create uh an ECDSA signature. And the idea is the the the signatures you are creating on the go as you're running new computations should be matching the initial signature that you've created and you've attested to. This is uh this process is called remote attestation. And that's how you make sure that you're running the same software in an in like a non-tempered way if that makes sense. Yeah, that that makes complete sense.

And then kind of the other attack vector would be kind of like the trusted execution environment itself kind of not I mean being broken in a way that kind of like it's no longer trusted right so for instance if you were to kind of break Intel SGX um and kind of I could read kind of like the the actual computation happening in there you'd be compro compromised right that is true um I think there is an attack vector where um there are two attack vectors. One is physical access as you're as you're describing and one is around access pattern leakage that's a problem that happened with secret network and um as far as I'm aware the latter is more

for um privacy uh or like leaking private data and then um yeah so those are like two two possible attack vectors. Okay. Do do you kind of see trusted execution environments as a temporary bridge? Um or do you think kind of like this is this will be so baked into the system that kind of you can no longer replace it replace it with a different um mode of proving. The way I I see it is you can use whatever method you want to use. The important thing is how fast can you prove things and what that means for the users who are you know using your system or these crosschain application uh you

know um interfaces. The reality is we care about proving fast because it gives the superior user experience. I am not like you know necessarily tied to trusted execution environments but the reality is we do not believe for the next 3 years uh there's nothing like like there is you know interest that real time zero knowledge proving is going to be fast but um I believe otherwise and I'm happy to get into why that's my that's my belief uh t's are not going to be um removed from the equation for another 3 years. So we we

lean in very heavily into them and and when we want to strengthen TE's with defense and depth we basically go with the idea is how can we keep things fast and and how can we make things safe. So just like one uh for us like the the midterm solution is when we make T's permissionless we require some u consensus to be reached uh among TE nodes. This is also what secret did. Um, and this would allow us to also go very fast. And in the event that there is a single TE that is misbehaving, we can

attribute that misbeh misbehavior and we could slash uh the the stake even if there's a single honest tea actor, right? uh and to us this bake with tees when things become permissionless is a a more sustainable path to going allowing real-time proving than going something with zero knowledge proving. Um and then in our architecture like you know there's always this like attack vector if attacking a proof of system proof ofstake system is more profitable than the stake itself. Yeah. you know, you will attack it. And for us, this like

the the the real attack vector for a network like T1 is when there are withdrawals, right? If the withdrawal amount is larger than the value at stake, it could be a single withdrawal or it could be cumulative withdrawals, then you are at the risk of um you know being I guess like rockpulled or breached, whatever you call it. Um so what we do or what we want to do in the future is we want to have this uh bespoke or periodic zonowledge proof generation model where we create these your knowledge proofs not say every block or not say like every x time um but based on the cumulative

withdrawals from the system let's say we have a billion dollars of economic security when we have let's uh I don't know 200 millions of withdrawals. We can create as your knowledge proof and we can verify that all those withdrawals up until that point were valid. If they're not, we can slash the system and we can make sure whoever cheated gets their money or like you know is um or like let's say the the amount that's stolen is is recompensated to the stake and that way like zero out our budget and then go again and and and again and this would be a way to uh keep things cheap because you know like zero knowledge proving even though the cost is coming down it's never going to be as cheap as

a hardware thing and um and fast and and permissionless in the short run and and we think this is like we've seen in the market that users care about cost, right? Um we who have been in in crypto or in the blockchain space since 2017 like we have very high ideals and you know we should strive for those ideals. I think it's also important to realize the newcomers have a different set of priorities and if we miss those users then then we have the risk of like missing this like okay let's take this to a billion users

narrative. Yeah. No, I I totally follow. But I also kind of got from your answer that kind of like while you think of TES as um crucial right now kind of like if in say five years time you had a much much faster ZK proving um framework you you would be happy to kind of switch over to something less trusted. Right. Exactly. We don't care about like you know how uh we achieve something. We don't we care about what we achieve and why achieving that is meaningful. So yeah you know uh if in 5 years zero knowledge proving is

real time then of course like we have no um yeah like you know I'm not uh married to te's in that sense. So um do you use one type of TE or kind of like in principle you could make the system um much more secure by using different kinds of TE because then kind of whenever kind of like one kind of has kind of like a zero day or whatever kind of like you you could still fall back on the uncorrupted nodes kind of just like we have um different um uh clients, right?

Exactly. Yes. In the short term, we will use a single TE because that allows us to go to m market faster and solve user problems faster. In the long term, yes, that's something that we're looking into. And um also, I think there I think there's a misconception on this front which I believe is important. If a lot of people talk about multi- vendor solutions as a solution to the whole thing. Uh however like a multi- vendor solution still requires trust on a single entity to be running the whole thing. Um when you do have uh let's say like you know as in our future or

long-term vision when you do have different nodes uh you know uh execute and form consensus then you don't care whether it's a single uh vendor or a multi- vendor you because you already are verifying the computations via some sort of um you know some sort of like re-execution I think multi- vendor people, you know, use that in like a in environments where again there's trust in a single party, but they're like like layers of defense and and we want to remove trust from a single party

first then adding like you know layered trust to to the single party environment if that makes sense. Yeah, that makes sense. Maybe let's talk about one more thing kind of like before we talk about kind of like the ecosystem and kind of like what it looks like for you guys right now. Um so initially kind of like for Ethereum the idea was that all um assets would be issued on L1 and then kind of they could be acted upon kind of on rollups but kind of um in order for them in order for you as a user to kind of be able to kind of um force an exit to L1 um you need assets that are natively issued on L1 right so kind of

like if you have an NFT key that's um natively minted on base, you have no recourse, right? So, how do you see that kind of in terms of um T1's um security promises? I think all assets should be issued on L1 if you know we want to say that they inherit the security of Ethereum. Um and at the same time you know this is a like an asset issuer and user uh relationship and decision. I you know I don't hold any assets that are not issued on L1 if that um kind of like makes my stance uh

kind of like somewhat clear and at the same time like you know I don't feel it's right for someone to you know if there is an asset issuer on T1 like I don't think it's right for us to say no your assets can't be issued in L1 um I think they have the responsibility to to communicate to their users or holders what risk that they're taking but at the end of the day it's like it's I don't think it's it's our business to dictate that. Okay. Um so 41 what's live today? So today we have a devet that uh entails a a custom like rust environment uh runtime that's running

inside TE uh and then uh inside T we also have an L1 node and a relayer and what we're doing is we basically can deploy any applications any EVM applications on the rollup um And we can prove the rollup state back to Sephogia. So you can imagine like you know you can do things like you can start from Sepholia the L1 test net deposit funds to T1 you can do um you can use AMMs or applications on T1 and you can exit back to or withdraw your funds back to the L1 in the next L1 block. So within like uh we're talking

on the order of seconds um you can deploy your own applications to this kind of setting. We also are using the setting to show how we can do in the intent example I just uh shared earlier in this in this podcast. We can allow we can prove faster repayments based on the ERC7683 standard. we can prove that a solver uh paid the user, therefore allowed the solver to get repaid faster. This is really attractive for them because when they're getting repaid faster, they can meet the same user demand with with much with much less capital and therefore be more profitable. The solvers that we're

talking to tell us like time and time again if they are getting repaid faster, they're going to offer better rates for for the for the users. So right so we can show that and we also have like you know again leveraging solvers we can allow someone on L1 to swap against liquidity on T1 without seeing T1 exist in the background. Um so that's kind of like what we have today. Um, we are aiming to go to a mainet in Q3 this year, late Q3 realistically, with a a let's say a mini version of of what we have today that is optimized for proving these

crosschain reads to serve this ERC7683 or intentbased bridging and crosschain uh ideas. uh because again you know we can make this cheaper for users, we can make the system more profitable for market makers. It is you know a way to make both the demand side and supply side better off. So so so we're building that uh to be ready for production. We're aiming to integrate that with you know existing bridge providers um to allow better user experience. And then um in Q1 of next year we want to become this like fully permissionless

rollup that you can deploy whatever app you want on mainet. We have that today on a devet version but like we are taking an intermediate step in terms of going to mainet and then and then we go for the full rollup vision. But you're targeting other protocols and applications, right? Kind of like I as an end user would never interface with T1 directly. Yes. And to be uh very honest like we can build some of these use cases inhouse just to like you know the prove to you know the dogs will eat the dog food kind of situation. Um but yeah

ideal um ideal strategy for us is to make existing protocols let's say like across better off with real time proving and then programmability uh in in a phased approach h how easy is it for protocols like across to kind of integrate T1 what we are going to be allowing in our initial um let's say mainet that's coming out this or Q3 is to allow anyone to call T1 to prove um you know a something happened on a different rollup. So in this in this scenario, you know, across

uh for example could from their um origin chain um get this um proof of phil um from T1 that shows that hey solver A uh you know paid your user on the destination chain and therefore allow to solver to get repaid faster. This would be basically like just a smart contract uh upgrade on their behalf to recognize uh the proof that we're we're already providing to to their base chain. So they wouldn't need to necessarily touch T1 in any way.

Okay. Do you incentivize partnerships? So kind of like uh kind of in terms of interoperability kind of like there are a number of ideas and solutions out there and kind of it's it's um as so often it is um a coordination game right so kind of you you need everyone in the same boat or you know you need a significant number of players in the same boat. How how do you um how do you get critical mass?

Yeah, I mean our goal is the incentive is we make um cheaper transactions or we enable cheaper transactions for existing bridge users. We believe this is a significant uh incentive and you know we can we have uh market makers and solvers in our network who are for example incentivized by getting repaid faster um and you know tell us that they would be willing to provide liquidity on a bridge that we built. Now we we don't want to maintain a bridge necessarily but if no one you know if people are not convinced by

faster cheaper payments for their users which we believe is a good good enough incentive then you know maybe we put it out there and see how our bridges getting used and see like you know whether aggregators like the alchemies and third webs of this world are willing to offer this solution because it is providing paying cheaper fees and and seeing that direction. I we're we're not meaningful enough to, you know, offer grants to people who are like 10 times our size. We just want to organically provide something to them. Cool. Yeah.

Let's hope that works. So maybe let's kind of like zoom a little bit further out. Um so um you could argue that Solana has solved the user experience problem that that you guys are tackling um at least within kind of you know a single ecosystem and it's very much kind of pulling ahead in terms of um user activity and um uh and uh at significantly lower cost than Ethereum. Why double down on on Ethereum in this context?

Great question. Um I would argue that you know Solana will have the problems Ethereum is having today. Um you know we are seeing rollups on Solana or ideas of rollups on Solana. So I think this is a problem that that we're going to you know see uh in the Solana land as well. Why Ethereum? because I believe Ethereum um values of like censorship resistance and verifiability are uh things that resonate with us. Um the fact that uh you know like Ethereum is truly unstoppable um is is important uh to us because

you know if we're building a a new open finance this open finance platform cannot and I don't mean to like you know um criticize anyone necessarily but this open finance cannot go down when we have um you you know, uh, a memecoin launch like Ethereum had those issues with the ICOs. That was back in 2017. The network would get congested and things would not work. But today, Ethereum works and Ethereum would work in the in the edge case that you mentioned, what if all the data centers the platform validated, Ethereum would still work. Uh we think Ethereum is captures the the values and the ethos that got people like me

excited back in the day and with the white with with the Bitcoin white paper and that's why we're building on Ethereum. That's uh yeah that's that's a very heartening answer. Um so people like you kind of have it a little bit difficult in our ecosystem right because kind of people who kind of value um this kind of ethos they are typically critical of tees and reliance on tees. What what do you think um is the one thing that people in our space kind of um get wrong about trusted execution environments?

I would argue it's not about trust execution environments but like uh it's a criticism to to like you know Ethereum community um at you know to to some extent I don't think we have and maybe like you know the new EFDX direction is a is an improvement uh or like you know it's a it's a change from this we don't know who our users are right like for years we had this narrative that hey L1 L1 is not for users. L1 is for data space or like DA and like no like you know L1 should be for DeFi users. I guess L1 should not be for gaming users but we

need to have the let's say uh we need to be able to differentiate between different user types and we need to be able to know what user types that we're serving and and and how. like you know there was this criticism that do EF people even use Ethereum applications and like if they're not that's a problem. So trusted execution environments are not perfect. We acknowledge that that they're not perfect. However, today the only alternative that gives the same user experience is a trust me bro setup which is so much riskier than trusted execution environments. I will give you

an example. Wormhole, which is a, you know, multi-IG bridge. Um, and I believe it was like that back in 2022 and it still is. I had to get out of Terra. I had a ton of US and the only way I could sell that was unis swap by going from, you know, Terra L1 to Terra ERC20 token. you know, it took me like four hours to bridge my tokens because the system is a multi-IK system and like I don't assume ill intention, but in that 4 hours when I moved my USD from uh Terra to L1, like I lost, excuse my language, but a

ton of money because the USD was free falling and you know like that kind of stuff happens with multisex like and that stuff would not happen with the TE Like yes, you know, TE's are not perfect, but at least you don't have that kind of situation. So my calling is yes, this is like not the ideal solution and you know in this world we live in this is the only way to solve this problem. So we're pragmatic. If people don't like it, they don't have to use it. But we think it's like, you know, it's a 1000x better than what exists out there. And it's like a 1000x faster than what your what your ideal solution is.

So this is the the the world. This is the now we're in and we want to serve the now. That that's a great notion to kind of end on. So where can we send people who want to um kind of build with T1 on T1 using T1? So first of all follow us on Twitter. It's uh the handle is T1 protocol and uh we have our DevNet portal live. Um our website is t1protocol.com and we have devet.t1protocol.com t1protocol.com which is our devet portal. There you can deploy apps on t1. You can you know

bridge funds to t1 exits uh back from t1. We had uh like more than 100k um nonbot users in the last month and a half since we launched the devet. So yeah like you know more people are welcomed. If you want to build with us you know you can uh drop me a message uh on Twitter. My DMs are open. Um I'm not sure if we're going to share my Twitter somewhere. Yes, we can. But excellent. Fantastic. Thank you so much for coming on, Sean. Thank you so much uh Fidik for having me. This was a lovely conversation.