Learning the Fundamentals of Stacks

GM, GM! Welcome to what is going to be another great episode of DevNTell. So if you didn't know, DevNTell is a 30-minute podcast held every Friday, allowing developers, founders, and anyone in between to come on the show and showcase what they've built or what they founded. And today, I'm ecstatic to welcome Kenny Rogers, who's Lead DevRel at Stacks. So if you didn't know, Stacks is a Bitcoin L2 designed to activate the Bitcoin economy through smart contracts and a trust-minimized two-way bridge. So if you stick around for today's episode, you'll see Kenny introduce the fundamentals of how Stacks works through a demo of a basic borrowing and lending app using sBTC and Clarity. All right, let's get into this. GM, GM! Welcome to the show, Kenny, ecstatic to have you on today.

Hey, yeah, thanks. Happy to be here.

Yeah, yeah, 100%. I guess before we get into all the great content you have planned for us today, would you like to give a brief introduction about yourself?

Yeah, yeah, that sounds good. So my name's Kenny, I'm the Lead DevRel at the Stacks Foundation, and so I focus a lot on developer education, doing workshops, tutorials. I work a lot on the documentation, run hackathons, all that good stuff, pretty much all with the goal of helping developers to be as successful as they can be working with Stacks L2.

Excellent, excellent. And just curious, like how did you first get interested in technology and development and eventually found yourself at Stacks?

Yeah, so I've been a developer for about 10 years now. And I actually got started when I was just working a couple random side jobs, like driving a forklift for Lowe's, doing landscaping, and randomly was like, 'Coding seems cool.' And so I found, I actually started with Laravel. I found Jeffrey Way's Laracasts website. And that was actually how I got into it, built a couple apps for fun, and then reached out to a couple local development studios that worked or operated in the town that I lived in and ended up coming on to one of them as a junior developer and then it kind of went from there. A few years in, realized I liked teaching and writing tutorials a lot, and then started writing some tutorials on Stacks and Clarity, and that ended up then leading into the role I have now at the foundation. So that's kind of my quick version of my journey into development, yeah.

Awesome, awesome. So were you orange-pilled first before being world-pilled?

I was, yeah. So I think I actually followed a trajectory that I've since learned has actually been pretty common to a lot of Stacks developers where I found Bitcoin first and was originally interested in it for economic reasons, not even necessarily like development reasons at all. And then after that found Ethereum and was like, 'Oh, you can actually like build on this stuff.' And then got into Ethereum and did some Ethereum and Solidity stuff for a year or two. And then eventually found Stacks, and then it kind of came full circle and was like, 'Oh wait, I can do the development stuff on Bitcoin also.' And so that was about three and a half years ago now probably that I found Stacks. And so yeah, that was the kind of the trajectory which has been pretty common, I've talked to a lot of Stacks developers, it's been a pretty common path that a lot of them have followed.

Interesting, interesting. I didn't know that. Well, that's awesome, and it's brought you here to this point, and yeah, really interested to learn more about Stacks here. So without further ado, I'll give you the floor.

Cool, yeah, that sounds good. We'll just go, I've just got a pitch deck that I'll present first just to kind of give everybody kind of the lay of the land and an overview of how Stacks works, and then I'll jump over into my code editor and we'll look at a little quick demo and then I'll give some resources for people that want to learn more and keep going. Let me share my screen.

And folks who are watching us live, if you have any questions at all for Kenny, please post them in the chat and we will get them addressed as we go. All right, floor is yours, Kenny.

Cool. Awesome. So yeah, we'll just kind of go over kind of the fundamentals of Stacks. We'll do an intro to Stacks, specifically the Proof of Transfer (PoX), that's the block production mechanism Stacks uses, Clarity, and sBTC. Those are kind of like the three key components. Real quick overview, the way that I like to think about how I describe, sort of the elevator pitch of Stacks is that it's a Bitcoin L2 designed to enhance Bitcoin's scalability and functionality. So if you look at L2s in the Bitcoin ecosystem, it's a little bit different than how they work in something like Ethereum because with a Bitcoin L2, you can either enhance the scalability or functionality or both. Since Bitcoin's scalability or functionality at the L1 is pretty limited, part of the role that L2s are starting to play is to also enhance the functionality. So if you look at something like Lightning, that's an L2 that enhances the scalability of Bitcoin, but it doesn't necessarily enhance the functionality. It doesn't like bring smart contracts or anything to Bitcoin. And so a lot of the L2s that we're seeing pop up now are trying to do both, and there's all kinds of different ways that they're doing that. Stacks is kind of one of the original ones. It's been around in some form or another. It originally started actually as a company called Blockstack way back in like 2018, 2019, I think. And now it's sort of evolved once Stacks 2.0 launched, which was I want to say 2021. That was when it decentralized and became an open permissionless network and it's kind of evolved from there. And I've been in the Stacks ecosystem for about three, three and a half years now. So that's what Stacks' big ultimate goal is: to enhance Bitcoin scalability and functionality to kind of unlock all that latent capital that's just sitting there in Bitcoin. And for me personally, the really, what I like the idea of is we've got the money that's decentralized and Bitcoin's got the name recognition, it's kind of a household name at this point. There's people using it in all over the world. Highly recommend everybody check out the work of Alex Gladstein, but he's the Chief Strategy Officer at the Human Rights Foundation. And he does a ton of work and writes a lot about how people are actually using Bitcoin right now to like escape financial oppression and hide their wealth when they're maybe under like an oppressive regime or something like that. And so what really brought me into the ecosystem is how can we take that idea and we've got the money that's decentralized, now how can we actually build an economy on top of it that's also decentralized? And so that's what I really like about working in Stacks, kind of the big picture vision of it.

But there's a few properties that I see are necessary for an ideal Bitcoin L2. It should inherit Bitcoin's security, use Bitcoin as the medium of exchange, enhance the scalability and/or functionality, ideally both. And it should do all this while being as decentralized as possible. And if we're being realistic about it, decentralization is a path and a spectrum, and so the goal is: how can we build something that works with the technology we have now that allows for more and more decentralization over time both as the technology improves, the project grows, all that stuff? So that's kind of the ethos that Stacks follows is: what can we build now that allows us to become more decentralized over time while still accomplishing those goals?

So Stacks has three primary components. The first is Proof of Transfer (PoX). This is the block production mechanism. We'll dig into a little bit about how this works. Clarity is the smart contract language, so you don't use Solidity on Stacks, you use Clarity. And this is kind of purpose-built in order to make it easier to write safe and secure smart contracts. And then sBTC, which is coming out later this year in just like a month or so, month and a half maybe. This is going to be really the core of how we accomplish this second goal right here of using Bitcoin as the medium of exchange. This is going to be the trust-minimized two-way Bitcoin peg that will allow you to convert your Bitcoin from Bitcoin into sBTC and then do all the smart contract things you want with it and then convert it back out to Bitcoin whenever you're ready. And the goal with this system is to make it as trust-minimized as possible. We'll get into kind of how that works a bit more in a couple minutes.

But I'm going to go over Proof of Transfer at a high level. There's a lot going on behind the scenes, and so I highly recommend anybody that wants to dig more into this go check out the Stacks documentation that's just at docs.stacks.co. But at a high level, you can think of Proof of Transfer as one level above proof-of-work. So with proof-of-work, what we're doing is Bitcoin miners are spending one external resource, which in this case is energy, for the chance to mine a second resource, which in this case is Bitcoin. Proof of Transfer kind of seeks to recreate that programmatically. So what Stacks miners do is they will spend Bitcoin for the chance to mine a new Stacks block and earn Stacks. And one of the key things here is that this is put into a weighted, verifiable random function, and so spending the most Bitcoin doesn't guarantee that you're going to be the next miner but it increases the odds. So again, the goal is to kind of programmatically recreate proof-of-work. But if you're a Stacks miner, you spend the Bitcoin and you don't win that block, you don't get the Bitcoin back, you spend it just like in proof-of-work, you spend the energy just like you're spending that energy whether or not you mine the next Bitcoin block. And Stacks kind of works the same way.

And where that Bitcoin goes, so where the Stacks miners will send the Bitcoin, is it goes to a second party in the block production mechanism called stackers. And what stackers do is they lock up their Stacks tokens and then they actually earn this Bitcoin yield. And so the Stacks miners are spending this Bitcoin, that's being transferred to these stackers and so right now I think the yield is like 9-10%. So you lock up your Stacks tokens and you'll earn a yield on that in real Bitcoin of roughly like 9-10%. So that's not like a synthetic token, that's actual Bitcoin that the stackers are earning.

And then in Proof of Transfer, we just released the Nakamoto upgrade, which was designed to add a lot of improvements to the way the Stacks blockchain works. And so the way that the Proof of Transfer works under Nakamoto is there are miners and stackers who are equally involved in the block production process. So what a Stacks miner will do, they'll spend their Bitcoin, let's say that they're elected to be the next miner. Instead of mining a single Stacks block, what they're going to do is they're going to be elected for a miner tenure, and a miner tenure on Stacks corresponds with a Bitcoin block time. And so they'll be selected to be the miner for the entirety of a Bitcoin block and within that time, they're going to propose several Stacks blocks to be included. And then what happens is those proposed blocks get passed on to the stackers, and their job is to basically serve as a check against the miners and verify that the blocks are following all of the rules of the chain and if they are then the stackers are the ones that will actually append those to the chain. So we've kind of got this cohesive relationship between both where if the miners don't do their job, they don't get their Stacks rewards, and if the stackers don't do their job then they don't get their Bitcoin yield. And there's a lot going on behind the scenes with signing software and different things that need to happen, but this is sort of the high level. Again, the docs are definitely the place to go if you want to dig into how this works a little bit more.

But the other key part of what happens here is that this process also includes Bitcoin finality, and what that means is that after two Bitcoin blocks, so let's say we've got Bitcoin block A and miner tenure A, once Bitcoin block B has been mined and confirmed, any Stacks transactions that were included in miner A's tenure are now anchored to the Bitcoin chain and you would actually have to reorg Bitcoin in order to reverse any of those transactions. And the reason is because as part of the, whenever a miner changes, they have to do a block commit transaction which actually happens on the Bitcoin side and part of that is they have to write in a hash of the Stacks history up until that point into the Bitcoin chain. And the Stacks chain can't fork on its own. So a new miner can't come in and try to overpower the network and create their own canonical fork, that's part of what the stackers check for is the miner has to build upon the previous miner's last mined Stacks block and they have to continue that chain. So that combination of writing that information to Bitcoin and not allowing forking on Stacks gives us Bitcoin finality so that the history of the Stacks chain is anchored to the history of the Bitcoin chain and you can't reorg Stacks without also reorging Bitcoin first.

Next thing we'll jump into real quick is Clarity. This is the smart contract language Stacks uses. If you're used to something like JavaScript or Solidity, Clarity is quite a bit different. There's a couple key things to know about it. One is that it's interpreted and not compiled. So you as a Clarity developer, you upload your code to the Stacks chain, that's going to be uploaded exactly as it is, there's no compiler step in there. There's no re-entrancy allowed in Clarity, it's just not allowed at the language level. There's built-in token support, so rather than pulling in like a library like OpenZeppelin, in Clarity there are native functions for working with NFTs and fungible tokens. It's composable, it's not object-oriented. So again, instead of like importing and inheriting a bunch of different functionality from a library, instead Clarity uses what are called traits. And traits basically serve as like smart contract templates. So for example, there's a standard fungible token trait. And if I implement that trait in my Clarity contract, what that means is that I'm required to have a certain set of functions that all conform to this fungible token standard. And the reason for doing that is so that then different third-party applications and marketplaces can all know that they're interfacing with the same format and there's a standard for how they can call things like transfers and mints and burns and that kind of stuff.

And then the final thing and probably the biggest difference outside of just syntax, which we'll look at in a second, is that Clarity's decidable. And the short version of that means is that it's not Turing complete, which means that there are no unbounded loops in Clarity. And this is probably the biggest difference for developers to kind of wrap their heads around. There's no unbounded loops meaning there's no for loops, there's no while loops. And the entire goal and reason behind this is because in a distributed system, it's a big advantage to know all of the possible execution paths of your program. And so there's no such thing as like running out of gas in the middle of a contract call in Clarity because because it's decidable and there's no unbounded loops, you can know before you actually call the function the exact maximum possible execution cost of that function is going to be. There's no way to run out of gas in the middle of a Clarity call and because of this it also has a lot of implications in testing because there's a finite number of potential paths that the code can actually follow. So one practical example of this is for data structures in Clarity that are sequences, so you know a collection of multiple things. You either have to do one of two things. So something like a map, which is, you know, typical key-value pair data structure. Maps in Clarity are not iterable, you can't loop over a map, you have to pull out individual values based on their keys, but you don't have to define a maximum length for a map. Whereas lists, you can iterate through lists, so there are looping functions in Clarity they just can't be unbounded. So for a list, when you define a list, you have to define a maximum length of that list of how many items can fit into it. And then you can loop over it because then the Clarity VM will know what the possible execution paths are and what the maximum cost is going to be to execute that. Again, there's an entire page on this just this concept of decidability in the docs because it is just something quite a bit different, so go ahead and check that out if you're interested more in how that works.

But the other big thing to wrap your head around is the syntax. And so here's a counter example in Clarity. If you're familiar with Lisp or some other functional programming languages, this might look familiar, but if you're familiar with stuff like JavaScript or Solidity this is going to be a lot different. And what I've found working with Clarity and talking to other developers who have is that what happens is that the learning curve, what is a little bit jarring right at first because the syntax is so different and there's a lot of parentheses, but it's a really short learning curve. So it's a very simple language and it's really easy to wrap your head around as soon as you start working with it a bit and get a feel for how the syntax works and how things are constructed. So here what we're doing is we're defining a map called counters. We're setting the key to a type of principal which is just an address and we're setting the value to a type of an unsigned integer so just a positive integer. Then we've got a read-only function called get-count and it takes one argument and that argument name is who and it's of a type principal. And then we actually implement the function and what this is going to do is we're actually going to start in the middle of this and work our way out, that's how I've found it's helpful sometimes to understand these functions, so we'll start in the middle at this map-get function call. And what that's going to do is that's going to get the value from our counters map that matches the argument that we pass in here for our who value and so this is a principal. So we're going to pull out the map value that matches that. And what this default-to function does is if that map-get doesn't return us a value, then we're going to default to zero. And this is another thing to note about Clarity is that you always have to return a response of some kind, you can't have like a hanging function call execute where it doesn't bubble up a response and so you're left hanging there, you have to handle responses for every single function call in Clarity. Next thing is we have a public function, so in Clarity there's public, private, and read-only. Just how they sound: public can be accessed from anywhere, private can only be accessed from within the contract itself, and read-only will not actually modify any chain state data, it'll only pull chain state data in and read it. So this count-up function again we'll start in the middle at this get-count. So this is going to do is it's going to call that get-count function, passing in the transaction sender, this is a built-in keyword. And then the next thing to note a little bit different about how Clarity works is operators are actually functions also. And so what we're doing here is we're calling the addition function which is what that plus sign is and the two parameters we're passing it are the count that we get from that get-count function and one. And so we're actually adding those two together by calling that add function. And then what we're doing is we're going to update that map with the map-set function. We're going to update the counters map and we're going to update the count of the transaction sender with that new value and then we're going to return an OK response which is one of the two response types you can have in Clarity. You can either have OK or an error and this just indicates you know if the function was successful or not. So that's kind of the brief walkthrough of the counter example and some syntax of Clarity.

Now I want to very quickly go through sBTC. And I'm going to kind of speed through this because one we're running out of time but two you can read more about this again in the documentation, there's an entire section on sBTC. But really what this is meant to do is provide a trust-minimized way to bridge your Bitcoin back and forth between the Bitcoin L1 and the Stacks L2. So at a very high level, the basics of how this works is I as a user will deposit Bitcoin into a threshold signature wallet. This is a wallet that's collectively controlled by a decentralized group of signers. Again, those are the same signers that we talked about earlier that will be involved in the block verification for the block production. So they will verify the validity of this Bitcoin deposit and once they verify the deposit actually happened and confirmed it, they'll then mint the corresponding amount of sBTC on the Stacks side of things. And so then now I'll have on my in my Stacks wallet, let's say deposit one Bitcoin on the Bitcoin side, I'll then have one sBTC in my Stacks wallet and then I can reverse the process when I want to go back to Bitcoin. I will call a withdrawal function within the sBTC smart contract, pass it say 1.5 sBTC, say I did some DeFi stuff now I have 1.5 sBTC. I'll then call that withdrawal function, that will get then passed to the signers, they'll verify it and then they will burn that sBTC and then send the Bitcoin, the 1.5 Bitcoin back to me. And there's always a one-to-one correlation of sBTC and Bitcoin. There are some verification mechanisms to make sure that sBTC's only minted when the corresponding amount of Bitcoin has been deposited and vice-versa. So we're going to go into a real quick Clarity demo.

This is a sample smart contract I have called Lagoon. It's just a super basic borrowing and lending protocol. And so I'll over not this entire thing because we'll run out of time but some of it. But what this is designed to do is implement a very simple sample smart contract for how you might implement something like a borrowing and lending protocol using that sBTC token that we just talked about. So the cool thing about sBTC is there's a ton happening under the hood and behind the scenes but for application developers, it's really just like working with any other fungible token that lives on Stacks. And so standards in Stacks are they're called SIPs. And so you can think of these as like an EIP, an SIP is a Stacks Improvement Proposal. And SIP-10 is the standard for defining fungible tokens. And so what we're doing here first is we're just defining a bunch of different data, defining a couple maps to keep track of stuff, defining a couple variables that we can change and then defining a couple constants to serve as errors. And then I'm going to spend a good chunk of time just right here because it'll illustrate a couple key concepts. But we've got a deposit function in this Clarity smart contract here. And we can see that we're taking in an amount and then we have this let block. And what let is going to do is the first block of let is going to set some context variables for the rest of the function. So right here we're setting this current balance variable which will then be available in the rest of the function here. And this highlighted part here is the actual function implementation itself. And so we've got a try block here. And what we're doing right here, this is kind of the most important part, is we are calling the sBTC contract, we're calling the transfer function in that sBTC contract and we're passing it the amount, the transaction sender, and then this 'as-contract' function. This is how we get the current contract's principal. So what we're doing here is we're calling sBTC transfer, we're passing it the amount we want to transfer which is the same as this argument here and we're saying that we want to transfer it from the transaction sender to the contract. And so let's go then take a look at this sBTC contract and remember earlier when I said that rather than being object-oriented and inheriting functionality through libraries, Clarity is composable. And so what this means is that if you want to use functionality from another contract, you actually call that contract directly and you have to explicitly pass where the contract is so that anybody that's looking at this code can directly go and see exactly what code that you're talking about. It just makes everything very linear and clear and you have to write out exactly what your contract is going to do, there's no hidden functionality. So if we open our sidebar here we'll actually see this sBTC contract. Quick side note, what I'm using here to build this is called Clarinet. This is a tool built by a company called Hiro which is one of the main developer tooling companies in the Stacks ecosystem. It's HIRO.SO, sorry, HIRO.SO is their website. But they built a tool called Clarinet which is how you can get a local development environment up. You can think of this, it's similar to like Hardhat or Foundry in the Ethereum world. But if I go to this sBTC contract, we're going to look for this transfer function. And so if we scroll down here, this is how I'm actually defining the sBTC token. And so this is just a mock version of what the actual sBTC smart contract might look like when it's deployed. And the whole reason I wanted to do this was illustrate that as a developer in order to work with this like trust-minimized two-way peg solution sBTC, this is literally all you have to do is you just have to call a basic contract and call the transfer function to move it around. Everything else is handled behind the scenes and under the hood through this signer system that we have. So if we go find this transfer function, one more thing too is we can see we're implementing a trait here, this is that fungible token standard trait that I was talking about, so this is what requires that we have certain functions in our contract. One of those is the transfer function. And what this is going to do is this is going to do a couple checks to make sure that we actually have permission to send this and then it's going to call this fungible token transfer function and this is a built-in native function in Clarity. And we want to transfer the sBTC token, we want to transfer this amount from this person to this person. And so that's what's actually happening under the hood. This is something that you don't need to worry about, this is just some internal record-keeping the contract uses. This assert statement is what is checking to make sure that the person calling this function is either the contract caller or the transaction sender meaning that they're the one that originated this request and they actually have the ability and permission to transfer this sBTC. And so that's what we're calling there, so we can deposit that into our system. And then we've got a couple other functions throughout here where we can borrow, again this is like a super basic borrowing and lending protocol definitely not meant to be used in production. But basically the rules we have set here you can see us setting all these context variables is we have a 50% over-collateralization rate and so you're allowed to borrow up to 50% of what you're deposit is. And then the way that we have yield and interest being calculated is that it will calculate based on a block time that's passed. And so you can call this get amount owed and it'll calculate your accrued interest and what that's going to do is that's going to use this block height keyword combined with the start block of when this loan was taken out and it's going to calculate how much interest you owe based on how many block times have passed. And then you can withdraw, borrow, get amount owed, you can repay as a depositor, so you can repay however much you owe and then you can also claim your yield as a depositor as well depending on your share of the pool.

So if you want to check this out and use it, you can go to I have this up as a repo: github.com/kenrogers/sbtc-starter. That's the repo where this lives. And the other thing that I have here is I have a README file and what this'll do is this'll actually give you an introduction to how the contract works and also how you can test it using the Clarinet console. So if we go back here and I open up my terminal, I can run 'clarinet console' and that's going to pop me into basically a mini development environment that's got these contracts deployed and it'll set me up with some test addresses. So I can go through and I can mint this sBTC, I can make all of these contract calls all from within here. This is my favorite way to do some like quick manual testing. And the other thing that we can do, we won't run it now because it takes a little bit to spin up, but you can also run 'clarinet devnet start' and that will spin up like a local, actually we'll run it real quick let's see if it works I haven't tried this before so bear with me if it doesn't work. But what this'll do is this'll actually spin up a mock version of what the actual Stacks blockchain does in production. So you can see behind the scenes here under services it's actually spinning up a mock Bitcoin node, a Stacks node, the Stacks signers, a Bitcoin explorer, so you can interact with your local Bitcoin API directly here. But this is how you can implement like a mock local development environment in your local system.

But yeah, that's that's about it. Basics of Stacks and a quick little demo contract. Again, highly recommend: one, checking out this repo to kind of get an intro to how it works, but then we also have there's a whole concept section in the docs that'll walk you through exactly how all of this stuff works in much more detail than what we covered here. And then we've got some guides and tutorials here too for anybody that wants like an easy guided introduction. If you go to stacks.org/dev, I created a five-day email course and this'll kind of give you like the crash course in Stacks and how the ecosystem works, what you need to be aware of, the developer tooling. It'll have you write your first smart contract. This is probably the best place to go for anybody that just wants like the holistic introduction to everything Stacks. It's guided and then there's a program at the end we're doing right now called Code for Stacks where you can get paid just for working on your own project, whatever you want to work on. So there's more information on that there as well. But yeah, that's about it.

Awesome! Yeah, that's wonderful. Thank you so much, that was quite an in-depth overview and you finished with just like 30 seconds left! But yeah, I'm curious to hear, has any interesting project caught your eye who's been building on Stacks? Like something you're like, 'Oh, I never thought someone would build something like this with Stacks'?

Yeah, let me actually pull up one more page because this will be good for everybody to reference as well. So let me share my screen one more time real quick to answer this question. But there is on the Stacks website there's an ecosystem page and so there's actually a shortcut if you just want to go to stacks.co/ecosystem right here. This is kind of a list of a bunch of different projects that are all being built in the ecosystem right now. You can sort them by different category. The one that I don't know if I'd say it was like unexpected, but the one that I'm maybe one of two of the ones that I'm most excited about right now are Hermetica, they're building a Bitcoin-backed stablecoin. And then Stacking DAO, and what Stacking DAO is doing is you can think of them basically as the Lido of the Stacks ecosystem. They're building a liquid stacking protocol. So you can, you know, lock up your Stacks to earn that Bitcoin yield but instead you get a stacked Stacks synthetic token minted and then you can use that in a bunch of different DeFi protocols like Velar is a good one, Zest is really interesting they're building a lending and borrowing protocol kind of like what we were looking at except you know actual real production level version. Bitflow is another DeFi application to look at and you can use your Stacking DAO tokens in all of these DeFi protocols much the same as you can use like a staked ETH token from Lido to then participate in DeFi as well.

And then we actually just I just wrapped up an EasyA hackathon in Boston this just actually about a week ago, this past weekend. We got some really interesting projects coming out of that. I don't know if anybody's familiar with what forward contracts are, but it's like a trillion dollar a day market and they built a prototype of basically building out these forward contracts on on Bitcoin using sBTC. So the whole idea there is how can we take this, which is what I really like these directions of how can we take what is currently a massive like traditional finance market and just put it on top of Bitcoin and bring Bitcoin all that Bitcoin liquidity to the same thing? So I like projects that that do that, but that was another one to to keep an eye on. They're not up on testnet yet or anything, they just had like a super simple prototype but excited about what that team's going to do.

Interesting, interesting. And I guess do you guys have any active grant programs for people to further be enticed to to start building on Stacks?

Yeah, we have a couple different things. Our grants program, the way it works right now is a little bit unique because we have several big upgrades in progress right now. All of our effort is kind of focused on those. And so our grants program is more focused on what we what we're calling critical bounties right now. And those are more like RFP-style requests where we're like, 'Hey, this thing really needs to exist in the ecosystem but you know the core devs don't have the resources to work on it right now, so here's what it looks like.' And then people will basically apply to say, 'I want to build this.' And then those are like much larger projects and larger payouts. But our like open grants program isn't really operating like that at the moment, it's more those critical bounties. But what we do have to encourage developers to get started is we're really looking for right now developers that are interested in like being technical founders so developers that have ideas for stuff they want to see built. Just with where the Stacks ecosystem is at right now, it's still very young and it's kind of a blue ocean right now. There's a ton of opportunity to build stuff, but it's right at this sweet spot where the developer tooling is really, really good but you know there's a ton of projects that still need to be built.

So we have this Code for Stacks program, if you just Google 'Stacks Code for Stacks program' it'll show up. But basically what this is designed to do is you can just build a project that you want to build and submit your PRs for it every month and then you'll be entered into a lottery to win either 100 Stacks tokens or there's a jackpot every month of 2,500 Stacks tokens. And that's just kind of like a way for us to incentivize people just being consistent building on their projects because that's what we've seen is the biggest differentiator is just being consistent. So that's another program that we have right now as well. And then in February right alongside ETHDenver, we've got a huge builders tournament coming up called Biddle Battle. I think the URL for that is just biddlebattle.com. But that one's going to be pretty cool too, there's going to be a bunch of different prizes for that.

Awesome! So sounds like there's a full gamut of opportunities coming up. That's awesome to hear. And I guess final question is you kind of hinted at it that you guys are are working on some stuff, some core functionality. Is there anything that can share along the roadmap side of things for Stacks or...?

Yeah, sBTC is the biggest one that's on the roadmap right now. That should be usable by developers on testnet before the end of the year. They're making really good progress on that. And then the other big thing is now that the main Nakamoto upgrade was launched just a few weeks ago, which shifted a lot of the way Stacks operates, but one of the big two big unlocks were Bitcoin finality that I talked about and then fast blocks. So before, Stacks blocks were tied one-to-one with Bitcoin block timing so you had to wait a long time for a Stacks transaction to be confirmed. Now we have those fast blocks with the tenure-based system that I talked about, but there's still a lot more optimizations that need to be made to bring that transaction time down. And so that's kind of those are the two big things on the roadmap are optimizing the transaction speed based on the new Nakamoto core upgrade and then yeah releasing sBTC.

Awesome, awesome. Exciting stuff and I really looking forward to seeing folks start to build all these interesting different kinds of apps with Clarity and Stacks. So weekends coming up gang, you got all this awesome resources in front of you so get building! And I guess with that, Kenny thank you so much again for taking the time to join join us today, giving that wonderful overview. And yeah one last shout out: how can people follow you on various social medias or get in touch if they have questions?

Yeah, X is the main one I'm on, my tag there is just 'kentherogers'. That's probably the best place to to follow me. And then that stacks.org/dev email course is going to be the best place to like get a bunch of other resources for help. I do a weekly office hours, you can reply to those emails and that'll get sent directly to me at my email. But yeah whatever anybody needs: follow me on Twitter, jump in the Discord and tag me, email me kenny@stacks.org, yeah any of those work.

Awesome, awesome. That's great, thank you so much for sharing that. And I guess with that, I want to wish everybody a very happy Friday, happy weekend wherever you may be and we'll catch you back here next week for another great episode of DevNTell. Right on, have a good one!

Bye!