Cardano Vision 2026 Mid-Year Report | Research Progress Update

Miller. Uh yeah, thanks. Thanks, N. So, my name's Fergie Miller. I'm director of research partnerships at Input Output. Um [snorts] we're here today to to present uh the midyear report of Kadano Vision 2026. Um so, we'll uh we have an agenda where um we have a number of speakers that are going to come forward and and and talk about their work. uh and uh following following the session today, we'll also um uh circulate the report publicly. So I'm just going to uh start by just providing an overview of Kadano Vision 2026. I think a lot of this will be quite familiar with you now and then um I'll just point you to the report which will be available on the IoG website and on the Kadano forum um imminently and then and then we'll we'll sort of kick off with our with our first speaker so to speak. Um so so I think I think most of you are aware that the the the Gadano vision 2026 has three strategic focus areas. It's human- centered. It's scalable and it's postquantum secure. These cut across um the entire body of work uh that that I is is is delivering for the community this year. Um we're doing that through uh six technical work packages. So these are aligned to the intersect 2030 strategic framework. Uh and and um you know the first one is is trust and security. The second one focuses on scalability and execution. Um the third is is more about developer experience. Um the fourth around um applications adoption and liquidity. And then the fifth and the sixth look at um economic incentives and and then governance and and identity as well. We we have a have an evidence-based methodology here at at input output. So um it's actually two teams working on this. The first team is the research team and and who primarily publishes papers and and explores new protocol designs and security proofs and we work up to um for those of you who are familiar technology readiness level two. Um we then also have an applied research team. So where items are are um deemed worthy, we then bring them forward um to the applied research team to conduct technical feasibility and they really mature a work stream from TRL 23 up to what was TL5 and at TRL5 the the the the work stream should be implementation ready. So we will then hand over all being well that work stream to to any engineering lab in the community for for implementation. um within Kadano 2026 we we've um committed to um 42 deliverables in total. So so deliverables will have multiple outputs. Um so a deliverable might be a a report and a Kadano problem statement for example. Uh but this is really the innovation funnel that that the research and innovation funnel that that we're we're um uh we're providing. So at the top we've got five Kadano improvement proposals um and and uh we've got one of those drafted already and that's at TRL5 sort of early mid mid TRL um we're working on 12 prototypes and eight uh and delivering eight Kadano problem statements and and it's notable here that the the prototypes uh around quarter of the program's output. So there's a a real emphasis on practical implementation and then the foundational research at the bottom that underpins all this where we committing to 38 research papers and and technical reports um in terms of progress where we are at midyear. So I'll I'll talk through I'll sort of just give everyone a quick walk through the the report um very shortly but this is really the high level. So we've been working at risk um from the start of the year. The proposal was successfully awarded um in May. I think the agreement with Intersect was signed in the last couple of weeks. So we've activated this um very quickly I would say um and uh looking at looking at um uh the papers and and and the reports that underpin this. So so the target is 38. Um nine have been completed so far. nine are in progress and and are public. Um so we only publish work once once it's achieved a certain level of quality. We've got 15 drafts that are working in private um which we will public publish um in the second half of the year. And then the plan um through sort of July um August and September is is to to start work on a number of other papers. Um if we look at the the CPS's so we we we've um contributed to one CPS in in postquantum CPS30 um and we've got a number of others coming through um over the coming months and then actually we we're very happy that we've got our first um draft SIP in in fe market design where the target is is is is for as well. Sorry I I should have probably before I mentioned SIPs I should have sort of flagged the the prototypes there. So a third of prototypes have already been um um published with with a lot more to go. Uh so that's sort of CPS's and prototypes are mid mid-tier and then the six are TRL5 at the bottom. Um we we've had two handovers to engineering. This isn't sort of formally within the program but we're very mindful of of implementation and delivery. And then this is as I said our second um R&D session. Uh so so these happen quarterly through through the year as well. Um we've also got a number of articles up on the IO website including papers and we're sort of in the process of launching a technical workshop series with with with partners to inform specification and uh engineering handover and and road mapping as well. Um I'm just going to uh pull up the midyear report if I can. Um uh so I just want to um just lift this off the page for everyone um if that's if that's possible. So uh it's it's um a sort of more concise report than than what we have delivered historically. It's got an executive summary with a a scorec card per work package. Um and you can see most most work packages are on well pretty much all work packages are on track. uh if if not ahead in a couple of instances. Um we've got the the scorecard, the headline metrics that I just shared with you. And then within within the report itself, um we uh we provide a a uh a a rep a sort of a a summary of work performed. Um so for each program and uh with each uh sort of task as it were under each program we provide a summary of work performed. Uh so you can see that here and then we list um uh the outputs and evidence. So you can see that under um consensus for example um we've got four tasks. Um the first task is being delivered. Um and uh uh and then task two is in is is on track. Um task three is on track but that's in progress. So we don't feel that the the the the um the deliverable is is in a state to be public yet and then we start we start the uh the fourth one um imminently as well. So I just wanted to share that you with you. We also summarize um by work package any variance or change requests just to flag those so there's full transparency in in in how we work. Uh and and just sort of sort of running through these I'll just sort of highlight some of the sort of key deliverables. So we've made some good progress on on fear fee market design uh specifications and the simulation and analysis uh which is good. the the early version of the pub sub repository is is being published. Um and then we've got some you know a preprint in in the proto um protogo latattis paper. Um we hosted the sort of zero knowledge workshop um just last week in fact where where um these tools uh were disseminated and we had a very good sort of constructive discussion around around um their use and and implementation. Uh just sort of running down here. So sort of work pro program three, work package three. Um the kayfish prototype is is is is public and and the art team have have done some good work on that at the start of the year. Um and then uh looking at uh bridges we we've we've we've we've um uh the cardinal bridge paper is is is has been published in e-print and and actually the atomic swap the cans repo is is also being published as well. Um so we will be sharing the link in in I'll share the link in the channel here and also be available on on the um as I said on the IOG website uh and the Kadano um foundation um uh so I'd urge you to read that. We'll be running a community consultation for the next few weeks before we finalize the report around the end of the month and and make the formal submission to to intersect. Um so I'll I'll stop there. Um uh and and I'd like to invite up our our first speaker. So Yorgos um I think you you're going to going to present some work on on sort of memple partitioning assessment and and the linear layer security and performance analysis. So um I'll hand over to you Yorgos to uh for your presentation. >> Yes, thank you Frankie. Hello everyone. Um yeah so this what I'll talk about is is related to the consensus work packets but first let me give a quick introduction uh myself. Um so I'm a researcher on cryptography distributed systems and and blockchain protocols. uh I'm a research fellow at IUR and I had quite a diverse uh blockchain research experience for the past 10 years but that's so I've looked at proof of work and proof of useful work I worked on permissionless consensus on transaction concession control and lately lately on one scaling and in fact I'm leading the robos research efforts for the past couple of years um so to give you a bit of context Next um this work package uh uh is about uh uh layer one scaling meaning the robber leos and peras uh protocols. Leos is about high throughput. Peras is about fast settlement and our goal as these are higher uh uh objects. Our goal was to to secure their deployment pathway and support engineering in a way and uh also provide security and performance improvements that can be implemented in the uh medium to short term short to medium term sorry. Okay. So on the on the protocol improvement side, we have been doing uh work on uh optimizing the vote certificate design and by optimizing here I mean first better efficiency meaning smaller certificates and and and uh voting like network load and also higher security meaning that the voting scheme uh should be secure against uh stronger uh attackers if you want. Now we have uh an improved understanding and uh we're in the process of of writing a research uh paper that is to be finished by the by the end of the year and published by the end of the year. And also let me highlight here that um voting certificates are are relevant for both LEOs and Peras. In Leos uh there is voting for block availability that you know a block of transaction is available to to the whole network and for Peras voting is used uh for block boosting to to uh increase the weight of some block in order to speed up uh settlement. So this this work is really uh focusing on these two uh uh protocols and I would also like to highlight here that uh our work is based on on earlier work from my research. First the myth paper by by uh Agulos and Pio and then the fetakle commit selection paper by Peter Agulos and Alex. Um and and what's nice now is that throughout the years like we're uh you know improving our understanding of things and then now we can take these two uh papers that it's add something new to the problem uh also come up with new ideas and come with a better uh aborting certificates design overall. So I think that's a nice highlight of this of this uh uh work. Um now the other uh things we worked here have to do with performance and security modeling. So first we did some work on informing and by week obviously I'm not have to say I'm not involved in all of these uh objects. This is this was a team effort but I'm just presenting for the team now and there are also other people in the call that were that actually did work on some of these items that I didn't. So one one of these items is work uh trying to inform parameter selection and high requirements. So there we build a markoff model uh for block protection and certification informing us about for example how often do we expect a block to be certified and then we went to you know uh to an even higher complexity model trying to do a constraint model on the resource usage uh of the less protocol trying to see okay if I set the parameters this way uh being informed by the mark of model now uh how would um hardware user How would how would usage look how much how many CPUs do I do I need to properly run this this protocol and try to inform now the hardware requirements part for the for the protocol. Secondly, uh we looked at uh front running attacks and me fragmentation and the the idea there was try to understand better this uh this type of attacks uh because with leos we're inviting more load to the network in some sense more more uh throughput so then we wanted to see you know do this uh do things get worse or or how exactly uh uh things are going to look regarding uh me and running attacks and me fragmentation. Um and finally we did some work on adversary modeling and analysis that is um first uh trying to understand uh or to increase our confidence on the uh block diffusion process on the large block diffusion process if you like in the uh LEOS uh protocol. So in that protocol um um block diffusion is is is critical for for consensus as well and the compared to what was happening before in browse now we have to deliver an object that is a message or a block if you want that's a lot bigger than what we did in browse which required you know really careful analysis of of what's happening in the network modeling of possible uh attacks modeling and also coming up with uh mitigation strategies for certain uh shortcomings. So that's ongoing work trying to map uh to you know to follow also the implementation uh uh process and trying to map the analysis we do on what's actually being implemented and you know increase our confidence on that part and secondly there was work on on formal proofs in acta about the safety and the liveness of the protocol as well as a trace verifier. So trace verifier you know is a nice uh uh program that you know given some implementation and given that this implementation you know creates a trace of what is what is being uh what is the you know the program doing the trace verifier can come up and check this this trace and tell you if this trace is uh is conforming to the actual uh leo specification so it's a tool for implementers in some sense helping implementers conform to the actual specification of the protocol And you know this these three topics are quite uh you know there quite many things you can say and in fact these updates for these three topics uh where were have been presented in the LEOS monthly meetings and I urge everyone to also have a look there for some extended discussion on this on all these topics. Um okay so having said that um for the second half of the year um there are some key deliverables ahead that we're uh working on. First as I said the voting uh certificates research paper that's something we're probably going to have by Q3. Um secondly the uh a report on uh the unification of Fio and Peras and the possible synergies between the two protocols. something haven't started that plan to start uh this month and finally this uh report about the you know timeliness of of the of block diffusion in leos and as I said this you know quite an an important um report as it helps build uh you know increase confidence on the actual uh uh le implementation that's being uh done right now as I said before this is teamwork I wasn't involved in all of this uh you know documents and and work. U I hope I don't didn't forget any any of my uh co-workers. So thank you everyone. Back to you Frankie. >> Um thank you. So um if anyone's got any questions, we can take one or two questions now. Otherwise um we'll move to a round table after we've been through um the the sort of the four the four speakers who've presented their work. Um, uh, >> I hope I wasn't too too technical or what was described was somewhat understandable at least. >> Yeah. Did >> Sorry if it Sorry if it was not >> Did I can't see. Did anyone stick a hand up then? >> There's none at the moment, Freddy. I just dropped the draft report into the chat though as well for reference. But yeah, feel free to join in and ask any questions you have at this point, please. That would be great. >> Okay, I don't think we have any questions. So, um we'll we'll move on to the um uh the next the next speaker. So, I >> um pub sub is next. Freddie might have changed the agenda there. >> Okay. So, so over over to Will. Um Will Wolf that is. [laughter] >> Yeah. Um am I audible? >> Yes. Fine, Will. Thank you. >> Okay. Awesome. All right. Um then hello everyone. Uh my name is William and I'm here to give you a brief update on the uh midyear update on the midyear for the Kadana Popsub innovation workstream. Um, we're in pursuit of uh building a verifiable communication layer for Cardano for the Cardano ecosystem. One that essentially gives you similar guarantees u to what Cardano gives for transactions but for the kind of um one to many announcements that today happen offchain. Think of um SPO. SPO is talking to the delegators um notifying them about updates or pool retirement or a note building team um pushing emergency alerts to node operators. All of that happens offchain today and u with none of the guarantees that we get for transactions on chain. And that's essentially the gap we uh want to close with this workstream. And on the right on the right side here you can see a very high level um idea of a popsub system. There are two sides of it. We have the publishers who are able if they are authorized to pub publish messages to specific topics and on on the other hand we have subscribers who subscribe to whichever topics that they want they want to receive messages messages for. And uh the important part is that the two sides actually are never directly connected and neither cares how the message travels. So the popsup infrastructure takes care of that. Um from the publishers perspective, it's essentially a fire and forget and the subscriber mainly uh cares about strong delivery guarantees for the topics that they subscribe to. Um most off-the-shelf popsup uh solutions today rely on central brokers. um that facilitate the message dissemination and what we exploring in this innovation work stream um are designs that are decentralized and ideally Byzantine resistant and that's where the novelty comes from. And uh before we continue um this is by no means a oneman effort. So um behind this is a team of formal and prototyping engineers uh cryptographers researchers um colleagues from product and uh yeah speaking of which um a few words uh to myself I've been with um IO for almost five years now started off as a solutions architect um transitioned into the technical architect role uh I've worked for um lace on the backend platform and led the power work stream uh throughout 2025 which has been handed over to engineering and uh since early 2026 um I'm leading the pubs work stream. So uh with that what are we uh working towards? Um we're working towards a uh Cardano anchored popsup layer with um identifiable publishers uh verifiable events and uh onchain um registered topics and an economic cost to creating publisher identities. So what product has put forward are four main use cases that we are focusing on and you can see them here kind of uh in the bullet points as well as on the right hand side as a as a figure. So first we have as I've mentioned before the uh node builders like or maybe Amaru um who may need uh to send emergency alerts to node operators like SPOS's. Um second we have SPOS's um communicating to the delegators um again like notifying them about maybe pool changes or upcoming retirement. Uh third we have dreps uh talking to their delegators maybe about loading intent or other governance matters. And uh lastly we have uh dubs um uh talking to their users which might be about either user individual notifications about I don't know open positions or other things. Um so what impact would our solution um actually have? Uh I have this before and after slide here um but let me start with the line at the bottom because I think it captures the overarching arching uh goal better. Um I've I think I've mentioned it before, but we want to take the guarantees um uh the that Kono gives to transactions and extend them to more general communication um while focusing on those four use cases. So with that in mind, the before um right now or today, most of these critical messages basically travel across social platforms like X, Discord, Telegram, and they're entirely offchain and unverified. Um and yeah and anyone can impersonate SPOS's or governance actors. There are no dedicated officially acknowledged channels um that can trust. Um there's also no uh delivery guarantee that people actually re received the message and there's barely any cost to creating and spamming um uh creating several account like accounts multiple accounts and spamming. And um with with our solution we would uh change that to that publishers are actually identifiable by their onchain credentials. Um we also using them to um make any message that gets published cryptographically verifiable. um our in our architecture uh consideration that we're looking at um topics actually are registered on chain and so that subscribers know what they subscribe to and um yeah and uh we have uh basically uh added a cost to identities um so that there's a real a real onchain cost and in becoming part of the system uh Yeah. Did I miss anything? Yeah. Oh, yeah. The uh delivery to to um every honest subscriber basically comes from or comes with a formally analyzed and bonded failure risk. So, this is basically our formal formal analysis part. Um so, how do we get there? Uh we have um two phases that this workstream is split into. The first one is um completed already and we're right at the beginning of um the second one. Uh phase one was mostly exploratory research. Our starting point were those four use cases I've mentioned earlier plus a research paper called secure cyclone published in 2023. Um that paper uh proposes a design of uh three stack gossip networks u made up of a peer sampling layer at the bottom which uh gives every node a random view of the network. Um uh on top of it a navigation layer uh which favors links between nodes that share similar interests and topic in topics and uh finally a dissemination layer that uses those links to spread and disseminate messages. And the paper argues that certain security properties transfer across those um layers. And what we did was test those claims systematically with um a formal analysis and modeling as well as simulations. And what we found is that the um nodes view can actually be biased by adversaries who simply stay silent and drop messages for instance uh without ever violating the protocol. So even in the secure version of the cyclone protocol uh this is secure cyclone protocol named after that has defined nine defense mechanisms uh that can catch those uh kind of attacks because it sits outside the papers adversary model and that uh led us to kind of take a step back and aim for a simpler more um easily verifiable design. And at this point we are actually not considering using a peer sampling protocol at all and instead we rely on an onchain registry of um all participating nodes so that every node is capable of locally computing and sampling from this list uh on its own uh which sidesteps exactly the silent sampling attacks uh that secure cyclone surface farm. Uh we've also spent some time here um on alternative designs um like Bzalt for instance is another peer sampling protocol that among others that we've taken a look at u but we ended up choosing uh our simplified list approach or onchain list approach. Um but these analysis uh gave us some several methods that uh helped us constrain some adversarial uh scenarios in for phase two. So phase two um which is about the approach we're taking uh it's it's captured by the title here together with the line at the bottom. We want to derive the design and not propose it. So in other words, um if the final design carries uh complexity, we want to be able to defend that with data from running experiments that show that any simpler design would actually fail and with reasons why. And uh everything rests on one bar that uh every candidate design has to clear which is what we call a good graph. A network where every message of every honest publisher reaches all honest uh all other honest nodes. Um now whether a given setup actually produces a good graph is probabilistic. So what we measure is um the good graph probability and we want it to be as closest to one uh to we want it to be as close as possible to one um with the uh residual failure uh risk quantified. So having that single bar is basically what allows us to compare different designs on equal footing and uh we have five of them. Uh so those are what we call M1 through M5 here on the right hand side in the table and each defines a different set of rules. uh for how nodes um are supposed to connect to each other and form a topology. Um so what they all share is the adversary um a fraction mu of silent Byzantine nodes um exactly the attacker class um that broke secure cyclone. So we evaluate these um designs or these candidate designs on two independent tracks. Um we have Denise who's our formal engineer that drives the formal analysis part of it. looking into delivery guarantees, bandwidth, hops, um connection degrees um and those results should then again uh uh check against um the Rust prototype that we are building um is equal myself um of a node of a basically a prototype node of the pubsub and um we plan to basically measure and compare the same models empirically. So ideally both tracks can confirm each other's results and where they disagree that might be a good signal for us to track down bugs or reassess um some assumptions that we've made. So in the end um they should complement each other so that the design we propose is grounded in data. Um so what does this mean concretely for the upcoming weeks? Uh we basically have three things that we want to complete. one is um the form analysis is uh is still not done for the cross comparison between the different models. Um and we are just about to finish um uh completing the implementation of the prototype with those five models so that we can run simulations. U we're still missing a sort of a test harness to actually spin up a network of those um uh nodes and actually run the experiments to get the data and analyze them. Um and then uh the idea or the goal would be here to design or have this uh candidate um that we can put forward as a solution architecture by mid of August. Um if time permits perhaps we are able to draft a cap but this is an unclimited uh goal for now. And maybe one one last thing to add is that um currently what's beyond the scope is like the economic feasibility of it. meaning um we have not yet looked at fees or incentive schemes uh which is still an open question that uh might come with the next phase and with that um yeah thank you for listening and uh I pass it back to you guys. >> Thanks William. I know you've got a um an appointment that you have to have to leave for. So I appreciate you making the time. Um have we got any questions from uh people on the call? Nothing in the chat, but if anyone wants to raise their hand, please do. >> Um, okay. Well, I think that was pretty comprehensive presentation and um uh yeah, I know you have to drop William, but if if anyone's got any questions later on, then um then uh then we can take those uh at the round table. Uh so I think um uh we have the other will coming up next don't we um ne will gold who's going to talk >> present uh the work we're doing on dynamic pricing over to you will >> hello hi uh so yeah hi everyone um I am Will G I'm a software engineer at IO um and I am leading urgency signaling dynamic pricing /free market. Um we've been working on this for a few months now. Um and to give you a sort of TLDDR before we dive in. Um we basically want to give um a way for users to tell block producers how urgent their transaction is essentially um so that they can get uh proper treatment. So where we are today um is obviously Cardano has u a flat fee. Uh there's there's there's no dynamism there. So uh you might have a particularly urgent transaction and uh in a time of congestion you might be stuck behind a transaction that doesn't care when it's included. Um and obviously that is suboptimal. It would be nice to indicate to the block producer. Um, with the advent of uh linear layoffs, uh, this is sort of a a perfect time because linear layoffs adds a a new uh block type, the endorser block, which has a slightly different uh latency profile to prowess blocks. Um, so we'll get into what how we use that uh on the next slide. Um so initially we we started out by writing a CPS. So we wrote CPS uh 0031 uh and that defines the the criteria of the problem that we are trying to solve. Um and we started out by uh analyzing the paper tiered mechanisms for blockchain transaction fees. And this describes um sort of a full fat tiered pricing mechanism. And we initially wanted to go along those lines. Um but after some analysis we we realized that it's it's kind of tricky to apply to linear layoffs uh directly. Um and additionally um at builderfest uh our our product person Carlos Lopez Delara had a discussion with community members and the the takeaway from that was that people would be quite happy with something uh relatively simple. So this all sort of pointed towards a design where we can just sort of get our foot in the door with regards to urgency signaling. Um and then we can always build on it later if necessary. Um additionally it it means we can get it out quicker as well which is which is always nice. Um so this number that you see on the slide 44.32% this is how much value was retained on average for urgent transactions in our simulation um under severe congestion. And when we say urgent um a transaction's urgency is the rate at which its value decays. So where are we today? Um well, we've got a mechanism that we recommend. So, it's a a two-lane mechanism. Um we consider um entry into uh prowess blocks or ranking blocks. Um we consider that to be the the fast lane and we consider entry into uh standard into uh endorser blocks to be the standard lane. Now in order to get into a ranking block uh a transaction must pay the urgent fee. Uh this is important because it means that we can verify on the ledger um that the transaction has in fact paid the urgent fee. That allows us to avoid bribery. Um we want to avoid bribery in situations where like imagine if a uh transaction is paying the standard fee but it bribes the block producer hey I'll give you this uh please include me uh in the fast lane so that's what we want to avoid there [sighs and gasps] um now this is an important point both lanes uh in this design are dynamic both are dynamically priced so that means that even the standard lane is dynam dynamically priced this is potentially uh controversial point. Um but rest assured that in order for dynamic pricing to even kick in uh on the standard lane, you need to start reaching um uh 50% of the endorser blocks uh being full. Um so as in like a 50% fill rate of endorser blocks. Um that's a huge amount of of of load obviously. Um but if anybody has uh concerns about about this we are happy to discuss it. I I'll explain the reason why we have the standard lane as well as the urgent lane being dynamic uh in a minute. So the way this uh dynamism works is uh as I implied um once once once we start getting blocks uh above 50% uh the price will increase and that would um be by increasing factors up to 100% where it would be a full 6.25. 25% uh increase uh or at 0% full rate um it would be obviously a minus 6.25% uh to the price. Um so how have we validated all of this? So primarily with uh experiments. So we have a linear layoff simulator and um we basically took all the design axes that we wanted to take a look at and a bunch of different load profiles which you can see on this table here um and we compared them uh against each other. Um now you can see this this number uh that I showed you on the on the previous slide 42 44.32% we got that uh up to 50.97% for urgent retained value under that uh severe congestion load that we were using as a as a sort of benchmark uh which is a roughly 15% relative uh improvement which we're we're quite pleased about. And we're especially pleased about the fact that under none of these loads uh do we see any regression from the uh unmodified uh linear layoffs. So uh we either beat or match in in in every case. Um now I promised to explain why earlier um why we uh want to make standard lane dynamic. And if you take a look at this launch day um uh section here what this is simulating is like what if the Sunday swap launch day congestion uh happened and it was also scaled up to max out endorser blocks. So it's probably a bit unrealistic for the moment, but imagine you had fully saturated endorser blocks. Um what would happen in that case? And as you can see, we don't improve latency, but we still improve urgent retained value. And that is because of the standard lane being dynamic. So, this sort of encourages um users with transactions that aren't urgent um to to hang fire until a better time because they don't they don't care about having their transactions included immediately. Um freeing up block space for more urgent transactions and so that is the reasoning there. Uh so in terms of validating the implementation path uh Nicola Anrar has uh built a prototype uh this is a prototype on top of the linear layoffs prototype um and uh Nikolai is running this on a private devet and it works which is great and it looks great. Um and he also made a point that it was relatively straightforward. Um so that is quite a good sign. Of course this is a happy path but it bodess well for future full implementation. On the formal specification side uh Pina Vinegrada has produced a transaction commutativity proof. Now that's important because it proves that we can freely reorder most of the transactions that we care about. Uh which is uh pivotal obviously for the design that we're going for. Um and she's also almost completed the uh a formal ledger spec to go along with that. Um now as far as uh the research track is concerned uh Yos will be um performing an incentives analysis but we're going to hold off on that until the CIP um is is fully open and once we sort of reach community consensus as to what exactly we're doing so that we avoid uh repeating unnecessary research work don't want to be going back and forth. So where are we? So we we we we think that the CIP is going to be ready uh probably by the end of July and certainly by mid August. Um obviously at that point we'll have community discussion. Um and then when Yorgos starts his work um we would imagine that will be finished at some point within the next six months. Um so yeah the important thing now for for all of you to do uh if you could please if we could ask you please do take a look at uh at our repository it's public um so I believe you all have access to the halfyear uh update document. Please do uh click those links um give us feedback read the CIP draft which is work in progress but it should give you a good gist of where we're going. Um and uh also please do read CPS 0031 um to make it very clear like exactly what what the set of problems are that we're trying to solve. Um but just to reiterate, we do um you know we want to produce something that people want. So anything that is controversial is always up for discussion. So yeah um that's that's me done. Thank you very much. Great. Thank you, Will. Um, we got one question here from Rusty. >> Yes, thank you, Rusty. Um, she says, "May have missed it, but does the M pool selectively propagate transactions that have higher fees?" >> Uh, no, no, no. We've not uh we we we've not we've not done we've not done that now. >> Ramsey, do you want to jump in? Your hand up there. Thank you. >> Yeah. Sorry. >> Um related question. I suppose you said you wanted to avoid um you want to avoid people where you pay more first. Are you avoiding that structure? Is it just the >> Oh, sorry, Ramsey. Your mic is kind of >> Is it is a little bit >> It's a little bit sort of I I don't know how to describe it. Robotic. >> Sorry, Ramsey. Yeah, maybe you can type in the chat or >> Can you hear me if I just fine? >> Oh, yeah. >> Apple technology is not working. Um, you said you want to avoid people bribing block. >> Oh, you've muted now. Sorry. >> Hi tech, right? I have a PhD in computing. [laughter] I could probably microphone. Right. >> You said you wanted to avoid people um bribing block producers to get ahead, right? And obviously there are networks where you pay more, you go first. It's completely kind of arbitrary and straightforward. Were you avoiding it for some structural reason or just you don't want to dive into the deep end? >> So the Okay. Yeah, you're you're asking uh yeah may may clarification. It's not about avoiding it's about making it public, right? We don't want this to happen, you know, under the table. That's we want to have a you know a simple process where if you want to get you know if you're if you have high urgency >> sure >> there's a simple process which is clear how what you have to do in order to you know uh get this uh type of service while you know finding 10 SPOS's you know calling them and then okay I want to go in fast and then this is not obviously an efficient economic terms process right compared to you know there is a price for example it [clears throat] is pricing >> just make that market public, I guess. But, uh, yeah. Any more? By the way, Rusty, um, I I'll have a a think about about your question because that's not something that we considered. I'll make a note. >> Um, okay, great. Well, well, thank you very much. I think um you know we plan to hold a a technical workshop on this in in in in the coming months. So um we'll we'll we'll try and get more eyes use that to get more eyes and more more feedback for you um in due course. Uh okay. So, I think I think um uh um we've got um who? So, is it is it over to Paulo now for for the governor's incentives? >> Mhm. >> Okay, great. Okay, let me share screen. Can you see my slides? >> Thank you. >> Okay. So, hello everyone. I'll be talking about gold incentives model and mechanisms. This is work package 6.1.1. Uh just a few words about myself. I'm a research fellow at IIG since uh three years and uh I've been working mostly in incentives again theory for about 25 years uh with application to civil systems using microeconomics and uh computational tools. uh other ongoing projects u within IOG uh are related to incentives including me market design to economics but as I said uh today present you the state of the research for this stigma uh concerning governance and incentives um so the progress that we have made uh related to this key issues about Cardano governance One is the high complexity of Volter Scardan system which is probably one of the most complex uh governance system probably the most complex in the context of blockchains. And the second is uh the system is running and we kind of observing some tendency in uh dividing participation and centralization. And so the the research progress um is around this uh two topics. Uh the first one we have a complete uh technical report. Um and about the second one is uh an ongoing uh research. So we have a in progress model uh that focuses on a geratic model on what is the effect of incentives in participation and decision. So I would like to start from the low from the lowest to the newest and just as a additional motivation uh this is the data that was uh few months ago I think in March so we had uh 50% only of total ADA being directly uh involved in delegation booking and if you look at DPS for instance uh we observe them only the top 10 control 48% of the voting power and I looked this morning at the same numbers and they look a little bit worse okay so I cannot tell you that this is a constant tendency that it's just a fluctuation but there is some issue okay so how can we counteract or should we counteract uh this decline participation centralization so We have produced a new incentives model that tries to capture the sense of this question and give some insights and I'd like to present you the results by comparing what this new model says and what was known before. So there is a super classical result called the conversary jury theorem which says roughly speaking that the more voters you have in an election the more chances you have that the election uh selects the correct outcome whatever the correct outcome is. So it's a kind of whistle of the crowd result and I'd like to explain this classical result with a some illustration. So let's say we have to choose between two options. A is a good option in the sense that it will advance Cardano and B is a bad option. And as a single voter I look at the proposal or the information that is available and I'm not perfect. So there is 60% chances that I'm able [clears throat] to detect what is the good answer, what is the good thing to do. So as a single border if you just ask me there is 60% chances that we make the right decision for Canada and what theorem says is something perhaps natural namely if instead of one model we have three models and each of them picks the right answer with 60% probability and then we do the simple majority in this small well there is part is 65% correct. So we have 65% now that we vote for the correct thing for Kada. And if you push this even a further so we have 100 voters the rob that collectively is 100 voters pick the right answer. So the majority says answer is a is close to 100%. Okay let's say 99%. Now it turns out that this classical result cannot be applied uh I would say to Katan to many other context and that's where we the research made significant and intuitively what it says is uh because uh it's not so easy to understand the question so to get a confidence of 60% as a single So because of incentives it might happen that people just vote at random. So this creates an inverse of this content which says if you have too many voters because of uh of this cost people tend to vote at random. So instead of 97% I have this 100 people that would just click a run between A and B. And so the final outcome of the vote is a random choice. And this model uh I just want to give credit to the uh member of the team that started working on it is really uh capturing the essence of the volume of certain type of volume. So on the one hand if I uphold uh some ADA I want to have done so I want to pick the right answer on the other hand uh very often I'm asked to vote on technical question so that a priority I don't know the answer so I would have to learn stuff I would have to read proposals I would have to spend some time on it so there is this tension as a single voter and now if I'm together with other voters who for whatever reason decided to order the random I also have an incentive to order random because my doesn't count that's the idea okay the intuition behind this result that I was trying to explain uh these plugs uh on top so uh I just want to illustrate a little bit the trade-offs of some of the results that we have this is a work in progress as I said uh you see that there is one dimension which is the number of voters and there is another dimension which we could think about it as the diff of the question that we ask. So if I have a simple question or a proposal that is clearly a terrible idea, so it's obvious that should be rejected, then uh larger number of voters can still produce the right answer. But as soon as we have a fairly part technical question uh because of the increasing cost for understanding what is the correct answer bigger let's say committees or very large number of voters end up in the pure random voting outcome and that's bad for the system. So this suggests that there is a nearent uh trade-off between decentralization of as many people as possible to participate and the optimality of the outcome. And what I want to stress here is that uh somehow participation here means not just voting but active participation. So voting in a informant way and the preliminary result suggests that there is a number of mitigations of things that candidate mechanism could use to improve the things. You can think about it having smaller properties for certain questions. Uh in part this is already in Cardano if you think about constitutional comedy versus draps. uh but also a mechanism that altogether could make easier or facilitate understanding the question redlegated to people who have better expertise. So um this concludes the first part of the results. Now I would like to focus on the other part and somehow zoom out a little bit and uh describe what this technical reward contains. it's uh essentially completed will be available publicly I think in a week or so and it focuses on the the complexity of Cardano governance at all. So again let me give some of the before and after overview. So um katano system is so complex that uh essentially existing methods consider only simpler systems or only some of the aspects not the interaction between you know we have three parameters three bodies that vote different kind of votes etc and so it's not even clear what is the right mechanism what are the mechanism that are possible for a law to be implemented and if we have different candidates How do we evaluate them? So this technical report makes it formal uh first of all what are the relevant parameters. So the specification of the test mechanis what is allowed to do the space of possible mechanisms in governance and then um what are the data that we test mechanism should achieve and there are different goals and very often they are in contrast with each other. So we what we are really looking at is the investigate the trade-offs and one third and last key contribution of this research is the formalization of a formal governance. This is the name for what I will describe as a sort of test net or simulator for governance. I will give a picture in a moment. uh what I want to to tell you here is this is like involving a longerterm research. So this rapper says what needs to be done and the impact for Cardano governance is to have a systematic formal way to evaluate the current state of governance. uh find venues to improve it without risking to sacrificing security or other properties and adapt the voting scheme depending on the external change that of course the system will face in the future years and so how can we keep the optimal train between the different consider priorities what should be looked into First, um the other important thing is there is a lot we can learn from the fact that governance is right now live and running on Cardano and the permal governance is a in my opinion a very fundamental tool to facilitate exploration evaluation of new solutions and that's the last slide from my presentation. So it this work from uh four different layers and which captures the different ingredients and different approach that you need to have in governance. So one is um a formal uh method approach to define what is allowed to do including uh what part of the governance can be changed by the governance itself. self amendment and then there's a human part like the voters and the others entities that are involved they will behave in a certain way. So you have seen one example from the previous uh uh paper that assumed something about the voters. Maybe that's correct for some situation. In other situation you would have to to change your model and the way we plan to do it is by looking at data on chain and checking and adopting our assumptions to the to data so that we are working with models that describe reality correctly. And the last module or the last layer is something that tries to search automatically or semi-automatically uh possible mechanisms and parameter changes in optimal way given the upper part of of the model. So this concludes what I wanted about governance. I'm happy to take questions now later. >> Thanks Paulo. Um uh uh I think that was that was very thorough and particularly enjoyed your your sort of uh vision of the technology stack uh or approach for that. Um Ryan, are you on the call? You you able to sort of um uh come forward and and sort of um talk a bit about your your your your comments around uh binary decision-m. >> Yeah, sorry I I joined late so I might have missed some of it but I did do some of my own research on this. I linked in the chat. uh was very much vibe research. I was I was just excited about the idea and and I was thinking about the just how to decide when a decision is good or bad in a governance outcome, right? Because it's it's it's never, you know, black and white. It's always shades of gray. So to me, that's a a very difficult premise to base research off of. So I tried to looking at the exact same metrics you were looking at. I think you talked about voting power concentration and participation as your chief metrics. And so I tried to optimize um just a couple different levers for that um but without binary outcomes. And so I tried to tried to capture that in a little paper there. Um so to me I mentioned a highex knowledge problem. So it does seem it does seem a bit odd to me you know intuitively and especially for a decentralized blockchain which is much like a market right like uh you very much it would apply in this that sense you would think that the the collection of knowledge there wouldn't be enough you know a handful of people to be able to collect all of the knowledge necessary to make the right decisions. Um, so I think that could be applied in a decentralized economy, uh, a decentralized blockchain too, um, even when it comes to non-economic things. Um, so that was kind of my thought process that went into that. >> So Paulo, is this is this model exclusive to sort of binary decision-m or or can it can it be expanded? >> No, I think uh my feeling is that can be expanded. So the the first step would be of course to to have a third option which is to abstain which we already had. I mean to see the the effect of abstaining option uh saying I admit that I'm not an expert and I should not be dumped versus the other option is I'm not an expert and I want to follow someone else so I delegate this other person. So uh that's the first uh ingredient going far from two options. Uh I mean right now many proposals are you know pass not and there is another aspect that is in my sty model doesn't appear which is uh we have a threshold so passing requires 67% so there is aiming etc. So uh but from the mathematical point of view I don't see a reason why having five options and you know from the best to the worst would quantitatively change the things. Uh I suspect it would change the things quantitatively but uh I mean the table that I showed that's for a toy version of the ving. So I would I said invite you to just uh think about it in terms of how the things degrade but not how much. Uh I suspect there is this third dimension of the number of options will introduce complexity and so too many options is is a bad idea. But that's my feeling because I will have a harder cost to evaluate the relative benefit of each option and so my budget let's say is now divided uh into a more complex task. So it my feeling is that will create a similar problem like a huge comedy. uh for your question, I think that it is possible to collectively have a sort of wisdom of the crowd uh by introducing or leveraging some slightly more advanced delegation system, something that is a bit less than liquid uh staging or liquid democracy where I can redelegate as much as I want and then the next person can redlegate because this to me looks a little bit out of control >> but partial uh redelegation or redlegate to experts which is something that people have in the community suggested in some cases. Yeah, you mentioned wisdom of >> wisdom of the crowd which I think is you know it you know delegating to other DRS kind of is our quality control lever right like if you have a very high quality DREP that they should naturally attract more delegation versus a a low quality DREP should should have less but it's hard to measure that quantitatively you know it's a qualitative measure um so it's a difficult thing and there's another kind of metric that I've been recently considering um that could uh skin in the game is is what I call I'm not sure if there's a better word for it. But if you think of like Apple and SpaceX stock for example, you wouldn't want somebody who owns a lot of Apple stock and knows SpaceX stock to be voting in SpaceX things. But you know if somebody is very popular and you know an influencer has YouTube channel celebrity or whatever, they might still attract a lot of delegation for that feature and then they might vote against the ecosystem's best interest because they're a stakeholder for the other thing. Um so that's why I I I wrote a sip on DR pledge also trying to it's still actually being drafted but to try >> pledge is I think pledge is a key thing also this going on >> right but that was that was another >> if you have if you have a higher pledge >> somehow you have a indirectly you have a higher benefit from uh voting on the correct board to be implemented >> and this is this is excellent work thank you >> I Um, Andrea, you've got your hand up. Um, if you >> Yes. Hi. Thank you so much for this interesting webinar. Hi Paulo. Um I would like to ask uh if you can say a bit more about uh the assumption you make between the link about the link between the difficulty of the question and the behavior the randomness of the behavior of the borders delegators because I think that the the results you may obtain is very sensitive to this and it would be very difficult to to find. Do you have data that you can uh extract some distribution? So uh how do you solve this problem if it is a problem or maybe I haven't understood properly the model? So that there there can be different interpolation of this difficulty. One is how much time I have to spend to understand the question correctly correctly means get a good confidence. So really a process and so then it becomes subjective. But the other the other dimension the same is uh is related to the pledge. So if the right question is implemented and I have a large stake for me it is worth to spend many arms reading the question or a proposal to find out the right answer. So it's a there are two ways to to look to interpret the results. If I ask an expert for the expert is easier to to evaluate the question. If I ask someone who is not an expert but as a high pledge this person still want to understand the question. So it will behave in the same way. And now you have in the middle the hard part is people that have low interest in Cardano or even the opposite of course and they're not experts. So That makes sense. So the data would have to dig into the trying to figure out um the expertise that you have prove it in the past during the past. That's one way the pledge that you have and try to estimate how good you can be for sending questions. >> Thank you. Um, we've got we've got a few more comments in in the chat here. They're they're largely on on governance. So, um, I think you sparked a an interesting discussion, Paulo, but if anyone's got comments about other other work presented this afternoon, then then please come forward. Um, Rusty, I know you sort of made some remarks about rational ignorance. Um, and I don't know, Tavo, are you there? Do do you want to come are you able to come forward or um just sort of >> do what? >> Well, just sort of ask your question. You had some you had some comments around um I guess an algorithmic approach uh uh and sort of concentration of decision-m did is is there anything in particular you wanted to ask or or remark that you wanted to make? Okay. So there were two different things. One was like the idea of having this recurring delegative representative because I think when catalyst started and few years into they already started talking about hey let's have delegation and the first way we thought was like as a dire you can select other ds and that would give you actually the collective intelligence because then you you are being more strategic of who you trust and you would like create this network craft and if we bubble it all up, we will see a huge Intel networking. But I think the downside of that is then we will clearly see a single decision makers uh because of the way it functions and well we could get the healthy graph too and see like oh there is actually and but yeah I don't know how would that solve anything and the second point is uh and whenever like you know the best decisions are the best where nobody has to really vote they just know that this is the right way to go and with this proposal process. We are planning futures where it's it it's not really clear. We like we try to always scope to a specific thing and then we basically are now forced because of a budget to also uh choose basically our like fraction or like which direction we basically choose our priority. Um, and when we look at the DEP results, we we kind of turn it to I don't know tribalism or like we we force out this discussion of the individual why he made the choice and and it sometimes doesn't like get great. But what we need is we we want to implement the proposal. doesn't matter is it should it be now like if there is a person who's willing to do it and has time to do it and like he can work on it concurrently. Um so in order to like improve the propo like the proposal itself has to be somehow written in a way that is coming from all of us but somehow it's always like a team like we are not we don't have a process to create the proposals that we can get like a collective insight and then just collectively move it on. So we we're missing that part of governance. I feel like even though we have intersect is doing its work but somehow it's always gets sidetracked and because it's all open process it we have like multiple frameworks of people engage with the governance. Um >> so there one or two strands you just um would like to reflect on there of what TV said. So the the tribalism you are referring may also you know somehow try to to capture it. There is another dimension which is uh if I have to make a choice uh partially would be also reflected by my personal preferences. I mean we we could have conflicting goals among the bodies of course which is not something I explaining in the first model but in the more complex one this is uh part of it and the other interaction that you were referring to is probably one of the tools or processes that could lead to an easier or lower cost for evaluating proposal. >> I don't know if I miss something but uh you were suggesting but or missing something that does make sense. >> Yeah, it does. I mean there there's certainly some practical solutions that I I know are being discussed for for governance going going forward um off the back of the [snorts] the recent round of Treasury withdrawals. Uh Russy, you've had your hand up for a while. I'll come to you for the for the next question if if you don't mind. >> Yeah, I have two thoughts. Um, so the first is kind of building off what Ryan's question was like with the model. Does it expand? Uh, these proposals are necessarily ranking proposals even though it's like yes or no for specific proposals, the proposals are competing against each other for a fixed pot of funding. So my first question is like do you think the model can accurately capture that where you and I could agree that this is a good proposal but we disagree in the prioritization of the proposal. Uh and then the second comment it's I think is more of a comment is the current DREP model does not actually reliably map reality of how humanity or human nature works. I would rather have different DREPs for each proposal. uh like I'm an economist so for an economic proposal like my dre should choose me but for consensus I don't know anything about consensus I'd rather delegate to somebody else so maybe a default to drep and then I manually choose and override direct for particular proposal there's no recursive algorithm there um is that being explored at all like those are my two questions thoughts I I personally like this the second part this uh you know selective uh this kind of selective redelegation because it's transparent and uh I think it's not in contrast with the model type of those even though the model is still rudimental many things that we want to add I would expect that this could uh be doable probably better Okay, in terms of performance uh the gun in the ranking, we didn't think about it. The one nice way to extend this model to the rent would be to interpret this uh yes no question as paywise comparison and to come up with an order which is more complicated. So we don't have the analysis of uh let's say if I ask everyone between two proposals which one you you prefer the more then the way this is aggregated it's not majority but uh if if I can estimate the probability of producing let's say a good ranking the same principle uh would apply. Okay. So I would expect that with a larger committee again we have this phenomenon of not not looking at the questions and just saying random answers and then you have a random outcome. So the bad results carry on. The good ones you would have to to redo the analysis which is doable. And I think we might uh I mean I think it's a good suggestion we look into this. >> Um >> thanks. >> Great. And and Walter probably probably our last question given the time but uh but but but over to you. >> So did you call me I'm Walter? Yes. No I have not a question maybe a remark regarding this governance system. I also made a a remark in the chat already. See, I was referring to the Swiss voting system. I'm Swiss and we are used to have every two months at least the referendum where we have to make a decision. Now, I don't say that the Swiss system would work for Cardano. But still I think the issue of randomness in answering a a question or of tired tired voters etc might still be interesting to have a look at the Swiss system which in fact is um in a way that when we go for a vote then we have vote on a national level and these votes normally are big and our big questions are should Switzerland land somehow participate in the European Union or not. I think that's quite a simple question which affects everybody. Whereas when it's about voting for let's say the transporting system of a city, not everybody in Switzerland can answer this question. Only those who live in this specific city where the transportation system should be changed or whatsoever. So people always have some understanding of what they are voting on and they are affected by the vote and I think this principle makes it still livable makes sense for enough people in Switzerland to participate in this governance and now I'm just giving you a feedback from an outside and following Cardano. I've been following Cardono since its first days in 19 in 2016. So I really and I'm on a regular base listening into it. For me I think I'm a mathematician. I if I want I can try to understand what's going on. But honestly the last evolvement in this government and in this voting system I missed because I just didn't have the time to to go into it. It's too complex and I think if we I say we because I'm also part of Cardano community we want to have this wonderful in terms of blockchainbased voting system we what it should maintain Cardano a good thing and let it prosperous etc etc then we need to find somehow also a level of communicating to those who should vote And I think that's that's that's what's lacking because I cannot understand everything which is asked in this voting. So what should I vote if I don't even know what the question is? I don't understand it. I think that's the issue. It's not a technical problem but it's really a communicational problem and I think you're doing great job by by going into it trying it out but why not looking at existing voting system as I said like a Swiss voting system which is really has a couple of years of experience and maybe you can we can learn from there something that's my proposal but still again thank you very much for your great job everybody here on Um, >> thank you. Thank you, Walter. And there's some other remarks as well around voter fatigue and and domain understanding. And Paulo, just to conclude, have you sort of got any sort of final remarks to wrap things up on the governance side? >> Uh, no, I just want to thanks everybody for the inspiring ideas, feedback. And uh for if there is a way to to save the questions that are in the chat because I'm afraid they will be gone. >> Um >> you know because I didn't have time to read all of them but >> yeah I'll get those best. Great. And and we'll we'll um >> yeah, I know there's, you know, we're planning to hold a a workshop on this, a governance workshop on this in in the next couple of months along with other workshops as well as we look to disseminate our our work here more effectively and to you know build partnerships with stakeholders in in the community around the different domains and across the body of work um under Kadano Vision 26. So, um, yeah, we we'll we'll we'll make sure that we notify you of of those as and when they happen. Um, so yeah, I I'm I'm going to we're on the half hour, so I'm going to I'm going to call time if if I may. So, thank you all for your for your time um uh today in in joining the session. I hope it's been informative. Um thank you to my colleagues presenting. I I know there's a lot of work that goes into these presentations. Uh the report is available um the midyear report. So, please share it. Please have a read. Um please come back to us with any questions or clarifications. Uh this is a consult community consultation now for for a couple of a two to three weeks. Uh so we do invite feedback. uh and um uh yeah, you know, we'll we'll we'll carry on um working hard at Kadano Vision 26 and and and bringing bringing out these these research and innovation results and and with a particular focus on on on uh on practically making them a reality and implementing them um in in the near future. So, thank you all for your time and uh wish you a a good afternoon and uh good well well cut final weekend this weekend for the team still involved. >> [laughter] [snorts] >> Thanks everyone for joining. >> Thank you. >> That's her. >> Thank you. >> Bye. >> Thank you.