 We're building testnets for a number of reasons, deploying testnets to users. It's first important to distinguish that there's really two different kinds of testnets that we're doing. There are testnets which are about some kind of cool new feature, like a tech preview of something that we want to demonstrate a new feature, and the other kind of testnet is the kind of ongoing testnet that just runs forever and is just what's going to be in the next version. So it's important to distinguish those two kinds because they have different purposes. So if we look at the kind of ongoing testnet first, so this is the testnet that should be available at any time for anyone who wants to do system integration, testing, whatever. Exchangers want to use this, anyone else who wants to do integration wants a testnet to work with to help them test and do integration. But it's also for the purpose of letting partners, integration partners, end users see what is going to be in the next version because we have this process of rolling development and rolling releases and when things are done, there's a cycle, a release cycle, when things are ready, well, it's actually on a time-based schedule, there's a cutoff date, things get put into the testnet, well, they go through internal QA, put into the public testnet, and then some time for end users to try that out, see if there's any problems, and then we deploy that to the mainnet. So the purpose there is exactly that, for end users to see what's going on, to see, to try out new things, to see if anything has broken accidentally that we haven't managed to catch through our own QA processes. So that's that kind of testnet. And then we've got these sort of tech preview testnets, and those are all about showing that we have our technology working and trying to get feedback from people. So for example, we've got the Sheli project with decentralization and wallet features, and then we've got Gogan with all of its smart contract features, and we want to get early feedback from developers and other users on how that's working and whether that meets their needs. So if we look at, for example, the testnet that we're going to be deploying first, this is actually from the Gogan project, but it's in some ways relatively early in the Gogan process. There's two testnets we're going to be deploying. One is for the K EVM, and the other is for Yele. And so these are both Ethereum EVM related features. So ultimately Cardano is going to support both EVM compatibility, sort of legacy compatibility with existing EVM programs, and also a kind of improved EVM-like system, which is called Yele. So the first testnet that we're doing here is for both of these two things. We're deploying it as part of our Ethereum Classic client, because it was, from development purposes, easier to integrate an EVM-like thing into an Ethereum Classic client. So that's the Mantis client. And so we'll be deploying those, and the purpose is to get feedback from users and from developers on how well these systems work, do they meet their needs, are there any things that we didn't think of that turn out to be really important. So that down the line, once they're integrated into Cardano proper, everything works smoothly. So the first testnet is going to be on the 28th of May, and that will be the K EVM and Yele testnets, so two testnets. And these are the ones that are of the sort of tech preview feature style, rather than the ongoing rolling release style. And these are about demonstrating our Yele and K EVM platforms and the ability to compile and run stability contracts. So that's the purpose of those ones. And then there will be additional testnets coming out later. There'll be a whole series of testnets over the next six months. Probably the one that we'll get out following will be the testnet that corresponds to the Cardano mainnet. It'll be the testnet that will be available publicly in the weeks before a mainnet update as part of our rolling release cycle. And so that will have like an ADE faucet available and partners and users will be able to try that out. Then over throughout the Q2, Q3 we will have, well, there will be a testnet for decentralization, the staking, which is probably going to be the back end of Q3. And that's the one that will have, the full decentralization of Shelley, the ability to run stake pools, the ability to delegate your stake using the deadless user interface. And there'll be further testnets, again, of the feature variety throughout the rest of the year on the Gogan project. That's all the smart contract stuff. There'll be ones that demonstrate various features including sidechains, multiple native currencies. We haven't planned out exactly which features will appear together in one testnet or which ones will be available separately. But throughout the course of the year, we're going to be having testnets for demonstrating these new features and they'll be rolled out as and when they're ready. Different testnets are aimed at different people for different purposes. So if we look first at our testnets, which are aimed at our smart contract platform and then look at decentralization in a second. So the smart contract platform testnets are aimed at developers, people who want to write smart contracts. People who, for example, might have been using Ethereum already and writing Solidity programs and JavaScript that interacts with their Solidity programs. The KEVM and the LA testnets are aimed squarely at developers who are familiar with Solidity and have been using, perhaps, Ethereum or have been writing applications, perhaps, that make use of Ethereum. Then later in the year, we will also have smart contract testnets that will demonstrate our other languages, Plutus and Milo. Again, they're aimed at developers, but they're a different style of language. They are functional declarative smart contract languages, which I think a lot of developers will find very interesting. We certainly think there's a lot of promise in those. So yeah, the testnets for those smart contract platforms are really aimed at software developers. Now then on the delegation side, the decentralization side of things, that is aimed at slightly different people. It's aimed at people who are interested in running state pools. It's aimed at people who are interested in seeing how delegation is going to work. How will I be able to make choices between different state pools and see what information is available and choose how I do delegation. So that one will be aimed at keen and interested users and it will be aimed at people who are interested in operating state pools. So the state pool registration process closed at the end of May. Now we are expecting that the actual testnet will be not for several months yet, probably back end of Q3. So there's a fair period of time in between and we will try to keep giving updates to everyone as the process goes along. But it's important to note in particular that, well, we have everybody's registration, nearly 2000 people at this point have registered interest. And it's important to note that actually in the end everyone will have an opportunity to be involved, but there will be different levels of participation. Because what we're trying to do here is test out, in part we're testing out the social dynamics of state pools. We have a game theory that says how things should work in a perfect world, but we also need to test that with reality. So some people are trying out operating state pools, but we also need people to take part to be end users and choose between state pools. So we will provide particular assistance to a selected subgroup that we will pick of people that we hope might be able to run a state pool in the testnet. And in particular that will involve providing them with additional documentation, a bit more communication engagement to say that that's what's going on. And during the testnet, what we are currently expecting to happen is that we will provide those people who are going to act in the role as operating state pools to give them a bit more test ADA upfront because part of the game theory requires that state pools have a slightly larger amount of stake to start off with. But everybody else will still be able to take part and they'll be able to go to the ADA faucet and get some test ADA on the testnet and do delegation. They can choose between the various people who are running state pools on the testnet. So it will be a little bit of a long process and we will provide updates as we go along in much more detail how it's going to work. At this stage we've pretty much finalized the game theory. It's been a rather long process, it took longer than we expected, but we've now got lots of pretty graphs and simulations that show that everything stabilizes and things are looking quite good. So our game theory people are now happy that we have a coherent set of rules that we really think are going to work. So what we're providing for access to the testnet and information about the testnet is for starters we've launched a testnet website and that lists all the different kinds of testnets that we are currently doing. I mean at the beginning at the moment that's just the one, well actually it's two, the KEVM and the LA, but over time that will be a portal for all of the different testnets that we are running at any one time. So you're about to see what they all are, you're about to see for each one, you're about to see information about it, what is it, what's it for, who's it for, and dig into more detailed documentation. So you'll be able to learn about what that testnet is about. Then there'll be also resources for using it, for installers, downloads, and if necessary other tools, things like block explorers, AIDA faucets, these kinds of things. And then in addition we will have forums for people to ask questions and answer each other's questions. We're hoping to get a stack exchange established and that will allow expert users to answer other users' questions. So there's really kind of two ways to get in touch and get information, get answers. It depends on the kind of question. So if you've got a bug that you think you've found in one of our testnets, one of the beta tech previews, whatever, if you're using deadless you can still report bugs through the deadless user interface and that will submit the logs to IOHK and they'll be analyzed by developers. Now if it's more about how do I do this with Solidity or how do I use this API, then the appropriate thing is probably going to be community forums. As I say hopefully we'll have a stack exchange but if not some other forum for people to ask and answer questions. So different testnets will last for different periods of time. Remember that there's these two different kinds of testnets. There's the kind of one that goes on the rolling release style, the one that corresponds very closely to what the current mainnet is. And that one never finishes really. I mean it gets updated every seven weeks, six weeks, whatever. And so if you want the period of that testnet it might only be a week or two weeks between when it's rolled out publicly and when it goes into the mainnet. But that testnet is always there. It's just the rolling and it's just updated as we go along. Then there's these feature or beta tech preview style testnets. And those have a limited lifetime. But even then they can be updated multiple times as new. Either fixes are incorporated or new features are added. So in particular for the smart contract testnets we're expecting there to be several testnets in parallel and for someone to run for quite a long time. But probably with updates every couple of months or so as new features are added as we go along. So some could be comparatively short and others could be quite long and some will have multiple updates. And there will be multiple testnets running in parallel. In particular there's always the one that corresponds to what's about to go into mainnet and then there'll be at least two parallel testnets for Cardano, for smart contract features for different smart contract platforms and then a Shelley delegation as well. So there'll be several concurrently with different lifetimes.