Hello dear listeners, welcome to a milestone episode of the Awesome Algo podcast, episode number 20. Today we are diving into the latest news in the Algorand ecosystem and the Algorkit project, hopefully sparkling a bit more technical details and delving a little bit deeper into some of the features that we think were quite impactful in terms of deliverables in the year of 2023 and obviously some things to get excited about this year and going onwards.
This episode is a bit of a milestone for me personally, not just in number but in the format as well, because this is the first time we are hosting a roundtable discussion with three distinguished guests who will offer us an insider look into the latest advancements and exciting developments in this space. First up we have John Woods, the city of Algorand Foundation. John joined Algorand in 2022, bringing a wealth of experience in blockchain technology and software architecture.
His impressive resume includes working for companies like Cardano, Informatica, Consensys, and known in the Algorand space as a leader who has deep commitments to enhancing the developer experience and integrating user-friendly programming languages such as Python into the blockchain technology powering Algorand. John is a passionate advocate of fork, decentralized, self-savaring, privacy-preserving technologies.
I am eager to hear his insights, especially on the recent Lambda updates that are revolutionizing transaction finality speeds. Next up we welcome Rob Moore, chief technology officer at MakerX, an Australian venture-focused digital product firm. Rob's expertise in leading teams and innovating in the tech space, particularly in mobile, web, ethical web-free and cloud development is truly inspiring.
He's been instrumental in steering MakerX explorations into the web-tree ecosystems, focusing on ethical and pragmatic approaches that do not abandon modern standards of software development and modern software engineering practices. As a colleague and a mentor, Rob's insights are invaluable to me personally and I'm sure they will be to you too. And last but certainly not least, we have Alessandro, head of product at Algorand Foundation.
With MBA in background specializing in digital finance, Alessandro has seamlessly transitioned into software engineering, combined technical and business skills to deliver innovative solutions. He is at the forefront of product development and strategy, playing a pivotal role in overseeing the product vision and roadmap on Algorand's global blockchain platform, with primarily focus for him right now being the AlgoCAD project.
His unique perspective on marrying engineering with digital finance promises to bring a fascinating dimension to our discussion. Today we'll cover a range of topics as I already mentioned, and with that, episode number 20 of the Awesome Algo podcast starts now. And with that, I would like to start with John and the first topic as I mentioned, some introductions obviously and recap on AlgoCAD and Algorand's technological advancements and there has been a lot of exciting news and changes.
So given your role as a CTO of Algorand Foundation, what do you think are the most significant technical milestones that Algorand aims to achieve in 2024? And how do you think these advancements enhance developer experience on Algorand? And perhaps push the whole industry, because I think we are in this very interesting stage where you have a lot of companies, right? There's like 200, 300,000 engineers in the world working in it. So it's still very minuscule area.
Obviously, there are market caps of billions, but it's not in there in the big leagues just yet, but a lot of companies are finally starting to realize, okay, there's too much competition. We all have same goals, right? We need to push towards standardizing. We need to push towards building better frameworks to work with legal aspects of applying this and improving the accessibility.
So I'm hoping that this is actually a sign that industry is finally getting to a stage where everything is maturing and people realizing that 100 L1s or 100 L2s are not going to make it if they will constantly continue pretty much competing with each other. I totally agree. Hello, everyone. Great to be here. Thanks for the opportunity to speak. And so in the year and a half that I've been working on Algorand, it's in the best shape I've ever seen.
The protocol is in great shape and we've got an incredible roadmap and I'm going to talk about some of those things. The developer experience, which is core to Algorand's DNA, is in the best shape it's ever been in, thanks to the work directly of Alizandro, who has been leading product for the foundation with a job-zine level of care, and MakerX, our technical partner, who have been implementing Alizandro's vision. And then finally, the ecosystem as well. It's on fire.
I'm seeing so much excitement from people. I'm seeing so many new projects brought to the platform. Our discords are electric. The forums are alive. And so, you know, for the, I guess, it's an all-time high in terms of excitement, in terms of positivity, and in terms of work in the last year and a half. So I'm in a happy mode. I'm feeling good. And so, let me walk you through some of the things that we're doing. So on the protocol side, you could look at the various things we're doing.
We came out with our roadmap yesterday, or I think two days ago, on the 17th or 18th. And so, all the days are blending into one. And so, our roadmap basically defines the things we're going to do in 2024 on the protocol side and on the developer experience side. But if you look at the protocol, I mean, there are certain parts of it that kind of dovetail well together or marry well together. For example, consensus incentives, which is, of course, this change.
We're bringing this tectonic shift that's going to come to Algorand where individuals get rewarded in Algo for producing blocks and validating transactions on the Algorand network. Essentially, the pure proof of stake version of mining, you will now get, you know, by the middle of this year, you'll get rewarded for that act. And so, this has two major side effects.
By rewarding people for validating transactions, running nodes and staking their Algo, we increase the number of nodes that are active on the network. And so, this decentralizes the network. It ensures that there's lots of data propagation path network because the nodes are all interconnected. So, it becomes this dense network of nodes. And it also critically secures the network.
So, the more Algorand it's staked, the more expensive it is and the more difficult it is to mount any kind of attack against the decentralized network. So, that's stage one with consensus incentives. And looking at another part of the roadmap that we're bringing this year, which is what we call the Capoblanca variation with our chess themed roadmap, we're going to be bringing peer to peer as a network propagation topology.
And so, what this means is that we're shifting away from the current standard, which is where participation nodes or consensus nodes, as I'm going to call them for the rest of the interview because I think a consensus node is just a simpler term because that's what they do. These nodes are running consensus. Right now, they're not connected to each other. They don't talk to each other.
Instead, they talk outwards to this kind of ring of relays, which propagate their work, the messages, the transactions, the proposals, these relays propagate that and the consensus nodes just talk to the relays. And so, what this means is that we have this kind of bunch of entities that are responsible for the decentralization of the network and they're controlled by a small number of entities. I don't know, 10, 15 different entities will run these relays.
And so, we want to improve the decentralization there. And so, with our release of the Capoblanca variation or peer to peer networking, we're going to make a change to the network topology so that consensus nodes can now start talking to each other directly. They don't have to go via this relay middleman. And so, this decentralizes the network. It decreases the reliance on relays and on the Algorand Foundation.
And it means that even without an Algorand Foundation, even without an Algorand Technologies slash Inc., we would still, or users will still have the ability to use Algorand without any authority or any oversight. And the blocks and the transactions, et cetera, could propagate directly from user to user or peer to peer. And so, this is hugely important. And so, you can see how these two things married together, right? Just like chocolate and orange, strawberries and ice cream.
What else do I like? Coffee and milk. You know, they... How many oranges, though, John? Four, the four oranges. The reason they married well so well together is because, first, we increased the number of nodes and the number of pathways. We increased the security of the network. Everyone's running these nodes. And then, boom, we drop peer to peer. And now, all of a sudden, all those nodes that have just sprung up, they're now talking to each other.
And we have this very dense data propagation pathway. So, super cool. And so, consensus incentivization. We have this chess-themed roadmap. We've given all of the major milestones a name. And so, consensus incentivization is Reti. And then, peer to peer is the Kappa Blanket variation. These are moves or opening moves in chess. And they all have some meaning, which you can read on our roadmap at the Algorand Duff Foundation website.
Did you have to go and research chess moves, John, to learn all of them? So, like, I learned chess from a great... A grand-uncle of mine one day on Christmas. Oh, wow. Yeah. And I'm terrible at it. But it's a beautiful game. I think I lost a little bit of love for it when I realized it could be brute-forceable, you know? It's like, there is a set path at any point.
And so, to me, that deterministic nature kind of ruins the game a little bit, whereas you may not have that with other games like poker and stuff like that. But like, of course, I respect these, like, hive-mind people who are able to just look at the board and think five-ply and like... And it's an incredible skill. And of course, it's kind of... So I think it's intellectual, but also still quite sexy. So the team, and it was nothing to do with me, they just asked, hey, do you like this?
And I'm like, yeah, I like it. So they came up with this idea. And then they went and selected the different moves and, you know, the relevance of the different moves. Like, for example, we're doing our non-archival relays and we're sacrificing archival relays. So they call it the Queen's Gambit, which is kind of like where you sacrifice a pawn. And so they came up with all this great stuff. And I think they've done a wonderful... It's a pretty impressive job, I think. Yeah, totally.
And so maybe, you know... So looking at consensus incentivization and peer-to-peer, I would class them as like decentralization and security. And then if you look at some of the other things we're doing on the protocol, as an example, dynamic roundtimes, that's not focusing on decentralization or security. That's focusing on improving the efficiency of the network and how fast blocks propagate. And so indeed, how many transactions per second we can have.
So I think, though, you know, Algorand was running well. We didn't have to focus on these things. It was fast enough. It's, you know, one of the fastest blockchains out there. It was decentralized, I think, enough, you know. Certainly there's different lenses. You can look at decentralization, whether it's the distribution of the token, the data propagation path, the actual active consensus and who controls the production of blocks and the minting of blocks.
So there's different lenses you can view. But I think functionally, if you look across, we were pretty good, but we didn't want to stop and just sit there on our laurels and rest and say, well, it's good enough. We wanted to strive for better. And by bringing incentivization to consensus, which is adithetical to Sylvio's original thought, you know, that consensus will be executed, you know, altruistically. But you know, empirically, over time, we've looked and we've not seen that happen.
So we're kind of saying, hey, okay, you know, that contention didn't hold in the real world. And so we're pivoting to make it better. Bringing peer to peer. We don't have to do that. It's functioning well, but we want to make it true to the value proposition of cryptocurrency, web three, decentralization, self-suffer. Do we want these things to be true? And so that's why we're focusing on that. So that's the protocol. I think it's in pretty great shape.
And in 2025, we've got some even cooler things coming in. I think we can discuss it a little bit later on. So now to this, to the, probably the most important thing for me, it's the developer experience. When I get a new MacBook and people know I like my MacBooks, although they're, Apple are pissing me off a little bit recently with some of the bugs that I'm finding and I reported them and they're not getting that. John, John, John. Yeah. Yeah. So hang on.
Let me just see if anyone's watching from Apple. Let me just see here. Give me one second. I was fine. I'm going to put that here. It's really annoying me. I'm just signing in. Just give me one second. Okay. If you can please look at feedback request FB13463773. It's driving me insane and I'm a big customer. I will make sure to include it in the description of the episode actually. So if it's the Apple support engineer, you can click on the, for more directly. And come to me directly.
If you're a support engineer at Apple and you like Algorand, I don't know, I'll reward you with some algo or something like that. We can do a deal. Just fix the book. So I'm a person to get my new MacBook. First thing I do is like I sit down and I set it up perfectly. I care about how my terminal looks. I care about the fonts. I care about whether it's using clear type. I care about installing power level, you know, 9K. I care about installing ZSH. I care about my package managers.
And I think to a lot of people, the developer experience is so core to their day to day, they feel this exact same way about how they develop and engineer things. And so people will have preferences. They have their Visual Studio Code set up. They have themes installed. They have Vim bindings installed. They want to work in a modern environment that feels good. This is people's bread and butter. It's like the, you know, if you're working on a construction site, you care about the tools you use.
You care about you have high quality hammers, high quality drills. You know, if you're driving a taxi, you want to make sure that the car you're driving for nine hours a day is comfortable. And so these are people's tools for work. And it's essential that we make it fun and as easy as possible and take the friction away. And so, you know, when I first started in Algorand, I was interviewing with Stacey. She said to me, what are the things you'd improve?
And the most obvious glaring thing, because prepping for the interview, I was like trying to, you know, just stick a contract on mainnet, see what the experience was like. And I was so confused. Reach Albo builder, Teal, PyTeal, what's the language is a Python? No, it's not. It's kind of like bindings. I'm not sure what's going on. What, what, what development environment do you use? I just, I know everyone uses visual studio code. What's the good plugins for that? No, there's not.
Is there any static analysis? No, there's not. Is there a command line tool like Truffle? No, there's not. Is there hard? It was like a mess. And so, you know, Alexander and I sat down like week one and we're looking at this and going, what are the things we need to do to fix the developer user experience? Because it's got to feel like that new MacBook experience, you know, maybe not perfect, but fun draws you in. You want to develop for it.
It gets out of the way, you know, that the tools get you to expressing your intent, your business logic and your idea. And so, AldoKit is that it's, it's, it's been a revelation. It's been probably the work I'm most proud of that, excuse me, that we've done that that I've done or that the CTO kind of function has done. And so, Alessandro has been the genius behind it, the vision behind it, the strategy behind it. And MakerX, like I mentioned earlier on, have been an incredible partner.
I've worked with so many vendors over the years through all the jobs I've had. I've worked at many outsourced, if you want to call it outsourced tech. I don't see them like that. It's when we work together, it's like they are, they might as well be members of the foundation. They work so closely with us and they care so much about the output of their, you know, their product.
But what we've built is so much more, you know, it's, it's, it's, it's revolutionized the experience in Algorand because Algorand at its heart is a platform for execution of code. The AVM is a virtual CPU. It's got instructions. You write code, we call the code smart contracts, the smart contracts run on, on the AVM.
And so, if, if, if Algorand has no, has no developers and doesn't have great apps and we don't make it easy, all it is is a network where people can send Algo back and forth to each other. So that's why it became so much smarter. Algorand, Algorand, Algorand's ResonDItra is to provide a platform for people to express business logic on the chain. And Algor kid has provided what I consider world class industry leading tooling for this.
And so you're in Visual Studio, it's a normal experience, it's a one button, compile and deploy. It's CI CD. It's command line tools to help you build, test and deploy. It's frameworks. It's languages that you know like Python and soon to be expanded. And so, the team I've managed to achieve opens the floodgates for everyone to build on Algorand, I couldn't be happier. I think it's probably the most important thing as an entire group that
we've done. Without this, the oxygen would have been sucked out of the room. We needed this. You can need a great protocol, sure, but if you don't have great dev tools, you're in big trouble. And we finally have great dev tools. And if I made some remarks here, basically, the thing is that it's also, I would say based on observations of, because for me, it was also rather a pivot to delve into blockchain and for most part of the journey, it was a process of demystifying
this industry a little bit for myself as well. And I do notice that there's quite a huge, I would say inflow of web developers, because there's obviously a lot of references and ties to Dapps, which in this case, mostly have a rather simplified business logic, because everything is executed on chain. Well, not everything, right, depends on the platform, the protocol, but mostly blockchain allows you to simplify a lot of, I would say, execution of the business
logic in this very small, verifiable chunks of logic that you execute. So it's mostly focused on the front end, hence a lot of web development. And if you look at the development industry in general, it's a bit controversial as well, right? There's a lot of complexity in tooling itself. Most of web developers spend more than, I would say, 50% of their time dealing with complexity of their own tools, rather than solving the complexity of the problems that they need to
achieve, right? And so it's extremely important, I think, that given that there is also dominance and the presence of people coming from web to essentially ensure that if they are to hop on things like Alucid and things that allow interaction with this, you have a great analogy for this actually, a decentralized operating system, right? It's a massive network that serves as a layer where you can execute and deploy your applications. And so I think it's important to ensure that the
tools that we provide to these people are essentially not going to get in front of them, right? It should work, it should be convenient, it should be, as you said, pretty much. And I think that's something that may be a great relief for a lot of web developers, right? You don't have to worry about NPM or some person on NPM removing a left pad package and just like halting the entire industry
relying on NPM. Things like that essentially is also, I would say, considerate to the Terence, Alucid, but to also expand on the other remark you did in regards to, I've also heard this quite often with the recent announcement of the new roadmap of mentioning that, well, obviously, it's a significant, I would say, change. It's one of the biggest changes we had so far,
the algorithm protocol, right? The change to incentivization, which is, I think, I might actually argue that this goes against, obviously, this goes against the initial Sylvia's assumption in regards to the altruism, but largely to be frank, it's, it's, one could say it's also a reflection of the current financial system, right? Altruism is not always spared nicely when we talk, when we talk about money.
But at the same time, I think it also still pretty much was in the spirit of Algorand, because another, I recall one of the points that Sylvia was actually doing in his very early talks is the ability for the consensus and the core protocol itself to be adaptable to changes in the industry and changes in the environment, basically. It's not like you have this, you know, fixed Bitcoin proof of work protocol, right? That is protected and guarded like a holy
grail. It's actually a dynamic system. It's a software system, basically, that adjusts to the environment. It adjusts to the demands in the ecosystem as well. And I think this goes largely in spirit, because we clearly have a change in the environment. And this is, I think, a response to, to, to, to adapt to this new environment and ensure that this incentivization is actually even further propagated. But thank you for the answer, John. I think this is great.
I would like to give the stage to Alessandro and delving a bit deeper into AlgorKit. Could you perhaps discuss some technical decisions behind one of its like most recent, I would say, feature developments and how it addresses a critical need within Algorand developer community? Yep. Also, hi, everyone. I'm Alessandro, head of product at the foundation. I lead the AlgorKit efforts. So our idea with AlgorKit, when we first started off, we, we wrote down a few key
principles. And the most important is meet developers where they are. Blockchain development isn't as easy as web development. You're in a bit more confined space with virtual machines that are extremely powerful, but they don't have those, all those layers of abstractions where, that you're used to in normal web dev or normal programming. So a lot of the work with, that we did with AlgorKit was to, and you can see this with the Puyah compiler or with, with the
generators approach that we took, are to remove tools from being a hurdle. If we want Algorand to grow, we need to enable developers to feel comfortable with the tooling they have. And the more hurdles you know, you'll have to face, the less big of a step you're willing to take as a first step. So with things, my favorite thing is the, my favorite feature on AlgorKit is decline generators, because smart contracts are the business logic. So that is what powers the
heartbeat of your application. But an application isn't only composed of a smart contract. There are plenty of things around that for it to be successful. And the translating smart contract requirements to middleware or front end, that was extremely difficult. And so with, with the work of MakerX team with work and help of their roles in the community, we came up with a standard. And all of a sudden from a smart contract, you can have a set of functions that are available
outside of your smart contracts to interact with it. This, in my opinion, is one of the things that our developer says, all right, if this easy, I can really focus on my business logic and make it as big a moon shots as it possibly can. Because then I have the client generator that does most of the work for me. And then I simply need to connect the dots. This was one of the proudest achievement and proudest release that we had last year. The other one is the Pouya compiler,
always thinking meat developers where they are. The only thing that is sure in this, in our ecosystem is the AVM. Everything else will, can and will change. So if you look at languages in normal development, they come and go with its trending. It's like, first everything was on the server, then everything was on the client. Now we're moving back to everything on the server. It was first was monoliths, then all cloud, everything's a lambda, then back to,
shifting back to monoliths. Industries are extremely trendy and biased towards trends. So there are a few things, there are a few languages that have been there through thick and thin. And one of them, and it's the one that is most taught in schools and everything. So it's the one that we could cast the net wide enough to have a gigantic double funnel is Python. So Python, if you don't know how to write Python, but you know how to speak English,
you're already 80% there. That is the key thing. It's extremely similar to pseudo code, lead code exercises. So that is what we are trying to achieve is bringing the simplicity of Python development to something that is extremely intense and difficult, such as smart contract programming. So these are these are the things that I really enjoy about what we've done with AlgoKit. Then we have also we do a lot of our development, it's feedback driven.
Because after all, we are building this for our community. And our community has the most important voice in shaping its requirements, because at the end of the day, they're the users, and we are building it for them. So the I'd say this is, we have seen our AlgoKit approach at the end of the day. And we have seen that in the last few years. Here's a huge blob of code. It already works. It's extremely well documented. But at first glance, you could say it might be a bit
overwhelming. We heard that feedback. That's why for AlgoKit 2.0, we are working the in its own way to a generator first approach, where you only where AlgoKit only generates the pieces that you want at in that time. And then as your developer journey and that development journey evolves, AlgoKit will generate a bit more code. So first, you only do the smart contracts, you
don't need a client right off the bat. You don't need a deployer right off the bat. So we're doing it, we're taking the approach of still giving you everything that you need, but more bite sized for it to be more, more easy going, more easy to start with, and less intense from, from a mid standpoint. And if I may expand on this, yeah, like this is quite an interesting, I would say,
logical continuation of what was initially intended with the templates, right? Because the initial experience was also highly, I would say customizable, but the premise there was actually, okay, so here is sort of people for people, for example, who are familiar with things like create react app or any of the template builders that you would usually get and develop is here is a set of pieces that we think is a good starting point for you. Go ahead and pretty much, you know,
it's up to you to do whatever you want with it. But there is some, I would say benefits to that approach, but certainly there's the realization that there's a lot more power to actually customize this experience by allowing it to treat them as as Lego blocks, right? Because you always start small, you always start with certain base requirements and then you keep expanding and functionality, but only functionality that you actually find and then need at a particular point
in time. And I think, yeah, was, and I guess for some engineers, they will realize that what Alessandro just said is a bit of a spoiler alert. But basically, I think people are going to be, are going to find this really useful. And thank you. Thank you for the wonderful answer, Alessandro. I would love to move to ask a question to Rob. Our second is you. So it's not just one, it's not just two and best CTO is the best we have we have like a kind of top trumps.
But as a as a CTO, what do you think are looking back at the set of the features that were delivered so far and all the work that went into the design of how we get. Are there any interesting engineering challenges that MakerX has faced when implementing those and what innovative solutions have you considered to overcome these? And I'm pretty sure we do have
quite a good chunk of example there. Yeah, for sure. And hi, everyone. So Rob Moore, co-founder and CTO of MakerX, we're a business that works with startups, corporates and venture builders to build ventures and digital products. And as has been said, we've been working very closely with John and Alessandro and the Elgrand Foundation to build out the algorithm experience. And it's certainly, I know John was saying it's one of the things he's probably the most proud of
in his career and same for myself because I'm immensely proud of what's been built. I think it's really cool. And yes, this is a really hard question to answer because pretty much every single thing that we've done over the last 12 months has been really interesting from a technical perspective. We've really been pushing the boundary of I guess what is possible and what has been done
in the Web3 industry. And so I could probably sit here all day talking through that. The obvious one that first comes to mind is probably the Poyer compiler because naturally building a compiler is incredibly large technical challenge and certainly doing it in the really small time frame that we built it in was very interesting. But I have a suspicion we'll probably touch on the Poyer compiler later on. So I'm actually going to pick something else or maybe two other things. So
the first one is probably the types deployment clients that Alessandro alluded to. This was a really fun challenge because if you think about it, you've got a smart contract in the metadata that describes a smart contract. And then the goal that we had, which was that someone interacting with that smart contract could write type, essentially type safe code in TypeScript or Python and have an idiomatic experience with that programming language to interact with that
contract. And that we would abstract away as much as possible all of the intricate Algorand protocol knowledge that you would otherwise have to have to be able to successfully issue transactions that call those methods and pass the right parameters and marshal them in the correct way from the type system of TypeScript and Python through to the underlying binary encoding that the AVM expects based on the smart contract code that you have written. And so that's quite an interesting
technical challenge. And I think in particular, the thing that was really exciting about it when we worked on it, and actually, this is one of the features that I personally did a bunch of work on it was really fun, is that the sky's the limit in terms of what do these clients that we're generating will like the code inside them and more importantly, the interface that they expose to
the developers that are calling them, like that could be literally anything. And so, you know, we were guided by those principles, I said it should be idiomatic, it should hide the Algorand stuff and it should be type safe. And it was just a lot of fun, I guess, to, you know, iterate and get towards an experience that I myself have used multiple times and I'm very grateful for that feature when I am using it because it makes the experience of calling these
smart contracts so much easier to do. And I understand the underlying protocol, you know, stuff and binary encoding, etc. quite deeply. But I don't want to be doing that day to day because that's the distraction from being productive as a developer to implement, say, a D app or a backend API or whatever it is that's abstracting this Algorand functionality. I don't want to be in that low level detail of binary encoding because it's not productive.
CTOs like Rob, I call them ivory terror CTOs, they don't want to get their hands dirty. Rob wants to be kind of standing on a mountain, just kind of like thinking, you know, you know what I'm saying, like not down the detail. Nice troll, John. Rob is probably one of the most detail-oriented and down and down and down in the real work CTOs I've ever met. So he's brilliant. I'm only teasing. I love it. You owe me a beer for that troll.
Anyway, so that was fun, right? It was fun and it was a big technical challenge, I guess, to whittle down the endless possibilities of, you know, what could a client experience look like down to what we ended up coming up with and making that idiomatic for each of them and including quite hardcore type inference things like when you call a method, it gives you the return
type of that method from the smart contract. You know, so if, for instance, you had a struct with multiple fields, you get a, you know, same type script and interface with those fields there and all of the encoding and decoding is taken care of for you. And in your programming code, you have this type safe return value. Like that's, it was hardcore to get that working. But the end result is basically magic. And as I said, it was a lot of fun. So the second thing
I thought would be interesting to talk about was the breakpoint debugging. And the reason why is because breakpoint debugging is something that like every developer generally would have some sort of experience of breakpoint debugging. It's a fairly foundational kind of software development skill, right? And the experience that you would have in traditional development and it could be anything like a web app and API, a console app, whatever, is that you attach a debugger to the
running process. And the running process stops at a certain point where you've set a breakpoint, and you can kind of move bit by bit through lines of code and hover over variables and see what they are, et cetera. It makes it so much easier to debug issues that happen in the code that
don't match your expectation when you programmed it. It's an incredibly productive kind of mechanism now the problem with the blockchain like Algorand, it's a decentralized kind of system, you can't pause Algorand and say, can you just stop executing the smart contract online free for a second there so that I can just see what's going on? You can't do that, right? It just fundamentally doesn't make
sense. And so the challenge that we had for that feature was how can we create an experience that feels intuitive for developers that have spent years and years and years learning how to do breakpoint debugging where you attach the process and stop the process and all of that, which we can't do with Algorand, but craft it in such a way between the library code and the
extension, Visual Studio, et cetera, that it feels like you've kind of done that. And where we landed frankly went beyond my expectations of what would be possible and is incredibly exciting. And I must call out the awesome work that Algorand Technologies did in creating the core debug adapter protocol, because they did some hardcore frankly and phenomenal work. And then we were able to build on top of that and integrating to Algor kit in this really intuitive like intuitive experience
that feels, you know, as close as possible to normal breakpoint debugging as you could get. So those two in particular, I think we're really interesting from a technical challenge perspective. Shout out to Jason Paul. One extra thing to that, which is like, people expect debugging because they're used to it from a traditional software engineering background, you get debugging in C, whatever, you know, you get
debugging in Rust, you get debugging in Swift. This stuff has to be built from the ground up. Like Rob just said, like we needed Algorand Technologies to add core things to the fundamental structure of the node and the tooling around the node. Then we needed Rob, Alessandro and the teams at MakerX and the foundation to work together to build up the entire debugging stack. And so it's like inventing fire for the first time. And so
this is a huge technical challenge. I know debugging might sound like a kind of a fundamental to some software engineers who may be listening, but we're doing this in a context where it's never been done before. And so I just blown away with the results. So yeah, I just want to say very well done on that because it's critical to a normal developer journey. But again, something that wasn't there a year ago. And also, as Rob mentioned, shout out to people at Inc
and for technologies for a lot of the work on the debug adapter protocol as well. And I guess, thank you to Big Enterprise is pushing for some of these standardization in terms of providing protocols to implement debug adapters. Because a great thing about this is that what we did with the Visual Studio extension is that it's actually relying on a language agnostic implementation that implies that it's actually fairly straightforward to extend it right now. It's
available on VS Code. But that core is actually could be extended to pretty much any IDE that supports the debug adapter, which is another important part because a lot of things that Rob was also mentioning in regards to the AlgoKit is obviously in line with some of the core. And as a developer, you can actually go on AlgoKit repository and look up the documentation. And there's the chapter on the principles. And there's roughly around eight
to nine principles on which AlgoKit operates. And I think modularity is extremely, extremely powerful and important concept that we are also trying to embed into a lot of the functionality and features on AlgoKit. And I definitely can agree with you more on this, Rob. I think that those were certainly very interesting technical challenges to tackle and solve. One thing that we do with AlgoKit is that we are championing VS Code, as it's the most common
text editor. But everything that VS Code does, you can do from the CLI. So we are just simply packaging it up a bit nicer for VS Code. But every piece of AlgoKit works, either you're in NeoVim, Emacs, Visual Studio, Sublime Text, if people still use it. So this is the important thing. It's catering to everyone, but giving a premier experience. And if you're going after Europe?
I was just going to say, you're basically describing two of the fundamental principles of AlgoKit that we've been very consistent in applying, one of which is meet developers where they are. So don't build something that only works if you say, on a Mac in this specific environment, blah, blah, blah, it's like, we're trying to build for whatever environment developers
have so that they can be productive where they used to be productive. And secondly, it's the modularity principle, which is every single thing that we do for AlgoKit is built up of multiple building blocks. And we design every single building block to be able to be used independently so that if a developer wants to opt out of certain things or craft their own experience by pulling some of the building blocks together in a different way, they're
totally open to do that. And that's like a deliberate thing that we've designed in. And I just want to say, if you take yourself seriously as an engineer, you should be in VIM and you should be in the command line. And I just want to say my VIM or C, I'll just check my VIM or C, right? My configuration for VIM is 848 lines. Can you imagine what that's like? How many years have you been crafting that, John? Decades. But actually, I use this. There's a great VIM or VIM or C bootstrap website,
and it kind of gives you the basics, but VIM is so powerful. So is Emacs, of course. And so command line bros for the win. I like that you sidestep the war of VIM versus Emacs and just send both of them are really good there. So you haven't pissed off half the audience. It's like, yeah, yeah. It's like tabs versus spaces. By the way, the answer is spaces. And what you should do is bind your tab to four spaces,
and then you won't have any problems. And then everything will be fine when you cat files. Exactly. Exactly. And by the way, if there's any other engineering kind of like serious questions you need to answer, we can do it now. We've done spaces and tabs. We've done Emacs VIM. What else is there? Algorithms or other blokechains? Algorithms. Unless you want privacy, in which case you can use Monero. Can I think anything else? Linux versus Mac?
Linux. Linux, I think, if I had to pick one to die, I'd have to pick Apple to die, because it's more important for computing that Linux exists. But on a day to day, the MacBook is probably the best portable computer I've ever owned, the current generation Apple Silicon. Yeah. And to, I guess, expand on the next topic, which is hopefully going to delve a little bit deeper into the algorithm. And given that, John, you already provided a great,
you know, outline of higher level deliverables and goals for this year. Is there anything that you would say makes you the most excited in regards to the upcoming algorithm features? Right? If we look at the current stack, right, we are, I guess, we are calling the 2023 as a V2, right, prior to that was establishing the fundamentals of the Alucid CLI and things like that. So we have already have a huge bundle, like, and actually the listeners of the same
podcast can go back in time and listen for episode number one or two. And essentially seed the discussions and problems the engineers and smart-coded developers used to have back in then back then it was actually like you couldn't dream about an ability to execute a single command with the chance essentially sets up end to end tests unit tests, it sets up, you know, static analysis, it sets up conventions, CI, CD that already has the deployment into things like
Netlify or VersaL. So and all of that just out of the box. And you pretty much can just focus on the actual problem rather than dealing with all of these tooling yet again, going back to that point with simplifying the complexity of the tools tool is should essentially never be in front of you, it should be beside you in some sense. But we have all of these great things in the baggage and obviously a lot of improvements are already being in works on each individual track
of the features that are already available for the users. But what would you say are these sort of most exciting things that you think are the logical continuation of what's already available in the algorithm ecosystem? Yeah, and I just, you know, you just went through, it just reminded me of so much of the stuff that's been accomplished there in that preamble. And I just want to say, I'm so grateful that I met Alizandro, I hired someone on to the team who was able to actually do this.
Like he's created this vision without any instruction. I mean, it didn't sound like I gave him a whole load of requirements and said, look, here's, here's, here's it in a nutshell. He's just incepted this stuff. And so, and with the incredible, hyper competent team at MakerX for the on the implementation, I'm just lucky that I met these people.
Okay, so I'll keep this short because I spent a lot of time talking on the previous one. I'm most looking forward to Python getting to production level, which is mid 2024 or sorry, early 2024, like March, something like that. And so that'll be production, you can use it in your code day to day. And it just makes building and maintenance so much cheaper. You just have to hire a Python
person, you don't have to hire like a TL expert. And it's also going to make it fun and super inclusive for the whole world from from teenagers in school all the way to to quantitative analysts and in FX options brokerages. That's number one, number two, moving that line by line debugging that Rob talked about to support things like Python. I mean, it's a hope. It's not an absolute certainty, but that's what one of the goals is for this year. And you'll be able to stay in
Python as you debug. Super amazing. And then yeah, I think they're there are my two most favorite, I guess as well, reusing that incredible pipeline that LLVM style, efficient pipeline for compilation that we built or the team have built for Python, reusing that maybe to screw off the the front end and put a different language on. I think that'd be very exciting if we can do that. And I think that's part of this trip. So yeah, that's it. And another one, Nvidia versus AMD.
The answer is an Ortiex 4090. And so if you bought an AMD card, I'm afraid you've made the wrong choice. But but they make very good CPUs. And so I'm a person who uses the 7800 X 3D over the i9 1390 and 900 K or whatever. So AMD for the CPU and video for the graphics card. On point. And controversial, I like it. And to, I guess, expand on this algorithm, evolution, obviously,
it's an open source project, right, which has its own benefits and challenges. And one might actually be curious about how how would one approach measuring, you know, key performance indicators for these things, how would you monitor the reception of features get and ensure that it's actually, you know, developer friendly and robust and navigating in an open source environment when dealing with the obligations of metrics such as that is sometimes could, you know, challenge
and require very interesting and I would say very interesting solutions, basically, in order to achieve that. So on that point, Alessandro, anything that you can perhaps expand on in regards to how you could also try to ensure that it's always on point in regards to what's the actual demands from the users. Yeah, so we have first and foremost, it's tracking is extremely difficult in CLIs. You're not on the web where there is 1000 different types of trackers, cookies and
everything and you can know where your user shops and everything. So on the CLI and neither would I want it to be honest, it's an address, his browser, his national average, everything, everything is right. It's invasive and CLIs and tools shouldn't be tracked to that level. They should just simply be tools that someone uses. So thankfully, with the approach, with the benefits of the modular approach that we set off to do since the beginning, we have split into different libraries,
all the different steps of the algorithm development experience. And so we can compare simple CLI downloads and this would give us a ballpark figure. Then we have client generators when they're pulled. This is an extremely useful criteria to measure the usage of it. And we can see usage growing week after week with the, with simply the download analytics that come. Of course, they're not precise because there's no telemetry, never will be. I am here on record to say it.
We will do everything in our, and we look at all these kind of things, all of the small pieces that compose our Gokit are self-standing packages. So we can see what is the usage of all those and when it's pulled in versus when it's not. That is one way we keep track and measure. The most important part though is the first line of feedback. Our DevRel team is extremely helpful, both to the core team, as because we first develop things in an MVP state.
DevRel gives us the initial feedback. Once that is incorporated, we go out and we go out for the entire people to look at it as a main release. People could well build from branches. It's all in the open. There is no hidden things. But the DevRels are a key part of this experience. Then, of course, we monitor our Discord channels are extremely active. We are always there monitoring it. We get up issues when they arise. They are triage-stakes really quickly. We also run quite
some bootcamps. For each new bootcamp, it's a fresh new batch of new developers, because it's usually beginner bootcamps. We can see and we can gather feedback from more experienced users on Discord and GitHub. But on the bootcamp side, we have the raw green to Algorand development feedback. That is important. That is treading the balance between experts and new developers. We should cater to both, because it's just simply a tool. A tool just works.
We see a lot of things that maybe we should tackle either with helper libraries or new functions in the U2s libraries from an expert developer standpoint. There are things in the documentation or how we approach simply even the information given within the CLI. That we get most from the beginner side, because they are least biased. They don't have a history without it. It's cleaner and more unbiased. If I may just slightly expand on this. I actually quite recently was thinking about what
are the origins of the term DevRel? Where does this came from? What kicked off this trend in the industry in some sense? I was very actually surprised and happy to learn that if you look at just general inception of this notion of a DevRel engineer, in general, there's a lot of companies nowadays that are actually misusing that particular role, which is DevRel is not just organizing conferences or having tech tools. DevRel is actually a very multifaceted and very nuanced
role or profession where you actually create the environment in which it's friendly. That's one of the reasons why I actually got into Algorand, because I've met a few DevRels and the response and the support and just the inclusiveness of the ecosystem was unparalleled to anything I've experienced so far in terms of just if you compare that with say opening an issue on an open source repository where someone responds in a year because someone tipped in $5 on
Tiffany Button on the markdown. That's one. But when you just tells you know, maybe you can implement it. Yeah, I'll be happy if you implemented yourself and I'll just approve it or something.
We get and then you get a dedicated ecosystem at this core channel where you come in, you ask a question, you get a tailored personalized response and you get this very friendly attitude basically that sort of makes you want to build, makes you want to expand your knowledge base and the fact that it's all on this very interesting, very decentralized and very scalable ecosystem that
literally can scale to billions of people. And I think that's a very important aspect to highlight and thank you for mentioning DevRels as well and shout out to all DevRels that are working at the foundation there. The folks are doing a really great job there. But to expand on this, to continue with Rop as well in building aggregate features. Are there any particular use cases? And once again, I'm also trying to be cautious of obviously your time and how hard it is to find a matching slot
spanning across two continents. Right now we have Europe and Australia on the call. But can you share maybe some use cases where technical ingenuity directly translated into delivering a lot of value for our good.
Yeah. I think there's one clear example that really truly stands out for me and that's it's around the Puerh compiler and more specifically something that John talked about before, which was the fact that we can actually add different front-end languages to it and basically reuse the engineering effort and the thinking and the optimizations and all the other awesome things that have been built into the compiler, but with a different language without having to
rewrite an entire compiler and team. And I think the origin of that was, look, honestly, when we first dived into doing what turned into Puerh, we didn't really know what none of us knew what it was going to look like. And so we dived in Eyes Wide Open, trying not to remove any options. And the team did a lot of research and were reading a lot of pretty hardcore academic journal articles from people that write compilers for a living.
A lot of them made my eyes glaze over when I saw them. But yeah, the team did a great job in figuring out what does it take to build a really good compiler. And one of the things that came out pretty early was this concept of having different layers, essentially, or stages that you go through in essentially a pipeline. And whilst on the surface, that might seem like that makes it more complex because there's probably more code and you've got to have all of these intermediate
representations that you kind of translate between for each layer. What it means is that each layer in its own right is a hell of a lot simpler because it's doing one thing and doing one thing well, and also able to use sort of proven algorithms that have been proven for decades, in some cases, in that particular layer, because that algorithm is really great at doing that thing.
And once we'd realized that, it became pretty clear to us that the first step after we pass the Python code is to turn it into an intermediate representation that essentially represents a high level language. And as soon as we had that on our architecture diagram, we were like, oh, we just realized that everything from that point on could be reused and you can
plug another language in the front. And so from that moment, that kind of, you know, ingenuity, as you said, kind of made it clear to us that what we were building here wasn't just a Python compiler, it was an AVM compiler that happened to start with Python as the language in front of it.
I think this is definitely a great example of a rather creative pivot because if you look into the original plans, right, there was a lot of fragmentation in the ecosystem and it was essentially initially assumed that maybe all of that could be solved by the direct transpilation, right? But there's so so much more power and thought that ended up going into delivering the compiler. And I'm very excited to look forward for the productization of the language and the compiler itself as well.
Going forward towards the closing, I guess forward looking insights, I have a a slight pivot of myself actually for John. I wanted to ask a slightly, I guess, open-ended question to you and I think you might actually enjoy it quite a lot. But when we look into like this notion of layers, right, we have layer two on Ethereum, our grand is a layer one, but it's always important to look back and realize that, well, what's layer zero, right? Layer zero is our internet infrastructure and none of that
would be possible without that. And obviously, when we look into internet, we have organizations like ICANN, we have the V3C consortium, right, the guys who develop basically the most fundamental, you could call them like atoms in physics, right, the most fundamental building blocks that essentially allow this massive global infrastructure that essentially is already being considered like, like it's an internet access, for example, being considered as a
fundamental human right, like it's so embedded into human society and pushes us so much further with that. So when it comes to V3C, they also are very interested and keen on decentralization, but they do have a slightly different and more conservative look into it. And you could actually understand their point, for example, creator of World Wide Web Tim Berners-Lee, who actually also was from, I believe, started at MIT with this project called SOLID and then later on ventured
off and created this company called INRUPT. And that's a lot more focused on linked data and semantic web. And it's yet, I would say, another angle of looking at how you can decentralize communication. And what he did with SOLID, and he, by the way, is a big proponent of going against the term Web3, which again, you could also understand his reasons, right? Because I would say Web3 was largely sort of borrowed in some sense by people in the blockchain community,
while the guy is actually standing at the roots of the original notion of it. But basically, his premise with things like SOLID, for example, is introduction of new core sort of V3C RFCs that define new protocols that built upon established web protocols that allow you to
further decouple data ownership from the applications. So that instead of, say, having Facebook storing all your images and Twitter storing, like storing all of your images, you say, okay, here's my folder with images, Facebook, you can access 10 images from here, Twitter, you can access 15 images from here, you can't really do anything else with that. And here I didn't information that you can apply on them, you can run them through AI algorithms for ads or
whatever. And so his whole fixation right now is on decoupling ownership of data, which is, I think, is also a very interesting way of thinking about decentralization. And his main argument against blockchains is actually, and I'm quoting this from the CNBC. Sorry, just a second. So blockchain protocols may be good for some things, but they're not good for solid. A web decentralization project led by Tim Berners-Leach has said, they're too slow,
too expensive, and too public. Personal data stores have to be fast, cheap, and private. And I obviously don't want to sort of go on the argument here, but there's a fair bit of generalization right when it comes to, and it's really hard to keep up with the things that are going in the blockchain industry. And to that extent, obviously, you can take big protocols that are slow and
expensive and use proof of work still, it's 2024. But at the same time, when we look at things like Algorand, which is, I think, takes a lot of boxes and what he considers this is an important argument
for prerequisites for having something like that done in proper decentralized matter. What are your sort of opinions on the ways how blockchain industry in general going to increase its interoperability with more sort of conservative and I guess more core layer zero sort of V3CRFCs and specs that they're introducing and that they consider it through decentralization. Sure. Yeah, so this is a huge topic. And so I'll try to be like a 30 second answer on it. But like,
I also care deeply about this. And my eyes were opened at CFC. I was on a panel with Yuval from Kanton Chain. And like he was telling me, they built Damol, right, this kind of Markup language it's actually like an abstract syntax tree for like financial instruments. And you can model anything from a structured product to a butterfly to like a whole bunch of like exotic things, like bonds, knock ins, knock outs, all in this kind of like tree. And so he made the point to me and
I think he's absolutely right. Interoperability really only gets there when an asset, when a bond is represented on an Algorand can be transferred to Ethereum without wrapping, without a translation where we have a standard baselayer representation of financial instruments where we have a standard baselayer representation of NFTs. Of course, on Ethereum, it's ERC721, ERC20 on Algorand,
it's ARKTHIS, ARKTHAT, ARK19, whatever. Like that stuff is fine. And you're representing the same abstraction or you have an abstraction representing the same kind of fundamental concept, but like it's not portable. And so I do think that we need like IEEE, ISO level kind of level standards that just kind of, you know, the way same way all Wi-Fi access points use the same radio frequencies and all like, like, you know, quick or HTTPS uses the same, it doesn't matter what
browser you're using, they all talk the same way. And so that's where I'd love to see it. I think things like the DREC Alliance, like, you know, non-partisan, non-biased technologies like that that Hedera and Algorand are doing together for key recovery, that's a first step into this kind of approach. But I would love to see leaders from or representatives or stewards from the various projects, all have a place that they can come to set standards globally, because sure, Ethereum's the
leader in a lot of this stuff. And most of the other chains have kind of taken a derivative of what they've done. But I would just love to see it more standardized, because that's where we get real interoperability. And by the way, congratulations was the great cooperation initiative was Hedera on the DREC, which I think is one of the most fundamental sort of issues in terms of
accessibility. Alessandro, is there anything you could, I guess, as a set of closing thoughts, you can share in regards to the house Algor kit is basically being designed to accommodate future advancement. Because right, what we're doing here is obviously targeting the user feedback and the needs and demands in the ecosystem. But at the same time, there's a lot of cool things that are happening and other chains, right? Everyone is working really hard in this particular
industry. And there's a lot of innovation happening. What would you say? What would you say is the mechanism by which Algor kit is essentially trying to be designed such that it can easily accommodate certain periods like that? Yeah, we've touched it throughout a bit, the entirety of this episode, the modularity aspect of our look it and whatever we ship, we try it to be as modular and self standing as possible case in point, the Puyah compiler,
the only certain thing at the moment in Algor and is the ATM. So languages come and go. We have Python for now, we'll add another language next year. But then if, and if all of a sudden zig brand new language gets into mainstream and everyone wants to develop the big, they'll have our integrations in commit histories and documentations that will do throughout the year on how to port a language to the Puyah compiler, they'll have that as a as a guiding
principle. So the Puyah compiler stays there, but everything around it could change. And the same thing goes for Algor kit. At the moment, we are as a front end, we are championing react, because this looks like the industry standard. But client generators, which is the core thing that we have done. Those can be can be used everywhere with JavaScript front ends, or even with Python or JavaScript back ends. This is the key thing, we are building solid foundations.
So that then everything that sits on top of it can change fast and can change easily. So this is, this is why with this year that we are not only building in open source, like we've always did, but we are building in the open. So all our developers and all our community members can see our whole process, how we go through tasks, scope them out, the ADR is behind them. They can see why and how we take certain decisions, and they can be a part of it,
because we are only as good as all the information that we can have. So the more information we have, the better and the better choices we can make. So I'm looking forward to a year of building in the open, building with the community, even more than ever, and building things that are not opinionated and can therefore serve and cater to the community as long as possible.
I can't agree with you more on that point. And historically, this podcast would always have the closing remarks by asking the guests on their opinions on sort of and advices for aspiring software engineers, but I think there has been 19 advices so far in the previous episodes. And this time, given the very special format, I wanted to ask the final question to Rob was a bit more, I guess, target towards a different audience. And this
audience, in this case, I'm talking about this. There's a lot of, I would say, small to medium size tech startups and businesses out there, not necessarily within blockchain, right? And they are all looking for ways to solve unique problems. And sometimes those unique problems are solved
with very unique distributed systems and technologies. And basically, if you are assuming them as a target audience, you know, from from their startup perspective, what technological trends should businesses be prepared to leverage and adopt if they're considering solving a problem with blockchain as the main key is a main tool to resolve this? And how do you think
Algukit and Algorantin in a bigger scope can facilitate this? Yeah, so I do spend a lot of time talking to startups and founders naturally that, you know, the key kind of target that we work with. And what I'd actually say, maybe controversially, is that if the starting point is how can I use this tech, they're probably not actually starting at the right point, because I generally say to people, don't start with the tech, start with the business problem
that you're solving, and what value means to that business problem. And, you know, as part of that, what is going to be a sustainable business model? Because it's a hyper competitive world. And if you don't have a sustainable business model, then you're going to go out of business. There's only
so many funding rounds that you can do from VCs, etc. Right. So I guess step one from my perspective then is, you know, once you have a, you know, this deep understanding of your business model and what value means, that's when you can start looking at what technology can potentially solve that.
And then that's the point where you can say, great, now that we know what you're trying to solve, is there unique ways that we can use technology, be it things like AI, which is obviously very big at the moment, or blockchain, or whatever other, you know, IoT, or whatever, there's so many technologies out there, potentially a combination of them that can help to solve business problems and create business models that otherwise wouldn't be possible, or they can make them more efficient,
or they can make them cheaper, or, you know, something or more secure, or whatever it is, right. And what I would then say is great, once you've figured that out, now let's figure out if blockchain is a good solution. And for that, the mental model I generally take is, there are certain architectural properties of blockchains, particularly one as, as John, as so eloquently put so many times fit for purpose as our grand, that, you know, help you
solve problems in a more, in a better or more efficient manner. And there's three categories of architectural properties, there's trust security and tradeability. So for trust, we're talking about things like business problems where immutability or public inspectability or
transparency are of value, right, to that business interaction. From a security perspective, it might be things like multi-party atomicity of some sort of transaction, which doesn't have to be a financial transaction, it could be any kind of business transaction or exchange of information or data or whatever it might be, or things like cryptographic verifiability, or where you're trying to prove a fact that something happened at some point, or, and in particular, that that's tamper
proof. There's obviously a number of interesting privacy kind of things that you can do naturally where you're not storing the actual data that needs to be private on a public blockchain. And certainly, if you want to have like enforced auditable history from a security perspective, that's a, that's really easy to do with blockchain. And then from a tradeability perspective, the
interesting thing about blockchain is it transcends borders. So whilst you still need to be regulatory compliant, things like global tradeability, proof of ownership, automation of business, processes based on ownership or trading of data or informational assets or whatever it might be, and certainly encoding like process efficiency, particularly using things like smart contracts where you can encode parts of the process in a, you know, a trustless manner into, you know, this
thing without needing humans to necessarily do things that in traditional kind of mechanisms, these are the things that blockchain technology and particularly a fit for purpose blockchain like Algran make really easy compared to what it would otherwise be. And then maybe to circle all the way back around, if you then look at something like Algor kit in the context of Algor and Algor
kit is something that makes it way easier. Once you realize that blockchain is a great answer to build the solutions that use that technology with traditional engineering skills without having to have a real deep, deep understanding of this very different kind of technology ecosystem and the low level protocol. So yeah, that's that's kind of my thoughts on that. Thank you. Thank you
for the great response. I think this is definitely a list of very important considerations to to keeping your head when you're once you obviously decide that it's indeed, you know, blockchain that is going to help me. But I absolutely agree with the point that the shouldn't start with speaking the technology, it should always start with speaking the actual problem to solve. How
can you reach a product market and all of those things but exactly. Yeah. On that note, I think we had very amazing and detailed recap of a lot of different areas and news and announcements in the Algorand world. And hopefully did a slightly deeper dive into Algor kit and looking forward to potentially have a dedicated episode on Puyah, but closer to the stages when it's going to be a bit
more. I would assume fit for production or prod. But other than that, once again, thank you very much for I know how hard it is to once again to make, you know, to organize something like this and make sure that everyone is comfortable and their time slot is available and things like that. So thank you very much for joining. It's an incredible privilege and pleasure to chat with you. And I hope the listeners are going to enjoy this episode and have a lot more insights behind what goes into
Algor kit. Thank you. It's been awesome. Thanks buddy.