Post-Quantum Transaction Signature Breakout #9
Post-Quantum Transaction Signature Breakout · 27 May 2026 · 54:15
Post-Quantum Transaction Signature Breakout #9, held on 27 May 2026. These breakout calls cover how Ethereum transactions could be signed with post-quantum signature schemes. Two frameworks, one FORS-based with a variable signature budget and Riva Labs' NiceTry, were converging, and rotating the key on every transaction was proposed as the default.
Speakers
Topics
From Post-Quantum Transaction Signature Breakout, hosted by Ethereum Foundation.
Transcript
Antonio Sanso: Hello, everyone.
Matteo Vicari: Hi, Antonio.
Antonio Sanso: Oh, dope. As usual, I'm a bit earlier to check if everything's okay. I will try to share my slides. Alessandro. Do you see my slide, right?
Matteo Vicari: Yes?
Antonio Sanso: Alright. As you should wait a few more minutes, and we'll start.
We just wait a couple more minutes, we'll start.
All right, let's kick it in. We are the breakout room number 9 for post-pandemic transaction signatures. Just… Quick comment. Today, we are not having any guests. I want to check with you, with the people here, that you are all on the same page. This is call number 9, so… I want just to recap what we've been doing in the previous 8 goals, and see if, You guys agree with the status quo? So, I'll start with the presentation. Can you guys see my screen? I think it is. Okay, great. So interrupt me at any time. Again, just having a few slides to having a recap of where we are right now. Just saying that, we're breading as well.
I will use some of the comment of today to include this in a blog post that should appear in the next weeks. Of course, I'll try to credit everyone if… There is some comments that I can understand the source. So, this is more or less the… this is the data of the transaction signatures for this post quantum. There are, like, 6… boxes. Of course, let's try to spend a couple of words about that. We want this transaction signal to… to be post-com secure, but of course, we want to be as well classical secure. We want this to be efficient, so as small as possible. Of course, we can never meet the… 64 bytes, but yeah, we try to do our best. We want to be fast to sign and verify, with low bandwidth.
We want to be simple to implement. With low complexity. As well, low memory footprint, and no heavy hardware needed. We want no dresses it up. Compatible with validators, and a graceful, updatable path. I want to be robust, so long-term security margin, we don't really want to Migrate to a new signature every year. That's basically it. This is the router. This is what we have from NIST. Again, we've already seen this this few weeks ago. As you can see, there's no rod, it's all green, so it really is a bigger poison. Scenario. Just focusing on the slide on the signature side, just to recap. list. Just one of the… columns in the previous slides, but the signal size is one important one. So, as we know, ECDSA has 64 bytes, the smallest
Post-quantum signatories is Falcon, which is 10 times bigger, and… up to SPHINCS Plus, that is 122 times bigger. Tomorrow. So far, I… Found two, basically two scenarios. that are important to cover. I'm not saying they're the only ones, but these are the two that I see the most. And the first one on the left is the… infrequent high-value transactions, they can be a treasury, can be a Dow, so they have… this… people have… All that have hardware wallets, and ideally, save with a K of N Multisig. And the right scenario is, like, everyday low-cost signing. That's what we do, for example, with MetaMask on a browser wallet. So, let's set to the scenario for the first.
So the low… the high value and infrequent transactions. So, if we see the demo again, what do we want? We want hardware implementation, And threshold signatures. And we see only a row that has to green, and it's Dilithium. So, so far, we had already two people in the Ethereum sphere doing something about that. Of course, we have GKnox that's been working on this Dilithium implementation. for Ledger using an abstraction, did a really nice demo. At HCCAM. And, as well, recently there's science laboratories. That hopefully we'll present this demo next week… in the next two weeks at this call, so… Call number 10 will be… they did use what, ZKnox did for verification, but before signing, they have some MPC infrastructure.
Let's see what we can do for the… Browser wallet, so frequent and cheap transactions. So again, here we want to have a signature size that's not too big, and we want, as well the gas to be approachable. And we know already what we do in the long term with these things, because what really matters is not the signature size, but ideally we'll have a… signal aggregation that will low impact at the peer-to-peer mental layer, so we know that for L-star, we will have something like Lean-Lean SPHINCS minus. with the stranded signal recreation, the question is, like, what do we do here? for, until L-star. So… We've seen shrinks already. We had Mikhail presenting it, and in the… for Ethereum World, we had already a proposal that they're doing something similar, and we have Jordan from Nico that has in the call. Thanks for joining, Nico.
So, Jordan is a… The implementation of this compact plus fallback. And, it used sphinx minus plus FORS. And, yeah. We keep the state off-chain, and every 128 for signature rotate, and then we had a nice try that had SPHINCS minus plus. winter's needs, but now I have also 4s, so I just forgot to update the slide, sorry. sorry, I guess, from Riva Labs, I forgot to update the fact that you support Force now, and you can see the nice dry wallet, like Ger10, with, with Q equals 1, namely that they rotated the fourth signature every time, not after 128. For signatures. Two important things for going forward, and in my opinion, are not evacant abstraction, as we said many times, but it is…
above my pay grade, so it will need to be SED approved. Hopefully, we'll have this for Pegota. And what I would really like someone to help with, if there is anyone in… in the call that can help you with that, I would be really, really happy, to… since we are not gonna ship precompile, we really need to formally verify signature contracts in Lean. This historically used to be, kind of. big… task, maybe now with AI and machine learning. Should be… and could be a bit…
Alex: Glimmer. Ricardo and I have been working on, like, getting the verification of the signatures using Lean, and so far, it's looking pretty promising.
Antonio Sanso: Sorry, was there? Can you repeat again?
Alex: Oh yeah, yeah, we've been, trying to do this formal verification of the signature contracts using Lean, and it's looking pretty, Pretty good so far.
Antonio Sanso: Alright, who is speaking, sorry? I didn't see it.
Alex: This is Alex, and also Ricardo, who's in the call as well.
Antonio Sanso: Hi. Hi, Alex. Were you guys, by any chance, in Rome?
Alex: Yeah, yeah, that was us.
Antonio Sanso: Oh, okay, great. Can we be in touch after? I think I already replied Ricardo, and We… we… just, like, I mean, we can be in touch after the call in the next days. If you… I would be really happy to have someone helping here, if possible. So you already… you already look into it?
Alex: Yeah, yeah, and amazing, yeah, I'll take your contact after, and we'll… Keep speaking.
Antonio Sanso: Okay, great, thanks a lot. And, yeah, basically, in any case, it… this hole I had… What I would like to… Discuss now, huh? Yes, I see Nico, and the river laps Here… And probably… We know, again, we're not ready for SPHINCS models, the kind of parameters. We kind of know somehow, but… Do you think… And I will ask Nico first, and then Dariba. Do we have numbers in terms of, like. Size of 4 signatures, and the gas cost. That we… a ballpark that we can agree on? Because I remember from your presentation, Nico, there were, like. a zoo of combination you can really launch your script with, but is there any golden combination that is actually
Now being agreed on.
Nicolas Consigny: Not yet. I mean, I've been agreeing with myself, mostly, so I need to find people to agree with. The… last, update that I have is… a plain SPHINCS, pass for, signing registration, sorry, for plane registration in, Jordan. And this one really optimized for signer, For assigner work, so it creates a big… signature size, and it's, it's not the best. If we're talking about just FORS, so plain FORS, for the… for the compact signing pass, so it's just a Merkle tree with, FORS, leaves. This one is also proposed in the Jordan repo, and, yeah, I took two different parameters, and they give roughly the same signature size.
Which is 2.6 kilobytes. So yeah, I'm happy to discuss, the… The different trade-offs. For hardware signer, I have the one SPHINCS Minus that is the most optimized for signing work. And for laptop signers, I have the… SPHINCS Minus, that is the most optimized for gas costs. And actually, I published a repo, which is the EVM parameter research. And so we can do a sweep and find the best variants, depending on our use case, and depending on the cold data pricing and the kit track opcode pricing. So for this exploration, I took the next, call data. price, and I estimated that we are going to bump the K-track cost by at least 20%.
So yeah, happy to… to discuss the… optimal variance and to settle on a canonical one. I guess, yeah, happy to discuss that with Riva Labs or anyone that is interested in the topic.
Antonio Sanso: Alright, a quick question, Nico. So, I arrived at the conclusion that, the… like, let's say the nice dry wallet is similar, because at the moment they migrate to FORS, it's similar to Jordan, with Q, with your queue equals to 1. Do you think it's, like, is some… something that is… can converge, or are you really keen to keep your line of 128 for signature?
Nicolas Consigny: So the only reason there is a line of 128 signature is, Because Jordane is used on a hardware wallets, and on a hardware wallet, you need to do the key generation, which is very slow. And so 129 is just an arbitrary number that takes about 1 minute on the Ledger Nano. device, so this is why I kept it. But if we are okay to say that at onboarding, the user is gonna wait for 5 minutes on the hardware, then we can make this number Go up… Or we can just say that there is no number, and whenever the user is registering the wallet the first time, he can wait for as much as he wants, and when he finishes, he commits.
A certain number, Yeah.
Antonio Sanso: Oh, but I mean, with Q equals 1, there is no line at all, right?
Matteo Vicari: Yeah.
Nicolas Consigny: Yeah, with QE Code 1, you don't need a… a tree, basically, yeah, so you can just…
Antonio Sanso: Sorry, second, Matt, I'll give you… just to understand. Is Q equals 1 something that will work on a hardware wallet, or not at all?
Nicolas Consigny: I guess yes, I guess, yes, you just do a FORS. Whiskey, you come over one… Yeah, it would work. You would just add an extra rotation cost on every transaction. Which is, in my opinion, unnecessary, because you are using a few-time post-quantum transaction scheme. But yeah, it works, it works. Bose works.
Antonio Sanso: Okay. Okay, okay, thanks. So let's, let's see, what Riva Labs says about the… their numbers, and we can, I mean, we don't have to end up here, I mean, we can continue this if we don't finish today, or we can have a specific time.
Matteo Vicari: we can, talk in, we have a chat with, all the guys that work on, this kind of media. Just a question. Why, You need to, why it's better to submit more key in the first instance, because… For what we… we see, so far, if you can just put only one and rotate… the rotate is, really cheap, because You just need to put another address on chain that is representing the next FORS, like in the ephemeral tree first design. And the cost to every time resign with a SPHINCS, It's a really high cost compared to just adding the next signer, and… why… why it is approved? What's the benefit of this approach? Because this is something we were working on and trying to understand.
Yeah, this is just a question.
Nicolas Consigny: So this is really just because of the hardware constraint. There is really no other reason than the hardware constraint. So you need to commit, basically, you need to commit, to a tree in the design where Q is not equal 1, where you have a Merkle tree, you need to commit… you need to commit this tree in order to be able to reveal the leaves, and the size of the tree that you commit. You need to do the full KGEN for this. And so the more kitchen you do, the bigger the tree you want. the bigger the signing time that you need to spend, sorry, the key gen time that you need to spend. So basically the trade-off here is just, trading
a kitchen time, versus, gas cost in the EVM.
Matteo Vicari: Why? Because if you have to sign with the SPHINCS, you have to pay the cost of the SPHINCS. Okay? So, it's like, If we don't need to resign with the SPHINCS every 108 sign, we don't pay an extra cost, because the rotation, it's practically free, because it's just to memorize one address on-chain. So… I don't know why you say, are more gas cost, this approach, because in… for what I see, but maybe I missed something, because this is, my…
Nicolas Consigny: I think you're, you might be missing the… so here, I don't sign with SPHINCS all the time, I sign with FORS, okay? So we're signing with the same… let's say we're signing with the exact same FORS. If I sign with this, FORS, in my model, I, I need to give a queue that is progressing, because I don't want to use the same queue all the time. So for this, I commit a Merkle tree. When I commit this Merkle tree, when I sign with Q1, Q2, Q3, I spend the leave. And then, when I get to the last leaf of my miracle tree, I don't have an index anymore, so I need to, redo a key gen, and to redo the, the…
The key generation to have more index and register a new lane. Yeah. I could… I could also design, decide, that I'm gonna spend, an arbitrary amount of time, and commit to, let's say, a thousand key, and then I will not have to do anything for a thousand transactions. Your model is also very good. I think we're almost at the same point at this… at this point. It's just instead of spending this time to commit the Merkle tree, you just rotate and use Q1 all the time. It's a very valid trade-off, and I think it's basically you trade a few thousand, or a few hundred gas, I don't know.
Matteo Vicari: It's really, really low gas, because it's just to memorize an address on-chain. So it's around, I don't know, 100 gas, something like this.
Nicolas Consigny: That's okay. Yeah, then in that case, I think if it's this slow… Wait, you just need to… Memorized post address… okay, yeah, well, if rotation is below, like, 2K guys, but you still need to do an easy recover on top?
Matteo Vicari: No, really, because we… our verify is like a C-Recover for FORS. So, the verify part is the recover for parts. There is not, no, no electric cure, nothing, it's just… I call it, XC Recover just for,
Nicolas Consigny: Is he comfortable?
Matteo Vicari: impression, but it's not…
Nicolas Consigny: You don't also rotate any CDA key all the time.
Matteo Vicari: No, no, no, no. We just… we just rotate the address of the next FORS.
Nicolas Consigny: Oh, alright, alright. Yeah, then, okay, then at this point, it's almost exactly the same, and your, model might be nicer, because you don't have the… Basically, the key gen time to spend At the beginning. So yeah, the trade-off is just really this gas cost versus spending some time waiting for the hardware to grind some addresses. So yeah, I guess at this point, it's a very good trade-off to also just say we are always going to use Q1,
Antonio Sanso: Just from understanding here, with quick Q equal 1, there is no… there's no grinding at all, right? I mean, because the tree is really small. It's just, I mean, I don't understand that the price to pay here is… updating the next public key, that's the next… the next, FORS address, and but again, like I said, I really see now… it took me a while, to be fair, but I… I really… I really think that what the Riva Labs guys did is Jordan with Q equals 1, basically. That says, you can see that.
Nicolas Consigny: Exactly. Yeah, exactly. Right now, it is the case. Yeah, it seems to be… it seems to be a good trade-off. Like, if it's… if we're talking about less than 1K gas. And it's basically saving me a few minutes of my life. Well, it's… a few K gas all the time, or a few hundred gas all the time. Maybe it's worth a few minutes of my life, so… I think it's a good trade-off, yeah.
Antonio Sanso: Maybe what we can do as an exercise for the next weeks is this. Seeing everything in… with the eye of Jordan Framework, and see if Q equals 1 makes sense, for example, for… browser wallet, and Q128 makes sense for hardware wallet, and see where… the sweet spot of QEs for each situation. Do you know what I mean?
Nicolas Consigny: In that case, it would be the same signing work, so basically the QEQAL1 would work for both, I mean, this entire design was based, designed to be hardware wallet friendly, so… So yeah, both would work with hardware wallets, yeah.
Antonio Sanso: So there is no… do you think there's no… scenario where Q more than 1… assuming that the gas cost is low, do you think that Q equals 1 is really the sweet spot?
Matteo Vicari: I think we find a scenario where this can be useful, and we try to send us… we try to build up a paper for, try to make, post-quantum, also paymaster, in, In.
Antonio Sanso: You mean a scenario with Q, more than one, you've been using PM? Yeah. Okay.
Matteo Vicari: this can be useful. We try to finish our paper about this, because the idea is start talking about the big elephant in the room when we use count abstraction, and we want to go post-quantum, because the transponder of the transaction is still HEDSA. We try to figure out a solution for, mitigate this and make it, better. and Post Quantum. We are working, I think in the next few days, we try to, put online this part. And, the idea to have, more sign… sign commits all together can help, to, In this kind of scenario, so we can.
Alessandro Baiocchi: Basically, sorry, because the reason it's useful to have more than one sign registered is because you can then sign most transactions in parallel and do not risk of, like, a cascade failure if one fails. Because you, of course, you don't want to sign MOX transactions in the same block with the same signal, because it's a few times signal, and… but if you sign with our, like, similar quotation that rotates each time. if one fails, all the other subsequent transactions are not signed by a valid signer, so they will fail. Instead, if you have, like, 128 valid signers. you can sign a lot of transactions, and then they can all succeed if one reverts. That's the basic, the reason why it's useful.
Matteo Vicari: Yeah, and in, one, scenario that can be really useful, and, the, the paymaster. The paymaster received a lot of transaction, a lot of data from other, other users. So, he can have to parallel all the lane more as possible. It's not important to have a low kitchen, because he can preparate, it's like a server, the work of pre-master, so you have the… running capacity to, create more key in parallel. So, this can be helpful, and we can think to use this solution for this idea. So, we try to finish this work. And.
Antonio Sanso: So, just to recap, just to recap, like, you're saying that Q more than one can be useful for the key master of icon abstraction.
Matteo Vicari: Yeah, they pay master of the account abstraction, the bundler, all the stuff maybe can, help… can benefit to have, a really, large queue for parallel, all the operations they want to use for, pushing the data on-chain. This is something we are working. So, when it's ready, we share it with you, I promise.
Antonio Sanso: Just to keep things in a nice mental model for the future, do you guys agree that we can call this now Jordan, and working with a different kind of queue? So, I mean, like, the framework, you know, like, having this as a mental model that will be a FORS. with the variable Q, and the Q equals 1 will be, like, let's say that the normal scenario, and in some scenario will be beneficial to have a Q more than 1.
Matteo Vicari: I think, I think, yeah. Just another, curiosity, because there is some different part, part we see. Just, something. In our, implementation, we use forts plus C. But I see in Jordan, the last version, it is, I don't know if I also am wrong, just use plain FORS.
Nicolas Consigny: Yeah, I did both. I did fine FORS for… because it was easier for some of the formal verification work, but there is no… actually, it's not even much easier. I thought it was easier, but it's not really. So both are… you can do FORS plus C, or FORS. It's… yeah.
Matteo Vicari: And also, we come with, the, the verify of the, the forza, is around, I don't remember, Alessandro. the, the, the.
Alessandro Baiocchi: Is it the gas? Yeah. Yeah, we worked a bit on the optimization of the verifier, and we went down to 3,500, a bit lower than 35,000 gas, excuse me, sorry, 3,500. No, 35,000.
Antonio Sanso: But does this include the verification plus the rotation, or only the verification?
Alessandro Baiocchi: Well, it's… no, it's just a verification, but the rotation is just a… like a nest store on an address storage slot, so it's, like, it's… It's 2,500. 25,000. TX5,000.
Antonio Sanso: So, and this includes… this includes everything. I mean, also, they… they call the.
Alessandro Baiocchi: Well… No, no, no, that's the cost for the execution of the verify, plus the changing of the address.
Antonio Sanso: And the collector, how much does it add on top?
Alessandro Baiocchi: I don't know if we have some measures here already.
Antonio Sanso: Do you remember, by any chance yourself? Because, probably, I see this. Also, you guys, you come with 2.5… 25 kilobytes It's similar. So, the call data of the signatures being about 2.6K, how much is in gas?
Nicolas Consigny: Depends on which variant.
Matteo Vicari: I think we, we both use the same, parameter, N16, key, 27, 27… 26?
Alessandro Baiocchi: 26 degrees and a depth of 5.
Nicolas Consigny: I think it was 26 and 5 deaths, right? 26… Yeah, 26…
Alessandro Baiocchi: And five steps, yeah.
Nicolas Consigny: Yeah, yeah, it's, well, I have the number somewhere, I just don't remember by hand.
Alessandro Baiocchi: Yeah, it sucks.
Matteo Vicari: the same mass. And…
Nicolas Consigny: I think it's 2.4K, the size of the signature, and then the cold data, well, you price it with the… floor, EIP, yeah.
Alessandro Baiocchi: Signal size is to… yeah, it's, 2400 bytes.
Antonio Sanso: Yeah.
Alessandro Baiocchi: I have it here.
Antonio Sanso: Yeah.
Alessandro Baiocchi: And…
Matteo Vicari: But, all this parameters, we can talk, we can create a chat and, talk about it.
Antonio Sanso: Sure, sure.
Matteo Vicari: Okay.
Antonio Sanso: But, I mean, so, actually, I close the second here discussion, I'll be back soon, but, for anyone that's seen the presentation, I mean, do you guys have any… do you agree on the mental model of Of these two scenarios, where, one, you probably better use the lithium, because we have all the machinery of threshold, and, and… And the verification can be, as well, also here, but it can be, like, formally verified, and we'll use… okay, long term, we'll use SPHINCS minus, or SPHINCS with Lean SPHINCS, and short term, we are using this Jordan with the variable Q2. For the… for… for the medium term before Lynn SPHINCS. Do you guys have any… do you guys agree, or have any question?
Matteo Vicari: A question was with Dilithium, but there is, There is, some paper, you also post, Antonio. I, I don't have the time for reading, But, it's something like, there is some… find some algorithm to, skip some, the bit security of Dilithium. I don't know. Because I don't work on, Lattice Becinado, so, there is some concern, because I see your post, just for this.
Antonio Sanso: No, I think probably what you mean is, like, probably misunderstandardized Dilithium way too early, so there have been some optimization at Crypto 2025, but, I mean, part that… It's kind of fine. I shall see as well, Reno on the call… Reno, do you mind if I make you a question about this Dilithium contract?
RENO ZKNOX: Yeah, of course.
Antonio Sanso: Okay, thank you. Probably, I don't know if you were at the presentation, but there is a company that uses your contract for MPC, so they, they.
RENO ZKNOX: Yeah, yeah, we are in contact with them, and actually, we're also working on the same subject, so we're having TSS over MLDSA.
Antonio Sanso: Right, right. And basically, like, my question is, are you guys working, or any… are interested to verify, formally verify the Dalitium contract, the Solidity one?
RENO ZKNOX: Yeah, yeah, we are. So we, we are discussing V-Verity. One of our concerns is how to phone this effort right now, to be transparent.
Antonio Sanso: Sure.
RENO ZKNOX: Because, actually, yeah, with the wing down, it's like… but, yeah, this is, clearly something that, We are highly interested in, and… Yeah, I think for, for this, working with LFG Labs, We'll certainly be, yeah.
Antonio Sanso: Right.
RENO ZKNOX: Huh.
Antonio Sanso: Probably just a bit late, but in the call, there are Alex and Ricardo that are looking into formally verified contract, but in case you're already covered here, Alex and Ricardo may, if interested, they can, they can focus on the verification of, instead, the hash-based signatures, I mean…
Alex: Yeah, I would… I would be very interested in doing the hash-based route as well.
Antonio Sanso: Okay. Yeah. Okay. Alright, so let's be in touch. Let's be in touch. Great, so, that's basically all I had for today. We… I'm really happy to see things kind of converging as well with Jordan and the Riva Labs framework. That's what I understood of the article, FORS, is about, for both, is about 2.6 kilobyte. And the verification is 30K, 35K with FORS plus C, and of course there is, call data. Let's see if there's something in the chat, and we can write the verify directly in Lean. Yeah? I mean, what do you mean, Nico? You don't need solidity?
Nicolas Consigny: So right now, we still need Solidity, but, if, the Verity… works as a full compiler at some point, we… Would be able to write directly to me.
Matteo Vicari: Yeah, the problem to write directly in Lean, it is what we have to solve. is matching the bytecode size, the bytecode with the Lean implementation, and the Solidity ARD optimized implementation, because this is something we struggle to do. Because we cut a lot of corner for, put the gas lower possible in the implementation, but, we need also a way to matching with the Lean, so this is something, if someone can help on this part, we are really helpful.
Nicolas Consigny: Yeah, absolutely. Actually, we started to do this, So, when we had the Verity idea, the SPHINCS Minus was one of the first examples, and they started to work on, one of the early versions. It was, like, C5 or C6. And so we need to do it again for a new version, and yeah, the LFG Labs team, the Verity team, they know how to, to get this equivalence from the YuleBytecode to the lean. So yeah, they will definitely be able to do this for you, and I think it's quite easy for them. I know it's a lot for us, but yeah.
Matteo Vicari: Nice. We can talk and share some info about this.
Antonio Sanso: Alex, Ricardo, are you guys using Verity as well, or are you using something else?
Nicolas Consigny: Yeah, I see they're using Verity.
Antonio Sanso: Okay.
Alex: No, we're not at that stage yet.
Antonio Sanso: So you're not at that stage. Okay. Alright.
Ricardo Perello: Like, for now, we're trying to, get some proofs around the Falcon SimpleWallet, contract? So we're not yet, we haven't finished that yet. But we're open to do other stuff as well, I guess.
Matteo Vicari: You, you try to do the form verify of the simple wallet.
Ricardo Perello: the simple wallet, and for the Falcon Simple wallet as well.
Matteo Vicari: Okay.
Ricardo Perello: That's what we're trying to get to, like, by the end of… Month, I guess.
Antonio Sanso: Alright. Cool. So, next step is, with, I'm writing with, Toma from the Post Quantum, Ethereum. We're writing this blog post. I'm planning to share an initial note in the chat, in the post-quantum transactions in the chat, looking for feedback, and basically, like. the content is what I presented today, with the slides, plus the discussion here, and happy to have any feedback when Once I have a day of the draft. And if you don't have any questions, I will wrap the call for today. Alright then, thanks a lot for your help so far, it was really productive today. Thank you, and see you in two weeks.
Matteo Vicari: Thank you.
Alessandro Baiocchi: fuel, my energy.
Miha Stopar: Bye-bye.
Nicolas Consigny: Thank you, guys, bye.
Alex: Interesting.
Transcript adapted from ethereum/pm, CC BY-SA 3.0.