L2 Interop Working Group #17

Transcript

All right, welcome to the L2 interop working group. We have a few agenda items for today. Starting off with updates on interoperable addresses aka chain specific addresses. This is ERC 7828 and 7930 presented by Unruggable and Wonderland. Uh next up, open intense framework. some updates there and a demo presentation overview of some work from Nethermind Starknet. And then last up um open discussion, many updates, comments for the work happening around the 7-day withdrawal window reductions. This is

for optimistic roll-ups and the 7-day windows. Okay, cool. So that is an overview of the agenda and I think we can kick things off with agenda item number one. Whoever wants to to start there. Orca. >> Hey. Yeah. Thanks. Thanks so much Josh. Um I'll share um some things to look at I guess quickly. Oh sharing is not turned on. Um if you can help Josh. >> Yeah. One second. Sorry. >> Okay. Good to go. >> Um yeah. So, as Josh mentioned, this is um um this is uh interal addresses. So, this has been um ongoing for

>> Can you see your screen just yet? Okay. >> Yeah. One second. I'm just getting the permission. >> Can you see this guy now? >> Oh, yeah. Works. Thank you. >> Um so, this is a site just giving an overview of some of the work which we'll be um publishing. As Josh mentioned, this is chain aware addressing for the Ethereum ecosystem. It actually the standards allow for addressing for nonem chains as well. Um this has been um collaborative effort between a bunch of people. Um some of the logos are here. If um your organization has been a part of it and isn't um shown here, then definitely do um give us a shout. Um in terms of why these addresses are needed, um obviously um getting addresses and chains um joined up in the right way is

important. wrong chain loss funds in some cases. Uh just generally readability typos and there's also like a reliance on a centralized um chain list for a lot of um information in terms of chain IDs mapping to chain names interoperable addresses um try to address much these in in one fell swoop. So um chain specific addresses to prevent errors um powered by an onchain onchain registry a compact format for use in on crosschain messaging and intent declaration. um think about things like human readability um and yeah as I mentioned universal compatibility um how does it work um essentially there are these two ELC's two layers the 7930 which is the um the binary representation and a simple human

readable format and 7828 wraps that in um ENS for both um address resolution but then also chain name resolution so you can put in Alice at base um these specifications are um approaching finalization so I Thomas from honorable will talk a little bit more about um where we're at with those um and the states of the chain registry. Um and yeah, we're working on essentially tooling stuff to make this a bit more accessible and digestible. So um essentially if you look at type ether eth um this is a demo site powered by the um addresses module of the interrop SDK um it essentially breaks down and makes it easy to see okay when you've got if you go from this human readable address um how then that gets turned

into binary format what the different parts are you can see the representation there um and all this available in the wonderland uh inrop um SDK and specifically the interrop addresses module uh there's some FAQs is there as well. Um but uh as I mentioned uh we've made a lot of progress. There's still a few things remaining uh which I think Thomas uh will talk about. Um uh and generally we're working with we're talking to wallets about um integration. Uh we're seeing this being integrated into more and more standards. So even um today clear signing the clear signing effort I think 7730 um we were talking about this. So um uh excited to see it I guess um approaching production. Um, and

I'll hand it over to Thomas. >> Perfect. Uh, thank you, Walker. I'm Thomas from Unugable. Uh, we work for the ENS DAW and we've been working extensively with the team at Wonderland on these specs. Um, so I'm just going to give a brief update from the ENS end and from the spec end. In terms of uh 7930 which is the the binary format uh we've been iterating on the exact terminology and semantics of that specification to make it as accessible as possible. Were very close to kind of completion on that and then we're going to be um creating a pull request to get that into the actual

Ethereum ERC's repo. Uh the 78281 adds the ENS um specific functionality which is uh a chain registry resolver. Um that is the resolver for the on. E uh second level ENS name. There was a temperature check posted by Josh on the ENS forum to get a read of the room if uh the ENS community were happy to um assign ownership of on.eth to the multisig that will be leading that effort. Uh I've posted that link in the chat. Um the general consensus from the ENS DA was a positive one. I say the general

consensus it was completely positive. No one um disagreed. Everyone was very happy with it. Um so in terms of next steps I will be putting together the call data to um propose an executable proposal to the ENS dow to have that assigned um to a multi-IG which uh will then allow us to set uh the chain resolver as the resolver for that um ENS name which is the resolver through which all of this um chain metadata discover recovery uh occurs.

In terms of the state of that chain resolver, that uh repo is complete and ready to go. Um we had a discussion today between myself and the uh the Wonderland team. We're just working to add some final touches including aliases whereby um chains go by multiple um identifiers in different contexts. The obvious ones being OP and optimism or ARB and ARB one. Um such that we kind of have the functionality that those can all resolve to the same uh ERC 7930 identifier.

Orca is uh piecing together kind of a finalized uh list of chains, their labels and the metadata associated with those chains. The intention was that we would post that on the ENS forum as well as on ETH magicians and we would circulate that through social media to kind of get the the eyes of chain operators on that list to make sure that uh everything is correct and in order. Initially, we're intending to have the administration of the resolver controlled by a multi-IG that will have representatives of Wonderland, uh, Unruggable, the Ethereum Foundation, the

ENS DAO, etc. Uh and then over time once this is kind of solid solidified and everyone's happy with the the state of things we will assign authoritative ownership to the people and representatives of the chains in question and um we will kind of uh remove any administrative control from that multisig. So at that point the chain will own all of their um metadata and all of the the um information associated with it. Um I think that that is uh everything. Um yeah, once the executable proposal is

passed, we're just doing final testing of these contracts. um we'll kind of test it in production on um the oneth uh name and make sure everything uh is working. Then the intention is to create pull requests to uh established frameworks like VM and ephers such that we can uh get this integrated into uh clients, wallets, DAPs, etc. That is all from my end. Happy to answer any questions.

>> Hi, this is a great update. There's just a couple questions in the chat for links to the SDK and the website for interoperable addresses. Thank you. >> Yeah, Orca, do you want to drop a link? I think the website is not quite ready to be live yet. Is that correct? Yep, that's right. We'll um we'll definitely share I guess with this group when it's there. But I shared the link to the MPM package. Perfect. Any other questions?

Cool. We can move on then. Next up on the agenda, OAF updates. Uh maybe we can start off. Let's see. Is Barnaby here? Are you available to chat to talk? >> Hey. >> Yep. Can you hear me? >> We can. >> Nice. Um I'll show some slides just quickly and then I let I know there's other people in the room who are also part of this. So like briefly what happened uh just before Defcon connect is we a bunch of us went to HCT uh from Ethereum Foundation, Open Zeppelin, Wonderland and many many other teams Lei and and

other teams that are now dipping their toes into the open intent framework. And the idea of this week that we spent together in in Patagonia was to try to accelerate um some of the integrations or components of OAF towards having um an end to end demo of an intent that was uh secure and and propagated through the OAF layers. Um and I think we made actually a lot of progress. Maybe some people will discuss some of those, but I just want to show u an overview of of what was built. Um, one of the first things was a payment

request demo that was actually using the interoperable addresses. Um, and OAF at the back to to settle the intent. uh Misla from Bonomy and Ky they worked on uh crosschain deposits using composible batching uh so that apps have access to a toolbox that allows them to just very easily provide interoperability tools to their to their users. Um we had some work on the compliant resolver. So using 7683 make the solver uh understand the orders so that yeah you can create deeper markets with more solvers that all follow the same um standard.

We wanted to harden also the oracles. So proposed like an optimistic game uh that secures an intent. So the solver wants to settle. Somebody can challenge that settlement and this is eventually resolved uh using the broadcaster which is this trust minimized um proof going over the canonical bridges. Someone worked on uh proving the fields. So instead of storage proof using ZK proofs which I think was really cool. And then we had another project that was mixing uh together AI agents um resource locks uh TE's and other like tools in in one beautiful um mix of of all of this. Uh

yeah I think that that's it. But we had a a lot of fun and I think it was also very productive to to show the like the the promise of OAF and and already what's available which was quite a lot like definitely sufficient for us to make a lot of progress in in three days. >> Awesome. Thanks. Uh Pepe, do you want to share anything next? >> Yeah, sure. So I just want to reiterate uh what Barnav just said like we had a very nice time in Patagonia. I appreciate everyone who who attended and everyone who supported um since then or like around those days a couple of

updates regarding if and settling. So the main audit of the settlement contracts was released. You can find it on the contracts repo. We've also audited the first part of the broadcaster protocol. So like the core contracts in in broadcaster have been audited. Um I believe that that audit is not still fully public but we will be shared relatively soon. Um an upcoming audit will take care of all the provers for each different network type. Uh one of the points that was raised or was identified during the Patagonia event um it's it was like the fact that the

solver could not support arbitrary callbacks and could not kind of support basically random actions on top of just moving tokens. There is already basically a solution for that in the solver uh repo. So if anyone is interested in following up you can you can go and take a look. Um now what's happening like what are we now focusing on? We are focusing on broadcaster and evolving the the provers and making sure we have like secure and compatible provers for everything and we are focusing on on boarding um the long tail of furries. So uh we will be able to

share much more information on how we are feeling about it but generally speaking we've identified that the biggest um requirement is basically having a solver or a solar network that supports your specific new L2 and the solver will basically be able to do self on boarding. Um but lot of networks doesn't want to run that infrastructure themselves. So we are looking at ways on how to facilitate this or how to play around with liquidity management. Um so yeah it's it's an active point of conversation. So if any of you are interested in participating in these

debates, if you know of an L2 that wants to get on boarded and is having issues with other intent providers, happy to to get in touch. And then for the big question of what's being printed, uh, it's a deer, uh, like a wine bottle holder beer. I will send you a picture forest. >> Nice. Please do. I actually also have one remark that is OIF related, not just the printer behind Pepe. And that is a a few days ago on the OAF drivers call um to some people's surprise um we kind of identified a potential obstacle for OAF

which is that the uh even I would have thought negligible gas cost increase of something like an OAF rapper of 10K might actually be a big shows stop for some uh solvers and and even aggregators. And so I I I I was wondering if anyone in this call had additional input on what it would take for a standard that is slightly less gas efficient to actually be more attractive to them.

I mean my my thoughts just to to share with the rest is obviously um much more kind of streamlined contrast will allow for optimized gas use utility having a standardized wrapper or layer on top of that h may increase the gas cost but will definitely increase the uh compatibility surface. Um, so I think it's also worth checking like if anyone on this call or checking the recording does have specific concerns um, worth mentioning. We've been talking with the Lei and across teams for for this and they also have their own thoughts and and different approaches for this.

Cool. I think we have a few more updates on OAF. Mislav, do you want to hop in next? >> Uh yeah, sure. Hi everyone. Uh Mlav here from Bconomy. Uh yeah, I I actually wanted to share some slides as well, but I joined over the web uh web Zoom, so it's not allowing me. Um anyways, um what we were working on, I give a shout out to um Volts FYI and Kimi uh who is Anon. So we'll we'll stop there. Um so the idea was that uh we combined the OIF um 7683 with 4337 with 7579 and with a few non ERC things which is by economy

super transactions and uh volts FYI call data generation to achieve something that's kind of a big deal in DeFi is rebalancing vaults from one chain to another without any dust. in between. So like the problem that you had, the problem space that you had before was if you like go from a USDC volt to a USDT volt from like arbitrum to base. Uh the problem is that when you unwind, maybe at that point you still have information exactly how much you're going to get from the vault. Sometimes you don't because like linear calculations like for for curves for calculating interest rates can can mess up with you. But if you like withdraw

from a vault then you swap to another token then you call a bridge then you you know supply approve and supply to another a vault on another chain. The idea is that this should all be done in a single signature. Now this uses for the single signature stuff we use the byonomy merkel tree uh ERC7579 validator module uh which enables basically singleclick execution across multiple chains. It's very very similar in design to the Merkel tree validator uh from from EIL Ethereum interoperability layer essentially. I think it's it's part of our codebase that's uh that's that's being referenced there as well. So that's I I'm assuming that's also something that's going to get standardized quite quite soon. Um, and then we used this composable

batching module. And then we used basically one of the features that I'm the happiest that OIF currently has. Uh, which is the fact that with OIF, you don't have to provide the exact same value to the function call that you quoted. For example, you quote um an Ethereum uh like you quote moving USDC from one chain to WE on another chain and then you get basically um quote that says like for 3,100 USDC I'll give you one WE or something like that. Um if you are essentially in in a lot of like other bridges you

would have to provide the exact same value that you quoted before but this you quoted this before you started execution. So before slippages were incurred on chain you didn't know exactly where in the block your transaction is going to get set. Maybe you get like some better some worse execution. So you could get very very precise. You could get within like half a percent of of precision but you would always leave some dust. And this would incur uh compounding execution inefficiencies. If you had 0.3% inefficiency on every step, you would have five steps. It would escalate to 1.5% and suddenly your solver or mult multi-chain execution aggregator is no longer competitive with anything on the

market. This has made it so that right now how these multi-chain uh vault optimizations are done is that solvers actually hold inventory of vault tokens uh often and they will quote you for this. Oftent times for smaller vaults this will result in like immense slippages like 60% 70% something like that. Um so in this case the only slippage we incur is the like USDC to WE uh open intense framework slippage which you know with the modular nature and the capital that's going to acrew there with all the big solvers I assume that's going to be an extremely competitive rate and all the withdraw from uh vault swaps uh and then supply to another

vault is done through this composable batching. So it's essentially a zero slippage operation. So yeah, that's been uh coded in the three days uh that we were there. We did a live demo. It worked really nicely. Um I mean it's demo is kind of janky to be honest. It was it was um was lucky that it worked but uh it demonstrated the point across. Um and yeah so the idea here is also if anyone is interested I would like to propose uh we already have the code audited ready to go but for people to comment and maybe make composible batching into an ERC I would love to see it uh being uh essential part of the Ethereum stack to be honest it's it's it's shown itself to be immensely useful

for us and our clients when when used. Yeah, that's it for mine. >> Thanks, Kaf. Anyone else with any updates on OIS stuff? Cool. If not, John, I think you're up next then. >> Okay. Um, hey everybody. It's John Church Nethermind a product lead for um uh our for our institutional in DeFi and also our our Starknet division. Um, but I just wanted to showcase, you know, we

we we were really excited about building a an extension of the OIF on Starknet. And so, um, we've I'll share my screen. Uh, we've built this out a Cairo implementation of the Solidity contracts as well as a uh uh solver in Go instead of the the Open Intense Rust solver. So, um, you know, if anybody's interested in checking this out, I'm going to share this in the chat. Um, and you know, we have we have the tests built out. We have, uh, uh, um, you know, everything fleshed out for anybody to get started and and of course a template solver. So, um, you know, anybody would want to take

this and and, uh, uh, customize it to different strategies or or whatever your your competitive analysis is. Um so uh and we also liked it so much that our our uh lead dev on it decided took it and and built a uh um a hackathon project with it and implemented it. So Matt, if you want to share off what you built. >> Sure. Uh yeah. Hey everybody, my name is Matt uh also from Netherland. Yep. I can share my screen here. Um, new to Zoom, so excuse. Uh, let's see.

Set permissions quick. >> Uh, in order to share SC the quit and reopen, is that fine or would should we just skip this? >> Maybe try. Usually, you don't need to actually restart. Just try now that you've granted. >> Gotcha. Oh, yeah. I think you're right. Cool. So you guys can see my screen now. >> Yeah, we can. >> So yeah, here is the project we built for the hackathon. Uh the only difference between this and the one that we built for Nethermind is that we added support for the new network like a proof of concept network called Zarknet.

Zarknet, it's kind of hard to pronounce, but essentially this all runs off of that. So I've already connected an EVM wallet and a Starknet wallet. So here I'll open up this and then if we open up we're also running a solver for the hackathon. So if I pull that up now we can see the logs for that. Um okay cool. So if we pick a chain uh we can just show off go stark net keep it simple. Um for this demo we're using just a ERC20 that we deployed.

Sorry transaction brings those tokens. And then we'll see over here we'll see the solver pick up the order and start to fill it. And with that, I mean, I can share transaction hashes. But with that, you will see that the one dog coin is now sent to the Starknet address.

So, so that's it. We just we just wanted to celebrate a win, share off how how we built a an an implementation and the like. So, you know, it's uh uh you know, no no major protocol updates or anything like that, but but uh we're we're extending OIF to Starknet and and uh and yeah, the UI was pretty cool. I was I thought they did a good job at that. >> Thanks, Matt. >> No problem. Uh how do I stop Or is it Oh, right here. Cool. >> Love it. Super cool. Thanks, John and Matt.

>> Yeah. Thanks, guys. I think it's great to see progress is progress and it's great to see continued adoption of shared infrastructure. So yeah, thanks for coming on and and sharing that. Any questions on any of that? Oh, if not we can move on. I think we are at the final agenda item for today, which is discussion on a continued discussion of what we touched on on the last call, which is the 7-day window reduction. Um, and maybe just to set a bit of context for folks who are not familiar, I think

most everyone here is, but just in case, um, what is this? Why do we have 7-day windows? Just really quickly, well, and actually do has a great post on this. So, I'll link it in the chat in a second. Recommend reading for anyone interested. Uh, TLDDR was originally set to allow enough time for a social response in case of any sort of attack from, let's say, malicious nodes or builders and to prevent funds from being stolen. Downside, of course, of the 7-day window is that it's a bottleneck on UX, liquidity, assets, and just generally users ability to seamlessly do what they want to do across chains. Um, so there's been a bunch of discussion and renewed interest. This is not the

first time this has come up. Of course, it's not a sort of new piece of information. This was by design with an understanding of some of the sort of limitations. Um, and I think there's been a bit of or there's definitely been a bit of renewed interest in seeing what we can do given what we've learned and given what we now know around um, paths to reducing this to something like one or two days. I think there's fairly broad agreement that there are significant benefits. There's no um disagreement that the benefits are meaningful. Um but at the same time, this is of course a sensitive area. We want to be mindful in how we approach this and not just sort of yolo it. Um so yes, we've had discussions

with folks from arbitrum, optimism, unis swap, L2B around what is the right way to do this? What sort of data do we need to gather? um and how can we do this in a way that of course doesn't take months and months but allows us to get sufficient confidence in in what we're doing here. Um so maybe that's just yeah a bit of context. I see we have Ed here. Do you want to jump in with anything? >> Sure. Yeah. So from my point of view and I think our team's point of view um what we would need to justify reducing the inclusion time assumption would be some kind of analysis that shows that doing

so would be safe that is against an adversary who is very highly motivated and capable. Um, can we really guarantee that a party who wants to get a transaction included on L1 Ethereum can do so within 24 hours? Um, and in order to establish that, we need to think about sort of what assumptions can we make about Ethereum. Um, because I think it's easy to get to a one-day delay if you make unrealistic assumptions, right? Like an unrealistic assumption would be to assume that if I want to submit a transaction at time zero that at time zero it will be in the memp pool of every local mempool of every builder and

will stay there even if a highly motivated and capable adversary is trying to prevent that right that would not be a realistic assumption to make because we know that adversaries can in fact mess with meool propagation try to destabilize the P2P network and so on So in order anyway in order to get to um in order to get to any confidence in an assumption about inclusion time which I think is what this really is about uh really requires like careful analysis of all the different ways that an attacker could try to prevent inclusion of transactions and I don't think we have anything like that kind of analysis that's been done to my knowledge by anybody at this point. Um and that's

really I think that's really the missing piece uh that would be needed to justify making a making a particular change >> right and just to highlight for the group what we need to understand is what is the maximum cost to guarantee a single transaction can get in within a certain amount of time in this case 24 hours. Well, the question is can we even guarantee that at any cost >> because that even that is not established. >> Right. >> Right. There are some just to expand a little bit on what uh Josh said there there are some kinds of attacks that are economic in nature and there may be economic responses to those attacks

where an where honest parties could spend some money to try to sort of somehow outbid an adversary who's let's say bribing block builders. But there are other attacks that are not economic in nature. And you know this being a security property we need to reason from a set of assumptions about what Ethereum what guarantees Ethereum can provide us and then figure out okay given those assumptions about what Ethereum can provide. Here's a procedure that we can embed in in our code that would guarantee inclusion within 24 hours or 48 or whatever number uh whatever number uh we might pick.

Right. >> And that's kind of to me that's the missing piece is um you know what what are the assumptions about L1 and then what procedure from those assumptions can get us to a guarantee of inclusion. So I shared in the chat some not a full answer to this question but um some analysis that Dono from L2B has put together. I think Ed, you've pointed out that this doesn't quite fully cover some of the more sort of adversarial >> Yeah.

>> Yeah. This um this, as I understand it, Dono's formula is based on a paper that our team published >> um that analyzes one type of economic attack. Um but um it's only one of the tactics that an adversary could use. and combining that tactic with other tactics would um uh means that the results of the paper don't give you any guarantee that would apply to Ethereum, right? It's so it's it's maybe a piece of the analysis that might be needed, but um it doesn't uh it doesn't cover um some of the really significant uh

potential avenues of attack, >> right? And if anyone else wants to jump into the discussion, feel free. Um Ed, how is your team sort of approaching next steps here then? Potentially, are we are there folks on your side that are looking at a more thorough analysis? the the the really tough part is um there's a bunch of tough pieces of this. Um one of them is how to analyze the possibility of old school denial of service attacks like say network flooding attacks against the uh against the party who's trying to get a transaction included. What kind of assumptions can we safely make about ordinary parties ability to uh let's say reestablish connectivity to Ethereum um

if they're subject to such an attack from a highly motivated adversary. That's one piece that I think is hard to model. Another piece that I think is hard to model is uh P2P propagation and mempool management in clients because uh clients tend to use client specific heruristics to decide how to manage their mempool. what to keep, what to throw out when it gets full and so on. And so if we're going to make an assumption that an honest party can keep their transaction in the mem pool of um all of the block builders um for an extended period of time against a hostile adversary trying to prevent that then we need to have some way of reasoning about say meool maintenance uh policies of clients and how resistant

they are to uh manipulative behavior by uh by other clients. So, we don't really even have a have a handhold on that problem, I think. >> Right. Got it. >> Yeah. I guess I'm I'm trying to think through then what is the sort of best path forward at this point? It might be taking it back to the group. Um, I know, yeah, optimism is also interested in running their own analysis on this. Um, as well as unis swap and potentially others. Pepe, you mentioned potentially

open zeppelin might want to jump in and and help if if helpful. Um >> yeah I mean if people if people have um analyses about say uh the impact or what what we can assume about um let's call them old school denial of service attacks or what we can cons um what we can assume about attacks on P2P propagation or mempool management um that would be really helpful. I think those are missing pieces. Um, and if anybody can figure out like how to reason about the security of properties of that against an active motivated adversary, uh, I think that would help to fill in the fill in the gaps.

>> Okay, cool. That's helpful. Got him. And Ed, I'm not sure if you're the right person um from your side to answer this question, but may be helpful to share sort of the latest on how your team is thinking about the alternative or another approach around accelerating something like a two of three system. I think called it pragmatic fast finality in the past, >> right? So yeah, there's things you can do if you um uh where you have like a a ZK proving and optimistic proving as well as some kind of say security council um uh veto uh type of situation um and where you want two or three of

those to happen. Um now one thing to note is that security council affirmative security or let's see so a security council response also relies on non-ensorship or an assumption about the security council's ability to include a transaction. The other thing to note is that ZKbased proving is also subject to censorship attacks. The difference is that censorship of posting a ZK proof uh doesn't allow an doesn't um harm the safety of the chain but it does uh prevent it does delay settlement. uh and there are realistic scenarios where a motivated adversary can delay the

posting temporarily censor the posting of a ZK proof in order to delay uh settlement and cross-chain interop for whatever reasons they might have. Um, and that's another area that I think is under analyzed um is um basically um de uh attacks that aim to delay settlement uh as opposed to defeat it. >> Right. So I think even with the two out of three system, you're still subject to some censorship considerations.

um as well as the obvious ones around cost um the cost of posting frequently and so on. Um but yeah, we're absolutely working we the offchain team in R&D are working toward a system that um would be in the spirit of of the two of three >> and not to like hold you to any sort of specific date of course but but how are you thinking about sort of the road map here and is this like a 2026 goal further out? We're not talking about dates. Um and um I'm being a little cautious here because I'm not sure what we've said publicly.

>> Sure. Sure. >> Um but um it's been it's been a tough Maybe one of my teammates on the calls um on the call um knows this more clearly what's been announced and what's not been announced. Uh and if so, please do speak up. Um but um it's an effort that's been underway for a considerable length of time. Um and I gave a talk a public talk about a year ago about um a scheme for uh this sort of two two of three um or uh style of uh of proving. So it's something we've been working on for a long time as well as the underlying sort of zk proving piece.

>> Yeah. No public time communicate on this yet. >> Thanks Alen. >> Cool. Got it. Thanks Alen. All right. Um, well, yeah, I'm not sure that there's much else to say on the topic at the moment. If there's anyone else here, I think some of the other folks that are more active in this discussion were not able to make today's call. Um, I appreciate Ed. Thank you for making the time to come on today's call. If anyone else has anything to share here, we can keep going. Otherwise, maybe we can wrap the call up here. And I'm sure this won't be the end of the of the 7-day discussion, so can continue at more to share on that, I'm sure, in the coming weeks.

>> Yeah, I'll just add quickly. Uh Josh, I'm happy to work with you on on trying to pull in the right people uh from other teams to try and check some of those boxes that Ed listed. Um there's a few that we're working on internally. there's others that I think we need a little bit more support and expertise on uh if if we want to try and um you know make those assumptions clear uh and then you know raise any sort of disputes we need to about those assumptions and get to a point where we could feel comfortable um changing that that that period. So um just let me or let me know if there's anything we can do to help uh her cats outside of uh this group or or just broadly.

>> That's great. Yeah, I will definitely hit you up about that. Um, yeah, I think right now we're in a bit of a position where we're all sort of like standing around pointing at each other a little bit. Everyone's busy and and no one is like really has the bandwidth, I think, to to jump in and spend the necessary time to to do the proper analysis here. But, um, I think with maybe a bit of thoughtful hering, we can we can get it done in the coming weeks or at least make some progress in this direction. So, yes. Uh, and if anyone else has interest, comments, anything around this, feel free to message me or anyone else here. Drop a message in the chat.

>> Cool. Okay. Um, awesome. Thank you all so much for joining. See you all next time. >> Thank you. But