Web3 Galaxy Brain 🌌🧠

Stephane Gosselin: I think generally speaking for credible accounts, liveness matters less than custody. But these are all the components that are needed to make this future a reality. You could use this as kind of like the new MEV supply chain. Basically, there's three things you can optimize for. Being permissionless, providing the optimal price, or providing the best reliability. What we observed is the majority of the systems have to pick between two of these things. And most of the time, they compromise on the permissionlessness. There's a need and a desire for providing a more unified experience so you don't have to care about all these details. And you can expose just a one-click experience to the end user. And so our contribution to the space is one balance, which solves a small piece of the chain of projection puzzle.

Nicholas: Welcome to Web3 Galaxy Brain. My name is Nicholas. Each week, I sit down with some of the brightest people building Web3 to talk about what they're working on right now. My guest today is Stefan Gosselin. Stefan co-founded the MEV Pirate Dev Club. He's been working on a new project, OneBalance, which he left in late 2022. His new project, OneBalance, is a framework that substantially reimagines how blockchain accounts are created and managed. In this episode, Stefan and I dive into the lifecycle of an Ethereum transaction today and the growing number of paths a user's intentions may take to ultimately be expressed on-chain. We then dive into OneBalance, Stefan and Ankit Chiplunkar's new account framework that decouples accounts from global consensus machines in an effort to bundle user state across all chains in a unified wrapper called a credible account. It was exciting to speak with Stefan. about OneBalance's paradigmatic refresh on the notion of accounts at such an early stage in the project's development. I hope you enjoy the show. As always, this show is provided as entertainment and does not constitute legal, financial, or tax advice or any form of endorsement or suggestion. Crypto has risks, and you alone are responsible for doing your research and making your own decisions. Stefan, welcome to Web3 Galaxy Brain. Thanks for joining me today.

Stephane Gosselin: Hello. Excited to be here.

Nicholas: There's so many things we have to talk about. OneBalance is the, your new project is the main subject, and I want to get into what it is that you're working on right now. I think a lot of people don't really know anymore how a transaction lands on L1. So, I know there's a lot of steps, but do you think you could give us an overview of what the supply chain is like, what the timeline is like for the life cycle of a transaction from the time I hit, except in my wallet?

Stephane Gosselin: So, yeah, I'm partially responsible for making it really complex to get things on-chain. Well, I apologize, because... There's a lot of the confusion I contributed to. So, obviously, I worked at a company called Flashbots previously, right? And one of the things I proposed while there was MefBoost and the concept of the MEV supply chain. So, this was sort of proposed a few years ago to say, "Hey, we're introducing sort of a new set of roles that are party towards getting things on-chain." Namely, the builder and the... The searcher role. So, initially, when using Ethereum, the idea was that users would be running Ethereum nodes locally, right? So, there was none of these, like, middle things. All the users would run a node locally, and they would have a key that's stored on that node. And that node would, you know, wholesale the smart contracts. And then if you're developing a dApp, you would deploy it to Swarm. And then you could load it locally. Swarm being kind of like an alternative to IPFS. And it was, like, really nice because all the users had their own Ethereum node. They were validating the network. They were all talking to all the other, like, nodes on the network directly on a peer-to-peer manner. But then a team called Infura came around. And they said, "Oh, actually, like, you know, we can host the node for you. So, you don't actually need to host your Ethereum node anymore.". And a team called Metamask came around and said, "Oh, actually, we can host your keys for you in the browser. And so, you don't need to host your keys on the node anymore.". And then all of a sudden, we came into this paradigm where we had applications, you know, Web3 apps being deployed as regular websites and connecting into Metamask in the browser. And then sending transactions through this JSON RPC, which was connected to Infura. That was then gossiping the transaction to the network and to miners to actually get included. So, that's how it worked for a while, right? It was users talking to wallets and then wallets somehow sending their transactions to validators. And then... Flashbots came around and said, "Actually, because of MEV, there's kind of like this incentive to do trading. And so, to keep the validator set decentralized, let's introduce this new role called the searcher that allows for doing the MEV stuff.". And so, then wallets send transactions to the mempool. The searchers picked it up. And then they back ran it or sometimes did more nasty stuff with it and then sent it to the validator. And then when the merge came around, we introduced the concept of a block builder. So, the block builder just builds blocks on behalf of validators. And proposes them to the network. So, that was sort of the supply chain for a while. Now, the impact of this is that it created the ability for a lot of different specialized roles to emerge. And so, I sort of made this blog post that we published at Frontier.Tech. that's called Infinite Games. that describes the fact that increasingly there's more and more roles emerging to sort of solve niche needs. And so, the reason why today is a lot of confusion. How does a transaction work? It's because it can take any of these paths to get there. And so, there's a lot of different ways to get a transaction to the chain. There's some folks that tried to map it out. So, there's this website called orderflow.arts by the Flashbots folks. And it tries to map out like actively, you know, from the Uniswap website, where do transactions go? Do they go public transaction pool, private transaction pool? Which order flow aggregation system do they go to? Which block builder do they land in? And so, it tries to look at all the different layers of this transaction supply and map where are the largest flows of transactions. So, the reason why it's confusing is because there's a lot of moving parts and it's a very chaotic system. But it all emerged sort of using the, from the story that I told.

Nicholas: Very cool. I think the part that is interesting to me, maybe from a high level is, would you say, because listening to your appearance on Epicenter, it occurred to me that there are different ways to solve these problems. Would it be like a fair summary to say that the Flashbots and ultimately the Ethereum solutions have been ones where, wherever there's a point of centralization in the supply chain, it's turned into a market so that there can be competition, so that it's not, it doesn't devolve into centralization?

Stephane Gosselin: Yeah. So, I think that episode. I'm not sure when it was recorded. It was probably over two years ago.

Nicholas: It was a while ago.

Stephane Gosselin: If not more, maybe like. Yeah. So, certainly my thinking has evolved on this topic. I would say like looking back on things, the Flashbots approach and maybe like the approach favored by the Ethereum ecosystem to date has been, how do we most efficiently extract all of the value? And a lot of the mechanisms that were built are sort of responses to this. So, MevBoost being, an auction mechanism says actually outsourcing block construction is the most efficient way to express desires to control block construction. And so, it ends up that you have these specialized parties that optimize for their amount of MEV that's in a block to be able to win this auction to get blocks landed on chain. So, I would describe it as like a design preference of the group of people that call themselves Ethereum people, have decided to optimize for, which is the efficient extraction of the maximum amount of value.

Nicholas: Got it. So, I think this is a good point. We can start to think about what is OneBalance. What is the problem that OneBalance tries to solve?

Stephane Gosselin: So, our mission with OneBalance, and this is maybe like a bit of a jump, I guess.

Nicholas: Oh, really?

Stephane Gosselin: Let's see how we can build this.

Nicholas: I guess from the perspective of a user, it's like, you know, I'm trying to do transactions. I'm trying to live this cool multi-chain life. I'm using all these different protocols all over the place. And it feels like OneBalance, it relates to, you know, living my life on chain, right?

Stephane Gosselin: From the user perspective, yeah. So, you know, when asking a question like what is OneBalance, it's like from which perspective, right? From the user perspective, I think it's an interesting one to go from. So, obviously, I displayed this complexity of getting a transaction on chain. And that was just for getting a transaction on Ethereum, right? But then you have to imagine like Ethereum is no longer just the only place where people want to interact, right? They want to interact on a bunch of Layer 2s. Maybe they want to interact on Solana, whatever. There's like a similar architecture for each of these different things. They also have different properties. And it's quite difficult to ask a user to keep track of all of this and to understand how to write things. It's also quite difficult to have even application developers keep track of all this stuff and figure out. The complexities and intricacies of interacting with different chains. And so, there's this entire movement called chain abstraction that, you know, I don't take credit for. I'm just a member of this movement. But that says that actually we shouldn't have users making all these decisions and handle all that complexity on their heads. We should develop tools that allow for applications to abstract away all of this. This complexity for the end user. So, this idea that we had that we'd have a single world computer that, you know, you could interact with worked great, you know, during DeFi summer in 2020 when we had, you know, YAM Finance and whatever else. But as we, like, tried to scale the space, we've had just an increasing amount of fragmentation. And so, we're, you know, there's a need and a desire for providing a more unified experience. So, you don't have to care about that. You don't have to worry about all these details. And you can expose just a, you know, a one-click experience to the end user. So, chain abstraction is kind of like a unifying vision, a unifying flag to achieve this. And it's something that ourself, myself and my research partner, Ankit, have been researching for quite a long time. A problem that I've been passionate about for many years and started working on back in 2019. And so, our contribution to this. To this space is OneBalance, which solves a small piece of the chain abstraction puzzle.

Nicholas: So, maybe as we get into that, speaking of chain abstraction, what is the CAKE framework? And is that kind of how you got to the OneBalance solution?

Stephane Gosselin: It is, yeah. So, the CAKE framework is kind of came out of a few observations and our research that a lot of folks are starting to approach the challenge of interoperability. But none of them sort of took a global picture of it. So, they sort of tried to bite off small pieces without having a sort of a longer-term vision of, like, what is required to achieve this unified experience. And the CAKE framework is basically just like a publishing of all of our research that combines, you know, topics of interoperability and distributed systems from computer science with topics of interoperability and financial systems. From TradFi with kind of, like, the special spice that is MEV. that kind of comes and, like, makes everything much more difficult to build in crypto. And what we've basically our observation was that a lot of people came from either, like, the TradFi background or the computer science background. But they were not necessarily speaking to each other. And they also didn't really have the MEV perspective on it. And so, we built this framework to sort of say, like, okay, guys, we're all building different components to this. But it's only when it all fits together. That it starts to work. And so, the catch line is if you want to have chain abstraction, it basically requires us to have our cake and eat it, too. And we need to build the cake to be able to get there. The, like, really fundamental premise of the CAKE framework is that users should not really be interacting with the chain directly. They should be interacting with solvers. And the solvers are the ones that are bringing things to the chain on behalf of the users. And if you look at what, you know, folks are pushing for, like, in account abstraction world with 4337, it's all the same thing. It's how do you get bundlers or paymasters to send transactions to the chain on behalf of users. And how do you create this, like, other mempool? that's, you know, user ops that allows for them to do so. So, all of these systems are trying to drive towards the same vision. And we just provided a unified framework. So, that's the framework for thinking through the problem.

Nicholas: In the blog posts that I've read describing Frontier's approach with OneBalance, you talk about sort of reframing the coupling of credible commitment machines and global consensus and shifting to a coupling of credible commitment machines and accounts. Can you tease out what that actually means and how can you remove the global consensus from the coupling? I mean, isn't that how blockchains work?

Stephane Gosselin: That is how global consensus works. And in many ways, that was sort of, like, the fundamental innovation of Ethereum, if you look back at, like, what motivated Vitalik to start it. It was the idea of being able to implement smart contracts, which smart contracts are really just implementations of credible commitments. The question is, like, what are the enforcement mechanisms that you're using for these smart contracts? And having the entire world agree that you've made a commitment is certainly one approach. But for many types of agreements, you don't need that. You don't need the entire world to attest to it. And so the global computer that is Ethereum, the reason why it's so expensive is because, you know, it requires everyone to attest on everything, which oftentimes are things that don't need to be attested to. So if I'm paying for coffee, you know, at the coffee shop, there isn't really a reason why the entire world computer of Ethereum needs to validate it. I could have, like, a special agreement with, like, a subset of nodes, you know, maybe just me and the coffee shop. And we can, like, settle effectively. And so the question is, how do we go from this world computer concept into one that is much more scalable while, you know, maybe the coffee shop runs on a roll-up and every account runs on a roll-up? And then you basically just have a cross roll-up message between your account and the roll-up of the coffee shop. And then you're not requiring the world computer to attest to that transaction. You just need the sequence. You need the sequencers of each of the roll-up to, like, validate that they're valid state transitions and synchronize between them. And so, you know, OneBalance is kind of like a reflection on this that, like, you don't need to have the global consensus for accounts to be able to interact with other accounts. But you need a way to secure the commitments that the account makes. And so that's why we came up with this concept of resource locks. And credible commitment machines are able to enforce these resources. So once accounts are able to make commitments to other accounts and using some kind of machine to be able to do so, you eliminate the need to rely on the global network for those commitments.

Nicholas: Right. So one slide that was helpful in one of your presentations was pointing to exactly these two topics we've been talking about, which might be sort of new terminology for people. This credible commitment machine, credible accounts language, and the resource lock language. One of the slides that really helped me understand was the resource lock slide really shows that resource lock allows you to do something like an intent to just say. this is what I want. And as you say, a solver comes in and actually provides the path to getting the result that the user demands and kind of marrying that with a credible machine, which, from what I understand, something like a smart account is one example of a credible account and a credible machine. Maybe could you explain a little bit more what you mean by this terminology? Yeah, for sure.

Stephane Gosselin: Let me see if I can pull up the thing that you're mentioning.

Nicholas: Yeah, sure.

Stephane Gosselin: So we published this blog post to Eth Research that discusses all these things. So, yeah, like, what is a resource lock? That was kind of the question that you're asking. Yeah. And the very simple way to say it is like a limit order, right? That's kind of like the most simple version. Hey, I have some USDC on my credit card. I want to buy an NFT on, like, base. I want to buy an NFT on Solana. And I want it to expire at a specific block. If I'm able to credibly say that, okay, this USDC in my account is not going to move for this period of time, then a solver can go and buy the NFT on Solana and then credit it to my account and provide a proof that they've credited it to my account to be able to receive the USDC. So just think of it as like putting escrows inside of wallets. That don't require the user to make a transaction against a chain. So that's really what it enables. And then the solver can go and do the transactions on chain to get the assets that they need to get. So that's the first step. And then how does this relate to smart accounts? I think it was the other question that you were asking.

Nicholas: Yeah, I guess. I mean, one thing about that is that like a resource lock. I mean, in a sense. Yeah. A smart account is the resources are locked in the smart account or they're in the smart account contract rather than in an EOA. So in some of the discussion, I guess we didn't really talk about it, but there's a substantial difference between an EOA signed transaction where the chain is not able to know whether or not there are multiple signed transactions that could move those assets. Right.

Stephane Gosselin: Exactly. So what is the difference between an external account? A smart account? A stateful account? And a credible account? You know, that's kind of your question. Yeah. I have put out this slide as well that tries to answer this question in a more sort of maybe intuitive way. So the problem with external accounts is, like you said, they can sign any message. Right. And so from an Ethereum perspective, a user can sign two transactions with the same nonce and they're both considered valid by the protocol. Right. And so a block builder that receives either of those transactions can include an external account. Right. And so it can be included and it remains valid. The problem is then if you sign a transaction and you give it to a solver and the solvers rely on this for some reason to remain true, but then you have another way to sign a transaction and send it to someone else, you're effectively able to double spend the request that you have. And so it's not a credible commitment because you can equivocate out of it. So this ability to sign something else is the issue. Right. Now, you can turn an external account into a credible account by removing your ability to double sign things. And so that essentially means that there's some external machine that's not controlled by you that can attest to the fact that you haven't signed the thing twice. And there's multiple different ways to implement this. One of them is by putting things in a smart contract, like you mentioned. So, like, let's just say that you deposit your funds inside of a smart contract account. Right. So as long as there isn't a way to, for example, upgrade the account or change the approvals over the funds that you have in, then people can rely that the assets in the account are there for a certain period of time. But most smart accounts are actually supporting this by default. And so even the smart accounts, they need a wrapper that makes them credible. One way to think about this is just as a module on top of a Gnosef safe. So we're working with a Gnosef safe. We're working with a Gnosef safe team to develop this module that allows for turning a Gnosef safe into a credible account. But by default, they're not credible accounts. So all of these different existing account types can turn into credible accounts, but they need to have different security properties that they're exposing to counterparties.

Nicholas: In the graphic you're showing, it also mentions stateful accounts. What's the difference between a smart account and a stateful account?

Stephane Gosselin: So I kind of made up this terminology of stateful accounts because I wanted something to describe the 3074 and 7702 standards that are being proposed. And it didn't seem like they had terminology themselves. But what these standards say is that you can take an EOA, you can take an external account, and you can delegate its execution semantics to a smart contract. So these are just like turning EOAs into smart accounts. But themselves have other issues that are involved because you can equivocate out of your delegation. And so even though there's a smart contract that implements the logic for my key, because I'm still able to sign a different request to delegate to a different smart contract, it means I can equivocate out of any rules that that contract enforces, which means that, once again, the account is incredible.

Nicholas: In practice, they're like EOAs. Yeah, exactly.

Stephane Gosselin: They have the same equivocation problem as EOAs. And by the way, the reason why these equivocation things happen is, when you're running a global consensus, you need to prevent the ability for a node to lock a user account. So if the user is not able to equivocate, imagine that a block builder receives a transaction and they just never put it on chain. And so the user is never able to issue a transaction again. A lot of people have had this issue where their MetaMask account goes out of sync and a transaction has too low gas and never gets mined into a block. Right? Well, then they sign another transaction with higher gas price to override it. But if you weren't able to do this, then you would end up in really weird locking situations where you wouldn't have access to your account anymore. So there's a valid reason why accounts are designed this way. But it makes it really, really difficult to do cross-chain activities because of it. And so you need to restrict some of the functionality of accounts in a way to be able to make them credible.

Nicholas: Okay, that's interesting. You say it makes it more difficult to do cross-chain activities. I want to get back to that in just a second. But just before we do, the smart accounts themselves have sort of affordances to make sure that the bundlers are not getting griefed in the way that you're talking about. solvers getting griefed if the assets in the account move prior to the transaction occurring, right? Something like OpenSea might have this problem. where if you make a bid with or any kind of exchange where if you make an off-chain order, with WEATH, and then you move the WEATH, you need to know, sort of in the transaction execution, it needs to validate that the WEATH is actually there before passing the NFT or whatever asset it is you're trading for at execution time. But in the case of something like a smart account or a credible account, there's the concern that the person who's paying the gas is going to get caught paying a bill to put the transaction on-chain when the asset that was supposed to be used to pay for that gas. It's no longer there in the smart account, for example. But bundlers do have a way of validating that the transactions that they're bundling are not going to grief them, right? So why does the same not apply to solvers in the CAKE and OneBalance model?

Stephane Gosselin: So, yeah, I think you're touching on an interesting topic here that may get a little bit into the weeds of things. Let's do it. So you're absolutely right. If you're just a protocol, like a smart contract protocol, like OpenSea or Uniswap, you rely on the fact that you have synchronous execution. So at runtime, you can check, does the user have the balance that they say they have, right? And you call into the ERC20 token and then you say, like, balance of, is it like what it is? If it is, great, continue. If it's not what I expect it to be, revert, right? And so when you're designing single-chain applications in a synchronous setting, as opposed to cross-chain applications in an asynchronous setting, you have the ability to do these checks and revert. But you can't do those checks in a cross-chain setting. There's no way to call from a roll-up down to Ethereum to check if the user's balance has changed or not, right? And so that's sort of where the problem emerges once you have a cross-chain setting. But you're also absolutely right that you have the same problem when it comes to paying for gas. So because... When you're running a bundler and you're submitting a transaction on behalf of someone else, if you're executing the check on chain that says, does this user have enough to pay for the gas, you've had to pay for that check to take place. And that check, of course, is much smaller. You're essentially paying for the revert, right? And most applications, if you look at, like, Uniswap X or 1inchfusion or Calswap, they just eat that themselves. They say, like, we're going to absorb that revert check. But if you look at an open system that's meant to be permissionless, like 4337, you need to come up with other constraints. I'm not super up to date with how the 4337 folks resolve this. As far as I understand, they have some constraints over the simulation space. So they say, like, user ops can only interface with a subset of state. And then because of that, you're able to restrict, right, much like credible accounts are able to restrict, like, the type of things that... that the account can interface with. And then the bundlers, they're still responsible for simulating off-chain, but they have some level of assurances that between the time where they simulate off-chain and they submit the transaction to, like, a paymaster for inclusion, that state doesn't change. So that's what they try to fix. Again, it works by restricting the state that the user has access to on a single chain, but it doesn't do so on a cross-chain setting. So one way to think about, like, what are credible accounts, you could say it's like, okay, it's similar types of restrictions as 4337, but it's bringing 4337 in a cross-chain setting.

Nicholas: Mm-hmm. Got it. I've heard about... I don't know what the EIP is for this, if there is one, but I've heard about sort of being able in the transaction execution to know the state of... of another chain by proving... by being able to compute that a transaction hash was included in the state root of another roll-up because Ethereum will be writing... because sort of you go from Optimism to Ethereum and check what Arbitrum wrote to Ethereum in order to know what happened on Arbitrum. Obviously, something else could happen sort of in the next block of Arbitrum, which maybe is the answer to why that's not a good enough solution. But are you familiar with that? Or is there a terminology for that kind of, like, hopping from using Ethereum as a way to get access to data about what's happening on another roll-up?

Stephane Gosselin: Yeah, so I believe what you're referring to is called Universal Synchronous Composability, so USC. It's something that's being explored by a few different folks. It's very related to shared sequencing or pre-confirmations or base sequencing. A lot of these topics are mostly being pushed and explored by Justin Drake. So maybe the 10,000-foot abstraction of this concept is if you have sequencer on roll-up A and sequencer on roll-up B talking to each other, when they're processing a request, they can feed data from the other roll-up into this to validate the transaction, right? So you can call between roll-ups by just having the sequencers talk to each other. If you're in a ZK context, you can do this with proof aggregation. So you're submitting these... these ZK proofs, and there's some aggregated way to have them, like, be conditional on each other for inclusion. The folks at AgLayer are looking at this a lot, as well as the folks at ZK Sync. So my general take on this class of solutions is that they indeed manage to reduce non-execution risk for people that are doing cross-chain transactions. But they do so from providing guarantees on behalf of validators. So those are all, like, validators or sequencers providing guarantees to users. And it's quite expensive. So if you think about, like, what's required to be able to provide this, like, cross-roll-up messaging, you need to issue a lock across two roll-ups. So you're saying, like, now I have the synchronous execution of roll-up A, and I have the synchronous execution of roll-up B, and for a period of time, I'm going to make both of these executions locked together, so I can provide this guarantee that the state here is not going to move while the state here is being updated. And so that's quite expensive to do. But it does help reduce the execution risk. One balance is a bit of a different take to this. So if you see USC or pre-confirmations being commitments made by validators or by chains for inclusion, one balance is commitments made by accounts or by users made to solvers. And so both of them, you could think of them as, like, commitments being made to solvers or bundlers to help them manage their execution risk just from different sides. So one of them is from the chain, from validators. The other one is from users. And, you know, maybe the vision or the outcome that we believe of chain abstraction is, at the end of the day, it will mostly be solvers that are putting things on roll-up or on L1s. And what you'll have is everyone's trying to help solvers manage their risk such that they can remain very lean and there can be a wide diversity of them, as opposed to there being just, like, a handful of block builders that are providing all the liquidity and doing all the sequencing for all the chains and all the transactions.

Nicholas: So the essence, then, of a credible account is that it has resource locks enabling you to make guarantees about the resources not moving.

Stephane Gosselin: Correct. That's all it is.

Nicholas: Okay. And credible machines, then, are just any kind of-- in this class of solutions that provides that?

Stephane Gosselin: Yeah, so they're just an enforcement mechanism. They're an enforcement mechanism that secures these locks. And, you know, what makes a machine credible is just that it's mutually trusted by the user and the solver. And that's, like, a very simple definition, which means that there's also a bunch of different ways to implement them. So, like, you could use a rollup as a credible commitment machine. You have a smart contract wallet on a rollup, and then you just have everyone, like, monitor the rollup and see, like, okay, is this, like, providing messages that I trust? And if so, then I'm going to process them. Or you could have a more complex system that uses trusted execution environments like SGX. You know, it's running code inside of it, and I, you know, no matter where this code is being run, because it's signed by the machine, I know that no one's able to tamper with the code that's being run there. And so I believe the commitments that this machine is making. A CCM, or a credible commitment machine, is kind of just, like, an abstract concept that says this is a machine that's mutually trusted between solvers and users to enforce some set of code that's running on it. And if it's running a credible account that's making credible commitments, then you have a solution to the problem that we're trying to solve.

Nicholas: So as long as the solvers are happy with it, then it's a legitimate solution. I saw in one of the other slides that you had in that presentation and in the blog posts, the four options that you mentioned. there are, as you say, like a modified VM that supports this, a TEE solution, an MPC solution is another option, and the smart accounts that we talked about. Is the best in class... I mean, I know that it has some drawbacks around cost, and maybe there are other drawbacks also, but are the smart accounts kind of the best solution in terms of decentralization? Or are there reasons why you might see credible machines actually executed in, say, MPC or one of these other formats?

Stephane Gosselin: Yeah, best is a difficult thing to achieve. So my general take here is that we're in the first inning of these types of accounts, and so whatever is best today is going to be very different than what's best a year from now or five years from now. There's going to be a ton of innovation. Our observation that we make between these four classes of architectures is that they all have trade-offs, and so none of them is actually best. None of them is strictly dominant over the others, which means that I sort of expect them to be used for different things depending on the use case. So, you know, what is... What does TE provide that smart accounts doesn't? It's really scalable. And so a TE is able to issue resource locks at the clock speed of the TE, right? And that is just not something that you can do on a smart contract account, depending on the chain that it's on. Obviously, if the smart contract account is on an L2, then you have other considerations, like you have the sequencer that's running the L2, and, like, what are the properties that sequencer has? And so it's not, like, strictly... It's not that one is strictly better than the others. I think the path to adoption for credible accounts depends on, like, what the user is used to, right? So if the user is used to a flow using EOAs, then it's likely that they'll have an easier time adopting sort of a TE or MPC-based solution, because that's just saying, like, how do we give additional guarantees to an EOA? Whereas if the user is used to smart accounts, then a smart account wrapper is the best way to deliver the credible commitments. And so my expectation is we'll see a bunch of different wallets take different approaches for how they want to distribute these credible accounts.

Nicholas: And in that case where someone is trying to deliver a solution that's familiar to EOAs, I suppose they might use something like a stateful account in order to upgrade it to delegate transaction execution to a TE, or even that, I suppose, would not be good. Because you can still equivocate those 3074 delegations.

Stephane Gosselin: Yeah. So the stateful account, I would put it as, like, the virtual machine modification, like, class of architectures. It's -- well, first of all, we don't know yet exactly what the design of these things is going to end up being, when it's going to be included, blah, blah, blah. But putting that to the side, I think the biggest question here is how do you prevent it from equivocating out of its delegation? And I think that's a good question. I think that's just an active area of exploration. I haven't fully wrapped my mind up around how that would work yet. I think realistically for folks today that are using EOAs, I would point to the people that are implementing Telegram Trading Bots. They've done the most amount of work at, like, making EOAs look and feel more seamless and improving the UX behind it. What they've struggled with is to maintain the non-custodial aspects of EOAs while doing so. And so hosting an EOA inside of something like a TE and then having delegated session keys for that EOA issued to folks like Telegram Bots is a way to maintain the non-custodial aspect and turning the keys into credible accounts because they're being hosted inside of TEs.

Nicholas: Makes sense. So you mentioned that this will be like a transition to message passing of resource locks and fulfillment proofs, that this is kind of the world that OneBalance foresees. How will a transition to message passing and resource locks -- sorry, I want to say it correctly -- a transition to message passing of resource locks and fulfillment proofs, how will that change? sort of DevX and UX?

Stephane Gosselin: So I'll show my screen again. I think this is a useful framework to use, which is the credible stack. You know, it's shaped as a cake deliberately because it is an implementation basically of the cake framework. But these are all the components that are needed to make this future a reality. You could use this as kind of like the new MEB supply chain. So this is how transactions go from apps to going on-chain. The important thing to know for apps is that they can just use the existing SDK providers that they're used to. So we're working with folks like WalletConnect, Web3.js, VM, and Ethers.js, and all of these capabilities that we're describing are just sort of a version bump on those apps. The reason why that's possible is because the JSON RPC API is being extended. So we're extending it with some standard methods that allow for delivering all the capabilities directly to applications behind standard methods. So for folks that are developing applications or wallets, go check out these EIPs and ERCs because this is the way that we're delivering all of these advanced capabilities without introducing a huge amount of complexity for wallets. Behind the scenes is where the resource locks live. And so Solver Networks and the Oracle providers are passing around resource locks and fulfillment proofs that are being interpreted by the Credible Commitment Machine, and then data providers or the Credible Commitment Machines themselves are exposing those through the JSON RPC to the wallets and the applications.

Nicholas: So if we imagine that example earlier of like an OpenSea or Uniswap swap, I would have to, as a user, have previously made-- a transaction would have to have landed already on L1 that locks the resources that I'm then making some subsequent-- you know, signing some subsequent message upon, correct? Like it can't all happen right away because it needs to already be on chain that the resource is locked.

Stephane Gosselin: So realistically, as a user, I go to OpenSea and then I do like connect wallet, and then as part of that call, it would do wallet get capabilities. So the app would request from the wallet, "Hey, do you support Credible accounts?". And then the wallet would say yes or it would say no. If it would say no, then it would just use the existing flow, right? But if the wallet does support Credible accounts, then, you know, the user already has the balance that's accessible to be able to issue resource locks. And so you would go into then the flow of creating the resource locks. And so, you know, from the application perspective, this sort of assumed that the user brings, you know, whatever wallet that they want to bring to interact with it, and you have to provide, like, a different experience depending on the type of wallet that the user comes with. Now, for users that, like, select the type of wallets that they want, obviously, if they want to use a wallet that has the Credible account capability, then they would need to transfer their funds to that kind of wallet, right? So until MetaMask supports Credible accounts, then they would have to switch to a different wallet provider to be able to get access to those capabilities. Sure.

Nicholas: But let's say I'm logging to OpenSea, I have a Credible account or an account that supports Credible, that is a Credible account. I need to sort of lock some resources to begin to make, you know, these kinds of limit orders, correct?

Stephane Gosselin: Well, if your account already supports Credible accounts, your account can already issue these resource locks, right? So it assumes that your balance is already within a Credible account.

Nicholas: Okay, so if it's a Credible account, 100% of the assets that are contained inside of it are already resource locked or are already eligible for this kind of transaction creation. I guess I'm curious how... Maybe there's something I'm missing, I'm not understanding. How can I not equivocate then? How can I not have two simultaneous resource locks or two, you know, two limit orders over the same assets? What is it that... I guess it is just a Credible machine that will only execute them... I guess, why can I not sign two messages that have the same... over the same locked resource?

Stephane Gosselin: Yeah, so basically, instead of just the wallet communicating to solvers directly, it communicates to the Credible commitment machine. that then communicates to the solvers. And so the Credible commitment machine's job is to enforce that there isn't conflicting resource locks. Right? So you can think of it like... What's a good example to this?

Nicholas: Let's say I have an amount of Weeth. I have an amount of Weeth and I'm going... I want to, you know, swap it for... Swap it on... You know, I simultaneously want to swap it for an NFT on OpenSea and I want to swap it for USDC on Uniswap. How does the Credible commitment machine refuse that?

Stephane Gosselin: So let's say that the Credible commitment machine is just hosted inside of TE, just for this example. It would receive the first request and then it would lock the funds and then it would receive the second request and it would say, "Oh no, this is conflicting with the existing lock.". And so it would reject the second request. And so it would reject it until the first one either is expired or is fulfilled. So it's the job of the Credible commitment machine to say, like, "Does this new request conflict with any of the pending resource locks that this account already has?".

Nicholas: And if the Credible account were Gnosis Safe upgraded with a Credible module, would it have to execute something on-chain to be able to reject the second transaction?

Stephane Gosselin: Not necessarily. So the simplest way to implement a wrapper around an existing smart account is just a cosigner. So you have some other party that's cosigning every transaction that's being requested. So let's say that your Gnosis Safe is just a one-of-one. Now you're turning it into a two-of-two. And every request that the user originates needs to be cosigned by this other entity before being propagated. And so it's still using this external machine that's run not on-chain despite the enforcement being actually done on-chain. And so the transaction still goes through the smart account. It could be using sort of 4337. And so you could have like a bundler that's providing cosigning services or a paymaster that's providing cosigning services. And basically, the solver knows that, okay, if the bundler has cosigned, it means that--and I trust the bundler-- it means that this is like a valid request and I can rely on it for execution.

Nicholas: So it starts to look more--. I guess that's maybe the simplest way, but it would be possible to encode that into the logic of the smart contract of the 4337 itself so that it's not relying on an out-of-band signer to cosign the transactions. Like, you could imagine a module where you actually do lock up the funds every time you make one of these commitments.

Stephane Gosselin: Yeah, the resource loss could be enforced on-chain for sure.

Nicholas: Mm-hmm. Just because it seems like if you're just adding a signer, I mean-- The challenge there with the smart contract approach is managing the approvals.

Stephane Gosselin: So because when you're issuing like an approval for a token, you basically have arbitrary spending capability over that thing, you basically need to transfer the tokens into like a sidecar to the smart account. That sidecar doesn't have the same capabilities for sending approvals, especially with things like Permit 2 and the new permit standards that are emerging that like a simple signature can allow for a third party to spend funds on behalf of the smart accounts. And so you got to restrict all those capabilities to be able to make the transactions credible.

Nicholas: I see, I see. Maybe with regard to solvers and just in general, the whole setup, how will MEV exist in this credible account architecture?

Stephane Gosselin: Yeah. So the CAKE framework, was really an analysis of solver networks in many ways. So looking at solvers, solver networks, geoswap X, 1S fusion, all the order flow action mechanisms and providing an analysis from the perspective of MEV of how does MEV manifest in these systems and how do these various systems design around it? And what we propose is this concept of an order flow trilemma. And so any of these systems that are trying to introduce some counterparties to provide the execution run into the problem of you can either optimize, basically there's three things you can optimize for, being permissionless, providing the optimal price or providing the best reliability. And what we observed is the majority of the systems have to pick between two of these things and most of the time they compromise on the permissionlessness. And so all of these solver networks run some kind of white list where they manage the solvers and they say, you should restrict the amount of MEV that you extract, otherwise we will kick you from this white list. And that's sort of how the MEV ends up getting expressed. And so whether it's things like you can only back run this or you need to provide some level of reliable inclusion or reliability over the inclusion, or you need to quote prices within a certain spread, these are all restrictions that are imposed by these networks, usually using a white list to try to prevent MEV from having a negative impact on the user experience of those that are submitting through the systems.

Nicholas: Got it. Is there a forcing function that will engender adoption of cake style, cake style transactions, or what is it that makes all of these SDK providers excited to integrate one balance?

Stephane Gosselin: I think, again, the unifying flag is chain abstraction. There's a huge amount of pain for users to do cross-chain stuff. What we'll see increasingly so is the more people do cross-chain interactions, we'll see people struggling with reliability, so revert rates, in the cross-chain setting are going to continue increasing. And so, these are kind of like the two big motivators. There's a third one, which is wallets making the most out of the order flow that they're generating. And so, a lot of wallets are looking for a way to monetize, and a cake-like stack is providing them a way to monetize through order flow generation. The question is, how do you do this? by optimizing the user guarantees? And this is a whole topic that we could dive into. But, okay, so there's user pain of doing things cross-chain. There's the existing solutions that will have more and more revert rates. The solution to both of these things is credible accounts. And sort of the carrot for wallets to integrate is that it provides a way for them to have a revenue model, a monetization model, over the order flow that they generate.

Nicholas: And specifically, how does that work for them? How are they able to extract value from generating these credible transactions?

Stephane Gosselin: So, the thesis behind a lot of the OFA systems is you send a bunch of order flow into this, the solvers or the block builders bid for it, and then you're able to distribute back that value to the people that originated the order flow. Right? And so, this doesn't enable this. Like, we're not hosting an order flow auction ourselves. But what we're doing is we're making order flow auctions more reliable and more secure. And so, you can think of it as, like, it allows solvers that are participating on something like Uniswap X to quote tighter spreads because they don't have to worry about toxic flow. Right? Like, their users don't have an option to equivocate out of their request. Therefore, you can't, like, you can't just snipe the bids that the market makers are making because the market makers have last look on the other side. Therefore, the market makers are, like, able to quote tighter spreads, and then you're able to pass more of that value back to the end user. So, yeah. I probably need to write a blog post about this. Like, how do resource locks help make any order flow auction mechanisms work? Is it more efficient? And how does that maximize the amount of value that can be passed back to the users?

Nicholas: And in this case, users is really the wallets because they're the ones generating the transactions and so they can pocket the difference.

Stephane Gosselin: That's up to them. You know, do they want to share that back with their users or do they want to keep it as a monetization? What percentage of the value do they want to share back versus keep themselves? I think these are all things that very few people have, like, explored yet. But increasingly so, I think it will stabilize around some equilibrium. It's a similar question of, like, for a staking pool operator, when you're running MevBoost, like, how much of the MEV revenues are you keeping yourself versus passing back to your stakers? It'll be the same questions.

Nicholas: Mm-hmm, mm-hmm. I realize it's not really the same thing exactly, but I am curious. How does OneBalance relate to Vitalik's proposal for an L2 registry of cross-chain accounts? It seems like it maybe solves some related problems but goes a bit further.

Stephane Gosselin: Yeah, so the key store is about. how do you, like, are able to have a single point for permissioning. It doesn't say anything about keeping track of the, like, state that the accounts has. So it's a registry for permissions. It's a tangential proposal. And so, you know, in a world -- let's say you imagine a world where every account is its own roll-up, you don't really need, then, a key store. But if you have a world in which you have an account on every roll-up, then you need a key store to synchronize them. So it's sort of targeting, like, different views of what the world could end up looking like. And the key store proposal doesn't have much to say about cross-chain execution. It's more like cross-chain permissioning.

Nicholas: You mentioned that -- you expect a lot of different solutions will come out over the coming years, and maybe the whole architecture -- or not the whole architecture, but at least the credible machines, the credible accounts piece will look different. People are very hot on 457 right now. Do you think that -- I mean, it sounds like maybe this is -- some people are detractors because they find it -- I guess they -- maybe you could explain it better than I do, but people are concerned about introducing not just complexity, but I suppose the centralization of having a whole new -- maybe it's not even centralization, but just having a whole new mempool of transactions. that's specific to these accounts. And I don't know. People are skeptical of 457, as well as it requiring a transition of existing accounts and new accounts to this more complex architecture. Do you think 457 is a good solution, or what about it do you think might be improved upon in subsequent developments in that space?

Stephane Gosselin: I think 457 is a really good start. At the end of the day, it promotes the use of smart accounts, which are useful primitives. I think the 457 mempool is still an open question over, like, how much adoption is it going to have? How useful is it on Ethereum mainnet? Is it really something that's mostly useful on other chains? And how will, sort of, application developers feel about the restrictions that it imposes on the usage of external state? And so TBD, how that works, I think one of the really good parts about 457 is the definition of user ops. And that in and of itself, I think, is something that's a reusable concept for a lot of different constructions. So, you know, the initial blast for credible accounts will definitely be to leverage a lot of the 4337 architecture. I just... Yeah, there's a bunch of different components that are involved in 4337. I think some will be more popular than others. And probably the user ops is the biggest value-add of the system.

Nicholas: I was interested by what you said about the Telegram bots and potentially using something like a TEE, credible machine solution. I've heard people say that TEE-based solutions are not actually non-custodial, and people should be careful about assuming that they are. Can you imagine a construction where they are genuinely non-custodial? You mentioned session keys as a possible path.

Stephane Gosselin: Yeah. I mean, like, all of these things, it's like, it depends on the implementation, right? So there's... Typically, the concern with TEEs is around security. And the fact that you can do... So there are two classes of attacks. There's site-general attacks, which is, like, someone has physical access to the hardware, and they're able to, like, send electrons through and, like, be able to, like, read bits of memory or something like this. And then there's the... You could call them, like, supply chain attacks of, like, well, maybe the U.S. government put a backdoor in it. And I think both of these concerns have mitigations for them. So one mitigation for, like, the backdoor thing is you can actually run MPC over TEE. So you can have three different hardware manufacturers of TEEs, with only a share of a secret that have to come to agreement on the outputs. And so even if one is compromised, it's fine. If two are compromised, then you're running into more trouble. But then the question is, like, you know, would Intel or AMD, like, go out of business if it's, like, found out that they've put a backdoor into their, like, secure compute thing and that, you know, they're selling to everyone without telling them that there's a backdoor? Well, maybe it wouldn't be great for their business. And so that general class of concerns, I think, is fairly well addressed. The second one around side-channel attacks, which is, like, if someone has physical access to this machine, are they able to read from it? My understanding is the solution to this is you just don't want long-term secrets to be held on the machine. And so there's all kinds of approaches to make sure that whenever there's a secret that's held on the machine, it's only there for, I don't know, 30 seconds, a minute at most, which sidesteps this class of attack. So that's my understanding of the security model. Now, there's a separate question of, like, is the implementation actually non-custodial? Like, this has more to do with, like, which provider are they using? and, like, what are they implementing? The litmus test for this is, like, if you contact their support, like, is there a way for them to recover your account? If the answer is yes, then it's custodial. If the answer is no, then either it's custodial and they don't tell you, or it's non-custodial. And so, you know, generally the advice would be, like, you need to go with a provider that's trusted and, like, has external audits that are credible if you want to be able to make sure that it's a fully non-custodial solution.

Nicholas: I guess in that-- it makes sense to me, but I guess it's-- downtime is not enough to constitute custodial-- custody. Like, if there are services to go offline and you lose access to your wallet, it may feel custodial at that point, but that maybe doesn't actually make it custodial because they can't execute a transaction without your participation. I guess that's the-- Exactly, yeah.

Stephane Gosselin: There's a difference between liveness and custody here, or, like, liveness and security. Security being, like, they can't do something on your behalf. Liveness means that, like, they can't just go offline. And then there's a separate, like, problem, which is, like, censorship, right? And that can also be-- so you can have a system that's secure, that's, like, non-custodial, that's live, but is still censoring. And so there's, like, a bunch of different factors to consider. I think, generally speaking, for credible accounts, liveness matters less than custody. And so when looking at, like, the trade-offs, like, if you want to do something that has full liveness guarantees, the best possible thing you can have is an EOA talking to a local Ethereum node, right? That's, like, you'll have the best liveness guarantees. But already, if you're using MetaMask, you're trusting Infura for liveness, right? And so the-- despite, like, Infura not being custodial, you're still trusting that they're, like, running their nodes. And if Infura was to go down, you'd have millions of users that are like, "Holy shit, like, Ethereum is down. "It doesn't work anymore.". Like, no, Ethereum is still up. It's just that the servers that are proxying your requests all went down. And so, yeah, it's important to draw a distinction between liveness and security in these systems because users may, like, be afraid that liveness means that they have lost their keys when really it just means that the counterparty that's servicing it on the other side is down. Mm-hmm.

Nicholas: I paid a fair amount of attention to this, like, passkey meta in the 4337 world, which is interesting because it puts quite a bit of control in the hands of the users, although it does put more weight on the passkey managers, like the iCloud keychains of the world. But it's interesting to hear that you're thinking about the Telegram apps, which I think are actually probably far more popular than any passkey solution thus far. And maybe the UX of them from a user perspective is, like, far superior, but traditionally pretty bad on the security front and custody fronts. Mm-hmm. Are there any particular things that you see there where it's, like, that maybe the CT is not paying attention? because it's not, you know, the latest wallet from a big company, but instead there's some really exciting thing happening on Telegram or somewhere else in the wallet space that people should know about?

Stephane Gosselin: For sure. Like, Telegram is the cutting edge of user experience. So we helped build a Telegram bot called Alfred and had this funny moment. A few weeks ago, where I was getting Hayden from Uniswap to use it, I was telling him, like, "Hey, like, why are you, like, building stuff on, like, progressive web apps or, like, building your own wallet? Like, look, like, a chat interface is clearly the best way to go about it.". And so we developed a feature with Alfred where you can speak to it. So you, like, you, you know, just like speaking to chat GPT or something, you, like, open up the microphone, you say, like, "Hey, I want to trade this for that on, like, this chain.". And then it's like, you know, it goes and it does all the routing and the encoding of the transactions. It pops back, like, "Is this the trade that you want to do?". And you say, like, "Yes.". And then it executes. You can do this with, like, really complex limit orders, which is really cool. So you can say, like, "Buy this coin now, but then sell it if, like, it goes down by more than 5%.". And then it will store this order for a period of time and, like, have the limit order execute whenever it needs to. And so it's, I think, the folks that are building that area are really on the cutting edge. The challenge that they're facing is delivering these capabilities while remaining non-custodial. And so that's, like, a big reason why, you know, a lot of the unlock of building OneBalance was being close to that space and understanding the problem set that they were dealing with when trying to deliver these next-generation experiences. They needed accounts that were a lot more capable than the typical EOAs or smart contract wallets. And so, you know, credible accounts do deliver those capabilities.

Nicholas: Very cool. On that Epicenter call from, I think it was about 10 months ago, but maybe it was a little more than that, you mentioned that UniswapX and this kind of RFP marketplaces, I guess you would say, off-chain order books. How would you describe them? What would the encompassing term be for things like UniswapX? RFP platforms?

Stephane Gosselin: Yeah, it could be, like, an RFQ. I mean, a lot of people are calling them, like, intent DEXs or intent bridges as well. Could, yeah. But I think, like, an RFQ platform is probably a good way.

Nicholas: I thought it was very interesting. you mentioned that the, because of their nature, they sort of, at the time, you predicted that, or people were talking about it shifting liquidity off-chain because off-chain market makers could fill those orders without having to experience the, you know, without the cost of rebalancing a pool on-chain. And so there would be no reason to put your liquidity into on-chain DEXs. Has that played out? What's the current status?

Stephane Gosselin: I haven't looked at the data most recently, but I think it's mostly played out. I know that the UniswapX team has had some trouble with reliability of execution over a thing.

Nicholas: Oh, really?

Stephane Gosselin: Not a surprise, but...

Nicholas: Why do you say not a surprise?

Stephane Gosselin: Because it's inherent to the model. Because they give last look to the users, therefore the market makers on the other side are worried about toxic flow. And so then the market makers are quoting much wider and then may not bring the transaction to the chain if it falls outside of the execution that they expected. So, again, this is all, you know, expected because of the order flow trilemma. But I think all in all, what we've expected to take place did take place, which is trading over all the majors is being quoted by market makers and being filled by market makers. And then sort of long-tail assets that really only have liquidity on-chain, those are still being routed to the chain. But if you are an LP for like an ETH/USDC pool, you're losing money. There's no way you're making money because all the good orders are being filled by the market makers and then all the terrible orders are being put on-chain. And so, you know, if there's anyone that's an LP on a USDC/ETH pool, please explain to me how you're making money because I don't comprehend it.

Nicholas: So does that? ultimately, I mean, is that the death of, you know, the market? AMMs for sort of current, you know, for USDC/ETH, for these big pairs? Does all of the liquidity end up moving off-chain such that you only get a price based on what the prior transactions are, not based on, I mean, I guess that's always been the case given that they're rebalancing. But yeah, is this the end of DEXs on-chain?

Stephane Gosselin: I don't think so. So I think the paradigm of AMM is changing. And I think people are realizing that different assets seem to have different constructions. And I think, you know, even the Uniswap team is very cognizant of this, which is why Uniswap v4 is so programmable, is because the question is like, who's providing the liquidity and what do they expect, right? I think we're still seeing folks doing rental of liquidity to market makers. One question that I have is like, why do like teams that are launching a token go to someone like Wintermute and like Shrek market making deal as opposed to use some kind of lending that's on-chain to lend out to those folks? And I think that's sort of like the new frontier of AMM design is how do you lend out from retail or from foundations to solvers or market makers such that, you know, the capital is still available on-chain for them to use, but instead of being sort of just-in-time rental, it's like longer-dated lending. So I think the meta of AMMs is shifting away from this just-in-time, always available stuff to you have parties that are holding assets that have different capital costs and utility ratio over this stuff. And then you want to create a market between them and market makers that may be able to utilize these assets more effectively. And yeah, that's the next place where I think all these DeFi platforms are going to head towards.

Nicholas: Fascinating. We've reached the end of my list of questions. Is there anything about OneBalance that we didn't get to that people should understand or any technical aspects that you think are worth diving into?

Stephane Gosselin: Account registration is open. So people can go and pre-register for their accounts. We are going to be slowly rolling out more and more capabilities over the course of the summer and opening up integrations. But if you're a user and you're curious to be a part of the journey of doing these OneBalance accounts and simplifying your cross-chain life, then yeah, go ahead and register your account. If you're a developer that's building an application or a wallet and you want to expose these capabilities for your users, then please be in touch and we can talk about how we can help you do that. And then for anyone that's building anything chain abstraction related, come join the party. We have this cake working group. We have the fellowship of the OneBalance and we're hosting events and conversations all the time. We'll have a big event at ECC about cake and sequencing. So we'll touch on the topic that you mentioned earlier. What's the difference between sort of some of the USC stuff and OneBalance? So you have an entire day that's being co-hosted with Espresso at ECC. And so if you're interested in this topic, please apply because it'll be a really fun event. So those are all my call to actions on where folks can interact with this stuff.

Nicholas: Very cool. Actually, I realized I did miss one question. Tell me about your working relationship with Ankit at Frontier. You've been working together for a long time?

Stephane Gosselin: Yeah. I initially met him, I think, in 2019, late 2019, when I was working at Numeri. And he was working at Token Analyst at the time. And we collaborated on a few things regarding Razor. And so about a year and a half ago when I started Frontier Research, I linked back up with him and he was looking for the next thing to work on. And yeah, we decided to start this research collaboration together. And so yeah, it's been really fun. It's been a thrill to work with him on it. And I feel like we've been able to publish things that have opened maybe like the Overton window or opened people's minds on different design patterns and hopefully contributed to the space in a meaningful way.

Nicholas: Yeah, that's great. How many people are researching at Frontier these days?

Stephane Gosselin: We're pretty lean. So we're just a team of three working on Frontier Research itself. A lot of our team is just oriented on OneBalance. And so OneBalance is a separate company than Frontier Research. We sort of keep Frontier Research for more of our ecosystem-based efforts. And then OneBalance is being structured as sort of a proper company that's doing the whole hiring team and building product stuff.

Nicholas: Got it. Very cool. Stefan, thanks so much for coming on the show and telling us all about OneBalance. This was very interesting.

Stephane Gosselin: Yeah, of course. Thank you for having me.

Nicholas: Sure thing. Hey, thanks for listening to this episode of Web3 Galaxy Brain. To keep up with everything Web3, follow me on Twitter. @Nicholas with four leading Ns. You can find links to the topics discussed on today's episode in the show notes. Podcast feed links are available at web3galaxybrain.com. Web3 Galaxy Brain airs live most Friday afternoons at 5 p.m. Eastern Time, 2200 UTC on Twitter Spaces. I look forward to seeing you there.