DOT Decoded Everything You Need To Know Before Investing by founder Gavin Wood

Hi Laura, nice to see you again.

Well, there are many sort of answers to this question. It's an interesting one. In many respects, it was a very abstract thing that I wanted to do when I started Polkadot. It was really just a push to become more abstract, more general over what it was that we were solving, what it was that we were producing. So it's like, you know, Bitcoin started off with a very basic scripting language, Ethereum sort of introduced this much more complete means of scripting financial transactions, and really with Polkadot it was trying to create something that produced an even more general model for how it can be extended, how things can be added. And then on top of that, it was really also trying to address this fundamental problem of scalability: how do we try and push through more transactions? How do we take advantage of the fact that there's an awful lot of workers out there on the network, but it's so wasteful to have them all working on the same thing? So it was these twin sort of topics, this generality and scalability, and really the vision was just to sort of make blockchain great again. It's like, can we take blockchain to a step further? Can we actually address some of these really important issues that we've always known have existed? You can go really quite far back, five, ten years, and see that people are already thinking, well, we really need to process different transactions on different nodes, we really need to be more general. And it was really just kind of, can we bring this forward? Can we be more general? Can we process more transactions on different nodes?

Yes, they are. So a meta protocol is, it's like, a meta means sort of after or beyond, and it's generally used to mean the next sort of step down this concept. So it's like, you know, a meta protocol is a protocol that governs another protocol, a protocol on which you can place another protocol. It's like a protocol of protocols. And what I mean by meta protocol in this sense really is that it's an underlying, much more basic, much simpler protocol on which we build what we would normally consider to be the protocol. So to take an example, the protocol of Bitcoin is, well, we send blocks around, and these blocks, when you execute them, when you interpret the blocks or the transactions in them, there are transactions with some script, but basically most of the time it means send these Bitcoins to these addresses. And that's a protocol we, the nodes of the Bitcoin network, understand how to interpret these blocks, right? It's language basically. But it's very difficult once you've set that language, it's kind of set in stone, it's very difficult to alter it, to change it, to introduce additional features, to fix bugs. And it's very rigid. A meta protocol would sit underneath that protocol and define that protocol. And the nice thing is that because it's defined in terms of this meta protocol, then you can change it quite easily. You just have to obey the rules of the meta protocol, and then the main protocol can adapt and evolve and iterate over time. So then the question is, well, why is that? What if you need to adapt, evolve, and iterate on the meta protocol? The idea with that is that we make it as simple and as abstract as possible. We take a pre-existing technology, something that has already kind of been iterated through, something that very clever people, people from many different stakeholders, have already argued about and sort of come to the decision that this is probably the best thing that does this kind of meta protocolized stuff. And what we did was, well, we chose basically WebAssembly, because WebAssembly is like an industry standard. It's been iterated on. It's actually already two separate technologies, one built by Mozilla, one built by Google, has sort of been spun together into this thing, WebAssembly. So it's already got a lot of ideas, it's already had a lot of iterations. It's unlikely that we're ever really going to need to change it, and therefore it's a really good foundation to build our stuff on, this meta protocol. And then we just have to define everything else in terms of that, and that's where the protocol comes in. So the real Polkadot protocol, parachains and governance and balancing and DOT protocol and staking, all of this stuff is the Polkadot protocol, and that stuff changes over time. But it's defined in terms of the meta protocol that doesn't really change over time. And that's the stuff that we make sure that we've got this tried and tested, very well understood, well-known technology in WebAssembly. So yeah, it is a lot about being flexible and abstract, because this top level, the Polkadot protocol, is not very abstract. I mean, it is, parachains are pretty good, but there's still a very specific way of having different shards there, a specific way of scaling there, a specific way of having a market mechanism to claim them. So it's still like opinionated, as we would say, there's still a lot of opinions involved in it. Whereas the WebAssembly isn't very opinionated, or it's not even our opinion, it's someone else's, it's Google's and Mozilla's and Microsoft's and all of their opinions really. We just said, right, well, you guys have had time to argue about whose opinion is best, we'll take the answer and use it because we don't want to argue, we just want to have something that's stable. And because of that, it's a more abstract level that we can build things on. So there is these dual levels: the meta protocol, very abstract, very general, doesn't change very much, and the protocol, much more opinionated, more specific, changes a lot, because our opinions are always wrong in the fullness of time, opinions are always wrong, they always need changing, design always needs changing, it iterates over time, and we want to allow ourselves to evolve. And that's why having these two separate protocols, the meta protocol on the bottom, the protocol building on top of it, is how we achieve that. And it's the same how we get from Bitcoin to Ethereum to Polkadot. There is this idea of, well, with Bitcoin it wasn't really programmable, with Ethereum it was kind of programmable, but you have this very limited computation model with gas and dynamic gas pricing and dynamic counting of resources and limited memory and storage, and it was all very expensive. And that all changes with the computation model in Polkadot, because we have parachains which are much more abstract, much more general, in that they're not just the smart contract, an easy little bit of code that keeps some records of maybe people's balances, but rather an entire blockchain that can basically do more or less anything that you can imagine a blockchain to do. And that's a much more abstract thing. And I'll give you a concrete reason why that's an abstract thing: you could easily implement a smart contract inside of a blockchain, there already are blockchains that do it, Edgeware, Moonbeam, a few others. You can't do it the other way around. You can't implement a blockchain inside of a smart contract because there's just not enough computational power. It's like trying to shove a shoe inside of a thimble, you know, it doesn't, one can contain the other, the other can't contain the one. And that's why we can say, well, look, Polkadot and the parachain model is more general than the smart contract model. Now it doesn't mean it's better for all use cases in all circumstances, but it does mean that anything that you can do in a smart contract, you can do in a parachain, but not the other way around. There's a lot of things that you can do in a parachain that you really can't, or that at the very least would be extremely difficult to do in a smart contract.

Yeah, so parachains, as a term, it's sort of evolved a little bit over time, but broadly speaking parachains are these slots, they're like, there's some number of them, and they're a little bit like computer cores. So your computer has a bunch of CPUs, I mean this one that I'm on I think has four, but some of them these days have six or eight or even more. And the CPUs can process a particular application at once. So if you've got a bunch of windows open, then it might be that one of the cores is doing the video playing in one window, and another core is helping your web browser render the email in another window, and another core is playing your music in the background or whatever. So they can do different workloads. Well, basically parachains are like this but for a blockchain. So they can do different workloads. One of them might be processing smart contract transactions, another might be processing balance transfers, like kind of Bitcoin transfer transactions, another one might be doing governance, another one might be calculating what the optimum staking situation is. So each of these cores, each of these parachains, can do different things at any given time. And we measure time in terms of blocks. So it's like this particular block, block number 1,470,293, is doing this, it's got a staking parachain, it's got a governance parachain, it's got two or three smart contract parachains, and so on. Now, parathreads are when we say, right, well, this application doesn't need to be processing transactions literally every block, maybe it only needs to process transactions every 10th block, right? So instead of it happening every six seconds, it's every minute. Now that's perfectly reasonable. Bitcoin doesn't process transactions, you know, some of the time it takes an hour before the transactions go through, you know, on average it should be about 10 minutes. So it's not unreasonable to expect that probably one block in every 10 is sufficient for quite a lot of use cases. So then we say, right, well, rather than having this application just constantly always taking up one of these processing slots, even when maybe it doesn't have that many transactions to process, instead what we do is we say, right, well, you don't get any by default, but when you're ready to process some transactions, when you've got a bunch in your queue and they're important enough or they've been waiting long enough or whatever, then you pay a bit of money, but only a little bit, and they get processed. You sort of just push them bulk onto the Polkadot network, and you get a block, it's like you get in one of these Polkadot blocks, you get your block being processed, you get your block of transactions through.

Yeah, there's a few. So one of them would be an oracle. So you can imagine there will be some oracle situations, they're feeding in data from the external world. Now feeding in a load of data every six seconds seems overkill for a lot of it. I mean, you know, if you're talking about weather data, you don't need to update the weather every six seconds, right? Maybe once an hour, I don't know, once a day, but yeah, definitely not every six seconds. You know, 500 raindrops have fallen, 493 more raindrops have fallen, no. So we can imagine that actually, and with weather it's like, you know, maybe once an hour, once every half hour tops, and maybe it doesn't matter whether it's literally 30 minutes to the dot after the last update, maybe it's okay for it to be like 30, 31 minutes after the last update, you know, there's no huge time deadline. And that would be a really good one for parathreads, because they would just basically have some amount of money, of tokens or whatever, that they want to pay in order to get their new block of weather information, that update in, and then they just wait until the chain of Polkadot is sufficiently unused, underutilized, and then their block will go in. A little bit like how transactions work in Bitcoin and Ethereum right now. So you know, you got your transaction fee and maybe it sticks around for a block or two or three until a miner picks it up because there aren't enough other transactions that are paying more. So very similar in that regard, basically just an adaptive market. Another use case would be regional applications. So it could be that there's a US-centric or a China-centric insurance app, and it's like, look, people don't claim their insurance mostly at 4 a.m., right? Mostly any claim that's going down happens at 4:00 a.m. perhaps, but the insurance claim comes a day or two later in daylight hours. And so realistically for these kinds of regional daylight hour use cases, you're going to have like eight, ten hours where people are going to use it, there's going to be transactions, but the rest of the day, the rest of the 24-hour period, there won't be very much going on. And it doesn't make sense therefore to have a constantly scheduled parachain slot if 60% of the time it's not being used, no transactions.

Well, I mean, it's going to be an ecosystem, so there's going to be a lot of different things all kind of helping each other to get to the end use cases. Something that seems pretty clear is that we can't jump past this stage. The magic of blockchain isn't really in delivering a specific use case really well. We've had a lot of time to do that and nothing's really come through, one or two minor exceptions, but more or less. Where we have seen hugely promising developments is in the emergent effects of being able to combine multiple use cases, multiple applications, multiple solutions, in an environment where they can form symbiotic relationships, build on top of each other, and provide a composite solution that no one ever really designed, but that nonetheless fulfills some goals. So you know, you've got the flash loans, you've got the paycheck loans, you've seen a bit of the DeFi thing happening at the moment. That's kind of where I think blockchain is able to provide a good step forward in providing these trustless environments where people can be very experimental and deploy interesting use cases, interesting applications, interesting bits of code that build upon that, that form symbiotic relationships with pre-existing bits of code, and that allow others to build upon that. So this is what we call composition, it's what we call emergent effects, and I think that's really where things are going to go. So what kind of parachains? I mean, there's going to be parachains that want to specialize in smart contracts for sure, just because they're an easier way of developing and deploying stuff than a full-blown blockchain, though interestingly enough, not that much easier. I think we're going to see different blockchains that come with niche applications that they provide, plus a smart contract component that allows people to extend those applications. So at the moment we have in chains like Ethereum, we have a lot of smart contracts deployed into them, each one fulfilling a particular niche, but none of them are particularly performant, none of them scale well, none of them are really utilizing the computational power of the machines. What I think we're going to end up with is the smart contract environment primarily used for extending the functionality of things, but where the blockchain itself provides the sort of really bread and butter logic for doing flash loans, for doing decentralized exchanges, for transferring funds, for governance voting functions. This I think is going to migrate to a more fixed part of the blockchain, like basically what Substrate provides to you. And yeah, the smart contracts, the sort of fast iteration on the smart contracts where people can develop and deploy very quickly, will be for more experimental, extensible stuff. So I think we're going to have a lot of different flavor smart contract chains doing things super diverse. We're going to have oracle chains, like chains that are very specialized to just have data pumped into them. There'll be chains that actuate stuff, I think. So you know, Slock.it, I don't know, they're not really doing much anymore, but as far as I know, sorry if you are guys, they were acquired by Blockchain's LLC, right? Yeah. So, you know, but good example of an actuator where they're actually, the transactions on blockchain are having effects in the physical world. I think we will see these kinds of things growing, whether it's home automation, maybe it's a blockchain that transactions are like turn my light on, turn my light off, and the advantage of using a blockchain is you get an indelible ledger of who told your lights to turn on and off, making it sort of more secure. But yeah, actuation blockchains may well become a thing. I mean, obviously there's things like consortium blockchains, parachains that bring together other sets of blockchains. We're going to have bridge chains that allow blockchains to connect, Polkadot and its parachains to connect to other networks. Yeah, I mean, there's going to be a lot.

Yeah, well, okay, so the retirement is an interesting thing. So you go back, I don't know, two, three years ago, it didn't really have a great answer to this question. It was sort of like, well, if they're useful then they'll just have to pay. But yeah, about a year and a half ago, came up with parathreads. I think it was a year and a half ago, maybe it was only a year ago. No, it was a year, yeah, it's 2020, yeah, a year and a half ago. And parathreads, as I mentioned, are these pay-as-you-go block pay-as-you-go parachains, right? So it's like they don't do much unless you sort of fund them, but you only pay for one block at a time. So you only need a few transactions that are willing to, you know, pay enough that the rest of the Polkadot network doesn't desperately want to use all of the parathread slots. And to give some, like, I would expect there'll be probably about 50 free slots for parathreads every six seconds. So I think when the calculations are done, it's like for each parathread, if you get one block in every, I don't know, 10 minutes, then it's like you can have 3,000 or 10,000 or something parathreads that are kind of mostly active. So they're going to be reasonably cheap. Now the idea is that when your parachain, if your parachain is sufficiently unuseful that you can't collect together the funds for renewing your slot, and it's not that this happens overnight, right? You get 18 months, in principle you get an 18-month grace period. So you got one and a half years to convince people to make your token worth enough that you can swap enough of it for DOTs to pay for your parachain slot, to lease out your parachain slot. And you get 18 months to actually secure that next six-month period. So you'll know very much ahead of time if this is coming. But that said, suppose for some reason you just can't scrape together the DOTs, then you don't just disappear in a puff of smoke with all of your oracle data or anything. Your chain stays active, it sticks around, it's there. An oracle would tend to use passive data transfer, which basically means you look at the relay chain to see what the last block was for that particular chain, and then you get one of the collators, one of the people who has the blockchain and its information, to give you a proof that, hey, what was the gold price most recently? And they'll come back with a proof that will use the data on the Polkadot relay chain plus some extra witness, some extra data that fits alongside that, and you plug them together and you can now be sure that the price of gold according to this parachain was such and such. Now, this will still work. So an oracle chain wouldn't actually stop working now, it just means that their updates wouldn't necessarily be every six seconds, it would be as often as it's willing to pay for its updates. And that's basically how it works. It's like, you know, when you've had a mobile phone contract and it's like, you know, you're paying per month and you're paying like $50 a month, and it's like, yeah, in the beginning it's okay, but then it kind of drags on, it drags on, and you're thinking, I'm not actually using this $50 a month subscription that much, it's not that useful to me. So you tell them, look, I want to cancel my subscription. They're like, oh well, if we can't persuade you not to keep your subscription, then I'll tell you what, you can keep the number, but you'll go on the pay-as-you-go tariff, right? So basically, just make sure you put, you know, $20 on every six months and you'll be fine, we'll keep your number active, you can still receive calls and all that. Basically, it's exactly the same with Polkadot. If once your subscription ends, then you just go directly onto the pay-as-you-go version tariff, and you can still keep your chain going, you just have to pay per block.

Yeah, because it's the same, it's exactly the same technology, like 100%.

Well, interesting question, yeah. It's really difficult to say because the auctions for parachains, I don't really want to start the auctions for parachains until pretty solidly sure that we know when the parachain is going to start. Because as soon as you start the auctions, you're taking, you know, people are locking up their DOTs, and it's like, well, yeah, it might be next week, it might be next year, not a great thing to be locking up your DOTs on, right? So parachain auctions are going to start once we basically have tested parachains on whichever network they're on. So you know, we've got Kusama and Polkadot, we roll them out to Kusama first because Polkadot, we don't push code on that isn't audited externally by our security company. So Kusama will get the unaudited code that we're still reasonably sure is okay, but you know, I know it, so you take what you will. And just for listeners who aren't sure what Kusama is, Kusama is basically the test network, but there's actual real value being staked on it, and the token, the KSM token, has real value. So the incentives are all there, and it's like a kind of a true test environment where you can actually see how the incentives will affect the ecosystem.

Sure. Well, now basically, the way that these auctions work is that we didn't want to, so blockchains necessarily are these super open and transparent things, everyone can see what's going on all the time. And what we didn't want was to have this game, this sort of auction game, where you, I don't know if you ever used eBay, I mean, I don't know, is it used these days or is everyone just using Amazon? I mean, I haven't used it in years, but back in the early days of Web 2, I was an avid eBayer, like sort of 2005-ish, 2007, that sort of thing. And what inevitably happened was the last 60 seconds, you know, the price would be, yeah, $5, slowly climbing up from $3, like $3.40, $3.45, and it'd get to like $5, and then the last 60 seconds it'd be like 10, 15, 50, 500. It's like, okay, right. So it was a 10-day auction, but actually all of the important bids happened in the last minute. Now that's a pretty standard kind of game theoretic thing to do, you basically hold your best bid for the very last point in the auction. And it's kind of rubbish to do that for a blockchain because it means that it's not great price discovery. People, if you hold it for the last minute, then it's like you might not get it in. Validators can kind of keep them back, you know, and if a few bad validators happen to have the last few blocks, then maybe a good price won't get chucked for a bad one. It's fraught with problems. So what we wanted to do was find a solution for this. It turns out there was already a solution, hurrah, history has provided us one. So there are these auctions called candle auctions. They're named so because basically the auctioneer had a candle next to them, and the candle was lit at the beginning of the auction. People could put bids in, it was an open auction, so anyone can bid anything at any time as long as it's higher than the previous highest bid. But when the candle goes out, then regardless of whether anyone's got any more bids to add, that last bid is the bid that wins. Yeah, so it's a really good way of making sure that auctions don't go on forever and that there isn't a group of people, like a cabal of people, that are just waiting and waiting and waiting until everyone else has done their thing. Now the problem with candle auctions is that you can't put a candle on a blockchain, you can't even put an abstract representation of a candle on a blockchain, because you can't end something randomly very easily, basically. To end something randomly, someone has to know when it's going to end, because someone has to model the candle, someone has to be the generator for the candle, is the flame gone out yet? And if that someone's the generator, it means they've got an advantage. So what instead we do is we do this clever thing where we have a retroactive ending. So the auction ends at the end of some hour, right? Time is broken up into hours, and at the end of some hour we say the auction's ended, but it doesn't literally end at that hour. Instead it ends at some point in the previous hour. So we know it's ended sometime in the last hour, but we don't know when yet. And then we choose a point randomly in that last hour, and that point is when the auction ended, which means there have been possibly other higher bids that have come in since that point, because we're at the end of the hour, right? But we discard them. And what this means is that even things like smart contracts that you can very easily predict the behavior of can still have a good chance of getting a slot. Because even though I might instantly see the smart contract bid and then bid one higher in the next block, it might be that the smart contract maybe bids up in the block after that, and I bid, so I might be in a bidding war with the smart contract, but that still means that every other block the smart contract will be the winning one at that point, and then it's like a 50-50 chance whether it's the smart contract or me, because it's a block chosen at random in the last hour. So it might be one where the smart contract was winning, but it might be one where I'm winning. Now normally you wouldn't be able to do that because I would just always be checking the smart contract, bidding one up, and by the time it ended I would be bidding one beyond the smart contract. But because we end at a random time, we can avoid that problem.

Yeah, it's basically we leave it as a problem for the parachain. We don't want to force parachains into a particular model for how they measure or charge for their transactions. What we instead do is say, well, look, enough validators must agree that your block, your parachain block, is verifiable, validatable, executable, basically can be run in a particular period, two seconds I think at the moment, so it's like a third of the six-second block time. And as long as that's the case, then we don't care how you manage your transactions, how you manage your users, how you manage any of your blockchain logic to make sure it fits in the two seconds. If for some reason it doesn't, then the block isn't going to get in, and maybe your next block it'll get in, maybe some other collator, some other block producer, will come up with a block that takes less than two seconds. But the point is that we want to be more abstract, more general. So a more general way than counting gas, which is a very specific way of working out how to make sure that blocks don't take too long, that you don't get DoSed, a more general way is just to say, well, we don't care, as long as it happens in two seconds, we don't care how you manage it. So alternative ways of managing it would just be to have voting, for example, or to not have transactions, or to have transactions but have a very simple way of measuring, not gas, just saying, well, there's only one kind of transaction, transfer transactions, so like a plasma kind of chain where it's just super transfer-oriented, and we know that every transfer only takes however many, 0.1 of a millisecond or something, and we just make sure that you can't have more than 20,000 of them in a block, and you know, then you don't need gas counting, you don't need dynamic resource measurement. Now, of course, for smart contracts, if you want to have smart contracts be very general and very deterministic, then you probably still want this. But the point is that you don't need it in every circumstance, and there are lots of use cases where, more simple than the smart contract use case, where you really don't need that level of complexity and the performance hit that you take from it. So by allowing parachains to decide their own way of keeping this two-second enforcement, we allow them all sorts of more flexibility and potentially performance benefit.

Well, you know, we haven't done much legal research on, I mean, I think they're now PLOs or something, parachain lease offerings, but anyway. Oh, okay. It's like trying to not sound like IPO, but anyway. Okay, well, why don't you describe what they are? But yeah, so the thing about parachain leases is, we call it like crowd loaning. So it's like crowdfunding, but instead of just handing over your hard-earned cash and getting, I don't know, something back, maybe a product or a token or whatever, it's only a loan. So you lock up your DOTs or your KSMs on Kusama for some period of time, and you can choose, well, you know ahead of time how long it is, so you don't choose yourself, rather the team chooses. They might say, well, we only need it for six months, after six months we'll have launched our token, we'll have users, we'll be very clearly a good use case, and we will then work out other funding mechanisms, probably selling our own tokens into whatever market it is for DOTs, and then using those DOTs, that would be a pretty obvious way of doing it, I'd say. But that initial six months, you probably, you may well need to go to others, go to DOT holders and say, look, you know, loan us the DOTs for a lease, would you please? And that's what this is for. So it's crowd loan, you're asking DOT holders to put their DOTs in for a fixed period of time. Now this loan, this crowd loan, is kind of a bit like staking, it's handled entirely by the Polkadot relay chain, and then probably over time that will migrate into a parachain, because we don't really want all of this complex stuff on the relay chain. But you don't have to trust the team with it, that's the main thing, right? You're loaning the DOTs into Polkadot, the relay chain, and they just get kind of reserved, they don't even really...

When you leave your account, they're still kind of on your account. They're certainly still on the chain, and you can always check the logic of the chain to see they're very much associated with the account. You have three and a half months to go, then they'll be back spendable by you from your account. And it's a bit like using the staking system. The only difference is they're not producing any returns like they do with the staking system. But presumably the team that has asked you to loan these dots for their initial parachain or parachain lease are planning to reward your contribution, your loan, with something on their chain. Perhaps one might imagine some of their own tokens. But I don't want to straightjacket these guys. Maybe they've got some other thing going on. Maybe it's an NFT chain and they're giving you free tickets to a gig. Who knows? Could be all sorts of things. So yeah, main takeaway is there is no transfer of value in this. The team isn't getting anything from the crowd. The crowd are just kind of locking up their tokens with a guarantee guaranteed by the protocol that these tokens are coming back in a particular time period. Now again, we haven't consulted anyone of any note, legal or otherwise, on this and how it might be different. But in my layman opinion, I would think that having just literally locking up some tokens for some period that you definitely get back later with zero risk or zero additional risk isn't really anything. It's like staking, and that's not really a thing. The rewarding is a thing perhaps and might have some knock-on effect, but locking something up is not a thing as opposed to value transfer into some other entity, which very much is a thing. So I think by moving away from the value transfer into a guaranteed lockup situation with a guaranteed return unlock date, I think that may well move it into being viewed by various organizations as a non-event basically.

Sure. Well, okay, so let's move this from the meta protocol. So I mentioned earlier you got this meta protocol, right? WebAssembly, this low-level language, basically it's a machine language on which we can describe and define the Polkadot protocol and the Kusama protocol and the Edgeware protocol and the Moonbeam protocol and the Centrifuge protocol, all these protocols. And they're all built on this meta protocol, this WebAssembly-based meta protocol. Now you've got a problem. The problem is how do you know when to change your protocol? What governs that? What decides that? So you can say, well, there's a team and they've got a CEO and the CEO has a key and they can just change the protocol with a key. But it's not really in the spirit of decentralized blockchain kind of scene, is it? It's not a very good answer. And of course it has its big problems, which is what if the CEO loses the key? What if the CEO goes mad? Whatever gets stuck. So we need a better way. And normally we decentralize this decision-making criteria. So we have multi-signatures, we have voting, we try and pluralize the mechanism. Now that's all well and good, but then how do you make sure that this mechanism is respected? If it's more than just literally a single key that is trivial to respect, you can build it into the software for example. Then how do we ensure that everyone is on the same page? We have this consensus problem. So this is another reason why we have a meta protocol. The meta protocol allows for us to alter the protocol according to the rules of the protocol. And that's where we have the governance, but also the enactment of the decision coming from the governance. And we have this situation in the US at the moment with a lack of consensus on the one side, which is most of the news outlets, I don't know, 74%, 80%, whatever of the population, and a lot of people on Twitter all saying, well, obviously Joe Biden won the election. And then on the other side, you've got the president himself and a lot of voices behind him saying, well, actually no, he didn't, Trump won the election. We have a lack of consensus over the governance process itself. And this is problematic. The reason it's problematic is because it's not clear, people are asking, well, what exactly governs the transition process? How do we know who should be the next president if there isn't consensus? Who makes sure that the government is indeed the government that was elected if we can't decide who was elected? And there isn't like, well, whoever's in the White House governs. Well, that doesn't seem like, what if the current occupier doesn't want to leave the White House, then what happens? We have this constitutional crisis. And this is why it's important to have absolute enactment. This is why it's important to tie the enactment of the decision to the decision-making process itself and make the decision-making process a sort of the enforcer as it were, or at least part of the enforcement. Now, there isn't like an independent Election Commission that has the power to both manage the election and put in the new president. That doesn't exist. It's sort of, well, the old president just should get out of the way. It wasn't really answered by the people who drew up the Constitution. It's like, of course the old president should just get out of the way.