...and we're going to go ahead and play. Let's look at the stuff that was written down. All right, let me share my screen. All right, in the beginning, it starts with our good friend, the Cardano Ledger formal specifications. So, this is a public repo, and these are the blueprints of Cardano. So, if you're ever curious about anything in Cardano land, from the beginning with Byron, Shelley, Allegra, Mary, Alonzo, Babbage and soon to be Conway...

...you can see the formal specifications that we have here. The rings of power, the Genesis keys, were introduced with Shelley. Let's go to the specification, boom, right here, on page 29 of the 129-page document. (https://github.com/input-output-hk/cardano-ledger/releases/latest/download/shelley-ledger.pdf) Go up here. It says, "A formal specification of Cardano Ledger". And if you go ahead and control-find, and you say "Genesis Keys", you can see the first references to them.

Five of seven of them would be able to upgrade the system after some form of a social process worked its way through. We mentioned the Federated governance model of Shelley; it's in the core document. I want to show you guys something that's a little bit behind the scenes. So what happens is that a social process forms, and there are two forms of social processes that have materialized.

If you scroll down, there are seven governance actions within CIP1694. Three of these are regulating functions for the Constitutional Committee, and the other four, specifically four to six, are replications of the process that occurred here. This is defined in the update proposal of Shelley, along with some extensions for the new things you can do in Conway.

The group is basically m event so you can go from three to five to seven to nine; you can have different terms. The other thing is that the constitution itself enables constraints on the committee via smart contracts. When this was designed, we had no Shelley, no stake pool operators, no Plutus; we had none of these things. So, we had to have some form of bootstrap mechanism to be able to...

...certain entities have total control over the network, and this is materially untrue. There has always been, since the beginning with Shelley, a balance of 3-2-2. It's hardcoded into the Genesis block and that is a kind of a custodial trustee-style role. What we've been doing is just basically submitting updates after a social consensus forms. Now let's say the...

...defined through a social process, when we wrote the Shelley specification, we didn't formally put in the notion of 70% of the Stake Pool operators upgrading to initiate or trigger a hard fork. Now, it's kind of there as a social process and it's something we honor and follow. If there's a deviation from that, the consequence is an uncontrolled hard fork because the people won't tolerate it.

They basically take their network and change some things. Uh, the point of CIP1694 is to memorialize and formalize, uh, tradition, and precedent into something that is algorithmically adjudicated. But the thing is, you have to move as your capabilities move. When Shelley came out, we did not have extended UTXL and Plutus. If we had, we'd put a lot of the off-chain stuff that's done...

..and other things, and you use social consensus to enable and preserve those things. But just like a hermit crab, you outgrow your Shelley. We have outgrown the governance structure of Shelly, and you're all going to have to make a decision soon in the coming months. Where do you want to go and what shell do you want to occupy? We've built a new shell that we think is fit for purpose.

We see that a single Hydra head achieves up to roughly 1,000 TPS, so by running 1,000 heads in parallel (for example, one for each stake pool of the Shelley release), we should achieve a million TPS. So, this is basically, well, this is hypothetical.

So, the kinds of things getting Cardano done, the kinds of things that are related to that roadmap of Shelley, Basho, Voltaire, and Goguen, and then continuity is just kind of the daily affairs, better, faster, cheaper, less memory consumption, improvements, API enhancements, all these types of things that form a backlog.

...places in the world exist other than the United States, and in those places, sometimes it's daytime when it's nighttime here. So, I bite the bullet and I try to get a little bit of a nap in so that I can talk to you guys as well because I love you guys as much as everyone else. A few things, one: I wanted to give an update on where we're at with Ledger and where we are with Shelley, and then open it up for questions.

...because it provides a faster user experience. It boots really quickly and it's really easy to install and manage Yoroi. So, until we get clients for Daedalus, that's probably the way to go. That's the story there. Now, in terms of Shelley, the milestone for Shelley really consists of three buckets of work that we do and each of those buckets have to be done for Shelley to begin.

So, Byron was launched in September of 2017, late in September, and we are now reaching the end of life of Byron. The last major update to Byron was 1.4, and the first update to begin the Shelley era for our current code base in ??? is 1.5. So, 1.5 is the OBFT update. It's been a QA hell for a bit because the CEREC code has been so...

So 1.5 is the first major step in Shelley, and then there will be a series of updates that come quickly. I mean, each one of them will be rolling in new features and functionality. Second, we've been working really hard at finalizing the candidate specifications for Shelley. So, while code is nice at the end of the day, if this is truly decentralized.

...the candidate specifications for the card are not done for Shelley yet, but they should be done before the end of Q1. That might slip a little bit, but we're almost there. Technically, you don't need specifications done to ship a product like Shelley, but what that effectively means is that there are parts of your protocol or your cryptocurrency. This is quite common for most cryptocurrencies, from Bitcoin to...

That's where we're at in terms of the second bucket specification, and we're moving pretty quickly. The third thing is basically the "When can I stake?" So when we say "Shelley," we mean staking. That's the most common notion, and it's an accurate notion. So, staking always begins first on a test net because a lot can go wrong. You want to make sure that people actually know what they're doing.

You're not exactly sure when that test net is going to land, but, to me, it's a very high priority to get that net out in Q1. At that point, we are in the Shelley era as we'll have specs. That's one bucket. We'll have the first of a series of hard forks enabled, and at some point, we flip the switch and staking has begun. In addition to that, you need people to stake, so we launched the stake pool taskforce.

The Cardano Foundation will create some educational material, and some third-party community people will as well. Now, after we have done this whole stateful thing, we have this huge pool of people who are really excited. Interestingly, some subset of them will be fairly technically capable, and that is the perfect set of people to take and place right into the Shelley test net.

That's where we're at. A huge hackathon is under way, and things are moving really quickly on the Rust side. We're priming the pool and are about to have a large group of people flood into the Shelley test net. These people will be sophisticated, so once they leave this process, there will be a lot of surrogacy and they can actually start building communities and answering questions, many, many people are very excited about that.

Then, hopefully, we could have a very short time period to move over into Shelley. On the Haskell side, things are still moving in a pretty good direction. We have a lot of very refined and elegant ideas that the Haskell team have been working on. What we're trying to do is figure out...

Time, so that's where we're at. Shelley is staking. Staking is coming soon. Either it's going to be on the Rust side of the Haskell client side, more likely not the first test that will be rust will hit right now. We're priming a large group of people to participate. Anyone can, but we'd like to at least have some fairly good participants. The specs are entering the candidate phase, there are some...

But remember that it's for stake pools, not for Shelley consumer clients. We're, of course, going to have Windows, Mac, Linux, and mobile client interoperability there. I see this one a lot too. "Will IOHK extend a contract on a contract beyond 2020?" I think we don't extend contract clients. This has more to do with more work, but there's a scope of work with Cardano, and that scope of work will...

The accountability of a deadline kind of forces you to work under pressure and do your best work and get things out quicker. So, it accelerates the launch of Shelley, our competitiveness, and shows off all the things we've done. It'll help us dispel this myth that we're just a white paper and we're just a bunch of academics who have no idea how to ship anything.

They also, they can act as bridges for Interledger, which is a protocol from Ripple. We'll look at these things and, you know, we'll probably roll them out as soon as Shelley and Goguen are around because we'll have enough capability in the ledger. It'll be fairly straightforward to do that. Now, closely related to interoperability is a discussion about metadata. This is really, really, really important.

...to the new Haskell code that we've been writing, so throughout the next few weeks to months, we're going to be connecting the Rust code and connecting the new Haskell code to that wallet back-end. Whichever one is done first will end up becoming the first release of Shelley. It looks like the Rust code is a little ahead of the Haskell code in terms of our ability to run a test net, so that's...

...probably going to use the repo and the code base for the three upcoming Shelley tests in order to build up a population of stake pools. There's a series of things that must be done to get there. The OBFT update, which is Cardano 1.5, and then the Cardano decoupled, which is 1.6. After that, we can connect the rest of the ASCO code whenever we're ready.

For anything, either on the Haskell side or the Rust side, we can just simply wire the code together, flip a switch, and suddenly, Shelley's turned on. Yeah, to mention the rollout, what's going to happen is that OBFT will run for all slots in the first epoch. Then in the next epoch, some percentage of slots will be turned over to the state pool. So this is if they make all their slots or if they...

Jared, the head of that effort, is currently cleaning up the specification. He's also going to be merging the Byron Ledger spec with the Shelley spec. If you look at how our system works, we're changing the way that validation works on the ledger. In many cases, we're simplifying things and in many cases we're making it a little easier to understand and implement. So, Shelley is...

...in a way, it's a massive improvement over what we released with Sarah Kells' code and fire. But, in order to validate older transactions and run the old chain, we still have to have the old legacy rules. Therefore, these things have to be combined. Now that the delegation spec is in its final stages of refinement, the Shelley and the Byron spec will be synchronized, and then G will be introduced.

We'll see how it goes. Based on the data we generate, the project will mature enough at some point that we can connect it to the existing Cardano code. Once we turn on the fork Shelley, we will be in good shape. Thanks guys for all your support. Sorry, it's taking a while; it's a lot of work. You know, complying with the specifications during development requires a considerable effort, and we had to learn a few things.

We've learned a lot along the way, but you know we're getting there. It's nice to see how quickly things are coming together and how we're able to have great conversations about the work that's been done. I'm really excited to see Shelley come out. I'm also really excited to see Plutus and Marlow come out. There are a lot of cool things there, and I think you guys are going to be really happy with the product, I thank you so much for your time, and I will talk to everybody soon.

I went from London to Zurich and took a three-hour train ride to come on down and I enjoyed this nice conference. This is one of the few places in Switzerland where you're likely to hear more Italian than you are French or German. I just got back from a major summit in Berlin not too long ago and I wanted to make a video recap of some Shelley-related stuff and some news about that workshop...

...so no more, no less, the necessary one who showed up. The purpose of the summit was to discuss the formal specifications that we've been writing for Shelley. In particular, we discussed two formal specifications: one is the delegation specification, and the other is the formal ledger specification. So generally, when you have a cryptocurrency, the rules of how that ledger works are incumbent, and...

...the ledger needs to work for Shelley, covering all the features that Shelley's going to have, like multi-asset accounting. So, when you issue assets, how can you track multiple assets at the same time? There are also extensions to UTXO models so that we can actually implement Plutus and Marlowe into the system, amongst a litany of other little features like, for example, the notion of preservation of value where...

...they're going to need to understand where the legend rules are going for Shelley to ensure that your Yoroi has, you know, interoperability. Okay, so the other specification that we're covering, the one that's probably more meaningful to the vast majority of you, is the delegation specification. Basically, that describes how staking is going to work under the hood when we first design Cardano...

And they don't find too many issues, so a natural question asked is, "Well, where are we going to go from here, and how do we get to Shelley? What's the bridge to Shelley?" So, we're retiring Byron. In fact, 1.5 will be the end-of-life update to Byron, and it's part of the Shelley update. So it's the very first Shelley update, and it's the very last Byron update. So excluding the hotfix, which is shipping soon 1.4...

... and we've replaced that with Ouroboros BFT. Now, this is the first step on the road to Shelley. How Shelley is going to work is that there's going to be a series of iterative updates that will first put core infrastructure in place and then basically put a process into place that will gradually decentralize the network, epoch by epoch. So, the first...

...it is going to be a fairly straightforward process to put all the Shelley-related logic on. Where it is heaviest is on the address side. Instead of just having a single address for the spending account, now you have this idea of having to track both a spending key and a staking key. You can actually segregate these things. For example, in the case of cold staking, you'll be able to take a...

So one of the reasons Shelley took so long to get us to that point, is that we realized we needed to abstract our design process in a way where things were very modular, and it was easy to hook things on. The price we pay for that is that we have a bit of complexity creep. The price you pay for that is that by reducing the system's simplicity, you have more...

...Shelley-related features like a mass update to Daedalus, which includes the delegation center, include the registration process and all these other things so that you can actually begin staking now. How do we build up stake pools? Well, there's a parallel effort on the Rust side to get basically a fair representation of the Shelley specification done as quickly as possible.

The new back end works, and then the other effort will be to get that hook set up for expert users who want to run stake pools, to actually start doing that, getting used to that, understanding that, and then upgrading and iterating that to a point where it now perfectly replicates the user experience that we anticipate with Shelley. Then there'll be a merger between the two.

...network is just a temporary measure to ensure high security and all the rewards go to the actual slot producers, so that's kind of the road we're starting with Ouroboros BFT. That's the protocol that will be used all throughout the life of Shelley to get us to Shelley, decoupling a bunch of wallet-specific features - excuse me - and then from decoupling, we're moving on to verifying that the new Rust back-end...

...of the GUI UX and UI that you have, so you guys will get a pretty good idea of what the delegation center is going to look like. So, we're pretty excited about the designs. We think they're very forward-thinking, well-structured, and also extensible. So we can add new, cool things to that. Anyway, that's the whole Shelley story. It's a gradual...

We're just there for the workshop, for example, and now and then, you guys can be our red team. In addition to the one we had in the workshop, verify that those things are okay. Now, there's also another side of things, which is the feature richness. Where are we going to go? Because Shelley's exciting but by no means is Shelley the end of the road. Shelley's just another major milestone getting us to where we need to go.

The Extended UTXO model has an advantage; the approach we've taken turns out to be a rather mild extension compared to delegation. Thus, it can be added quickly into Ledger post-Shelley, and it doesn't reach the same scale or complexity. Most of the scale and complexity are within the language design. Truly, it's a four-layer model consisting of Marlowe, Plutus, Haskell.

...with his team, extending our specs so that we have that. Then, we can easily roll those into the Cardano Chain in anticipation of the launch of Goguen on the wallet back-end team. After we have the Icarus-style addresses, the next thing in our pipeline is hardware wallet support and multisig. This will happen alongside all the API enhancements that need to be done for Cardano, for Shelley.

Marketplace, but while preserving a safe core to the system to ensure that the things that we use the base layer for are fairly well thought out and well designed. Shelley is a spectrum and we're right now at the beginning of it, starting to roll it out. The fact that we've gotten here is a humongous milestone and it's just really cool to see all this stuff come together. I'm really...

If Crypto Kitties was ported to Cardano; would it be sizably better? This is a really interesting question. So, we get a lot of questions about the scalability of the system and exactly how much TPS you need. This is very controversial, and it's often a misunderstood topic. So, my hope for where we can take Shelley is somewhere in the performance range between 50 to 250 TPS. So, when we worked with Integer 32 and

...trade-offs and some tuning are necessary to start with Shelley in the 50 to 250 is our range there. Hydra, Our targets are five to ten thousand. We'd like to be in that range. Now, where does that get us if we just achieve that alone? Well, it provides more visa scale. Realistically, that's a network that can process a humongous load and most people would be pretty happy with it. However, we're not quite done because there's a lot of...

Their lab performance was one hundred and sixty-three thousand TPS on a production system using SGX. Great work, it's easy for us to bring that in when the time comes and layer it with other solutions like adding Oracle's, and so forth. So, the agenda for getting great performance is really three-pronged: one is to get Shelley out and then evolve Shelley to Hydra, which is really an

...code will probably be feature-complete by the end of the month, which is good for QA. We'll roll that out once we have those addresses. Then it's a pretty short order for support. We are building the infrastructure of Daedalus and handling a few little things here and there to get that done. So, rather than rush everyone and tread overburden back-end team, because they have a lot of Shelley stuff.

...to get that support sometime in February, we're going to be a little bit behind them. I wouldn't imagine February support - maybe more March support, but just as with Shelley, Shelley takes priority. I don't want to delay anything there, and if you already have one wallet that you can use a ledger device with, then you know that's just an interface. All the security comes from the ledger...

But do file a help desk report and once everybody's on that foundation and we're on to 1.5, we're on the road to Shelley and a lot of things are going to happen pretty quickly all.

I just wanted to go and make a video before Christmas about a few things related to Shelley and new features we anticipate seeing during Q1 2019. Things that are priorities, things that are going to be changing for the new year and anyway I figured why not...

OK, moving into Q1 2019, let's talk about new features coming to Cardano and let's talk about the Shelley. So basically, what is the Shelley release? Well, there are three dimensions to the Shelley release. There is a testing dimension. There is a deployment dimension and then there's a social dimension...

Then there's the actual rollover of what we have today - the Byron system - to where we'd like to go, Shelley. Now, this means that we're going to have to issue series of updates to the Cardano Client. At least two updates will be required. One is that the current implementation of Ouroboros, this Ouroboros classic is a very old implementation. It's based on the ideas we had back in 2017, but...

So once BFT is out, that will be 1.5. The very next thing to do is to then begin a series of upgrades to get us to basically to Shelley. So, there's going to be some changes to the Ledger rules. There's going to be some changes to the API's and there's going to be some changes to the network stack. All of these things are required for us for, basically Shelley logic, and you'll see that post 1.5 going through.

So we actually had to write 2 formal specs, one for the old system and one for the upcoming new system. The old system basically is required because we still need to validate legacy transactions as we move to Shelley. So that's all been done.

Furthermore, we now have a lingua franca for our about, basically design. We say here's the set theory, here's the math. You can read a spec. It has some verbosity to it. There's some words associated with the math, and this is what Shelley is...

It won't require restoration. It won't require new data layer. It won't require you to do much. It should be like a normal upgrade, so it won't be as painful as 1.4 is, but that'll get done. And then after that we will have a decoupled wallet backend. We'll have Icarus style addresses. And then we're just going to gradually move our way to the V2 API and gradually move our way to all of the things that are required for Shelley. And then there will likely be one more major update, and then we'll put in all the infrastructure and then Shelley will just slide in.

Now some threshold conditions for Shelley are it's not just good enough to have all the code written, and it's not just good enough to have all of the protocols ready to go and fully tested. It is a social component as well. We do need a certain critical threshold of people who are actually deploying stake pools, running stake pools and understand what that means so...

So, in summary, Shelley has three components of social component. Testing component and an upgrade component upgrade taking the existing system and gradually morphing it into the Shelley system. Testing, meaning that we have to verify. That our version of reality i correct and we think...

How all these delegation mechanics are going to work and basically just set a date once all these things are done, we've hit certain thresholds and then once we flip the switch, there'll be gradual reduction of BFT nodes that control the system and Epoch by Epoch down to a basically a complete decentralization, so it won't be instantaneous. It will be gradual, Epoch by Epoch, and then we'll just wake up maybe 10 Epoch later and suddenly the entire system is totally decentralized, so that's a little bit about Shelley.

It's incredibly important to understand that when Shelley comes out, Cardano is basically on same footing with every other major cryptocurrency in the space, and that it is fully decentralized to be 50 to 100 times more decentralized than Ethereum, Bitcoin and EOS....

What's really nice is we've actually managed to take the ledgers back which defines all the rules for validating what is legitimate Ledger and what is not legitimate leisure and create almost like a DSL to describe different Ledger rules and so it's very easy for us to describe the old ledger, which is the Byron Ledger and what the new Shelley Ledger is going to look like...

What's really exciting though, is that because the Ledger spec now lives as it does, and the network spec now lives as it does, and other parts of the system now lives as they do. Overall, the Cardano code base I'd say is considerably higher quality once Shelley is released then it's ever been in its history and it's going to probably be the highest quality code base, I would argue of any cryptocurrency ever made.

The other factor, it's kind of a silent 4th factor was it was never clear until the second-half of our year exactly how we would handle cold staking with a hardware wallet device. There were many different ways we could do this, but we need some sort of basically offline or cold key management system built into Daedalus. And this was always anticipated to be something that we handled once we had released Shelley and we had a very clear crystallized UI/UX planned out for the delegation center. I've been getting GUI scamps and mock ups for the delegation center, e registration process, and the litany of other things that are Shelley related on a pretty regular basis and we're converging to a final user experience for that.

We actually have a Rust team and a Haskell team, and both of them are building independent full clients for Shelley, and they're in a sudden death of whichever 1 finishes first. Our hope is that one of them can get to a testnet quickly so that we can start building up the stake pool population.

A big component of the Shelley release isn't just having the technology ready and the science ready. We're converging to that. It's also having the community ready. A big impediment throughout this entire year was the Cardano Foundation not making meaningful investments in community management.

So, we ran a pilot just to see what was interest, back earlier this year around April and the registration did get far more than 1000 people who expressed interest in running a staking pool, so our hope is to reconstitute that soon within the next 60 days. And to then try to convert that list as soon as we can. When a Shelley testnet is operational to get as many people as we can to play around with that Shelley testnet and to learn how staking works and to get ready for the decentralization of the entire system.

We've seen a lot of FUD this year, some of it was just because of common misunderstandings or applying things that other cryptocurrencies are dealing with us. And in some cases, they were just baseless lies and attempts to just make people really worried about things they ought not to be thing. For example, with this concept of, well, because Shelley is delayed, whatever this means that everything else is delayed. The reality is that the smart contract work was following a different path than the consensus work...

The delegation work and the rewriting of the entire code base. The smart contract stuff was done by a scholar team and done by a language designing team. The language designing team was led by Philip Wadler and Wilshire Vardy ?????, and they're based at University of Edinburgh, and they had their own group, their own resources and they were following a two-year track and that Plutus track and Marlowe track have now come to a research end, and we've been moving into actual implementation. So none of the Shelley delays from the Ouroboros side and the delegation side cascaded into the language side...

Furthermore, the work with Yella was done with a fork of the Mantis client and we ran two testnets and they've been operational since the summer. And we've learned a huge amount about that model. Runtime verifications learned a lot about from that model, and in short order we should be able to productize that. So, we're on target and on schedule for smart contracts and what's going to end up happening is that the Shelley release is going to come out a little later than anticipated. So originally, we wanted to come out this year, now we'd like it to come out as close to Q1 as possible. Unless there's some major event where it makes sense to slide it...

Hopefully we should have end of November or early December release for 1.4, so it's the most significant update we've ever made to the Cardano ecosystem and then after that every update is going to be Shelley related.

So the rewrites come along well, just a little caveat, if you're following the main repository, you might want to look into the IOHK GitHub repo, because there's several repos like Cardano chain and so forth which are separate from the main Cardano SL repo. And we're making all of the contributions there for the core rewrite that's coming for Shelley.

In addition to that, we're also looking into writing a Cardano improvement proposal process. Every cryptocurrency that's legitimate needs one. We're no different. So, as we get closer to Shelley, all future updates post Shelley hopefully will be constrained by CIP process so...

We'll take everything we want to do put it into a CIP and just list it in GitHub and so major releases will be basically in that format. Takes a lot of work to do, that slows things down quite a bit. So that's why we decided to skip that process for Shelley.

Because the peak driver here is getting Shelley to market as quickly as we can, but moving beyond Shelley, that's going to be a big goal. Now. The advantage we have also is we can put a voting system to CIP's and a funding system to CIP.

We've had some discussions about after Shelley. What do we do? The great part about Shelley is we're going to have all this wonderful infrastructure. Great network protocol. It will be quite easy for us to layer more functionality on top of that. We'll also have this notion of stake pools.

We also are kind of keen to understand what a quantum adversary looks like. So what does an adversary who has a quantum computer? What are all the things that that person can do? It goes beyond just breaking signatures, and that's a really deep and interesting topic, and it's an under study topic. So it's something we'll definitely. Do after we have our feet wet with just picking a signature scheme for Shelley and then moving beyond that, we'll examine Ouroboros in that perspective.

But that would be that that would be super cool to do post Cardano. You know, once we're past Shelley.

Ouroboros is just streaming along. We have many prototypes we've created. We have new variants of the protocol coming out almost monthly It seems. From privacy preserving ones, the BFT ones, we see great acceleration and progress with the Rust Cardano code base and the Cardano rewrite is progressing with great speed, so Shelley is coming and it looks really interesting.

We have to begin having real discussions about how we're going to roll out the treasury system, and we also have to have some real discussions about how we're going to introduce some democratic processes into acceptance of Cardano improvement proposals as we move post Shelley and post Gougen.

So that's something we'll be exploring post Shelley and it's actually quite easy for us to roll that in because what we can do is just basically take best available technology and it would be something that could be done in a matter of months with the engineers we have the architecture, we have.

Shelley out the door, but there is going to be a group of people who worry about specific type of thing it's kind of this same group of people who worry about all mechanism, design and market style things so the people who write our incentives research like Elias. At Oxford, and we'll write some nice paper on it and it will be a good compromise paper and I think it will be reasonable.

And we discovered within that paper that we think our system could sustain a total of over 1000 stake pools, assuming that most people would be rational just to simply delegate. But some people perhaps want to just run their own pool or run their own staking operation, so so I encourage people to read that paper. The final parameterization we set as we had a little bit closer to the launch of Shelley, but it's it's probably going to be around 5% inflation per annum. But there are a lot of factors that fit into. That the amount of transactions we have, fit in the profit. There's also the concept of the Treasury system and what the Treasury system comes out. Percentage of rewards will be allocated to the Treasury and these things are discussed in the paper and have been discussed in literature that we have, in particular works Lars Brunjes has been working on.

This is truly cutting across all economic zones and lines, so the succinct short answer is yes. I would love to be on the Joe Rogan podcast. It'd be a heck of a lot of fun to meet him, talk to him, spend some time with him, be fun to talk to Tim Ferris. It'd be fun to talk to Sam Harris, I think we do a lot of good there now in terms of the greatest bang for our buck I think would be probably more productive for me to be on that show once we have smart contracts and Shelley out the door because in addition to going on and being aspirational and telling the world about all the cool things we could do in the future, I'd be able to say download the software.

So 1 aspect of the post 1.4 work will be Ouroboros BFT as a halfway house transition for us to get to Shelley. Another dimension of that work will be decoupling the wallet backend which is currently connected to the Cardano client to pull it off as an independent standalone product.

Building manual transactions and offline transactions and extending that API for other parameters like delegation and so forth. We can do that without being on the normal release cycle for for Cardano. So those are going to be near term goals. That we're working towards me and meantime we have three parallel teams working full time on all of the Shelley related stuff, some on delegation, some on Ouroboros Genesis. Other dimensions of that stuff and some on the new Ledger rules You know some on how we're going to extend the UTXO set to include Plutus and Marlowe. It's a humongous amount of work.

Duncan Coutts is going to be preparing some content, some videos and our product marketers are going to be been kind of parsing down all of this stuff and trying to put it into an Understandable road map for people So people can get a pretty good sense of the scope and scale of Shelley. Shelley, we thought was going to be this year so larger and that's why it's taking so much more time for us to very carefully think about it. It's larger. And that the interdependencies and the the way that The software works. You have to think super carefully about it.

The next versions will be on Ouroboros BFT and decoupling of components in preparation for Shelley. And then Shelley testnet next. And then after that, it's basically Shelley. Decentralization. Then very short leader after tackle on the side chains, extended UTXO and yeah, Plutus, Marlowe and then K-EVM and IELE. So lot of stuff is coming soon and long long overdo.

Will Tom, still say Cardano is a scam. after Shelley, the answer is yes. But but Tom been telling me that to my face for a long time. I guess he's no longer asking me to go to jail, he just says I should be banned from coding and from running a company.

We still fully anticipate Shelley to ship as we've stated early next year.

So after we get all these wallet improvements out the door and we're pretty much done with Shelley and decentralization, the next major priority is to kind of really start talking about, well, what is the Treasury system going to look like?

So that's Shelley.

One work units of Shelley.

The Shelley test Nets will also come out and you get a lot of people who registered for the state pools and opportunity to come and play around and see how staking works and so forth.

And we'll work really closely with the community to try to build up a lot of knowledge and competency and then come, Shelley, there'll be.

So look for those as well and as soon as we can find a responsible way to pull that into the stack either pre, Shelley, Shelley or Post Shelley, we'll find a A kind of a route that's when we'll be able to link up a CDL and actually run smart contracts in the system.

Successful we have to have halfway House solutions and we do have them and we are building them and implementing them for Shelley Gogan and other steps in the network that will definitely provide us exactly what we need to be able to scale to large settings.

Where are we going? There's January and February and many months coming. And then there's the Shelley release. So, the immediate priority is that there is some technical debt in our architecture and our code from the Byron release. And we've been working towards reducing that debt in parallel to finishing the specifications for Shelley and starting new code work for Shelley.

This will not interfere with the shipping of Shelley we hope, and we're going to bring a new company on board specifically to accelerate things so that we can leave key core personnel in, in the Shelley work streams and continue our March towards launching Shelley.

So as a user in the coming weeks, expect to see a patch issued to the edge nodes, probably early February as our hope. In addition, we are beginning preparations for the first Shelley testnest. Our hope is to launch that Shelly test net sometime in early February to mid-February.

Once the great cleanup is done, then the next step is to gradually roll out Shelley features. So, there are many work streams for Shelley from delegation and stake pools to enhancements to the network.

The highest priority is to begin the process of getting people who want to run stake pools into some sort of slack channel or formum that we can have a direct communication with them so we can get a better understanding of what their technical competency is. What operational costs are going to be and required hardware is going to be for staking. These types of things, our hope is to get between 25 to 100 stake pools by the launch of Shelley.

And Rackspace and other servers for people who are running stake pools and eventually for people to deploy their stake pools in the Shelley testnet for the next iteration of testnet, The one that is likely coming in February, but probably the one that's coming in March.

The end result of this output. will be the first formally verified and specified consensus algorithm in the cryptocurrency space actually used in a cryptocurrency, so that's pretty exciting and we probably will end up writing a paper concurrently with releasing the protocol because it's a novel from an academic viewpoint, but that's coming along quite nicely and we're going to try to accelerate it so we can get it out in the first half of this year potentially, but it might bleed into the second-half of the year, although it's not required for Shelley.