The mute button is hard sometimes. Hey. So thank you so much, for the amazing kind of words, Nathan. I really appreciate your all the work that you're doing in the Medigob to make build play being a a protocol politician easier, standardizing these things. Medigov has a, like, a really important role that, you know, as a as a kind of a tweener, as they say, between organizations, and it's doing critical work. I'm going with this project, pairwise. I'm going at the other direction of really, like, a quick application that can be used by DAOs, kind of like Snapshot. But the goal is, as you said, to make it easy. Effectively, we're taking the Tinder UX and applying it to making decisions within a community. The the the fact of the matter is oh, come on. Switch there we go. Fact of the matter is that being in DAOs suck. Like, I don't do you guys like reading forum posts and, like, voting in all these DAOs? I am sick of it. I think it's way too much overhead. It doesn't make any sense for everybody to come in with to spend so much time to get the context to be able to make decisions, And we need to find a better way because it's not working. Dow ing is hard. And whether like, people will start off really excited and then eventually trail off because they have lives. They get apathetic. And in this whole yes, no voting strategy, like, this is stuff that we had. Like, we're basically voting in Dallas. Like, people vote in the seventeen hundreds. You know, I think we can do better. I know we can do better. And a lot of people think one direction is to just try to make everything along metrics. And actually, this is ripped out of the budget box paper. So I want to give credit to Aaron and Daniel for this concept, but it is not, it doesn't make sense to make everything in metrics. There's because then it gets played. The good arts law is is the clear, like, argument against trying to instead of to fix the voting issue, just make everything along metrics. Do it all retroactively and and and and solve issues that way. But the fact is that when you start to measure everything and measurements become a target, it seems to be a good measure because it gets played. So we really want to still have subjective input by DAO members and people who are participating in decentralized protocols. But make it easy for them, you know, make it not feel like voting. Voting is bad. Signaling is great. In a dream world, a DAO would just be a whole bunch of people who share a mission. And the DAO would kind of be would would push along the directions that the that the DAO members are signaling. That without all of this bureaucracy around forum posts and yes, no voting. So pairwise is a first effort along those lines, and it's a very easy effort because of all the work that had been done on budget box to build a, a really robust foundation. So if you wanna learn more about BudgetBox, I'll probably pass it to Daniel and Aaron to talk about the history there. But, you know, these guys are p big brain PhDs that are way beyond my capacity. And the there's a really nice, paper here that goes into exactly how budget box works under the hood. But I'm gonna stay at the high level and just talk about how basically the use cases and where it works well and and what the issue is trying to address. So the main point is voting needs to be easy, needs to be fun, needs to be engaging. And and I think it needs to be contextual. I think different voting systems or different ways of solve of of deciding issues should be should have their own voting system. We shouldn't try to fit every decision into a forum post in a yes, no vote. And so Pairwise is great for some applications, specifically curating a list. If you have a lot of options and you wanna rank them or you wanna distribute funds to a large group of them, pairwise is a great solution. It's great for grants. It's great for, like, distributing grant funding. It's great for ranking NFTs. It's great for market feedback, market research. It's great for choosing any scenario where you have projects and you wanna rank them or you wanna reward them in in some kind of order fashion. Retro PGF, for instance, is a great application. And the the overall concept is in which I would love to see applied more often is to break large decisions into lots of small easy decisions that people can kinda come and go and apply some context apply their context and walk away. So in pairwise, we just show two options. Pairwise or get. Right? And or abstain. And then the person picks one or the other. And it could be in this case, this this is a screenshot from retroactive public goods funding. So it's like, hey. Which one of these has provided more value, to the OP stack? Pairwise or guy? You know? And then you pick one, or you pick abstain. And, actually, one thing we got from feedback in our in our prototype is that we need to make the abstain button really big and in the middle so that people choose to click abstain when they don't have the context. At the end, you end up with a a a weighted list. So you can use that way to list as a winner takes all. Hey. The first one wins. You know? First one wins $500. Second one wins $200. Done. You know? Or you can use an ordered list, and maybe there's certain benefits that follow the order. Like, in Giveth, we want to we have this program called Givebacks, and this is what the original driver was for me to use pairwise or build out this this this protocol is to kind of reward give give project owners the ability to also participate in governance on which projects get givebacks. Right now, it's a 100% plutocratic. It's somewhat quadratic, you could say in a sense, but it's still mostly a plutocratic game where give token holders stake, give tokens behind their favorite give us projects, and then the ones with the most stake, get the most givebacks. Givebacks are when people donate to a project, they get give tokens back. And this is kind of like following the model of tax deductions for donors, but without taxes and governments. And so, well, we have it so that give token holders decide who gets the most. But that's too plutocratic. We want to enable other inputs without having this just pure, like, token weighted. Pairwise is our solution to that. And also, our audience is nonprofit donors, nonprofit projects, people who are not crypto friendly. So we wanna make it as easy as possible. And that's what Pairwise does. So and the end results can be this order list, or it can also be a weighted list where every project that was participating gets a percentage. And retroactive funding, for instance, I was a participant. I'm a citizen in Optimism House, and we had to we had a 195 projects. We had to allocate a percentage to each of those projects of how much funding they should receive. 195 projects. Lots of those projects are getting less than 1%, and I have to, like, figure out, oh, yeah, point 01% for that project. Point 02% for that project. It doesn't make any sense. But pairwise can give the output directly. And it's worth mentioning that we're proposing this right now, actually, Zeptimus, who made this slideshow. Oh, this is actually the wrong one. But we have a we have a draft up right now to propose the optimism to use pairwise for retro PGF. So that's very exciting. And that went up yesterday. Yeah. And the way that it works, and maybe I can even just show the actual prototype that we built, is that if we're trying to model after after snapshot so that any DAO can come in and create a space. They create a space where they create their own votes. So if we go to Optimism, we have these two pairwise votes in the space. Soon, we're gonna actually make it hierarchical so we can so you can have multiple votes, for the same kind of decision making process. What I mean by hierarchical is to kind of, increase the context of the comparisons. So, like, right now, we have this, project, right, where any OP holder can vote, on on this, and only OP token holders can vote. And so now we have this community project, Optimism in Spanish, versus this development project, Zapper. And those are contextually different. So what we'd like to do in the next version, something we learned from here, is to break it up a little bit more contextually so that we have, like maybe you have development projects versus community projects, and you have, all of the you you would have those two choices come up. And then you would do a pairwise comparison between all of the different groupings of potential projects. And then when you go into those projects, you have a pairwise specifically for community projects. So you wouldn't be comparing optimism in Spanish versus zapper. You'd be comparing optimism in Spanish versus the, like, community community development in Discord. You know? And then, you would pick which one you think is more important in that context. But it's really easy. As you can see, you can just do you want optimism support nerds or optimism ambassadors? Just click one. You're right. It's a little we need to add abstain as a bigger button, but you can also click abstain. And so you can just click these. And if you wanna know more context, you can click here and learn about the context of this project, right, and what their submission, basically. And then you can submit the vote, and it and it follows the snapshot pattern where you can create a snapshot strategy and a way to vote, and you just sign a message on MetaMask, and there's no gas fees or any of that. Yeah. So each DAO can have their own space. You just add a question, whatever you're talking about. Maybe you just wanna rank your you'd get market research on your NFTs and say, which NFT is the cutest? You know? And you can have really fun games like that. We are really trying to follow the pattern that Snapshot made, but for specific types of decisions and with a specific type of UX. In a dream world, one day, maybe this just gets merged upstream to to Snapshot, and it's not my problem anymore. That would be great. But our current path is, you know, obviously, this project was really started in 2018 by Daniel and Aaron. And now we you know, after a long migration, we're taking it. We're taking the flag and pushing it. We have a deep road map, which involves a you know, now that we already launched the prototype and learned a lot from user testing, and we have some very strong idea a way better idea of how to implement the user experience. And now we're just basically seeking funding for the project so that we can development develop it in this bear market and not be delayed. Yeah. And so you can reach out to me, or you can reach out to Zephyrnis, who's also in this call if you have any interest in in using pairwise for your project. And hopefully, the other option the other thing is to go into if you have any OP tokens, vote for us in the upcoming vote in a week and a half. Maybe I'll open it up to questions. But if there's no questions, I can also pass it to Daniel and Aaron to talk about the, like, back like, what's happening behind the scenes.

Yeah. So I don't know. Aaron or Daniel, who wants to, like, talk about how Pairwise works because, you know, there's a it's similar to ranked choice voting. I think this is really interesting personally as, like, a governance nerd that it but it's not using a traditional ranked choice voting method. It's actually using more like a page rank algorithm. Yeah.

Yeah. And I think one thing that I would I would add to that is I think that in terms of having the decisions be I I think a kind of a maybe a phrasing I like was every decision should contain its own context. Meaning every decision should really be intuitive for for the participant to know kind of what is being done. And, you know, if we compare, like, is this a good or a bad proposal? You know, I would say every proposal is is a good one under ideal conditions. You know? So, you know, do I vote yes or no on this proposal? It's like, well, in an ideal world, I'd vote yes on every proposal. But, you know, ultimately, there's a lot of constraints, I. E. A lot of context that I need as a participant to make a yes no decision. So even though a yes no decision seems simple on its face, it actually requires a ton of context, whereas a pairwise decision, it's still just one bit if you think about it. It's still just ultimately like a a one bit decision. But when you frame the decision as a relative one instead of as an absolute one, a lot of the context, a lot of the hidden context goes away, and a lot of the context becomes much more intelligible to the participant. So that's sort of, I think, what Aaron and Griff were talking about in terms of the simplicity. Right? A pairwise decision is much simpler to understand than a up or down good or bad decision because the up or down good or bad decision just requires a ton of implicit context that the relative choice does not.

And, you know, if no one else has questions, I have questions. I wanna understand how the ranking works because there's a lot of ways to manage ranked choice voting, and this doesn't use any of them is my understanding.

Yeah. That's that's that's a good question. I mean, and, ultimately, the technique that we use is, like, the actual the actual math of it is is almost the least interesting part of this work because that is actually that's just well established. Right? I think, ultimately, you know, this technique, which is creating a markup matrix and finding the steady state distribution is something they've been doing since the nineties, if not before. They use it for ranking sports teams. You know, ultimately, Google used it to rank web pages. The idea of taking these interactions and coming up with the ranking is a super established, I think, fascinating algorithm. I think that I don't wanna say it first, but I think applying it to, like, a voting setting explicitly was something that I don't know had been done in the past before. But the actual math is very well established. You know, the idea is, well, you you taste it. You take a couple of interactions, right? Like, imagine you have a sports league and you wanna know who the best team is. You don't have you can't have every team play every team. So you have some teams play each other. And then from that, you infer what the, what the ideal winners would've been. And it's basically, you know, yeah, that that's basically that. And I think that the, the percentage you could say, well, I guess, like, to may maybe to to think of the intuition, right, you have all of these interactions, with different teams playing or in this case, different projects going head to head, and you get this matrix of, you know, when these two people matched up, this was the results. Right? That's the data that you observe is the results of the matchups. And then you basically say, let's basically I almost think of it as turning a crank. Let's run like this almost like I you know, it's like a you know, out of a 100%, it's let's run the, like, victory juice through the through the matrix with a crank. And every time there's a victory, some energy juice flows through to that winner. And so we just keep running it until it kind of all settles. And then we just kinda see where the energy juice ended up, and that's our distribution percentages. And then we say, well, if we have a percentage if we have percentages, why not just give people money according to the percentage? That was something that that was something that we added. The idea, like, the math of using the matrix already existed, but saying we could just give out money based on the percentages or something that I don't know I I hadn't seen done before.

I hear that. I think my the one kind of thing I I would push back on is, you know, I I think that the idea that we know in advance how much something costs and if we just had that much money, it would, get done. I I I'm I'm suspicious of that as as the reality. You know, I think that people

it's just

But what

I'm saying, like, you know, you can ask, say, it's gonna cost us 10,000. And then $10,000 later, you're like, well, it's gonna cost us 5,000 more. So the the idea that the idea that only funding someone's request is meaningful and anything other than that is not meaningful, I'm I'm skeptical of that as the reality. Also something I would say is, you know, what if we looked at funding not as a one off payment, but as rather like a continuous drip where, you know and that's the nice thing about having this budget is there's no rule saying that, you know, it's once a year we give out money to people. It could be every day or every time increments, we give out some money. And it's really the the rate of you getting funding is is the result of of this sort of distribution. And then ultimately, every project then says, okay. We are gaining resources at a rate of whatever. We can now take that as an input to make our own planning. If we need, you know, if we're getting a thousand dollars a month, okay, then it'll take us ten months to save up what we need. If we're getting 3,000 a month, it'll take us three months, you know? And then if our if our and costs go up to 15,000, okay, it'll take us such and such more months. So I think that thinking of these thinking of financial planning, not as, like, a one once a year process, but as an ongoing continuous process, I think would make some of those experiences of getting underfunded. I think, it's almost like cutting the Gordian knot. It just it's it's it's sort of just a different framing. That's kind of my suggestion or my my thought.

Yeah. I mean, I think the last thing I'd say, one one can imagine a setting where, okay, we use this technique to determine our top level budgets, like the amount going to, you know, engineering or product or marketing, or you could say the amount going to web three software projects versus advocacy projects or whatever. And then within that, the actual grants to projects are one off. Right? So you determine the major allocation categories, the very large numbers, but then within that, the specific recipients are either are all or nothing. Right? So you have, like, a a dual layered system now where the the the the recipients get all or nothing, but the the the major allocations for the organization or the project are done using this technique. One can imagine a setup like that as well.

And and I I wanna throw out, this this make, like, reinforce this idea of context specific decisions. And I think Vitalik has this really nice post where he talks about, like, when the wisdom of the crowds is useful and when when it's not and making the simple analogy between concave and convex decisions, where, like, basically, a concave decision is a decision where compromise is usually better for all involved. And a convex decision is where choosing making a compromise actually makes a worse decision. So you can think of, like, one group wants blue for the website color and the other group wants red. Well, I guess we do purple. No one wants purple. So it's actually a worse decision. That's not good. But, hey, a lot of people want to fund fund these projects to help the homeless. A lot of people want to fund those projects to help the homeless. Let's fund them all a varying amount. That's probably actually going to push push forward the the, like, community that cares about helping the homeless more than if you kind of let some just die off and those people have to go get other jobs. And and, like yeah. And and the context that he's really bringing out here for that kind of for the public goods funding is specifically this retroactive public goods funding that optimism is trying to promote. And I'd love to hear your thoughts on this actually because their their model I I assume you may have heard of it, but maybe not. Their so I'll repeat it. Their model is that, hey. If we can reliably allocate a budget to fund public goods in some context, then people will actually be able to even create businesses around receiving the public goods funding so that they can, so they can even launch a token and, sell that token to investors and then whatever funding they get is between those investors. And, and the idea is that, well, there's a big challenge in, using using a, like, a small group to make those kinds of decisions because it's it's very likely to be in, like, corruptible. And the best solution at least this is what Vitalik says in this post. Let me see if I can make sure I find the right heading. Yeah. Here it is. The best solution so there's kinda, like, three ways to mitigate the corruption and insider trading issues. It's either punish malicious deciders, proactively built filter for trusted equality decision makers, or just add more people. And to add more people, we need, you know, easy UX. We need simple decision making, that doesn't rely on a lot of context and, decisions that are broad, you know, that have this kind of broad appeal. And so I really feel, pairwise is is especially useful for this kind of solution, especially compared to oh, not that one. I wanna show you what we use to vote in retroactive public goods funding. It was so bad. Like, I mean, we literally had this spreadsheet. This is this is my spreadsheet. And, I went and we built like, independently, we built, like, a system to kind of, like, say small, medium, or large and kinda categorize them already. But all we had to do was put in this this allocation into a form. We literally had to put a percentage next to all of these projects. And, I mean, it's just impossible. A 195 projects, and we have to come up with a small percentage. It was a very difficult decision.

I have a I another thought, but, also, Edward had some comments in the chat that I was sort of curious to to hear expounded upon. One thing I will say, though, is one nice thing about this approach as well compared to pass, fail, vote is that participants can actually update their inputs arbitrarily. So this is not like a one and done. It actually this represents more of an ongoing asynchronous thing where it could be, you know, in January, you're like, I wanna put more funding towards this domain, but in in March, I I actually wanna redirect some funding. So we've got not only is the funding being distributed continuously, but the allocation is being updated continuously as information comes in. So we've got it's basically much more responsive to new information and to course correct for errors. So I think those are some nice attributes of this where even if there's some randomness or noise at various points, the distribution can adapt as participants gain new knowledge. So there's an aspect of self correcting here that is not as available when it's a pass fail on a proposal type of regime. That's that's one of the thing I would throw out there. But I am really curious to hear Ed's experiences because it sounds like there's a lot of relevant guidance and counsel there.

Sure. I'd be happy to share just for a minute. Can you hear me?

Yeah.

So, you know, what I've used all our ideas. I don't know if you know that, which has sort of been a tool for this kind of pairwise ranking that's been around for quite a while. I mean, I'm very excited about this. As, you know, it's obviously, like, the sort of default way we make these opinions these decisions right now, I think, is terrible. So I'm very keen on looking at different ways of doing it. I've applied it sort of, you know, real situations with real committees to try and do real funding, three times. You know, each each with, like, significant amounts of money, sort of $5.05 or 6 figures. And, generally, the way that it was done was we would create a list of all of the projects or proposals, and then the committee would would spend, you know, half an hour voting. And then this is you know, the committees would be between ten and twenty people. You know, what we found is people could people were happy to use it. In in thirty minutes, you can get, like, tens of thousands of votes somehow, which is quite fantastic. And then somehow that feels quite legitimate, But then a lot of people express surprise with the outcomes. And generally when they would have to sort of vote on whether they like the outcomes, they would not feel very enthusiastic about it, which I think is somehow quite surprising, particularly when both they come up with all the suggestions and and and and there's so many vote. And what we found in general is it's quite good at sort of sorting the things that no one wants from the things that are generally okay. There's quite a lot of noise between, like, individual pairs, especially at the extremes because those ones don't get tested against each other very much. And, also, like, it doesn't you know, it kind of does, like, generalized success rather than, like, ranking. Right? It's sort of how the algorithm works. So so so you can't necessarily trust, like, you know, 95% versus 97%. I think that's sort of, like, dangerous. So your cutoffs have to be quite, like, generous. The other thing we found was, certainly, you end up with kind of, like, incompatible you know, if you have one one proposal that wants more than half your budget and then the second one also wants more than half your budget, you know, you can find where, like, both of these things are very popular and then that doesn't really solve your budgeting problem. So rather than having I mean, this is much harder, but you can start with sort of having, like, a strategic budget allocation rather than a project budget allocation. So you can say, you know, we wanna have 10% of our budget to this kind of project and 50% of our budget to this kind of project. And then you can compare that to, like, 30% of our project and put and that kind of thing you can compare to talk about, like, how you're gonna allocate your budget sort of in in terms of buckets rather than, like, projects. We think this might be a bit more robust because anything you end up with will be a valid allocation. And it can be easy to end up with sort of, like, invalid allocations. Because, you know, somehow the the most obvious thing to do is you sort of start at the top and you keep going down until you run out money. Right? That's your basic approach. But so unfortunately, in practice, it doesn't work. You know, we found that, like, you know, you end up with, like, lots of very small projects which would, like, be very easy to fund. You know, don't get near the top because they're somehow less interesting because they're smaller. But you could find a ton of those. And then you have, like, two big projects at the top, which you can only find one of. And then you don't really sort of trust that decision very well. So so in practice, you sort of have to, like, manually rearrange. You know? I don't know. I mean, it it was quite difficult in practice because it doesn't have, you know, in some sense, the sensitivity, and then you don't really get the sort of explanation of this of this, like, specific ranking, you know, when you then have to, like like, have consensus on your decision. So so so in a sense, it has lots of really nice properties, but in practice, it's, like, quite surprising and quite frustrating at the same time.

I just I have one comment. That's actually a great story. I didn't realize anyone had done something like that. One thing I will say is I'm familiar with all our ideas. Their their technique is actually different. So it could be it could be that that their actual their actual calculation for determining the result is is not quite the same. I am curious to what extent that makes a difference because I I remember in my first machine learning class, it's so funny. I remember, like, when the technique was first presented, I almost, like, heard a bell go off in the back of my head. I was like, this is the place. You know? So, like, the actual the mark off technique, I really do think, has a lot of amazing properties specifically for legitimacy that, I think other techniques might not always have. So I think that's my one piece of feedback. Although that said, like, you know, the fact that you did this in practice is actually very cool. And so I'm I'm I'm hearing what you're saying, and I'm taking it very seriously.

I mean, I'd try it again. You know. But, but it but it was and, like, it for a lot of the participant I mean, obviously, like, I'm a fan of trying weird things. But if somehow you're not, and then you have this and it feels surprising, it it it's quite difficult to through.

I I also think I think your point about, you know, the setup is important. Right? I think that, you know, maybe maybe the idea of funding departments where there's not a sense of all or nothing, more like a bucket, would be a a better use case. It sounds like a lot of those a lot of the issues that we're having, which is it's over underfunded, kind of go away if you go one level high up in the abstraction and say we're just we're funding areas.

Exactly. You know, I mean, with any general purpose tool like this, there's a lot of sort of configuration as possible, and there may be nice ways of using it and not nice ways of using it. So you just have to, like, frame it in terms of what other people hopefully do things that will work out.

I I I think the biggest key is that you have to be working in a in a in an area. For Pairwise to be useful, it has to be an area of decision making where the wisdom of the crowds will add value. If if it's a very context specific decision where, like, experts know what's going on, don't use Pairwise. Get in a room. Talk about it. But if you're trying to get hundreds or thousands of people to signal on what is the best solution for, you know, taking care of the environment in the city. This is a way better way to get people to vote than having a politician who's got lots of other issues kind of just decide. Right? And it it's really about the the use case.

So I'll be honest. For the prototype, it is equal rights because we're lazy. Even though we're using snapshot strategy, we kinda just made a hack to shortcut it because this is a very early stage prototype that was just mostly for user experience testing. But in practice, we want to implement snapshot strategies. So it's a 100% you could have tokens on a variety of networks and and NFTs, and you could say that people and you can give a score or a weight to anyone's on chain identity or on chain address to any tokens that they hold or any kind of attributes. We ask actually also wanna integrate Optimism's attestations. Well, I guess the Ethereum attestation system, which is mostly being used on Optimism, so that we can even have on chain attestations, which aren't even tokens, have a weight. And everybody has a different voting power. And that I I couldn't agree more with you, Chi, that this is, like, critical for real stakeholder, you know, voting for decisions to be made. They we can't have one person, one vote. I don't I just don't believe in it. I wish I did. However, I do believe I wish that we had I do believe in the quadratics style where individuals do have, like, unique perspectives that have value. And so maybe if you have a 100 tokens and this person has one, maybe you have 10 times the voting power, not a 100 times the voting power. But but, absolutely, that's at least how we're designing. We're not trying to recreate any wheels here. Snapshot did a great job. So we're gonna import everything that Snapshot did.

And I do have use cases for one person, one vote in mind.

Do you wanna show proof of history? Because I don't know what I don't know what you mean.

Cool.

Very cool. Yeah. And I believe we met before and have have chatted about this a little bit. I was at, just recently at one of these conferences. Right? Do you participate in the BitDAO ecosystem a little bit?

Oh, okay.

I had a sorry. I know Nathan in the chat posted about she and Steve's comment about reputation. One thing I will say is 100%, this could be used to develop reputation scores. And, actually, I believe that this is similar to what they use for chess players, the ELO rating. And in that case, though, that's based on head to head competition. Right? So, ultimately, you could say, well, we could either base the scores on the outcome of actual competitions in the case of chess players, or we could base the scores on observers' subjective opinions about which of the two is more important. Right? But and and as far as the technique is concerned, they're equivalent. Right? Is the is the matrix a result of actual head to head matchups in the case of chess or sports, or is it the result of people inputting preferences as, like, a community of observers? But those are either one ultimately from the perspective of the technique is the same. So you you can you either have the the head to head use case or the the subjective, perception use case, but you get the same results. And you can treat them both as reputation, just of different of different kinds that mean different things.

Yeah. I mean, the biggest challenge is this high context decision making expectation and just like the difficulty of being able to signal your voice as a DAO member. And and it's just a lot of work. It shouldn't be so much work. You know, you do not have to vote for Amazon to try to sell you a backpack. Your behavior is is watched. And then there are algorithms that try to satisfy your needs without you having to do anything. And this is what I wanna see in DAO governance. You know, pairwise is just a first step, I think, in evolving the way that we make decisions as communities. And making that more passive, making it be something like what happens in the advertising space. You know, if you're developing a blockchain video game, you have all of these characters with on chain identities, on chain reputation, assets, various things. And when they choose, how many choose to go into battles? And how many choose to try to save the princess? And how many choose to try to, you know, I don't know, you know, just, like, mess with people, you know, and, like like, troll people? Like, all of that is is actually really interesting data that can be used for the organization, the DAO that runs this video game to kind of like satisfy the needs of their users. Right? To try to like say, oh, well, you know, everyone keeps trolling each other. We should just go full on into that. And we don't, no one's trying to rescue the princess. No one cares about the princess. What are we thinking? Stop building those kinds of things and start building these kinds of things and really going more data centric and in a transparent way so people can see what decisions they're making. And like, pairwise is a specific application trying to bring in the wisdom from, you know, you know, how we how we rank people in sports sporting events. Right, and for sports leagues and trying to apply that to DAO governance. I wanna see more of that. I wanna see us start to apply advertising and techniques in AI and and machine learning that are commonly applied for solving problems and and have them be projected into how do we get signals from DAO members to move a community forward. Pairwise is honestly a tiny step, not even the first step on the moon, not even close. It's more like someone putting some screws into a spaceship. You know? It's it's really a small step towards where I think we wanna go, which is signal aggregation. Individuals doing things, reading that, making decisions off of that. And and sometimes that's automated peep automated, and sometimes that's humans taking the data and making decisions. But any kind of mix will make being part of a DAO something you want to do, you know, not a chore right now. Being a delegate for optimism, ENS, TC, give it get coin. I don't know. Probably others. I feel bad already for even trying to list them all because someone's gonna be like, they didn't say this, Griff. You're a top 20 delegate. You know, I can't it's a chore. It's an obligation. It doesn't feel like a privilege or something I wanna do at some point. You know? It's something I do as my job. But being part of the DAO shouldn't feel like a job. It should feel like a privilege, like an opportunity, like something that like, because you have these tokens, now your signals have value, not you have to go read some forum posts and vote. So that's that's my rant. That's my rant on this. It it we have to do better. We have to do better.

Thanks, Ed.

Thank you.