-
diff --git a/concepts/block-production/README.md b/concepts/block-production/README.md
deleted file mode 100644
index 77b4b6be05..0000000000
--- a/concepts/block-production/README.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Block Production
-
-Block production is a key concept to understand in order to understand how Stacks operates under the hood. This section will walk you through the three main actions that need to happen in order for the Stacks chain to operate.
-
-* Mining
-* Signing
-* Stacking
-
-There are two primary parties in Stacks block production: miners and stackers. Miners are responsible for building and proposing new blocks, while stackers are responsible for validating both those blocks and signing sBTC deposits and withdrawals.
-
-Stacking is another action conducted by stackers that is a necessary prerequisite to signing. We'll cover how all of this works together in the next three sections.
-
-For an in-depth overview of the technical aspects of how block production works after the Nakmoto Upgrade, be sure to read through [SIP-021](https://github.com/stacksgov/sips/blob/feat/sip-021-nakamoto/sips/sip-021/sip-021-nakamoto.md).
-
-Here's a diagram outlining the block production process under Nakamoto rules. We'll dig into each part of this in the following docs.
-
-
diff --git a/concepts/block-production/bitcoin-finality.md b/concepts/block-production/bitcoin-finality.md
deleted file mode 100644
index a625504d74..0000000000
--- a/concepts/block-production/bitcoin-finality.md
+++ /dev/null
@@ -1,37 +0,0 @@
-# Bitcoin Finality
-
-The concept of 100% Bitcoin finality is crucial to the design of Stacks. This is what turns Stacks into a true Bitcoin L2 and allows it to leverage all of the security inherent in Bitcoin.
-
-Let's first define what we mean by 100% Bitcoin finality, then we'll dig into how Stacks accomplishes this.
-
-Finality refers to the point at which transactions are irreversible. Once a blockchain reaches finality, it is nearly impossible to change the ledger's history without undertaking extraordinary measures that are often computationally and economically prohibitive.
-
-When we talk about Stacks blocks having 100% Bitcoin finality, we mean that they are as hard to reverse as Bitcoin transactions themselves.
-
-That's a bold claim, so how does Stacks accomplish that?
-
-As discussed above, miners are responsible for producing Stacks blocks in their tenure, which corresponds to a single Bitcoin block. As part of their block commit transaction, which is the transaction that previously committed the hash of the next Stacks block to the Bitcoin chain, miners will instead be required to add an indexed block hash.
-
-The indexed block hash is the hash of the first block produced by the last Stacks miner in their tenure. This is the SHA512/256 hash of both the consensus hash of all previously-accepted Bitcoin transactions that Stacks recognizes, as well as the hash of the block itself.
-
-This will anchor the Stacks chain history to Bitcoin up to the start of the previous miner's tenure, as well as all causally-dependent Bitcoin state that Stacks has processed. This ensures Bitcoin finality, resolves miner connectivity issues by putting fork prevention on stackers, and allows nodes with up-to-date copies of the Stacks chain state to identify which Stacks blocks are affected by a Bitcoin reorg and recover the affected Stacks transactions.
-
-This relationship between Stackers, miners, Bitcoin blocks, and Stacks blocks is what maintains Bitcoin finality while allowing miners to rapidly produce Stacks blocks. Bitcoin finality is achieved because at every Bitcoin block N + 1, the state of the Stacks chain as of the start of tenure N is written to Bitcoin. Even if at a future date all of the former Stackers’ signing keys were compromised, they would be unable to rewrite Stacks history for tenure N without rewriting Bitcoin history back to tenure N + 1.
-
-Because of this, Stacks transactions can be considered to have Bitcoin finality after the tenure they are a part of concludes, or Bitcoin block N + 1. As an example, if I initiate a Stacks transaction that gets confirmed by a Stacks miner, at the conclusion of that miner's tenure (the end of the current Bitcoin block) that transaction will be written to Bitcoin as part of the Stacks chain state and all future miners are required to build off of that chain tip, making reversing the transaction as difficult as reversing the corresponding Bitcoin transaction.
-
-#### Nakamoto Transactions and Bitcoin Reorgs
-
-If Nakamoto transactions follow Bitcoin finality, what happens if Bicoin forks?
-
-In order to answer this question, we need to distinguish between two types of Stacks transactions: Bitcoin-reliant and internal.
-
-**Bitcoin-reliant** transactions are transactions that read Bitcoin state. If Bitcoin forks, then these transactions will change. For these, you cannot do better than following Bitcoin finality. Let's say you moved BTC from L1 to L2, you have to wait for Bitcoin finality before your L2 BTC can be used (you don’t have any L2 BTC if Bitcoin forks and your L1 transaction becomes unconfirmed).
-
-**Internal** transactions don't rely on Bitcoin state, and thus won't change if Bitcoin forks. We can have faster confirmations with these because even if Bitcoin forks, signers can ensure that these are re-processed in the same order.
-
-The key takeaway is this:
-
-Under Nakamoto Stacks transactions won’t impactfully reorganize due to a Bitcoin fork. Not only is reorging relatively infrequent, but transactions on Stacks that got reorganized due to a Bitcoin fork behave just as reorganized Bitcoin transactions do. With some future analysis, transactions purely on the L2 chain may one day be entirely unaffected.
-
-This is a nuanced and complicated concept, so if you are interested in learning more about how this works, you can take a look at the [Bitcoin Reorgs](bitcoin-reorgs.md) page of the docs.
diff --git a/concepts/block-production/bitcoin-reorgs.md b/concepts/block-production/bitcoin-reorgs.md
deleted file mode 100644
index b99d664c7a..0000000000
--- a/concepts/block-production/bitcoin-reorgs.md
+++ /dev/null
@@ -1,27 +0,0 @@
-# Bitcoin Reorgs
-
-Under Nakamoto Stacks transactions don’t impactfully reorganize due to a Bitcoin fork. Not only is reorging relatively infrequent, but transactions on Stacks that got reorganized due to a Bitcoin fork behave just as reorganized Bitcoin transactions do. With some future analysis, transactions purely on the L2 chain may one day be entirely unaffected.
-
-Understanding this concept fundamentally comes down to understanding finality on post-Nakamoto Stacks.
-
-**Under Nakamoto the Stacks chain won’t fork on its own.** It is designed not to fork with only special exceptions, and it’s entirely infeasible for Stacks to fork on its own if even 31% of Stackers don’t want it to fork, and even then it would likely only happen within the span of a single tenure.
-
-The only case in which Stacks forks post-Nakamoto is if Bitcoin forks cause it to fork.
-
-Under Nakamoto, instead of winning the right to make a single block, miners win the right to make a ton of blocks, and during that time we say they’re under “tenure”. Every single Stacks block produced in a tenure requires at least 70% of Stackers to approve (sign) it for it to be included in the Stacks blockchain. The Stackers are watching the Bitcoin blockchain and will only sign blocks from the miner that won the latest sortition.
-
-Now, let’s imagine that Bitcoin reorganizes itself and the Stackers were watching a Bitcoin fork that is now sub-optimal. The Stackers would essentially go back in time to the latest common sortition between the fork that it was watching and the new best Bitcoin fork and start signing the blocks within the tenures from there. Note that 70% of the Stackers will be doing the same thing all at once, and the moment 70% agree to start signing from the latest tenure on the new Bitcoin fork there’s a new singularly optimal Stacks blockchain.
-
-So what happens to the transactions that were confirmed on the tenure that got reorganized? Nothing. Still in the mempool as if the reorganized tenure didn’t happen. For anything within the Stacks blockchain everything is fine.
-
-**This is 1:1 with a Bitcoin fork reorganizing a Bitcoin transaction.** You shouldn’t consider a transaction on Bitcoin final if it’s near the chain tip, and you shouldn’t consider a Stacks transaction final if it’s near the tenure tip.
-
-#### Replaying Transactions
-
-Since 70% of the signers have to sign any Stacks block included in the chain at least 70% of signers know the state of the chain before and after a Bitcoin fork causes a Stacks reorg.
-
-There’s a catch to this that makes enforcing it difficult: if a transaction were dependent on something on the Bitcoin blockchain that also got reorganized (a peg-in, for example), that transaction would now be invalid. Taint analysis is when you attempt to answer the questions “which transaction interacted with the now-orphaned Bitcoin blockchain in a way that makes them invalid (tainted) in the new chain” and then also “which transactions interacted with the now invalid (tainted) transaction such that they are now also invalid”. There’s a cascading effect, but enforcing any kind of replay requires that the Stackers and the Miners can identify which transactions can get replayed at all.
-
-Taint analysis, and subsequently replay enforcement, can be added in the future.
-
-For the first release, Nakamoto explicitly ties the Stacks blockchain to the Bitcoin blockchain such that there’s only one optimal Stacks fork tied to Bitcoin at any given point. This is completely 1:1 with the Bitcoin Blockchain behavior, but on the tenure scale.
diff --git a/concepts/block-production/mining.md b/concepts/block-production/mining.md
deleted file mode 100644
index 1744239d04..0000000000
--- a/concepts/block-production/mining.md
+++ /dev/null
@@ -1,136 +0,0 @@
-# Mining
-
-{% hint style="info" %}
-This is conceptual guide that covers how mining works. For practical steps on how to setup your own miner please refer to the guides to running a miner on [mainnet](../../guides-and-tutorials/run-a-miner/mine-mainnet-stacks-tokens.md) and [testnet](../../guides-and-tutorials/run-a-miner/mine-testnet-stacks-tokens.md).
-{% endhint %}
-
-### Miner Tenures
-
-In previous version of Stacks (before the Nakamoto Upgrade), Stacks miners would mine new Stacks blocks at a one-to-one cadence with Bitcoin blocks.
-
-After Nakamoto, this is no longer the case. Under Nakamoto rules, miners are instead selected for a tenure that corresponds to a Bitcoin block. During this tenure, miners build and propose several Stacks blocks (roughly every 10 seconds) and stackers will approve and append them (next section).
-
-To be considered for a tenure, a miner must have a block commit included in a Bitcoin block. If a miner wishes to update their commitment after submission, they may use Bitcoin Replace-By-Fee.
-
-### Coinbase rewards
-
-Miners receive coinbase rewards for tenures they win.
-
-The reward amounts are:
-
-* 1000 STX per tenure are released in the first 4 years of mining
-* 500 STX per tenure are released during the following 4 years
-* 250 STX per tenure are released during the following 4 years
-* 125 STX per tenure are released from then on indefinitely.
-
-These "halvings" are synchronized with Bitcoin halvings.
-
-
-
-### Transaction fees
-
-Miners receive Stacks fees for transactions mined in any block they produce.
-
-### Reward maturity
-
-Block rewards and transaction fees take 100 blocks on the Bitcoin blockchain to mature. After successfully mining a block your rewards appear in your Stacks account after \~24 hours.
-
-### Mining with proof-of-transfer
-
-Miners commit Bitcoin to **two** addresses in every leader block commit. The amount committed to each address must be the same. The addresses are chosen from the current reward set of stacking participants. Addresses are chosen using a verifiable-random-function, and determining the correct two addresses for a given block requires monitoring the Stacks chain.
-
-For more detailed information on this process, read [SIP-007](https://github.com/stacksgov/sips/blob/main/sips/sip-007/sip-007-stacking-consensus.md), which describes proof of transfer in detail.
-
-
-
-PoX mining is a modification of Proof-of-Burn (PoB) mining, where instead of sending the committed Bitcoin to a burn address, it's transferred to eligible STX holders that participate in the stacking protocol.
-
-{% hint style="info" %}
-A PoX miner can only receive newly minted STX tokens when they transfer Bitcoin to eligible owners of STX tokens
-{% endhint %}
-
-
-
-Miners run Stacks nodes with mining enabled to participate in the PoX mechanism. The node implements the PoX mechanism, which ensures proper handling and incentives through four key phases:
-
-* Registration: miners register for a future election by sending consensus data to the network
-* Commitment: registered miners transfer Bitcoin to participate in the election. Committed BTC are sent to a set participating STX token holders
-* Election: a verifiable random function chooses one miner for a new tenure to write blocks on the Stacks blockchain
-* Assembly: the elected miner writes the new blocks by pulling transactions from the mempool and collects rewards in form of new STX tokens
-
-### Probability to mine next block
-
-The miner who is selected to mine the next block is chosen depending on the amount of BTC the miners sent, that is, transferred or burnt.
-
-The probability for a miner to mine the next block is determined using a variation of the Assumed Total Commitment with Carryforward (ATC-C) MEV mitigation strategy described in [this document](https://github.com/stacksgov/sips/blob/feat/sip-021-nakamoto/sips/sip-021/MEV-Report.pdf) to allocate block rewards to miners. The probability a miner will win the sortition and be granted the current tenure will be based on a function that accounts for the total block commit spend on the blocks leading up to the current sortition.
-
-You can read more about this in the [MEV section of SIP-021](https://github.com/stacksgov/sips/blob/feat/sip-021-nakamoto/sips/sip-021/sip-021-nakamoto.md#block-reward-distribution-and-mev).
-
-While there is no minimum BTC commitment enforced by the protocol, in practice, there's a floor constrained by [dust](https://unchained-capital.com/blog/dust-thermodynamics/): basically, if the fees for a transaction exceed the value of the spent output, it's considered dust. How dust is [calculated](https://github.com/bitcoin/bitcoin/blob/master/src/policy/policy.cpp#L14) depends on a number of factors, we've found 5,500 satoshis to be good lower bound per [output](https://learnmeabitcoin.com/technical/output). Bitcoin transactions from Stacks miners contain two outputs (for Proof-of-Transfer), so a commitment of at least 11,000 satoshis / block is recommended.
-
-To calculate the amount of BTC to send miners should:
-
-* Guess the price BTC/STX for the next day (100 blocks later)
-* Guess the total amount of BTCs committed by all miners
-
-Stackers are in charge of both validating and appending new blocks and conducting miner tenure changes. The next section will explain how that works, and then we'll see how this process results in Bitcoin finality.
-
-### Stacks mining in practice
-
-If you take a look at [SIgnal21's mining dashboard](https://app.signal21.io/stacks/mining), you can view some interesting data about mining on the Stacks network, including BTC spent per block, STX earned per block, the total number of miners over the course of the chain's history, and the number of miners for any given block.
-
-Many people notice the seemingly small number of miners on Stacks. Without context, this can sometimes raise eyebrows. Let's dig into how mining works on Stacks so we can understand why this isn't an issue for decentralization.
-
-Stacks miners function similarly to sequencers in L2 systems in that they are only responsible for constructing and proposing new blocks, not appending them to the chain. But unlike most Ethereum L2s that operate with just a single centralized sequencer, Stacks consistently has at least 4-5 miners with open membership allowing anyone to join.
-
-It's important to note that there are two primary parties involved in the block production process on Stacks: miners and stackers.
-
-These two roles serve complementary relationships in the [block production process](./), and stackers drastically reduce any potential destructive power miners have over the chain.
-
-Miners cannot reorganize the chain. In the worst case, all miners can do is omit (some kinds of) transactions, and all that is required to address this is to run your own miner.
-
-Furthermore, more miners on the network would mean fewer BTC rewards for Stackers, as miners would have to spend more of their funds on Bitcoin L1 fees rather than sending it to the Stackers.
-
-{% hint style="info" %}
-**Wouldn't more miners mean more competition, meaning more rewards?**
-
-The reason more miners means fewer rewards is because miners act economically rationally, and they don't have an unlimited amount of BTC to work with.
-
-Miners are paying their PoX commitments plus their Bitcoin fees for a chance to win the coinbase (1,000 STX) plus fees for a tenure. If there are more miners, they will each pay less, because they will have a lower chance of winning. They can't pay ever-increasing amounts of BTC because at some point they will never be profitable, so there is a limit to how much BTC they can spend in order to try and win a tenure.
-
-As they pay less, the Bitcoin fee becomes a more significant portion of their expenses, and that also decreases their odds of winning the tenure.
-
-Here's a concrete example:
-
-Let's say Stacks is trading at 1,000 Sats per STX.
-
-The total spend from all miners, if everyone is acting logically and we ignore Stacks fees, would be less than 1,000,000 Sats (1,000 STX coinbase \* 1000 Sats/STX).
-
-If that is from 5 miners, then it could be 10,000 Sats (2,000 Sats for each transaction) going to Bitcoin fees and 990,000 Sats going to PoX.
-
-If there are 100 miners, then it would be 200,000 Sats going to Bitcoin fees, and 800,000 Sats going to PoX.
-{% endhint %}
-
-
-
-This creates a natural economic equilibrium where:
-
-1. Enough miners participate to ensure blocks are produced reliably
-2. Stackers receive optimal BTC rewards
-3. The network maintains censorship resistance without unnecessary mining competition
-
-This design is intentional - by having stackers as complimentary security guarantors who receive BTC rewards via PoX, Stacks achieves security without requiring an excessive number of miners competing solely to win block production rights.
-
-Unlike other chains where miners alone determine the canonical chain, Stacks' two-party system provides stronger guarantees:
-
-* Miners cannot force invalid transactions or blocks (stackers won't sign them, and even if they did, the nodes would not accept them)
-* No miner can unilaterally reorg the chain (stackers control chain finality)
-* The 70% stacker threshold signature requirement ensures broad consensus before blocks are accepted
-
-This separation of concerns between miners and stackers is what makes Stacks uniquely secure despite having a small number of miners.
-
-### What About Microblocks?
-
-Microblocks are a legacy feature of the previous version of Stacks that no longer exist. They were originally created as a way to improve transaction throughput, but without the functionality of Nakamoto, they never worked in practice.
-
-Instead of microblocks, Nakamoto instead utilizes a block production structure that creates Stacks blocks at a rapid cadence as described here.
diff --git a/concepts/block-production/stackers-and-signing.md b/concepts/block-production/stackers-and-signing.md
deleted file mode 100644
index 0667c32154..0000000000
--- a/concepts/block-production/stackers-and-signing.md
+++ /dev/null
@@ -1,81 +0,0 @@
-# Signing
-
-Stackers play an essential role in the Nakamoto system that had previously been the responsibility of miners. Before, miners both decided the contents of blocks, and decided whether or not to include them in the chain (i.e. by deciding whether or not to confirm them). In this system each actor has the following responsibilities necessary to make the system function reliably without forks:
-
-* **Miners** decide the contents of blocks.
-* **Stackers** decide whether or not the block is included in the chain.
-
-The bulk of the complexity of the Nakamoto changes is in separating these two concerns while ensuring that both mining and Stacking remain open-membership processes. **Crucially, anyone can become a miner and anyone can become a Stacker, just as before.** The most substantial changes are in getting miners and Stackers to work together in their new roles to achieve this proposal's goals.
-
-The key idea is that Stackers are required to acknowledge and validate a miner's block before it can be appended to the chain. To do so, Stackers must first agree on the canonical chain tip, and then apply (and roll back) the block on this chain tip to determine its validity. Once Stackers agree that the block is both canonical and valid, they collectively sign it and replicate it to the rest of the Stacks peer network. Only at this point do nodes append the block to their chain histories.
-
-This new behavior prevents forks from arising. If a miner builds a block atop a stale tip, Stackers will refuse to sign the block. If Stackers cannot agree on the canonical Stacks tip, then no block will be appended in the first place. While this behavior creates a new failure mode for Stacks -- namely, the chain can halt indefinitely if Stackers cannot agree on the chain tip -- this is mitigated by having a large and diverse body of Stackers such that enough of them are online at all times to meet quorum and incentivizing them via PoX rewards to act as such.
-
-### Stacker Signing
-
-{% hint style="info" %}
-You can view a list of all of the [active signers](https://explorer.hiro.so/signers?chain=mainnet) on Hiro's block explorer.
-{% endhint %}
-
-We'll cover how stacking works in the [Stacking](stacking.md) section and the sBTC signing in the [sBTC](../sbtc/) section, here we'll cover the signing process as it relates to Stacks block production.
-
-The means by which Stackers agree on the canonical chain tip and agree to append blocks is tied to PoX. In each reward cycle, a Stacker clinches one or more reward slots; there are at most 4,000 reward slots per reward cycle. Stackers vote to accept blocks by producing a weighted threshold signature over the block. The signature must represent a substantial fraction of the total STX locked in PoX (the threshold), and each Stacker's share of the signature (its weight) is proportional to the fraction of locked STX it owns.
-
-The weighted threshold signature is a Schnorr signature generated through a variation of the [FROST protocol](https://eprint.iacr.org/2020/852.pdf). Each Stacker generates a signing key pair, and they collectively generate an aggregate public key for nodes to use to verify signatures computed through a distributed signing protocol. This signing protocol allocates shares of the associated aggregate private key to Stackers proportional to the number of reward slots they clinch. No Stacker learns the aggregate private key; Stackers instead compute shares of the private key and use them to compute shares of a signature, which can be combined into a single Schnorr signature.
-
-When a miner produces a block, Stackers execute a distributed signing protocol to collectively generate a single Schnorr signature for the block. Crucially, the signing protocol will succeed only if at least X% of the reward slots are accounted for in the aggregate signature. Nakamoto is currently set to use a 70% signing threshold -- at least 70% of the reward slots (by proxy, 70% of the stacked STX) must sign a block in order to append it to the Stacks blockchain.
-
-Nakamoto uses the [WSTS protocol with the FIRE extension](https://trust-machines.github.io/wsts/wsts.pdf), which admits a distributed key generation and signature generation algorithm pair whose CPU and network bandwidth complexity grows with the number of distinct Stackers. The FIRE extension enables WSTS to tolerate byzantine Stackers.
-
-Here is a diagram outlining the relationship between signing and stacking.
-
-
-
-### Validating and Appending New Blocks
-
-When miners are selected for a new tenure, they begin building new blocks from transactions in the mempool. They then send those blocks to stackers for approval. Stackers must approve the blocks with a quorum of at least 70% for them to be appended to the chain.
-
-Stackers will approve a block based on several properties:
-
-* The block is well-formed
- * It has the correct version and mainnet/testnet flag
- * Its header contains the right number of Stacks blocks preceding this one.
- * Its header contains the correct total Bitcoin spent in the sortition that elected the current tenure.
- * Its header contains the same Bitcoin block hash as the Bitcoin block that contains its tenure's block-commit transaction\*
- * Its header contains the correct parent block ID of the immediate parent of this block.\*
- * The transaction Merkle tree root is consistent with the transactions
- * The state root hash matches the MARF tip root hash once all transactions are applied
- * The block header has a valid ECDSA signature from the miner.
- * The block header has a valid WSTS Schnorr signature from the set of Stackers.
-* All Bitcoin transactions since the last valid sortition up to (but not including) this tenure's block-commit’s Bitcoin block have been applied to the Stacks chain state\*
-* In the case of a tenure start block:
- * The first transaction is the `TenureChange` transaction.
- * The first transaction after the `TenureChange` transaction is a `Coinbase`.
-
-The properties marked with \* are collectively how Stacks ensures Bitcoin finality. By adhering to these properties, it ensures that miners are only able to append blocks if they build atop the correct chain tip, which also anchors the history to Bitcoin.
-
-Stackers, by validating these rules, ensure Bitcoin finality. We'll talk about this more in the next section.
-
-### Conducting Miner Tenure Changes
-
-The other primary signing responsibility in block production involves conducting tenure change transactions. As discussed in the mining section, miners will submit a `block-commit` transaction on the Bitcoin chain to initiate mining. If they are selected, stackers will detect that and create a `tenure-change` transaction.
-
-This tenure change transaction includes:
-
-| Name | Description | Representation |
-| ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------- |
-| tenure consensus hash | Consensus hash of this tenure. Corresponds to the sortition in which the miner of this block was chosen. It may be the case that this miner's tenure gets extended across subsequent sortitions; if this happens, then this `consensus hash` value remains the same as the sortition in which the winning block-commit was mined. | 20 bytes |
-| previous tenure consensus hash | Consensus hash of the previous tenure. Corresponds to the sortition of the previous winning block-commit. | 20 bytes |
-| burn view consensus hash | Current consensus hash on the underlying burnchain. Corresponds to the last-seen sortition. | 20 bytes |
-| previous tenure end | The index block hash of the last Stacks block from the previous tenure. | 32 bytes |
-| previous tenure blocks | The number of blocks produced since the last sortition-linked tenure. | 4 bytes, big-endian |
-| cause |
A flag to indicate the cause of this tenure change - 0x00 indicates that a sortition occurred, and a new miner should begin producing blocks. - 0x01 indicates that the current miner should continue producing blocks. The current miner’s tenure execution budget is reset upon processing this transaction.
| 1 byte |
-| pubkey hash | The ECDSA public key hash of the current tenure. | 20 bytes |
-
-This tenure change transaction is then sent to the newly elected miner and they must include it as the first transaction in their first block, otherwise stackers will not approve it.
-
-This process is then repeated over and over as new miners are elected for tenures.
-
-Be sure to take a look at [SIP-021](https://github.com/stacksgov/sips/blob/feat/sip-021-nakamoto/sips/sip-021/sip-021-nakamoto.md) to get a detailed description of exactly what happens under the hood during these processes.
-
-Next up, let's dig a little deeper into this idea of Bitcoin finality and how the Stacks block production mechanism achieves it.
diff --git a/concepts/block-production/stacking.md b/concepts/block-production/stacking.md
deleted file mode 100644
index 24c0aa36bd..0000000000
--- a/concepts/block-production/stacking.md
+++ /dev/null
@@ -1,169 +0,0 @@
-# Stacking
-
-### Introduction
-
-Stacking rewards Stacks (STX) token holders with bitcoin for providing a valuable service to the network by locking up their tokens for a certain time and participating as consensus-critical signers. If you aren't familiar with the concept of signers in Stacks, be sure to check out the [Stackers and Signing section](stackers-and-signing.md).
-
-This document is presented as a conceptual overview of stacking and how it works. You can also view the [stacking guides](../../guides-and-tutorials/stack-stx/) to get a practical guide on the different ways you can stack and how to do it and a [deep dive into the contract](../../example-contracts/stacking.md).
-
-`pox-4.clar` is the stacking contract. If you are interested in experimenting with proof of transfer use cases including state changes, solo stacking, and pool stacking, all the functions you’ll need can be found at the deployed contract:
-
-* Testnet: [https://explorer.hiro.so/txid/0xfba7f786fae1953fa56f4e56aeac053575fd48bf72360523366d739e96613da3?chain=testnet](https://explorer.hiro.so/txid/0xfba7f786fae1953fa56f4e56aeac053575fd48bf72360523366d739e96613da3?chain=testnet)
-* Mainnet: [https://explorer.hiro.so/txid/0xc6d6e6ec82cabb2d7a9f4b85fcc298778d01186cabaee01685537aca390cdb46?chain=mainnet](https://explorer.hiro.so/txid/0xc6d6e6ec82cabb2d7a9f4b85fcc298778d01186cabaee01685537aca390cdb46?chain=mainnet)
-
-### Stacking vs Staking
-
-While stacking on the Stacks network can be conceptually similar to staking, Stacks is not a PoS network and there are a couple key differences.
-
-There are two primary differences between stacking in Stacks and staking in PoS networks.
-
-#### Yield generated in burnchain token
-
-In staking, users lock one token and earn their yield in the same token. In stacking, users lock one token (STX) and earn a yield in the "burnchain" token (BTC), rather than the same token that was locked. In PoX, the yield comes from a finite, external source (Bitcoin deposits from Stacks miners). In PoS, the yield comes from the currency's issuance schedule itself, which means it is programmatically unlimited (but theoretically limited, we'll get into this a bit more below).
-
-That's the first main difference. Staking involves a yield of the same token being generated by the issuance mechanism set by the core protocol, where stacking yield requires an input of an external, separate token.
-
-How are these issuance rates set? In Ethereum, issuance rates are determined by network usage. Ethereum's goal is to create a deflationary money supply, so the issuance rate is determined depending on the usage of the network. In order for an Ethereum transaction to be considered valid, it must include a base fee that is burned during transaction execution. The [issuance rate is algorithmically determined](https://ethereum.org/en/roadmap/merge/issuance/#post-merge) block-by-block depending on how much ETH is being burned by these base fees plus normal gas fees.
-
-Stacking doesn't have any of this complex functionality, since it does not generate a yield of the same token (and therefore doesn't need to issue new tokens, but rather transfer existing tokens from the base network) and it does not need to maintain an issuance rate. We are speaking here of the yield specifically, Stacks does have an issuance rate and does generate new STX tokens, but this process is completely separate from stacking and the yield generated from it.
-
-The Bitcoin yield that stackers earn is determined by a combination of the Bitcoin being committed by miners and the number of STX tokens that are locked up in the network.
-
-#### No slashing
-
-Although stackers do fulfill a consensus critical role in Stacks by serving as signers, there is no concept of slashing in PoX (Proof of Transfer).
-
-Rather, if stackers do not perform their duties as signers, they simply cannot unlock their STX tokens and will not receive their BTC rewards.
-
-
-
-Stacking is a built-in action, required by the "proof-of-transfer" (PoX) mechanism. The PoX mechanism is executed by every miner on the Stacks network.
-
-{% hint style="info" %}
-Stacking functionality is implemented as a smart contract, using Clarity. Read more about [the contract](../../example-contracts/stacking.md).
-{% endhint %}
-
-### Locking and Unlocking STX
-
-One important thing to keep in mind is that when we speak of STX tokens being "locked", no transfer of STX tokens is occuring. Locking STX tokens is non-custodial, and STX tokens remain in your wallet. When you initiate a stacking transaction (described below) those tokens are locked and unspendable at the protocol level, but they do not leave the stacker's wallet.
-
-At the end of the lock period, they will be automatically unlocked (spendable at the protocol level) but this occurs implicitly, there is no direct transaction that unlocks them.
-
-### Stacking flow
-
-The Stacking mechanism can be presented as a flow of actions:
-
-
-
-1. Make API calls to get details about the upcoming reward cycle
-2. For a specific Stacks account, confirm eligibility
-3. Confirm the BTC reward address and the lockup duration
-4. The transaction is broadcasted and the STX tokens are locked. This needs to happen before the prepare phase of the next reward cycle, the last 100 Bitcoin blocks of the ongoing reward phase
-5. The Stacking mechanism executes reward cycles and sends out rewards to the set BTC reward address
-6. During the lockup period, details about unlocking timing, rewards and more can be obtained
-7. Once the lockup period is passed, the tokens are released and accessible again
-8. Display reward history, including details like earnings for previous reward cycles
-
-{% hint style="info" %}
-Keep in mind that the target duration for a reward cycles is \~2 weeks. This duration is based on the target block time of the Bitcoin network (10 minutes) and can be higher at times due to [confirmation time variances](https://www.blockchain.com/charts/median-confirmation-time) of the bitcoin network.
-{% endhint %}
-
-### Stacking delegation flow
-
-There are two main ways you can stack:
-
-1. Solo stacking
-2. Delegated stacking
-
-Solo stacking follows the flow outlined above, and is where stack your own STX tokens and run your own signer. In order to operate as a solo stacker, you need to have a minimum amount of STX tokens. This minimum is dynamic and can be found by viewing the [pox endpoint of the API](https://api.testnet.hiro.so/v2/pox) in the `min_threshold_ustx` field.
-
-
-
-The Stacking flow is different for delegation use cases:
-
-* Before Stacking can be initiated for a token holder, the delegator needs to be granted permission to Stack on behalf of the account owner. The permission is restricted to the maximum amount the delegator is allowed to Stack. The maximum amount is not limited by the available funds and can be set much higher. An account can only be associated with one single delegator
-* The account has to define the delegation relationship. They can optionally restrict the Bitcoin reward address that must be used for payouts, and the expiration burn block height for the permission, thus limiting the time a delegator has permission to Stack
-* Delegators have to lock Stacks from different accounts ("pooling phase") until they reach the minimum amount of Stacks required to participate in Stacking
-* Once a delegator locks enough STX tokens, they can finalize and commit their participation in the next reward cycle
-* Certain delegation relationships may allow the STX holder to receive the payout directly from the miner (step 5/6)
-* The termination of the delegation relationship can either happen automatically based on set expiration rules or by actively revoking delegation rights
-
-### Token holder eligibility
-
-Stacks (STX) token holders don't automatically receive stacking rewards. Instead, they must:
-
-* Commit to participation before a reward cycle begins
-* Commit the minimum amount of STX tokens to secure a reward slot, or pool with others to reach the minimum
-* Lock up STX tokens for a specified period
-* Provide a [supported Bitcoin address](../../example-contracts/stacking.md#supported-reward-address-types) to receive rewards
-* Maintain their signer software (if they are operating a signer)
-
-The following diagram describes how the minimum STX tokens per slot is determined.
-
-
-
-Token holders have a variety of providers and tools to support their participation in Stacking. The Stacks website contains a [list of pools and stacking options](https://www.stacks.co/learn/stacking#startstacking).
-
-### Stacking in the PoX consensus algorithm
-
-Stacking is a built-in capability of PoX and occurs through a set of actions on the Stacks blockchain. The [full proof-of-transfer implementation details](https://github.com/stacks-network/stacks-blockchain/blob/develop/sip/sip-007-stacking-consensus.md) are in SIP-007. Below is a summary of the most relevant actions of the algorithm.
-
-{% hint style="info" %}
-Note that SIP-007 describes stacking before Nakamoto. While much of the functionality remains the same, stackers now have the additional responsibility of operating as signers as outlined in [SIP-021](https://github.com/stacksgov/sips/blob/feat/sip-021-nakamoto/sips/sip-021/sip-021-nakamoto.md).
-{% endhint %}
-
-
-
-Stacking happens in reward cycles of 2100 Bitcoin blocks (roughly two weeks. Reward cycles are split up into two phases: the prepare phase and the reward phase.
-
-The prepare phase lasts 100 Bitcoin blocks and is where the new stackers for the upcoming reward phase are selected by the PoX anchor block (see SIP-007 for details).
-
-Because Stacks does not fork after the Nakamoto upgrade, the PoX anchor block is always known 100 Bitcoin blocks before the start of the next reward cycle. It is the last tenure-start block that precedes prepare phase.
-
-The PoX anchor block identifies the next Stackers. They have 100 Bitcoin blocks to prepare for signing Stacks blocks. Within this amount of time, the new Stackers would complete a Distributed Key Generation round for signing blocks. The PoX contract will require Stackers to register their block-signing keys when they stack or delegate-stack STX, so the entire network knows enough information to validate their signatures on blocks.
-
-This process is handled by [running a signer](../../guides-and-tutorials/running-a-signer/) and then subsequently [conducting stacking operations](../../guides-and-tutorials/stack-stx/stacking-flow.md) as that signer.
-
-### Stacking and Signing
-
-Stacking and signing are two distinct actions, but they are both necessary in order to perform the other. Signers must stack their STX tokens, and you cannot stack STX without running a signer. However, there is some nuance here depending on whether you are solo stacking or delegating.
-
-There are several possible scenarios that can take place. Let's go over them.
-
-### Solo Stacking
-
-If you are solo stacking, you have two options for signing.
-
-#### Run your own signer
-
-First, you can run your own signer by following the How to Run a Signer guide. This does require some technical chops and some resources for running a machine. It's all covered in the guide if this is the route you want to go down.
-
-#### Work with another signer
-
-If you don't want to run your own signer, you can collaborate with another signer and pass their signature into your stacking transactions, Details on how to do this can be found in the [Stack STX](../../guides-and-tutorials/stack-stx/) guide.
-
-### Delegated Stacking
-
-If you are delegating your STX to a pool operator, you don't need to worry about running a signer. Since you are only delegating your STX, but the pool operator is conducting the actual stacking transaction, the pool operator is responsible for running the signer.
-
-If you are a pool operator, we have a [stacking guide](../../guides-and-tutorials/stack-stx/operate-a-pool.md) specifically for you.
-
-### How and Where to Stack
-
-There are several options for stacking including solo stacking, participating in a pool, using an exchange, and liquid stacking.
-
-The Stacks website has a [stacking page](https://www.stacks.co/learn/stacking) dedicated to all these different options.
-
-For detailed instructions on how to stack, view the [Stack STX guides](../../guides-and-tutorials/stack-stx/).
-
-You can view all sorts of Stacking data and statistics using tools in the ecosystem such as:
-
-* [Signal21](https://app.signal21.io/)
-* [Stacking Tracker](https://www.stacking-tracker.com/)
-* [StakingRewards.com](https://www.stakingrewards.com/calculator?asset=stacks)
-* [Stacking Calendar](https://stacking.tools/)
-
-- [Signal21](https://app.signal21.io/)
-- [Stacking Tracker](https://www.stacking-tracker.com/)
-- [StakingRewards.com](https://www.stakingrewards.com/calculator?asset=stacks)
-- [Stacking Calendar](https://stacking.tools/)
diff --git a/concepts/clarity/README.md b/concepts/clarity/README.md
deleted file mode 100644
index 0a51a45328..0000000000
--- a/concepts/clarity/README.md
+++ /dev/null
@@ -1,55 +0,0 @@
-# Clarity
-
-Clarity is the smart contract language that Stacks uses. It has been built from the ground up to make it easier for developers to write safe, secure smart contracts. Clarity has several unique features that make it an ideal choice for writing smart contracts. We'll go over an overview of Clarity here, and highly recommend checking out the [Clarity Crash Course](../../guides-and-tutorials/clarity-crash-course.md) guide to dig in and get started learning Clarity.
-
-Clarity is a **decidable** smart contract language that optimizes for predictability and security, designed for the Stacks blockchain. Smart contracts allow developers to encode essential business logic on a blockchain.
-
-The design decisions behind Clarity were based heavily on taking lessons learned in common Solidity exploits and creating a language that has been purpose-built for safety and security in mind.
-
-These docs serve primarily as a reference for the functions and keywords that you can use in Clarity.
-
-In order to learn Clarity, we recommend diving into the [Clarity of Mind](https://book.clarity-lang.org/), an online book to teach you everything you need to know to build robust smart contracts, or joining a [Clarity Camp](https://clarity-lang.org/universe#camp), the cohort-based immersive Clarity experience.
-
-### What makes Clarity different
-
-The following section is an excerpt from the excellent book, [Clarity of Mind](https://book.clarity-lang.org/ch00-00-introduction.html):
-
-The number of smart contract languages grows by the year. Choosing a first language can be challenging, especially for a beginner. The choice is largely dictated by the ecosystem you are interested in, although some languages are applicable to more than just one platform. Each language has its own upsides and downsides and it is out of the scope of this book to look at all of them. Instead, we will focus on what sets Clarity apart and why it is a prime choice if you require the utmost security and transparency.
-
-One of the core precepts of Clarity is that it is secure by design. The design process was guided by examining common pitfalls, mistakes, and vulnerabilities in the field of smart contract engineering as a whole. There are countless real world examples of where developer failure led to the loss or theft of vast amounts of tokens. To name two big ones: an issue that has become known as the Parity bug led to the irreparable loss of millions of dollars worth of Ethereum. Second, the hacking of The DAO (a "Decentralized Autonomous Organization") caused financial damage so great that the Ethereum Foundation decided to issue a contentious hard fork that undid the theft. These and many other mistakes could have been prevented in the design of the language itself.
-
-#### Clarity is interpreted, not compiled
-
-Clarity code is interpreted and committed to the chain exactly as written. Solidity and other languages are compiled to byte-code before it is submitted to the chain. The danger of compiled smart contract languages is two-fold: first, a compiler adds a layer of complexity. A bug in the compiler may lead to different byte-code than was intended and thus carries the risk of introducing a vulnerability. Second, byte-code is not human-readable, which makes it very hard to verify what the smart contract is actually doing. Ask yourself, would you sign a contract you cannot read? If your answer is no, then why should it be any different for smart contracts? With Clarity, what you see is what you get.
-
-#### Clarity is decidable
-
-A decidable language has the property that from the code itself, you can know with certainty what the program will do. This avoids issues like the halting problem. With Clarity you know for sure that given any input, the program will halt in a finite number of steps. In simple terms: it is guaranteed that program execution will end. Decidability also allows for complete static analysis of the call graph so you get an accurate picture of the exact cost before execution. There is no way for a Clarity call to "run out of gas" in the middle of the call. We explore this idea more, along with a discussion on Turing completeness, in the security deep dive on decidability.
-
-#### Clarity does not permit reentrancy
-
-Reentrancy is a situation where one smart contract calls into another, which then calls back into the first contract—the call "re-enters" the same logic. It may allow an attacker to trigger multiple token withdrawals before the contract has had a chance to update its internal balance sheet. Clarity's design considers reentrancy an anti-feature and disallows it on the language level.
-
-#### Clarity guards against overflow and underflows
-
-Overflows and underflows happen when a calculation results in a number that is either too large or too small to be stored, respectively. These events throw smart contracts into disarray and may intentionally be triggered in poorly written contracts by attackers. Usually this leads to a situation where the contract is either frozen or drained of tokens. Overflows and underflows of any kind automatically cause a transaction to be aborted in Clarity.
-
-#### Support for custom tokens is built-in
-
-Issuance of custom fungible and non-fungible tokens is a popular use-case for smart contracts. Custom token features are built into the Clarity language. Developers do not need to worry about creating an internal balance sheet, managing supply, and emitting token events. Creating custom tokens is covered in depth in later chapters.
-
-#### On Stacks, transactions are secured by post conditions
-
-In order to further safeguard user tokens, post conditions can be attached to transactions to assert the chain state has changed in a certain way once the transaction has completed. For example, a user calling into a smart contract may attach a post condition that states that after the call completes, exactly 500 STX should have been transferred from one address to another. If the post condition check fails, then the entire transaction is reverted. Since custom token support is built right into Clarity, post conditions can also be used to guard any other token in the same way.
-
-#### Returned responses cannot be left unchecked
-
-Public contract calls must return a so-called response that indicates success or failure. Any contract that calls another contract is required to properly handle the response. Clarity contracts that fail to do so are invalid and cannot be deployed on the network. Other languages like Solidity permit the use of low level calls without requiring the return value to be checked. For example, a token transfer can fail silently if the developer forgets to check the result. In Clarity it is not possible to ignore errors, although that obviously does prevent buggy error handling on behalf of the developer. Responses and error handling are covered extensively in the chapters on functions and control flow.
-
-#### Composition over inheritance
-
-Clarity adopts a composition over inheritance. It means that Clarity smart contracts do not inherit from one another like you see in languages like Solidity. Developers instead define traits which are then implemented by different smart contracts. It allows contracts to conform to different interfaces with greater flexibility. There is no need to worry about complex class trees and contracts with implicit inherited behavior.
-
-#### Access to the base chain: Bitcoin
-
-Clarity smart contracts can read the state of the Bitcoin base chain. It means you can use Bitcoin transactions as a trigger in your smart contracts! Clarity also features a number of built-in functions to verify secp256k1 signatures and recover keys.
diff --git a/concepts/clarity/decidability.md b/concepts/clarity/decidability.md
deleted file mode 100644
index 52db783d2c..0000000000
--- a/concepts/clarity/decidability.md
+++ /dev/null
@@ -1,167 +0,0 @@
-# Decidability
-
-### What does it mean for a language to be Non-Turing Complete or Decidable?
-
-Non-Turing complete and decidable are two terms you will often hear about the security advantages of Clarity, but what do they mean?
-
-While related, they are not quite interchangeable, since there are a few differences.
-
-#### Non-Turing Complete
-
-A system or language is non-Turing complete if it cannot simulate a Turing machine, which is an abstract model of computation. Non-Turing complete systems have limited computational power compared to Turing complete systems. A Turing-complete system or language can simulate any Turing machine. Examples of non-Turing complete systems include finite state machines and some domain-specific languages (like Clarity).
-
-Non-Turing complete languages typically cannot express all possible algorithms. Specifically, some problems whose solutions require unbounded loops or recursion cannot be expressed using non-Turing complete languages. This last property is especially important in the context of Clarity, as it makes it so that features like unbounded loops and reentrancy are disallowed at a language level.
-
-#### Decidable
-
-A problem is decidable if there exists an algorithm that can always determine whether a given input has a particular property or not in a finite amount of time. In other words, a decidable problem can be solved by a Turing machine that is guaranteed to halt for all input instances. Decidability is a property of problems, whereas Turing completeness is a property of languages or computational systems.
-
-The fact that Clarity is decidable means that developers (and tooling) can more easily reason about and predict with certainty the behavior of Clarity contracts, regardless of the input.
-
-### Mindset of a Smart Contract Developer
-
-Before we dive into specifics, let's first set the context and viewpoint we should hold as smart contract developers who want to write secure code.
-
-As you explore further into the security properties of Solidity and Clarity, you'll see that there are always mitigation steps that _can_ be taken by developers to help address some of these security issues.
-
-The main issue, with this line of thinking, is it increases the odds of human error in smart contract security. If we can preserve functionality while mitigating the chance of human error as much as possible, we should do so.
-
-### Should smart contracts be Turing complete?
-
-We will discover new applications for smart contracts. These applications will go beyond current smart contracts, traditional contracts, and may even open new economic opportunities. Given these possibilities, how should we build our smart contracts? What characteristics should our smart contract languages have?
-
-It is good practice to separate data from programs. Should smart contracts be data, or programs, or something in between? If smart contracts are data, then should the programs that execute-them be Turing complete or perhaps less powerful? If smart contracts are programs, then what language should smart contracts be written in? What characteristics should this programming language have?
-
-The Church-Turing thesis is the hypothesis that all formal notions of computation are captured by Turing machines or modern computers. A programming language is Turing complete if it captures all formal notions of computation. Many programming languages are Turing complete. For example, Python, C++, Rust, Java, Lisp, and Solidity are all Turing complete.
-
-Consider a program and its input. In the worst case, determining this program’s output is impossible. Validating a program, on a particular input, is done by generating a proof-of-correctness.
-
-Proofs-of-correctness are logical proofs that can be mechanically validated. Finding proofs-of-correctness for programs and their input is undecidable. Kurt G\”odel showed there are undecidability logical statements.
-
-This indicates all programs in Turing complete languages cannot be validated in the worst case. Thus, Turing complete smart contract languages must allow contracts that cannot be validated.
-
-Alonzo Church and Alan Turing showed there are problems that are uncomputable. Uncomputable problems cannot be solved by any Turing machine. Hence, assuming the Church-Turing thesis, these uncomputable problems cannot be solved by any computer.
-
-We'll explore this idea further later in this section.
-
-Turing complete languages are very expressive. In fact, assuming the Church-Turing thesis, Turing complete languages are as expressive as possible in some sense.
-
-Is there a trade-off? What types of problems can occur with uncomputable problems and programs whose validity may be undecidable?
-
-As smart contracts subsume parts of contract law, consider the large body of laws and regulations for tax law.
-
-For instance, US tax law and regulations take up several million words. International tax law and regulations pushes these numbers much higher.
-
-Are these laws and regulations programs or are they data? If tax law were to be written in a Turing complete language, then the law may codify uncomputable problems. It is an accountant’s nightmare for their advice to be undecidable.
-
-Clarity is non-Turing complete, yet very expressive. This makes it so that Clarity is decidable and cannot encode uncomputable problems. There are discussions and papers on smart contract languages such as Solidity that propose subsets of Solidity that are non-Turing complete. These subsets are decidable and cannot encode uncomputable problems. However, there is no consensus on which subsets to work with and they are not widely used.
-
-### Advantages of Decidability in Smart Contracts
-
-Why is decidability important in the context of smart contracts?
-
-First, it is not possible for a Clarity call to run out of gas in the middle of a call. Because of its decidability, it is possible to get a complete static analysis of the call graph to get an accurate picture of the cost before execution.
-
-Solidity allows for unbounded loops, recursion, and dynamic function calls, which makes it difficult to accurately predict the execution cost or gas usage beforehand. As a result, Solidity contracts may run out of gas during execution if the gas limit is not set appropriately or if the contract encounters a scenario with unexpectedly high computational requirements.
-
-One practical example is the issue of a specific kind of DoS attack in Solidity, where the contract is rendered inoperable because of unbounded execution constraints. An example of this is the GovernMental attack, where a mapping that needed to be deleted for a payout became so large that working with it exceeded the block gas limit.
-
-There are a few different properties of Clarity's language design that prevents such DoS attacks.
-
-The reason that the analysis system can accurately estimate the execution cost is because certain functionality is intentionally limited in Clarity.
-
-For example, there is no recursion in Clarity, so we can't infinitely call into a function over and over.
-
-Data types in Clarity are also restricted. Any data types that don't require a hard length limit are not iterable.
-
-Maps and tuples, for example, do not require you to enter a maximum length when defining them, but you also can't iterate over them.
-
-Lists, on the other hand, which are iterable, do require the developer to define an upper limit when defining them. This is a large part of what allows an accurate static analysis of Clarity contracts.
-
-So how would we implement a mapping of an undefined size in Clarity? We wouldn't, because it's an anti-pattern in smart contract design.
-
-Instead, Clarity forces us to think of a better solution to our problem. For example, implementing a way for users to handle mapping/list element operations themselves, instead of mass operations handled at the contract level.
-
-If you [analyze the GovernMental attack](https://hackernoon.com/smart-contract-attacks-part-2-ponzi-games-gone-wrong-d5a8b1a98dd8#h-attack-2-call-stack-attack), you'll see that it took advantage of multiple security issues, all of which are mitigated in Clarity. You'll also see that a fix was added to make it economically infeasible to carry out this type of attack again.
-
-This brings up another crucial point when setting appropriate mental models for smart contracts and blockchain systems: complexity means more potential bugs, which means adding more complexity to address those bugs.
-
-When this happens over and over again, we are trapping ourselves into creating an evermore complex system. Addressing these issues at the language level prevents this ever-growing complexity.
-
-For a deep dive into how Clarity was designed, check out [SIP-002](https://github.com/stacksgov/sips/blob/main/sips/sip-002/sip-002-smart-contract-language.md).
-
-:::note You can view some more common smart contract vulnerabilities and how they are mitigated in [this article](https://stacks.org/bringing-clarity-to-8-dangerous-smart-contract-vulnerabilities/). :::
-
-This has second-order effects as well when we look at security testing and auditing. One of the common tools for testing smart contracts is formal verification, where we mathematically prove that certain properties of smart contracts will or will not remain true in all cases.
-
-This can lead to the path explosion problem, where there are so many paths available that formal verification becomes incredibly difficult. This problem is mitigated in Clarity, since there is not chance of a program encountering an unbounded loop.
-
-This leads us to a more general mental model for thinking about decidability as smart contracts continue to become a larger part of our economy. Remember that the goal with blockchain systems is to create an open, transparent, fair financial system.
-
-This means that smart contracts will be responsible for managing large amounts of wealth for ever-growing amounts of people. As smart contracts encompass more financial structures, their complexity and usage will grow.
-
-Complexity is the enemy of security. The more complex a system is, the more danger there is in creating uncomputable problems when there are no hard restrictions on the execution steps that can be taken.
-
-This is deadly in financial infrastructure that is not only open and transparent, but immutable. Let's explore this idea of uncomputability a bit more.
-
-### Intuition on Uncomputability
-
-Intuitively, uncomputability is an algorithmic view of undecidability. Uncomputability has the same foundations as undecidability. Undecidable questions are framed as logic statements or statements about integers. Of course, programs are logic statements and may even be viewed as integers, though we view programs differently. We often view programs with additional details of memory models, implementation details, and execution semantics.
-
-The [Halting problem](https://en.wikipedia.org/wiki/Halting\_problem): As an example, given any program `P` and any finite input `I` for `P`, then the Halting Problem is the challenge of determining if `P` halts on input `I`.
-
-Alonzo Church and Alan Turing showed the Halting Problem is unsolvable.
-
-Christopher Strachey gave an intuitive proof-by-contradiction showing the Halting problem is uncomputable. This is set up by supposing there is a program `H` that can solve the Halting problem for any program `P`. `H(P)` returns true if `P` halts and false otherwise. Then build a program `P` that does not halt when `H(P)` is true, giving a contradiction. Similarly, this program `P` halts when `H(P)` is false, also a contradiction.
-
-Uncomputable problems are problems that cannot be solved by an algorithm or a computer, no matter how much time or resources are provided. These problems exist in various forms, and one such example is the Post correspondence problem, which was proposed by Emil Post.
-
-The Post correspondence problem can be described using pairs of strings and an integer. Imagine you have n pairs of strings, called P. These strings are made up of characters from a character set, such as UTF-8 or any other alphabet with at least two symbols. The pairs of strings look like this:
-
-`P = { (x1, y1), (x2, y2), … , (xn, yn) }`
-
-Now, you also have an integer `m` that is greater than 0. The Post correspondence problem asks whether there is a way to create a list of indices `(i1, i2, …, im)` using the given pairs of strings. You can repeat these indices if needed, with one condition: when you combine the `x` strings from the pairs using the indices, the resulting string must be equal to the combined `y` strings from the same pairs using the same indices. In other words:
-
-`x(i1) x(i2) … x(im) = y(i1) y(i2) … y(im)`
-
-When developers try to solve the Post correspondence problem, they often attempt to use indeterminate loops (loops without a fixed number of iterations) rather than recursion. This is because the problem seems to require searching through different combinations of indices until a solution is found or it's proven that no solution exists.
-
-In simple terms, the Post correspondence problem involves trying to find a sequence of indices that, when applied to the given pairs of strings, produces equal concatenated strings from both the `x` and `y` components. This problem is considered uncomputable because there is no general algorithm that can solve it for all possible input pairs of strings and integers.
-
-It turns out, many questions about how programs behave are uncomputable. This has a number of consequences for smart contracts that are built in Turing complete languages, many of which we are not aware of yet but will surely become aware of as we encounter them in the future.
-
-### Raymond Smullyan’s Intuition on Undecidability
-
-This is a part of Raymond Smullyan’s approach to understanding undecidability in propositional logic. It uses meta-information to show something must be true, though it cannot be proved in propositional logic. This is based on a paradox.
-
-In propositional logic, a logical statement is undecidable if we cannot prove it true or false. Given a propositional logic statement S, a proof is a sequence of formal logical deductions, starting from basic facts and ending by indicating if S is true or false.
-
-Smullyan’s starts with an island of Knights and Knaves. Knights always tell the truth. Knaves always lie. We cannot distinguish islanders otherwise.
-
-There is a great logician named Ray. Whatever Ray proves is true. This is just like a good theorem prover.
-
-An islander Jack proclaims: “You cannot prove I am a Knight” to the logician Ray.
-
-The next reasoning is based on meta-knowledge of this situation. This meta-knowledge shows that some problems are undecidable in propositional logic.
-
-If Ray can prove Jack is a Knight, then Jack must be a Knave, since Jack must have lied. That is because Ray proved Jack is a Knight. Since Jack is a Knave, Ray’s proof contradicts the assumption that Ray only proves true things. So, this case cannot hold.
-
-If Ray cannot prove Jack is a Knight, then Jack must be a Knight, since Jack stated the truth. But Ray cannot prove the fact that Jack is a Knight.
-
-In the context of smart contracts and programming languages, Turing complete languages like Solidity come with the possibility of undecidable problems.
-
-These undecidable problems are similar to the paradox presented in the Knights and Knaves story, where it's impossible to determine whether Jack is a Knight or a Knave based on the given information.
-
-In the Knights and Knaves story, Ray is analogous to a theorem prover or a smart contract in a Turing complete language. Ray is faced with a statement that is undecidable within the constraints of the system (Knights and Knaves), which leads to a paradox.
-
-Similarly, a Turing complete smart contract language might face undecidable problems that can't be resolved, leading to unexpected behavior, vulnerabilities, or resource consumption issues (like running out of gas in Ethereum).
-
-On the other hand, non-Turing complete languages like Clarity are designed to avoid undecidable problems by limiting their expressiveness.
-
-In the context of the Knights and Knaves story, a non-Turing complete language would simply not allow Jack to make a statement that could lead to a paradox. By disallowing certain features like unbounded loops and recursion, non-Turing complete languages can provide stronger guarantees about the behavior and resource usage of smart contracts.
-
-This predictability is desirable in many cases, especially when dealing with high-value transactions or critical systems.
-
-### Reference
-
-The Mathematics of Various Entertaining Subjects: Research in Recreational Math Illustrated Edition, Jennifer Beineke (Editor), Jason Rosenhouse (Editor), Raymond M. Smullyan (Foreword), Princeton University Press, 2016.
diff --git a/concepts/clarity/overview.md b/concepts/clarity/overview.md
deleted file mode 100644
index 35fc7ed507..0000000000
--- a/concepts/clarity/overview.md
+++ /dev/null
@@ -1,53 +0,0 @@
-# Overview
-
-Clarity is a **decidable** smart contract language that optimizes for predictability and security, designed for the Stacks blockchain. Smart contracts allow developers to encode essential business logic on a blockchain.
-
-The design decisions behind Clarity were based heavily on taking lessons learned in common Solidity exploits and creating a language that has been purpose-built for safety and security in mind.
-
-These docs serve primarily as a reference for the functions and keywords that you can use in Clarity.
-
-In order to learn Clarity, we recommend diving into the [Clarity of Mind](https://book.clarity-lang.org/), an online book to teach you everything you need to know to build robust smart contracts, or joining a [Clarity Camp](https://clarity-lang.org/universe#camp), the cohort-based immersive Clarity experience.
-
-### What makes Clarity different
-
-The following section is an excerpt from the excellent book, [Clarity of Mind](https://book.clarity-lang.org/ch00-00-introduction.html):
-
-The number of smart contract languages grows by the year. Choosing a first language can be challenging, especially for a beginner. The choice is largely dictated by the ecosystem you are interested in, although some languages are applicable to more than just one platform. Each language has its own upsides and downsides and it is out of the scope of this book to look at all of them. Instead, we will focus on what sets Clarity apart and why it is a prime choice if you require the utmost security and transparency.
-
-One of the core precepts of Clarity is that it is secure by design. The design process was guided by examining common pitfalls, mistakes, and vulnerabilities in the field of smart contract engineering as a whole. There are countless real world examples of where developer failure led to the loss or theft of vast amounts of tokens. To name two big ones: an issue that has become known as the Parity bug led to the irreparable loss of millions of dollars worth of Ethereum. Second, the hacking of The DAO (a "Decentralized Autonomous Organization") caused financial damage so great that the Ethereum Foundation decided to issue a contentious hard fork that undid the theft. These and many other mistakes could have been prevented in the design of the language itself.
-
-#### Clarity is interpreted, not compiled
-
-Clarity code is interpreted and committed to the chain exactly as written. Solidity and other languages are compiled to byte-code before it is submitted to the chain. The danger of compiled smart contract languages is two-fold: first, a compiler adds a layer of complexity. A bug in the compiler may lead to different byte-code than was intended and thus carries the risk of introducing a vulnerability. Second, byte-code is not human-readable, which makes it very hard to verify what the smart contract is actually doing. Ask yourself, would you sign a contract you cannot read? If your answer is no, then why should it be any different for smart contracts? With Clarity, what you see is what you get.
-
-#### Clarity is decidable
-
-A decidable language has the property that from the code itself, you can know with certainty what the program will do. This avoids issues like the halting problem. With Clarity you know for sure that given any input, the program will halt in a finite number of steps. In simple terms: it is guaranteed that program execution will end. Decidability also allows for complete static analysis of the call graph so you get an accurate picture of the exact cost before execution. There is no way for a Clarity call to "run out of gas" in the middle of the call. We explore this idea more, along with a discussion on Turing completeness, in the security deep dive on decidability.
-
-#### Clarity does not permit reentrancy
-
-Reentrancy is a situation where one smart contract calls into another, which then calls back into the first contract—the call "re-enters" the same logic. It may allow an attacker to trigger multiple token withdrawals before the contract has had a chance to update its internal balance sheet. Clarity's design considers reentrancy an anti-feature and disallows it on the language level.
-
-#### Clarity guards against overflow and underflows
-
-Overflows and underflows happen when a calculation results in a number that is either too large or too small to be stored, respectively. These events throw smart contracts into disarray and may intentionally be triggered in poorly written contracts by attackers. Usually this leads to a situation where the contract is either frozen or drained of tokens. Overflows and underflows of any kind automatically cause a transaction to be aborted in Clarity.
-
-#### Support for custom tokens is built-in
-
-Issuance of custom fungible and non-fungible tokens is a popular use-case for smart contracts. Custom token features are built into the Clarity language. Developers do not need to worry about creating an internal balance sheet, managing supply, and emitting token events. Creating custom tokens is covered in depth in later chapters.
-
-#### On Stacks, transactions are secured by post conditions
-
-In order to further safeguard user tokens, post conditions can be attached to transactions to assert the chain state has changed in a certain way once the transaction has completed. For example, a user calling into a smart contract may attach a post condition that states that after the call completes, exactly 500 STX should have been transferred from one address to another. If the post condition check fails, then the entire transaction is reverted. Since custom token support is built right into Clarity, post conditions can also be used to guard any other token in the same way.
-
-#### Returned responses cannot be left unchecked
-
-Public contract calls must return a so-called response that indicates success or failure. Any contract that calls another contract is required to properly handle the response. Clarity contracts that fail to do so are invalid and cannot be deployed on the network. Other languages like Solidity permit the use of low level calls without requiring the return value to be checked. For example, a token transfer can fail silently if the developer forgets to check the result. In Clarity it is not possible to ignore errors, although that obviously does prevent buggy error handling on behalf of the developer. Responses and error handling are covered extensively in the chapters on functions and control flow.
-
-#### Composition over inheritance
-
-Clarity adopts a composition over inheritance. It means that Clarity smart contracts do not inherit from one another like you see in languages like Solidity. Developers instead define traits which are then implemented by different smart contracts. It allows contracts to conform to different interfaces with greater flexibility. There is no need to worry about complex class trees and contracts with implicit inherited behavior.
-
-#### Access to the base chain: Bitcoin
-
-Clarity smart contracts can read the state of the Bitcoin base chain. It means you can use Bitcoin transactions as a trigger in your smart contracts! Clarity also features a number of built-in functions to verify secp256k1 signatures and recover keys.
diff --git a/concepts/gaia/README.md b/concepts/gaia/README.md
deleted file mode 100644
index c5050c00f6..0000000000
--- a/concepts/gaia/README.md
+++ /dev/null
@@ -1,82 +0,0 @@
-# Gaia
-
-Apps built with the Stacks blockchain can store off-chain data using a storage system called Gaia.
-
-Gaia is a unique approach to decentralized storage that focuses primarily on user-ownership of data, rather than immutable on-chain storage. The emphasis here is on user control.
-
-While on-chain storage solutions like IPFS and Arweave are designed for immutable, censorship-resistant permanent storage, they cannot be deemed as providing user control of the data since the user cannot modify or remove the data once it has been deployed.
-
-Gaia solves a different problem of allowing users to be in control of where their data is stored while connecting the access of that data to their on-chain Stacks identity.
-
-Whereas public transactional metadata is best stored on the Stacks blockchain, user application data can often be stored more efficiently and privately in Gaia storage.
-
-Storing data off of the blockchain ensures that Stacks applications can provide users with high performance and high availability for data reads and writes without introducing central trust parties.
-
-### Understand Gaia in the Stacks architecture
-
-The following diagram depicts the Stacks architecture and Gaia's place in it:
-
-Blockchains require consensus among large numbers of people, so they can be slow. Additionally, a blockchain is not designed to hold a lot of data. This means using a blockchain for every bit of data a user might write and store is expensive. For example, imagine if an application were storing every tweet in the chain.
-
-The Stacks blockchain addresses performance problems using a layered approach. The base layer consists of the Stacks blockchain and the Blockchain Naming System (BNS). The blockchain governs ownership of identities in the Stacks network. Identities can be names such as domain names, usernames, or application names.
-
-When an identity is created, its creation is recorded in the Stacks blockchain. Identities make up the primary data stored into the Stacks blockchain. These identities correspond to routing data in the OSI stack. The routing data is stored in the Atlas Peer Network, the second layer. Every core node that joins the Stacks Network is able to obtain an entire copy of this routing data. Stacks uses the routing data to associate identities (domain names, user names, and application names) with a particular storage location in the final layer, the Gaia Storage System.
-
-A Gaia Storage System consists of a _hub service_ and storage resource on a cloud software provider. The storage provider can be any commercial provider such as Azure, DigitalOcean, Amazon EC2, and so forth. Typically the compute resource and the storage resource reside same cloud vendor, though this is not a requirement. Gaia currently has driver support for S3, Azure Blob Storage, Google Cloud Platform and local disk, but the driver model allows for other backend support as well.
-
-Gaia stores data as a simple key-value store. When an identity is created, a corresponding data store is associated with that identity on Gaia. When a user logs into a dApp, the authentication process gives the application the URL of a Gaia hub, which then writes to storage on behalf of that user.
-
-The Stacks blockchain stores only identity data. Data created by the actions of an identity is stored in a Gaia Storage System. Each user has profile data. When a user interacts with a decentralized dApp that application stores application data on behalf of the user. Because Gaia stores user and application data off the blockchain, a Stacks DApp is typically more performant than DApps created on other blockchains.
-
-### User control or how is Gaia decentralized?
-
-A Gaia hub runs as a service which writes to data storage. The storage itself is a simple key-value store. The hub service writes to data storage by requiring a valid authentication token from a requestor. Typically, the hub service runs on a compute resource and the storage itself on separate, dedicated storage resource. Typically, both resources belong to the same cloud computing provider.
-
-Gaia's approach to decentralization focuses on user control of data and its storage. Users can choose a Gaia hub provider. If a user can choose which Gaia hub provider to use, then that choice is all the decentralization required to enable user-controlled applications. Moreover, Gaia defines a uniform API for applications to access that data.
-
-The control of user data lies in the way that user data is accessed. When an application fetches a file `data.txt` for a given user `alice.id`, the lookup will follow these steps:
-
-1. Fetch the `zonefile` for `alice.id`.
-2. Read her profile URL from her `zonefile`.
-3. Fetch Alice's profile.
-4. _Verify_ that the profile is signed by `alice.id`'s key
-5. Find the read-only url out of the profile's `appsMeta` section (e.g. `https://example-app.gaia.alice.org`).
-6. Fetch the file from `https://example-app.gaia.alice.org/data.txt`.
-
-Because `alice.id` has access to her [zonefile](https://docs.stacks.co/references/bns-contract#name-update), she can change where her profile is stored. For example, she may do this if the current profile's service provider or storage is compromised. To change where her profile is stored, she changes her Gaia hub URL to another Gaia hub URL. If a user has sufficient compute and storage resources, a user may run their own Gaia Storage System and bypass a commercial Gaia hub provider all together.
-
-{% hint style="warning" %}
-Users with existing identities cannot yet migrate their data from one hub to another.
-{% endhint %}
-
-Applications writing directly on behalf of `alice.id` do not need to perform a lookup. Instead, the [Stacks authentication flow](https://stacks.js.org) provides Alice's chosen gaia hub URL to the application. This authentication flow _is also_ within Alice's control because Alice's wallet _must_ generate the authentication response.
-
-### Understand data storage
-
-A Gaia hub stores the written data _exactly_ as given. It offers minimal guarantees about the data. It does not ensure that data is validly formatted, contains valid signatures, or is encrypted. Rather, the design philosophy is that these concerns are client-side concerns.
-
-Client libraries (such as [`Stacks.js`](https://stacks.js.org/)) are capable of providing these guarantees. A liberal definition of the [end-to-end principle](https://en.wikipedia.org/wiki/End-to-end\_principle) guides this design decision.
-
-When an application writes to a Gaia hub, an authentication token, key, and the data are passed to the Gaia hub.
-
-The token ensures the app has the authorization to write to the hub on the user's behalf.
-
-### Gaia versus other storage systems
-
-Here's how Gaia stacks up against other decentralized storage systems. Features that are common to all storage systems are omitted for brevity.
-
-| Features | [Gaia](https://github.com/stacks-network/gaia) | [Sia](https://sia.tech/) | [Storj](https://storj.io/) | [IPFS](https://ipfs.io/) | [DAT](https://datproject.org/) | [SSB](https://www.scuttlebutt.nz/) |
-| ------------------------------------------ | ---------------------------------------------- | ------------------------ | -------------------------- | ------------------------ | ------------------------------ | ---------------------------------- |
-| User controls where data is hosted | X | | | | | |
-| Data can be viewed in a normal Web browser | X | | | X | | |
-| Data is read/write | X | | | | X | X |
-| Data can be deleted | X | | | | X | X |
-| Data can be listed | X | X | X | | X | X |
-| Deleted data space is reclaimed | X | X | X | X | | |
-| Data lookups have predictable performance | X | | X | | | |
-| Writes permission can be delegated | X | | | | | |
-| Listing permission can be delegated | X | | | | | |
-| Supports multiple backends natively | X | | X | | | |
-| Data is globally addressable | X | X | X | X | X | |
-| Needs a cryptocurrency to work | | X | X | | | |
-| Data is content-addressed | | X | X | X | X | X |
diff --git a/concepts/gaia/amazon-ec2.md b/concepts/gaia/amazon-ec2.md
deleted file mode 100644
index a11f0b0620..0000000000
--- a/concepts/gaia/amazon-ec2.md
+++ /dev/null
@@ -1,88 +0,0 @@
-# Amazon EC2
-
-### Introduction
-
-The template provided on this page provides an easy way to deploy a Gaia hub directly to Amazon EC2. You can use this template to deploy your own Gaia hub to your Amazon Web Services (AWS) account. Amazon EC2 is an affordable and convenient cloud computing provider. The template provides a one-click deploy for Amazon EC2 with either S3 or EBS as a storage provider.
-
-### Prerequisites
-
-This procedure uses Amazon CloudFormation to configure an EC2 cloud compute provider to run the Gaia hub service with an S3 or EBS provider for file storage. You should have access to an AWS account either through your personal account or through a corporate account. This account should have permissions to create resources.
-
-Additionally, you must also own a domain name and be able to update the DNS records associated with that domain name.
-
-### Setup steps
-
-#### Step 1 - Create Stack
-
-Use a link in the table to launch the [CloudFormation](https://console.aws.amazon.com/cloudformation/) template in the AWS region that you wish to deploy a Gaia hub.
-
-#### Step 2 - Setup stack using template
-
-You need to configure the template with the appropriate values for your hub and domain it runs on.
-
-Select `Template is ready` and `Amazon S3 URL` and enter the following Amazon S3 URL:
-
-```
-https://s3-external-1.amazonaws.com/cf-templates-vzldibfi2mw8-us-east-1/2022160J6G-cloudformation.yaml
-```
-
-If you prefer you can instead select `Template is ready` and `Upload a template file` to upload the template file `cloudformation.yaml`.
-
-The latest `cloudformation.yaml` file can be downloaded [here](https://raw.githubusercontent.com/stacks-network/gaia/master/deploy/cloudformation.yaml). On most browsers you can right-click on that page and click on `Save page as` to download the file. Alternatively, you can copy/paste the text into a text file called `cloudformation.yaml`.
-
-Then click `Next`.
-
-#### Step 3 - Specify stack details
-
-Specify the stack details and then click `Next`:
-
-| Field | Value | Notes |
-| --------------- | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| Stack name | _a unique name in your AWS account_ | e.g.: my\_gaia\_hub |
-| DomainName | _your-domain_ | |
-| EmailAddress | _your email address_ | |
-| GaiaBucketName | _S3 bucket name_ | The template combines this name with the stack name to create a unique S3 bucket. The template ignores this field if GaiaStorageType is set to `disk`. |
-| GaiaStorageType | `s3` or `disk` | Select the GaiaStorageType of which to use as a backend for the Gaia Hub. Selecting `s3` causes the template to create an S3 bucket based on the name given in the previous field. Selecting `disk` causes the template to attach a separate EBS volume to the EC2 instance for Hub storage. |
-| InstanceType | t2.micro | Select the instance type you want. Default value is `t2.micro`. |
-| KeyName | | In the KeyName drop-down, select an [EC2 KeyPair](https://console.aws.amazon.com/ec2/v2/home?region=us-east-1#KeyPairs:) to enable SSH access to the EC2 instance. You should download the `.pem` keyfile for this pair from the EC2 console. For more information see the [EC2 key pair documentation](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html#prepare-key-pair) |
-| SSHLocation | 0.0.0.0/0 | Leave the SSHLocation field with the default value of `0.0.0.0/0` to enable SSH access from any IP address. If you wish to restrict SSH access to the EC2 instance to a certain IP, you can update this field. |
-| SubnetId | _subnetid_ | Select a public subnet |
-| VpcId | _vpcid_ | |
-
-#### Step 4 - Configure stack options
-
-Configure any stack options that fit your desired setup and click `Next`. All these fields are optional.
-
-#### Step 5 - Review
-
-Review the configuration of your Gaia hub, select the checkbox to acknowledge that AWS may create IAM resources with custom names and click on `Create stack`.
-
-#### Step 6 - Retrieve the public IP of your Gaia hub
-
-Your stack can take several minutes to launch. You can monitor the Events tab of your hub to review the current progress of the launch. When the launch is complete, the Outputs tab displays information about the hub. Select the PublicIP and copy it to configure your domain name.
-
-Create an `A` DNS record pointing to the given IP in your domain.
-
-Wait a few minutes for the DNS record to propagate, and your should be able to access your Gaia hub with SSH.
-
-### Accessing your Gaia hub with SSH
-
-To SSH into your Gaia hub EC2 host directly, you must have the keyfile used in container creation. Access the host with the following command in your terminal:
-
-```bash
-ssh -i admin@
-```
-
-:::tip If you can only access SSH with the IP but not with the DNS name and you wish to do so, you can optionally activate it by following these steps:
-
-```
-Open your [AWS Console](https://console.aws.amazon.com)
-Click on `Service` -> VPC
-Open Your VPCs
-Select your VPC connected to your Gaia Hub
-Click `Actions` -> `Edit DNS Hostnames` -> Change `DNS hostnames` to `Enable`
-```
-
-:::
-
-### Graphical representation of the cloudformation template
diff --git a/concepts/gaia/configuration.md b/concepts/gaia/configuration.md
deleted file mode 100644
index 8d45d6939d..0000000000
--- a/concepts/gaia/configuration.md
+++ /dev/null
@@ -1,69 +0,0 @@
-# Configuration
-
-### Configuration files
-
-The following configuration files exist in the folder `deploy/configs/gaia/`:
-
-```
-admin-config.json
-hub-config.json
-reader-config.json
-```
-
-### GAIA Admin Service
-
-You can also use the GAIA Admin Service to remotely administer it with an API Key. It will require you to install `npm` with a `apt install npm`. Once `npm` is installed you can continue with the steps in the [GAIA Admin Service](https://github.com/stacks-network/gaia/blob/master/admin/README.md).
-
-### Driver Selection
-
-The Gaia hub currently supports the following drivers:
-
-```
-'aws' == Amazon S3
-'azure' == Azure Blob Storage
-'disk' == Local disk
-'google-cloud' === Google Cloud Storage
-```
-
-Set the driver you wish to use in your [config.json](https://github.com/stacks-network/gaia/blob/master/hub/config.sample.json) file with the `driver` parameter. Many drivers additionally accept the `bucket` parameter, which controls the bucket name that files should be written to.
-
-These driver may require you to provide additional credentials for performing writes to the backends. See `config.sample.json` for fields for those credentials. In some cases, the driver can use a system configured credential for the backend (e.g., if you are logged into your AWS CLI account, and run the hub from that environment, it won't need to read credentials from your `config.json`).
-
-:::caution The disk driver requires a \*nix like filesystem interface, and will not work correctly when trying to run in a Windows environment. :::
-
-### Note on SSL
-
-We _strongly_ recommend that you deploy your Gaia hub with SSL enabled. Otherwise, the tokens used to authenticate with the Gaia hub may be stolen by attackers, which could allow them to execute writes on your behalf.\
-Configuration options are available to run the hub with an `https` Node.js server.\
-Otherwise, a reverse proxy web server such as nginx or Apache can be used.
-
-### Require Correct Hub URL
-
-If you turn on the `requireCorrectHubUrl` option in your `config.json` file, your Gaia hub will require that authentication requests correctly include the `hubURL` they are trying to connect with. This is used to prevent a malicious gaia hub from using an authentication token for itself on other Gaia hubs.
-
-By default, the Gaia hub will validate that the supplied URL matches `https://${config.serverName}`, but if there are multiple valid URLs for clients to reach the hub at, you can include a list in your `config.json`:
-
-```javascript
-{
- ....
- serverName: "normalserver.com"
- validHubUrls: [ "https://specialserver.com/",
- "https://legacyurl.info" ]
- ....
-}
-```
-
-### The readURL parameter
-
-By default, the gaia hub drivers will return read URLs which point directly at the written content. For example, an S3 driver would return the URL directly to the S3 file. However, if you configure a CDN or domain to point at that same bucket, you can use the `readURL` parameter to tell the gaia hub that files can be read from the given URL. For example, the `hub.blockstack.org` Gaia Hub is configured to return a read URL that looks like `https://gaia.blockstack.org/hub/`.
-
-Unset this configuration parameter if you do not intend to deploy any caching.
-
-### Minimum Proofs Requirement
-
-The gaia hub can also be configured to require a minimum number of social proofs in a user's profile to accept writes from that user. This can be used as a kind of spam-control mechanism. However, we recommend for the smoothest operation of your gaia hub, to set the `proofsConfig.proofsRequired` configuration key to `0`.
-
-### CDN & Replicated Hubs
-
-* https://docs.microsoft.com/en-us/azure/storage/blobs/storage-https-custom-domain-cdn
-* The hub implementation is designed to be ran from a single Node.js instance. If the hub instance is sharded (e.g. replicated hubs via load balancing), then any given `bucket` (identified by URI segment) must be served by the same instance, At least a couple elements of the Gaia Hub depend on this: token invalidation in-memory caching, and resource endpoint 409 contention behavior.
diff --git a/concepts/gaia/deploy-gaia-hub.md b/concepts/gaia/deploy-gaia-hub.md
deleted file mode 100644
index 8a58f8f1fc..0000000000
--- a/concepts/gaia/deploy-gaia-hub.md
+++ /dev/null
@@ -1,12 +0,0 @@
-# Deploy Gaia Hub
-
-### Deploy your GAIA hub
-
-Tutorials to deploy your own GAIA hub are currently available for Linux, MacOS and Amazon EC2 / CloudFormation.
-
-Regardless of what server the Gaia Hub runs on, the storage it uses can currently be deployed on multiple platforms:
-
-* Local disk (the server itself)
-* Amazon S3
-* Azure Blob Storage
-* Google Cloud
diff --git a/concepts/gaia/linux.md b/concepts/gaia/linux.md
deleted file mode 100644
index ebfe40df8f..0000000000
--- a/concepts/gaia/linux.md
+++ /dev/null
@@ -1,121 +0,0 @@
-# Linux
-
-This configuration will setup the following 4 docker containers:
-
-* Nginx with certbot on TCP ports 80 and 443.
-* Gaia hub on TCP port 3000.
-* Gaia admin on TCP port 8009.
-* Gaia reader on TCP port 8008
-
-**1. Update the system and install the dependencies and software we will use to test:**
-
-```bash
-apt update && apt upgrade -y && apt install -y git vim gnupg jq
-```
-
-**2. Install** [**docker**](https://docs.docker.com/engine/install/debian/) **and** [**docker-compose**](https://docs.docker.com/compose/cli-command/#install-on-linux) in your OS. For our example we install _docker_ with:
-
-```bash
-curl -fsSL https://download.docker.com/linux/debian/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
-
-echo \
- "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/debian \
- $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
-
-apt update && apt install -y docker-ce docker-ce-cli containerd.io
-```
-
-Install _docker-compose_ by downloading the [latest-release](https://github.com/docker/compose/releases):
-
-```bash
-VERSION_DC=$(curl --silent https://api.github.com/repos/docker/compose/releases/latest | jq .name -r)
-DESTINATION_DC=~/.docker/cli-plugins
-mkdir -p ${DESTINATION_DC}
-curl -SL https://github.com/docker/compose/releases/download/${VERSION_DC}/docker-compose-linux-x86_64 -o ${DESTINATION_DC}/docker-compose
-chmod +x ${DESTINATION_DC}/docker-compose
-```
-
-**3. Clone the GAIA repository** and enter it's docker directory.
-
-```bash
-git clone https://github.com/stacks-network/gaia.git && cd gaia/deploy/docker
-```
-
-**4. Copy and edit appropriate .env file**. In the folder `./deploy/docker/` they are different sample files for different configurations like using aws, azure or disk among others. In this example we will store the data locally so we will copy the _disk_ file and update the domain and email fields. Please change `gaia.site.com` and `gaiarocks@mydomain.com` accordingly. Note you need both for the SSL certificate to be created correctly.
-
-```bash
-export MYGAIADOMAIN=gaia.site.com
-export MYGAIAEMAIL=gaiarocks@mydomain.com
-cp sample-disk.env disk.env
-sed -i 's/my-domain.com/'"$MYGAIADOMAIN"'/g' disk.env
-sed -i 's/my-email@example.com/'"$MYGAIAEMAIL"'/g' disk.env
-
-```
-
-**5. Start GAIA HUB service**
-
-To start GAIA HUB
-
-```bash
-./gaiahub.sh start
-```
-
-To stop GAIA HUB
-
-```bash
-./gaiahub.sh stop
-```
-
-To view GAIA HUB status
-
-```bash
-./gaiahub.sh status
-```
-
-**6. Verify server works locally** with the following command:
-
-```bash
-curl -sk http://localhost/hub_info | jq
-```
-
-A correct result should look similar to this:
-
-```bash
- {
- "challenge_text": "[\"gaiahub\",\"0\",\"gaia-0\",\"blockstack_storage_please_sign\"]",
- "latest_auth_version": "v1",
- "max_file_upload_size_megabytes": 20,
- "read_url_prefix": "https://gaia.site.com/reader/"
- }
-```
-
-**7. Test your GAIA HUB** Running `gaia_test.js` will test your GAIA Hub, by trying to connect to it, uploading a file and downloading it again.
-
-First install all required dependencies with:
-
-```bash
-npm install
-```
-
-Then, from the root folder of the project type:
-
-```bash
-node ./deploy/gaia_test.js https://yourgaiaurl
-```
-
-A correct result will be something like this:
-
-```
-Will run a test for the GAIA HUB: https://gaia.mydomain.com
-Generating some test keys...
-Private key: 5aacc60fc2a429e1f02be139f3cac82061c6a980********************
-Public key: 025691f17f2ab80dc4af363bb9c7aac59e9e1db6ae8ff668202582a3f4ec9678ff
-Address: 15n8Xo8acRvSZghJG2dxJ8dCdzDMYicUuS
-[DEBUG] connectToGaiaHub: https://gaia.mydomain.com/hub_info
-[DEBUG] uploadToGaiaHub: uploading testing.txt to https://gaia.mydomain.com
-File uploaded successfully.
-Upload to gaia hub thinks it can read it from: https://gaia.mydomain.com/reader/15n8Xo8acRvSZghJG2dxJ8dCdzDMYicUuS/testing.txt
-Hub info thinks it can read it from : https://gaia.mydomain.com/reader/15n8Xo8acRvSZghJG2dxJ8dCdzDMYicUuS/testing.txt
-Let's now try to fetch the uploaded file...
-File fetched successfully. Contents of file: GAIA ROCKS!
-```
diff --git a/concepts/gaia/mac-os.md b/concepts/gaia/mac-os.md
deleted file mode 100644
index 00be60dccc..0000000000
--- a/concepts/gaia/mac-os.md
+++ /dev/null
@@ -1,76 +0,0 @@
-# Mac OS
-
-The following assumes you have [Docker Installed](https://docs.docker.com/docker-for-mac/install/)
-
-* Recommended to also have [MacOS Homebrew](https://docs.brew.sh/Installation) installed
-* Use Homebrew to install jq with `brew install jq`
-
-In your working directory:
-
-**1. Clone a copy of the** [**gaia repo**](https://github.com/stacks-network/gaia)**:**
-
-```bash
-$ git clone -b master --single-branch https://github.com/stacks-network/gaia
-```
-
-**2. Change your cwd:**
-
-```bash
-$ cd gaia/deploy/docker
-```
-
-**3. Create a copy of sample-disk.env and fill out the values:**
-
-```
-$ cp sample-disk.env disk.env
-# Update the DOMAIN_NAME variable to `localhost`
-```
-
-**4. Start the server:**
-
-```
-$ docker-compose -f docker-compose-base.yaml -f docker-compose-disk.yaml --env-file disk.env up
-```
-
-**5. Verify the server is responding locally:**
-
-```
-$ curl -sk https://localhost/hub_info | jq
- {
- "challenge_text": "[\"gaiahub\",\"0\",\"gaia-0\",\"blockstack_storage_please_sign\"]",
- "latest_auth_version": "v1",
- "max_file_upload_size_megabytes": 20,
- "read_url_prefix": "https://localhost/reader/"
- }
-```
-
-#### Modifying the configuration for your gaia-hub
-
-Two methods exist:
-
-1. Edit the `gaia/deploy/configs/gaia/hub-config.json` using `vim` or other
-
-* requires a restart of the containers: `docker-compose -f docker-compose-base.yaml -f docker-compose-disk.yaml --env-file disk.env restart`
-
-2. Use the running `admin` container to modify any config values, and also reload the hub when complete:
-
-* [GitHub - Gaia Admin README.md](https://github.com/stacks-network/gaia/blob/master/admin/README.md)
-
-```
-$ export API_KEY="hello"
-$ curl -s \
- -H "Authorization: bearer $API_KEY" \
- -H 'Content-Type: application/json' \
- -X POST \
- --data-raw '{"serverName": "myserver"}' \
- http://localhost:8009/v1/admin/config
-
-$ curl -s \
- -H "Authorization: bearer $API_KEY" \
- -X POST \
- http://localhost:8009/v1/admin/reload
-
-$ curl -s \
- -H "Authorization: bearer $API_KEY" \
- http://localhost:8009/v1/admin/config | jq
-```
diff --git a/concepts/network-fundamentals/README.md b/concepts/network-fundamentals/README.md
deleted file mode 100644
index 9cbb5d7a9e..0000000000
--- a/concepts/network-fundamentals/README.md
+++ /dev/null
@@ -1,5 +0,0 @@
-# Network Fundamentals
-
-Now that you have a high-level understanding of what Stacks is and how it works, let's dive into some more details of all of the components that make up the Stacks Bitcoin L2.
-
-We're going to start with the basics of how the network is actually structured and the components that comprise it.
diff --git a/concepts/network-fundamentals/accounts.md b/concepts/network-fundamentals/accounts.md
deleted file mode 100644
index 69102ccaf6..0000000000
--- a/concepts/network-fundamentals/accounts.md
+++ /dev/null
@@ -1,98 +0,0 @@
-# Accounts
-
-### Introduction
-
-Stacks uses an accounts-based model, more similar to Ethereum, rather than a [UTXO](https://learnmeabitcoin.com/technical/transaction/utxo/) model like Bitcoin. In a UTXO model, the network operates as a ledger, with each UTXO being analagous to a cash bill.
-
-With an accounts-based model, each account is associated with a balance and that balance can be added to or subtracted from.
-
-Stacks accounts are entities that own assets, like Stacks (STX) tokens. An account has an address, private key, nonce, and one or more asset balances.
-
-{% hint style="info" %}
-The cryptographic signature algorithm used in Stacks is [**secp256k1**](https://en.bitcoinwiki.org/wiki/Secp256k1).
-
-Additionally, [Ed25519](https://ed25519.cr.yp.to/) is also used just for the VRF (Verifiable Random Function).
-{% endhint %}
-
-Assets cannot leave an account without an action from the account owner. All changes to assets (and the balances of the account) require a corresponding transaction.
-
-{% hint style="info" %}
-The transaction type doesn't need to be a token transfer - contract deploy and contract call transactions can change the balances of an account
-{% endhint %}
-
-### Creation
-
-An account is generated from a 24-word mnemonic phrase. This is often referred to as the **seed phrase**. The seed phrase provides access to Stacks accounts.
-
-{% hint style="danger" %}
-If the seed phrase is lost, access to the associated account cannot be restored. No person or organization can recover a lost seed phrase.
-{% endhint %}
-
-The easiest way to generate a new Stacks account is to use the [Stacks CLI](https://github.com/hirosystems/stacks.js/tree/master/packages/cli):
-
-```bash
-# install CLI globally
-npm install --global @stacks/cli
-
-# generate a new account and store details in a new file
-# '-t' option makes this a testnet account
-stx make_keychain -t > cli_keychain.json
-```
-
-`make_keychain` creates the following file:
-
-```js
-{
- "mnemonic": "aaa bbb ccc ddd ...",
- "keyInfo": {
- "privateKey": "5a3f1f15245bb3fb...",
- "address": "STJRM2AMVF90ER6G3RW1QTF85E3HZH37006D5ER1",
- "btcAddress": "biwSd6KTEvJcyX2R8oyfgj5REuLzczMYC1",
- "wif": "L4HXn7PLmzoNW...",
- "index": 0
- }
-}
-```
-
-{% hint style="info" %}
-Check out the [Stacks CLI reference](https://docs.hiro.so/references/stacks-cli) for more details
-{% endhint %}
-
-| Field | Description |
-| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| `mnemonic` | A 24-word seed phrase used to access the account, generated using [BIP39](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) with 256 bits of entropy |
-| `keyInfo.privateKey` | Private key for the account. Required for token transfers and often referred to as `senderKey` |
-| `keyInfo.address` | Stacks address for the account |
-| `keyInfo.btcAddress` | Corresponding BTC address for the account. |
-| `keyInfo.wif` | Private key of the btcAddress in compressed format. |
-| `keyInfo.index` | Nonce for the account, starting at 0 |
-
-Note that a new account automatically exists for each new private key. There is no need to manually instantiate an account on the Stacks blockchain.
-
-{% hint style="info" %}
-Addresses are created by generating the [RIPEMD-160 hash](https://en.wikipedia.org/wiki/RIPEMD#RIPEMD-160\_hashes) of the [SHA256](https://en.bitcoinwiki.org/wiki/SHA-256) of the public key. BTC addresses are encoded with [Base58Check](https://en.bitcoin.it/wiki/Base58Check\_encoding). For Stacks addresses, [c32check](https://github.com/stacks-network/c32check) is used. Deriving an address from a public key can be done without internet access, for instance using the c32check `c32addressDecode` method.
-{% endhint %}
-
-Alternatively to the CLI creation, the [Stacks Transactions JS](https://github.com/hirosystems/stacks.js/tree/master/packages/transactions) library can be used:
-
-```js
-import {
- makeRandomPrivKey,
- privateKeyToString,
- getAddressFromPrivateKey,
- TransactionVersion,
- getPublicKey,
-} from "@stacks/transactions";
-
-const privateKey = makeRandomPrivKey();
-
-// Get public key from private
-const publicKey = getPublicKey(privateKey);
-
-const stacksAddress = getAddressFromPrivateKey(
- privateKeyToString(privateKey),
- TransactionVersion.Testnet // remove for Mainnet addresses
-);
-```
-
-Finally, you can generate new account using a Stacks-enabled wallet like [Leather](https://leather.io/), [Xverse](https://www.xverse.app/), or [Asigna](https://asigna.io/).
diff --git a/concepts/network-fundamentals/authentication.md b/concepts/network-fundamentals/authentication.md
deleted file mode 100644
index 84070b2d62..0000000000
--- a/concepts/network-fundamentals/authentication.md
+++ /dev/null
@@ -1,85 +0,0 @@
-# Authentication
-
-### Introduction
-
-This guide explains how authentication is performed on the Stacks blockchain.
-
-Authentication provides a way for users to identify themselves to an app while retaining complete control over their credentials and personal details.
-
-Users who register for your app can subsequently authenticate to any other app with support for the [Bitcoin Name System](bitcoin-name-system.md) and vice versa.
-
-### Web2 vs Web3 Authentication
-
-If you come from the web2 world, you are likely used to authenticating with usernames and passwords, where the user's info is stored in a database. Upon entering the password, it is hashed and compared to the hash stored in the database and, if it matches, the user is logged in.
-
-Web3 authentication works a bit differently. One of the core philosophies of web3 is data ownership, which means users are in control of their data, including their authentication.
-
-Authentication in the Bitcoin and Stacks world makes use of cryptography to generate private keys, public keys and addresses.
-
-We'll go over the basics here, but if you want to dig in, [Learn Me a Bitcoin](https://learnmeabitcoin.com/beginners/guide/keys-addresses/) is a great place to start.
-
-To generate a Stacks account, we generate a private key from a 24 word mnemonic phrase, as discussed in the previous section. This private key is then used to generate a public key using a one-way hash function. Meaning you can derive a public key from a private key, but not vice versa.
-
-A user's private key is their main source of security and is used to authenticate them. Do not lose your private key.
-
-So, when I use a wallet app like [Leather](https://leather.io) and I want to use it to authenticate with a dapp like StackingDAO, what I am doing is that I am giving my wallet my private key, proving that I own the corresponding address.
-
-The wallet will then pass that information (my address and public key) to the app along with a signature.
-
-A signature can be thought of as proof that I own the private key without actually revealing the private key. That mechanism is how I can use the same wallet and address to log in to any app that supports Stacks authentication.
-
-Third Web has a great [conceptual primer](https://blog.thirdweb.com/web3-auth/) on web3 authentication.
-
-For a more practical introduction, take a look at the [Quickstart tutorial ](../../guides-and-tutorials/hello-stacks-quickstart-tutorial.md)and [Hiro's Stacks.js docs](https://docs.hiro.so/stacks/connect/guides/authenticate-users).
-
-### How it works
-
-The authentication flow with Stacks is similar to the typical client-server flow used by centralized sign in services (for example, OAuth). However, with Stacks the authentication flow happens entirely client-side.
-
-{% hint style="info" %}
-This explanation is here so you can understand how this process works, but the bulk of this functionality is handled by the wallet and the JS library you use. Take a look at the [Stacks.js docs](https://docs.hiro.so/stacks/stacks.js/concepts/accounts-and-addresses) for more info.
-{% endhint %}
-
-An app and authenticator, such as the [Leather wallet](https://leather.io), communicate during the authentication flow by passing back and forth two tokens. The requesting app sends the authenticator an `authRequest` token. Once a user approves authentication, the authenticator responds to the app with an `authResponse` token.
-
-These tokens are based on [a JSON Web Token (JWT) standard](https://tools.ietf.org/html/rfc7519) with additional support for the `secp256k1` curve used by Bitcoin and many other cryptocurrencies. They are passed via URL query strings.
-
-When a user chooses to authenticate an app, it sends the `authRequest` token to the authenticator via a URL query string with an equally named parameter:
-
-`https://wallet.hiro.so/...?authRequest=j902120cn829n1jnvoa...`
-
-When the authenticator receives the request, it generates an `authResponse` token for the app using an _ephemeral transit key_ . The ephemeral transit key is just used for the particular instance of the app, in this case, to sign the `authRequest`.
-
-The app stores the ephemeral transit key during request generation. The public portion of the transit key is passed in the `authRequest` token. The authenticator uses the public portion of the key to encrypt an _app private key_ which is returned via the `authResponse`.
-
-The authenticator generates the app private key from the user's _identity address private key_ and the app's domain. The app private key serves three functions:
-
-1. It is used to create credentials that give the app access to a storage bucket in the user's Gaia hub
-2. It is used in the end-to-end encryption of files stored for the app in the user's Gaia storage.
-3. It serves as a cryptographic secret that apps can use to perform other cryptographic functions.
-
-Finally, the app private key is deterministic, meaning that the same private key will always be generated for a given Stacks address and domain.
-
-### Key pairs
-
-Authentication with Stacks makes extensive use of public key cryptography generally and ECDSA with the `secp256k1` curve in particular.
-
-The following sections describe the three public-private key pairs used, including how they're generated, where they're used and to whom private keys are disclosed.
-
-#### Transit private key
-
-The transit private is an ephemeral key that is used to encrypt secrets that need to be passed from the authenticator to the app during the authentication process. It is randomly generated by the app at the beginning of the authentication response.
-
-The public key that corresponds to the transit private key is stored in a single element array in the `public_keys` key of the authentication request token. The authenticator encrypts secret data such as the app private key using this public key and sends it back to the app when the user signs in to the app. The transit private key signs the app authentication request.
-
-#### Identity address private key
-
-The identity address private key is derived from the user's keychain phrase and is the private key of the Stacks username that the user chooses to use to sign in to the app. It is a secret owned by the user and never leaves the user's instance of the authenticator.
-
-This private key signs the authentication response token for an app to indicate that the user approves sign in to that app.
-
-#### App private key
-
-The app private key is an app-specific private key that is generated from the user's identity address private key using the `domain_name` as input.
-
-The app private key is securely shared with the app on each authentication, encrypted by the authenticator with the transit public key. Because the transit key is only stored on the client side, this prevents a man-in-the-middle attack where a server or internet provider could potentially snoop on the app private key.
diff --git a/concepts/network-fundamentals/bitcoin-name-system.md b/concepts/network-fundamentals/bitcoin-name-system.md
deleted file mode 100644
index 66fe22e8eb..0000000000
--- a/concepts/network-fundamentals/bitcoin-name-system.md
+++ /dev/null
@@ -1,231 +0,0 @@
-# Bitcoin Name System
-
-Bitcoin Name System (BNS) is a network system that binds Stacks usernames to off-chain state without relying on any central points of control.
-
-The Stacks V1 blockchain implemented BNS through first-order name operations. In Stacks V2, BNS is instead implemented through a smart-contract loaded during the genesis block.
-
-Names in BNS have three properties:
-
-* **Names are globally unique.** The protocol does not allow name collisions, and all well-behaved nodes resolve a given name to the same state.
-* **Names are human-meaningful.** Each name is chosen by its creator.
-* **Names are strongly owned.** Only the name's owner can change the state it resolves to. Specifically, a name is owned by one or more ECDSA private keys.
-
-The Stacks blockchain insures that each node's BNS view is synchronized to all of the other nodes in the world, so queries on one node will be the same on other nodes. Stacks blockchain nodes allow a name's owner to bind up to 40Kb of off-chain state to their name, which will be replicated to all other Stacks blockchain nodes via a P2P network.
-
-The biggest consequence for developers is that in BNS, reading name state is fast and cheap but writing name state is slow and expensive. This is because registering and modifying names requires one or more transactions to be sent to the underlying blockchain, and BNS nodes will not process them until they are sufficiently confirmed. Users and developers need to acquire and spend the requisite cryptocurrency (STX) to send BNS transactions.
-
-### Motivation behind name systems
-
-We rely on name systems in everyday life, and they play a critical role in many different applications. For example, when you look up a friend on social media, you are using the platform's name system to resolve their name to their profile. When you look up a website, you are using the Domain Name Service to resolve the hostname to its host's IP address. When you check out a Git branch, you are using your Git client to resolve the branch name to a commit hash. When you look up someone's PGP key on a keyserver, you are resolving their key ID to their public key.
-
-What kinds of things do we want to be true about names? In BNS, names are globally unique, names are human-meaningful, and names are strongly owned. However, if you look at these examples, you'll see that each of them only guarantees _two_ of these properties. This limits how useful they can be.
-
-* In DNS and social media, names are globally unique and human-readable, but not strongly owned. The system operator has the final say as to what each names resolves to.
- * **Problem**: Clients must trust the system to make the right choice in what a given name resolves to. This includes trusting that no one but the system administrators can make these changes.
-* In Git, branch names are human-meaningful and strongly owned, but not globally unique. Two different Git nodes may resolve the same branch name to different unrelated repository states.
- * **Problem**: Since names can refer to conflicting state, developers have to figure out some other mechanism to resolve ambiguities. In Git's case, the user has to manually intervene.
-* In PGP, names are key IDs. They are globally unique and cryptographically owned, but not human-readable. PGP key IDs are derived from the keys they reference.
- * **Problem**: These names are difficult for most users to remember since they do not carry semantic information relating to their use in the system.
-
-BNS names have all three properties, and none of these problems. This makes it a powerful tool for building all kinds of network applications. With BNS, we can do the following and more:
-
-* Build domain name services where hostnames can't be hijacked.
-* Build social media platforms where user names can't be stolen by phishers.
-* Build version control systems where repository branches do not conflict.
-* Build public-key infrastructure where it's easy for users to discover and remember each other's keys.
-
-### Organization of BNS
-
-BNS names are organized into a global name hierarchy. There are three different layers in this hierarchy related to naming:
-
-* **Namespaces**. These are the top-level names in the hierarchy. An analogy to BNS namespaces are DNS top-level domains. Existing BNS namespaces include `.id`, `.podcast`, and `.helloworld`. All other names belong to exactly one namespace. Anyone can create a namespace, but in order for the namespace to be persisted, it must be _launched_ so that anyone can register names in it. Namespaces are not owned by their creators.
-* **BNS names**. These are names whose records are stored directly on the blockchain. The ownership and state of these names are controlled by sending blockchain transactions. Example names include `verified.podcast` and `muneeb.id`. Anyone can create a BNS name, as long as the namespace that contains it exists already.
-* **BNS subdomains**. These are names whose records are stored off-chain, but are collectively anchored to the blockchain. The ownership and state for these names lives within the P2P network data. While BNS subdomains are owned by separate private keys, a BNS name owner must broadcast their subdomain state. Example subdomains include `jude.personal.id` and `podsaveamerica.verified.podcast`. Unlike BNS namespaces and names, the state of BNS subdomains is _not_ part of the blockchain consensus rules.
-
-A feature comparison matrix summarizing the similarities and differences between these name objects is presented below:
-
-| Feature | **Namespaces** | **BNS names** | **BNS Subdomains** |
-| -------------------------------------- | -------------- | ------------- | ------------------ |
-| Globally unique | X | X | X |
-| Human-meaningful | X | X | X |
-| Owned by a private key | | X | X |
-| Anyone can create | X | X | \[1] |
-| Owner can update | | X | \[1] |
-| State hosted on-chain | X | X | |
-| State hosted off-chain | | X | X |
-| Behavior controlled by consensus rules | X | X | |
-| May have an expiration date | | X | |
-
-\[1] Requires the cooperation of a BNS name owner to broadcast its transactions
-
-### Namespaces
-
-Namespaces are the top-level name objects in BNS.
-
-They control a few properties about the names within them:
-
-* How expensive they are to register
-* How long they last before they have to be renewed
-* Who (if anyone) receives the name registration fees
-* Who is allowed to seed the namespace with its initial names.
-
-At the time of this writing, by far the largest BNS namespace is the `.id` namespace. Names in the `.id` namespace are meant for resolving user identities. Short names in `.id` are more expensive than long names, and have to be renewed by their owners every two years. Name registration fees are not paid to anyone in particular---they are instead sent to a "black hole" where they are rendered non-spendable (the intention is to discourage ID squatters).
-
-Unlike DNS, _anyone_ can create a namespace and set its properties. Namespaces are created on a first-come first-serve basis, and once created, they last forever.
-
-However, creating a namespace is not free. The namespace creator must _burn_ cryptocurrency to do so. The shorter the namespace, the more cryptocurrency must be burned (that is, short namespaces are more valuable than long namespaces). For example, it cost Blockstack PBC 40 BTC to create the `.id` namespace in 2015 (in transaction `5f00b8e609821edd6f3369ee4ee86e03ea34b890e242236cdb66ef6c9c6a1b281`).
-
-Namespaces can be between 1 and 19 characters long, and are composed of the characters `a-z`, `0-9`, `-`, and `_`.
-
-### Subdomains
-
-BNS names are strongly owned because the owner of its private key can generate valid transactions that update its zone file hash and owner. However, this comes at the cost of requiring a name owner to pay for the underlying transaction in the blockchain. Moreover, this approach limits the rate of BNS name registrations and operations to the underlying blockchain's transaction bandwidth.
-
-BNS overcomes this with subdomains. A **BNS subdomain** is a type of BNS name whose state and owner are stored outside of the blockchain, but whose existence and operation history are anchored to the blockchain. Like their on-chain counterparts, subdomains are globally unique, strongly owned, and human-readable. BNS gives them their own name state and public keys. Unlike on-chain names, subdomains can be created and managed cheaply, because they are broadcast to the BNS network in batches. A single blockchain transaction can send up to 120 subdomain operations.
-
-This is achieved by storing subdomain records in the BNS name zone files. An on-chain name owner broadcasts subdomain operations by encoding them as `TXT` records within a DNS zone file. To broadcast the zone file, the name owner sets the new zone file hash with a `NAME_UPDATE` transaction and replicates the zone file. This, in turn, replicates all subdomain operations it contains, and anchors the set of subdomain operations to an on-chain transaction. The BNS node's consensus rules ensure that only valid subdomain operations from _valid_ `NAME_UPDATE` transactions will ever be stored.
-
-For example, the name `verified.podcast` once wrote the zone file hash `247121450ca0e9af45e85a82e61cd525cd7ba023`, which is the hash of the following zone file:
-
-```bash
-$TTL 3600
-1yeardaily TXT "owner=1MwPD6dH4fE3gQ9mCov81L1DEQWT7E85qH" "seqn=0" "parts=1" "zf0=JE9SSUdJTiAxeWVhcmRhaWx5CiRUVEwgMzYwMApfaHR0cC5fdGNwIFVSSSAxMCAxICJodHRwczovL3BoLmRvdHBvZGNhc3QuY28vMXllYXJkYWlseS9oZWFkLmpzb24iCg=="
-2dopequeens TXT "owner=1MwPD6dH4fE3gQ9mCov81L1DEQWT7E85qH" "seqn=0" "parts=1" "zf0=JE9SSUdJTiAyZG9wZXF1ZWVucwokVFRMIDM2MDAKX2h0dHAuX3RjcCBVUkkgMTAgMSAiaHR0cHM6Ly9waC5kb3Rwb2RjYXN0LmNvLzJkb3BlcXVlZW5zL2hlYWQuanNvbiIK"
-10happier TXT "owner=1MwPD6dH4fE3gQ9mCov81L1DEQWT7E85qH" "seqn=0" "parts=1" "zf0=JE9SSUdJTiAxMGhhcHBpZXIKJFRUTCAzNjAwCl9odHRwLl90Y3AgVVJJIDEwIDEgImh0dHBzOi8vcGguZG90cG9kY2FzdC5jby8xMGhhcHBpZXIvaGVhZC5qc29uIgo="
-31thoughts TXT "owner=1MwPD6dH4fE3gQ9mCov81L1DEQWT7E85qH" "seqn=0" "parts=1" "zf0=JE9SSUdJTiAzMXRob3VnaHRzCiRUVEwgMzYwMApfaHR0cC5fdGNwIFVSSSAxMCAxICJodHRwczovL3BoLmRvdHBvZGNhc3QuY28vMzF0aG91Z2h0cy9oZWFkLmpzb24iCg=="
-359 TXT "owner=1MwPD6dH4fE3gQ9mCov81L1DEQWT7E85qH" "seqn=0" "parts=1" "zf0=JE9SSUdJTiAzNTkKJFRUTCAzNjAwCl9odHRwLl90Y3AgVVJJIDEwIDEgImh0dHBzOi8vcGguZG90cG9kY2FzdC5jby8zNTkvaGVhZC5qc29uIgo="
-30for30 TXT "owner=1MwPD6dH4fE3gQ9mCov81L1DEQWT7E85qH" "seqn=0" "parts=1" "zf0=JE9SSUdJTiAzMGZvcjMwCiRUVEwgMzYwMApfaHR0cC5fdGNwIFVSSSAxMCAxICJodHRwczovL3BoLmRvdHBvZGNhc3QuY28vMzBmb3IzMC9oZWFkLmpzb24iCg=="
-onea TXT "owner=1MwPD6dH4fE3gQ9mCov81L1DEQWT7E85qH" "seqn=0" "parts=1" "zf0=JE9SSUdJTiBvbmVhCiRUVEwgMzYwMApfaHR0cC5fdGNwIFVSSSAxMCAxICJodHRwczovL3BoLmRvdHBvZGNhc3QuY28vb25lYS9oZWFkLmpzb24iCg=="
-10minuteteacher TXT "owner=1MwPD6dH4fE3gQ9mCov81L1DEQWT7E85qH" "seqn=0" "parts=1" "zf0=JE9SSUdJTiAxMG1pbnV0ZXRlYWNoZXIKJFRUTCAzNjAwCl9odHRwLl90Y3AgVVJJIDEwIDEgImh0dHBzOi8vcGguZG90cG9kY2FzdC5jby8xMG1pbnV0ZXRlYWNoZXIvaGVhZC5qc29uIgo="
-36questionsthepodcastmusical TXT "owner=1MwPD6dH4fE3gQ9mCov81L1DEQWT7E85qH" "seqn=0" "parts=1" "zf0=JE9SSUdJTiAzNnF1ZXN0aW9uc3RoZXBvZGNhc3RtdXNpY2FsCiRUVEwgMzYwMApfaHR0cC5fdGNwIFVSSSAxMCAxICJodHRwczovL3BoLmRvdHBvZGNhc3QuY28vMzZxdWVzdGlvbnN0aGVwb2RjYXN0bXVzaWNhbC9oZWFkLmpzb24iCg=="
-_http._tcp URI 10 1 "https://dotpodcast.co/"
-```
-
-Each `TXT` record in this zone file encodes a subdomain-creation. For example, `1yeardaily.verified.podcast` resolves to:
-
-```json
-{
- "address": "1MwPD6dH4fE3gQ9mCov81L1DEQWT7E85qH",
- "blockchain": "bitcoin",
- "last_txid": "d87a22ebab3455b7399bfef8a41791935f94bc97aee55967edd5a87f22cce339",
- "status": "registered_subdomain",
- "zonefile_hash": "e7acc97fd42c48ed94fd4d41f674eddbee5557e3",
- "zonefile_txt": "$ORIGIN 1yeardaily\n$TTL 3600\n_http._tcp URI 10 1 \"https://ph.dotpodcast.co/1yeardaily/head.json\"\n"
-}
-```
-
-This information was extracted from the `1yeardaily` `TXT` resource record in the zone file for `verified.podcast`.
-
-#### Subdomain Lifecycle
-
-Note that `1yeardaily.verified.podcast` has a different public key hash (address) than `verified.podcast`. A BNS node will only process a subsequent subdomain operation on `1yeardaily.verified.podcast` if it includes a signature from this address's private key. `verified.podcast` cannot generate updates; only the owner of `1yeardaily.verified.podcast can do so`.
-
-The lifecycle of a subdomain and its operations is shown in Figure 2.
-
-```
- subdomain subdomain subdomain
- creation update transfer
-+----------------+ +----------------+ +----------------+
-| cicero | | cicero | | cicero |
-| owner="1Et..." | signed | owner="1Et..." | signed | owner="1cJ..." |
-| zf0="7e4..." |<--------| zf0="111..." |<--------| zf0="111..." |<---- ...
-| seqn=0 | | seqn=1 | | seqn=2 |
-| | | sig="xxxx" | | sig="xxxx" |
-+----------------+ +----------------+ +----------------+
- | | |
- | off-chain | |
-~ ~ ~ ~ | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~|~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | ~ ~ ~ ~ ~ ~ ~ ...
- | on-chain | |
- V V (zone file hash ) V
-+----------------+ +----------------+ +----------------+
-| res_publica.id | | jude.id | | res_publica.id |
-| NAME_UPDATE |<--------| NAME_UPDATE |<--------| NAME_UPDATE |<---- ...
-+----------------+ +----------------+ +----------------+
- blockchain blockchain blockchain
- block block block
-
-
-Figure 2: Subdomain lifetime with respect to on-chain name operations .A new
-subdomain operation will only be accepted if it has a later "sequence=" number,
-and a valid signature in "sig=" over the transaction body .The "sig=" field
-includes both the public key and signature, and the public key must hash to
-the previous subdomain operation's "addr=" field.
-
-The subdomain-creation and subdomain-transfer transactions for
-"cicero.res_publica.id" are broadcast by the owner of "res_publica.id."
-However, any on-chain name ("jude.id" in this case) can broadcast a subdomain
-update for "cicero.res_publica.id."
-```
-
-Subdomain operations are ordered by sequence number, starting at 0. Each new subdomain operation must include:
-
-* The next sequence number
-* The public key that hashes to the previous subdomain transaction's address
-* A signature from the corresponding private key over the entire subdomain operation.
-
-If two correctly signed but conflicting subdomain operations are discovered (that is, they have the same sequence number), the one that occurs earlier in the blockchain's history is accepted. Invalid subdomain operations are ignored.
-
-Combined, this ensures that a BNS node with all of the zone files with a given subdomain's operations will be able to determine the valid sequence of state-transitions it has undergone, and determine the current zone file and public key hash for the subdomain.
-
-#### Subdomain Creation and Management
-
-Unlike an on-chain name, a subdomain owner needs an on-chain name owner's help to broadcast their subdomain operations. In particular:
-
-* A subdomain-creation transaction can only be processed by the owner of the on-chain name that shares its suffix. For example, only the owner of `res_publica.id` can broadcast subdomain-creation transactions for subdomain names ending in `.res_publica.id`.
-* A subdomain-transfer transaction can only be broadcast by the owner of the on-chain name that created it. For example, the owner of `cicero.res_publica.id` needs the owner of `res_publica.id` to broadcast a subdomain-transfer transaction to change `cicero.res_publica.id`'s public key.
-* In order to send a subdomain-creation or subdomain-transfer, all of an on-chain name owner's zone files must be present in the Atlas network. This lets the BNS node prove the _absence_ of any conflicting subdomain-creation and subdomain-transfer operations when processing new zone files.
-* A subdomain update transaction can be broadcast by _any_ on-chain name owner, but the subdomain owner needs to find one who will cooperate. For example, the owner of `verified.podcast` can broadcast a subdomain-update transaction created by the owner of `cicero.res_publica.id`.
-
-That said, to create a subdomain, the subdomain owner generates a subdomain-creation operation for their desired name and gives it to the on-chain name owner.
-
-Once created, a subdomain owner can use any on-chain name owner to broadcast a subdomain-update operation. To do so, they generate and sign the requisite subdomain operation and give it to an on-chain name owner, who then packages it with other subdomain operations into a DNS zone file and broadcasts it to the network.
-
-If the subdomain owner wants to change the address of their subdomain, they need to sign a subdomain-transfer operation and give it to the on-chain name owner who created the subdomain. They then package it into a zone file and broadcast it.
-
-#### Subdomain Registrars
-
-Because subdomain names are cheap, developers may be inclined to run subdomain registrars on behalf of their applications. For example, the name `personal.id` is used to register usernames without requiring them to spend any Bitcoin.
-
-We supply a reference implementation of a [BNS Subdomain Registrar](https://github.com/stacks-network/subdomain-registrar) to help developers broadcast subdomain operations. Users would still own their subdomain names; the registrar simply gives developers a convenient way for them to register and manage them in the context of a particular application.
-
-### BNS and DID Standards
-
-BNS names are compliant with the emerging [Decentralized Identity Foundation](http://identity.foundation) protocol specification for decentralized identifiers (DIDs).
-
-Each name in BNS has an associated DID. The DID format for BNS is:
-
-```bash
- did:stack:v0:{address}-{index}
-```
-
-Where:
-
-* `{address}` is an on-chain public key hash (for example a Bitcoin address).
-* `{index}` refers to the `nth` name this address created.
-
-For example, the DID for `personal.id` is `did:stack:v0:1dARRtzHPAFRNE7Yup2Md9w18XEQAtLiV-0`, because the name `personal.id` was the first-ever name created by `1dARRtzHPAFRNE7Yup2Md9w18XEQAtLiV`.
-
-As another example, the DID for `jude.id` is `did:stack:v0:16EMaNw3pkn3v6f2BgnSSs53zAKH4Q8YJg-1`. Here, the address `16EMaNw3pkn3v6f2BgnSSs53zAKH4Q8YJg` had created one earlier name in history prior to this one (which happens to be `abcdefgh123456.id`).
-
-The purpose of a DID is to provide an eternal identifier for a public key. The public key may change, but the DID will not.
-
-Stacks Blockchain implements a DID method of its own in order to be compatible with other systems that use DIDs for public key resolution. In order for a DID to be resolvable, all of the following must be true for a name:
-
-* The name must exist
-* The name's zone file hash must be the hash of a well-formed DNS zone file
-* The DNS zone file must be present in the Stacks node's data.
-* The DNS zone file must contain a `URI` resource record that points to a signed JSON Web Token
-* The public key that signed the JSON Web Token (and is included with it) must hash to the address that owns the name
-
-Not all names will have DIDs that resolve to public keys. However, names created by standard tooling will have DIDs that do.
-
-A RESTful API is under development.
-
-### DID Encoding for Subdomains
-
-Every name and subdomain in BNS has a DID. The encoding is slightly different for subdomains, so the software can determine which code-path to take.
-
-* For on-chain BNS names, the `{address}` is the same as the Bitcoin address that owns the name. Currently, both version byte 0 and version byte 5 addresses are supported (that is, addresses starting with `1` or `3`, meaning `p2pkh` and `p2sh` addresses).
-* For off-chain BNS subdomains, the `{address}` has version byte 63 for subdomains owned by a single private key, and version byte 50 for subdomains owned by a m-of-n set of private keys. That is, subdomain DID addresses start with `S` or `M`, respectively.
-
-The `{index}` field for a subdomain's DID is distinct from the `{index}` field for a BNS name's DID, even if the same created both names and subdomains. For example, the name `abcdefgh123456.id` has the DID `did:stack:v0:16EMaNw3pkn3v6f2BgnSSs53zAKH4Q8YJg-0`, because it was the first name created by `16EMaNw3pkn3v6f2BgnSSs53zAKH4Q8YJg`. However, `16EMaNw3pkn3v6f2BgnSSs53zAKH4Q8YJg` _also_ created `jude.statism.id` as its first subdomain name. The DID for `jude.statism.id` is `did:stack:v0:SSXMcDiCZ7yFSQSUj7mWzmDcdwYhq97p2i-0`. Note that the address `SSXMcDiCZ7yFSQSUj7mWzmDcdwYhq97p2i` encodes the same public key hash as the address `16EMaNw3pkn3v6f2BgnSSs53zAKH4Q8YJg` (the only difference between these two strings is that the first is base58check-encoded with version byte 0, and the second is encoded with version byte 63).
diff --git a/concepts/network-fundamentals/mainnet-and-testnets.md b/concepts/network-fundamentals/mainnet-and-testnets.md
deleted file mode 100644
index 23070db1f0..0000000000
--- a/concepts/network-fundamentals/mainnet-and-testnets.md
+++ /dev/null
@@ -1,65 +0,0 @@
-# Mainnet and Testnets
-
-Stacks has both a mainnet and a few different testnets for different purposes. Mainnet and testnet are two completely different networks and tokens cannot be transferred between one or the other.
-
-### Mainnet
-
-Stacks mainnet is directly connected to Bitcoin mainnet and is the network where tokens have actual monetary worth. This is the production network and should be treated as such.
-
-You can view mainnet activity using [Hiro's block explorer](https://explorer.hiro.so/).
-
-### Primary and Nakamoto Testnets
-
-There are some notable differences between Primary Testnet and Nakamoto Testnet, this table can guide you in selecting the one most aligned with your needs.
-
-
Attributes
Nakamoto Testnet
Primary Testnet
Stacking Cycle Length
3 days
1 week
Description
Bleeding edge, more frequent upgrades with Release Candidates.
Stable release updates ONLY, the last step before Mainnet.
Usage Recommendations
Use this if you don’t mind frequent resets and would like to test the latest features as they’re released
Use this if you prefer faster feedback loops to test various stacking-signer scenarios
Use this if you prefer more stable releases and don’t want frequent resets and updates
Use this if you don't need to be among the first to test new features
Use this if you prefer longer Stacking cycles
Lifespan
Nakamoto Testnet will remain available until sBTC goes live on Mainnet
The Primary Testnet will exist and be maintained forever.
-
-### Important notes on the Primary Testnet:
-
-* Core devs are working on a BTC Regtest Explorer. In the meantime, Wallet, Explorer, and API links to BTC transactions will lead you nowhere. This is expected and will be addressed. All STX transactions are available to track on the [Explorer](https://explorer.hiro.so/?chain=testnet).
-* You can start onboarding your Signer, deploy contracts and test your Apps. All functionality from the previous testnet is available.
-* Old testnet data is archived and will remain [available](https://explorer.hiro.so/?chain=testnet\&api=https://api.old.testnet.hiro.so) until the end of June 2024
-* **Faucet and tSTX:**
- * The [Faucet address](https://explorer.hiro.so/address/ST2QKZ4FKHAH1NQKYKYAYZPY440FEPK7GZ1R5HBP2?chain=testnet) and limits stay the same.
- * If you need more tSTX than the current daily limit to onboard your Signer on Primary Testnet, please reach out to your main point of contact in the ecosystem.
-
-### Configuration Files for Signers
-
-* [sample-configuration-files.md](../../reference/sample-configuration-files.md "mention")
-* [#primary-testnet-config](../../reference/sample-configuration-files.md#primary-testnet-config "mention")
-
-### About testnet
-
-The testnet is a separate blockchain from the Stacks mainnet analogous to a staging environnement. It's a network used by developers to test their apps, smart contracts, or changes to the protocol in a production-like environment.
-
-It produces blocks at roughly the same rate as mainnet; about 1 block every 10 minutes on average. The Stacks testnet is rarely reset.
-
-#### Faucets
-
-Testnet faucets provide you with free Stacks Token (STX) to test with. These are not the same as STX on mainnet and have no value. There are a couple of different options for getting testnet STX.
-
-**Hiro**
-
-You can get STX from the Hiro faucet on the [Hiro Explorer Sandbox](https://explorer.hiro.so/sandbox/faucet?chain=testnet), or using the [API](https://docs.hiro.so/api#tag/Faucets).
-
-To get STX tokens from within the Explorer Sandbox, navigate to the "Faucet" tab on the left and click "Request STX" button.
-
-You can also try out Stacking by clicking on `I want to stack`.
-
-{% hint style="info" %}
-The Explorer Sandbox requires you to login with a Stacks wallet
-{% endhint %}
-
-**LearnWeb3**
-
-Alternatively, you can use the [LearnWeb3 faucet](https://learnweb3.io/faucets).
-
-
-
-#### Testnet API
-
-The hosted Stacks Blockchain API for the testnet is available at this base URL:
-
-```shell
-https://api.testnet.hiro.so/
-```
diff --git a/concepts/network-fundamentals/network.md b/concepts/network-fundamentals/network.md
deleted file mode 100644
index eb8a41920f..0000000000
--- a/concepts/network-fundamentals/network.md
+++ /dev/null
@@ -1,91 +0,0 @@
-# Network Basics
-
-### Tokens
-
-Stacks (STX) tokens are the native tokens on the Stacks blockchain. The smallest fraction is one micro-STX. 1,000,000 micro-STX make one Stacks (STX).
-
-STX amounts should be stored as integers (8 bytes long), and represent the amount of micro-STX.
-
-### Fees
-
-Fees are used to incentivize miners to confirm transactions on the Stacks blockchain. The fee is calculated based on the estimate fee rate and the size of the raw transaction in bytes. The fee rate is a market determined variable. For the testnet, it is set to 1 micro-STX.
-
-Fee estimates can obtained through the [`GET /v2/fees/transfer`](https://docs.hiro.so/api#operation/get\_fee\_transfer) endpoint of the API.
-
-{% hint style="info" %}
-Note that this example uses an external tool, [Hiro's Stacks API](https://www.hiro.so/stacks-api). You can also use the native [Stacks API ](../../reference/api.md)if you would rather run your own node or connect to one.
-{% endhint %}
-
-```bash
-# for mainnet, replace `testnet` with `mainnet`
-curl 'https://api.testnet.hiro.so/v2/fees/transfer'
-```
-
-The API will respond with the fee rate (as integer):
-
-```json
-1
-```
-
-[The Stacks Transactions JS library](https://github.com/hirosystems/stacks.js/tree/master/packages/transactions) supports fee estimation for:
-
-* token transfers (`estimateTransfer`)
-* contract deploys (`estimateContractDeploy`)
-* non read-only contract calls (`estimateContractFunctionCall`)
-
-{% hint style="info" %}
-For an implementation using a different language than JavaScript, please review [this reference implementation](https://github.com/hirosystems/stacks.js/blob/master/packages/transactions/src/builders.ts#L97).
-{% endhint %}
-
-### Nonces
-
-Every account carries a [nonce property](https://en.wikipedia.org/wiki/Cryptographic\_nonce) that indicates the number of transactions processed for the given account. Nonces are one-time codes, starting at `0` for new accounts, and incremented by 1 on every transaction.
-
-Nonces are added to all transactions and help identify them in order to ensure transactions are processed in order and to avoid duplicated processing.
-
-{% hint style="info" %}
-The consensus mechanism also ensures that transactions aren't "replayed" in two ways. First, nodes query its unspent transaction outputs (UTXOs) in order to satisfy their spending conditions in a new transaction. Second, messages sent between nodes review sequence numbers.
-{% endhint %}
-
-When a new token transfer transaction is constructed, the most recent nonce of the account needs to be fetched and set.
-
-{% hint style="info" %}
-The API provides an endpoint to [simplify nonce handling](https://docs.hiro.so/get-started/stacks-blockchain-api#nonce-handling).
-{% endhint %}
-
-### Querying
-
-Stacks network details can be queried using the [Stacks Blockchain API](https://docs.hiro.so/get-started/stacks-blockchain-api).
-
-#### Health check
-
-The [status checker](https://status.stacks.org) is a service that provides a user interface to quickly review the health of the Stacks blockchain.
-
-#### Network info
-
-The network information can be obtained using the [`GET /v2/info`](https://docs.hiro.so/api#operation/get\_core\_api\_info) endpoint:
-
-```bash
-# for mainnet, replace `testnet` with `mainnet`
-curl 'https://api.testnet.hiro.so/v2/info'
-```
-
-Sample response:
-
-```js
-{
- "peer_version": 385875968,
- "burn_consensus": "826401d65cf3671210a3fb135d827d549c0b4d37",
- "burn_block_height": 1972,
- "stable_burn_consensus": "e27ea23f199076bc41a729d76a813e125b725f64",
- "stable_burn_block_height": 1971,
- "server_version": "blockstack-core 0.0.1 => 23.0.0.0 (master:bdd042242+, release build, linux [x86_64]",
- "network_id": 2147483648,
- "parent_network_id": 3669344250,
- "stacks_tip_height": 933,
- "stacks_tip": "1f601823fbcc5b6b2215b2ff59d2818fba61ee4a3cea426d8bc3dbb268005d8f",
- "stacks_tip_burn_block": "54c56a9685545c45accf42b5dcb2787c97eda8185a1c794daf9b5a59d4807abc",
- "unanchored_tip": "71948ee211dac3b241eb65d881637f649d0d49ac08ee4a41c29217d3026d7aae",
- "exit_at_block_height": 28160
-}
-```
diff --git a/concepts/network-fundamentals/sips.md b/concepts/network-fundamentals/sips.md
deleted file mode 100644
index cc11868ae7..0000000000
--- a/concepts/network-fundamentals/sips.md
+++ /dev/null
@@ -1,54 +0,0 @@
-# SIPs
-
-### Stacks Improvement Proposals (SIPs)
-
-Stacks improvement proposals (SIPs) are aimed at describing the implementation of the Stacks blockchain, as well as proposing improvements.
-
-The SIP process [(SIP-000)](https://github.com/stacksgov/sips/blob/main/sips/sip-000/sip-000-stacks-improvement-proposal-process.md) describes how to make a SIP and get it ratified.
-
-They should contain concise technical specifications of features or standards and the rationale behind it. SIPs are intended to be the primary medium for proposing new features, for collecting community input on a system-wide issue, and for documenting design decisions.
-
-The SIPs are located in the [stacksgov/sips](https://github.com/stacksgov/sips) repository as part of the [Stacks Community Governance organization](https://github.com/stacksgov).
-
-Anyone in the Stacks community can submit a SIP.
-
-{% hint style="info" %}
-Stacks Improvement Proposals Community Calls Add the [weekly community SIP call](https://www.addevent.com/event/wS15955379) to your calendar.
-
-SIP Meeting calls are recorded and available [here](https://www.youtube.com/playlist?list=PLg717Ri\_rTnx5kuaWqp3cUAtwQk\_yzslT)
-
-More details of the meetings are available [here](https://github.com/stacksgov/sips/issues/79)
-{% endhint %}
-
-### Ratified SIPSs
-
-* [x] [SIP 000: Improvement Proposal Process](https://github.com/stacksgov/sips/blob/main/sips/sip-000/sip-000-stacks-improvement-proposal-process.md)
-* [x] [SIP 001: Burn Election](https://github.com/stacksgov/sips/blob/main/sips/sip-001/sip-001-burn-election.md)
-* [x] [SIP 002: Clarity, a language for predictable smart contracts](https://github.com/stacksgov/sips/blob/main/sips/sip-002/sip-002-smart-contract-language.md)
-* [x] [SIP 003: Peer Network](https://github.com/stacksgov/sips/blob/main/sips/sip-003/sip-003-peer-network.md)
-* [x] [SIP 004: Cryptographic Commitment to Materialized Views](https://github.com/stacksgov/sips/blob/main/sips/sip-004/sip-004-materialized-view.md)
-* [x] [SIP 005: Blocks, Transactions, and Accounts](https://github.com/stacksgov/sips/blob/main/sips/sip-005/sip-005-blocks-and-transactions.md)
-* [x] [SIP 006: Clarity Execution Cost Assessment](https://github.com/stacksgov/sips/blob/main/sips/sip-006/sip-006-runtime-cost-assessment.md)
-* [x] [SIP 007: Stacking Consensus](https://github.com/stacksgov/sips/blob/main/sips/sip-007/sip-007-stacking-consensus.md)
-* [x] [SIP 008: Clarity Parsing and Analysis Cost Assessment](https://github.com/stacksgov/sips/blob/main/sips/sip-008/sip-008-analysis-cost-assessment.md)
-* [x] [SIP 009: Standard Trait Definition for Non-Fungible Tokens](https://github.com/stacksgov/sips/blob/main/sips/sip-009/sip-009-nft-standard.md)
-* [x] [SIP 010: Standard Trait Definition for Fungible Tokens](https://github.com/stacksgov/sips/blob/main/sips/sip-010/sip-010-fungible-token-standard.md)
-* [x] [SIP 012: Burn Height Selection for a Network Upgrade to Introduce New Cost-Limits](https://github.com/stacksgov/sips/blob/main/sips/sip-012/sip-012-cost-limits-network-upgrade.md)
-* [x] [SIP 013: Standard Trait Definition for Semi-Fungible Tokens](https://github.com/stacksgov/sips/blob/main/sips/sip-013/sip-013-semi-fungible-token-standard.md)
-* [x] [SIP-015: Stacks Upgrade of Proof-of-Transfer and Clarity](https://github.com/stacksgov/sips/blob/main/sips/sip-015/sip-015-network-upgrade.md)
-* [x] [SIP-016: Metadata for Tokens](https://github.com/stacksgov/sips/blob/main/sips/sip-016/sip-016-token-metadata.md)
-* [x] [SIP-018: Signed Structured Data](https://github.com/stacksgov/sips/blob/main/sips/sip-018/sip-018-signed-structured-data.md)
-* [x] [SIP-019: Notifications for Token Metadata Updates](https://github.com/stacksgov/sips/blob/main/sips/sip-019/sip-019-token-metadata-update-notifications.md)
-* [x] [SIP-020: Bitwise Operations in Clarity](https://github.com/stacksgov/sips/blob/main/sips/sip-020/sip-020-bitwise-ops.md)
-* [x] [SIP-022: Emergency Fix to PoX Stacking Increases](https://github.com/stacksgov/sips/blob/main/sips/sip-022/sip-022-emergency-pox-fix.md)
-* [x] [SIP-023: Emergency Fix to Trait Invocation Behavior](https://github.com/stacksgov/sips/blob/main/sips/sip-023/sip-023-emergency-fix-traits.md)
-* [x] [SIP-024: Emergency Fix to Data Validation and Serialization Behavior](https://github.com/stacksgov/sips/blob/main/sips/sip-024/sip-024-least-supertype-fix.md)
-
-### How to Get Involved
-
-There are several ways you can get involved with the SIP process:
-
-* **Join the weekly SIP Meeting call** listed [here](https://community.stacks.org/events).
-* **SIP Editor**. SIP editors help SIP authors make sure their SIPs are well-formed and follow the right process. They help get SIPs ready for deep review by advancing it them from Draft to Accepted status. If you want to become a SIP editor, open an issue with your name and email to ask to be added to the list of SIP editors.
-* **Join a CAB** (Consideration Advisory Board). SIPs fall under the purview of one or more considerations. A full list is in [this github](https://github.com/stacksgov/sips/tree/main/considerations) directory. Currently they are: Diversity, Economics, Ethics, Governance and Technical. Members of SIP consideration advisory boards use their domain expertise to give Accepted SIPs a deep read, and give the authors any/all feedback to help make the SIP workable. If you want to join a board, reach out to the board's chairperson via the listed contact information.
-* **Steering Committee**. The Steering Committee organizes the consideration advisory boards and votes to advance Recommended SIPs to Activation-in-Progress status, and then to either Ratified or Rejected status. Once they are in the process of being activated, they use a SIP's Activation section to determine whether or not the Stacks ecosystem has ratified or rejected the SIP. Joining this committee requires the consent of the Stacks Foundation board.
diff --git a/concepts/network-fundamentals/technical-specifications/README.md b/concepts/network-fundamentals/technical-specifications/README.md
deleted file mode 100644
index e6901a562a..0000000000
--- a/concepts/network-fundamentals/technical-specifications/README.md
+++ /dev/null
@@ -1,66 +0,0 @@
-# Technical Specifications
-
-### Consensus
-
-* Proof of Transfer (PoX) as described in [SIP-007](https://github.com/stacksgov/sips/blob/main/sips/sip-007/sip-007-stacking-consensus.md)
-* Network will transition to Proof of Burn (PoB) as described in [SIP-001](https://github.com/stacksgov/sips/blob/main/sips/sip-001/sip-001-burn-election.md) after 10 years. [Learn more about Proof-of-Burn in SIP-001](https://github.com/stacksgov/sips/blob/main/sips/sip-001/sip-001-burn-election.md).
-* Threat model
- * 51% of malicious Bitcoin mining power can reorg the Stacks chain or perform a double-spend attack
- * Chain can halt if Stackers cannot meet 70% consensus on block validity
-* Different actors and their roles
- * Stacks Miners package transactions into blocks and propose them to stackers
- * Stacks Holders may alter the calculation of block limits (subject to a miner veto) and may vote to disable Proof-of-Transfer rewards for a reward cycle.
- * Stackers validate and append blocks to the chain and validate sBTC deposit and withdrawal transactions
-
-### Proof of Transfer Mining
-
-* Coinbase reward schedule:
- * 1000 STX/block for first 4 years
- * 500 STX/block for following 4 years
- * 250 STX/block for subsequent 4 years
- * 125 STX/block in perpetuity after that
-* Coinbase rewards accumulate for "missed sortitions": If a Bitcoin block has no sortition (at height N), then any Stacks block mined in a subsequent sortition that builds off of any Stacks chain tip that existed at the penultimate sortition (at height N-1) may claim its coinbase. This encourages miners to keep mining even if Bitcoin fees are high.
-* Initial mining bonus: This is a special case of the above to incentivize early miners. Coinbase for all burnchain blocks between the first burn block height (to be chosen by independent miners as part of the Stacks 2.0 launch) and the first sortition winner accumulate and are distributed to miners over a fixed window (to be determined). For instance, say burn block height is 10,000 and first sortition is at block 10500 and distribution window is 100 blocks, then coinbase for the first 500 blocks (10,500 - 10,000) will be distributed evenly to miners who win sortition over the subsequent 100 blocks.
-* Reward maturity window: 100 blocks, meaning leaders will earn the coinbase reward 100 blocks after the block they successfully mine.
-* Block interval: Stacks blockchain produces fast blocks roughly every 10 seconds with a miner tenure change occurring every Bitcoin block
-* BTC commitment: Miners must commit at least 11,000 satoshis (5,500 sats / [UTXO output](https://learnmeabitcoin.com/technical/utxo)); 2 outputs / block) to avoid "dust."
-* For more details, see Block Production.
-
-### Stacking
-
-* Stacking works in 2 phases
- 1. Prepare phase: In this phase an "anchor block" is chosen. The qualifying set of addresses ("reward set") is determined based on the snapshot of the chain at the anchor block. Length of prepare phase is 100 blocks. Stacking commitments need to be confirmed before this phase starts
- 2. Reward phase: In this phase miner BTC commitments are distributed amongst the reward set. Reward cycle length is 2000 BTC blocks (\~2 weeks).
-* Two reward addresses / block, for a total of 4000 addresses every reward cycle. The addresses are chosen using a VRF (verifiable random function), so each node can deterministically arrive at the same reward addresses for a given block.
-* Stacking threshold: 0.025% of the participating amount of STX when participation is between 25% and 100% and when participation is below 25%, the threshold level is always 0.00625 of the liquid supply of STX.
-* Delegation: An STX address can designate another address to participate in Stacking on its behalf. [Relevant section in SIP-007](https://github.com/stacksgov/sips/blob/main/sips/sip-007/sip-007-stacking-consensus.md#stacker-delegation).
-* Pooling: STX holders that individually do not meet the Stacking threshold can pool together their holdings to participate in Stacking. To do this, STX holders must set the (optional) reward address to the "delegate address." For more details, see [this reference](https://docs.stacks.co/references/stacking-contract#delegate-stx).
-* Legacy, SegWit, Native Segwit, and Taproot addresses are supported
-
-### Accounts and Addresses
-
-* Transactions in the Stacks blockchain originate from, are paid for by, and execute under the authority of accounts
-* An account is fully specified by its address + nonce + assets
-* Address contains 2 or 3 fields: 1 byte version, 20 byte public key hash (RIPEMD160(SHA256(input))), optional name (variable length, max 128 bytes)
-* Two types of accounts: standard accounts are owned by one or more private keys; contract accounts are materialized when a smart-contract is instantiated (specified by the optional name field above)
-* Nonce counts number of times an account has authorized a transaction. Starts at 0, valid authorization must include the _next_ nonce value.
-* Assets are a map of all asset types -- STX, any on-chain assets specified by a Clarity contract (for example NFTs) -- to quantities owned by that account.
-* Accounts need not be explicit "created" or registered; all accounts implicitly exist and are instantiated on first-use.
-
-### Transactions
-
-* Transaction types: coinbase, token-transfer, contract-deploy, contract-call, tenure-change.
-* Only standard accounts (not contracts) can pay transaction fees.
-* Transaction execution is governed by 3 accounts (may or may not be distinct)
- 1. _originating account_ is the account that creates, _authorizes_ and sends the transaction
- 2. _paying account_ is the account that is billed by the leader for the cost of validating and executing the transaction
- 3. _sending account_ is the account that identifies who is currently executing the transaction: this can change as a transaction executes via the `as-contract` Clarity function
-* Transactions can be batched or streamed into blocks. The behavior can be controlled by the anchor mode of a transaction. With streaming (microblocks), a faster confirmation time is possible.
-* Two types of authorizations: standard authorization is where originating account is the same as paying account. _Sponsored_ authorization is where originating account and paying account are distinct. For instance, developers or service providers could pay for users to call their smart-contracts.
-* For sponsored authorization, first a user signs with the originating account and then a sponsor signs with the paying account.
-* Mempool limit for concurrent pending transactions is 25 per account
-* Pending mempool transactions will be garbage-collected [256 blocks after receipt](https://github.com/stacks-network/stacks-blockchain/blob/master/src/core/mempool.rs#L62). With 10 minutes target block time, this would equal \~42 hours
-* [Learn more about transaction encoding in SIP-005](https://github.com/stacksgov/sips/blob/main/sips/sip-005/sip-005-blocks-and-transactions.md#transaction-encoding)
-* [Transaction signing and verification are described in SIP-005](https://github.com/stacksgov/sips/blob/main/sips/sip-005/sip-005-blocks-and-transactions.md#transaction-signing-and-verifying)
-* All transactions impacting account balance are atomic, a transfer operation can not increment one account’s balance without decrementing another’s. However, transactions that perform multiple account actions (for example, transferring from multiple accounts) may partially complete.
-* Transactions can include a memo string (max 34 bytes)
diff --git a/concepts/network-fundamentals/technical-specifications/audits.md b/concepts/network-fundamentals/technical-specifications/audits.md
deleted file mode 100644
index 6fc2cbfeb4..0000000000
--- a/concepts/network-fundamentals/technical-specifications/audits.md
+++ /dev/null
@@ -1,59 +0,0 @@
----
-description: Index of known audits related to Stacks core and sBTC
----
-
-# Audits
-
-_All 'high' or 'critical' issues listed in audits have either been mitigated or otherwise made obsolete, even if the report states otherwise._
-
-#### sBTC
-
-{% file src="../../../.gitbook/assets/Clarity Alliance - sBTC (1).pdf" %}
-
-{% file src="../../../.gitbook/assets/CoinFabrik - WSTS.pdf" %}
-
-{% file src="../../../.gitbook/assets/Ottersec - sBTC Withdrawal.pdf" %}
-
-{% file src="../../../.gitbook/assets/Ottersec - WSTS.pdf" %}
-
-#### Stacks Core
-
-{% file src="../../../.gitbook/assets/CoinFabrik - Signer Binary.pdf" %}
-
-{% file src="../../../.gitbook/assets/CoinFabrik - StackerDB.pdf" %}
-
-{% file src="../../../.gitbook/assets/CoinFabrik - Stacks LibSigner.pdf" %}
-
-{% file src="../../../.gitbook/assets/Coinfabrik - Stacks PoX.pdf" %}
-
-{% file src="../../../.gitbook/assets/CoinFabrik - Stacks Signer Audit.pdf" %}
-
-{% file src="../../../.gitbook/assets/Quantstamp - Network State Machine.pdf" %}
-
-#### Audits are just part of the story
-
-For any project, layers of security are crucial. Audits represent one layer, while core developers and contributors collaborate to provide many more. Notable security programs, designs, and partners beyond audits include:
-
-* Embedded security researchers [via Asymmetric Research](https://stacks.org/asymmetric-joins-stacks-ecosystem)
-* Attackathon programs in partnership with Immunefi
-* sBTC’s decentralized [network of validators/signers](https://www.stacks.co/sbtc) (removing the need to entrust a single entity and mitigating counterparty risk)
-* Stacks’ underlying design that offers 100% Bitcoin finality, securing sBTC at the consensus level of a $2.5 billion network.
-* Support at the app layer via [Hypernative](https://hackernoon.com/hypernative-bolsters-bitcoin-l2-security-as-stacks-ecosystem-gets-real-time-protection)
-* Bitcoin L2 Labs'[ whitehat security program](https://bitcoinl2-labs.github.io/2024/06/04/orange-hats.html)
-* Stacks Foundation's partnership with Staking Defense League,
-* Stacks Founation's ongoing[ Immunefi bug bounty program](https://immunefi.com/bug-bounty/stacks/information/)
-* Dedicated Stacks Foundation Residents focused exclusively on fuzz and penetration testing (created [Rendezvous](https://stacks-network.github.io/rendezvous/))
-
-
-
-#### Other audits
-
-{% file src="../../../.gitbook/assets/Clarity Alliance - sBTC Rewards Program (1).pdf" %}
-
-{% file src="../../../.gitbook/assets/Blockstack_Desktop_Wallet_Pentest_Report_11-12-2020.pdf" %}
-
-{% file src="../../../.gitbook/assets/NCC_Group_Stacks_Wallet_Report_2020-11-17_v1.0.pdf" %}
-
-{% file src="../../../.gitbook/assets/NCC_Group_Stacks_Blockchain_Audit_Report_2020-11-23_v1.0.pdf" %}
-
-Trail of Bits Report, Stacks Blockchain (No PDF, [Github Issues List provided](https://github.com/diwakergupta/stacks-blockchain-tob-audit/issues))
diff --git a/concepts/sbtc/README.md b/concepts/sbtc/README.md
deleted file mode 100644
index 26b2c2b1f1..0000000000
--- a/concepts/sbtc/README.md
+++ /dev/null
@@ -1,48 +0,0 @@
-## Introduction to sBTC
-
-sBTC is a SIP-010 token on the Stacks blockchain that represents Bitcoin (BTC) in a 1:1 ratio. It enables Bitcoin holders to participate in DeFi applications and other smart contract functionalities while maintaining a peg to the underlying Bitcoin.
-
-### Purpose
-
-The primary purpose of sBTC is to bridge Bitcoin to DeFi via the Stacks blockchain, providing Bitcoin holders with access to the rich functionality of smart contracts without sacrificing the security and value of their BTC holdings.
-
-### Key Benefits
-
-1. **Bitcoin Compatibility**: Allows Bitcoin holders to participate in the Stacks ecosystem without selling their BTC.
-2. **Quick Conversions**: Facilitates rapid movement between BTC and sBTC (within 3 Bitcoin blocks for deposit, 6 for withdrawal).
-3. **Decentralized Management**: Initially utilizes a set of 15 community-chosen signers for maintaining the peg wallet.
-4. **Community Governance**: Involves the community in key decisions, such as selecting the initial signing set.
-
-## Key Concepts
-
-Understanding sBTC requires familiarity with several key concepts:
-
-### sBTC
-
-sBTC is a [SIP-010](https://github.com/stacksgov/sips/blob/main/sips/sip-010/sip-010-fungible-token-standard.md) token on the Stacks Blockchain that can be converted back to BTC on the Bitcoin Blockchain. The key property of sBTC is its 1:1 peg to Bitcoin, meaning 1 sBTC is always equivalent to 1 BTC.
-
-### sBTC UTXO
-
-The sBTC UTXO is the single unspent transaction output (UTXO) on the Bitcoin blockchain that holds the entire BTC balance pegged into sBTC. This UTXO is managed and maintained by the set of sBTC Signers.
-
-### sBTC Signer
-
-In sBTC, the sBTC Signer is a signer entity separate from the Stacks Nakamoto signer. sBTC signer responsibilities include:
-
-- Signing sBTC operations
-- Communicating with the sBTC contracts on the Stacks chain
-- Managing the sBTC UTXO
-
-### sBTC Signer Set
-
-The sBTC Signer Set is the group of all sBTC signers. This set has full democratic access to the sBTC UTXO and is responsible for maintaining the security of the peg wallet. The signers also have the ability to rotate their private keys for enhanced security.
-
-### Emily API
-
-Emily is an API that helps facilitate and supervise the sBTC Bridge in addition to serving as a programmatic liaison between sBTC users and signers.
-
-### SIP-010 Token
-
-sBTC adheres to the [SIP-010](https://github.com/stacksgov/sips/blob/main/sips/sip-010/sip-010-fungible-token-standard.md) standard for fungible tokens on the Stacks blockchain. This ensures compatibility with wallets and applications that support the SIP-010 standard.
-
-Understanding these concepts is crucial for grasping the overall architecture and functionality of sBTC. In the following sections, we'll explore how these concepts come together to create sBTC.
diff --git a/concepts/sbtc/auxiliary-features/README.md b/concepts/sbtc/auxiliary-features/README.md
deleted file mode 100644
index d5adb59151..0000000000
--- a/concepts/sbtc/auxiliary-features/README.md
+++ /dev/null
@@ -1,8 +0,0 @@
-# Auxiliary Features
-
-This section covers additional features that enhance the functionality and security of the sBTC system:
-
-1. [Transaction Fee Sponsorship](fee-sponsorship.md): Allowing sBTC transactions to be sponsored
-2. [Signer Wallet Rotation](signer-wallet-rotation.md): Enabling secure key rotation for sBTC Signers
-
-These auxiliary features contribute to the overall robustness and user-friendliness of the sBTC ecosystem.
diff --git a/concepts/sbtc/auxiliary-features/fee-sponsorship.md b/concepts/sbtc/auxiliary-features/fee-sponsorship.md
deleted file mode 100644
index 406134c3ff..0000000000
--- a/concepts/sbtc/auxiliary-features/fee-sponsorship.md
+++ /dev/null
@@ -1,31 +0,0 @@
-# Transaction Fee Sponsorship
-
-Transaction Fee Sponsorship is a feature in sBTC that allows users to pay for Stacks transaction fees using sBTC instead of STX.
-
-## Overview
-
-- sBTC transactions on Stacks can be sponsored in return for some sBTC.
-- This feature improves user experience by allowing sBTC holders to use their tokens for gas fees.
-
-## Implementation
-
-The fee sponsorship system is implemented using the approach suggested in [stacks-network/stacks-core#4235](https://github.com/stacks-network/stacks-core/issues/4235).
-
-Key points:
-
-1. sBTC users can get support from existing STX holders for transaction fees.
-2. The sponsor pays the STX fee and receives sBTC in return.
-
-## User Experience
-
-From a user's perspective:
-
-1. When initiating an sBTC transaction, they can opt for fee sponsorship.
-2. The user agrees to pay a small amount of sBTC for the sponsorship.
-3. The transaction is then processed with the fees paid in STX by the sponsor.
-
-## Benefits
-
-1. **Improved UX**: Users don't need to hold STX to use sBTC.
-2. **Lower Barrier to Entry**: New users can start using sBTC without first acquiring STX.
-3. **Flexibility**: Provides an additional option for handling transaction fees.
diff --git a/concepts/sbtc/auxiliary-features/signer-wallet-rotation.md b/concepts/sbtc/auxiliary-features/signer-wallet-rotation.md
deleted file mode 100644
index 19d50bd731..0000000000
--- a/concepts/sbtc/auxiliary-features/signer-wallet-rotation.md
+++ /dev/null
@@ -1,35 +0,0 @@
-# Signer Wallet Rotation
-
-Signer wallet rotation allows sBTC signers to update their private keys and modify the signer set composition. This mechanism is how the network maintains security over time and adapts to changing participants.
-
-## How it works
-
-The sBTC system uses a multi-signature wallet on Bitcoin to custody BTC deposits. When the system needs to change who controls this wallet - either by rotating keys or changing the signer set - it uses the rotation mechanism.
-
-As of v1.1.0, the system supports:
-
-- Adding new signers to the set
-- Removing existing signers
-- Replacing specific signers
-- Rotating keys for current signers
-
-When signers agree on a new configuration, the system automatically runs a Distributed Key Generation (DKG) protocol to create new signing shares for the updated group. Once complete, control of the sBTC wallet transfers to the new configuration.
-
-## The rotation process
-
-Here's what happens during a typical rotation:
-
-1. Signers coordinate off-chain to decide on the new signer set
-2. Each signer operator updates their configuration with the newly decided set
-3. Once all signers have configured the exact same set of signers, DKG occurs automatically
-4. The new signer set takes control of the sBTC wallet
-
-The Bitcoin UTXOs remain under continuous control throughout this process - there's no moment where funds are unsecured.
-
-## When rotation occurs
-
-Key rotation typically happens when:
-
-**Signer changes**: When someone leaves the signer set or new participants join, the configuration must be updated to reflect the new membership.
-
-**Security events**: If a key might be compromised, an emergency rotation can be initiated to secure the system.
diff --git a/concepts/sbtc/clarity-contracts/README.md b/concepts/sbtc/clarity-contracts/README.md
deleted file mode 100644
index 39740f539a..0000000000
--- a/concepts/sbtc/clarity-contracts/README.md
+++ /dev/null
@@ -1,47 +0,0 @@
-# Clarity Contracts
-
-### Deployed Mainnet Contracts
-
-* [sbtc-token](https://explorer.hiro.so/txid/SM3VDXK3WZZSA84XXFKAFAF15NNZX32CTSG82JFQ4.sbtc-token?chain=mainnet)
-* [sbtc-registry](https://explorer.hiro.so/txid/SM3VDXK3WZZSA84XXFKAFAF15NNZX32CTSG82JFQ4.sbtc-registry?chain=mainnet)
-* [sbtc-deposit](https://explorer.hiro.so/txid/SM3VDXK3WZZSA84XXFKAFAF15NNZX32CTSG82JFQ4.sbtc-deposit?chain=mainnet)
-* [sbtc-withdrawal](https://explorer.hiro.so/txid/SM3VDXK3WZZSA84XXFKAFAF15NNZX32CTSG82JFQ4.sbtc-withdrawal?chain=mainnet)
-* [sbtc-bootstrap-signers](https://explorer.hiro.so/txid/SM3VDXK3WZZSA84XXFKAFAF15NNZX32CTSG82JFQ4.sbtc-bootstrap-signers?chain=mainnet)
-
-This graph summarizes the overall of the Clarity portion of the sBTC protocol.
-
-Throughout this section, we'll expand on each contract and its functionality.
-
-
-
-### sBTC Clarity Contracts
-
-At a high level, the sBTC Clarity contracts are responsible for the following:
-
-#### sbtc-bootstrap signers
-
-Core contract for meta signer functionality such as registration & the rotation process.
-
-#### sbtc-deposit
-
-Processing contract called by the signers to record a consumed Bitcoin transaction & mint some amount of sBTC to a principal contained in the payload.
-
-#### sbtc-registry
-
-State storage for maintaining upgradability across protocol.
-
-#### sbtc-withdrawal
-
-Interaction points for users and signers to update withdrawal request state.
-
-### User Types
-
-In addition to the contracts themselves, there are two main user types that will interact with these contracts.
-
-#### Signer
-
-A signer that is part of the current sBTC signer set. More information on signers and their role in sBTC can be found in the [Signer Process Walkthrough](../walkthroughs/signer-process.md).
-
-#### Wallet
-
-A participant in the Stacks/Bitcoin ecosystem that wants to deposit/withdraw/use sbtc.
diff --git a/concepts/sbtc/clarity-contracts/sbtc-bootstrap-signers.md b/concepts/sbtc/clarity-contracts/sbtc-bootstrap-signers.md
deleted file mode 100644
index d35b713e24..0000000000
--- a/concepts/sbtc/clarity-contracts/sbtc-bootstrap-signers.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-hidden: true
----
-
-# sBTC Bootstrap Signers
-
diff --git a/concepts/sbtc/clarity-contracts/sbtc-deposit.md b/concepts/sbtc/clarity-contracts/sbtc-deposit.md
deleted file mode 100644
index 9e0826fad9..0000000000
--- a/concepts/sbtc/clarity-contracts/sbtc-deposit.md
+++ /dev/null
@@ -1,83 +0,0 @@
-# sBTC Deposit Contract Documentation
-
-## Overview
-
-The [sBTC Deposit contract](https://github.com/stacks-network/sbtc/blob/main/contracts/contracts/sbtc-deposit.clar) (`sbtc-deposit.clar`) manages the deposit process for the sBTC system. It handles the validation and minting of sBTC tokens when users deposit Bitcoin, and interacts with the sBTC Registry contract to update the protocol state.
-
-## Constants
-
-- `txid-length`: The required length of a transaction ID (32 bytes).
-- `dust-limit`: The minimum amount for a valid deposit (546 satoshis).
-
-## Error Constants
-
-- `ERR_TXID_LEN` (u300): Indicates that the provided transaction ID is not the correct length.
-- `ERR_DEPOSIT_REPLAY` (u301): Signifies an attempt to replay a deposit that has already been completed.
-- `ERR_LOWER_THAN_DUST` (u302): Indicates that the deposit amount is below the dust limit.
-- `ERR_DEPOSIT_INDEX_PREFIX`: Used as a prefix for deposit-related errors in batch processing.
-- `ERR_DEPOSIT` (u303): General deposit error.
-- `ERR_INVALID_CALLER` (u304): Indicates that the caller is not authorized to perform the operation.
-
-## Public Functions
-
-### complete-deposit-wrapper
-
-Processes a single deposit request.
-
-- Parameters:
- - `txid`: `(buff 32)` - The Bitcoin transaction ID
- - `vout-index`: `uint` - The output index of the deposit transaction
- - `amount`: `uint` - The amount of sBTC to mint (in satoshis)
- - `recipient`: `principal` - The Stacks address to receive the minted sBTC
-- Returns: `(response bool uint)`
-
-Function flow:
-
-1. Verifies that the caller is the current signer principal.
-2. Checks that the deposit amount is above the dust limit.
-3. Validates the transaction ID length.
-4. Ensures the deposit hasn't been processed before (prevents replay).
-5. Mints sBTC tokens to the recipient.
-6. Updates the deposit state in the sBTC Registry contract.
-
-### complete-deposits-wrapper
-
-Processes multiple deposit requests in a single transaction.
-
-- Parameters:
- - `deposits`: `(list 650 {txid: (buff 32), vout-index: uint, amount: uint, recipient: principal})` - List of deposit data
-- Returns: `(response uint uint)`
-
-Function flow:
-
-1. Verifies that the caller is the current signer principal.
-2. Iterates through the list of deposits, processing each one using the `complete-individual-deposits-helper` function.
-
-## Private Functions
-
-### complete-individual-deposits-helper
-
-Helper function to process individual deposits within the batch operation.
-
-- Parameters:
- - `deposit`: `{txid: (buff 32), vout-index: uint, amount: uint, recipient: principal}` - Single deposit data
- - `helper-response`: `(response uint uint)` - Accumulator for tracking processed deposits
-- Returns: `(response uint uint)`
-
-Function flow:
-
-1. Calls `complete-deposit-wrapper` for the individual deposit.
-2. If successful, increments the processed deposit count.
-3. If an error occurs, it's propagated with additional index information.
-
-## Interactions with Other Contracts
-
-- `.sbtc-registry`: Calls `get-current-signer-data`, `get-completed-deposit`, and `complete-deposit` to manage deposit state.
-- `.sbtc-token`: Calls `protocol-mint` to create new sBTC tokens.
-
-## Security Considerations
-
-1. Access Control: Only the current signer principal can call the deposit completion functions.
-2. Replay Prevention: The contract checks for previously processed deposits to prevent replay attacks.
-3. Dust Limit: Enforces a minimum deposit amount to prevent spam and ensure economic viability.
-4. Transaction ID Validation: Ensures the provided transaction ID is the correct length.
diff --git a/concepts/sbtc/clarity-contracts/sbtc-registry.md b/concepts/sbtc/clarity-contracts/sbtc-registry.md
deleted file mode 100644
index c54fb2be1a..0000000000
--- a/concepts/sbtc/clarity-contracts/sbtc-registry.md
+++ /dev/null
@@ -1,204 +0,0 @@
-# sBTC Registry Contract Documentation
-
-## Overview
-
-The [sBTC Registry contract](https://github.com/stacks-network/sbtc/blob/main/contracts/contracts/sbtc-registry.clar) (`sbtc-registry.clar`) serves as the central registry for the sBTC system. It manages withdrawal requests, completed deposits, and the current signer set. This contract is crucial for maintaining the state and coordinating operations within the sBTC ecosystem.
-
-## Error Constants
-
-- `ERR_UNAUTHORIZED` (u400): Indicates unauthorized access.
-- `ERR_INVALID_REQUEST_ID` (u401): Signifies an invalid withdrawal request ID.
-- `ERR_AGG_PUBKEY_REPLAY` (u402): Indicates an attempt to replay an aggregate public key.
-- `ERR_MULTI_SIG_REPLAY` (u403): Signifies an attempt to replay a multi-signature address.
-
-## State Variables
-
-- `last-withdrawal-request-id`: Tracks the latest withdrawal request ID.
-- `current-signature-threshold`: Stores the current threshold for required signatures.
-- `current-signer-set`: Maintains a list of current signer public keys.
-- `current-aggregate-pubkey`: Holds the current aggregate public key.
-- `current-signer-principal`: Stores the current signer's principal address.
-
-## Data Maps
-
-### withdrawal-requests
-
-Stores withdrawal request details indexed by request ID.
-
-- Fields:
- - `amount`: Amount of sBTC being withdrawn (in sats)
- - `max-fee`: Maximum fee for the withdrawal
- - `sender`: Principal of the sender
- - `recipient`: BTC recipient address (version and hashbytes)
- - `block-height`: Burn block height where the request was created
-
-### withdrawal-status
-
-Tracks the status of withdrawal requests indexed by request ID.
-
-- Value: `bool` (true if accepted, false if rejected, none if pending)
-
-### completed-deposits
-
-Records completed deposit transactions to prevent replay attacks.
-
-- Key: `{txid: (buff 32), vout-index: uint}`
-- Value: `{amount: uint, recipient: principal}`
-
-### aggregate-pubkeys
-
-Tracks used aggregate public keys to prevent replay attacks.
-
-- Key: `(buff 33)` (aggregate public key)
-- Value: `bool`
-
-### multi-sig-address
-
-Tracks used multi-signature addresses to prevent replay attacks.
-
-- Key: `principal` (multi-sig address)
-- Value: `bool`
-
-### protocol-contracts
-
-Stores authorized protocol contract addresses.
-
-- Key: `principal` (contract address)
-- Value: `bool`
-
-## Read-only Functions
-
-### get-withdrawal-request
-
-Retrieves a withdrawal request by its ID.
-
-- Parameters:
- - `id`: `uint`
-- Returns: `(optional {amount: uint, max-fee: uint, sender: principal, recipient: {version: (buff 1), hashbytes: (buff 32)}, block-height: uint, status: (optional bool)})`
-
-### get-completed-deposit
-
-Fetches a completed deposit by transaction ID and output index.
-
-- Parameters:
- - `txid`: `(buff 32)`
- - `vout-index`: `uint`
-- Returns: `(optional {amount: uint, recipient: principal})`
-
-### get-current-signer-data
-
-Returns current signer set information.
-
-- Returns: `{current-signer-set: (list 128 (buff 33)), current-aggregate-pubkey: (buff 33), current-signer-principal: principal, current-signature-threshold: uint}`
-
-### get-current-aggregate-pubkey
-
-Returns the current aggregate public key.
-
-- Returns: `(buff 33)`
-
-### get-current-signer-principal
-
-Returns the current signer's principal.
-
-- Returns: `principal`
-
-### get-current-signer-set
-
-Returns the current set of signer public keys.
-
-- Returns: `(list 128 (buff 33))`
-
-## Public Functions
-
-### create-withdrawal-request
-
-Creates a new withdrawal request. Only callable by protocol contracts.
-
-- Parameters:
- - `amount`: `uint`
- - `max-fee`: `uint`
- - `sender`: `principal`
- - `recipient`: `{version: (buff 1), hashbytes: (buff 32)}`
- - `height`: `uint`
-- Returns: `(response uint uint)`
-
-### complete-withdrawal-accept
-
-Marks a withdrawal request as accepted.
-
-- Parameters:
- - `request-id`: `uint`
- - `bitcoin-txid`: `(buff 32)`
- - `output-index`: `uint`
- - `signer-bitmap`: `uint`
- - `fee`: `uint`
-- Returns: `(response bool uint)`
-
-### complete-withdrawal-reject
-
-Marks a withdrawal request as rejected.
-
-- Parameters:
- - `request-id`: `uint`
- - `signer-bitmap`: `uint`
-- Returns: `(response bool uint)`
-
-### complete-deposit
-
-Records a completed deposit transaction.
-
-- Parameters:
- - `txid`: `(buff 32)`
- - `vout-index`: `uint`
- - `amount`: `uint`
- - `recipient`: `principal`
-- Returns: `(response bool uint)`
-
-### rotate-keys
-
-Updates the signer set, multi-sig principal, and aggregate public key.
-
-- Parameters:
- - `new-keys`: `(list 128 (buff 33))`
- - `new-address`: `principal`
- - `new-aggregate-pubkey`: `(buff 33)`
- - `new-signature-threshold`: `uint`
-- Returns: `(response (buff 33) uint)`
-
-## Private Functions
-
-### increment-last-withdrawal-request-id
-
-Increments and returns the next withdrawal request ID.
-
-- Returns: `uint`
-
-### is-protocol-caller
-
-Checks if the caller is an authorized protocol contract.
-
-- Returns: `(response bool uint)`
-
-### validate-protocol-caller
-
-Validates if a given principal is an authorized protocol contract.
-
-- Parameters:
- - `caller`: `principal`
-- Returns: `(response bool uint)`
-
-## Events
-
-The contract emits events (via `print`) for important actions:
-
-- Withdrawal request creation: "withdrawal-create"
-- Withdrawal acceptance: "withdrawal-accept"
-- Withdrawal rejection: "withdrawal-reject"
-- Deposit completion: "completed-deposit"
-
-## Security Considerations
-
-1. Access Control: Only authorized protocol contracts can call certain functions.
-2. Replay Prevention: The contract prevents replay attacks on deposits, aggregate public keys, and multi-signature addresses.
-3. State Management: The contract carefully manages the state of withdrawals and the current signer set.
diff --git a/concepts/sbtc/clarity-contracts/sbtc-signers.md b/concepts/sbtc/clarity-contracts/sbtc-signers.md
deleted file mode 100644
index ab1c7edd31..0000000000
--- a/concepts/sbtc/clarity-contracts/sbtc-signers.md
+++ /dev/null
@@ -1,125 +0,0 @@
-# sBTC Signers Contract Documentation
-
-## Overview
-
-The [sBTC Signers contract](https://github.com/stacks-network/sbtc/blob/main/contracts/contracts/sbtc-bootstrap-signers.clar) (`sbtc-bootstrap-signers.clar`) manages the signer set for the sBTC system. It handles the rotation of signer keys and provides utilities for generating multisig addresses.
-
-## Constants
-
-- `key-size`: The required length of public keys (33 bytes).
-
-## Error Constants
-
-- `ERR_KEY_SIZE_PREFIX`: Prefix for key size errors in batch processing.
-- `ERR_KEY_SIZE` (u200): Indicates that a provided key is not the correct length.
-- `ERR_INVALID_CALLER` (u201): Signifies that the function caller is not the current signer principal.
-- `ERR_SIGNATURE_THRESHOLD` (u202): Indicates an invalid signature threshold (must be >50% and ≤100% of total signer keys).
-
-## Public Functions
-
-### rotate-keys-wrapper
-
-Rotates the keys of the signers. Called when the signer set is updated.
-
-- Parameters:
- - `new-keys`: `(list 128 (buff 33))` - List of new signer public keys
- - `new-aggregate-pubkey`: `(buff 33)` - New aggregate public key
- - `new-signature-threshold`: `uint` - New signature threshold
-- Returns: `(response (buff 33) uint)`
-
-Function flow:
-
-1. Validates the new signature threshold.
-2. Verifies that the caller is the current signer principal.
-3. Checks the length of each new key and the aggregate public key.
-4. Calls the sBTC Registry contract to update the keys and address.
-
-## Read-only Functions
-
-### pubkeys-to-spend-script
-
-Generates the p2sh redeem script for a multisig.
-
-- Parameters:
- - `pubkeys`: `(list 128 (buff 33))` - List of public keys
- - `m`: `uint` - Number of required signatures
-- Returns: `(buff 1024)` - The p2sh redeem script
-
-### pubkeys-to-hash
-
-Computes the hash160 of the p2sh redeem script.
-
-- Parameters:
- - `pubkeys`: `(list 128 (buff 33))` - List of public keys
- - `m`: `uint` - Number of required signatures
-- Returns: `(buff 20)` - The hash160 of the redeem script
-
-### pubkeys-to-principal
-
-Generates a principal (Stacks address) from a set of pubkeys and an m-of-n threshold.
-
-- Parameters:
- - `pubkeys`: `(list 128 (buff 33))` - List of public keys
- - `m`: `uint` - Number of required signatures
-- Returns: `principal` - The generated Stacks address
-
-### pubkeys-to-bytes
-
-Concatenates a list of pubkeys into a buffer with length prefixes.
-
-- Parameters:
- - `pubkeys`: `(list 128 (buff 33))` - List of public keys
-- Returns: `(buff 510)` - Concatenated pubkeys with length prefixes
-
-### concat-pubkeys-fold
-
-Concatenates a pubkey buffer with a length prefix.
-
-- Parameters:
- - `pubkey`: `(buff 33)` - A single public key
- - `iterator`: `(buff 510)` - Accumulator for concatenation
-- Returns: `(buff 510)` - Updated concatenated buffer
-
-### bytes-len
-
-Returns the length of a byte buffer as a single byte.
-
-- Parameters:
- - `bytes`: `(buff 33)` - Input byte buffer
-- Returns: `(buff 1)` - Length as a single byte
-
-### uint-to-byte
-
-Converts a uint to a single byte.
-
-- Parameters:
- - `n`: `uint` - Input number
-- Returns: `(buff 1)` - Number as a single byte
-
-## Private Functions
-
-### signer-key-length-check
-
-Checks that the length of each key is exactly 33 bytes.
-
-- Parameters:
- - `current-key`: `(buff 33)` - Public key to check
- - `helper-response`: `(response uint uint)` - Accumulator for error handling
-- Returns: `(response uint uint)` - Updated accumulator or error
-
-## Constants
-
-### BUFF_TO_BYTE
-
-A constant list mapping uint values (0-255) to their corresponding byte representations.
-
-## Interactions with Other Contracts
-
-- `.sbtc-registry`: Calls `get-current-signer-data` and `rotate-keys` to manage signer data.
-
-## Security Considerations
-
-1. Access Control: Only the current signer principal can call the key rotation function.
-2. Key Validation: Ensures all provided keys are the correct length.
-3. Signature Threshold: Enforces a minimum threshold of over 50% of signers and a maximum of 100%.
-4. Multisig Generation: Provides utilities for secure generation of multisig addresses.
diff --git a/concepts/sbtc/clarity-contracts/sbtc-token.md b/concepts/sbtc/clarity-contracts/sbtc-token.md
deleted file mode 100644
index eb2e942478..0000000000
--- a/concepts/sbtc/clarity-contracts/sbtc-token.md
+++ /dev/null
@@ -1,175 +0,0 @@
-# sBTC Token Contract Documentation
-
-## Overview
-
-The [sBTC Token contract](https://github.com/stacks-network/sbtc/blob/main/contracts/contracts/sbtc-token.clar) (`sbtc-token.clar`) implements the fungible token functionality for sBTC. It manages both unlocked and locked sBTC tokens and provides functions for minting, burning, transferring, and querying token information. sBTC is a SIP-010 standard fungible token.
-
-## Constants
-
-- `ERR_NOT_OWNER` (u4): Error when the sender tries to move a token they don't own.
-- `ERR_NOT_AUTH` (u5): Error when the caller is not an authorized protocol caller.
-- `token-decimals` (u8): The number of decimal places for the token.
-
-## Fungible Tokens
-
-- `sbtc-token`: The main sBTC fungible token.
-- `sbtc-token-locked`: Represents locked sBTC tokens.
-
-## Data Variables
-
-- `token-name`: The name of the token (default: "sBTC").
-- `token-symbol`: The symbol of the token (default: "sBTC").
-- `token-uri`: An optional URI for token metadata.
-
-## Protocol Functions
-
-These functions can only be called by authorized protocol contracts:
-
-### protocol-transfer
-
-Transfers tokens between principals.
-
-- Parameters: `amount: uint`, `sender: principal`, `recipient: principal`
-- Returns: `(response bool uint)`
-
-### protocol-lock
-
-Locks a specified amount of tokens for a user.
-
-- Parameters: `amount: uint`, `owner: principal`
-- Returns: `(response bool uint)`
-
-### protocol-unlock
-
-Unlocks a specified amount of tokens for a user.
-
-- Parameters: `amount: uint`, `owner: principal`
-- Returns: `(response bool uint)`
-
-### protocol-mint
-
-Mints new tokens for a recipient.
-
-- Parameters: `amount: uint`, `recipient: principal`
-- Returns: `(response bool uint)`
-
-### protocol-burn
-
-Burns tokens from an owner's balance.
-
-- Parameters: `amount: uint`, `owner: principal`
-- Returns: `(response bool uint)`
-
-### protocol-burn-locked
-
-Burns locked tokens from an owner's balance.
-
-- Parameters: `amount: uint`, `owner: principal`
-- Returns: `(response bool uint)`
-
-### protocol-set-name
-
-Sets a new name for the token.
-
-- Parameters: `new-name: (string-ascii 32)`
-- Returns: `(response bool uint)`
-
-### protocol-set-symbol
-
-Sets a new symbol for the token.
-
-- Parameters: `new-symbol: (string-ascii 10)`
-- Returns: `(response bool uint)`
-
-### protocol-set-token-uri
-
-Sets a new URI for the token metadata.
-
-- Parameters: `new-uri: (optional (string-utf8 256))`
-- Returns: `(response bool uint)`
-
-### protocol-mint-many
-
-Mints tokens for multiple recipients in a single transaction.
-
-- Parameters: `recipients: (list 200 {amount: uint, recipient: principal})`
-- Returns: `(response (list 200 (response bool uint)) uint)`
-
-## Public Functions (SIP-010 Trait)
-
-### transfer
-
-Transfers tokens between users.
-
-- Parameters: `amount: uint`, `sender: principal`, `recipient: principal`, `memo: (optional (buff 34))`
-- Returns: `(response bool uint)`
-
-### get-name
-
-Returns the token name.
-
-- Returns: `(response (string-ascii 32) uint)`
-
-### get-symbol
-
-Returns the token symbol.
-
-- Returns: `(response (string-ascii 10) uint)`
-
-### get-decimals
-
-Returns the number of decimal places.
-
-- Returns: `(response uint uint)`
-
-### get-balance
-
-Returns the total balance (locked + unlocked) for a principal.
-
-- Parameters: `who: principal`
-- Returns: `(response uint uint)`
-
-### get-balance-available
-
-Returns the available (unlocked) balance for a principal.
-
-- Parameters: `who: principal`
-- Returns: `(response uint uint)`
-
-### get-balance-locked
-
-Returns the locked balance for a principal.
-
-- Parameters: `who: principal`
-- Returns: `(response uint uint)`
-
-### get-total-supply
-
-Returns the total supply of tokens (locked + unlocked).
-
-- Returns: `(response uint uint)`
-
-### get-token-uri
-
-Returns the token metadata URI.
-
-- Returns: `(response (optional (string-utf8 256)) uint)`
-
-## Private Functions
-
-### protocol-mint-many-iter
-
-Helper function for minting tokens to multiple recipients.
-
-- Parameters: `item: {amount: uint, recipient: principal}`
-- Returns: `(response bool uint)`
-
-## Security Considerations
-
-1. Access Control: Protocol functions can only be called by authorized contracts, enforced through the `sbtc-registry` contract.
-2. Ownership Verification: The `transfer` function checks that the sender owns the tokens being transferred.
-3. Separate Token Tracking: The contract maintains separate tracking for locked and unlocked tokens, ensuring proper accounting.
-
-## Interactions with Other Contracts
-
-- `.sbtc-registry`: Used to validate protocol callers for privileged operations.
diff --git a/concepts/sbtc/clarity-contracts/sbtc-withdrawal.md b/concepts/sbtc/clarity-contracts/sbtc-withdrawal.md
deleted file mode 100644
index 00f3910a5e..0000000000
--- a/concepts/sbtc/clarity-contracts/sbtc-withdrawal.md
+++ /dev/null
@@ -1,115 +0,0 @@
-# sBTC Withdrawal Contract Documentation
-
-## Overview
-
-The [sBTC Withdrawal contract](https://github.com/stacks-network/sbtc/blob/main/contracts/contracts/sbtc-withdrawal.clar) (`sbtc-withdrawal.clar`) manages the withdrawal process for the sBTC system. It handles the initiation, acceptance, and rejection of withdrawal requests, ensuring proper validation and interaction with other sBTC contracts.
-
-## Constants
-
-### Error Codes
-
-- `ERR_INVALID_ADDR_VERSION` (u500): Invalid address version.
-- `ERR_INVALID_ADDR_HASHBYTES` (u501): Invalid address hashbytes.
-- `ERR_DUST_LIMIT` (u502): Withdrawal amount below dust limit.
-- `ERR_INVALID_REQUEST` (u503): Invalid withdrawal request ID.
-- `ERR_INVALID_CALLER` (u504): Caller is not the current signer principal.
-- `ERR_ALREADY_PROCESSED` (u505): Withdrawal request already processed.
-- `ERR_FEE_TOO_HIGH` (u505): Paid fee higher than requested.
-- `ERR_WITHDRAWAL_INDEX_PREFIX`: Prefix for withdrawal index errors.
-- `ERR_WITHDRAWAL_INDEX` (u506): General withdrawal index error.
-
-### Other Constants
-
-- `MAX_ADDRESS_VERSION` (u6): Maximum value of an address version.
-- `MAX_ADDRESS_VERSION_BUFF_20` (u4): Maximum version for 20-byte hashbytes.
-- `MAX_ADDRESS_VERSION_BUFF_32` (u6): Maximum version for 32-byte hashbytes.
-- `DUST_LIMIT` (u546): Minimum amount of sBTC for withdrawal.
-
-## Public Functions
-
-### initiate-withdrawal-request
-
-Initiates a new withdrawal request.
-
-- Parameters:
- - `amount`: `uint` - Amount of sBTC to withdraw
- - `recipient`: `{ version: (buff 1), hashbytes: (buff 32) }` - Bitcoin address details
- - `max-fee`: `uint` - Maximum fee for the withdrawal
-- Returns: `(response uint uint)`
-
-### accept-withdrawal-request
-
-Accepts a withdrawal request.
-
-- Parameters:
- - `request-id`: `uint` - Withdrawal request ID
- - `bitcoin-txid`: `(buff 32)` - Bitcoin transaction ID
- - `signer-bitmap`: `uint` - Bitmap of signers
- - `output-index`: `uint` - Output index in the Bitcoin transaction
- - `fee`: `uint` - Actual fee paid
-- Returns: `(response bool uint)`
-
-### reject-withdrawal-request
-
-Rejects a withdrawal request.
-
-- Parameters:
- - `request-id`: `uint` - Withdrawal request ID
- - `signer-bitmap`: `uint` - Bitmap of signers
-- Returns: `(response bool uint)`
-
-### complete-withdrawals
-
-Processes multiple withdrawal requests (accept or reject).
-
-- Parameters:
- - `withdrawals`: `(list 600 {...})` - List of withdrawal details
-- Returns: `(response uint uint)`
-
-## Read-only Functions
-
-### validate-recipient
-
-Validates the recipient's Bitcoin address format.
-
-- Parameters:
- - `recipient`: `{ version: (buff 1), hashbytes: (buff 32) }` - Bitcoin address details
-- Returns: `(response bool uint)`
-
-## Private Functions
-
-### complete-individual-withdrawal-helper
-
-Helper function to process individual withdrawals in the batch operation.
-
-- Parameters:
- - `withdrawal`: `{...}` - Individual withdrawal details
- - `helper-response`: `(response uint uint)` - Accumulator for processing
-- Returns: `(response uint uint)`
-
-## Interactions with Other Contracts
-
-- `.sbtc-token`: Calls `protocol-lock`, `protocol-burn-locked`, `protocol-mint`, and `protocol-unlock` for token operations.
-- `.sbtc-registry`: Calls `create-withdrawal-request`, `get-withdrawal-request`, `get-current-signer-data`, `complete-withdrawal-accept`, and `complete-withdrawal-reject` for managing withdrawal requests and signer data.
-
-## Security Considerations
-
-1. Access Control: Only the current signer principal can accept or reject withdrawal requests.
-2. Dust Limit: Enforces a minimum withdrawal amount to prevent spam and ensure economic viability.
-3. Fee Management: Ensures that the actual fee doesn't exceed the maximum fee set by the user.
-4. Address Validation: Implements thorough validation of Bitcoin address formats.
-5. State Management: Prevents double-processing of withdrawal requests.
-
-## Bitcoin Address Types
-
-The contract supports various Bitcoin address types, including:
-
-- P2PKH (Pay-to-Public-Key-Hash)
-- P2SH (Pay-to-Script-Hash)
-- P2SH-P2WPKH (P2SH nested P2WPKH)
-- P2SH-P2WSH (P2SH nested P2WSH)
-- P2WPKH (Pay-to-Witness-Public-Key-Hash)
-- P2WSH (Pay-to-Witness-Script-Hash)
-- P2TR (Pay-to-Taproot)
-
-Each address type is represented by a specific version byte and hashbytes format in the recipient structure.
diff --git a/concepts/sbtc/core-features.md b/concepts/sbtc/core-features.md
deleted file mode 100644
index f318f968e3..0000000000
--- a/concepts/sbtc/core-features.md
+++ /dev/null
@@ -1,36 +0,0 @@
-# Core Features of sBTC
-
-sBTC offers several core features that make it a powerful trust-minimized Bitcoin bridge between Stacks and Bitcoin:
-
-## 1. 1:1 Bitcoin Backing
-
-Each sBTC token is backed by an equivalent amount of Bitcoin in the peg wallet. This ensures that sBTC maintains a stable value relative to BTC.
-
-## 2. Decentralized Management
-
-The sBTC peg wallet is maintained and managed by a set of sBTC signers. This decentralized approach enhances security and reduces single points of failure.
-
-## 3. Quick Conversions
-
-sBTC facilitates rapid movement between BTC and sBTC:
-
-- BTC to sBTC conversion can be completed within 3 Bitcoin blocks
-- sBTC to BTC conversion can be completed within 6 Bitcoin blocks
-
-## 4. SIP-010 Compatibility
-
-sBTC adheres to the SIP-010 fungible token standard on the Stacks blockchain. This ensures wide compatibility with Stacks wallets and applications.
-
-## 5. Community Governance
-
-The initial sBTC signing set is determined by a community vote, weighted by STX holdings. This approach ensures that the community has a say in the management of the sBTC system.
-
-## 6. Signer Key Rotation
-
-sBTC signers have the ability to rotate their private keys, enhancing long-term security of the system.
-
-## 7. Transaction Fee Sponsorship
-
-sBTC transactions on Stacks can be sponsored, allowing users to pay transaction fees in sBTC instead of STX.
-
-These core features work together to create a secure, efficient, and user-friendly bridge between Bitcoin and the Stacks ecosystem.
diff --git a/concepts/sbtc/emily.md b/concepts/sbtc/emily.md
deleted file mode 100644
index 0f5493159d..0000000000
--- a/concepts/sbtc/emily.md
+++ /dev/null
@@ -1,61 +0,0 @@
-# Emily API
-
-[Emily](https://github.com/stacks-network/sbtc/tree/main/emily) is an API that helps facilitate and supervise the sBTC Bridge, serving as a programmatic liaison between sBTC users and signers.
-
-## Overview
-
-The Emily API is designed to track deposits and withdrawals, providing information about the status of in-flight sBTC operations. It serves two primary user groups: sBTC users and sBTC app developers.
-
-## Why Emily?
-
-The Emily API is given an indirect name because it handles more than just Deposits and Withdrawals; it can detect the health of the system and will likely be extended to handle more as user requirements mature. It was once called the “Revealer API”, which stopped making sense after a few design changes, and then “Deposit API” which also stopped making sense after a few changes. The most obvious choice “sBTC API” gives the wrong impression of what the API is responsible for as well, since the API itself isn’t managing the entirety of the protocol.
-
-Large companies name their APIs after something loosely related but ambiguous enough that extensions of the API don’t make the original name of the API misleading. Following this, we chose “Emily” after Emily Warren Roebling who was the liaison between the builders and chief engineer, her husband, of the Brooklyn bridge. She was, in effect, the supervisor of the bridge’s construction; similarly, the Emily API supervises the sBTC bridge and liaises between the users of the protocol and the sBTC signers.
-
-## Key Features
-
-1. **Track Deposits**: Monitor the process of converting BTC to sBTC.
-2. **Track Withdrawals**: Monitor the process of converting sBTC back to BTC.
-3. **Provide Operation Status**: Offer real-time status updates for ongoing sBTC operations.
-4. **Retrieve Historical Data**: Allow querying of past sBTC operations.
-
-## Core Concepts
-
-### sBTC Operations
-
-sBTC operations are the fundamental processes tracked by Emily:
-
-1. **Deposits**: Converting BTC to sBTC
-2. **Withdrawals**: Converting sBTC back to BTC
-
-### Operation States
-
-Each sBTC operation goes through several states:
-
-1. **PENDING**: The operation has been initiated.
-2. **ACCEPTED**: The operation has been approved by the signers.
-3. **CONFIRMED**: The operation has been completed and confirmed on the blockchain.
-4. **FAILED**: The operation could not be completed.
-
-## Interaction Flows
-
-### Deposit Flow
-
-1. User creates a deposit transaction on Bitcoin.
-2. User submits proof of deposit to the Deposit API.
-3. Emily records the deposit as PENDING.
-4. Signers validate and vote on the deposit.
-5. If accepted, Emily updates status to ACCEPTED.
-6. Signers process the Bitcoin transaction.
-7. Signers mint sBTC on Stacks.
-8. Emily updates the deposit status to CONFIRMED.
-
-### Withdrawal Flow
-
-1. User initiates withdrawal through the sBTC Clarity contract.
-2. Emily records the withdrawal as PENDING.
-3. Signers decide to accept or reject the withdrawal.
-4. If accepted, Emily updates status to ACCEPTED.
-5. Signers process the Bitcoin transaction.
-6. Signers burn sBTC on Stacks.
-7. Emily updates the withdrawal status to CONFIRMED.
diff --git a/concepts/sbtc/operations/README.md b/concepts/sbtc/operations/README.md
deleted file mode 100644
index 7ef0469189..0000000000
--- a/concepts/sbtc/operations/README.md
+++ /dev/null
@@ -1,8 +0,0 @@
-# sBTC Operations
-
-This section covers the main operations in the sBTC system:
-
-1. [Deposit](deposit.md): Converting BTC to sBTC
-2. [Withdrawal](withdrawal.md): Converting sBTC back to BTC
-
-These operations form the core functionality of sBTC, allowing users to move value between the Bitcoin and Stacks ecosystems.
diff --git a/concepts/sbtc/operations/deposit-withdrawal-times.md b/concepts/sbtc/operations/deposit-withdrawal-times.md
deleted file mode 100644
index ba1ea76fff..0000000000
--- a/concepts/sbtc/operations/deposit-withdrawal-times.md
+++ /dev/null
@@ -1,31 +0,0 @@
-# sBTC Withdrawal Time vs Deposit Time
-
-## Why are Deposits So Fast and Withdrawals So Slow?
-
-sBTC allows users to use their BTC on the Stacks L2 by using a wrapped token called sBTC. Moving sBTC onto the Stacks L2 can take as little time as 1 Bitcoin block, but moving sBTC off the Stacks L2 into the native Bitcoin blockchain takes 6 Bitcoin blocks. Why is that?
-
-To understand why moving onto the Stacks layer can be so fast and yet moving off must be so slow, we need to first understand the consensus mechanism of the Stacks blockchain.
-
-The Stacks blockchain uses a consensus mechanism called proof of transfer, or PoX, in order to mint new blocks. On each Bitcoin block miners on the Stacks blockchain each sacrifice some amount of Bitcoin in a bid to win the right to make the next few Stacks blocks, where they retain the right to keep making Stacks blocks until the next Bitcoin block occurs and the latest bidding round elects a new Miner. Signers (validators equivalents for the Stacks Blockchain) look at the Bitcoin blocks and approve new Stacks blocks based on which miner currently has the right to make Stacks blocks, and they only approve new blocks from the Signers that won the most recent bid on the Bitcoin block within the fork that they collectively consider to be the “best”. The Stacks blockchain can only have new blocks added if the Signers agree that the miner who proposed it is the winner of the bid on the Bitcoin blockchain, and all the Signers are voting on which block should be added, effectively collectively deciding which Bitcoin fork is the best one.
-
-Here’s an important part: if the Signers believe that there’s a new and better Bitcoin fork that differs from the one that the last several Stacks blocks had been mined on, they’ll then only approve new Stacks blocks that build off of Stacks blocks that are tied to that new fork. As in, every Stacks block that was built on Bitcoin Blocks in the other Bitcoin fork that aren’t in this new fork are considered invalid; thus the Stacks blockchain forks too.
-
-A simple way to say this: “The Stacks blockchain forks with the Bitcoin blockchain.”
-
-Now that we understand this forking mechanism, let's take a look at why moving off the Stacks layer must be so slow.
-
-sBTC exists on the Stacks layer as a token that smart contracts can interact with. To move sBTC over from the Stacks layer to the Bitcoin layer the owner of the sBTC calls a smart contract to initiate what we call the “withdrawal” sequence. This lets the “sBTC Signers” (these are different from the earlier Signers mentioned, sorry) know that they need to create a transaction on the Bitcoin blockchain to distribute the BTC back to the user.
-
-If the signers create a Bitcoin transaction to enact the withdrawal they can’t take it back, and it will be valid on every fork of the Bitcoin blockchain. So what happens if, say, the bitcoin blockchain forks and the withdrawal on the Stacks layer got reorganized out? Then there’s an irretrievable withdrawal transaction on the Bitcoin blockchain giving precious BTC to a user who never withdrew their sBTC on the Stacks layer.
-
-"Can the Signers that maintain the original chain force miners to replay all previously confirmed transactions?" It's worth asking to learn more about withdrawal process. The Stacks blockchain is a true Layer 2 on top of Bitcoin, and you can write a smart contract to have different behavior based on observations of the Bitcoin blockchain underneath. You can, for example, write a Stacks contract that says “Pay to Jeff if the latest Bitcoin block hash ends in an even hex digit, and pay to Abigail if it’s an odd hex digit.” Now when there’s a reorg of the Bitcoin blockchain you can replay this transaction which originally paid to Jeff, but it now pays to Abigail, and what happens if this contract was giving out sBTC, and further what happens if Jeff then immediately executed a withdrawal?
-
-So in the end, to process a withdrawal safely you need to be sufficiently sure it won’t get reorganized out. That means it can only be processed 6 Bitcoin blocks (the finality criteria the Signers are comfortable with) after the withdrawal was made on the Stacks blockchain.
-
-But then, why can deposits be done in one Bitcoin block at its fastest?
-
-Remember how Stacks forks with Bitcoin? Let's say someone makes a deposit on the Bitcoin blockchain in an attempt to mint sBTC, and then lets say the sBTC Signers immediately mint sBTC. What happens if the Bitcoin chain forks causing the Stacks blockchain to fork? The mint gets reorganized out! Sure, the deposit is no longer on the Bitcoin blockchain, but it’s not on the Stacks blockchain either. If that deposit doesn’t ever arrive on the Bitcoin blockchain the sBTC signers will never mint sBTC, so there’s nothing to take back!
-
-So all in all, for movements of sBTC from the Stacks layer into the Bitcoin layer the protocol needs to wait for Bitcoin to be sufficiently final, but movements from the Bitcoin layer to the Stacks layer don’t need to wait for finality to mint because the Stacks layer will just reorganized itself if the Bitcoin layer reorganizes too.
-
-But then conceptually remember, the mint call on the Stacks blockchain is just as final as the Bitcoin block that contains the deposit of BTC onto the Stacks layer. If you’re minting sBTC on the Stacks layer and you want to wait for it to be final you’ll need to wait a suitable number of Bitcoin blocks to consider it finally minted, but that’s up to you and not the sBTC Signers.
diff --git a/concepts/sbtc/operations/deposit.md b/concepts/sbtc/operations/deposit.md
deleted file mode 100644
index 10df3ae355..0000000000
--- a/concepts/sbtc/operations/deposit.md
+++ /dev/null
@@ -1,26 +0,0 @@
-# Deposit
-
-The deposit operation enables users to mint sBTC, anchored to the BTC they have placed in the threshold wallet on the Bitcoin chain. This process can be completed within a single Bitcoin block, streamlining the user experience.
-
-## Process Overview
-
-
-
-The deposit process begins when a user initiates specific Bitcoin transaction that has two outputs:
-
-1. Script that lets the signers spend it
-2. Time lock to allow the depositor to reclaim
-
-Next, the depositor (usually through the application they are using to deposit) initiates an API call referencing that Bitcoin transaction. This call triggers the Emily API, which plays a crucial role by relaying deposit information to the sBTC Signers. These signers are responsible for verifying and processing the deposit. Once verified, an equivalent amount of sBTC is minted on the Stacks blockchain.
-
-The deposit is usually completed within a single Bitcoin block, but is guaranteed to be completed within 3. For more information on deposit and withdrawal confirmation times and why deposits can be so fast, check out the [Deposit and Withdrawal Times](deposit-withdrawal-times.md) doc.
-
-## Bitcoin Deposit Requirements
-
-For a deposit to be considered valid, it must adhere to specific requirements. The deposit must be made to a taproot address and be spendable by a consensus threshold of signers. Additionally, the deposit must follow a specific format that prevents short-term clawbacks, ensuring the security and integrity of the system.
-
-## User Experience
-
-From a user's perspective, the deposit process is straightforward. Users initiate a BTC transaction to a specified address and then wait for the transaction to be confirmed on the Bitcoin blockchain. Once confirmed, they receive the equivalent amount of sBTC in their Stacks wallet.
-
-To enhance the user experience, a sBTC bridge web application is currently in development which will provide an intuitive interface for users to track the status of their deposit operations. This allows users to stay informed throughout the process, from initiation to completion.
diff --git a/concepts/sbtc/operations/withdrawal.md b/concepts/sbtc/operations/withdrawal.md
deleted file mode 100644
index 377ded5dd1..0000000000
--- a/concepts/sbtc/operations/withdrawal.md
+++ /dev/null
@@ -1,29 +0,0 @@
-# Withdrawal
-
-The sBTC withdrawal operation enables users to convert their sBTC back to BTC. This process involves burning sBTC on the Stacks blockchain and releasing an equivalent amount of BTC on the Bitcoin blockchain.
-
-## Process Overview
-
-
-
-The withdrawal process begins when a user initiates a Clarity contract call. This call triggers a series of events that culminate in the user receiving BTC in their specified Bitcoin address. The process requires six Bitcoin block confirmations to complete. After these confirmations, sBTC Signers create the withdrawal transaction on the Bitcoin network.
-
-## Withdrawal Confirmation
-
-The requirement for six block confirmations serves multiple important purposes. First, it ensures the finality of the Stacks transaction, preventing any potential reversals or conflicts. Second, it mitigates issues that could arise from potential Bitcoin forks by allowing sufficient time for network stability. Lastly, it provides sBTC Signers with ample time to verify and process the withdrawal request accurately.
-
-For more information on deposit and withdrawal confirmation times and why deposits can be so much faster than withdrawals, check out the [Deposit and Withdrawal Times](deposit-withdrawal-times.md) doc.
-
-## Failure Cases
-
-While some withdrawal failures can be identified and resolved before the six confirmations are complete, others may only become apparent after the sBTC Bootstrap Signer attempts to create the withdrawal transaction on the Bitcoin network. This delay in failure detection is due to the complex nature of cross-chain operations and the need for thorough verification at each step.
-
-## Security Considerations
-
-The multi-block confirmation process is a crucial security measure that helps prevent double-spending attempts. By requiring multiple block confirmations, the system ensures that the withdrawal request is valid and final before processing it on the Bitcoin network. Additionally, sBTC Signers verify each withdrawal request before processing it, adding an extra layer of security.
-
-## User Experience
-
-From a user's perspective, the withdrawal process is designed to be straightforward and transparent. Users initiate a withdrawal request through a Stacks wallet or decentralized application (dApp). During this process, they specify the amount of sBTC they wish to withdraw and provide the destination Bitcoin address where they want to receive their BTC. After submitting the request, users must wait for the required six blocks to complete. Once confirmed, the BTC is sent to the specified Bitcoin address.
-
-To enhance user experience and provide clarity throughout the process, the sBTC bridge web application offers a user-friendly interface. This interface allows users to track the status of their withdrawal operations in real-time, providing updates at each stage of the process. This transparency helps users understand the progress of their withdrawal and anticipate when they can expect to receive their BTC.
diff --git a/concepts/sbtc/peg-wallet-utxo.md b/concepts/sbtc/peg-wallet-utxo.md
deleted file mode 100644
index a747c6b7c1..0000000000
--- a/concepts/sbtc/peg-wallet-utxo.md
+++ /dev/null
@@ -1,13 +0,0 @@
-# Peg Wallet UTXO
-
-The Peg Wallet UTXO is a fundamental element of the sBTC system, serving as the Bitcoin backing for all sBTC tokens in circulation. This system employs a Single UTXO Model, where the sBTC peg wallet is consistently represented as a single Unspent Transaction Output (UTXO) on the Bitcoin blockchain. This design choice offers simplicity and improved efficiency in managing the peg wallet.
-
-UTXO management falls under the responsibility of the Signer set. First, a Signer coordinator constructs the UTXO. Then the Signer set collectively consolidates all deposit and withdrawal requests, creating optimized batches that can be processed within a single UTXO. The new UTXO is created by spending the amount from the previous UTXO, adding confirmed deposits, and subtracting confirmed withdrawals.
-
-The batching process is carefully optimized to maintain the single UTXO invariant while creating optimal batches. When multiple sBTC operation requests are present, the Signer coordinator groups them by approval sets. In scenarios where differing approval sets exist across active sBTC operations, the coordinator batches deposit UTXOs into groups with the maximum size per approval set.
-
-This Single UTXO Model offers several advantages. It simplifies tracking and management, reduces the number of Bitcoin transactions required for sBTC operations, and centralizes funds in a single, well-secured output. These benefits contribute to the overall efficiency and security of the sBTC system.
-
-Security is a paramount concern in this model. The single UTXO is managed by the sBTC Bootstrap Signer Set, which requires a threshold of signers to approve any spending. This multi-signature approach adds an extra layer of protection to the funds. Additionally, regular audits and continuous monitoring are essential to ensure that the UTXO accurately represents the total sBTC in circulation at all times.
-
-By employing this streamlined approach, the Peg Wallet UTXO system maintains a balance between simplicity, efficiency, and security, forming a robust foundation for the sBTC ecosystem.
diff --git a/concepts/sbtc/sbtc-audits.md b/concepts/sbtc/sbtc-audits.md
deleted file mode 100644
index 0dbb6c00f2..0000000000
--- a/concepts/sbtc/sbtc-audits.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# sBTC Audits
-
-Several third-party security audits have been conducted on the sBTC system and can be referenced here.
-
-{% file src="../../.gitbook/assets/Clarity Alliance - sBTC-2.pdf" %}
-
-{% file src="../../.gitbook/assets/CoinFabrik_WSTS.pdf" %}
-
-{% file src="../../.gitbook/assets/Ottersec - stacks_sbtc_audit_final.pdf" %}
-
-{% file src="../../.gitbook/assets/Ottersec - stacks_wsts_audit_final.pdf" %}
diff --git a/concepts/sbtc/sbtc-faq.md b/concepts/sbtc/sbtc-faq.md
deleted file mode 100644
index f32e548adc..0000000000
--- a/concepts/sbtc/sbtc-faq.md
+++ /dev/null
@@ -1,277 +0,0 @@
-# sBTC FAQ
-
-### sBTC Basics
-
-
-
-What is sBTC?
-
-sBTC is a decentralizedl 1:1 Bitcoin-backed asset on the Stacks Bitcoin Layer. Read more about Stacks [here](https://www.stacks.co) and sBTC [here](https://www.stacks.co/sbtc).
-
-
-
-
-
-How does sBTC work?
-
-1. sBTC is a SIP-010 token on the Stacks blockchain that represents Bitcoin (BTC) in a 1:1 ratio. sBTC is always backed 1:1 against BTC.
-2. The sBTC peg wallet is maintained and managed by a set of sBTC signers. This decentralized approach enhances security and reduces single points of failure. Read more about Stacker Signing [here](https://docs.stacks.co/concepts/block-production/stackers-and-signing).
-
-
-
-
-
-What is Bitcoin Finality, and why is it important?
-
-Stacks and sBTC state automatically fork with Bitcoin. As such, all transactions settle to Bitcoin with 100% Bitcoin Finality. This protects users against attacks to sBTC via a hard fork. This is a critical security measure that aligns sBTC security with Bitcoin. Read more in [the Stacks Documentation](https://docs.stacks.co/concepts/block-production/bitcoin-finality).
-
-
-
-
-
-How does the Stacks Signer network improve security?
-
-Signers are responsible for approving all sBTC deposit and withdrawal operations, ensuring the integrity of the system. With a requirement of 70% consensus for transaction approval, Signers maintain the protocol's liveness and security.
-
-To launch sBTC, the Stacks community approved [SIP-028](https://github.com/stacksgov/sips/blob/69d40a5f4f0ad98eb448ba44e7c31ca054820aa3/sips/sip-028-sbtc_peg.md), defining the criteria for selecting signers based on factors such as technical expertise, reliability, performance, and decentralization. An initial group of 15 institutional Signers has been chosen for Phase 1 to maintain simplicity and reduce operational risks. This group will expand over time as the protocol matures.
-
-The list of sBTC signers is public and listed [here](https://bitcoinl2labs.com/sbtc-rollout#sbtc-signers).
-
-
-
-
-
-What security measures have been put in place to ensure sBTC is safe?
-
-sBTC is always backed 1:1 against BTC, and it's verifiably secure through threshold cryptography. sBTC removes the need for 3rd party custodian or trusted setup. Instead, BTC is secured by a decentralized signer set.
-
-Partnerships with top-tier security experts have been established to ensure the protocol is fortified at every level:
-
-1. **Asymmetric Research:** [Asymmetric Research](https://www.asymmetric.re) is a core security contributor. Known for their rigorous research and protocol audits, Asymmetric brings security expertise to sBTC to identify and mitigate potential vulnerabilities.
-2. **ImmuneFi:** A robust bug bounty program incentivizes ethical hackers to uncover and address potential issues, adding an additional layer of defense.
-3. **3rd Party Audits:** Several third-party security audits have been conducted on the sBTC system and can be referenced on the [sBTC Audits page](sbtc-audits.md).
-
-
-
-
-
-What sets sBTC apart?
-
-Here are the main differentiating characteristics of sBTC:
-
-* sBTC is a true Bitcoin native product
-* sBTC is backed by respected leaders in the Bitcoin community (signer network)
-* sBTC's security is provided by a decentralized network of validators/signers rather than a single custodian, removing the need to trust a single entity or exchange
-* sBTC leverages 100% Bitcoin finality
-* sBTC's technology offers optimal UX and DevEx for an L2
-* sBTC is a fully transparent project/product working in the open with public code
-
-
-
-
-
-Where can I learn more about the sBTC signers?
-
-Read the "[Selection of sBTC Signer Set](https://github.com/stacks-network/sbtc/discussions/624)" post for more information about each signer and their qualifications.
-
-
-
-### sBTC Rewards Program
-
-
-
-Where does the yield paid in BTC come from?
-
-The sBTC Rewards Program is powered by a group of Stackers "Stacking" STX to a designated reward address, contributing their BTC rewards to the program.
-
-When Stacking STX, Stackers receive BTC through Stack's [Proof-of-Transfer](https://docs.stacks.co/concepts/stacks-101/proof-of-transfer) (PoX) consensus mechanism. For example, over a given 2-week period, the Stacks protocol has historically [distributed around 10% APY to Stackers](https://www.stacking-tracker.com/), paid in BTC.
-
-To enable the sBTC Rewards Program, these stackers contribute the corresponding Proof of Transfer BTC rewards to the sBTC incentive pool. This BTC from the incentive pool is directly deposited into a smart contract that bridges the BTC to sBTC and distributes the rewards pro rata to sBTC holders.
-
-The program is designed to increase sBTC liquidity and drive early usage of the protocol.
-
-Here's a handy illustration to show the sBTC incentives design:
-
-
-
-
-
-
-
-How are rewards distributed?
-
-sBTC is automatically distributed every two weeks to the STX address used to enroll in your non-custodial wallet.
-
-
-
-
-
-What do I have to do to be eligible for rewards?
-
-To be eligible, you must enroll in the rewards program at bitcoinismore.org.
-
-
-
-
-
-Do I need to re-enroll in the sBTC Rewards Program if I previously enrolled in the sBTC Rewards Program and have received additional sBTC?
-
-No re-enrollment is needed. The Yield smart contract will automatically calculate enrolled users updated balance, as long as the sBTC contract address remains the same.
-
-
-
-
-
-What level of rewards should I expect?
-
-The level of rewards users can expect will vary based on the amount of STX in the rewards pool, the PoX yield rate, and the amount of sBTC that has been minted.
-
-
-
-
-
-What is the difference between PoX Rewards and the sBTC Rewards Program?
-
-PoX Bitcoin rewards are earned by Stackers who lock up their STX tokens to secure the Stacks network, a process that has been ongoing since the launch of Stacks.
-
-The sBTC Rewards Program, on the other hand, offers additional BTC rewards specifically for early adopters who hold sBTC without requiring them to participate in network consensus or lock up any tokens.
-
-
-
-### Using sBTC
-
-
-
-When will sBTC be available?
-
-sBTC deposits first went live on December 16, 2024, quickly hitting the 1,000 BTC cap. The second cap will go live on February 25th, 2025, quickly hitting the 3,000 BTC cap. Withdrawals went live on April 30, 2025.
-
-Full decentralization of the Signer set will follow in [a subsequent phase](https://bitcoinl2labs.com/sbtc-rollout), gradually expanding beyond the initial 15 community-elected signers.
-
-
-
-
-
-What wallets are supported for sBTC?
-
-[Xverse](https://www.xverse.app) and [Leather](https://leather.io) wallets are supported — two leading wallets with seamless integrations designed for Bitcoin and Stacks users.
-
-In addition, [Ledger](https://www.ledger.com/) and [Asigna](https://www.asigna.io/) support sBTC.
-
-We are actively working with institutional custodians, staking providers, and other 3rd party wallets to support sBTC. More will be announced.
-
-
-
-
-
-Why is there a .01 BTC minimum for BTC to sBTC deposits?
-
-A .01 BTC minimum is imposed for BTC to sBTC deposits to ensure the system does not get spammed by many smaller transactions. We are exploring reducing the deposit minimum for future phases.
-
-
-
-
-
-What are the steps to use the sBTC Bridge and earn rewards?
-
-In the Stacks Documentation, find a [video](https://www.youtube.com/watch?v=XZruuDgTo4k\&t=1s) and a [more detailed walkthrough](https://docs.stacks.co/guides-and-tutorials/sbtc/how-to-use-the-sbtc-bridge).
-
-1. Ensure BTC is accessible via one of the following non-custodial wallets: [Xverse](https://www.xverse.app), [Leather](https://leather.io), [Ledger](https://www.ledger.com/), or [Asigna](https://www.asigna.io/).
-2. To interact with the sBTC protocol and mint sBTC, head to [app.stacks.co](http://app.stacks.co) and connect your non-custodial wallet with BTC ready to deposit.
-3. Enter the BTC amount to convert to sBTC ([app.stacks.co](http://app.stacks.co) will guide you through this step).
-4. Enter your Stacks receiving address to initiate the transfer ([app.stacks.co](http://app.stacks.co) will guide you through this step).
-5. After your sBTC has been minted to your wallet, visit the rewards program site at [bitcoinismore.org](https://bitcoinismore.org/) and connect your wallet. Then click the 'Earn Rewards' button. Read more in [the Stacks Documentation](https://docs.stacks.co/guides-and-tutorials/sbtc/earn-sbtc-rewards).
-6. Seamlessly start earning sBTC rewards. sBTC is automatically paid every two weeks to the STX address used to enroll in your non-custodial wallet.
-
-**Note:** There is an initial lock-up period until withdrawals are activated in March. Following the lock-up period, sBTC can always be withdrawn.
-
-
-
-
-
-How long will it take for my BTC deposit to confirm?
-
-sBTC facilitates rapid movement between BTC and sBTC.
-
-1. BTC to sBTC conversion can be completed within 3 Bitcoin blocks (under an hour).
-2. sBTC to BTC conversion can be completed within 6 Bitcoin blocks (Approximately two hours)
-
-Read more in the [Stacks Documentation](https://docs.stacks.co/concepts/sbtc/operations/deposit-withdrawal-times).
-
-
-
-
-
-Why is there a cap on the total BTC pegged in?
-
-A BTC cap will be implemented to ensure a smooth rollout process with a focus on security.
-
-In addition, the BTC cap will give developers the time to focus on the sBTC user experience and integration with DeFi applications across the Stacks ecosystem prior to opening sBTC for all users.
-
-
-
-
-
-Are there any associated fees with minting sBTC?
-
-There are two transaction fees required to mint your sBTC. The first is set by the user manually when they initiate the deposit transaction within their wallet.
-
-The second is a fee used to consolidate the deposit UTXOs into the single signer UTXO. This separate transaction fee happens automatically and is set to a max of 80k sats. This is automatically deducted from your minted sBTC. This is not a signer fee but a regular Bitcoin transaction fee.
-
-
-
-
-
-Are there multi-signature solutions for sBTC?
-
-Yes. [Asigna](https://www.asigna.io) provides a multi-signature solution for sBTC users.
-
-
-
-
-
-Are custodians available to support sBTC?
-
-At the moment, there is no custodian support for sBTC. However, we are actively working with institutional custodians to support sBTC.
-
-Copper and BitGo already support Stacks and Stacking; however, we are working to prioritize SIP-10 and sBTC integration.
-
-
-
-### sBTC Troubleshooting
-
-
-
-My Bitcoin transaction confirmed, but I'm not seeing the sBTC token in my wallet.
-
-You may need to enable the display of the sBTC token within your wallet by clicking on 'Manage Tokens' and enabling sBTC.
-
-
-
-
-
-
-
-I received an "Errors.Invalid_Transaction" error when using an Xverse Wallet
-
-If you received a "Errors.Invalid\_Transaction" error when using an Xverse Wallet, you may be using a "Nested SegWit" wallet. To resolve the issue, change your Xverse wallet to use the "Native SegWit".
-
-
-
-
-
-sBTC still isn't showing up in wallet after 3 Bitcoin blocks. How much longer do I have to wait?
-
-BTC to sBTC conversions are typically completed within 3 Bitcoin blocks. Due to the speed of Bitcoin blocks, deposits can take up to two hours to see sBTC in your wallet.
-
-However, there may be a lag with your Leather or Xverse wallet where the sBTC will take another 20 minutes to show up in the wallet.
-
-
-
-
-
-I didn't receive a confirmation that I enrolled in the rewards program. How can I ensure I'm enrolled?
-
-Visit [bitcoinismore.org](https://bitcoinismore.org). On the enroll page, when your wallet is linked, it will say enrolled if you are enrolled in the program.
-
-
diff --git a/concepts/sbtc/walkthroughs/README.md b/concepts/sbtc/walkthroughs/README.md
deleted file mode 100644
index 0ec2198b09..0000000000
--- a/concepts/sbtc/walkthroughs/README.md
+++ /dev/null
@@ -1,5 +0,0 @@
-# Journey Walkthroughs
-
-These walkthroughs describe at a high level exactly how users and signers can expect to interact with the sBTC system.
-
-Read these to get a firm understanding of what is actually happening under the hood of the sBTC system.
diff --git a/concepts/sbtc/walkthroughs/sbtc-transaction-lifecycle.md b/concepts/sbtc/walkthroughs/sbtc-transaction-lifecycle.md
deleted file mode 100644
index 77b3b419e6..0000000000
--- a/concepts/sbtc/walkthroughs/sbtc-transaction-lifecycle.md
+++ /dev/null
@@ -1,118 +0,0 @@
-# sBTC Transaction Walkthrough
-
-Let's follow the journey of 1 BTC as it moves through the sBTC system, from initial deposit to final withdrawal.
-
-## Part 1: Deposit (BTC to sBTC)
-
-### Step 1: Initiation
-
-Alice decides to convert 1 BTC to sBTC to participate in Stacks DeFi.
-
-1. Alice creates a deposit transaction on the Bitcoin network (this will likely be done via a UI like the sBTC bridge or a DeFi application).
-2. The transaction enters the Bitcoin mempool.
-
-### Step 2: Proof Submission
-
-1. Alice submits proof of her deposit to the Deposit API (this step is also usually done via an application's UI).
-2. The Deposit API sets the deposit status to PENDING.
-
-### Step 3: Signer Validation
-
-The sBTC Signer Set:
-
-1. Detects the deposit.
-2. Validates the UTXO format.
-3. Votes on the deposit.
-
-If the deposit is rejected:
-
-1. Signers notify the API of the rejection.
-2. The Deposit API updates the status to FAILED.
-
-If the deposit is accepted:
-
-1. The Deposit API updates the status to ACCEPTED.
-
-### Step 4: Bitcoin Transaction
-
-If accepted, the sBTC Signer Set:
-
-1. Creates a new Bitcoin transaction consuming Alice's deposited BTC.
-2. Broadcasts this transaction to the Bitcoin network.
-
-If this transaction fails:
-
-1. Signers notify the API of the failure.
-2. The Deposit API updates the status to FAILED.
-
-### Step 5: sBTC Minting
-
-Upon successful Bitcoin transaction:
-
-1. The sBTC Signer Set interacts with the Stacks blockchain.
-2. They fulfill the deposit by minting 1 sBTC to Alice's Stacks address.
-
-### Step 6: Confirmation
-
-1. The Deposit API updates the deposit status to CONFIRMED.
-2. Alice now has 1 sBTC in her Stacks wallet.
-
-## Part 2: sBTC Usage
-
-Alice can now use her 1 sBTC in the Stacks ecosystem:
-
-1. She can transfer it to other users via the `sbtc-token` contract (again this will usually be done via an application UI).
-2. Participate in DeFi applications.
-3. Use it in any application that supports SIP-010 tokens.
-
-## Part 3: Withdrawal (sBTC to BTC)
-
-### Step 1: Initiation
-
-Alice decides to withdraw her 1 sBTC back to BTC.
-
-1. Alice interacts with the Clarity contract on the Stacks blockchain to initiate a withdrawal.
-2. She specifies her Bitcoin address for the withdrawal.
-3. If successful, the contract locks her sBTC and the withdrawal status is set to PENDING.
-4. If the transaction fails, no withdrawal occurs.
-
-### Step 2: Signer Validation
-
-The sBTC Signer Set:
-
-1. Detects the withdrawal request.
-2. Decides whether to accept or reject the withdrawal.
-
-If the withdrawal is rejected:
-
-1. Signers unlock the sBTC.
-2. The withdrawal status is updated to FAILED.
-
-If the withdrawal is accepted:
-
-1. The withdrawal status is updated to ACCEPTED.
-2. Signers wait for 6 Bitcoin block confirmations (for security purposes).
-
-### Step 3: Bitcoin Transaction
-
-After the waiting period, if accepted:
-
-1. The sBTC Signer Set creates a new Bitcoin transaction fulfilling Alice's withdrawal.
-2. They broadcast this transaction to the Bitcoin network.
-
-If this transaction fails:
-
-1. Signers unlock the sBTC.
-2. The withdrawal status is updated to FAILED.
-
-### Step 4: sBTC Burning and Confirmation
-
-Upon successful Bitcoin transaction:
-
-1. The sBTC Signer Set burns the locked 1 sBTC on the Stacks blockchain.
-2. The withdrawal status is updated to CONFIRMED.
-
-### Step 5: Completion
-
-1. Alice now has her 1 BTC back in her specified Bitcoin address.
-2. The withdrawn sBTC has been permanently removed from circulation.
diff --git a/concepts/sbtc/walkthroughs/signer-process.md b/concepts/sbtc/walkthroughs/signer-process.md
deleted file mode 100644
index 91bc183181..0000000000
--- a/concepts/sbtc/walkthroughs/signer-process.md
+++ /dev/null
@@ -1,47 +0,0 @@
-# Signer Process Walkthrough
-
-## Introduction
-
-This document provides a detailed overview of the sBTC system, focusing on the operations of an sBTC signer node. We'll explore the automated processes and software interactions that occur in the sBTC ecosystem.
-
-A step-by-step guide for setting up and running a sBTC signer node is in the works. This is a conceptual guide to help signers understand what their role looks like in the sBTC system.
-
-## Signer Node Setup
-
-As an sBTC signer, your primary responsibility is to run and maintain a signer node. Here's what that entails:
-
-1. Hardware setup: Ensure your node has sufficient computational power and storage.
-2. Software installation: Install the sBTC signer node software and its dependencies.
-3. Key management: The node software securely generates and stores the Bitcoin private key and corresponding public key.
-4. Node registration: Upon first run, the node automatically registers its public key with the sBTC Registry contract on the Stacks blockchain.
-
-## Day-to-Day Operations
-
-Once set up, your signer node operates autonomously, performing the following tasks:
-
-### 1. Monitoring Deposit Requests
-
-Your node continuously monitors for sBTC minting requests:
-
-1. The node connects to the Bitcoin network and the Stacks blockchain.
-2. It watches for Bitcoin transactions sent to the sBTC UTXO address.
-3. When a deposit is detected, the node verifies the transaction details.
-
-### 2. Processing Mint Requests
-
-Upon confirming a deposit:
-
-1. The node automatically prepares a signature for the mint operation using its private key.
-2. It submits this signature to the sBTC Deposit contract on the Stacks blockchain.
-3. The contract verifies the signature and combines it with signatures from other signer nodes.
-4. Once enough valid signatures are collected, the contract mints the corresponding amount of sBTC.
-
-### 3. Handling Withdrawal Requests
-
-For sBTC withdrawal requests:
-
-1. The node monitors the sBTC Withdrawal contract for new requests.
-2. Upon detecting a request, it verifies the user's sBTC balance and the request's validity.
-3. The node automatically signs the withdrawal operation and submits its signature.
-4. Once enough signatures are collected and the sBTC is burned, the node participates in creating and signing a Bitcoin transaction to fulfill the withdrawal.
-5. The signed Bitcoin transaction is broadcast to the Bitcoin network.
diff --git a/concepts/stacks-101/README.md b/concepts/stacks-101/README.md
deleted file mode 100644
index 22bd03150b..0000000000
--- a/concepts/stacks-101/README.md
+++ /dev/null
@@ -1,7 +0,0 @@
-# Stacks 101
-
-Stacks has a very unique technical model in the blockchain world. This section will help you get a high-level overview of the essential components to understand how Stacks works.
-
-We'll cover the basics of what Stacks is and how it works from both a philosophical and technical level, and you can dive into the further sections for more details.
-
-First up, let's get an overview of exactly what Stacks is.
diff --git a/concepts/stacks-101/bitcoin-connection.md b/concepts/stacks-101/bitcoin-connection.md
deleted file mode 100644
index 37858012cf..0000000000
--- a/concepts/stacks-101/bitcoin-connection.md
+++ /dev/null
@@ -1,110 +0,0 @@
-# Bitcoin Connection
-
-In the previous section, we described Stacks as bringing smart contract functionality to Bitcoin, without modifying Bitcoin itself, and explained a bit about how the chain works.
-
-That's a big promise, but how does Stacks actually deliver on it? And what makes Stacks unique among other Bitcoin layers and other blockchains like Ethereum?
-
-Before we get into the technical details of how Stacks works, it's important to get a high-level overview of the problem its solving and how it actually does that. We'll dive deeper into some of these topics as we go through the docs, but it's good to get a high-level picture to bring everything together.
-
-This topic is a bit of a rabbit hole, and this section is pretty long, but it will give you an in-depth understanding of exactly the problem Stacks is looking to solve, and how it solves it.
-
-Let's get into it.
-
-### Is Stacks a Bitcoin L2?
-
-Stacks is a Bitcoin layer for smart contracts. The classification as a layer-1 (L1) or layer-2 (L2) or sidechain really depends on the definition used. With that said, generally speaking L1 chains are sovereign meaning that (a) they have their own security budget, and (b) they can survive without the need for any other L1 chain. L2 chains typically do not have their own security budget and share the security of the underlying L1 chain, and they cannot live without the underlying L1 chain. There are many different design mechanisms that L2s can use, and we cover several of them and how Stacks compares in the [Stacks Among Other Bitcoin Layers](stacks-among-other-layers.md) section.
-
-The initial release of Stacks in early 2021 had a separate security budget from Bitcoin L1. Even though the Stacks layer could not function without Bitcoin L1, the developers working on the project described it as a different system that does not fit neatly into existing classifications, sometimes using the term layer 1.5 (see [this Decrypt article](https://decrypt.co/82019/bitcoin-defi-thing-says-stacks-founder-muneeb-ali) for example).
-
-The upcoming planned release of Stacks, called the Nakamoto release, will no longer have a separate security budget from Bitcoin. Instead, a 100% of Bitcoin hashpower will determine finality on Stacks layer. After the next upgrade, to reorg Stacks blocks/transactions the attacker will need to reorg Bitcoin L1 itself (which is very hard to do and therefore a great security property for a Bitcoin layer to have). More details in the [Stacks paper](https://stacks.co/stacks.pdf).
-
-The definition of [L2 used in Ethereum](https://ethereum.org/en/layer-2/) and other newer ecosystems is different and focuses on the ability to withdraw assets using only L1 security and L1 miners. According to that definition Stacks layer is not a clear L2, given the set of peg-out signers determine if users can withdraw sBTC. Bitcoin cannot support such verification without changes to Bitcoin L1 (which may happen in the future). The Ethereum L2 definition also does not apply that cleanly to Bitcoin L2s, given new assets are issued on L2s when it comes to Bitcoin and not issued on L1 (only BTC is the L1 asset). Therefore, using the definition of security of withdrawing assets is not directly applicable given assets are defined and used on L2s and not withdrawn out to Bitcoin L1 anyway (with the exception of BTC itself). Rather, what becomes more important is "settlement on Bitcoin" i.e., is contract data and state secured by 100% of Bitcoin's hashpower or not.
-
-Remember that L2s on Bitcoin also have to serve the additional purpose of expanding both functionality and scalability, which means L2s accomplish fundamentally different goals depending on the functionality of the L1.
-
-Users and developers organically call Stacks a Bitcoin L2, since it is a simpler concept to understand. There are certain properties of Stacks layer that also help the concept of Stacks as a Bitcoin L2:
-
-1. Bitcoin finality, as discussed above, where 100% of the Bitcoin hashpower decides block ordering and transaction finality.
-2. Stacks consensus runs on Bitcoin L1, and Stacks L2 cannot operate or survive without Bitcoin L1.
-3. With the upcoming decentralized Bitcoin peg, called sBTC, most of economy on Stacks layer will likely use BTC as the unit of economy. It is expected that most users will simply use Bitcoin in wallets and apps and then peg out their BTC to Bitcoin L1.
-4. All data and transactions on Stacks are automatically hashed and permanently stored on Bitcoin L1 on every Bitcoin block. Anyone can verify that some data on Stacks is valid by checking the corresponding hash on Bitcoin L1. This compact storage of hashes on L1 is somewhat similar to rollups (although there are other differences). You can read more about this process in the [Block Production](../block-production/) section.
-5. Contracts on Stacks layer can read Bitcoin L1 transactions and respond to them. Assets on Stacks layer can be moved simply through Bitcoin L1 transactions.
-
-Given all the details above, why would some people think that Stacks is not a Bitcoin L2? There are a couple of reasons why this question comes up often:
-
-1. The initial version of Stacks (released early 2021) had a separate security budget which changed to following 100% Bitcoin hashpower with the Nakamoto release. There is old material and blog posts floating around that still talk about the initial Stacks version. The old materials will likely get updated with time.
-2. According to the Ethereum definition of L2s a user should be able to withdraw their base-layer assets purely by doing a L1 transaction and relying only on L1 security (this is true for Lightning for example). This definition does not apply cleanly to Bitcoin L2s because assets are not defined at Bitcoin L1 but are defined in L2s instead. The only asset where this matters is the pegged BTC asset from Bitcoin L1, given all other assets are native to L2s anyway. In the upcoming Stacks release, users can withdraw their BTC by sending just a Bitcoin L1 transaction but Bitcoin L1 cannot validate that complex transaction and a majority of peg-out signers will need to sign on the peg-out request. In an ideal world Bitcoin miners can validate such transactions but that would require a change to Bitcoin L1. Therefore, Stacks design optimizes for a method that is decentralized and can be deployed without any changes to Bitcoin L1. If in the future it is possible to make changes to Bitcoin L1 then Stacks layer security can benefit from that as well.
-3. Bitcoin community members are generally skeptical of claims and on a look out for people making any false marketing claims. This is generally a healthy thing for the Bitcoin ecosystem and builds up the immune system. Some such community members might be skeptical about Stacks as a Bitcoin layer or L2 until they fully read the technical details and reasoning. There is a good [Twitter thread](https://twitter.com/lopp/status/1623756872976158722?s=20) about this topic as well.
-
-Why don't we use the term 'sidechain' for Stacks then? Sidechains in Bitcoin typically have a different security budget from Bitcoin L1, typically as a subset of Bitcoin miners who participate in the sidechain (they don't follow 100% Bitcoin finality), their consensus runs on the sidechain (vs running on Bitcoin L1), and they don't publish their data/hashes on Bitcoin L1. The Stacks layer does not fit that definition cleanly given the consensus runs on Bitcoin L1, it follows Bitcoin finality, and publishes data/hashes on L1.
-
-**Can Stacks layer work with rollups?**
-
-Yes! There is already an active R\&D effort to integrate rollups with the Stacks layer. Both with the Stacks layer and sovereign rollups the technically challenging part is how to get BTC in and out of the Stacks layer or the sovereign rollup. The decentralized BTC peg, [sBTC](../sbtc/), applies to both the Stacks layer and sovereign rollups. Without modifying Bitcoin L1, an sBTC-like design with a decentralized open-membership group of signers is the most trust-minimized way to move BTC in and out of Bitcoin layers. Once the necessary upgrades to Bitcoin L1 can be made to enable validity rollups i.e., Bitcoin L1 can enforce BTC withdrawal from a layer, then the Stacks layer can also upgrade to benefit from it.
-
-Given a trust-minimized asset like sBTC is needed for sovereign rollups, with the launch of sBTC such sovereign rollups become even more interesting to deploy. The Stacks layer can potentially provide the decentralized group of signers for a trust-minimized BTC asset that can be used in a sovereign rollup, and DA comes directly from Bitcoin L1 e.g., with Ordinals.
-
-### Why Does Stacks Need a Token?
-
-This brings us to a central philosophical conversation in the world of crypto and Bitcoin, whether or not blockchains need tokens.
-
-Let's start by looking at the fundamental reason why tokens exist: to fund the maintenance and forward progress of a blockchain.
-
-Bitcoin is a token. It is a cryptocurrency that is used to incentivize miners to add new blocks to the chain. In Bitcoin's case, mining rewards are set on a predefined schedule, and once those mining rewards run out, the chain will need to survive on transaction fees alone.
-
-The purpose of a blockchain is to have a permanent historical record of every transaction that has ever occurred on the chain. Blockchains are basically ledgers. The token aspect is used as an incentive mechanism to secure and maintain the chain.
-
-This is why networks like Lightning and other P2P networks don't need tokens, they don't need to maintain a historical record. Channel-based solutions like Lightning rely on users opening 2-of-2 multisigs with each other. Once those channels are closed, the state disappears. When we are talking about a system that is supposed to maintain a global financial system, it is important for the maintenance of that system to be incentivized correctly.
-
-Let's look at this concept in the context of Stacks and its goals. Stacks seeks to provide smart contract functionality to Bitcoin, to serve as the programming rails for building a decentralized economy on top of Bitcoin.
-
-Many Bitcoin community members are skeptical of new tokens and rightly so. There are countless projects out there that force the use of a token on their project and in many cases a token is actually not needed. The Stacks project was started by Bitcoin builders who have a long history of building apps & protocols on Bitcoin L1 without any token (e.g., BNS launched in 2015 on Bitcoin L1 which was one of the largest protocols using OP\_RETURN on Bitcoin L1). So why did a bunch of Bitcoin builders decide to have a separate token for Stacks L2? Great question! Let's dig into the details.
-
-The Stacks token (STX) is primarily meant to be used for two things (details in [Stacks paper](https://stacks-network.github.io/stacks/stacks.pdf)):
-
-1. Incentives for Stacks L2 miners
-2. Incentives for peg-out signers
-
-The only way to remove the token is to build Stacks as a federated network like Liquid. In a federation the pre-selected group of companies control the mining and block production and a pre-selected group of companies need to be trusted for peg-out transactions.
-
-Stacks developers wanted to design an open and permissionless system. The only way to have a decentralized mining process is through incentives. As mentioned above, this is how Bitcoin works as well, where newly minted BTC are used as incentives to mine new blocks and anyone in the world can decide to become a miner. Anyone with BTC can mine the Stacks L2 chain, it is open and permissionless.
-
-Similarly, the way sBTC is designed is that the group of signers is open and permissionless (unlike a federation). These signers have economic incentives to correctly follow the protocol for peg-out requests. In a federation, users need to blindly trust the pre-set federation members to get their BTC out of the federation and back on Bitcoin L1. Stacks developers wanted to have an open, permissionless, and decentralized way to move BTC from Bitcoin L1 to Stacks L2 and back. This is made possible through economic incentives i.e., need for a token.
-
-{% hint style="info" %}
-With more and more Bitcoin layers emerging, there is some nuance in this federated vs open network design. Some protocols like Botanix's Spiderchain offer an open network but have different incentive mechanisms. We dig into these in detail in the [Stacks Among Other Layers](stacks-among-other-layers.md) section.
-{% endhint %}
-
-Other than these two reasons, STX is also used to pay gas fees for transactions. However, once the upcoming sBTC peg is live most of the economy of Stacks L2 is expected to follow a Bitcoin standard and work using BTC as the economic unit. It is expected that users will mostly interact just with Bitcoin and use BTC in wallets and apps (gas fees can be paid with BTC using atomic swaps in the background). It is important to note that BTC cannot be used for mining incentives on Stacks L2 because the only way to incentivize decentralized block production is through newly minted assets by the protocol (similar to how Bitcoin works itself) i.e., need for a token.
-
-### The Symbiotic Relationship Between Stacks and Bitcoin
-
-Stacks and Bitcoin complement each other. Stacks leverages the extreme decentralization of Bitcoin, its PoW consensus mechanism, and its value as a cryptocurrency.
-
-But Stacks also complements Bitcoin by unlocking additional use cases, thereby increasing its value over time. This also helps to solve the additional problem of the future maintainability of Bitcoin after the coinbase rewards are gone and Bitcoin has to function on transaction fees alone.
-
-If Bitcoin is seen as only a store of value, the economic density, meaning how much value is being exchanged, of each transaction will be minimal. But if Bitcoin is the underlying foundation for an entire decentralized economy, those [transactions become much more valuable](https://twitter.com/muneeb/status/1506976317618728963), increasing transaction fees. This is a crucial incentive for miners to continue securing the network as coinbase rewards drop.
-
-### Reading from Bitcoin State
-
-One of the things that gives the Stacks chain its superpowers in connecting with Bitcoin is not only how it connects to Bitcoin at a protocol level, discussed above, but also how we can utilize that Bitcoin at a programmatic level.
-
-That's where Clarity comes in. Clarity is the smart contract language for Stacks, and is how we actually build out a lot of the functionality we are talking about here.
-
-One of the often-touted features of Clarity is that it has access to the state of the Bitcoin chain built in, but how does it actually do that? Because of Stacks' PoX mechanism, every Stacks block is connected to a Bitcoin block, and can query Bitcoin block header hashes with the [`get-burn-block-info?` function](https://github.com/stacksgov/sips/blob/feat/sip-015/sips/sip-015/sip-015-network-upgrade.md#new-method-get-burn-block-info).
-
-This function allows us to pass in a Bitcoin block height and get back the header hash. The [`burn-block-height` Clarity keyword](https://docs.stacks.co/docs/write-smart-contracts/clarity-language/language-keywords#burn-block-height) will give us the current block height of the Bitcoin chain.
-
-However, `get-burn-block-info?` only returns data of the Bitcoin block at that height if it has already been processed and was created after the launch of the Stacks chain. So if we want to evaluate whether or not something happened on Bitcoin, we have to wait at least one block later to do so.
-
-This is step 1 of Clarity contracts being able to serve as the programming layer for Bitcoin, when a BTC transaction is initiated, the first thing that needs to happen is that a Clarity contract needs to become aware of it. This can happen manually by utilizing Clarity functions discussed above with the [BTC library](https://explorer.stacks.co/txid/0x8b112f2b50c1fa864997b7496aaad1e3940700309a3fdcc6c07f1c6f8b9cfb7b?chain=mainnet), as [Catamaran Swaps](https://docs.catamaranswaps.org/en/latest/catamaran.html) do.
-
-{% hint style="info" %}
-Note that this process is made easier by the additional Clarity functions added in 2.1, like the `get-burn-block-info?` function we looked at above.
-{% endhint %}
-
-Or we can automate (albeit at a cost of some centralization in our dapp) using an event-based architecture using something like Hiro's [chainhooks](https://www.hiro.so/blog/meet-4-new-features-in-clarinet#setting-up-trigger-actions-with-chainhooks), which will allow us to automatically trigger a Clarity contract call when a certain BTC transaction is initiated.
-
-This is the first component of using Stacks to build Bitcoin dapps, the read access to Bitcoin chain.
-
-Next up, let's dig a bit deeper into how exactly Stacks is "built on Bitcoin" by taking a look at Stacks' block production mechanism, Proof of Transfer.
diff --git a/concepts/stacks-101/financial-incentive-and-security-budget.md b/concepts/stacks-101/financial-incentive-and-security-budget.md
deleted file mode 100644
index f463e1b000..0000000000
--- a/concepts/stacks-101/financial-incentive-and-security-budget.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# Financial Incentive and Security Budget
-
-In order to reorg the Stacks chain, someone must take control of at least 70% of the STX that are currently Stacked and conduct a 51% attack on Bitcoin itself. If acquired at market prices, then at the time of this writing, that amounts to spending nearly $1 billion USD in only the STX stacked.
-
-In addition to this, because of how Stacks achieves Bitcoin finality by not allowing forks, Stacks security budget reaches 51% of Bitcoin's mining power because in order to reverse the chain state you would need to reverse the Bitcoin chain state as well.
-
-Stackers have the new-found power to sign blocks in order to append them to the Stacks chain. However, some of them could refuse to sign, and ensure that no block ever reaches the 70% signature threshold. While this can happen by accident, this is not economically rational behavior -- if they stall the chain for too long, their STX loses their value, and furthermore, they cannot re-stack or liquidate their STX or activate PoX to earn BTC. Also, miners will stop mining if no blocks are getting confirmed, which eliminates their ongoing PoX payouts.
-
-The technical details of how this all works are discussed in the [Block Production](../block-production/) section.
diff --git a/concepts/stacks-101/proof-of-transfer.md b/concepts/stacks-101/proof-of-transfer.md
deleted file mode 100644
index 877ff700e7..0000000000
--- a/concepts/stacks-101/proof-of-transfer.md
+++ /dev/null
@@ -1,61 +0,0 @@
-# Proof of Transfer
-
-In the previous sections, we took a look at the vision and ethos of Stacks and talked a lot about it being connected to Bitcoin and how it enables expanding functionality without modifying Bitcoin itself.
-
-In this section, we'll run through the block production mechanism that makes that happen, Proof of Transfer.
-
-This section will be a conceptual overview of Proof of Transfer. For more details on exactly how block production happens at a technical level, check out the section on [Block Production](../block-production/).
-
-Consensus algorithms for blockchains require compute or financial resources to secure the blockchain. The general practice of decentralized consensus is to make it practically infeasible for any single malicious actor to have enough computing power or ownership stake to attack the network.
-
-Popular consensus mechanisms in modern blockchains include proof of work, in which nodes dedicate computing resources, and proof of stake, in which nodes dedicate financial resources to secure the network.
-
-Proof of burn is another, less-frequently used consensus mechanism where miners compete by ‘burning’ (destroying) a proof of work cryptocurrency as a proxy for computing resources.
-
-Proof of transfer (PoX) is an extension of the proof of burn mechanism. PoX uses the proof of work cryptocurrency of an established blockchain (Bitcoin in this case) to secure a new blockchain. However, unlike proof of burn, rather than burning the cryptocurrency, miners transfer the committed cryptocurrency to some other participants in the network (Stackers in this case).
-
-
-
-This allows network participants to secure the PoX cryptocurrency network and earn a reward in the base cryptocurrency (BTC). Thus, PoX blockchains are anchored on their chosen PoW chain. Stacks uses Bitcoin as its anchor chain.
-
-
-
-### Why Bitcoin?
-
-There are a number of reasons that Stacks chose Bitcoin as the blockchain to power consensus. It's the oldest blockchain protocol, having launched in 2009, and has become a recognized asset outside of the cryptocurrency community. BTC has held the highest market capitalization of any cryptocurrency for the past decade.
-
-Bitcoin champions simplicity and stability, and has stood the test of time. Influencing or attacking the network is infeasible or impractical for any potential hackers. It's one of the only cryptocurrencies to capture public attention. Bitcoin is a household name, and is recognized as an asset by governments, large corporations, and legacy banking institutions. Lastly, Bitcoin is largely considered a reliable store of value, and provides extensive infrastructure to support the PoX consensus mechanism.
-
-SIP-001 provides a full [list of reasons why Bitcoin was chosen to secure Stacks](https://github.com/stacksgov/sips/blob/main/sips/sip-001/sip-001-burn-election.md).
-
-{% hint style="info" %}
-By the way, SIP stands for Stacks Improvement Proposal, and it's the process by which community members agree on making changes to the network. Reading the SIPs in detail is an excellent way to familiarize yourself with Stacks at the implementation level. All of the SIPs are available in the [SIPs section](../network-fundamentals/sips.md) of the docs.
-{% endhint %}
-
-### Unlocking Bitcoin capital
-
-In the previous section we talked about Stacks being able to allow us to build a decentralized economy on top of Bitcoin and that PoX was a key piece of being able to do that.
-
-The reason is two-fold. First, as a part of this PoX mining process we have covered here, a hash of each Stacks block is recorded to the OP\_RETURN opcode of a Bitcoin transaction. If you aren't familiar, the OP\_RETURN opcode allows us to store up to 40 bytes of arbitrary data in a Bitcoin transaction.
-
-{% hint style="info" %}
-This [Stack Exchange answer](https://bitcoin.stackexchange.com/questions/29554/explanation-of-what-an-op-return-transaction-looks-like) gives a good overview of the reasoning and history of this opcode.
-{% endhint %}
-
-This is the first part of how Stacks inherits Bitcoin's security: it's history is anchored block-by-block to the Bitcoin chain. Anyone can use merkle roots to verify these hashes to determine if the history is correct.
-
-Additionally, after the Nakamoto Upgrade, Stacks no longer forks on its own. Miners are required at a protocol level to build atop the last mined Stacks blocks, meaning that **Stacks is secured by both 100% of Bitcoin's hashrate in addition to the Stacks security budget from its miners.** We'll get into this process in more detail in the [Block Production](../block-production/) section.
-
-Additionally, part of this PoX process involves each Stacks block also knowing which Bitcoin block it is anchored to. Clarity, Stacks' smart contract language, has built-in functions for reading this data, such as [`get-block-info`](https://docs.stacks.co/docs/write-smart-contracts/clarity-language/language-functions#get-block-info), which returns, among other things, a field called `burnchain-header-hash`, which gives us the hash of the Bitcoin header corresponding to this Stacks block.
-
-This allows us to do really interesting things like trigger certain things to happen in a Clarity contract by watching the chain and verifying whether or not certain transactions occurred. You can see this in action in [Catamaran Swaps](https://docs.catamaranswaps.org/en/latest/catamaran.html), with other interesting projects like [Zest](https://www.zestprotocol.com/) seeking to expand on this functionality.
-
-The ultimate goal of all this is to enable the vision of web3, building a decentralized economy and enabling true user ownership of assets and data, on top of Bitcoin as a settlement layer, and using Bitcoin as a base decentralized money.
-
-
-
-### Proof of Transfer Contracts and Technical Details
-
-The Proof of Transfer functionality is implemented on the Stacks chain via a [Clarity smart contract](https://explorer.hiro.so/txid/0xc6d6e6ec82cabb2d7a9f4b85fcc298778d01186cabaee01685537aca390cdb46?chain=mainnet). An overview of this contract is available in the docs.
-
-You can see the original design for stacking and proof of transfer by reading the relevant SIP, [SIP-007](https://github.com/stacksgov/sips/blob/main/sips/sip-007/sip-007-stacking-consensus.md). You can also utilize [Hiro's API](https://docs.hiro.so/api#tag/Info/operation/get\_pox\_info) to get proof of transfer details including the relevant contract address.
diff --git a/concepts/stacks-101/stacks-among-other-layers.md b/concepts/stacks-101/stacks-among-other-layers.md
deleted file mode 100644
index c6758ea418..0000000000
--- a/concepts/stacks-101/stacks-among-other-layers.md
+++ /dev/null
@@ -1,79 +0,0 @@
-# Stacks Among Other Layers
-
-Recently, we have seen a flurry of new "Bitcoin layers" popping up across the ecosystem as the market has finally woken up to the idea.
-
-However, not all Bitcoin layers are made equal. While a large chunk of these projects are vaporware riding the hype train, there are several projects that are making a good faith effort to grow the Bitcoin economy and build on top of Bitcooin using various approaches.
-
-The [Bitcoin Layers project](https://www.bitcoinlayers.org/) is an excellent place to begin learning about these different layers. In addition, here we've broken down how Stacks compares to some of the most promising Bitcoin L2 solutions so you can begin to learn about them all and make an educated decision on which to use.
-
-### What is a Bitcoin Layer?
-
-It's important to define terms, especially in a new and evolving ecosystem like web3, and an even newer and more rapidly evolving subecosystem like Bitcoin layers.
-
-For the purpose of this document and comparison, we can use the following definition of a Bitcoin layer: A Bitcoin layer is a separate distributed computing system built either alongside or on top of Bitcoin for the purpose of enhancing its scalability, functionality, or both.
-
-That definition is intentionally general, and encompasses many different projects like L2s, sidechains, federated, open network, etc.
-
-#### Technical vs Economic Considerations
-
-It's important to understand that when designing blockchains, especially layer 2 systems, we have to consider both technical and economic factors. Since a core component of a blockchain system is money, we need to make sure that our systems are both technically robust and economically efficient. And we need to accomplish both of these things while maintaining decentralization.
-
-While it is trivial to create a trusted bridge to bridge BTC from the L1 to a L2, that defeats the purpose of blockchain technology in general, since the goal should be to create permissionless, trust-minimized systems.
-
-At the same time, a great technical solution that doesn't consider the economic incentives of the decentralized actors running the network will not have a sustainable path to long-term adoption and viability.
-
-This balance is why Stacks has chosen the design it has, to balance both achieving the technical features of a Bitcoin L2 like security inheritance and a trust-minimized BTC peg with the economic incentives for the participants in the ecosystem to maintain it in the long term.
-
-As an example of this, Galaxy recently [conducted research](https://www.galaxy.com/insights/research/exploring-bitcoin-for-data-availability/) on this topic and found that a Bitcoin rollup "will need to generate approximately between $1.9m and $9.63m in revenue from L2 transaction fees per month." That is a significant number and again highlights the need to consider both technical and economic factors when designing Bitcoin layers.
-
-### Popular Bitcoin Layers Compared
-
-#### Lightning
-
-Lightning is probably the most well-known Bitcoin layer, and is primarily designed to address scalability issues. Lightning functions as a separate P2P network from Bitcoin, allowing participants to move their BTC from the main chain to Lightning, conduct multiple transactions on Lightning, and then send the final result to the BTC chain where it is finalized.
-
-This is actually a completely separate problem from what Stacks is trying to address. Where Lightning takes the existing functionality of Bitcoin and makes it much more scalable, Stacks is seeking to expand Bitcoin's functionality to do things you can't do now.
-
-Crucially, Lightning is ephemeral, meaning it has no state management. There is no continuous record of what has happened on the Lightning network, only current channels. Once users close their channel and their transactions are written back to the Bitcoin chain, they are gone.
-
-A key component of fully-expressive smart contracts is that they maintain a permanent historical record of all transactions that have happened on the chain.
-
-Bitcoin does this now, but its scripting language is very limited. So where Lightning seeks to make existing Bitcoin functionality happen faster, Stacks seeks to add new functionality.
-
-#### RSK
-
-Like Stacks, [RSK](https://www.rsk.co/) seeks to add additional functionality to Bitcoin, but it goes about that process differently than Stacks.
-
-RSK is a merge-mined chain, meaning that it is mined concurrently with Bitcoin. Stacks has its own miners and mining process, and its own economic value and security that is a function of that token value, more on this below.
-
-There are multiple perspectives to look at this from. Because RSK is merge-mined, Bitcoin miners are also the ones mining RSK blocks, and RSK does not have its own token.
-
-RSK can only exist with opt-in from Bitcoin miners and mining rewards are highly dependent on transaction volume.
-
-This also opens up a wider discussion on the costs and benefits of having a separate token, which we'll get into below a bit when we discuss rollups.
-
-RSK is also EVM-compatible, where Stacks uses Clarity and the Clarity VM.
-
-#### Liquid
-
-[Liquid](https://liquid.net/) is a federated network focused on unlocking more advanced financial capabilities with Bitcoin. Being federated, Liquid is not an open network, and thus not decentralized.
-
-The Liquid consensus mechanism is managed by 15 functionaries, who handle the transaction processing and validating. Liquid also does not support general-purpose applications, but is solely focused on financial applications.
-
-For another perspective, Hiro wrote an [excellent post](https://www.hiro.so/blog/building-on-bitcoin-project-comparison) comparing Stacks with other Bitcoin projects.
-
-#### Bitcoin Rollups
-
-Rollups are an exciting development for scaling decentralized applications. There are many different types of rollups; they're broadly divided into ZK rollups and Optimistic rollups, although other classifications are also there (see [this overview](https://era.zksync.io/docs/dev/fundamentals/rollups.html#what-are-rollups)).
-
-Rollups are generally considered layer-2 (L2) technology that runs on top of a layer-1 blockchain like Bitcoin or Ethereum. A critical aspect of rollups is the trustless nature where logic running on the L1 chain can determine whether something that happened on the rollup was valid. This is not true for all types of rollups, and there is some fuzziness around exact definitions. [Sovereign rollups](https://blog.celestia.org/sovereign-rollup-chains/), for example, only use the underlying L1 for data availability (DA) and not for consensus.
-
-Most of the rollups work on Ethereum uses Ethereum L1 both as a data availability layer, and for consensus, i.e., the validity of rollup transactions is determined by logic running on Ethereum L1. Newer systems, [like Celestia](https://celestia.org/), are taking a more modular approach and are separating DA from consensus. One interesting aspect of separating DA is that more established and durable chains like Bitcoin can be used for DA as well. Below is an interesting comparison of sidechains and two types of rollups possible on Bitcoin (John Light posted this [on Twitter](https://twitter.com/lightcoin/status/1630301411962388481?s=20)):
-
-
-
-This image broadly means developers can build sovereign rollups on Bitcoin today, but you'll need a "trusted" setup for moving BTC in and out of the rollup. In fact, people are already doing this -- see the recent [Rollkit announcement](https://rollkit.dev/blog/sovereign-rollups-on-bitcoin/). To build validity rollups, meaning Bitcoin L1 enforces BTC withdrawals from the rollup, you'll need modifications to Bitcoin L1. See [this overview](https://bitcoinrollups.org/) for more details.
-
-One important nuance here is the cost required to effectively run a rollup on Bitcoin as discussed in the Galaxy research report linked in the first section.
-
-Now we have a solid grasp of how Stacks works and how it fits in among other layers. Let's begin to dig into some of the technical implementation details and see how Stacks actually works.
diff --git a/concepts/stacks-101/what-is-stacks.md b/concepts/stacks-101/what-is-stacks.md
deleted file mode 100644
index fa24807439..0000000000
--- a/concepts/stacks-101/what-is-stacks.md
+++ /dev/null
@@ -1,75 +0,0 @@
-# What Is Stacks?
-
-## What is Stacks?
-
-We can get an idea of the goal and ethos behind Stacks by looking at [how Satoshi envisioned generalizing Bitcoin](https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/244/#222) back in 2010:
-
-> "...to be a completely separate network and separate block chain, yet share CPU power with Bitcoin...all networks in the world would share combined CPU power, increasing the total strength."
-
-This is major theme in the design decisions for Stacks. A bit of a contradiction in the Bitcoin world, the Stacks network is a Bitcoin L2, but it does have its own token.
-
-This is an intentional and critical design decision primarily for the purpose of maintaining decentralization, rather than needing to rely on a federation.
-
-If that's confusing or you are skeptical, that's understandable, we'll be diving deeper into these ideas as we go through the docs.
-
-### Stacks and the Purpose of Blockchain Technology
-
-When evaluating new blockchain technologies, it's important to keep the original intent and purpose of them intact. If we go back to Bitcoin, it was originally designed to be:
-
-* Decentralized
-* Immutable
-* Secure
-
-You've likely heard of the blockchain trilemma, the problem of trying to balance the decentralization, scalability, and security of a blockchain network.
-
-Stacks takes the approach of solving this trilemma by separating out chains into layers.
-
-So at the bottom, you have the foundational layer: Bitcoin.
-
-Bitcoin is the most decentralized, most secure, and most immutable blockchain network. However, that comes with a few tradeoffs.
-
-Bitcoin is very slow compared to other networks. Bitcoin only has a new block written once every 10 minutes or so, making its throughput negligible compared to networks designed for speed like Solana.
-
-Bitcoin is also "boring". Ethereum came along after Bitcoin and sought to do the same thing for software that Bitcoin did for money. Ethereum's goal is to be a decentralized supercomputer of sorts, serving as a global compute environment for smart contracts (code that is written to a blockchain).
-
-Bitcoin is also not scalable. Because every new block must propagate to every node on the network, Bitcoin can only run as fast as the slowest node in the network. Now we are seeing the rise of modular blockchain networks like Cosmos that are designed to make it easy for people to spin up their own blockchain networks.
-
-While most new blockchain protocols popping up these days see these properties as negatives and seek to eliminate them, the Stacks community sees things differently.
-
-### The Stacks Way
-
-Stacks takes a layered approach, where you have the foundational settlement layer at the bottom (Bitcoin), and then you add scalability and functionality on top of that using layers.
-
-There are many different types of L2s and different ways they can be built. They all come with [different tradeoffs](stacks-among-other-layers.md) and have their own way of accomplishing the goals of scalability or functionality.
-
-By taking this layered approach, we are able to have all of the same functionality as chains like Ethereum, but built on Bitcoin.
-
-So Stacks is a Bitcoin layer 2 with some unique properties, like having its own token, that acts as an incentive mechanism to maintain a historical ledger of all of its transactions and operate with its own security budget (in addition to Bitcoin's security budget, more on this in the next section).
-
-This is one of the things that separates Stacks from other Bitcoin layers like Lightning.
-
-Lightning doesn't add any additional functionality to Bitcoin, it simply helps to scale functionality Bitcoin already has and help it operate faster. Lightning is also ephemeral, it has no permanent state that it keeps track of, and so is unsuitable for things like smart contracts that need to keep track of data and maintain state.
-
-Contrast this to Stacks, which adds additional functionality to Bitcoin but still ultimately settles down to Bitcoin (we'll cover this next in the section as well).
-
-The benefit we get here is that we can maintain a separation of concerns and keep Bitcoin simple and sturdy, chugging along producing blocks, and add additional layers for functionality and speed. But if those other layers were to be compromised, that would not affect the foundational layer at all.
-
-This is an important property when we are talking about building blockchains that are designed to be a global decentralized money (Bitcoin) and a decentralized economy built on top of that money (Stacks).
-
-The STX token is a separate token used to incentivize honest block production. It does not represent pegged Bitcoin (there is a separate Bitcoin peg called [sBTC](../sbtc/) for that purpose). While this may ruffle some feathers among some people in the Bitcoin community, it has several advantages.
-
-By implementing a token into the Stacks chain, we provide additional economic incentive for miners to produce Stacks blocks honestly.
-
-This token provides additional incentive in the form of serving as a way to grow the chain. Rather than relying on altruism in order to produce blocks and grow the chain, we can incentivize builders, token-holders, and investors all at the same time by having a token.
-
-The ICO scams of 2017 put a bad taste in a lot of peoples' mouths, which has justifiably made a lot of people skeptical of every new blockchain project that pops up with a new token.
-
-But the problem with all of these projects is that they had no actual value, they weren't anchored to anything else of value and provided no real utility.
-
-With a project like Stacks, we have real utility in the sense of serving as a way to utilize Bitcoin and make it a productive asset **in a decentralized way.** This is a key point, Currently the only way to make Bitcoin productive is by giving it to a custodial service or transferring it off the Bitcoin chain by way of something like wBTC on Ethereum.
-
-Stacks allows us to do this while ultimately still settling to the Bitcoin chain.
-
-In addition, Stacks allows us to build decentralized and censorship-resistant software utilizing Bitcoin as the foundational settlement layer. Eventually, the goal is to build a network of financial systems and decentralized software products that all utilize Bitcoin as their money.
-
-With that context, let's dive into exactly how Stacks is connected to Bitcoin.
diff --git a/concepts/transactions/README.md b/concepts/transactions/README.md
deleted file mode 100644
index 8e77cb2089..0000000000
--- a/concepts/transactions/README.md
+++ /dev/null
@@ -1,3 +0,0 @@
-# Transactions
-
-Transactions are a key component of the Stacks chain and are the primary way users will interact with it. In this section, we'll cover how transactions work and give an introduction to post conditions, an additional security feature of Stacks that allows client-side developers to enforce certain conditions to protect users from interacting with malicious contracts.
diff --git a/concepts/transactions/post-conditions.md b/concepts/transactions/post-conditions.md
deleted file mode 100644
index 7ee5b0e25f..0000000000
--- a/concepts/transactions/post-conditions.md
+++ /dev/null
@@ -1,35 +0,0 @@
-# Post Conditions
-
-Post conditions are one of the most interesting and unique aspects of Stacks.
-
-From the beginning, safety and security has been at the heart of the Stacks ethos and formed the foundation of architecture decisions when building it.
-
-Like Clarity, Stacks' smart contract programming language, post conditions were specifically built and design to solve the problem of user safety when interacting with blockchain applications.
-
-So what are they and how do they work?
-
-### How Post Conditions Work
-
-Post conditions are conditions that are set on the client side to ensure that a smart contract does not perform any unexpected behavior.
-
-Let's look at an example to make this more concrete.
-
-Let's say a user is on an NFT marketplace and is expecting to purchase an NFT for 100 STX. Using post conditions, the developer who is building the frontend of the application can add in post conditions to ensure that this is in fact what happens when the user initiates the transaction.
-
-If it does not, the transaction will abort and the user won't be out anything except the transaction fee.
-
-It's important to note that post conditions do not live in smart contracts. They are designed to be an extra layer of security on top of smart contracts.
-
-The problem they help address is a user interacting with a malicious smart contract that attempts to do something the user does not expect.
-
-But rather than simply being a UI feature of a wallet, these post conditions are built into the Stacks blockchain itself and are enforced at the protocol level.
-
-When you use a Stacks wallet like the Hiro web wallet and initiate a transaction, the wallet will display the post conditions set by the developer and tell the user exactly what is going to happen. If the action taken by the smart contract matches, the transaction goes through fine, otherwise it aborts.
-
-Here's what that looks like:
-
-
-
-In this example, if the smart contract does not transfer one fabulous-frog NFT and and take 50 STX from the user, the transaction will abort.
-
-You can learn more about how post conditions work in [SIP-005](https://github.com/stacksgov/sips/blob/main/sips/sip-005/sip-005-blocks-and-transactions.md#transaction-post-conditions) and how to utilize them in your applications in Hiro's excellent [post conditions tutorial](https://docs.hiro.so/stacks/stacks.js/guides/post-conditions).
diff --git a/concepts/transactions/transactions.md b/concepts/transactions/transactions.md
deleted file mode 100644
index bb4188dd8c..0000000000
--- a/concepts/transactions/transactions.md
+++ /dev/null
@@ -1,41 +0,0 @@
-# How Transactions Work
-
-### Introduction
-
-Transactions are the fundamental unit of execution in the Stacks blockchain. Each transaction is originated from a Stacks account, and is retained in the Stacks blockchain history for eternity. This guide helps you understand Stacks transactions.
-
-### Lifecycle
-
-Transactions go through phases before being finally confirmed, and available for all, on the Stacks 2.0 network.
-
-
-
-* **Generate**: Transactions are assembled according to the encoding specification.
-* **Validate and sign**: Transactions are validated to confirm they are well-formed. Required signatures are filled in.
-* **Broadcast**: Transactions are sent to a node.
-* **Register**: A miner receives transactions, verifies, and adds them to the ["mempool,"](https://academy.binance.com/en/glossary/mempool) a holding area for all the pending transactions.
-* **Process**: Miners review the mempool and select transactions for the next block to be mined. Depending on the transaction type, different actions can happen during this step. For example, post-conditions could be verified for a token transfer, smart-contract defined tokens could be minted, or an attempt to call an existing smart contract method could be made.
-* **Confirm**: Miners successfully propose blocks with a set of transactions. The transactions inside are successfully propagated to the network when the stackers approve them.
-
-{% hint style="info" %}
-A transaction can have one of three states once it is registered: `pending`, `success`, or `failed`.
-{% endhint %}
-
-### Types
-
-Stacks supports a set of different transaction types:
-
-| **Type** | **Value** | **Description** |
-| ------------------------- | ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Tenure change | `TenureChange` | A tenure change is an event in the existing Stacks blockchain when one miner assumes responsibility for creating new stacks blocks from another miner. A change in tenure occurs when a Stacks block is discovered from a cryptographic sortition. Carried out by stackers. |
-| Tenure change block found | `TenureChange-BlockFound` | A `TenureChange-BlockFound` transaction is induced by a winning sortition. This causes the new miner to start producing blocks, and stops the current miner from producing more blocks. |
-| Tenure change extend | `TenureChange-Extend` | A `TenureChange-Extend`, which is induced by Stackers, resets the current tenure's ongoing execution budget, thereby allowing the miner to continue producing blocks. |
-| Token transfer | `token_transfer` | Asset transfer from a sender to a recipient |
-| Contract deploy | `smart_contract` | Contract instantiation |
-| Contract call | `contract_call` | Contract call for a public, non read-only function |
-
-A sample of each transaction type can be found in the [Stacks Blockchain API response definition for transactions](https://docs.hiro.so/stacks/api/transactions/get-transaction).
-
-{% hint style="info" %}
-Read-only contract call calls do **not** require transactions. Read more about it in the network guide.
-{% endhint %}
diff --git a/docs/build/SUMMARY.md b/docs/build/SUMMARY.md
index 12607f5b73..c4e408edef 100644
--- a/docs/build/SUMMARY.md
+++ b/docs/build/SUMMARY.md
@@ -20,12 +20,6 @@
* [How to Use the sBTC JS Library for Bridging](sbtc/how-to-use-the-sbtc-js-library-for-bridging/README.md)
* [Depositing: Pegging BTC into sBTC](sbtc/how-to-use-the-sbtc-js-library-for-bridging/btc-to-sbtc.md)
* [Withdrawing: Pegging sBTC into BTC](sbtc/how-to-use-the-sbtc-js-library-for-bridging/sbtc-to-btc.md)
- * [How to Run sBTC Signer](sbtc/how-to-run-sbtc-signer.md)
- * [Best Practices for running an sBTC Signer](sbtc/best-practices-for-running-an-sbtc-signer.md)
- * [How to Use the sBTC Bridge with Xverse/Leather](sbtc/how-to-use-the-sbtc-bridge.md)
- * [How to Use the sBTC Bridge with Fordefi](sbtc/how-to-use-the-sbtc-bridge-with-fordefi.md)
- * [How to Use the sBTC Bridge with Asigna](sbtc/how-to-use-the-sbtc-bridge-with-asigna.md)
- * [How to Earn sBTC Rewards](sbtc/how-to-earn-sbtc-rewards.md)
* [Price Oracles](price-oracles.md)
## Misc. Guides
diff --git a/docs/learn/SUMMARY.md b/docs/learn/SUMMARY.md
index 9032d7ca28..13dd5496d6 100644
--- a/docs/learn/SUMMARY.md
+++ b/docs/learn/SUMMARY.md
@@ -49,6 +49,10 @@
* [Walkthroughs](sbtc/walkthroughs/README.md)
* [Signer Process Walkthrough](sbtc/walkthroughs/signer-process-walkthrough.md)
* [sBTC Transaction Walkthrough](sbtc/walkthroughs/sbtc-transaction-walkthrough.md)
+ * [How to Use the sBTC Bridge with Xverse/Leather](sbtc/walkthroughs/how-to-use-the-sbtc-bridge.md)
+ * [How to Use the sBTC Bridge with Fordefi](sbtc/walkthroughs/how-to-use-the-sbtc-bridge-with-fordefi.md)
+ * [How to Use the sBTC Bridge with Asigna](sbtc/walkthroughs/how-to-use-the-sbtc-bridge-with-asigna.md)
+ * [How to Earn sBTC Rewards](sbtc/walkthroughs/how-to-earn-sbtc-rewards.md)
* [sBTC FAQ](sbtc/sbtc-faq.md)
* [sBTC Audits](sbtc/sbtc-audits.md)
* [Dual Stacking](dual-stacking/README.md)
diff --git a/docs/build/sbtc/how-to-earn-sbtc-rewards.md b/docs/learn/sbtc/walkthroughs/how-to-earn-sbtc-rewards.md
similarity index 100%
rename from docs/build/sbtc/how-to-earn-sbtc-rewards.md
rename to docs/learn/sbtc/walkthroughs/how-to-earn-sbtc-rewards.md
diff --git a/docs/build/sbtc/how-to-use-the-sbtc-bridge-with-asigna.md b/docs/learn/sbtc/walkthroughs/how-to-use-the-sbtc-bridge-with-asigna.md
similarity index 100%
rename from docs/build/sbtc/how-to-use-the-sbtc-bridge-with-asigna.md
rename to docs/learn/sbtc/walkthroughs/how-to-use-the-sbtc-bridge-with-asigna.md
diff --git a/docs/build/sbtc/how-to-use-the-sbtc-bridge-with-fordefi.md b/docs/learn/sbtc/walkthroughs/how-to-use-the-sbtc-bridge-with-fordefi.md
similarity index 100%
rename from docs/build/sbtc/how-to-use-the-sbtc-bridge-with-fordefi.md
rename to docs/learn/sbtc/walkthroughs/how-to-use-the-sbtc-bridge-with-fordefi.md
diff --git a/docs/build/sbtc/how-to-use-the-sbtc-bridge.md b/docs/learn/sbtc/walkthroughs/how-to-use-the-sbtc-bridge.md
similarity index 100%
rename from docs/build/sbtc/how-to-use-the-sbtc-bridge.md
rename to docs/learn/sbtc/walkthroughs/how-to-use-the-sbtc-bridge.md
diff --git a/docs/operate/SUMMARY.md b/docs/operate/SUMMARY.md
index 955afa4cb3..16332ea770 100644
--- a/docs/operate/SUMMARY.md
+++ b/docs/operate/SUMMARY.md
@@ -19,6 +19,8 @@
* [How to Monitor Signer](run-a-signer/how-to-monitor-signer.md)
* [Best Practices to Run a Signer](run-a-signer/best-practices-to-run-a-signer.md)
* [OpSec Best Practices](run-a-signer/opsec-best-practices.md)
+* [Run a sBTC Signer](run-a-sbtc-signer/README.md)
+ * [Best Practices for Running a sBTC Signer](run-a-sbtc-signer/best-practices-for-running-an-sbtc-signer.md)
* [Snapshot the Chainstate](snapshot-the-chainstate.md)
* [Stacking STX](stacking-stx/README.md)
* [Solo Stack](stacking-stx/solo-stack.md)
diff --git a/docs/build/sbtc/how-to-run-sbtc-signer.md b/docs/operate/run-a-sbtc-signer/README.md
similarity index 100%
rename from docs/build/sbtc/how-to-run-sbtc-signer.md
rename to docs/operate/run-a-sbtc-signer/README.md
diff --git a/docs/build/sbtc/best-practices-for-running-an-sbtc-signer.md b/docs/operate/run-a-sbtc-signer/best-practices-for-running-an-sbtc-signer.md
similarity index 100%
rename from docs/build/sbtc/best-practices-for-running-an-sbtc-signer.md
rename to docs/operate/run-a-sbtc-signer/best-practices-for-running-an-sbtc-signer.md
diff --git a/example-contracts/audited-starter-contracts.md b/example-contracts/audited-starter-contracts.md
deleted file mode 100644
index 30ae4487bf..0000000000
--- a/example-contracts/audited-starter-contracts.md
+++ /dev/null
@@ -1,10 +0,0 @@
-# Audited Starter Contracts
-
-Here's a list of sample contracts to learn Clarity or to serve as a starting point for your next project. All contracts come from the [Clarity book](https://book.clarity-lang.org/) and have been audited by [Coinfabrik](https://www.coinfabrik.com/).
-
-* [Counter](https://github.com/clarity-lang/book/tree/main/projects/counter)
-* [Multisig Vault](https://github.com/clarity-lang/book/tree/main/projects/multisig-vault)
-* [Sip-009 NFT](https://github.com/clarity-lang/book/tree/main/projects/sip009-nft)
-* [SIP-010 FT](https://github.com/clarity-lang/book/tree/main/projects/sip010-ft)
-* [Timelocked Wallet](https://github.com/clarity-lang/book/tree/main/projects/timelocked-wallet)
-* [Tiny Market (NFT marketplace)](https://github.com/clarity-lang/book/tree/main/projects/tiny-market)
diff --git a/example-contracts/bns.md b/example-contracts/bns.md
deleted file mode 100644
index ffb4a68c85..0000000000
--- a/example-contracts/bns.md
+++ /dev/null
@@ -1,510 +0,0 @@
-# BNS
-
-The Bitcoin Name System (BNS) is implemented as a smart contract using Clarity.
-
-Below is a list of public and read-only functions as well as error codes that can be returned by those methods:
-
-* Public functions
-* Read-only functions
-* Error codes
-
-### Public functions
-
-#### name-import
-
-**Input: `(buff 20), (buff 48), principal, (buff 20)`**
-
-**Output: `(response bool int)`**
-
-**Signature: `(name-import namespace name beneficiary zonefile-hash)`**
-
-**Description:**
-
-Imports name to a revealed namespace. Each imported name is given both an owner and some off-chain state.
-
-#### name-preorder
-
-**Input: `(buff 20), uint`**
-
-**Output: `(response uint int)`**
-
-**Signature: `(name-preorder hashed-salted-fqn stx-to-burn)`**
-
-**Description:**
-
-Preorders a name by telling all BNS nodes the salted hash of the BNS name. It pays the registration fee to the namespace owner's designated address.
-
-#### name-register
-
-**Input: `(buff 20), (buff 48), (buff 20), (buff 20)`**
-
-**Output: `(response bool int)`**
-
-**Signature: `(name-register namespace name salt zonefile-hash)`**
-
-**Description:**
-
-Reveals the salt and the name to all BNS nodes, and assigns the name an initial public key hash and zone file hash.
-
-#### name-renewal
-
-**Input: `(buff 20), (buff 48), uint, (optional principal), (optional (buff 20))`**
-
-**Output: `(response bool int)`**
-
-**Signature: `(name-renewal namespace name stx-to-burn new-owner zonefile-hash)`**
-
-**Description:**
-
-Depending in the namespace rules, a name can expire. For example, names in the .id namespace expire after 2 years. You need to send a name renewal every so often to keep your name.
-
-You will pay the registration cost of your name to the namespace's designated burn address when you renew it. When a name expires, it enters a "grace period". The period is set to 5000 blocks (a month) but can be configured for each namespace.
-
-It will stop resolving in the grace period, and all of the above operations will cease to be honored by the BNS consensus rules. You may, however, send a NAME\_RENEWAL during this grace period to preserve your name. After the grace period, everybody can register that name again. If your name is in a namespace where names do not expire, then you never need to use this transaction.
-
-#### name-revoke
-
-**Input: `(buff 20), (buff 48)`**
-
-**Output: `(response bool int)`**
-
-**Signature: `(name-revoke namespace name)`**
-
-**Description:**
-
-Makes a name unresolvable. The BNS consensus rules stipulate that once a name is revoked, no one can change its public key hash or its zone file hash. The name's zone file hash is set to null to prevent it from resolving. You should only do this if your private key is compromised, or if you want to render your name unusable for whatever reason.
-
-#### name-transfer
-
-**Input: `(buff 20), (buff 48), principal, (optional (buff 20))`**
-
-**Output: `(response bool int)`**
-
-**Signature: `(name-transfer namespace name new-owner zonefile-hash)`**
-
-**Description:**
-
-Changes the name's public key hash. You would send a name transfer transaction if you wanted to:
-
-* Change your private key
-* Send the name to someone else or
-* Update your zone file
-
-When transferring a name, you have the option to also clear the name's zone file hash (i.e. set it to null). This is useful for when you send the name to someone else, so the recipient's name does not resolve to your zone file.
-
-#### name-update
-
-**Input: `(buff 20), (buff 48), (buff 20)`**
-
-**Output: `(response bool int)`**
-
-**Signature: `(name-update namespace name zonefile-hash)`**
-
-**Description:**
-
-Changes the name's zone file hash. You would send a name update transaction if you wanted to change the name's zone file contents. For example, you would do this if you want to deploy your own Gaia hub and want other people to read from it.
-
-#### namespace-preorder
-
-**Input: `(buff 20), uint`**
-
-**Output: `(response uint int)`**
-
-**Signature: `(namespace-preorder hashed-salted-namespace stx-to-burn)`**
-
-**Description:**
-
-Registers the salted hash of the namespace with BNS nodes, and burns the requisite amount of cryptocurrency. Additionally, this step proves to the BNS nodes that user has honored the BNS consensus rules by including a recent consensus hash in the transaction. Returns pre-order's expiration date (in blocks).
-
-#### namespace-ready
-
-**Input: `(buff 20)`**
-
-**Output: `(response bool int)`**
-
-**Signature: `(namespace-ready namespace)`**
-
-**Description:**
-
-Launches the namespace and makes it available to the public. Once a namespace is launched, anyone can register a name in it if they pay the appropriate amount of cryptocurrency.
-
-#### namespace-reveal
-
-**Input: `(buff 20), (buff 20), uint, uint, uint, uint, uint, uint, uint, uint, uint, uint, uint, uint, uint, uint, uint, uint, uint, uint, uint, uint, uint, principal`**
-
-**Output: `(response bool int)`**
-
-**Signature: `(namespace-reveal namespace namespace-salt p-func-base p-func-coeff p-func-b1 p-func-b2 p-func-b3 p-func-b4 p-func-b5 p-func-b6 p-func-b7 p-func-b8 p-func-b9 p-func-b10 p-func-b11 p-func-b12 p-func-b13 p-func-b14 p-func-b15 p-func-b16 p-func-non-alpha-discount p-func-no-vowel-discount lifetime namespace-import)`**
-
-**Description:**
-
-Reveals the salt and the namespace ID (after a namespace preorder). It reveals how long names last in this namespace before they expire or must be renewed, and it sets a price function for the namespace that determines how cheap or expensive names its will be.All of the parameters prefixed by `p` make up the `price function`. These parameters govern the pricing and lifetime of names in the namespace.
-
-The rules for a namespace are as follows:
-
-* a name can fall into one of 16 buckets, measured by length. Bucket 16 incorporates all names at least 16 characters long.
-* the pricing structure applies a multiplicative penalty for having numeric characters, or punctuation characters.
-* the price of a name in a bucket is `((coeff) * (base) ^ (bucket exponent)) / ((numeric discount multiplier) * (punctuation discount multiplier))`
-
-Example:
-
-* base = 10
-* coeff = 2
-* nonalpha discount: 10
-* no-vowel discount: 10
-* buckets 1, 2: 9
-* buckets 3, 4, 5, 6: 8
-* buckets 7, 8, 9, 10, 11, 12, 13, 14: 7
-* buckets 15, 16+:
-
-### Read-only functions
-
-#### can-name-be-registered
-
-**Input: `(buff 20), (buff 48)`**
-
-**Output: `(response bool int)`**
-
-**Signature: `(can-name-be-registered namespace name)`**
-
-**Description:**
-
-Returns true if the provided name can be registered.
-
-#### can-namespace-be-registered
-
-**Input: `(buff 20)`**
-
-**Output: `(response bool UnknownType)`**
-
-**Signature: `(can-namespace-be-registered namespace)`**
-
-**Description:**
-
-Returns true if the provided namespace is available.
-
-#### can-receive-name
-
-**Input: `principal`**
-
-**Output: `(response bool int)`**
-
-**Signature: `(can-receive-name owner)`**
-
-**Description:**
-
-Returns true if the provided name can be received. That is, if it is not currently owned, a previous lease is expired, and the name wasn't revoked.
-
-#### get-name-price
-
-**Input: `(buff 20), (buff 48)`**
-
-**Output: `(response uint int)`**
-
-**Signature: `(get-name-price namespace name)`**
-
-**Description:**
-
-Gets the price for a name.
-
-#### get-namespace-price
-
-**Input: `(buff 20)`**
-
-**Output: `(response uint int)`**
-
-**Signature: `(get-namespace-price namespace)`**
-
-**Description:**
-
-Gets the price for a namespace.
-
-#### get-namespace-properties
-
-**Input: `(buff 20)`**
-
-**Output: `(response (tuple (namespace (buff 20)) (properties (tuple (can-update-price-function bool) (launched-at (optional uint)) (lifetime uint) (namespace-import principal) (price-function (tuple (base uint) (buckets (list 16 uint)) (coeff uint) (no-vowel-discount uint) (nonalpha-discount uint))) (revealed-at uint)))) int)`**
-
-**Signature: `(get-namespace-properties namespace)`**
-
-**Description:**
-
-Get namespace properties.
-
-#### is-name-lease-expired
-
-**Input: `(buff 20), (buff 48)`**
-
-**Output: `(response bool int)`**
-
-**Signature: `(is-name-lease-expired namespace name)`**
-
-**Description:**
-
-Return true if the provided name lease is expired.
-
-#### name-resolve
-
-**Input: `(buff 20), (buff 48)`**
-
-**Output: `(response (tuple (lease-ending-at (optional uint)) (lease-started-at uint) (owner principal) (zonefile-hash (buff 20))) int)`**
-
-**Signature: `(name-resolve namespace name)`**
-
-**Description:**
-
-Get name registration details.
-
-#### resolve-principal
-
-**Input: `principal`**
-
-**Output: `(response (tuple (name (buff 48)) (namespace (buff 20))) (tuple (code int) (name (optional (tuple (name (buff 48)) (namespace (buff 20)))))))`**
-
-**Signature: `(resolve-principal owner)`**
-
-**Description:**
-
-Returns the registered name that a principal owns if there is one. A principal can only own one name at a time.
-
-### Error codes
-
-#### ERR\_INSUFFICIENT\_FUNDS
-
-**type: `int`**
-
-**value: `4001`**
-
-#### ERR\_NAMESPACE\_ALREADY\_EXISTS
-
-**type: `int`**
-
-**value: `1006`**
-
-#### ERR\_NAMESPACE\_ALREADY\_LAUNCHED
-
-**type: `int`**
-
-**value: `1014`**
-
-#### ERR\_NAMESPACE\_BLANK
-
-**type: `int`**
-
-**value: `1013`**
-
-#### ERR\_NAMESPACE\_CHARSET\_INVALID
-
-**type: `int`**
-
-**value: `1016`**
-
-#### ERR\_NAMESPACE\_HASH\_MALFORMED
-
-**type: `int`**
-
-**value: `1015`**
-
-#### ERR\_NAMESPACE\_NOT\_FOUND
-
-**type: `int`**
-
-**value: `1005`**
-
-#### ERR\_NAMESPACE\_NOT\_LAUNCHED
-
-**type: `int`**
-
-**value: `1007`**
-
-#### ERR\_NAMESPACE\_OPERATION\_UNAUTHORIZED
-
-**type: `int`**
-
-**value: `1011`**
-
-#### ERR\_NAMESPACE\_PREORDER\_ALREADY\_EXISTS
-
-**type: `int`**
-
-**value: `1003`**
-
-#### ERR\_NAMESPACE\_PREORDER\_CLAIMABILITY\_EXPIRED
-
-**type: `int`**
-
-**value: `1009`**
-
-#### ERR\_NAMESPACE\_PREORDER\_EXPIRED
-
-**type: `int`**
-
-**value: `1002`**
-
-#### ERR\_NAMESPACE\_PREORDER\_LAUNCHABILITY\_EXPIRED
-
-**type: `int`**
-
-**value: `1010`**
-
-#### ERR\_NAMESPACE\_PREORDER\_NOT\_FOUND
-
-**type: `int`**
-
-**value: `1001`**
-
-#### ERR\_NAMESPACE\_PRICE\_FUNCTION\_INVALID
-
-**type: `int`**
-
-**value: `1008`**
-
-#### ERR\_NAMESPACE\_STX\_BURNT\_INSUFFICIENT
-
-**type: `int`**
-
-**value: `1012`**
-
-#### ERR\_NAMESPACE\_UNAVAILABLE
-
-**type: `int`**
-
-**value: `1004`**
-
-#### ERR\_NAME\_ALREADY\_CLAIMED
-
-**type: `int`**
-
-**value: `2011`**
-
-#### ERR\_NAME\_BLANK
-
-**type: `int`**
-
-**value: `2010`**
-
-#### ERR\_NAME\_CHARSET\_INVALID
-
-**type: `int`**
-
-**value: `2022`**
-
-#### ERR\_NAME\_CLAIMABILITY\_EXPIRED
-
-**type: `int`**
-
-**value: `2012`**
-
-#### ERR\_NAME\_COULD\_NOT\_BE\_MINTED
-
-**type: `int`**
-
-**value: `2020`**
-
-#### ERR\_NAME\_COULD\_NOT\_BE\_TRANSFERRED
-
-**type: `int`**
-
-**value: `2021`**
-
-#### ERR\_NAME\_EXPIRED
-
-**type: `int`**
-
-**value: `2008`**
-
-#### ERR\_NAME\_GRACE\_PERIOD
-
-**type: `int`**
-
-**value: `2009`**
-
-#### ERR\_NAME\_HASH\_MALFORMED
-
-**type: `int`**
-
-**value: `2017`**
-
-#### ERR\_NAME\_NOT\_FOUND
-
-**type: `int`**
-
-**value: `2013`**
-
-#### ERR\_NAME\_NOT\_RESOLVABLE
-
-**type: `int`**
-
-**value: `2019`**
-
-#### ERR\_NAME\_OPERATION\_UNAUTHORIZED
-
-**type: `int`**
-
-**value: `2006`**
-
-#### ERR\_NAME\_PREORDERED\_BEFORE\_NAMESPACE\_LAUNCH
-
-**type: `int`**
-
-**value: `2018`**
-
-#### ERR\_NAME\_PREORDER\_ALREADY\_EXISTS
-
-**type: `int`**
-
-**value: `2016`**
-
-#### ERR\_NAME\_PREORDER\_EXPIRED
-
-**type: `int`**
-
-**value: `2002`**
-
-#### ERR\_NAME\_PREORDER\_FUNDS\_INSUFFICIENT
-
-**type: `int`**
-
-**value: `2003`**
-
-#### ERR\_NAME\_PREORDER\_NOT\_FOUND
-
-**type: `int`**
-
-**value: `2001`**
-
-#### ERR\_NAME\_REVOKED
-
-**type: `int`**
-
-**value: `2014`**
-
-#### ERR\_NAME\_STX\_BURNT\_INSUFFICIENT
-
-**type: `int`**
-
-**value: `2007`**
-
-#### ERR\_NAME\_TRANSFER\_FAILED
-
-**type: `int`**
-
-**value: `2015`**
-
-#### ERR\_NAME\_UNAVAILABLE
-
-**type: `int`**
-
-**value: `2004`**
-
-#### ERR\_PANIC
-
-**type: `int`**
-
-**value: `0`**
-
-#### ERR\_PRINCIPAL\_ALREADY\_ASSOCIATED
-
-**type: `int`**
-
-**value: `3001`**
diff --git a/example-contracts/multi-send.md b/example-contracts/multi-send.md
deleted file mode 100644
index 286279cc18..0000000000
--- a/example-contracts/multi-send.md
+++ /dev/null
@@ -1,21 +0,0 @@
-# Multi Send
-
-Multi send is a very simple but highly useful utility contract for executing multiple STX transfers in a single transaction.
-
-It takes in a list of addresses and amounts and folds through them to execute a STX transfer for each one.
-
-Mainnet contract: [https://explorer.hiro.so/txid/0x59665b756dc0fa9efb3fca9e05a28f572c9b14ca894c115fd3e7d81a563e14f8?chain=mainnet](https://explorer.hiro.so/txid/0x59665b756dc0fa9efb3fca9e05a28f572c9b14ca894c115fd3e7d81a563e14f8?chain=mainnet)
-
-```clojure
-;; send-many
-(define-private (send-stx (recipient { to: principal, ustx: uint }))
- (stx-transfer? (get ustx recipient) tx-sender (get to recipient)))
-(define-private (check-err (result (response bool uint))
- (prior (response bool uint)))
- (match prior ok-value result
- err-value (err err-value)))
-(define-public (send-many (recipients (list 200 { to: principal, ustx: uint })))
- (fold check-err
- (map send-stx recipients)
- (ok true)))
-```
diff --git a/example-contracts/stacking.md b/example-contracts/stacking.md
deleted file mode 100644
index 53f605b61c..0000000000
--- a/example-contracts/stacking.md
+++ /dev/null
@@ -1,475 +0,0 @@
-# Stacking
-
-Stacking is implemented as a smart contract using Clarity. You can always find the Stacking contract identifier using the Stacks Blockchain API [`v2/pox` endpoint](https://docs.hiro.so/api#operation/get\_pox\_info).
-
-Currently, stacking uses the pox-4 contract. The deployed pox-4 contract and included comments can be [viewed in the explorer](https://explorer.hiro.so/txid/SP000000000000000000002Q6VF78.pox-4?chain=mainnet).
-
-In this walkthrough, we'll cover the entire stacking contract from start to finish, including descriptions of the various functions and errors, and when you might use/encounter them.
-
-If you are running into a specific stacking error, jump to the [errors section](stacking.md#errors).
-
-Rather than walking through the contract line by line, which you can do by simply reading the contract code and the comments, we'll instead explore it from the perspective of conducting stacking operations, including solo stacking, delegating, and running a pool.
-
-At the bottom you will find a list of some errors you may run into and their explanations.
-
-There are a few utilities that make interacting with this contract easier including [Leather Earn](https://earn.leather.io) as an UI and the [@stacks/stacking package](https://www.npmjs.com/package/@stacks/stacking) for a JS library.
-
-Hiro has a [detailed guide](https://docs.hiro.so/stacks.js/guides/how-to-integrate-stacking) available for stacking using this library as well as a [Nakamoto guide](https://docs.hiro.so/nakamoto/stacks-js) specifically for the additions made to work with `pox-4`.
-
-### Prerequisites
-
-If you are not familiar with stacking as a concept, it will be useful to [familiarize yourself with that first](../concepts/block-production/stacking.md) before diving into the contract.
-
-### Solo Stacking
-
-Solo stacking is the simplest option, and begins by calling the `stack-stx` function.
-
-#### stack-stx
-
-This function locks up the given amount of STX for the given lock period (number of reward cycles) for the `tx-sender`.
-
-Here's the full code for that function, then we'll dive into how it works below that.
-
-```clojure
-(define-public (stack-stx (amount-ustx uint)
- (pox-addr (tuple (version (buff 1)) (hashbytes (buff 32))))
- (start-burn-ht uint)
- (lock-period uint)
- (signer-sig (optional (buff 65)))
- (signer-key (buff 33))
- (max-amount uint)
- (auth-id uint))
- ;; this stacker's first reward cycle is the _next_ reward cycle
- (let ((first-reward-cycle (+ u1 (current-pox-reward-cycle)))
- (specified-reward-cycle (+ u1 (burn-height-to-reward-cycle start-burn-ht))))
- ;; the start-burn-ht must result in the next reward cycle, do not allow stackers
- ;; to "post-date" their `stack-stx` transaction
- (asserts! (is-eq first-reward-cycle specified-reward-cycle)
- (err ERR_INVALID_START_BURN_HEIGHT))
-
- ;; must be called directly by the tx-sender or by an allowed contract-caller
- (asserts! (check-caller-allowed)
- (err ERR_STACKING_PERMISSION_DENIED))
-
- ;; tx-sender principal must not be stacking
- (asserts! (is-none (get-stacker-info tx-sender))
- (err ERR_STACKING_ALREADY_STACKED))
-
- ;; tx-sender must not be delegating
- (asserts! (is-none (get-check-delegation tx-sender))
- (err ERR_STACKING_ALREADY_DELEGATED))
-
- ;; the Stacker must have sufficient unlocked funds
- (asserts! (>= (stx-get-balance tx-sender) amount-ustx)
- (err ERR_STACKING_INSUFFICIENT_FUNDS))
-
- ;; Validate ownership of the given signer key
- (try! (consume-signer-key-authorization pox-addr (- first-reward-cycle u1) "stack-stx" lock-period signer-sig signer-key amount-ustx max-amount auth-id))
-
- ;; ensure that stacking can be performed
- (try! (can-stack-stx pox-addr amount-ustx first-reward-cycle lock-period))
-
- ;; register the PoX address with the amount stacked
- (let ((reward-set-indexes (try! (add-pox-addr-to-reward-cycles pox-addr first-reward-cycle lock-period amount-ustx tx-sender signer-key))))
- ;; add stacker record
- (map-set stacking-state
- { stacker: tx-sender }
- { pox-addr: pox-addr,
- reward-set-indexes: reward-set-indexes,
- first-reward-cycle: first-reward-cycle,
- lock-period: lock-period,
- delegated-to: none })
-
- ;; return the lock-up information, so the node can actually carry out the lock.
- (ok { stacker: tx-sender, lock-amount: amount-ustx, signer-key: signer-key, unlock-burn-height: (reward-cycle-to-burn-height (+ first-reward-cycle lock-period)) }))))
-```
-
-First let's cover the needed parameters.
-
-* `amount-ustx` is the amount of STX you would like to lock, denoted in micro-STX, or uSTX (1 STX = 1,000,000 uSTX).
-* `pox-addr` is a tuple that encodes the Bitcoin address to be used for the PoX rewards, details below.
-* `start-burn-ht` is the Bitcoin block height you would like to begin stacking. You will receive rewards in the reward cycle following `start-burn-ht`. Importantly, `start-burn-ht` may not be further into the future than the current reward cycle, and in most cases should be set to the current burn block height.
-* `lock-period` sets the number of reward cycles you would like you lock your STX for, this can be between 1 and 12.
-* `signer-sig` is a unique generated signature that proves ownership of this signer. Further details for its role and how to generate it can be found in the [How to Stack](../guides-and-tutorials/stack-stx/stacking-flow.md) document.
-* `signer-key` is the public key of your signer, more details in the [How to Run a Signer](../guides-and-tutorials/running-a-signer/) document.
-* `max-amount` sets the maximum amount allowed to be stacked during the provided stacking period.
-* `auth-id` is a unique string to prevent re-use of this stacking transaction.
-
-{% hint style="warning" %}
-It's important to make sure that these fields match what you pass in to the signer signature generation. If they don't, you will likely get error 35 (`ERR_INVALID_SIGNATURE_PUBKEY`) \
-when trying to submit this transaction as the signer signature will not be valid.
-{% endhint %}
-
-#### Supported Reward Address Types
-
-{% hint style="info" %}
-For the `pox-addr` field, the `version` buffer must represent what kind of bitcoin address is being submitted. These are all the possible values you can pass here depending on your address type:
-
-```clojure
-(define-constant ADDRESS_VERSION_P2PKH 0x00)
-(define-constant ADDRESS_VERSION_P2SH 0x01)
-(define-constant ADDRESS_VERSION_P2WPKH 0x02)
-(define-constant ADDRESS_VERSION_P2WSH 0x03)
-(define-constant ADDRESS_VERSION_NATIVE_P2WPKH 0x04)
-(define-constant ADDRESS_VERSION_NATIVE_P2WSH 0x05)
-(define-constant ADDRESS_VERSION_NATIVE_P2TR 0x06)
-```
-
-The `hashbytes` are the 20 hash bytes of the bitcoin address. You can obtain that from a bitcoin library, for instance using [`bitcoinjs-lib`](https://github.com/bitcoinjs/bitcoinjs-lib):
-
-```javascript
-const btc = require("bitcoinjs-lib");
-console.log(
- "0x" +
- btc.address
- .fromBase58Check("1C56LYirKa3PFXFsvhSESgDy2acEHVAEt6")
- .hash.toString("hex")
-);
-```
-{% endhint %}
-
-The first thing the `stack-stx` function will do perform several checks including:
-
-* The `start-burn-ht` results in the next reward cycle
-* The function is being called by the `tx-sender` or an allowed contract caller
-* The `tx-sender` is not currently stacking or delegating
-* The `tx-sender` has enough funds
-* The given `signer-key` is valid, proving ownership
-* Stacking can be performed. This is determined through additional checks including if the amount meets the minimum stacking threshold and if the lock period and provided Bitcoin address are valid
-
-You can explore the private functions that handle these checks to see exactly how they do so.
-
-Next we register the provided PoX address for the next reward cycle, assign its specific reward slot, and add it to the `stacking-state` map, which keeps track of all current stackers per reward cycle.
-
-Finally we return the lock up information so the node can carry out the lock by reading this information. This step is what actually locks the STX and prevents the stacker from using them on-chain.
-
-From here, the locked STX tokens will be unlocked automatically at the end of the lock period.
-
-The other option is that the stacker can call the `stack-increase` or `stack-extend` functions to either increase the amount of STX they have locked or extend the time to lock them, respectively.
-
-### Delegated Stacking
-
-Delegated stacking has a few additional steps to it. It is essentially a three-step process:
-
-* Delegator delegates their STX to a pool operator
-* Pool operator stacks their delegated STX
-* Pool operator commits an aggregate of all STX delegated to them
-
-There are also a few alternative steps here depending on the action you want to take.
-
-* Revoke delegation
-
-Each of these steps has a corresponding function. Let's dig into them.
-
-#### delegate-stx
-
-This function is called by the individual stacker delegating their STX to a pool operator. An individual stacker choosing to delegate does not need to run their own signer.
-
-This function does not actually lock the STX, but just allows the pool operator to issue the lock.
-
-```clojure
-(define-public (delegate-stx (amount-ustx uint)
- (delegate-to principal)
- (until-burn-ht (optional uint))
- (pox-addr (optional { version: (buff 1), hashbytes: (buff 32) })))
-
- (begin
- ;; must be called directly by the tx-sender or by an allowed contract-caller
- (asserts! (check-caller-allowed)
- (err ERR_STACKING_PERMISSION_DENIED))
-
- ;; delegate-stx no longer requires the delegator to not currently
- ;; be stacking.
- ;; delegate-stack-* functions assert that
- ;; 1. users can't swim in two pools at the same time.
- ;; 2. users can't switch pools without cool down cycle.
- ;; Other pool admins can't increase or extend.
- ;; 3. users can't join a pool while already directly stacking.
-
- ;; pox-addr, if given, must be valid
- (match pox-addr
- address
- (asserts! (check-pox-addr-version (get version address))
- (err ERR_STACKING_INVALID_POX_ADDRESS))
- true)
-
- ;; tx-sender must not be delegating
- (asserts! (is-none (get-check-delegation tx-sender))
- (err ERR_STACKING_ALREADY_DELEGATED))
-
- ;; add delegation record
- (map-set delegation-state
- { stacker: tx-sender }
- { amount-ustx: amount-ustx,
- delegated-to: delegate-to,
- until-burn-ht: until-burn-ht,
- pox-addr: pox-addr })
-
- (ok true)))
-```
-
-This function takes a few parameters:
-
-* `amount-ustx` is the amount the stacker is delegating denoted in uSTX.
-* `delegate-to` is the Stacks address of the pool operator (or delegate) being delegated to.
-* `until-burn-ht` is an optional parameter that describes when this delegation expires.
-* `pox-addr` is an optional Bitcoin address. If this is provided, the pool operator must send rewards to this address. If it is not provided, it is up to the discretion of the pool operator where to send the rewards.
-
-It first runs through a few checks to ensure that the function caller is allowed, the provided `pox-addr` is valid, and that the stacker is not already delegating.
-
-Finally it updates the `delegation-state` of the contract with the details.
-
-At this point, no STX have been locked. The pool operator next needs to call the `delegate-stack-stx` function in order to partially lock the STX.
-
-#### delegate-stack-stx
-
-```clojure
-;; As a delegate, stack the given principal's STX using partial-stacked-by-cycle
-;; Once the delegate has stacked > minimum, the delegate should call stack-aggregation-commit
-(define-public (delegate-stack-stx (stacker principal)
- (amount-ustx uint)
- (pox-addr { version: (buff 1), hashbytes: (buff 32) })
- (start-burn-ht uint)
- (lock-period uint))
- ;; this stacker's first reward cycle is the _next_ reward cycle
- (let ((first-reward-cycle (+ u1 (current-pox-reward-cycle)))
- (specified-reward-cycle (+ u1 (burn-height-to-reward-cycle start-burn-ht)))
- (unlock-burn-height (reward-cycle-to-burn-height (+ (current-pox-reward-cycle) u1 lock-period))))
- ;; the start-burn-ht must result in the next reward cycle, do not allow stackers
- ;; to "post-date" their `stack-stx` transaction
- (asserts! (is-eq first-reward-cycle specified-reward-cycle)
- (err ERR_INVALID_START_BURN_HEIGHT))
-
- ;; must be called directly by the tx-sender or by an allowed contract-caller
- (asserts! (check-caller-allowed)
- (err ERR_STACKING_PERMISSION_DENIED))
-
- ;; stacker must have delegated to the caller
- (let ((delegation-info (unwrap! (get-check-delegation stacker) (err ERR_STACKING_PERMISSION_DENIED))))
- ;; must have delegated to tx-sender
- (asserts! (is-eq (get delegated-to delegation-info) tx-sender)
- (err ERR_STACKING_PERMISSION_DENIED))
- ;; must have delegated enough stx
- (asserts! (>= (get amount-ustx delegation-info) amount-ustx)
- (err ERR_DELEGATION_TOO_MUCH_LOCKED))
- ;; if pox-addr is set, must be equal to pox-addr
- (asserts! (match (get pox-addr delegation-info)
- specified-pox-addr (is-eq pox-addr specified-pox-addr)
- true)
- (err ERR_DELEGATION_POX_ADDR_REQUIRED))
- ;; delegation must not expire before lock period
- (asserts! (match (get until-burn-ht delegation-info)
- until-burn-ht (>= until-burn-ht
- unlock-burn-height)
- true)
- (err ERR_DELEGATION_EXPIRES_DURING_LOCK))
- )
-
- ;; stacker principal must not be stacking
- (asserts! (is-none (get-stacker-info stacker))
- (err ERR_STACKING_ALREADY_STACKED))
-
- ;; the Stacker must have sufficient unlocked funds
- (asserts! (>= (stx-get-balance stacker) amount-ustx)
- (err ERR_STACKING_INSUFFICIENT_FUNDS))
-
- ;; ensure that stacking can be performed
- (try! (minimal-can-stack-stx pox-addr amount-ustx first-reward-cycle lock-period))
-
- ;; register the PoX address with the amount stacked via partial stacking
- ;; before it can be included in the reward set, this must be committed!
- (add-pox-partial-stacked pox-addr first-reward-cycle lock-period amount-ustx)
-
- ;; add stacker record
- (map-set stacking-state
- { stacker: stacker }
- { pox-addr: pox-addr,
- first-reward-cycle: first-reward-cycle,
- reward-set-indexes: (list),
- lock-period: lock-period,
- delegated-to: (some tx-sender) })
-
- ;; return the lock-up information, so the node can actually carry out the lock.
- (ok { stacker: stacker,
- lock-amount: amount-ustx,
- unlock-burn-height: unlock-burn-height })))
-```
-
-At this point, the stacker has given their permission to the pool operator to delegate their STX on their behalf.
-
-The delegation is now in the hands of the pool operator to stack these delegated STX using the `delegate-stack-stx` function.
-
-This function can only be called after a stacker has called their respective `delegate-stx` function and must be called by the pool operator for each instance of a stacker calling `delegate-stx`.
-
-Like the other functions, this function takes in several parameters and runs through several checks before updating the contract state.
-
-* `stacker` is the principal of the stacker who has delegated their STX.
-* `amount-ustx` is at most the amount of uSTX they have delegated.
-* `pox-addr` is the Bitcoin address the rewards will be sent to. If the stacker passed this field in to their `delegate-stx` function, this must be the same value.
-* `start-burn-ht` corresponds to the field passed in by the stacker.
-* `lock-period` corresponds to the number of cycles to lock the funds for. This can be at most 12, or the number of cycles left until the cycle matching `until-burn-ht` argument in `delegate-stx` (if set by delegator).
-
-Now we assign a few variables using `let` before running several checks.
-
-* `first-reward-cycle` is set to the next reward cycle automatically
-* `specified-reward-cycle` is the reward cycle that the passed-in `start-burn-ht` parameter falls within
-* `unlock-burn-height` is the Bitcoin block height at which the stackers STX will be unlocked
-
-Now we proceed to run through some checks including:
-
-* The first reward cycle is the same as the specified reward cycle
-* The function is being called by the `tx-sender` or an approved contract
-* That the stacker actually delegated to the contract caller
-* Then we get the information from the delegation and make sure the information we are passing here matches it
-* That the stacker is not currently stacking
-* They have sufficient unlocked funds
-* Run the `minimal-can-stack-stx` to run a few additional checks to make sure stacking can occur
-
-Next we call a function called `add-pox-partial-stacked` which will add this stacker to a `partial-stacked-by-cycle` map.
-
-After those checks and partial stacking, we update the `stacking-state` map and return the information for the node to process.
-
-At this point this stacker's STX are considered partially stacked. We still need to perform one more step as the pool operator in order to officially lock them.
-
-#### stack-aggregation-commit-indexed
-
-The `stack-aggregation-commit-indexed` function is just a wrapper for the private `inner-stack-aggregation-commit` function, so that is the source code included here.
-
-```clojure
-;; Commit partially stacked STX and allocate a new PoX reward address slot.
-;; This allows a stacker/delegate to lock fewer STX than the minimal threshold in multiple transactions,
-;; so long as: 1. The pox-addr is the same.
-;; 2. This "commit" transaction is called _before_ the PoX anchor block.
-;; This ensures that each entry in the reward set returned to the stacks-node is greater than the threshold,
-;; but does not require it be all locked up within a single transaction
-;;
-;; Returns (ok uint) on success, where the given uint is the reward address's index in the list of reward
-;; addresses allocated in this reward cycle. This index can then be passed to `stack-aggregation-increase`
-;; to later increment the STX this PoX address represents, in amounts less than the stacking minimum.
-;;
-;; *New in Stacks 2.1.*
-(define-private (inner-stack-aggregation-commit (pox-addr { version: (buff 1), hashbytes: (buff 32) })
- (reward-cycle uint)
- (signer-sig (optional (buff 65)))
- (signer-key (buff 33))
- (max-amount uint)
- (auth-id uint))
- (let ((partial-stacked
- ;; fetch the partial commitments
- (unwrap! (map-get? partial-stacked-by-cycle { pox-addr: pox-addr, sender: tx-sender, reward-cycle: reward-cycle })
- (err ERR_STACKING_NO_SUCH_PRINCIPAL))))
- ;; must be called directly by the tx-sender or by an allowed contract-caller
- (asserts! (check-caller-allowed)
- (err ERR_STACKING_PERMISSION_DENIED))
- (let ((amount-ustx (get stacked-amount partial-stacked)))
- (try! (consume-signer-key-authorization pox-addr reward-cycle "agg-commit" u1 signer-sig signer-key amount-ustx max-amount auth-id))
- (try! (can-stack-stx pox-addr amount-ustx reward-cycle u1))
- ;; Add the pox addr to the reward cycle, and extract the index of the PoX address
- ;; so the delegator can later use it to call stack-aggregation-increase.
- (let ((add-pox-addr-info
- (add-pox-addr-to-ith-reward-cycle
- u0
- { pox-addr: pox-addr,
- first-reward-cycle: reward-cycle,
- num-cycles: u1,
- reward-set-indexes: (list),
- stacker: none,
- signer: signer-key,
- amount-ustx: amount-ustx,
- i: u0 }))
- (pox-addr-index (unwrap-panic
- (element-at (get reward-set-indexes add-pox-addr-info) u0))))
-
- ;; don't update the stacking-state map,
- ;; because it _already has_ this stacker's state
- ;; don't lock the STX, because the STX is already locked
- ;;
- ;; clear the partial-stacked state, and log it
- (map-delete partial-stacked-by-cycle { pox-addr: pox-addr, sender: tx-sender, reward-cycle: reward-cycle })
- (map-set logged-partial-stacked-by-cycle { pox-addr: pox-addr, sender: tx-sender, reward-cycle: reward-cycle } partial-stacked)
- (ok pox-addr-index)))))
-```
-
-This function contains many of the same parameters as the `stack-stx` function, with a few changes:
-
-* `pox-addr` is a tuple that encodes the Bitcoin address to be used for the PoX rewards, details below
-* `reward-cycle` is the reward cycle that these delegated STX will be stacked in
-* `signer-sig` is a unique generated signature that proves ownership of this signer. Further details for its role and how to generate it can be found in the [How to Stack](../guides-and-tutorials/stack-stx/stacking-flow.md) doc
-* `signer-key` is the public key of your signer, more details in the [How to Run a Signer](../guides-and-tutorials/running-a-signer/) doc
-* `max-amount` sets the maximum amount allowed to be stacked during the provided stacking period
-* `auth-id` is a unique string to prevent re-use of this stacking transaction
-
-{% hint style="warning" %}
-It's important to make sure that these fields match what you pass in to the signer signature generation. If they don't, you will likely get error 35 (`ERR_INVALID_SIGNATURE_PUBKEY`) when trying to submit this transaction as the signer signature will not be valid.
-{% endhint %}
-
-The first thing we do is pull the partially stacked STX that have been added to the contract state via our `delegate-stack-stx` calls.
-
-Next we run through many of the same checks as in previous functions:
-
-* Making sure the contract caller is allowed
-* Making sure the signer signature is valid
-* Making sure we can actually perform this stacking operation
-
-Now we take all of the delegated STX and actually add it to the reward cycle. At this point the pool operator has a reward slot in the chosen cycle.
-
-We don't need to update the stacking state because we already did that in the `delegate-stack-stx` function.
-
-All we need to do is delete and log the partially stacked STX state.
-
-### How Stacking Reward Distribution Works
-
-All of the above stacking functions take in a `pox-reward` field that corresponds to a Bitcoin address where BTC rewards will be sent. It's important to understand how these addresses are used and how reward distribution is handled in general.
-
-How Bitcoin rewards are distributed is primarily up to the discretion of the pool operator. Since PoX reward distributions are handled using Bitcoin transactions, there is currently not an effective way to automate their distribution to individual delegated stackers.
-
-Let's go over the role of `pox-addr` in each function and how it should be used.
-
-#### stack-stx
-
-This is the simplest option and simply corresponds to the Bitcoin address that the stacker would like to receive their rewards.
-
-#### delegate-stx
-
-In this function, which is the one that the delegator will be calling to give permission to the pool operator to stack on their behalf, the `pox-addr` argument is optional.
-
-If no `pox-addr` argument is not passed in, the pool operator determines where this delegator's rewards are sent.
-
-If a `pox-addr` is passed in, then rewards must be distributed to that address. **However, if this is passed in, the delegator must have enough STX to meet the minimum stacking amount.**
-
-The reason is because there are a finite amount of reward slots (4,000) and each `pox-addr` takes up one of these reward slots.
-
-Stackers need to be able to stack the minimum in order to be eligible for one of these reward slots. A delegator may choose to delegate to a pool (even if they meet the minimum stacking requirement) if they do not want to handle the infrastructure of running a signer or the actual stacking operations, which is why this option exists.
-
-#### delegate-stack-stx and stack-aggregation-commit-indexed
-
-In both of these functions, `pox-addr` corresponds to the address where the pool operator would like the rewards to be sent.
-
-At this point, it is up to the pool operator to determine how to allocate rewards. In most cases, a pool operator will use a wrapper contract in order to transparently track this information on-chain, and manually send rewards out to participants according to the proportion that they delegated.
-
-### Errors
-
-You may encounter several errors when trying to perform stacking operations. We won't cover them all in detail here, as you can see the error in the failed transaction and trace the source code to find it.
-
-But we will cover some of the more common errors you may encounter, what they mean, and how to resolve them.
-
-#### Error 35 - `ERR_INVALID_SIGNATURE_PUBKEY`
-
-This is likely the most common error you will encounter, and you'll usually see it in a failed `stack-stx` or `stack-aggregation-commit` transaction.
-
-This error actually occurs in the `consume-signer-key-authorization` which is called any time we pass in a signer signature.
-
-This means one of two things:
-
-* The public key you used to generate the signer signature is not the same as the one you are passing in to the `signer-key` field
-* One of the fields you passed in to generate your signer signature does not match the field you passed in to either the `stack-stx` or `stack-aggregation-commit` function
-
-To fix this, check all of the data you passed in to see where the mismatch is.
-
-#### Error 4 - ERR\_STACKING\_NO\_SUCH\_PRINCIPAL
-
-The stacking contract looks up partially stacked stx (after you have called `delegate-stack-stx`) with the lookup key `(pox-addr, stx-address, reward-cycle)`. This error means that either when you generated your signature or called the `stack-aggregation-commit` function, you passed in the wrong parameter for one of these. More information in the [stacking guide](../guides-and-tutorials/stack-stx/stacking-flow.md#delegator-initiates-delegation).
-
-#### Error 24 - ERR\_INVALID\_START\_BURN\_HEIGHT;
-
-This means that the `start-burn-height` parameter parsed was invalid (in a past or future cycle, instead of the current one). This error will mostly be seen in `stack-stx` or `delegate-stack-stx` failed transactions.
diff --git a/guides-and-tutorials/best-practices-to-snapshot-the-chainstate.md b/guides-and-tutorials/best-practices-to-snapshot-the-chainstate.md
deleted file mode 100644
index 87387a689e..0000000000
--- a/guides-and-tutorials/best-practices-to-snapshot-the-chainstate.md
+++ /dev/null
@@ -1,212 +0,0 @@
-# Best Practices for Stacks Chainstate Snapshots
-
-{% hint style="info" %}
-**Intended audience**: Solo Stackers, Stacking pool operators, and node operators who need to create reliable chainstate backups.
-{% endhint %}
-
-Regular snapshots of your Stacks chainstate help you recover quickly when things go wrong. This guide shows you how to create and manage chainstate snapshots properly.
-
-{% hint style="warning" %}
-**Critical**: Always shut down your Stacks node properly before creating a snapshot. Creating snapshots while the node is running will result in corrupted chainstate data.
-{% endhint %}
-
-## Shutdown Procedure
-
-To produce a valid chainstate backup, the node should be stopped gracefully before making a copy. The following steps will correctly shutdown the Stacks node:
-
-1. **Check node status** before shutdown
- ```bash
- # Verify if the node is responsive
- curl http://localhost:20443/v2/info
- ```
-
-2. **Initiate graceful shutdown**
- - For Docker: `docker stop stacks-node` (allows at least 10 seconds for graceful shutdown)
- - For systemd: `systemctl stop stacks-node`
- - For manual processes: `kill $(ps aux | grep stacks-node | grep -v grep | awk '{print $2}')`
-
-3. **Verify complete shutdown**
- ```bash
- # Ensure no stacks-node processes are running
- ps aux | grep stacks-node
- ```
-
-## Overview of Snapshot Methods
-
-There are two primary approaches for creating Stacks chainstate snapshots:
-
-1. **File-based snapshots** - compress up the chainstate folder
-2. **Volume snapshots** - snapshot the entire disk/volume
-
-Each method has its advantages depending on your infrastructure setup and recovery requirements.
-
-## File-Based Snapshots
-
-This method involves compressing the chainstate directory and storing it locally, or uploading to a cloud storage service.
-
-### Steps (see [Example Automation Code section](#example-automation-code) below)
-
-1. **Stop the Stacks node gracefully**
-
-2. **Create compressed archive**
-
-3. **Upload to cloud storage or save it locally**
-
-4. **Restart the Stacks node**
-
-## Volume-Based Snapshots
-
-This method creates block-level snapshots of the entire storage volume containing the chainstate. Different filesystems have different tools:
-
-- **ZFS**: Use `zfs snapshot` - [OpenZFS documentation](https://openzfs.github.io/openzfs-docs/man/v2.3/8/zfs-snapshot.8.html)
-- **XFS**: Use `xfsdump` - [XFS documentation](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/storage_administration_guide/xfsbackuprestore)
-- **ext4**: Use LVM snapshots - [LVM guide](https://kerneltalks.com/disk-management/how-to-guide-lvm-snapshot/)
-
-You can also use cloud provider snapshot tools (AWS EBS, Azure Disk, GCP Persistent Disk).
-
-### Steps
-
-1. **Stop the Stacks node gracefully**
-
-2. **Create volume snapshot** using ZFS or cloud provider tools
-
-3. **Restart the Stacks node**
-
-## How to Restore
-
-*After restoring the chainstate, you can check for corruption by waiting for a few blocks to download and ensuring the node syncs correctly.*
-
-### From File Snapshots
-
-1. Stop the Stacks node
-2. Download and extract the snapshot
-3. Replace the chainstate directory
-4. Restart the node
-
-### From Volume Snapshots
-
-1. Stop the Stacks node
-2. Create a new volume from the snapshot
-3. Attach the volume to your instance
-4. Update mount points if necessary
-5. Restart the node
-
-## Example Automation Code
-
-Here's a simple script that handles both file and volume snapshots on AWS.
-
-```bash
-#!/bin/bash
-set -euo pipefail
-
-# Configuration variables - modify these for your setup
-SERVICE_NAME="stacks-node" # systemd service name
-SNAPSHOT_DIR="/var/stacks/mainnet" # path to chainstate directory
-SNAPSHOT_BASE="/tmp" # temporary directory for archives
-EBS_VOLUME_ID="vol-1234567890abcdef0" # EBS volume ID containing chainstate
-S3_BUCKET="s3://my-stacks-snapshots" # S3 bucket for archive storage
-SNAPSHOT_TYPE="archive" # Options: ebs, archive, or both
-
-# Stop the Stacks node service gracefully
-stop_service() {
- echo "Stopping $SERVICE_NAME..."
- sudo systemctl stop "$SERVICE_NAME"
-}
-
-# Start the Stacks node service
-start_service() {
- echo "Starting $SERVICE_NAME..."
- sudo systemctl start "$SERVICE_NAME"
-}
-
-# Create compressed archive and upload to S3
-snapshot_archive() {
- echo "Creating archive snapshot..."
-
- # Generate timestamp and version info for filename
- TIMESTAMP=$(date +"%Y%m%d")
- DIR_NAME=$(basename "$SNAPSHOT_DIR")
- VERSION=$(stacks-node version 2>&1 | tail -n 1 | awk '{print $2}')
- DEST="$SNAPSHOT_BASE/$DIR_NAME-$VERSION-$TIMESTAMP.tar.zst"
-
- # Create compressed archive (using zstd for better compression)
- tar -cf - -C "$(dirname $SNAPSHOT_DIR)" "$(basename $SNAPSHOT_DIR)" | pzstd -o "$DEST"
- echo "Archive created at: $DEST"
-
- # Upload to S3
- echo "Uploading to S3..."
- aws s3 cp "$DEST" "$S3_BUCKET/"
- echo "S3 upload complete: $S3_BUCKET/$(basename "$DEST")"
-
- # Clean up local archive
- rm "$DEST"
-}
-
-# Create EBS volume snapshot
-snapshot_ebs() {
- echo "Creating EBS snapshot of $EBS_VOLUME_ID..."
-
- # Generate description with timestamp
- TIMESTAMP=$(date +"%Y%m%d")
- DESC="Stacks Node Snapshot - $TIMESTAMP"
-
- # Create snapshot with tags
- SNAPSHOT_ID=$(aws ec2 create-snapshot \
- --volume-id "$EBS_VOLUME_ID" \
- --description "$DESC" \
- --tag-specifications "ResourceType=snapshot,Tags=[{Key=Name,Value=Stacks Snapshot},{Key=type,Value=chainstate}]" \
- --query 'SnapshotId' --output text)
-
- echo "EBS Snapshot ID: $SNAPSHOT_ID"
-}
-
-# Main execution function
-main() {
- case "$SNAPSHOT_TYPE" in
- ebs)
- stop_service
- snapshot_ebs
- start_service
- ;;
- archive)
- stop_service
- snapshot_archive
- start_service
- ;;
- both)
- stop_service
- snapshot_archive # Create archive first
- snapshot_ebs # Then EBS snapshot
- start_service
- ;;
- *)
- echo "Invalid snapshot type: $SNAPSHOT_TYPE. Available options: ebs, archive, or both."
- exit 1
- ;;
- esac
-
- echo "Snapshot process completed successfully!"
-}
-
-# Execute main function
-main
-```
-
-### How to Use
-
-1. **Edit the variables** at the top of the script for your setup
-
-2. **Make it executable**: `chmod +x snapshot.sh`
-
-3. **Run it**: `./snapshot.sh`
-
-4. **Schedule it with cron** for daily backups:
- ```bash
- # Daily snapshot at 2 AM
- 0 2 * * * /path/to/snapshot.sh
- ```
-
-### What You Need
-
-- AWS CLI set up with the right permissions
-- `pzstd` installed (comes with the zstd package)
diff --git a/guides-and-tutorials/bitcoin-integration/README.md b/guides-and-tutorials/bitcoin-integration/README.md
deleted file mode 100644
index 17ee26dcbf..0000000000
--- a/guides-and-tutorials/bitcoin-integration/README.md
+++ /dev/null
@@ -1,3 +0,0 @@
-# Bitcoin Integration
-
-One of the unique features of the Stack chain and the Clarity language is that it allows for directly reading from the Bitcoin chain itself. These tutorials walk you through some different ways you can accomplish that.
diff --git a/guides-and-tutorials/bitcoin-integration/parsing-a-bitcoin-transaction.md b/guides-and-tutorials/bitcoin-integration/parsing-a-bitcoin-transaction.md
deleted file mode 100644
index 77c012d957..0000000000
--- a/guides-and-tutorials/bitcoin-integration/parsing-a-bitcoin-transaction.md
+++ /dev/null
@@ -1,48 +0,0 @@
-# Parsing a Bitcoin Transaction
-
-While we can verify that a transaction was mined using a library and Clarity's built-in functions, as outlined in the Verifying a transaction on the BTC chain docs, we can parse a Bitcoin transaction using Clarity as well.
-
-This doesn't actually require having access to the chain, all we need is the raw transaction hex.
-
-If you aren't familiar with how Bitcoin transactions are encoded in raw form, take a quick look at that.
-
-The short version is that all of the data from a Bitcoin transaction is encoded in hex form in a string of numbers, we can slice out pieces of that hex value to pull out all of our transaction data.
-
-The process to do this is relatively complex, but the Clarity-Bitcoin library comes with a function called `parse-tx` that makes this simple.
-
-All we need to do is pass it a raw transaction hex and we can get back the data of the transaction, including inputs and outputs.
-
-:::caution Note that currently the library only supports legacy transactions, although work to support segwit and taproot transactions is currently underway. :::
-
-You can view a [deployed version of the library](https://explorer.hiro.so/txid/0xd493b9ada8899be8773d3f55b21d300ef83ac5c0dd38c8a4dd52a295bd71d539?chain=mainnet) on the explorer and the [GitHub repo here](https://github.com/friedger/clarity-bitcoin).
-
-The `parse-tx` function looks like this.
-
-```clarity
-(define-read-only (parse-tx (tx (buff 1024)))
- (let ((ctx { txbuff: tx, index: u0})
- (parsed-version (try! (read-uint32 ctx)))
- (parsed-txins (try! (read-txins (get ctx parsed-version))))
- (parsed-txouts (try! (read-txouts (get ctx parsed-txins))))
- (parsed-locktime (try! (read-uint32 (get ctx parsed-txouts)))))
- (ok {version: (get uint32 parsed-version),
- ins: (get txins parsed-txins),
- outs: (get txouts parsed-txouts),
- locktime: (get uint32 parsed-locktime)})))
-```
-
-We can get the raw transaction hex from a Bitcoin block explorer API like mempool, and it will be returned back to use looking something like this:
-
-`0200000000010196277c04c986c1ad78c909287fd12dba2924324699a0232e0533f46a6a3916bb0100000000ffffffff026400000000000000160014274ae586ad2035efb4c25049c155f98310d7e106ca16440000000000160014599bcef6387256c6b019030c421b4a4d382fe2600247304402204d94a1e4047ca38a450177ccb6f88585ca147f1939df343d8ac5d962c5f35bb302206f7fa42c21c47ebccdc460393d35c5dfd3b6f0a26cf10fac23d3e6fab71835c20121020cb972a66e3fb1cdcc9efcad060b4457ebec534942700d4af1c0d82a33aa13f100000000`.
-
-You can paste this into a raw transaction decoder like [this one](https://live.blockcypher.com/btc/decodetx/) and see the data.
-
-If we were using stacks.js, we would just need to pass this to our function as a buffer like this:
-
-```javascript
-bufferCV(Buffer.from(txRaw, "hex"));
-```
-
-Where `txRaw` is just a string containing our raw transaction. When we do that, we are presented with the data of the transaction.
-
-We can then take that data and pull out whatever we need from it.
diff --git a/guides-and-tutorials/bitcoin-integration/sending-bitcoin-with-leather-wallet.md b/guides-and-tutorials/bitcoin-integration/sending-bitcoin-with-leather-wallet.md
deleted file mode 100644
index e1d2181bb1..0000000000
--- a/guides-and-tutorials/bitcoin-integration/sending-bitcoin-with-leather-wallet.md
+++ /dev/null
@@ -1,35 +0,0 @@
-# Sending Bitcoin with Leather Wallet
-
-Using Leather's web wallet, we can easily initiate a simple Bitcoin transaction using only a few lines of code.
-
-You'll need to be authenticated with the Leather wallet for this to work, which you can see how to do in the Authentication with Stacks.js tutorial.
-
-Once you have the wallet hooked up, you can use the Leather wallet API to initiate a simple Bitcoin transaction in your JS app like this.
-
-```javascript
-const sendBitcoin = async () => {
- const resp = await window.btc?.request("sendTransfer", {
- address: "tb1qya9wtp4dyq67ldxz2pyuz40esvgd0cgx9s3pjl", //replace this with whatever address you want to send to
- amount: "10000", // the amount you want to send denoted in satoshis
- });
-
- // Storing txid in local storage
- // We'll get back the transaction IF, which we can then use to do whatever we want
- if (typeof window !== "undefined") {
- localStorage.setItem("txid", JSON.stringify(resp.result.txid));
- }
-
- // We may want to do something once this transaction has confirmed, so we can set it to pending here and then use an API like mempool.space to query the Bitcoin chain for information about this transaction
- localStorage.setItem("txStatus", "pending");
-};
-```
-
-Then all we would do is hook up our button to call this `sendBitcoin` function.
-
-```javascript
-
-```
-
-You can take a look at the Verifying a transaction on the BTC chain recipe to see a more complex user flow of verifying a transaction was mined using this returned ID as a starting point.
-
-You can take a look at a bit more info about this simple API on the[ wallet developer docs](https://hirowallet.gitbook.io/developers/bitcoin/sign-transactions/sending-bitcoin).
diff --git a/guides-and-tutorials/bitcoin-integration/verifying-a-bitcoin-transaction.md b/guides-and-tutorials/bitcoin-integration/verifying-a-bitcoin-transaction.md
deleted file mode 100644
index ae2ccef9f0..0000000000
--- a/guides-and-tutorials/bitcoin-integration/verifying-a-bitcoin-transaction.md
+++ /dev/null
@@ -1,190 +0,0 @@
-# Verifying a Bitcoin Transaction
-
-One of the coolest things about Clarity is that it allows us to have visibility into the state of the Bitcoin blockchain. Since Stacks blocks are mined in lockstep with Bitcoin blocks, we can directly read the burnchain header info of each Bitcoin block using Clarity's built-in [`get-burn-block-info?`](https://docs.stacks.co/docs/clarity/language-functions#get-burn-block-info-clarity2) function.
-
-There are quite a few relatively complex things that need to happen to do this successfully, but a [clarity-bitcoin library](https://github.com/friedger/clarity-bitcoin/) exists to make the process a lot easier and handle some of the heavy lifting for us.
-
-Let's take a look at how to verify a Bitcoin transaction was mined using Clarity using the library. If you take a look at the `clarity-bitcoin.clar` file in the linked repo, you'll find a function called `was-tx-mined-compact`. That's what we'll be working with, and it looks like this:
-
-```clarity
-(define-read-only (was-tx-mined-compact (height uint) (tx (buff 1024)) (header (buff 80)) (proof { tx-index: uint, hashes: (list 14 (buff 32)), tree-depth: uint}))
- (let ((block (unwrap! (parse-block-header header) (err ERR-BAD-HEADER))))
- (was-tx-mined-internal height tx header (get merkle-root block) proof)))
-```
-
-The transaction itself is relatively simple, but there's a lot happening within other private function calls. I encourage you to read the contract for yourself and trace what is happening, step-by-step, when we call this function.
-
-For now, we'll just go over how to actually call this function successfully.
-
-You can see that it takes a few pieces of information:
-
-* `(height uint)` the block height you are looking to verify the transaction within
-* `(tx (buff 1024))` the raw transaction hex of the transaction you are looking to verify
-* `(header (buff 80))` the block header of the block
-* `(proof { tx-index: uint, hashes: (list 14 (buff 32)), tree-depth: uint})` a merkle proof formatted as a tuple
-
-:::info
-
-A Merkle proof is a compact way to prove that a transaction is included in a block in the Bitcoin blockchain. Here's how it works:
-
-1. Transactions in a block are hashed and paired, then the hashes of the pairs are hashed and paired, and so on until a single hash remains - this is called the Merkle root.
-2. The Merkle root is included in the block header. By providing the hashes that lead from a transaction's hash up to the Merkle root, along with the block header, one can prove that the transaction is included in that block.
-3. These hashes that connect a transaction to the Merkle root are called the Merkle proof or Merkle path. By providing the Merkle proof along with the transaction hash and block header, anyone can verify that the transaction is part of that block.
-4. This allows for efficient decentralized verification of transactions without having to download the entire blockchain. One only needs the transaction hash, Merkle proof, and block header to verify.
-
-:::
-
-Once we have this information, we can call into the `clarity-bitcoin.clar` contract and pass in this data. A common practice would be to get this data from a Bitcoin block explorer API like Mempool.space or Blockstream's esplora, parse it into the correct format for this helper, and then pass it to this function.
-
-We could do that directly via this contract if we just need a direct response on if the transaction was included or not, but more likely we would want to integrate this functionality into a Clarity contract of our own where we can `asserts!` that a transaction was mined before taking another action.
-
-Here's a basic example where we are calling [Blockstream's API](https://github.com/Blockstream/esplora/blob/master/API.md) using JavaScript, parsing the data into the right format, and then calling into our own `mint` function to only mint an NFT if the selected transaction was mined.
-
-We can get all the information we need with nothing but the transaction ID, which will usually be passed to us when we use a wallet like [Hiro's web wallet](https://hirowallet.gitbook.io/developers/bitcoin/sign-transactions/sending-bitcoin) to initiate the Bitcoin transaction.
-
-Let's go through the code we can use to implement this. For full context, this code is taken from the example [bitbadge](https://github.com/kenrogers/bitbadge) repo, which you can take a look at. For a complete step-by-step walkthrough of how to implement this, check out the [Bitcoin Primer](https://bitcoinprimer.dev).
-
-Here's the mint function:
-
-```clarity
-(define-public (mint (recipient principal) (height uint) (tx (buff 1024)) (header (buff 80)) (proof { tx-index: uint, hashes: (list 14 (buff 32)), tree-depth: uint}))
- (let
- (
- (token-id (+ (var-get last-token-id) u1))
- (tx-was-mined (try! (contract-call? .clarity-bitcoin was-tx-mined-compact height tx header proof)))
- )
- (asserts! (is-eq tx-sender contract-owner) err-owner-only)
- (asserts! (is-eq tx-was-mined true) err-tx-not-mined)
- (try! (nft-mint? bitbadge token-id recipient))
- (var-set last-token-id token-id)
- (ok token-id)
- )
-)
-```
-
-Note the `(asserts! (is-eq tx-was-mined true) err-tx-not-mined)` line. This is what is doing the heavy lifting.
-
-:::caution Right now the clarity-bitcoin library only supports legacy transactions. Work is in-progress to add support for segwit, but until then we have to do a bit of work on the front end to strip the witness data from the raw transaction hex. :::
-
-Here's the JavaScript code we can use to get the data we need.
-
-First we get the raw transaction and the merkle proof (we do this when we first get the transaction ID back).
-
-The `useEffect` here is so that we can check to see if the transaction was confirmed every 10 seconds before we get the rest of the information.
-
-```javascript
-// Effect hook to check and see if the tx has been confirmed using blockstream API
-useEffect(() => {
- const intervalId = setInterval(() => {
- const txid = JSON.parse(localStorage.getItem("txid"));
- if (txid) {
- fetch(`https://blockstream.info/testnet/api/tx/${txid}/status`)
- .then((response) => response.json())
- .then(async (status) => {
- // set txStatus in localStorage if it is confirmed, otherwise we want to leave it pending
- if (status.confirmed) {
- localStorage.setItem("txStatus", "confirmed");
- // set the block details
- const blockDetails = {
- block_height: status.block_height,
- block_hash: status.block_hash,
- };
- setBlockDetails(blockDetails);
- localStorage.setItem("blockDetails", JSON.stringify(blockDetails));
- // fetch and set the tx raw
- const rawResponse = await fetch(
- `https://blockstream.info/testnet/api/tx/${txid}/hex`
- );
- const txRaw = await rawResponse.text();
- localStorage.setItem("txRaw", txRaw);
- // fetch and set the merkle proof
- const proofResponse = await fetch(
- `https://blockstream.info/testnet/api/tx/${txid}/merkle-proof`
- );
- const txMerkleProof = await proofResponse.json();
- localStorage.setItem(
- "txMerkleProof",
- JSON.stringify(txMerkleProof)
- );
- clearInterval(intervalId);
- }
- })
- .catch((err) => console.error(err));
- }
- }, 10000);
- return () => clearInterval(intervalId); // Clean up on component unmount
-}, []);
-```
-
-Then we get and parse the rest of the data when we call the actual mint function.
-
-```javascript
-// This function retrieves raw transaction and merkle proof from localStorage and calls the mint Clarity function
-const mintBitbadge = async () => {
- // Retrieving rawTx and merkleProof from local storage
- let txRaw = "";
- let txMerkleProof = "";
-
- if (typeof window !== "undefined") {
- txRaw = removeWitnessData(localStorage.getItem("txRaw"));
- txMerkleProof = JSON.parse(localStorage.getItem("txMerkleProof"));
- }
-
- // First we need to verify that the sender of this transaction is the same as the user that is signed in
- if (!verifyCorrectSender()) {
- console.log("wrong sender");
- return false;
- }
-
- const blockHeight = blockDetails.block_height;
-
- // Fetch the block hash
- const blockHashResponse = await fetch(
- `https://blockstream.info/testnet/api/block-height/${blockHeight}`
- );
- const blockHash = await blockHashResponse.text();
-
- // Fetch the block header
- const blockHeaderResponse = await fetch(
- `https://blockstream.info/testnet/api/block/${blockHash}/header`
- );
- const blockHeaderHex = await blockHeaderResponse.text();
-
- const txIndex = txMerkleProof.pos;
- const hashes = txMerkleProof.merkle.map(
- (hash) => bufferCV(hexToBytes(hash).reverse()) // lib needs reversed hashes
- ); // Convert each hash to BufferCV and reverse it
-
- const functionArgs = [
- principalCV(userData.profile.stxAddress.testnet),
- uintCV(blockHeight),
- bufferCV(Buffer.from(txRaw, "hex")),
- bufferCV(Buffer.from(blockHeaderHex, "hex")),
- tupleCV({
- "tx-index": uintCV(txIndex),
- hashes: listCV(hashes),
- "tree-depth": uintCV(txMerkleProof.merkle.length),
- }),
- ];
-
- const contractAddress = "ST3QFME3CANQFQNR86TYVKQYCFT7QX4PRXM1V9W6H"; // Replace with your contract address
- const contractName = "bitbadge-v3"; // Replace with your contract name
- const functionName = "mint"; // Replace with your function name
-
- const options = {
- contractAddress,
- contractName,
- functionName,
- functionArgs,
- appDetails: {
- name: "BitBadge",
- icon: "https://freesvg.org/img/bitcoin.png",
- },
- onFinish: (data) => {
- console.log(data);
- },
- };
-
- await openContractCall(options);
-};
-```
diff --git a/guides-and-tutorials/build-a-borrowing-and-lending-protocol.md b/guides-and-tutorials/build-a-borrowing-and-lending-protocol.md
deleted file mode 100644
index 1aa8dd4ded..0000000000
--- a/guides-and-tutorials/build-a-borrowing-and-lending-protocol.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# Build a Borrowing & Lending Protocol
-
-In this in-depth tutorial, you'll get a holistic overview of the entire Stacks development process by building a very simple borrowing and lending protocol called Lagoon.
-
-We'll utilize the Hiro Platform to quickly get our contract set up and written. In an upcoming version of this tutorial, we'll also be creating the frontend and tests for our contract.
-
-A written version is also in the works.
-
-We'll also dig into sBTC a bit, the upcoming decentralized BTC peg, and how you can begin experimenting with it now.
-
-{% embed url="https://www.youtube.com/watch?v=-JFZ60UGODY" %}
diff --git a/guides-and-tutorials/clarity-crash-course.md b/guides-and-tutorials/clarity-crash-course.md
deleted file mode 100644
index ce294dd50c..0000000000
--- a/guides-and-tutorials/clarity-crash-course.md
+++ /dev/null
@@ -1,104 +0,0 @@
-# Clarity Crash Course
-
-This crash course is designed for people who have some experience with programming but are new to Clarity. You don't need smart contract development experience, but if you do, with something like Solidity, you'll pick this up really quick.
-
-Once you've familiarized yourself with the language, if you'd like to continue your journey and master Clarity to become a smart contract developer, we recommend either the book, [Clarity of Mind](https://book.clarity-lang.org/title-page.html), or the course, [Clarity Universe](https://clarity-lang.org/universe), which has both a self-paced and guided cohort-based version.
-
-### Your First Clarity Smart Contract
-
-We're going to build a basic Clarity smart contract using [Clarity Tools](https://clarity.tools/code/new), so you won't have to install anything for this introduction.
-
-Visit that link, and it will open up a new contract for you.
-
-Already we can take a look at a few basic features of both Clarity and Clarity Tools. First, on the left you'll see that our Clarity code is being evaluated in real-time for us. This is really nice for experimenting and demonstrating basic Clarity code.
-
-Next up we can see our first bit of Clarity code.
-
-Those two semicolons are how we denote comments in Clarity.
-
-Then the next line down we have a public function declaration.
-
-Here is our first glimpse of Clarity's syntax, which may be new to you depending on your development background.
-
-For those new to Clarity, it's a little weird and uncomfortable at first, but one of the core design tenets of Clarity is simplicity and readability, and the more you work with it the more you come to appreciate the succinctness and _clarity_ (sorry) of the code you are writing.
-
-Clarity takes inspiration from LISP, and you can think of everything in Clarity as a list inside of a list, or an expression inside of an expression. Everything in Clarity is wrapped in parentheses, function definitions, variable declarations, function parameters, etc.
-
-So here we are saying that we want to:
-
-1. Call a function called `define-read-only`. This is a built-in function, one of many that you can refer to in the docs.
-2. Pass it a parameter of hello, which corresponds to the method signature type.
-3. Pass it a parameter of "Hello", which corresponds to the function body.
-
-You can refer to the [`define-read-only`](https://docs.stacks.co/docs/write-smart-contracts/clarity-language/language-functions#define-read-only) documentation to see these parameters.
-
-Why am I describing this as if we are calling a function? Because we are, and it's an important concept in Clarity that everything is an expression inside of an expression.
-
-Let's expand on this concept a bit by deleting this and writing a new function.
-
-```clarity
-(define-data-var count int 0)
-(define-public (add-number (number int))
- (let
- (
- (current-count count)
- )
-
- (var-set count (+ 1 number))
- (ok (var-get count))
- )
-)
-
-
-(add-number 5)
-```
-
-If you type that into Clarity Tools, you'll see the result that gets printed is 6.
-
-Okay there are actually a lot of Clarity concepts packed into this simple code.
-
-Let's go over what this code is doing, and you'll pick up some Clarity concepts along the way.
-
-The first thing we are doing here is defining a new variable called `count` and setting its initial value to 0.
-
-This will be a persistent state variable, so this is actually getting written to the blockchain. If you are new to smart contract development, the fact that data is persisted within the file like this might take some getting used to.
-
-So if we were to write and deploy this contract (which you can do in the Stacks Explorer if you like), as soon as it gets deployed, it will run through the contract line by line executing anything at the root level.
-
-Remember that Clarity is interpreted, no compiled, so there's not compile step when developing Clarity contracts.
-
-So this `define-data-var` will be evaluated and the `count` variable will be initialized with a value of 0.
-
-Next we are defining a public function called `add-number`, which will be created (but not called) on deploy as well.
-
-:::note In Clarity, we have public, private, and read only functions. Public allow you to modify chain state and can be called from anywhere, private do the same except they can only be called from within the contract, and read only will fail if they attempt to modify state. :::
-
-This function is taking a single parameter, called `number` that is a type of `int`.
-
-Now, what is this `let` business all about? Remember that we said that everything in Clarity is an expression and declaring new functions is just a matter of calling the `define-public` function?
-
-Well the second argument to this is the function body, but it can only evaluate a single expression.
-
-So this `let` function is a way of wrapping a multi-step function into a single argument.
-
-But it does one other crucial thing at the beginning. This line:
-
-```clarity
-(current-count count)
-```
-
-Sets a variable that only exists in the context of this particular function. So here we are saying, create a new variable called `current-count` and set it equal to the value of `count`.
-
-Then we use that in our actual function body down below.
-
-In the next step we are setting the value of our `count` variable to 1 plus whatever number we passed in. The `+` is just another call to a function where the parameters are the numbers we want to add.
-
-Then, finally, we are returning the new value of `count` with our `ok` response, indicating that the function completed successfully.
-
-Then in the very last line we are actually calling this function, passing in 5.
-
-This was a very brief overview of Clarity just to get your feet wet and give you a taste of how it works.
-
-If you are interested in diving into the details, we highly recommend going through either the [Clarity Book](https://book.clarity-lang.org/title-page.html) or [Clarity Universe](https://clarity-lang.org/universe), depending on your learning style.
-
-If you prefer to dive directly into the docs, there are several guides and example contracts for you to learn from.
diff --git a/guides-and-tutorials/community-tutorials.md b/guides-and-tutorials/community-tutorials.md
deleted file mode 100644
index 639add400b..0000000000
--- a/guides-and-tutorials/community-tutorials.md
+++ /dev/null
@@ -1,25 +0,0 @@
-# Community Tutorials
-
-These tutorials have been created by various members of the Stacks community. Have a tutorial to suggest? View the [contribution guide](http://localhost:3000/docs/contribute/docs) to submit a PR with a new tutorial added.
-
-### Written Tutorials
-
-* [Create a server-side rendered Stacks app with Remix](https://micro-stacks.dev/guides/with-remix)
-* [Build a Stacks app with Next.js](https://micro-stacks.dev/guides/with-nextjs)
-* [Creating a Voting Contract](https://www.clearness.dev/01-voting-clarity-smart-contract/01-getting-started)
-* [Building an NFT with Stacks and Clarity](https://blog.developerdao.com/building-an-nft-with-stacks-and-clarity)
-* [Minting NFTs with QuickNode](https://www.quicknode.com/guides/web3-sdks/how-to-mint-nfts-on-the-stacks-blockchain)
-* [Order Book Contract Walkthrough](https://byzantion.hiro.so/)
-* [Build a DEX on Stacks](https://www.pointer.gg/tutorials/build-a-dex-with-stacks/56abb3a4-05c1-4608-b096-f82189e9f759)
-* [NFT Tutorial](https://docs.hiro.so/tutorials/clarity-nft)
-* [Billboard Tutorial](https://docs.hiro.so/tutorials/clarity-billboard)
-* [Integrating NFTs Into a Game](https://gamefi-stacks.gitbook.io/gamefistacks/tutorials/integrate-nfts-into-game)
-* [Building on Stacks](https://github.com/amoweolubusayo/stacks-clarinet-tutorial)
-
-### Video Tutorials
-
-* [Web3 for Bitcoin](https://www.crowdcast.io/e/web3-for-bitcoin/)
-
-### Other Resources
-
-There are also a great amount of both tutorials and developer tools in the [Awesome Stacks repo](https://github.com/friedger/awesome-stacks-chain#clarity-resources).
diff --git a/guides-and-tutorials/frontend/README.md b/guides-and-tutorials/frontend/README.md
deleted file mode 100644
index c373042f02..0000000000
--- a/guides-and-tutorials/frontend/README.md
+++ /dev/null
@@ -1,5 +0,0 @@
-# Build a Frontend
-
-A major part of building full-stack Stacks applications will involve building out a UI with a solid user experience. One of your primary tools in accomplishing this will be Stacks.js, a JavaScript library built by Hiro to make working with contracts and the chain itself easier.
-
-Hiro has excellent documentation in place to help you utilize Stacks.js to build out a great frontend to your Clarity contracts.
diff --git a/guides-and-tutorials/frontend/authentication-with-stacks.js.md b/guides-and-tutorials/frontend/authentication-with-stacks.js.md
deleted file mode 100644
index 926ed55ced..0000000000
--- a/guides-and-tutorials/frontend/authentication-with-stacks.js.md
+++ /dev/null
@@ -1,95 +0,0 @@
-# Authentication with Stacks.js
-
-Authenticating with a Stacks wallet is a very common task when building Stacks dapps.
-
-Let's see how to set this up on the front end.
-
-Code here is pulled from the Hello Stacks tutorial.
-
-### Stacks.js Code
-
-We're using React here, but you can modify this for whatever frontend code you are using.
-
-Before you add the frontend code, you need to install the correct NPM package.
-
-```bash
-yarn add @stacks/connect
-```
-
-And here's the JS code we'll need to implement.
-
-```js
-import {
- AppConfig,
- UserSession,
- AuthDetails,
- showConnect,
-} from "@stacks/connect";
-import { useState, useEffect } from "react";
-
-function App() {
- const [message, setMessage] = useState("");
- const [transactionId, setTransactionId] = useState("");
- const [currentMessage, setCurrentMessage] = useState("");
- const [userData, setUserData] = useState(undefined);
-
- const appConfig = new AppConfig(["store_write"]);
- const userSession = new UserSession({ appConfig });
-
- const appDetails = {
- name: "Hello Stacks",
- icon: "https://freesvg.org/img/1541103084.png",
- };
-
- const connectWallet = () => {
- showConnect({
- appDetails,
- onFinish: () => window.location.reload(),
- userSession,
- });
- };
-
- useEffect(() => {
- if (userSession.isSignInPending()) {
- userSession.handlePendingSignIn().then((userData) => {
- setUserData(userData);
- });
- } else if (userSession.isUserSignedIn()) {
- setUserData(userSession.loadUserData());
- }
- }, []);
-
- return (
-
-
-
Hello Stacks
-
- );
-}
-
-export default App;
-```
-
-This is all the code we need to authenticate and access the user data in the UI.
-
-But how do we actually use it?
-
-Let's implement a `connectWallet` button to see how we can utilize the data we're pulling here.
-
-```js
-{
- !userData && (
-
- );
-}
-```
diff --git a/guides-and-tutorials/frontend/post-conditions-with-stacks.js.md b/guides-and-tutorials/frontend/post-conditions-with-stacks.js.md
deleted file mode 100644
index 04eee406d4..0000000000
--- a/guides-and-tutorials/frontend/post-conditions-with-stacks.js.md
+++ /dev/null
@@ -1,133 +0,0 @@
-# Post Conditions with Stacks.js
-
-The content in this recipe has been pulled from the [tutorial on post conditions](https://dev.to/stacks/understanding-stacks-post-conditions-e65). Post conditions are an additional safety feature built into the Stacks chain itself that help to protect end users.
-
-Rather than being a function of Clarity smart contracts, they are implemented on the client side and meant to be an additional failsafe against malicious contracts.
-
-Put simply, post conditions are a set of conditions that must be met before a user's transaction will execute. The primary goal behind post conditions is to limit the amount of damage that can be done to a user's assets due to a bug, intentional or otherwise.
-
-So they are sent as part of the transaction when the user initiates it, meaning we need a frontend library to utilize them.
-
-Whenever you are transferring an asset (fungible or non-fungible) from one address to another, you should take advantage of post conditions.
-
-We're going to use [Stacks.js](https://github.com/hirosystems/stacks.js/tree/master/packages/transactions#post-conditions) to familiarize ourselves with them.
-
-### STX Post Condition
-
-```js
-import {
- FungibleConditionCode,
- makeStandardSTXPostCondition,
- makeContractSTXPostCondition,
-} from "@stacks/transactions";
-
-// With a standard principal
-const postConditionAddress = "SP2ZD731ANQZT6J4K3F5N8A40ZXWXC1XFXHVVQFKE";
-const postConditionCode = FungibleConditionCode.GreaterEqual;
-const postConditionAmount = 12345n;
-
-const standardSTXPostCondition = makeStandardSTXPostCondition(
- postConditionAddress,
- postConditionCode,
- postConditionAmount
-);
-
-// With a contract principal
-const contractAddress = "SPBMRFRPPGCDE3F384WCJPK8PQJGZ8K9QKK7F59X";
-const contractName = "test-contract";
-
-const contractSTXPostCondition = makeContractSTXPostCondition(
- contractAddress,
- contractName,
- postConditionCode,
- postConditionAmount
-);
-```
-
-### Fungible Token Post Condition
-
-```js
-import {
- FungibleConditionCode,
- createAssetInfo,
- makeStandardFungiblePostCondition,
-} from "@stacks/transactions";
-
-// With a standard principal
-const postConditionAddress = "SP2ZD731ANQZT6J4K3F5N8A40ZXWXC1XFXHVVQFKE";
-const postConditionCode = FungibleConditionCode.GreaterEqual;
-const postConditionAmount = 12345n;
-const assetAddress = "SP62M8MEFH32WGSB7XSF9WJZD7TQB48VQB5ANWSJ";
-const assetContractName = "test-asset-contract";
-const fungibleAssetInfo = createAssetInfo(assetAddress, assetContractName);
-
-const standardFungiblePostCondition = makeStandardFungiblePostCondition(
- postConditionAddress,
- postConditionCode,
- postConditionAmount,
- fungibleAssetInfo
-);
-
-// With a contract principal
-const contractAddress = "SPBMRFRPPGCDE3F384WCJPK8PQJGZ8K9QKK7F59X";
-const contractName = "test-contract";
-const assetAddress = "SP62M8MEFH32WGSB7XSF9WJZD7TQB48VQB5ANWSJ";
-const assetContractName = "test-asset-contract";
-const fungibleAssetInfo = createAssetInfo(assetAddress, assetContractName);
-
-const contractFungiblePostCondition = makeContractFungiblePostCondition(
- contractAddress,
- contractName,
- postConditionCode,
- postConditionAmount,
- fungibleAssetInfo
-);
-```
-
-### NFT Post Condition
-
-```js
-import {
- NonFungibleConditionCode,
- createAssetInfo,
- makeStandardNonFungiblePostCondition,
- makeContractNonFungiblePostCondition,
- bufferCVFromString,
-} from "@stacks/transactions";
-
-// With a standard principal
-const postConditionAddress = "SP2ZD731ANQZT6J4K3F5N8A40ZXWXC1XFXHVVQFKE";
-const postConditionCode = NonFungibleConditionCode.Owns;
-const assetAddress = "SP62M8MEFH32WGSB7XSF9WJZD7TQB48VQB5ANWSJ";
-const assetContractName = "test-asset-contract";
-const assetName = "test-asset";
-const tokenAssetName = bufferCVFromString("test-token-asset");
-const nonFungibleAssetInfo = createAssetInfo(
- assetAddress,
- assetContractName,
- assetName
-);
-
-const standardNonFungiblePostCondition = makeStandardNonFungiblePostCondition(
- postConditionAddress,
- postConditionCode,
- nonFungibleAssetInfo,
- tokenAssetName
-);
-
-// With a contract principal
-const contractAddress = "SPBMRFRPPGCDE3F384WCJPK8PQJGZ8K9QKK7F59X";
-const contractName = "test-contract";
-
-const contractNonFungiblePostCondition = makeContractNonFungiblePostCondition(
- contractAddress,
- contractName,
- postConditionCode,
- nonFungibleAssetInfo,
- tokenAssetName
-);
-```
-
-### Sample App
-
-Here's a [sample application](https://github.com/kenrogers/fabulous-frogs) that utilizes post conditions on the front end to secure user assets.
diff --git a/guides-and-tutorials/frontend/sending-transactions-with-stacks.js.md b/guides-and-tutorials/frontend/sending-transactions-with-stacks.js.md
deleted file mode 100644
index b4bfb0f9a2..0000000000
--- a/guides-and-tutorials/frontend/sending-transactions-with-stacks.js.md
+++ /dev/null
@@ -1,52 +0,0 @@
-# Sending Transactions with Stacks.js
-
-Any Stacks dapp is going to require sending transaction at some point, so how do we do that? We use the `@stacks/transactions` package.
-
-Again, this particular snippet is pulled from our Hello Stacks tutorial.
-
-When you send Stacks transactions, don't forget to utilize post conditions.
-
-But first, you'll need to install the right NPM package.
-
-```bash
-yarn add @stacks/transactions
-```
-
-### Stacks.js Frontend Code
-
-Assuming you are authenticated, you'll need to import from the `network` package to connect and import the right Clarity values to convert.
-
-You need to convert values from JS into the right format for Clarity values to ingest. You can view the complete list of types on the [Stacks.js docs](https://stacks.js.org/modules/\_stacks\_transactions#constructing-clarity-values).
-
-```js
-import { StacksMocknet } from "@stacks/network";
-import { stringUtf8CV } from "@stacks/transactions";
-```
-
-Let's assume we have a message that we need to send.
-
-```
-Hello this is something I need to say.
-```
-
-```js
-const submitMessage = async (e) => {
- e.preventDefault();
-
- const network = new StacksMocknet();
-
- const options = {
- contractAddress: "ST1PQHQKV0RJXZFY1DGX8MNSNYVE3VGZJSRTPGZGM",
- contractName: "hello-stacks",
- functionName: "write-message",
- functionArgs: [stringUtf8CV(message)],
- network,
- appDetails,
- onFinish: ({ txId }) => console.log(txId),
- };
-
- await openContractCall(options);
-};
-```
-
-For more details on the different types of transactions you can send, the [Stacks.js docs](https://stacks.js.org/modules/\_stacks\_transactions) have multiple examples.
diff --git a/guides-and-tutorials/hello-stacks-quickstart-tutorial.md b/guides-and-tutorials/hello-stacks-quickstart-tutorial.md
deleted file mode 100644
index 7600b1d6ad..0000000000
--- a/guides-and-tutorials/hello-stacks-quickstart-tutorial.md
+++ /dev/null
@@ -1,704 +0,0 @@
-# Developer Quickstart
-
-## Build Your First Stacks App in 30 Minutes
-
-Looking to see what building on Stacks is all about? You're in the right place.
-
-This tutorial will help you build a working Stacks application in just 30 minutes. You'll learn the essential tools and concepts needed to build decentralized applications on Stacks, the leading Bitcoin L2.
-
-**What you'll build:** A simple message board where users can post messages to the blockchain and read messages from others.
-
-**What you'll learn:**
-
-* How to write a Clarity smart contract
-* How to deploy contracts to Stacks testnet
-* How to connect a wallet to your app
-* How to interact with contracts from a frontend
-
-**Prerequisites:**
-
-* Basic familiarity with web development (HTML, CSS, JavaScript)
-* A modern web browser
-* 30 minutes of your time
-
-Let's get started!
-
-## Step 1: Set Up Your Wallet (5 minutes)
-
-First, you'll need a Stacks wallet to interact with the blockchain.
-
-### Install Leather Wallet
-
-1. Visit [leather.io](https://leather.io) and install the browser extension
-2. Create a new wallet or import an existing one
-3. **Important**: Switch to the **Testnet** network in your wallet settings
-4. Get testnet STX tokens from the [Stacks Testnet Faucet](https://explorer.hiro.so/sandbox/faucet?chain=testnet)
-
-{% hint style="info" %}
-Testnet STX tokens are free and used for testing. They have no real value but let you experiment with Stacks development without cost.
-{% endhint %}
-
-Your wallet is now ready for testnet development!
-
-{% hint style="info" %}
-You don't have to use Leather, two other wallets popular with Stacks users are [Xverse](https://xverse.app) and [Asigna](https://asigna.io) if you need a multisig.
-{% endhint %}
-
-## Step 2: Write Your First Clarity Contract (10 minutes)
-
-Clarity is Stacks' smart contract language, designed for safety and predictability. Let's write a simple message board contract.
-
-Clarity is inspired by LISP and uses a functional programming approach. Everything in Clarity is an expression wrapped in parentheses. This can be a bit overwhelming at first if you are used to languages like JavaScript or Solidity, but the learning curve is short and Clarity is a simple language to understand once you dive in and start using it.
-
-For a more detailed introduction, check out the [Clarity Crash Course](clarity-crash-course.md) in the docs.
-
-### Write the Contract
-
-Open [Clarity Playground](https://play.hiro.so/) in your browser. This is an online IDE where you can write and test Clarity code without installing anything.
-
-Delete the existing code and replace it with this message board contract:
-
-```clarity
-;; Simple Message Board Contract
-;; This contract allows users to post and read messages
-
-;; Define a map to store messages
-;; Key: message ID (uint), Value: message content (string-utf8 280)
-(define-map messages uint (string-utf8 280))
-
-;; Define a map to store message authors
-(define-map message-authors uint principal)
-
-;; Counter for message IDs
-(define-data-var message-count uint u0)
-
-;; Public function to add a new message
-(define-public (add-message (content (string-utf8 280)))
- (let ((id (+ (var-get message-count) u1)))
- (map-set messages id content)
- (map-set message-authors id tx-sender)
- (var-set message-count id)
- (ok id)))
-
-;; Read-only function to get a message by ID
-(define-read-only (get-message (id uint))
- (map-get? messages id))
-
-;; Read-only function to get message author
-(define-read-only (get-message-author (id uint))
- (map-get? message-authors id))
-
-;; Read-only function to get total message count
-(define-read-only (get-message-count)
- (var-get message-count))
-
-;; Read-only function to get the last few messages
-(define-read-only (get-recent-messages (count uint))
- (let ((total-count (var-get message-count)))
- (if (> count total-count)
- (map get-message (list u1 u2 u3 u4 u5))
- (map get-message (list
- (- total-count (- count u1))
- (- total-count (- count u2))
- (- total-count (- count u3))
- (- total-count (- count u4))
- (- total-count (- count u5)))))))
-```
-
-### Test the Contract
-
-Click "Deploy", and go to the command line in the bottom right corner and try calling the functions.
-
-We are using the [contract-call?](../reference/functions.md#contract-call) method to call the functions in the contract that we just deployed within the playground.
-
-```clarity
-;; Test adding a message
-(contract-call? .contract-1 add-message u"Hello, Stacks!")
-
-;; Test reading the message
-(contract-call? .contract-1 get-message u1)
-
-;; Test getting the count
-(contract-call? .contract-1 get-message-count)
-```
-
-You should see the contract working in the evaluation panel on the right!
-
-### Key Clarity Concepts Explained
-
-Now that you've seen the contract in action, let's talk about the core Clarity concepts you just used. When you write `define-map`, you're creating a data structure for storing key-value pairs on the blockchain. Think of it like creating a table in a database. The `define-data-var` function creates a variable that persists on the blockchain, perfect for keeping track of counters or settings that need to survive between function calls.
-
-When you declare a function with `define-public`, you're creating a function that can modify blockchain state and be called by anyone externally. This is different from `define-read-only`, which creates functions that can only read existing data without changing anything. This separation helps prevent accidental state changes and makes your contract's behavior more predictable.
-
-The `tx-sender` variable is particularly useful because it's automatically set by the blockchain to contain the address of whoever called your function. You can't fake this value, which makes it perfect for authentication. When you need to create temporary variables within a function, you'll use `let` to set up local variables that only exist during that function call.
-
-Finally, every public function in Clarity must return a response type, which is why you see `ok` wrapping our return values. This ensures that every function call has a clear success or failure outcome, making your contracts much more predictable and easier to debug.
-
-
-
-🔍 Deep Dive: Understanding the Contract Code (Optional)
-
-Want to understand exactly what each part of the contract is doing? Let's walk through every function and concept used in our message board contract. Links to the official documentation are included for each function, so you may dive deeper if you want.
-
-#### How We Store Data on the Blockchain
-
-Let's start with how we're storing our messages. We use [`define-map`](../reference/functions.md#define-map) to create what's essentially a database table on the blockchain:
-
-```clarity
-(define-map messages uint (string-utf8 280))
-```
-
-Think of this as creating a table where each message gets a unique number (the `uint` key) and the message content can be up to 280 characters (the `string-utf8 280` value). It's like having a simple database where message #1 might be "Hello World!", message #2 might be "Learning Clarity!", and so on.
-
-We also create another map to track who wrote each message:
-
-```clarity
-(define-map message-authors uint principal)
-```
-
-This links each message ID to a `principal` (that's Clarity's term for a blockchain address). So if you post message #1, we'll store your address alongside that message ID.
-
-Finally, we need a way to keep track of how many messages we've posted so far:
-
-```clarity
-(define-data-var message-count uint u0)
-```
-
-The [`define-data-var`](../reference/functions.md#define-data-var) creates a single variable that persists on the blockchain. We start it at `u0` (that's how you write the number 0 for unsigned integers in Clarity). The `u` prefix might look weird if you're coming from other languages, but it's just Clarity's way of saying "this is a positive integer."
-
-#### The Heart of Our Contract: Adding Messages
-
-Now let's break down the most important function, the one that actually adds messages to our board:
-
-```clarity
-(define-public (add-message (content (string-utf8 280)))
- (let ((id (+ (var-get message-count) u1)))
- (map-set messages id content)
- (map-set message-authors id tx-sender)
- (var-set message-count id)
- (ok id)))
-```
-
-Step by step, this function performs:
-
-When you call [`define-public`](../reference/functions.md#define-public), you're creating a function that anyone can call from outside the contract. The function takes one parameter called `content` that must be a UTF-8 string of maximum 280 characters.
-
-Inside the function, we use [`let`](../reference/functions.md#let) to create a local variable. This is like declaring a variable inside a function in other languages, but with Clarity's unique syntax. We're creating a variable called `id` and setting it to the current message count plus 1.
-
-_Here's where Clarity might trip you up if you're coming from other languages._ Notice how we write `(+ (var-get message-count) u1)` instead of something like `message-count + 1`. In Clarity, operators like `+`, `-`, `>`, and `<` are actually functions that use prefix notation. So `(+ 2 3)` means "add 2 and 3" (instead of `2 + 3` like you'd write in JavaScript or Python). This is part of Clarity's LISP-inspired syntax where everything is a function call.
-
-The [`var-get`](../reference/functions.md#var-get) function reads the current value of our message counter, and [`+`](../reference/functions.md#add) adds 1 to create the next message ID.
-
-Next, we store the message content using [`map-set`](../reference/functions.md#map-set), which is like inserting a row into a database table. We store the message content with the new ID we just created.
-
-We also store who posted the message using another [`map-set`](../reference/functions.md#map-set) call (_Notice how we use `tx-sender` here_). This is a special variable that Clarity automatically sets to the address of whoever called the function. You can't fake this or manipulate it, which makes it perfect for tracking message authors.
-
-We update our message counter using [`var-set`](../reference/functions.md#var-set), and finally return [`ok`](../reference/functions.md#ok) with the new message ID. In Clarity, all public functions must return either `(ok value)` for success or `(err error)` for failure. This ensures that every function call has a predictable outcome.
-
-#### Reading Messages Back
-
-Now let's look at how we read messages back from the blockchain. Our simplest function is:
-
-```clarity
-(define-read-only (get-message (id uint))
- (map-get? messages id))
-```
-
-When you use [`define-read-only`](../reference/functions.md#define-read-only), you're creating a function that can only read data, never modify it. This is perfect for getter functions like this one.
-
-The [`map-get?`](../reference/functions.md#map-get) function looks up a message by its ID. Notice the `?` at the end of the function name. This is Clarity's convention for functions that might not find what they're looking for. If the message exists, you'll get back `(some "message content")`. If it doesn't exist, you'll get `none`. This is much safer than null pointers in other languages because you have to explicitly handle both cases.
-
-We have similar functions for getting the message author and the total message count:
-
-```clarity
-(define-read-only (get-message-author (id uint))
- (map-get? message-authors id))
-
-(define-read-only (get-message-count)
- (var-get message-count))
-```
-
-The message count function is particularly simple because it just reads our counter variable and returns it. No parameters needed since there's only one counter.
-
-#### A More Complex Function: Getting Recent Messages
-
-Let's look at our most complex function:
-
-```clarity
-(define-read-only (get-recent-messages (count uint))
- (let ((total-count (var-get message-count)))
- (if (> count total-count)
- (map get-message (list u1 u2 u3 u4 u5))
- (map get-message (list
- (- total-count (- count u1))
- (- total-count (- count u2))
- (- total-count (- count u3))
- (- total-count (- count u4))
- (- total-count (- count u5)))))))
-```
-
-This function demonstrates several advanced Clarity concepts. We use [`if`](../reference/functions.md#if) for conditional logic. The [`>`](../reference/functions.md#greater-than) operator (remember, it's a function in prefix notation) compares whether the requested count is greater than our total messages.
-
-The [`map`](../reference/functions.md#map) function applies another function to each item in a list. So `(map get-message (list u1 u2 u3))` would call `get-message` on each of the numbers 1, 2, and 3.
-
-We use [`list`](../reference/functions.md#list) to create a list of message IDs, and [`-`](../reference/functions.md#subtract) for subtraction to calculate which recent messages to fetch.
-
-#### What Makes Clarity Special
-
-Now that you've seen the code, let me explain some of the key concepts that make Clarity different from other smart contract languages.
-
-One of the most important things to understand about Clarity is its response types. Every public function must return either `(ok value)` or `(err error)`. This might seem annoying at first, but it ensures that every function call has a predictable outcome. If a function returns `err`, any changes it made to the blockchain are automatically rolled back. If it returns `ok`, the changes are committed. This prevents a lot of the bugs that plague other blockchain platforms.
-
-Clarity also uses optional types extensively. Functions like `map-get?` return `(some value)` or `none` instead of potentially null values. This forces you to handle the case where data might not exist, which eliminates an entire class of bugs that you see in other languages where developers may neglect to check for null values.
-
-Understanding data persistence on the blockchain is another key concept. While Clarity does provide functions like `map-delete` and `map-set` that can modify or remove data, the decision of whether to make data mutable is entirely up to the contract developer. Notice how our contract doesn't have any functions to edit or delete messages. This is a deliberate design choice for our message board - we want messages to be permanent and trustworthy once posted. You could easily add update or delete functionality if your use case requires it, but for a message board, immutability makes sense.
-
-Every operation on the blockchain has execution costs, and Clarity is designed to make these costs predictable. Simple operations like reading a variable cost very little, while complex operations cost more. This is why we [avoid unbounded loops and recursion in Clarity](../concepts/clarity/decidability.md) at the language level - they can lead to unpredictable costs and potentially infinite execution.
-
-The automatic sender tracking through the `tx-sender` variable gives you built-in authentication without having to implement it yourself. This variable is automatically set by the blockchain and can't be spoofed, making it perfect for knowing who called your function.
-
-{% hint style="warning" %}
-**Important**: Be careful when using `tx-sender` vs `contract-caller` in your contracts. While `tx-sender` refers to the original transaction sender and remains constant throughout the entire transaction chain, `contract-caller` refers to the most recent principal in the transaction chain and can change with each internal function or contract call. This difference is crucial for security - malicious contracts can potentially exploit `tx-sender`'s persistent context to bypass admin checks if you're not careful. For simple contracts like our message board, `tx-sender` is appropriate, but for more complex authorization logic, consider whether you need the original sender or the immediate caller.
-
-For more details on this, check out [this excellent blog post](https://www.setzeus.com/public-blog-post/clarity-carefully-tx-sender) from Clarity developer [setzeus](https://x.com/setzeus).
-{% endhint %}
-
-Clarity's type safety means every variable and parameter has an explicit type. While Clarity is an interpreted language (not compiled), it performs comprehensive static analysis at deployment time through a multi-pass analysis system. This analysis catches type mismatches, undefined variables, and other errors before your contract is deployed, preventing runtime errors that could cause your contract to fail unexpectedly. Tools like `clarinet check` use this same analysis system to catch errors during development.
-
-Finally, Clarity's predictable execution model and [decidability](../concepts/clarity/decidability.md) mean that every function will terminate, and execution costs are predictable. Clarity doesn't allow recursion or unbounded loops, which makes Clarity contracts more reliable and easier to reason about than contracts written in other languages.
-
-This contract demonstrates the core patterns you'll use in most Clarity smart contracts: storing data in maps and variables, creating public functions for state changes, read-only functions for data access, and proper error handling with response types.
-
-
-
-## Step 3: Deploy Your Contract (5 minutes)
-
-Now let's deploy your contract to the Stacks testnet so you can interact with it from a web application.
-
-### Deploy via Stacks Explorer
-
-1. Visit the [Stacks Explorer Sandbox](https://explorer.hiro.so/sandbox/deploy?chain=testnet)
-2. Connect your Leather wallet (make sure you're on testnet)
-3. Paste your contract code into the editor
-4. Give your contract a name (e.g., "message-board") or just use the default generated name
-5. Click "Deploy Contract"
-6. Confirm the transaction in your wallet
-
-The deployment should only take a few seconds. Once complete, you'll see your contract address in the explorer. Here's [an example transaction](https://explorer.hiro.so/txid/0x3df7b597d1bbb3ce1598b1b0e28b7cbed38345fcf3fb33ae387165e13085e5d8?chain=testnet) deploying this contract.
-
-### Test Your Deployed Contract
-
-1. In the explorer, find your deployed contract
-2. Scroll down a bit and click on "Available Functions" to view its functions
-3. Try calling `add-message` with a test message (you'll need to change the post conditions toggle to allow mode, there is a dedicated docs page talking about [Post Conditions on Stacks](../concepts/transactions/post-conditions.md))
-4. Call `get-message` with ID `u1` to read it back
-5. Call `get-message-count` to see the total
-
-Your contract is now live and functional on the blockchain!
-
-## Step 4: Build the Frontend (10 minutes)
-
-Let's create a simple web interface to interact with your contract.
-
-### Set Up the Project
-
-Create a new React project:
-
-```bash
-npm create vite@latest my-message-board -- --template react
-cd my-message-board
-npm install
-```
-
-Install the Stacks.js libraries:
-
-```bash
-npm install @stacks/connect @stacks/transactions @stacks/network
-```
-
-### Create the App Component
-
-Replace the contents of `src/App.jsx` with the following:
-
-{% hint style="info" %}
-Since this is a quickstart, we won't dive into a long explanation of exacly what this code is doing. We suggest going and checking out [Hiro's Docs](https://docs.hiro.so/stacks/stacks.js) in order to get a handle on how stacks.js works.
-{% endhint %}
-
-```jsx
-import { useState, useEffect } from "react";
-import { connect, disconnect, isConnected, request } from "@stacks/connect";
-import {
- fetchCallReadOnlyFunction,
- stringUtf8CV,
- uintCV,
-} from "@stacks/transactions";
-import "./App.css";
-
-const network = "testnet";
-
-// Replace with your contract address
-const CONTRACT_ADDRESS = "YOUR_CONTRACT_ADDRESS_HERE";
-const CONTRACT_NAME = "message-board";
-
-function App() {
- const [connected, setConnected] = useState(false);
- const [messages, setMessages] = useState([]);
- const [newMessage, setNewMessage] = useState("");
- const [loading, setLoading] = useState(false);
-
- useEffect(() => {
- setConnected(isConnected());
- if (isConnected()) {
- loadMessages();
- }
- }, []);
-
- // Check for connection changes
- useEffect(() => {
- const checkConnection = () => {
- const connectionStatus = isConnected();
- if (connectionStatus !== connected) {
- setConnected(connectionStatus);
- if (connectionStatus) {
- loadMessages();
- }
- }
- };
-
- const intervalId = setInterval(checkConnection, 500);
- return () => clearInterval(intervalId);
- }, [connected]);
-
- const connectWallet = async () => {
- try {
- await connect({
- appDetails: {
- name: "Message Board",
- icon: window.location.origin + "/logo.svg",
- },
- onFinish: () => {
- setConnected(true);
- // Small delay to ensure connection is fully established
- setTimeout(() => {
- loadMessages();
- }, 100);
- },
- });
- } catch (error) {
- console.error("Connection failed:", error);
- }
- };
-
- const disconnectWallet = () => {
- disconnect();
- setConnected(false);
- setMessages([]);
- };
-
- const loadMessages = async () => {
- try {
- // Get message count
- const countResult = await fetchCallReadOnlyFunction({
- contractAddress: CONTRACT_ADDRESS,
- contractName: CONTRACT_NAME,
- functionName: "get-message-count",
- functionArgs: [],
- network,
- senderAddress: CONTRACT_ADDRESS,
- });
-
- const count = parseInt(countResult.value);
-
- // Load recent messages
- const messagePromises = [];
- for (let i = Math.max(1, count - 4); i <= count; i++) {
- messagePromises.push(
- fetchCallReadOnlyFunction({
- contractAddress: CONTRACT_ADDRESS,
- contractName: CONTRACT_NAME,
- functionName: "get-message",
- functionArgs: [uintCV(i)],
- network,
- senderAddress: CONTRACT_ADDRESS,
- })
- );
- }
-
- const messageResults = await Promise.all(messagePromises);
- const loadedMessages = messageResults
- .map((result, index) => ({
- id: count - messageResults.length + index + 1,
- content: result.value.value,
- }))
- .filter((msg) => msg.content !== undefined);
-
- setMessages(loadedMessages);
- } catch (error) {
- console.error("Error loading messages:", error);
- }
- };
-
- const postMessage = async () => {
- if (!newMessage.trim()) return;
-
- setLoading(true);
- try {
- const result = await request("stx_callContract", {
- contract: `${CONTRACT_ADDRESS}.${CONTRACT_NAME}`,
- functionName: "add-message",
- functionArgs: [stringUtf8CV(newMessage)],
- network,
- });
-
- console.log("Transaction submitted:", result.txid);
- setNewMessage("");
-
- // Reload messages after a delay to allow the transaction to process
- setTimeout(() => {
- loadMessages();
- setLoading(false);
- }, 2000);
- } catch (error) {
- console.error("Error posting message:", error);
- setLoading(false);
- }
- };
-
- return (
-
- setNewMessage(e.target.value)}
- placeholder="What's on your mind?"
- maxLength={280}
- disabled={loading}
- />
-
-
-
-
-
-
Recent Messages
-
- {messages.length === 0 ? (
-
No messages yet. Be the first to post!
- ) : (
-
- {messages.map((message) => (
-
- Message #{message.id}: {message.content}
-
- ))}
-
- )}
-
-
- )}
-
- );
-}
-
-export default App;
-```
-
-### Add Basic Styling
-
-Update `src/App.css`:
-
-```css
-.App {
- max-width: 800px;
- width: 100%;
- padding: 20px;
- font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", "Roboto",
- "Oxygen", "Ubuntu", "Cantarell", "Fira Sans", "Droid Sans",
- "Helvetica Neue", sans-serif;
-}
-
-.App-header {
- text-align: center;
- margin-bottom: 40px;
- padding: 20px;
- background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
- border-radius: 12px;
- color: white;
- box-shadow: 0 4px 6px -1px rgba(0, 0, 0, 0.1), 0 2px 4px -1px rgba(0, 0, 0, 0.06);
-}
-
-.App-header h1 {
- color: white;
- margin-bottom: 20px;
- font-size: 2.5rem;
- font-weight: 700;
- text-shadow: 0 2px 4px rgba(0, 0, 0, 0.1);
-}
-
-.connect-button,
-.disconnect-button {
- background-color: rgba(255, 255, 255, 0.2);
- color: white;
- border: 2px solid rgba(255, 255, 255, 0.3);
- padding: 12px 28px;
- border-radius: 8px;
- cursor: pointer;
- font-size: 16px;
- font-weight: 600;
- transition: all 0.3s ease;
- backdrop-filter: blur(10px);
-}
-
-.connect-button:hover,
-.disconnect-button:hover {
- background-color: rgba(255, 255, 255, 0.3);
- border-color: rgba(255, 255, 255, 0.5);
- transform: translateY(-2px);
- box-shadow: 0 8px 16px rgba(0, 0, 0, 0.2);
-}
-
-.post-message {
- margin-bottom: 40px;
- padding: 20px;
- border: 1px solid #e5e7eb;
- border-radius: 8px;
-}
-
-.message-input {
- display: flex;
- gap: 10px;
- margin-top: 10px;
-}
-
-.message-input input {
- flex: 1;
- padding: 10px;
- border: 1px solid #d1d5db;
- border-radius: 4px;
- font-size: 16px;
-}
-
-.message-input button {
- background-color: #10b981;
- color: white;
- border: none;
- padding: 10px 20px;
- border-radius: 4px;
- cursor: pointer;
-}
-
-.message-input button:disabled {
- background-color: #9ca3af;
- cursor: not-allowed;
-}
-
-.messages {
- padding: 20px;
- border: 1px solid #e5e7eb;
- border-radius: 8px;
-}
-
-.refresh-button {
- background-color: #6b7280;
- color: white;
- border: none;
- padding: 8px 16px;
- border-radius: 4px;
- cursor: pointer;
- margin-bottom: 20px;
-}
-
-.messages ul {
- list-style: none;
- padding: 0;
-}
-
-.messages li {
- padding: 10px;
- border-bottom: 1px solid #e5e7eb;
- margin-bottom: 10px;
-}
-
-.messages li:last-child {
- border-bottom: none;
-}
-```
-
-### Update the Contract Address
-
-1. Go back to the Stacks Explorer and find your deployed contract
-2. Copy the contract address (it looks like `ST1ABC...123.message-board`)
-3. Replace `YOUR_CONTRACT_ADDRESS_HERE` in the App.jsx file with your actual contract address and the contract name with the actual name
-
-### Run Your App
-
-```bash
-npm run dev
-```
-
-Visit `http://localhost:5173` and you should see your message board app! Connect your wallet and try posting a message.
-
-## Congratulations! 🎉
-
-You've just built your first Stacks application! Here's what you accomplished:
-
-1. ✅ Wrote a Clarity smart contract with data storage and public functions
-2. ✅ Deployed the contract to Stacks testnet
-3. ✅ Built a React frontend that connects to a Stacks wallet
-4. ✅ Integrated your frontend with your smart contract
-5. ✅ Posted and read data from the blockchain
-
-## Next Steps
-
-Now that you have the basics down, here are some ways to continue your Stacks development journey:
-
-### Learn More About Clarity
-
-* [**Clarity Book**](https://book.clarity-lang.org/): Comprehensive guide to Clarity development
-* [**Clarity Reference**](https://docs.stacks.co/docs/clarity): Complete documentation of Clarity functions
-* [**Clarity Crash Course**](https://docs.stacks.co/docs/clarity-crash-course): Quick introduction to Clarity concepts
-
-### Explore Advanced Features
-
-* **Error Handling**: Learn about Clarity's `try!` and `unwrap!` functions
-* **Access Control**: Implement admin functions and permissions
-* **Token Standards**: Build fungible (SIP-010) and non-fungible (SIP-009) tokens
-
-### Development Tools
-
-* [**Clarinet**](https://github.com/hirosystems/clarinet): Local development environment for Clarity
-* [**Hiro Platform**](https://platform.hiro.so): Hosted development environment
-* [**Stacks Explorer**](https://explorer.stacks.co): View transactions and contracts on mainnet
-
-### Community Resources
-
-* [**Stacks Discord**](https://discord.gg/stacks): Connect with other developers
-* [**Stacks Forum**](https://forum.stacks.org): Ask questions and share projects
-* [**Stacks GitHub**](https://github.com/stacks-network): Contribute to the ecosystem
-
-Happy building! 🚀
diff --git a/guides-and-tutorials/nodes-and-miners/README.md b/guides-and-tutorials/nodes-and-miners/README.md
deleted file mode 100644
index 85b7075943..0000000000
--- a/guides-and-tutorials/nodes-and-miners/README.md
+++ /dev/null
@@ -1,18 +0,0 @@
-# Run a Node
-
-This section will walk through the technical setup steps required to run Stacks Blockchain nodes and miners. There are multiple options available for running a node, including Docker, Digital Ocean, and Render.
-
-Running your own Stacks node is a great way to increase the decentralization of the ecosystem and not have to rely on any third-party, centralized providers.
-
-Regardless of your preferred setup, there are some minimum hardware recommendations you should be aware of:
-
-The **minimum viable requirements** are listed below.
-
-While you _can_ run a node using these specs, it's _recommended_ to assign more than the minimum for better performance.
-
-* ⚠️ [docker-compose](https://docs.docker.com/compose/install/) version `2.2.2` or greater is **required**
-* **8GB memory if running only a Stacks node**
-* **16 GB memory if running Stacks + Bitcoin node**
-* **2 Vcpu**
-* **1TB disk for Stacks node**
-* **1TB disk space for Bitcoin node**
diff --git a/guides-and-tutorials/nodes-and-miners/run-a-bitcoin-node.md b/guides-and-tutorials/nodes-and-miners/run-a-bitcoin-node.md
deleted file mode 100644
index 3992654a2e..0000000000
--- a/guides-and-tutorials/nodes-and-miners/run-a-bitcoin-node.md
+++ /dev/null
@@ -1,192 +0,0 @@
-# Running a Bitcoin Node
-
-### **Requirements:**
-
-This guide is written for a Unix based system. It's reasonable to expect some modifications will be required for other operating systems.
-
-When started, the Bitcoin node will take several days to reach chain tip.
-
-- Bitcoin Core >= v25.0
- -
- -
-- Host with a minimum of:
- - 2 vCPU (a single dedicated cpu for the bitcoind process)
- - 4GB Memory (during sync, more available memory will improve sync time)
- - 1TB free disk space
-- User account: `bitcoin:bitcoin`
-- Chainstate directory located at: `/bitcoin/mainnet`
- - `bitcoin` user must have read/write access.
-- Config directory located at: `/etc/bitcoin`
- - `bitcoin` user must have at least read access
-
----
-
-### **Add bitcoin user and set file ownership**
-
-```shell
-$ sudo mkdir -p /bitcoin/mainnet
-$ sudo mkdir /etc/bitcoin
-$ sudo useradd bitcoin -d /bitcoin
-$ sudo chown -R bitcoin:bitcoin /bitcoin /etc/bitcoin/
-```
-
-### **Bitcoin Config**
-
-Below is a sample config used to sync a bitcoin node - feel free to adjust as needed.
-
-{% hint style="info" %}
-If using the [systemd unit below](#systemd-unit-file), save this file as `/etc/bitcoin/bitcoin.conf`
-{% endhint %}
-
-- `btuser:btcpass` is hardcoded as an rpcauth user/password ([generated using this script](https://github.com/bitcoin/bitcoin/tree/master/share/rpcauth)).
-- Only localhost access is allowed (`127.0.0.1`) on the standard mainnet ports.
-- `dbcache` is set to the maximum of 16GB.
-- Wallet (and wallet rpc calls) are disabled.
-
-```text
-## [rpc]
-# Accept command line and JSON-RPC commands.
-server=1
-
-# Allow JSON-RPC connections from specified source.
-rpcallowip=127.0.0.1/0
-
-# Bind to given address to listen for JSON-RPC connections.
-rpcbind=127.0.0.1:8332
-
-# Username and HMAC-SHA-256 hashed password for JSON-RPC connections.
-# Use the script at https://github.com/bitcoin/bitcoin/tree/master/share/rpcauth to generate
-# Note: may be specified multiple times for different users.
-rpcauth=btcuser:18857b4df4b1f0f5e6b1d7884617ab39$de6e02e1da8ee138ee702e13e0637e24679d844756216b066c3aeac4bcac5e10 # btuser:btcpass
-
-# Optional: rpcwhitelist can restrict listed RPC calls to specific rpcauth users.
-# Uncomment the below the restrict the `limited` user to a small subset of `get` commands
-# rpcauth=limited:350c91a60895b567c4662c27e63e9a41$25188b0f51f2f974dcdc75c1e0d41174e8f7ae19fb96927abf68ac5bc1e8897b # limited:limited
-# rpcwhitelist=limited:getblockchaininfo,getblock,getblockcount,getblockhash,getblockheader,getnetworkinfo
-# rpcwhitelistdefault=0
-
-## [core]
-# Specify data directory
-datadir=/bitcoin/mainnet
-# Do not keep transactions in the mempool longer than hours (default: 336)
-mempoolexpiry=24
-# Bind to given address and always listen on it (default: 0.0.0.0)
-bind=127.0.0.1:8333
-# Maximum database cache size MiB (4 to 16384, default: 450). In addition, unused mempool memory is shared for this cache
-dbcache=16384
-# Maintain a full transaction index, used by the getrawtransaction rpc call
-txindex=1
-
-## [wallet]
-# Do not load the wallet and disable wallet RPC calls
-disablewallet=1
-```
-
-## Systemd unit file
-
-ref:
-
-```text
-[Unit]
-Description=Bitcoin daemon
-Documentation=https://github.com/bitcoin/bitcoin/blob/master/doc/init.md
-
-# https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
-After=network-online.target
-Wants=network-online.target
-
-[Service]
-ExecStart=/usr/bin/bitcoind -pid=/run/bitcoind/bitcoind.pid \
- -conf=/etc/bitcoin/bitcoin.conf \
- -startupnotify='systemd-notify --ready' \
- -shutdownnotify='systemd-notify --stopping'
-
-# Make sure the config directory is readable by the service user
-PermissionsStartOnly=true
-ExecStartPre=/bin/chgrp bitcoin /etc/bitcoin
-
-# Process management
-####################
-
-Type=notify
-NotifyAccess=all
-PIDFile=/run/bitcoind/bitcoind.pid
-
-Restart=on-failure
-TimeoutStartSec=infinity
-TimeoutStopSec=600
-
-# Directory creation and permissions
-####################################
-
-# Run as bitcoin:bitcoin
-User=bitcoin
-Group=bitcoin
-
-# /run/bitcoind
-RuntimeDirectory=bitcoind
-RuntimeDirectoryMode=0710
-
-# /etc/bitcoin
-ConfigurationDirectory=bitcoin
-ConfigurationDirectoryMode=0710
-
-# /var/lib/bitcoind
-StateDirectory=bitcoind
-StateDirectoryMode=0710
-
-# Hardening measures
-####################
-
-# Provide a private /tmp and /var/tmp.
-PrivateTmp=true
-
-# Mount /usr, /boot/ and /etc read-only for the process.
-ProtectSystem=full
-
-# Deny access to /home, /root and /run/user
-ProtectHome=true
-
-# Disallow the process and all of its children to gain
-# new privileges through execve().
-NoNewPrivileges=true
-
-# Use a new /dev namespace only populated with API pseudo devices
-# such as /dev/null, /dev/zero and /dev/random.
-PrivateDevices=true
-
-# Deny the creation of writable and executable memory mappings.
-MemoryDenyWriteExecute=true
-
-# Restrict ABIs to help ensure MemoryDenyWriteExecute is enforced
-SystemCallArchitectures=native
-
-[Install]
-WantedBy=multi-user.target
-```
-
-### **Enable and start the Bitcoin service**
-
-```shell
-$ sudo systemctl daemon-reload
-$ sudo systemctl enable bitcoin.service
-$ sudo systemctl start bitcoin.service
-```
-
-{% hint style="info" %}
-Once started, you may track the sync progress:
-
-```text
-$ sudo tail -f /bitcoin/mainnet/debug.log
-2024-12-05T19:35:31Z UpdateTip: new best=00000000000000000058990a84cc8f8eab25dbbd572f123f9190cea7256d7349 height=509258 version=0x20000000 log2_work=88.128280 tx=299522737 date='2018-02-15T03:42:14Z' progress=0.295203 cache=43.5MiB(172740txo)
-...
-$ bitcoin-cli \
- -rpcconnect=127.0.0.1 \
- -rpcport=8332 \
- -rpcuser=btcuser \
- -rpcpassword=btcpass \
- getblockcount
-509016
-```
-
-{% endhint %}
diff --git a/guides-and-tutorials/nodes-and-miners/run-a-node-with-a-hosted-provider.md b/guides-and-tutorials/nodes-and-miners/run-a-node-with-a-hosted-provider.md
deleted file mode 100644
index 7af4130744..0000000000
--- a/guides-and-tutorials/nodes-and-miners/run-a-node-with-a-hosted-provider.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Run a Node with a Hosted Provider
-
-We're always looking for new hosting providers that enable anyone to run the Stacks Blockchain. Below, you'll find some examples of the current providers that are known to support running a node.
-
-### Quicknode
-
-Please refer to the Quicknode Section for instructions on launching an instance with Quicknode.
-
-### Stacks on Render
-
-The [render-stacks](https://github.com/stacksfoundation/render-stacks) GitHub repo has instructions so anyone can deploy a Stacks node to the hosted [Render](https://render.com) service in one click.
-
-:::note While it is _possible_ to use the free plan with some modifications, \_ _**it is recommended to run this on paid plan**_ \_ :::
-
-### Stacks on Fly
-
-The [fly-stacks](https://github.com/stacksfoundation/fly-stacks) GitHub repo has instructions so anyone can deploy a Stacks node to the hosted [Fly](https://fly.io) service.
diff --git a/guides-and-tutorials/nodes-and-miners/run-a-node-with-digital-ocean.md b/guides-and-tutorials/nodes-and-miners/run-a-node-with-digital-ocean.md
deleted file mode 100644
index c863bba00e..0000000000
--- a/guides-and-tutorials/nodes-and-miners/run-a-node-with-digital-ocean.md
+++ /dev/null
@@ -1,81 +0,0 @@
-# Run a Node with Digital Ocean
-
-### Introduction
-
-This is a step by step guide to deploy the [Stacks Blockchain](https://github.com/stacks-network/stacks-blockchain) on [DigitalOcean](https://digitalocean.com).
-
-Build code is hosted on this [Github repository](https://github.com/stacksfoundation/stacks-machine-images) using the [methods from here](https://github.com/stacks-network/stacks-blockchain-docker)
-
-### Steps
-
-**Step 1**
-
-Go to the [Stacks Blockchain page](https://marketplace.digitalocean.com/apps/stacks-blockchain) in DigitalOcean's marketplace. Click on `Create Stacks Blockchain Droplet`.
-
-**Step 2**
-
-Choose a plan (it will only allow you to select a droplet that meets the minimum requirements) and your preferred datacenter region.
-
-**Step 3**
-
-Enter a root password or [enable SSH keys](https://docs.digitalocean.com/products/droplets/how-to/add-ssh-keys/) if you prefer.
-
-**Step 4**
-
-You can leave the rest of the options as they are and click on `Create Droplet`
-
-**Step 5**
-
-You will need to wait a few seconds for the droplet to get created. Once created click on it to see more information.
-
-#### Step 6
-
-Congratulations! You are now running the Stacks Blockchain. You can click on `Console` for a terminal window to open or login using SSH to the public IP you've been assigned to with user `root`.
-
-### Getting started after deploying Stacks Blockchain
-
-Once the droplet is launched, the initial startup can take several minutes while BNS data is imported (this is a one time operation) and the Bitcoin headers are synced.
-
-To keep track of the progress, you can `ssh root@your_droplet_public_ipv4` to the host and run: `/opt/stacks-blockchain-docker/manage.sh -n mainnet -a logs`.
-
-After the stacks blockchain finishes the initial header sync and starts to sync with its peers, the application ports will open (`20443` and `3999`) and HTTP port `80` will now start proxying requests.
-
-Use `http://your_droplet_public_ipv4` to access the data directly, with output being similar to:
-
-```json
-{
- "server_version": "stacks-blockchain-api v6.2.3 (master:77ab3ae2)",
- "status": "ready",
- "chain_tip": {
- "block_height": 91820,
- "block_hash": "0x06b276e85f238151414616618ae0adaf5eeda4eac6cad5bbefceeb37948ab275",
- "index_block_hash": "0x4d7c075d7ab0f90b1dbc175f5c42b7344265d00cfef202dd9681d95388eeed8c",
- "microblock_hash": "0xcf4f9037cc10696b2812b617ca105885be625c6acf8ad67e71bb4c09fa6ebb21",
- "microblock_sequence": 4
- }
-}
-```
-
-:::tip For the full list of API endpoints for the Stacks Blockchain, consult the [Hiro API Docs](https://docs.hiro.so/api) :::
-
-All services are managed by a [systemd unit file](https://github.com/stacksfoundation/stacks-machine-images/blob/master/files/etc/systemd/system/stacks.service) that is set to start on boot.
-
-Manual control is also possible via the [manage.sh script](https://github.com/stacks-network/stacks-blockchain-docker/blob/master/manage.sh) at `/opt/stacks-blockchain-docker/manage.sh` on the host.
-
-Full details on how to use the manage.sh script is [available here](https://github.com/stacks-network/stacks-blockchain-docker/blob/master/docs/usage.md).
-
-### Launching a Droplet using the DigitalOcean API
-
-In addition to creating a Droplet from the Stacks Blockchain 1-Click App via the control panel, you can also use the [DigitalOcean API](https://digitalocean.com/docs/api).
-
-As an example, to create a 4GB Stacks Blockchain Droplet in the SFO2 region, you can use the following curl command. You’ll need to either save your [API access token](https://docs.digitalocean.com/reference/api/create-personal-access-token/) to an environment variable or substitute it into the command below.
-
-:::note _The `name`, `region` and `size` values below are hardcoded, so adjust as desired._ :::
-
-```bash
-$ export TOKEN=
-$ curl -X POST -H 'Content-Type: application/json' \
- -H 'Authorization: Bearer '$TOKEN'' -d \
- '{"name":"stacks-blockchain","region":"sfo2","size":"s-2vcpu-4gb","image":"stacksfoundation-stacksblockchain"}' \
- "https://api.digitalocean.com/v2/droplets"
-```
diff --git a/guides-and-tutorials/nodes-and-miners/run-a-node-with-docker.md b/guides-and-tutorials/nodes-and-miners/run-a-node-with-docker.md
deleted file mode 100644
index 382880c719..0000000000
--- a/guides-and-tutorials/nodes-and-miners/run-a-node-with-docker.md
+++ /dev/null
@@ -1,106 +0,0 @@
-# Run a Node with Docker
-
-### Stacks Blockchain with Docker
-
-Run your own Stacks Blockchain node using [docker-compose](https://docs.docker.com/compose/) with just few commands using [stacks-blockchain-docker](https://github.com/stacks-network/stacks-blockchain-docker)
-
-* Quickstart
-* [Requirements](https://github.com/stacks-network/stacks-blockchain-docker/blob/master/docs/requirements.md)
-* [Docker Setup](https://github.com/stacks-network/stacks-blockchain-docker/blob/master/docs/docker.md)
-* [Configuration](https://github.com/stacks-network/stacks-blockchain-docker/blob/master/docs/config.md)
-* [Upgrading](https://github.com/stacks-network/stacks-blockchain-docker/blob/master/docs/upgrade.md)
-* [Common Issues](https://github.com/stacks-network/stacks-blockchain-docker/blob/master/docs/issues.md)
-
-### **Requirements:**
-
-The **minimum viable requirements** are listed below.
-
-While you _can_ run a node using these specs, it's _recommended_ to assign more than the minimum for better performance.
-
-* ⚠️ [docker-compose](https://docs.docker.com/compose/install/) version `2.2.2` or greater is **required**
-* **8GB memory if running only a Stacks node**
-* **16 GB memory if running Stacks + Bitcoin node**
-* **1 Vcpu** ( _minimum of 2 Vcpu is recommended_ )
-* **500GB disk for Stacks node**
-* **1TB disk space for Bitcoin node**
-
-{% hint style="warning" %}
-MacOS with an ARM (M-series chip) processor is NOT recommended
-
-The way Docker for Mac on an Arm CPU is designed makes the I/O incredibly slow, and blockchains are _**very**_ heavy on I/O. This only seems to affect MacOS with the M-series chip, other Arm based systems like Raspberry Pi work as expected.
-{% endhint %}
-
-### **Quickstart**
-
-The `` placeholder used below can be replaced with one of:
-
-* mainnet
-* testnet
-* mocknet
-
-1. **Clone the stacks-blockchain-docker repository locally**
-
-```bash
-git clone https://github.com/stacks-network/stacks-blockchain-docker && cd stacks-blockchain-docker
-```
-
-2. **Start the Services**
-
-```bash
-./manage.sh -n -a start
-```
-
-{% hint style="info" %}
-With an optional HTTP proxy on port 80:
-
-```bash
-./manage.sh -n -a start -f proxy
-```
-{% endhint %}
-
-### **Accessing the services**
-
-{% hint style="info" %}
-For networks other than `mocknet`, downloading the initial headers can take several minutes. Until the headers are downloaded, the `/v2/info` endpoints won't return any data.
-
-Follow the logs to track the sync progress:
-
-```bash
-./manage.sh -n -a logs
-```
-{% endhint %}
-
-**stacks-blockchain**:
-
-* Ports `20443-20444` are exposed on `localhost`
-
-```bash
-curl -sL localhost:20443/v2/info | jq -r
-```
-
-**stacks-blockchain-api**:
-
-* Port `3999` is exposed on `localhost`
-
-```bash
-curl -sL localhost:3999 | jq -r
-```
-
-**proxy**:
-
-* Port `80` is exposed on `localhost`
-
-```bash
-curl -sL localhost/v2/info | jq -r
-curl -sL localhost | jq -r
-```
-
-***
-
-### Upgrades
-
-{% hint style="warning" %}
-For schema-breaking upgrades to running instances of this repo, you'll need to [run an event-replay](https://github.com/stacks-network/stacks-blockchain-docker/blob/master/docs/upgrade.md).
-{% endhint %}
-
-***
diff --git a/guides-and-tutorials/nodes-and-miners/run-a-node-with-quicknode.md b/guides-and-tutorials/nodes-and-miners/run-a-node-with-quicknode.md
deleted file mode 100644
index 1879809c7d..0000000000
--- a/guides-and-tutorials/nodes-and-miners/run-a-node-with-quicknode.md
+++ /dev/null
@@ -1,37 +0,0 @@
-# Run a Node with Quicknode
-
-[QuickNode](https://www.quicknode.com/) is a service for rapidly getting set up with a Stacks node.
-
-As an easy and fast alternative to running your own node, you can utilize QuickNode to serve as an API.
-
-To get started, [set up an account](https://www.quicknode.com/signup) on QuickNode.
-
-Once you are signed in, getting set up with your own Stacks node is a matter of a few clicks, starting with 'Create an endpoint'.
-
-From there, you just need to select Stacks, your desired network, and your desired QuickNode plan level.
-
-_That's it._
-
-You now have an API endpoint URL you can use to connect to Stacks.
-
-How do you do that?
-
-It depends on the frontend framework you are using, but let's see how to do it with Stacks.js.
-
-First, you'll need to install the `@stacks/network` package.
-
-Next we'll import it:
-
-```javascript
-import { StacksTestnet } from "@stacks/network";
-```
-
-Then in your frontend, set up the network with the following line:
-
-```javascript
-const network = new StacksTestnet({ url: "" });
-```
-
-Then you can call transactions like you normally would using the `@stacks/transactions` library.
-
-For an example of how to do this, please refer to the Hello Stacks tutorial.
diff --git a/guides-and-tutorials/nodes-and-miners/run-a-pruned-bitcoin-node.md b/guides-and-tutorials/nodes-and-miners/run-a-pruned-bitcoin-node.md
deleted file mode 100644
index ce61d057de..0000000000
--- a/guides-and-tutorials/nodes-and-miners/run-a-pruned-bitcoin-node.md
+++ /dev/null
@@ -1,219 +0,0 @@
-# Running a Pruned Bitcoin Node
-
-### **Requirements:**
-
-This guide is written for a Unix based system. It's reasonable to expect some modifications will be required for other operating systems.
-
-When started, the pruned Bitcoin node will take roughly **~24** hours to reach chain tip.
-
-{% hint style="warning" %}
-While bitcoin is syncing, it's recommended to keep a stacks-blockchain node at chain tip, or [use a stacks chainstate archive](https://docs.hiro.so/stacks/archive/guides/stacks-blockchain).
-{% endhint %}
-
-- Bitcoin Core >= v25.0
- -
- -
-- Host with a minimum of:
- - 2 vCPU (a single dedicated cpu for the bitcoind process)
- - 4GB Memory (during sync, more available memory will improve sync time)
- - 50GB free disk space (actual usage is closer to 20GB)
-- User account: `bitcoin:bitcoin`
-- Chainstate directory located at: `/bitcoin/mainnet`
- - `bitcoin` user must have read/write access.
-- Config directory located at: `/etc/bitcoin`
- - `bitcoin` user must have at least read access
-
-### **Caveats**
-
-[BIP-0159](https://github.com/bitcoin/bips/blob/master/bip-0159.mediawiki)
-
-In short, this BIP specifies that pruned nodes will advertise the service bit `NODE_NETWORK_LIMITED`, which restricts syncing blocks older than 288 blocks (~2 days).
-
-What this means is that in practice, a stacks-blockchain node:
-
-- **Cannot** sync from genesis using a pruned node.
-- **Must not** be offline or otherwise down for longer than ~2 days (or 288 Bitcoin blocks).
-
----
-
-### **Add bitcoin user and set file ownership**
-
-```shell
-$ sudo mkdir -p /bitcoin/mainnet
-$ sudo mkdir /etc/bitcoin
-$ sudo useradd bitcoin -d /bitcoin
-$ sudo chown -R bitcoin:bitcoin /bitcoin /etc/bitcoin/
-```
-
-### **Bitcoin Config**
-
-Below is a sample config used to sync a pruned bitcoin node - feel free to adjust as needed.
-
-{% hint style="info" %}
-If using the [systemd unit below](#systemd-unit-file), save this file as `/etc/bitcoin/bitcoin.conf`
-{% endhint %}
-
-- `btuser:btcpass` is hardcoded as an rpcauth user/password ([generated using this script](https://github.com/bitcoin/bitcoin/tree/master/share/rpcauth)).
-- Only localhost access is allowed (`127.0.0.1`) on the standard mainnet ports.
-- Pruning is set to be small, storing only the last 1GB of blocks (for p2p traffic, this is more than enough).
-- `dbcache` is set to the maximum of 16GB.
-- Wallet (and wallet rpc calls) are disabled.
-
-```text
-## [rpc]
-# Accept command line and JSON-RPC commands.
-server=1
-
-# Allow JSON-RPC connections from specified source.
-rpcallowip=127.0.0.1/0
-
-# Bind to given address to listen for JSON-RPC connections.
-rpcbind=127.0.0.1:8332
-
-# Username and HMAC-SHA-256 hashed password for JSON-RPC connections.
-# Use the script at https://github.com/bitcoin/bitcoin/tree/master/share/rpcauth to generate
-# Note: may be specified multiple times for different users.
-rpcauth=btcuser:18857b4df4b1f0f5e6b1d7884617ab39$de6e02e1da8ee138ee702e13e0637e24679d844756216b066c3aeac4bcac5e10 # btuser:btcpass
-
-# Optional: rpcwhitelist can restrict listed RPC calls to specific rpcauth users.
-# Uncomment the below the restrict the `limited` user to a small subset of `get` commands
-# rpcauth=limited:350c91a60895b567c4662c27e63e9a41$25188b0f51f2f974dcdc75c1e0d41174e8f7ae19fb96927abf68ac5bc1e8897b # limited:limited
-# rpcwhitelist=limited:getblockchaininfo,getblock,getblockcount,getblockhash,getblockheader,getnetworkinfo
-# rpcwhitelistdefault=0
-
-## [core]
-# Specify data directory
-datadir=/bitcoin/mainnet
-# Do not keep transactions in the mempool longer than hours (default: 336)
-mempoolexpiry=24
-# Bind to given address and always listen on it (default: 0.0.0.0)
-bind=127.0.0.1:8333
-# Maximum database cache size MiB (4 to 16384, default: 450). In addition, unused mempool memory is shared for this cache
-dbcache=16384
-# Maintain a full transaction index, used by the getrawtransaction rpc call (**Running a pruned node requires that this option is disabled**)
-txindex=0
-
-# Reduce storage requirements by enabling pruning (deleting) of old
-# blocks. This allows the pruneblockchain RPC to be called to
-# delete specific blocks and enables automatic pruning of old
-# blocks if a target size in MiB is provided. This mode is
-# incompatible with -txindex. Warning: Reverting this setting
-# requires re-downloading the entire blockchain. (default: 0 =
-# disable pruning blocks, 1 = allow manual pruning via RPC, >=550 =
-# automatically prune block files to stay under the specified
-# target size in MiB)
-prune=1024 # 1GB of chainstate is enough for p2p block data (if using the RPC,this can be adjusted higher to store more blocks)
-
-## [wallet]
-# Do not load the wallet and disable wallet RPC calls
-disablewallet=1
-```
-
-## Systemd unit file
-
-ref:
-
-```text
-[Unit]
-Description=Bitcoin daemon
-Documentation=https://github.com/bitcoin/bitcoin/blob/master/doc/init.md
-
-# https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
-After=network-online.target
-Wants=network-online.target
-
-[Service]
-ExecStart=/usr/bin/bitcoind -pid=/run/bitcoind/bitcoind.pid \
- -conf=/etc/bitcoin/bitcoin.conf \
- -startupnotify='systemd-notify --ready' \
- -shutdownnotify='systemd-notify --stopping'
-
-# Make sure the config directory is readable by the service user
-PermissionsStartOnly=true
-ExecStartPre=/bin/chgrp bitcoin /etc/bitcoin
-
-# Process management
-####################
-
-Type=notify
-NotifyAccess=all
-PIDFile=/run/bitcoind/bitcoind.pid
-
-Restart=on-failure
-TimeoutStartSec=infinity
-TimeoutStopSec=600
-
-# Directory creation and permissions
-####################################
-
-# Run as bitcoin:bitcoin
-User=bitcoin
-Group=bitcoin
-
-# /run/bitcoind
-RuntimeDirectory=bitcoind
-RuntimeDirectoryMode=0710
-
-# /etc/bitcoin
-ConfigurationDirectory=bitcoin
-ConfigurationDirectoryMode=0710
-
-# /var/lib/bitcoind
-StateDirectory=bitcoind
-StateDirectoryMode=0710
-
-# Hardening measures
-####################
-
-# Provide a private /tmp and /var/tmp.
-PrivateTmp=true
-
-# Mount /usr, /boot/ and /etc read-only for the process.
-ProtectSystem=full
-
-# Deny access to /home, /root and /run/user
-ProtectHome=true
-
-# Disallow the process and all of its children to gain
-# new privileges through execve().
-NoNewPrivileges=true
-
-# Use a new /dev namespace only populated with API pseudo devices
-# such as /dev/null, /dev/zero and /dev/random.
-PrivateDevices=true
-
-# Deny the creation of writable and executable memory mappings.
-MemoryDenyWriteExecute=true
-
-# Restrict ABIs to help ensure MemoryDenyWriteExecute is enforced
-SystemCallArchitectures=native
-
-[Install]
-WantedBy=multi-user.target
-```
-
-### **Enable and start the Bitcoin service**
-
-```shell
-$ sudo systemctl daemon-reload
-$ sudo systemctl enable bitcoin.service
-$ sudo systemctl start bitcoin.service
-```
-
-{% hint style="info" %}
-Once started, you may track the sync progress:
-
-```text
-$ sudo tail -f /bitcoin/mainnet/debug.log
-2024-12-05T19:35:31Z UpdateTip: new best=00000000000000000058990a84cc8f8eab25dbbd572f123f9190cea7256d7349 height=509258 version=0x20000000 log2_work=88.128280 tx=299522737 date='2018-02-15T03:42:14Z' progress=0.295203 cache=43.5MiB(172740txo)
-...
-$ bitcoin-cli \
- -rpcconnect=127.0.0.1 \
- -rpcport=8332 \
- -rpcuser=btcuser \
- -rpcpassword=btcpass \
- getblockcount
-509016
-```
-
-{% endhint %}
diff --git a/guides-and-tutorials/oracles.md b/guides-and-tutorials/oracles.md
deleted file mode 100644
index 87baee58b1..0000000000
--- a/guides-and-tutorials/oracles.md
+++ /dev/null
@@ -1,32 +0,0 @@
-# Oracles
-
-## Price‑Feed Oracles on Stacks
-
-Smart contracts written in **Clarity** run in a deterministic sandbox: they can read data in the Stacks and Bitcoin chainstate, but _nothing else_. Whenever your dApp needs the latest **BTC/USD**, **STX/BTC**, or any other market price, you’ll rely on an **oracle** to bring that data on‑chain in a verifiable way.
-
-This page lays out _why_ price‑feed oracles matter on Stacks and link to the specific oracle provider docs for instructions on how to integrate them.
-
-***
-
-### Why you need a price‑feed oracle
-
-Here are some possible scenarios where you might need an oracle.
-
-| On‑chain need | Typical Stacks use case | What the oracle supplies |
-| ------------------------------------ | ---------------------------------------------- | ----------------------------------- |
-| **Liquidations & collateral ratios** | Lending / borrowing protocols, margin trading | Signed price updated every N blocks |
-| **Stablecoin peg maintenance** | BTC‑backed or exogenous‑collateral stablecoins | Reference BTC/USD (or other) price |
-| **AMM curve calculations** | DEXs that tune fees or rebalance pools | Time‑weighted average price (TWAP) |
-| **Derivatives settlement** | Options, futures, or perpetual swaps | Final settlement price at expiry |
-
-> **Rule of thumb:** if your contract’s math depends on a real‑time market price, you need a price‑feed oracle.
-
-### Oracle Providers
-
-There are two oracle providers that Stacks builders are currently using for their data needs: Pyth and DIA.
-
-Pyth is a pull-based oracle and Trust Machines currently maintains the Pyth bridge. You can view docs on how to use Pyth and the associated Clarity contracts on Trust Machine's [GitHub repo for the bridge.](https://github.com/Trust-Machines/stacks-pyth-bridge)
-
-DIA is the other oracle provider Stacks builders frequently use.
-
-There is a documentation guide on how to use DIA oracles with Stacks on [DIA's docs website](https://nexus.diadata.org/how-to-guides/fetch-price-data/chain-specific-guide/stacks).
diff --git a/guides-and-tutorials/run-a-miner/README.md b/guides-and-tutorials/run-a-miner/README.md
deleted file mode 100644
index f0da72f8a3..0000000000
--- a/guides-and-tutorials/run-a-miner/README.md
+++ /dev/null
@@ -1,5 +0,0 @@
-# Run a Miner
-
-If you are interested in running a Stacks miner, there are a few things you'll need to understand. Running a miner is similar to running a node, but you'll need to set up some additional configuration.
-
-These guides will help you get up and running with both a testnet and mainnet Stacks miner.
diff --git a/guides-and-tutorials/run-a-miner/mine-mainnet-stacks-tokens.md b/guides-and-tutorials/run-a-miner/mine-mainnet-stacks-tokens.md
deleted file mode 100644
index 6fd93e38a0..0000000000
--- a/guides-and-tutorials/run-a-miner/mine-mainnet-stacks-tokens.md
+++ /dev/null
@@ -1,307 +0,0 @@
-# Mine Mainnet Stacks Tokens
-
-### Introduction
-
-For more on the technical details of mining, please review the mining guide.
-
-The following is an abridged version of the [walkthrough here](https://github.com/stacksfoundation/miner-docs), written for a Linux system. If you're on Windows or MacOS, there will be some slight modifications needed (PR's welcome!).
-
-If you're interested in mining on the Stacks mainnet, you can find instructions on how to do that here:
-
-### Running a Bitcoin Mainnet Full Node
-
-To participate as a miner on mainnet, you must have access to a mainnet bitcoin node with a wallet (and the wallet's private key). One way to accomplish this is to run bitcoin locally.
-
-* [Ensure your computer meets the minimum hardware requirements before continuing.](https://bitcoin.org/en/bitcoin-core/features/requirements#system-requirements)
-
-First, download a [bitcoin binary](https://bitcoin.org/en/download), or [build from source](https://github.com/stacksfoundation/miner-docs/blob/main/bitcoin.md#source-install) (_there may be some extra requirements to building,_ [_defined here_](https://github.com/stacksfoundation/miner-docs/blob/main/prerequisites.md#install-required-packages)).
-
-If you want to learn more about the technical details of mining, please review the mining guide:
-
-{% hint style="info" %}
-**Tip:** It is recommended to use a persistent location for the chainstate, in the steps below we're using `/bitcoin`.
-{% endhint %}
-
-#### Update the Bitcoin Configuration File
-
-Next, update the bitcoin configuration:
-
-* **Optional, but recommended:** Use a persistent directory to store the Bitcoin chainstate, i.e. `datadir=/bitcoin`.
-* **Optional, but recommended:** Update the `rpcallowip` value to only allow `127.0.0.1`, or the stacks miner IPv4.
-* Modify the `rpcuser` and `rpcpassword` values from the defaults below.
-* Store the following configuration somewhere on your filesystem (ex: `$HOME/bitcoin.conf`).
-
-```toml
-server=1
-disablewallet=0
-datadir=/bitcoin
-rpcuser=btcuser
-rpcpassword=btcpass
-rpcallowip=0.0.0.0/0
-bind=0.0.0.0:8333
-rpcbind=0.0.0.0:8332
-dbcache=512
-banscore=1
-rpcthreads=256
-rpcworkqueue=256
-rpctimeout=100
-txindex=1
-```
-
-#### Start Bitcoin
-
-Finally, start `bitcoind` as follows (adjust the `conf` path to where it was created in the previous step, i.e. `$HOME/bitcoin.conf`):
-
-```bash
-bitcoind -conf=$HOME/bitcoin.conf
-```
-
-{% hint style="info" %}
-**Note:** It will take a few hours for the node to synchronize with Bitcoin Mainnet.
-{% endhint %}
-
-While it's syncing, you can track the progress with `bitcoin-cli` or the logfile (will be located where the chainstate is stored, i.e. `/bitcoin/debug.log`):
-
-```bash
-$ bitcoin-cli \
- -rpcconnect=127.0.0.1 \
- -rpcport=8332 \
- -rpcuser=btcuser \
- -rpcpassword=btcpass \
-getblockchaininfo | jq .blocks
-836745
-```
-
-***
-
-### Running a Stacks Blockchain miner
-
-First, download the latest tagged [stacks blockchain binary](https://github.com/stacks-network/stacks-blockchain/releases/latest), or [build from source](https://github.com/stacksfoundation/miner-docs/blob/main/stacks-blockchain.md#build-and-install-stacks-blockchain-from-source) (_there may be some extra requirements to building,_ [_defined here_](https://github.com/stacksfoundation/miner-docs/blob/main/prerequisites.md#install-required-packages)).
-
-{% hint style="info" %}
-**Tip:** It is recommended to use a persistent location for the chainstate, in the steps below we're using `/stacks-blockchain`.
-{% endhint %}
-
-#### Generate a keychain
-
-First, a keychain needs to be generated. With this keychain, we'll purchase some BTC from a cryptocurrency exchange, and then use that BTC to start mining.
-
-To create a keychain, the simplest way is to use the [stacks-cli](https://docs.hiro.so/references/stacks-cli) with the `make_keychain` command.
-
-```bash
-npx @stacks/cli make_keychain 2>/dev/null | jq -r
-```
-
-After this runs, you should see some JSON printed to the screen that looks like this:
-
-```json
-{
- "mnemonic": "spare decade dog ghost luxury churn flat lizard inch nephew nut drop huge divert mother soccer father zebra resist later twin vocal slender detail",
- "keyInfo": {
- "privateKey": "ooxeemeitar4ahw0ca8anu4thae7aephahshae1pahtae5oocahthahho4ahn7eici",
- "address": "SPTXOG3AIHOHNAEH5AU6IEX9OOTOH8SEIWEI5IJ9",
- "btcAddress": "Ook6goo1Jee5ZuPualeiqu9RiN8wooshoo",
- "wif": "rohCie2ein2chaed9kaiyoo6zo1aeQu1yae4phooShov2oosh4ox",
- "index": 0
- }
-}
-```
-
-
-{% hint style="danger" %}
-**Do not lose this information** - we'll need to use the `privateKey`, `btcAddress` and `wif` fields in later steps.
-{% endhint %}
-
-The above `wif` (`Kyk49jsPGen5C1ThhyJJH4CndLk8yLESuQJVGsbbTV3FFF9CRTJG`) will then need to be imported into the bitcoin mainnet network.
-
-Next, a bitcoin wallet is created:
-```bash
-bitcoin-cli \
- -rpcconnect=127.0.0.1 \
- -rpcport=8332 \
- -rpcuser=btcuser \
- -rpcpassword=btcpass \
- createwallet \
- wallet_name="miner" \
- disable_private_keys=false \
- blank=false \
- passphrase="" \
- avoid_reuse=false \
- descriptors=false \
- load_on_startup=true
-```
-
-Now, import your wif (bitcoin private key) inside the newly created wallet.
-
-{% hint style="info" %}
-**Note:** Be sure to replace `` with the wif value in the `Generate a keychain` step.
-{% endhint %}
-
-```bash
-bitcoin-cli \
- -rpcport=8332 \
- -rpcuser=btcuser \
- -rpcpassword=btcpassword \
- importprivkey
-```
-
-{% hint style="info" %}
-**Note:** The import may take a while, because a wallet rescan is triggered. After the import has completed successfully, you can check that the address is imported with `getaddressinfo`.
-{% endhint %}
-```bash
-bitcoin-cli \
- -rpcconnect=127.0.0.1 \
- -rpcport=8332 \
- -rpcuser=btcuser \
- -rpcpassword=btcpass \
- getaddressinfo
-```
-
-Once imported, we need to get some BTC to that address. You should be able to transfer BTC to this address using a cryptocurrency exchange such as [Coinbase](https://www.coinbase.com), [Binance](https://www.binance.com), or [Kraken](https://www.kraken.com).
-
-#### Update the Stacks Blockchain Configuration File
-
-Now, we need to configure our node to use this Bitcoin keychain. Copy the [sample mainnet miner config](https://raw.githubusercontent.com/stacks-network/stacks-blockchain/master/testnet/stacks-node/conf/mainnet-miner-conf.toml) to your local machine in a _memorable_ location like `$HOME/mainnet-miner-conf.toml`.
-
-Next, update the stacks configuration:
-
-* **Optional, but recommended:** Use a persistent directory to store the Stacks chainstate, i.e. `working_dir = "/stacks-blockchain"`
-* From the `make_keychain` step, modify the `seed` and `mining_key` values with `privatekey`
-* Store the following configuration somewhere on your filesystem (ex: `$HOME/mainnet-miner-conf.toml`)
-
-```toml
-[node]
-working_dir = "/stacks-blockchain"
-rpc_bind = "0.0.0.0:20443"
-p2p_bind = "0.0.0.0:20444"
-seed = ""
-miner = true
-bootstrap_node = "02196f005965cebe6ddc3901b7b1cc1aa7a88f305bb8c5893456b8f9a605923893@seed.mainnet.hiro.so:20444,02539449ad94e6e6392d8c1deb2b4e61f80ae2a18964349bc14336d8b903c46a8c@cet.stacksnodes.org:20444,02ececc8ce79b8adf813f13a0255f8ae58d4357309ba0cedd523d9f1a306fcfb79@sgt.stacksnodes.org:20444,0303144ba518fe7a0fb56a8a7d488f950307a4330f146e1e1458fc63fb33defe96@est.stacksnodes.org:20444"
-mine_microblocks = false
-
-[burnchain]
-wallet_name = "miner"
-chain = "bitcoin"
-mode = "mainnet"
-peer_host = "127.0.0.1"
-username = ""
-password = ""
-rpc_port = 8332
-peer_port = 8333
-satoshis_per_byte = 100
-burn_fee_cap = 450000
-
-[miner]
-mining_key = ""
-activated_vrf_key_path = "/stacks-blockchain/saved_vrf_key.json"
-
-[connection_options]
-private_neighbors = false
-```
-
-#### Start the Stacks Blockchain
-
-To run your miner, run this in the command line:
-
-```bash
-stacks-node start --config $HOME/mainnet-miner-conf.toml
-```
-
-Your node should start. It will take some time to sync, and then your miner will be running.
-
-#### Enable Debug Logging
-
-In case you are running into issues or would like to see verbose logging, you can run your node with debug logging enabled. In the command line, run:
-
-```bash
-STACKS_LOG_DEBUG=1 stacks-node start --config $HOME/mainnet-miner-conf.toml
-```
-
-***
-
-### Optional: Running a Stacks Blockchain miner with Docker
-
-Alternatively, you can run a Stacks mainnet miner with Docker.
-
-{% hint style="warning" %}
-Ensure you have [Docker](https://docs.docker.com/get-docker/) installed.
-{% endhint %}
-
-#### Generate a Keychain and Get Some Tokens
-
-Generate a keychain:
-
-```bash
-docker run -i node:20-alpine npx @stacks/cli make_keychain 2>/dev/null | jq -r
-```
-
-We need to get some BTC to that address. You should be able to transfer BTC to this address using a cryptocurrency exchange such as [Coinbase](https://www.coinbase.com), [Binance](https://www.binance.com), or [Kraken](https://www.kraken.com).
-
-#### Update Stacks Blockchain Docker Configuration File
-
-Use the steps outlined above to create the configuration file.
-
-#### Start the Stacks Blockchain miner with Docker
-
-{% hint style="info" %}
-**Info:** The ENV VARS `RUST_BACKTRACE` and `STACKS_LOG_DEBUG` are optional. If removed, debug logs will be disabled.
-{% endhint %}
-
-```bash
-docker run -d \
- --name stacks_miner \
- --rm \
- --network host \
- -e RUST_BACKTRACE="full" \
- -e STACKS_LOG_DEBUG="1" \
- -v "$HOME/mainnet-miner-conf.toml:/src/stacks-node/mainnet-miner-conf.toml" \
- -v "/stacks-blockchain:/stacks-blockchain" \
- -p 20443:20443 \
- -p 20444:20444 \
- blockstack/stacks-blockchain:latest \
-/bin/stacks-node start --config /src/stacks-node/mainnet-miner-conf.toml
-```
-
-You can review the node logs with this command:
-
-```bash
-docker logs -f stacks_miner
-```
-
-***
-
-### Optional: Running in Kubernetes with Helm
-
-In addition, you're also able to run a Stacks miner in a Kubernetes cluster using the [stacks-blockchain Helm chart](https://github.com/stacks-network/stacks-blockchain/tree/master/deployment/helm/stacks-blockchain).
-
-Ensure you have the following prerequisites installed:
-
-* [Docker](https://docs.docker.com/get-docker/)
-* [minikube](https://minikube.sigs.k8s.io/docs/start/) (Only needed if standing up a local Kubernetes cluster)
-* [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/)
-* [helm](https://helm.sh/docs/intro/install/)
-
-#### Generate keychain and get some tokens
-
-Use the steps outlined above
-
-#### Install the chart and run the miner
-
-To install the chart with the release name `my-release` and run the node as a miner:
-
-```bash
-minikube start # Only run this if standing up a local Kubernetes cluster
-helm repo add blockstack https://charts.blockstack.xyz
-helm install my-release blockstack/stacks-blockchain \
- --set config.node.miner=true \
- --set config.node.seed="your-privateKey-from-generate-keychain-step" \
- --set config.burnchain.mode="mainnet"
-```
-
-You can review the node logs with this command:
-
-```bash
-kubectl logs -l app.kubernetes.io/name=stacks-blockchain
-```
-
-For more information on the Helm chart and configuration options, please refer to the [chart's homepage](https://github.com/stacks-network/stacks-blockchain/tree/master/deployment/helm/stacks-blockchain).
diff --git a/guides-and-tutorials/run-a-miner/mine-testnet-stacks-tokens.md b/guides-and-tutorials/run-a-miner/mine-testnet-stacks-tokens.md
deleted file mode 100644
index c456ca0f70..0000000000
--- a/guides-and-tutorials/run-a-miner/mine-testnet-stacks-tokens.md
+++ /dev/null
@@ -1,314 +0,0 @@
-# Mine Testnet Stacks Tokens
-
-### Introduction
-
-For more on the technical details of mining, please review the mining guide.
-
-The following is an abridged version of the [walkthrough here](https://github.com/stacksfoundation/miner-docs/tree/testnet), written for a Linux system. If you're on Windows or MacOS, there will be some slight modifications needed (PR's welcome!).
-
-If you're interested in mining on the Stacks testnet, you can find instructions on how to do that here:
-
-### Running a Bitcoin Testnet Full Node
-
-To participate as a miner on testnet, you must have access to a testnet bitcoin node with a wallet (and the wallet's private key). One way to accomplish this is to run bitcoin locally.
-
-* [Ensure your computer meets the minimum hardware requirements before continuing.](https://bitcoin.org/en/bitcoin-core/features/requirements#system-requirements)
-
-First, download a [bitcoin binary](https://bitcoin.org/en/download), or [build from source](https://github.com/stacksfoundation/miner-docs/blob/testnet/bitcoin.md#source-install) (_there may be some extra requirements to building,_ [_defined here_](https://github.com/stacksfoundation/miner-docs/blob/testnet/prerequisites.md#install-required-packages)).
-
-{% hint style="info" %}
-**Tip:** It is recommended to use a persistent location for the chainstate, in the steps below we're using `/bitcoin`.
-{% endhint %}
-
-#### Update the Bitcoin Configuration File
-
-Next, update the bitcoin configuration:
-
-* **Optional, but recommended:** Use a persistent directory to store the Bitcoin chainstate, i.e. `datadir=/bitcoin`.
-* **Optional, but recommended:** Update the `rpcallowip` value to only allow `127.0.0.1`, or the stacks miner IPv4.
-* Modify the `rpcuser` and `rpcpassword` values from the defaults below.
-* Store the following configuration somewhere on your filesystem (ex: `$HOME/bitcoin.conf`).
-
-```toml
-server=1
-testnet=1
-disablewallet=0
-datadir=/bitcoin
-rpcuser=btcuser
-rpcpassword=btcpass
-rpcallowip=0.0.0.0/0
-dbcache=512
-banscore=1
-rpcthreads=256
-rpcworkqueue=256
-rpctimeout=100
-txindex=1
-
-[test]
-bind=0.0.0.0:18333
-rpcbind=0.0.0.0:18332
-rpcport=18332
-```
-
-#### Start Bitcoin
-
-Finally, start `bitcoind` as follows (adjust the `conf` path to where it was created in the previous step, i.e. `$HOME/bitcoin.conf`):
-
-```bash
-bitcoind -conf=$HOME/bitcoin.conf
-```
-
-{% hint style="info" %}
-**Note:** It will take a few hours for the node to synchronize with Bitcoin Testnet.
-{% endhint %}
-
-While it's syncing, you can track the progress with `bitcoin-cli` or the logfile (will be located where the chainstate is stored, i.e. `/bitcoin/testnet3/debug.log`):
-
-```bash
-$ bitcoin-cli \
- -rpcconnect=127.0.0.1 \
- -rpcport=18332 \
- -rpcuser=btcuser \
- -rpcpassword=btcpass \
-getblockchaininfo | jq .blocks
-2583513
-```
-
-***
-
-### Running a Stacks Blockchain miner
-
-First, download the latest tagged [stacks blockchain binary](https://github.com/stacks-network/stacks-blockchain/releases/latest), or [build from source](https://github.com/stacksfoundation/miner-docs/blob/testnet/stacks-blockchain.md#build-and-install-stacks-blockchain-from-source) (_there may be some extra requirements to building,_ [_defined here_](https://github.com/stacksfoundation/miner-docs/blob/testnet/prerequisites.md#install-required-packages)).
-
-{% hint style="info" %}
-**Tip:** It is recommended to use a persistent location for the chainstate, in the steps below we're using `/stacks-blockchain`.
-{% endhint %}
-
-#### Generate a keychain
-
-First, a keychain needs to be generated. With this keychain, we'll get some testnet BTC from a faucet, and then use that BTC to start mining.
-
-To create a keychain, the simplest way is to use the [stacks-cli](https://docs.hiro.so/references/stacks-cli) with the `make_keychain` command.
-
-```bash
-npx @stacks/cli make_keychain -t 2>/dev/null | jq -r
-```
-
-After this runs, you should see some JSON printed to the screen that looks like this:
-
-```json
-{
- "mnemonic": "spare decade dog ghost luxury churn flat lizard inch nephew nut drop huge divert mother soccer father zebra resist later twin vocal slender detail",
- "keyInfo": {
- "privateKey": "ooxeemeitar4ahw0ca8anu4thae7aephahshae1pahtae5oocahthahho4ahn7eici",
- "address": "STTXOG3AIHOHNAEH5AU6IEX9OOTOH8SEIWEI5IJ9",
- "btcAddress": "Ook6goo1Jee5ZuPualeiqu9RiN8wooshoo",
- "wif": "rohCie2ein2chaed9kaiyoo6zo1aeQu1yae4phooShov2oosh4ox",
- "index": 0
- }
-}
-```
-
-{% hint style="danger" %}
-**Do not lose this information** - we'll need to use the `privateKey`, `btcAddress` and `wif` fields in later steps.
-{% endhint %}
-
-The above `wif` (`cPdTdMgww2njhnekUZmHmFNKsWAjVdCR4cfvD2Y4UQhFzMmwoW33`) will then need to be imported into the bitcoin testnet network.
-
-Next, a bitcoin wallet is created:
-```bash
-bitcoin-cli \
- -rpcconnect=127.0.0.1 \
- -rpcport=18332 \
- -rpcuser=btcuser \
- -rpcpassword=btcpass \
- createwallet "miner" \
- false \
- false \
- "" \
- false \
- false \
- true
-```
-
-Now, import your wif (bitcoin private key) inside the newly created wallet.
-
-{% hint style="info" %}
-**Note:** Be sure to replace `` with the wif value in the `Generate a keychain` step.
-{% endhint %}
-
-```bash
-bitcoin-cli \
- -rpcport=18332 \
- -rpcuser=btcuser \
- -rpcpassword=btcpassword \
- importprivkey
-```
-
-{% hint style="info" %}
-**Note:** The import may take a while, because a wallet rescan is triggered. After the import has completed successfully, you can check that the address is imported with `getaddressinfo`.
-{% endhint %}
-```bash
-bitcoin-cli \
- -rpcconnect=127.0.0.1 \
- -rpcport=18332 \
- -rpcuser=btcuser \
- -rpcpassword=btcpass \
- getaddressinfo
-```
-
-Once imported, we need to get some testnet BTC to that address. Grab the `btcAddress` field, and paste it into [this Bitcoin testnet faucet](https://tbtc.bitaps.com/). You'll be sent `0.01` testnet BTC to that address.
-
-#### Update the Stacks Blockchain Configuration File
-
-Now, we need to configure our node to use this Bitcoin keychain. Copy the [sample testnet miner config](https://raw.githubusercontent.com/stacks-network/stacks-blockchain/master/testnet/stacks-node/conf/testnet-miner-conf.toml) to your local machine in a _memorable_ location like `$HOME/testnet-miner-conf.toml`.
-
-Next, update the stacks configuration:
-
-* **Optional, but recommended:** Use a persistent directory to store the Stacks chainstate, i.e. `working_dir = "/stacks-blockchain"`
-* From the `make_keychain` step, modify the `seed` value with `privatekey`
-* Store the following configuration somewhere on your filesystem (ex: `$HOME/testnet-miner-conf.toml`)
-
-```toml
-[node]
-working_dir = "/stacks-blockchain"
-rpc_bind = "0.0.0.0:20443"
-p2p_bind = "0.0.0.0:20444"
-seed = ""
-miner = true
-bootstrap_node = "029266faff4c8e0ca4f934f34996a96af481df94a89b0c9bd515f3536a95682ddc@seed.testnet.hiro.so:30444"
-mine_microblocks = false
-wait_time_for_microblocks = 10000
-
-[burnchain]
-wallet_name = "miner"
-chain = "bitcoin"
-mode = "xenon"
-peer_host = "127.0.0.1"
-username = ""
-password = ""
-rpc_port = 18332
-peer_port = 18333
-
-[[ustx_balance]]
-address = "ST2QKZ4FKHAH1NQKYKYAYZPY440FEPK7GZ1R5HBP2"
-amount = 10000000000000000
-
-[[ustx_balance]]
-address = "ST319CF5WV77KYR1H3GT0GZ7B8Q4AQPY42ETP1VPF"
-amount = 10000000000000000
-
-[[ustx_balance]]
-address = "ST221Z6TDTC5E0BYR2V624Q2ST6R0Q71T78WTAX6H"
-amount = 10000000000000000
-
-[[ustx_balance]]
-address = "ST2TFVBMRPS5SSNP98DQKQ5JNB2B6NZM91C4K3P7B"
-amount = 10000000000000000
-```
-
-#### Start the Stacks Blockchain
-
-To run your miner, run this in the command line:
-
-```bash
-stacks-node start --config $HOME/testnet-miner-conf.toml
-```
-
-Your node should start. It will take some time to sync, and then your miner will be running.
-
-#### Enable Debug Logging
-
-In case you are running into issues or would like to see verbose logging, you can run your node with debug logging enabled. In the command line, run:
-
-```bash
-STACKS_LOG_DEBUG=1 stacks-node start --config $HOME/testnet-miner-conf.toml
-```
-
-***
-
-### Optional: Running a Stacks Blockchain miner with Docker
-
-Alternatively, you can run a Stacks testnet miner with Docker.
-
-{% hint style="warning" %}
-Ensure you have [Docker](https://docs.docker.com/get-docker/) installed.
-{% endhint %}
-
-#### Generate a Keychain and Get Some Tokens
-
-Generate a keychain:
-
-```bash
-docker run -i node:20-alpine npx @stacks/cli make_keychain 2>/dev/null | jq -r
-```
-
-Now, we need to get some tBTC. Grab the `btcAddress` field, and paste it into [this Bitcoin testnet faucet](https://tbtc.bitaps.com/). You'll be sent `0.01` tBTC to that address.
-
-#### Update Stacks Blockchain Docker Configuration File
-
-Use the steps outlined above to create the configuration file.
-
-#### Start the Stacks Blockchain miner with Docker
-
-{% hint style="info" %}
-**Info:** The ENV VARS `RUST_BACKTRACE` and `STACKS_LOG_DEBUG` are optional. If removed, debug logs will be disabled.
-{% endhint %}
-
-```bash
-docker run -d \
- --name stacks_miner \
- --rm \
- --network host \
- -e RUST_BACKTRACE="full" \
- -e STACKS_LOG_DEBUG="1" \
- -v "$HOME/testnet-miner-conf.toml:/src/stacks-node/testnet-miner-conf.toml" \
- -v "/stacks-blockchain:/stacks-blockchain" \
- -p 20443:20443 \
- -p 20444:20444 \
- blockstack/stacks-blockchain:latest \
-/bin/stacks-node start --config /src/stacks-node/testnet-miner-conf.toml
-```
-
-You can review the node logs with this command:
-
-```bash
-docker logs -f stacks_miner
-```
-
-***
-
-### Optional: Running in Kubernetes with Helm
-
-In addition, you're also able to run a Stacks miner in a Kubernetes cluster using the [stacks-blockchain Helm chart](https://github.com/stacks-network/stacks-blockchain/tree/master/deployment/helm/stacks-blockchain).
-
-Ensure you have the following prerequisites installed:
-
-* [Docker](https://docs.docker.com/get-docker/)
-* [minikube](https://minikube.sigs.k8s.io/docs/start/) (Only needed if standing up a local Kubernetes cluster)
-* [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/)
-* [helm](https://helm.sh/docs/intro/install/)
-
-#### Generate keychain and get some tokens
-
-Use the steps outlined above
-
-#### Install the chart and run the miner
-
-To install the chart with the release name `my-release` and run the node as a miner:
-
-```bash
-minikube start # Only run this if standing up a local Kubernetes cluster
-helm repo add blockstack https://charts.blockstack.xyz
-helm install my-release blockstack/stacks-blockchain \
- --set config.node.miner=true \
- --set config.node.seed="privateKey-from-generate-keychain-step" \
-```
-
-You can review the node logs with this command:
-
-```bash
-kubectl logs -l app.kubernetes.io/name=stacks-blockchain
-```
-
-For more information on the Helm chart and configuration options, please refer to the [chart's homepage](https://github.com/stacks-network/stacks-blockchain/tree/master/deployment/helm/stacks-blockchain).
diff --git a/guides-and-tutorials/run-a-miner/miner-costs-and-fees.md b/guides-and-tutorials/run-a-miner/miner-costs-and-fees.md
deleted file mode 100644
index d948756e4b..0000000000
--- a/guides-and-tutorials/run-a-miner/miner-costs-and-fees.md
+++ /dev/null
@@ -1,22 +0,0 @@
-# Miner Costs and Fees
-
-### Configuring Cost and Fee Estimation
-
-Fee and cost estimators can be configured via the config section `[fee_estimation]`:
-
-```toml
-[fee_estimation]
-cost_estimator = naive_pessimistic
-fee_estimator = fuzzed_weighted_median_fee_rate
-fee_rate_fuzzer_fraction = 0.1
-fee_rate_window_size = 5
-cost_metric = proportion_dot_product
-log_error = true
-enabled = true
-```
-
-Fee and cost estimators observe transactions on the network and use the observed costs of those transactions to build estimates for viable fee rates and expected execution costs for transactions. Estimators and metrics can be selected using the configuration fields above, though the default values are the only options currently. `log_error` controls whether or not the INFO logger will display information about the cost estimator accuracy as new costs are observed. Setting `enabled = false` turns off the cost estimators. Cost estimators are **not** consensus-critical components, but rather can be used by miners to rank transactions in the mempool or client to determine appropriate fee rates for transactions before broadcasting them.
-
-The `fuzzed_weighted_median_fee_rate` uses a median estimate from a window of the fees paid in the last `fee_rate_window_size` blocks. Estimates are then randomly "fuzzed" using uniform random fuzz of size up to `fee_rate_fuzzer_fraction` of the base estimate.
-
-There is also a [mining calculator](https://friedger.github.io/mining-calculator/) that can help you with this process, with the [source code available here](https://github.com/friedger/mining-calculator).
diff --git a/guides-and-tutorials/run-a-miner/miner-prerequisites.md b/guides-and-tutorials/run-a-miner/miner-prerequisites.md
deleted file mode 100644
index 7058e44964..0000000000
--- a/guides-and-tutorials/run-a-miner/miner-prerequisites.md
+++ /dev/null
@@ -1,92 +0,0 @@
-# Miner Prerequisites
-
-## Prerequisites
-
-### VM setup
-
-The VM will not need a lot of resources to run a miner - the most resources will be consumed during the blockchain syncs (for both Bitcoin and Stacks). For this example, we'll be assuming a [**Debian**](https://www.debian.org/) host with `x86_64` architecture (_commands may also work on any Debian-derived distribution_)
-
-A single CPU system with at least 4GB of memory and 1TB of disk space should be considered the minimum required specs to run the miner.
-
-#### VM Specs
-
-* Minimum CPU of: `1 vCPU`
-* Minimum Memory of: `4GB Memory`
-* Minimum Storage of: `1TB Disk` to allow for chainstate growth
- * as of **July 2022**:
- * Bitcoin chainstate is roughly `420GB`
- * Stacks chainstate is roughly `45GB`
-
-**Disk Configuration**
-
-Two options here - either are fine but it's _recommended_ to mount the chainstate from a separate disk that only contains the chainstate (option 1)
-
-1. Separate disks for chainstate(s) and OS:
- * mount a dedicated disk for bitcoin at `/bitcoin` of 1TB
- * mount a dedicated disk for stacks-blockchain at `/stacks-blockchain` of at least 100GB
- * root volume `/` of at least 25GB
-2. Combined Disk for all data:
- * root volume `/` of at least 1TB
-
-Create the required directories:
-
-```bash
-$ sudo mkdir -p /bitcoin
-$ sudo mkdir -p /stacks-blockchain
-$ sudo mkdir -p /etc/bitcoin
-$ sudo mkdir -p /etc/stacks-blockchain
-```
-
-**If using mounted disks**: mount the disks to each filesystem created above - edit `/etc/fstab` to automount these disks at boot.
-
-Example:
-
-```
-/dev/xvdb1 /bitcoin xfs rw,relatime,attr2,inode64,noquota
-/dev/xvdc1 /stacks-blockchain xfs rw,relatime,attr2,inode64,noquota
-```
-
-Mount the disks `sudo mount -a`
-
-### Scripted install
-
-You can use the scripts/prerequisites.sh to install everything:
-
-```bash
-curl --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/stacksfoundation/miner-docs/main/scripts/prerequisites.sh | bash
-```
-
-### Install required packages
-
-The following packages are required, and used by the rest of these docs
-
-```bash
-$ curl -sL https://deb.nodesource.com/setup_16.x | sudo -E bash -
-$ sudo apt-get update -y && sudo apt-get install -y \
- build-essential \
- jq \
- netcat \
- nodejs \
- git \
- autoconf \
- libboost-system-dev \
- libboost-filesystem-dev \
- libboost-thread-dev \
- libboost-chrono-dev \
- libevent-dev \
- libzmq5 \
- libtool \
- m4 \
- automake \
- pkg-config \
- libtool \
- libboost-system-dev \
- libboost-filesystem-dev \
- libboost-chrono-dev \
- libboost-program-options-dev \
- libboost-test-dev \
- libboost-thread-dev \
- libboost-iostreams-dev
-$ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh && source $HOME/.cargo/env
-$ sudo npm install -g @stacks/cli rimraf shx
-```
diff --git a/guides-and-tutorials/run-a-miner/verify-miner.md b/guides-and-tutorials/run-a-miner/verify-miner.md
deleted file mode 100644
index 94e703a387..0000000000
--- a/guides-and-tutorials/run-a-miner/verify-miner.md
+++ /dev/null
@@ -1,18 +0,0 @@
-# Verify Miner
-
-## Verify Configuration
-You can verify that your node is operating as a miner by checking its log output to verify that it was able to find its Bitcoin UTXOs:
-
-```bash
-$ head -n 1000 /path/to/your/node/logs | grep -i utxo
-INFO [1630127492.031042] [testnet/stacks-node/src/run_loop/neon.rs:146] [main] Miner node: checking UTXOs at address:
-INFO [1630127492.062652] [testnet/stacks-node/src/run_loop/neon.rs:164] [main] UTXOs found - will run as a Miner node
-```
-
-## Verify Operations
-The first transaction of the miner is a registration transaction on Bitcoin. It just contains an `OP_RETURN` utxo.
-
-Thereafter, the miner creates for each block one transaction on Bitcoin with one date output, and two commit outputs to the stackers. The amount is half the value of the configured `burn_fee_cap` property.
-
-If the miner won a sortition, the corresponding Stacks address will create a tenure change transaction and a coinbase transaction. The block rewards will be awarded 100 blocks later if mining was successful.
-
diff --git a/guides-and-tutorials/running-a-signer/README.md b/guides-and-tutorials/running-a-signer/README.md
deleted file mode 100644
index 14a1ec5a0a..0000000000
--- a/guides-and-tutorials/running-a-signer/README.md
+++ /dev/null
@@ -1,365 +0,0 @@
-# Run a Signer
-
-### How to Use This Guide
-
-If you are not familiar with the concept of signing and stacking, and how they work together, be sure to check out the [Stackers and Signing concept guide](../../concepts/block-production/stackers-and-signing.md).
-
-This guide is a step-by-step walkthrough for actually setting up and running a signer. If you need to troubleshoot your signer setup, you can check out the Signer Troubleshooting section.
-
-If you need to Stack your STX, or have questions about how that process works, check out the Stack STX guide.
-
-### Background and High-Level Process
-
-In order to run a signer, you'll need to run a signer and a Stacks node side-by-side. Specifically, you'll want to run a follower node. Instructions for doing this are listed below in the "Running Your Stacks Node" section. The signer will monitor for events coming from the stacks node and is in charge of using the generated account (next section) to sign incoming Stacks blocks sent from the Stacks node.
-
-This doc will provide instructions on how to set up both using either Docker or using the release binaries available in the [stacks core](https://github.com/stacks-network/stacks-core/releases) repository.
-
-It will also walk through how to set up the config files to get the signer and Stacks node communicating correctly.
-
-### Knowledge Prerequisites
-
-* Docker and basic knowledge of pulling and running images
-* Basic knowledge of [Stacks accounts](../../concepts/network-fundamentals/accounts.md)
-* Basic knowledge of [stacking](../../concepts/block-production/stacking.md) and the [Stacking flow](../stack-stx/)
-
-
-
-Signer Checklist
-
-Detailed steps for each of these are laid out below, but this checklist is being included as a way to quickly reference if you have taken all the appropriate actions to run a signer.
-
-**Pre-Launch Setup**
-
-* [ ] Ensure your system meets the [minimum system requirements](./#minimum-system-requirements).
-* [ ] Acquire Docker and basic knowledge of Stacks accounts, stacking, and the Nakamoto stacking flow (links provided above).
-
-**Preflight Setup**
-
-* [ ] Generate a new private key using stacks-cli.
-* [ ] Save the generated account information securely.
-
-**Configuration Setup**
-
-* [ ] Create a `signer-config.toml` file with necessary configurations:
- * node\_host
- * endpoint
- * network
- * db\_path
- * auth\_password
- * stacks\_private\_key
-* [ ] Store `signer-config.toml` securely and note down the values used.
-
-**Running the Signer**
-
-* [ ] Decide whether to run the signer using Docker (recommended) or as a binary.
-* [ ] If using Docker:
- * [ ] Set up the necessary ports and volumes.
- * [ ] Run the Docker container with the appropriate settings.
-* [ ] If running as a binary:
- * [ ] Build `stacks-core` from source or download the pre-built binary.
- * [ ] Run the signer using the command: `stacks-signer run --config `.
-
-**Verify Signer Operation**
-
-* [ ] Check that the signer is listening on its configured endpoint.
-* [ ] Confirm that there are no errors and the system is ready for connections.
-
-**Setting Up the Stacks Node**
-
-* [ ] Create a `node-config.toml`, including the following necessary settings:
- * connection\_options.sauth\_token
- * events\_observer.endpoint (matching the signer configuration)
-* [ ] Decide whether to run the Stacks node using Docker or as a binary.
-* [ ] If using Docker:
- * [ ] Set up the Docker container with the correct ports and volumes.
- * [ ] Run the Stacks node Docker container.
-* [ ] If running as a binary:
- * [ ] Build `stacks-core` from source or download the pre-built binary.
- * [ ] Run it with the command: `./stacks-node start --config `.
-
-**Verify Stacks Node Operation**
-
-* [ ] Check the Stacks node logs for successful connection to the signer.
-* [ ] Confirm that the node is syncing Bitcoin headers properly.
-
-**Setup Stacks Accounts**
-
-* [ ] Set up a “pool operator” wallet in a Stacks wallet (e.g., Leather or Xverse).
-* [ ] Fund the pool operator wallet with sufficient STX for transaction fees.
-* [ ] Share the pool operator wallet’s STX address with delegating parties.
-* [ ] Fund your signer's STX wallet with enough STX to cover transaction fees (recommend at least 100-200 STX).
-
-
-
-### Minimum System Requirements
-
-These are the **minimum required specs** to be able to run a node and signer, but it is recommended to have more than the minimum for optimal performance.
-
-#### Signer, Stacks node and Bitcoin node
-
-* 4 vcpu
-* 8GB memory if running only a Stacks node and signer
-* 16GB memory if running Stacks + Bitcoin node + signer
-* 1.5+TB storage (1TB for Bitcoin node, 500GB for Stacks node, and 50 GB for signer)
-
-### Preflight Setup
-
-Before you get your signer set up, you'll need to [generate a new private key](https://docs.stacks.co/stacks-101/accounts#creation). The `stacks-cli` provides a mechanism for quickly generating a new account keychain via a simple CLI interface. The linked guide will show you how to create one of those accounts on testnet.
-
-Once you follow the instructions linked above, be sure to save the information in a secure location, you'll need it in a future step.
-
-{% hint style="info" %}
-**What should the networking setup look like?**
-
-Signers are intended to work with a local node. The node<->signer connection is not run over SSL, which means you can be exposed to a man-in-the-middle attack if your signer and node are hosted on separate machines. Be sure you are aware of your networking setup, especially making sure your signer isn't allowing requests from the public internet. We recommend setting up your infrastructure to either have the signer and node running locally on the same machine or use only internal networking between them.
-{% endhint %}
-
-### Create a Configuration File
-
-Create a new file called `signer-config.toml`. In that file, put the contents from the example signer config file from the [Sample Configuration Files](../../reference/sample-configuration-files.md) page. Each field is described on that page.
-
-### Running the Signer
-
-There are two options for running the signer: Docker and running with a binary. The recommended option is to use Docker. If you want to run as a binary, you will need to either build `stacks-core` from source, or download a signer release binary from the [stacks core releases page](https://github.com/stacks-network/stacks-core/releases). Instructions for how to do this are contained below in the relevant section.
-
-#### Running the Signer with Docker
-
-You can run the signer as a Docker container using the [`blockstack/stacks-signer:3.1.0.0.5.0`](https://hub.docker.com/layers/blockstack/stacks-signer/3.1.0.0.5.0/images/sha256-4f0c19225065754ed08594deb3d2c67dc1126558e9e50f8174a1bc1736fedb99) image.
-
-When running the Docker container, you’ll need to ensure a few things:
-
-* The port configured as the `endpoint` (in the above linked example, “30000”) must be exposed to your Stacks node. Note that this endpoint should not be public, but must be exposed to your Stacks node.
-* You’ll need a volume with at least a few GB of available storage that contains the folder your `db_path` is in. In the above example, that would be `/var`.
-* You’ll need to mount your `signer-config.toml` file as a volume, noted below with the first `-v` flag.
-
-An example command for running the Docker image with `docker run` is shown below.
-
-Be sure to replace the `STX_SIGNER_PATH` with the correct path to your config file and where you want to install and run the signer. In this example it will be done in the current directory.
-
-```bash
-IMG="blockstack/stacks-signer"
-VER="3.1.0.0.5.0"
-STX_SIGNER_PATH="./"
-STX_SIGNER_DATA="$STX_SIGNER_PATH/data"
-STX_SIGNER_CONFIG="$STX_SIGNER_PATH/signer-config.toml"
-
-docker run -d \
- -v $STX_SIGNER_CONFIG:/config.toml \
- -v $STX_SIGNER_DATA:/var/stacks \
- -p 30000:30000 \
- -e RUST_BACKTRACE=full \
- -e BLOCKSTACK_DEBUG=0 \
- --name stacks-signer \
- $IMG:$VER \
- stacks-signer run \
- --config /config.toml
-```
-
-{% hint style="info" %}
-If you get an error saying that the manifest cannot be found or about the requested image platform not matching the host platform, you are probably running on system architecture other than x64 arch. Since you are using a PR release you'll need to specify your platform with the `--platform` flag.
-
-For example, if you are running on M1 Mac, you would add `--platform=linux/amd64` to the above command.
-{% endhint %}
-
-Or, with a custom Dockerfile:
-
-```docker
-FROM blockstack/stacks-signer:3.1.0.0.5.0
-COPY signer-config.toml /config.toml
-EXPOSE 30000
-CMD ["stacks-signer", "run", "--config", "/config.toml"]
-```
-
-#### Running the Signer as a Binary
-
-If you do not want to use Docker, you can alternatively run your stacks node as a binary.
-
-Official binaries are available from the [Stacks Core releases page on Github](https://github.com/stacks-network/stacks-core/releases). Each release includes pre-built binaries. Download the ZIP file for your server’s architecture and decompress it. Inside of that folder is a `stacks-signer` binary.
-
-You can run the signer with the following command (be sure to replace `../signer-config.toml` with the actual path of your config file).
-
-```bash
-stacks-signer run --config ../signer-config.toml
-```
-
-#### Verify the Signer is Running
-
-To make sure your signer is running successfully, run `docker ps` to list your running containers.
-
-You should see something like this
-
-
-
-Now check the logs of that container by running:
-
-```bash
-docker logs 877d478dfe7f
-```
-
-Be sure to replace the container ID at the end with your actual container ID.
-
-You should see a message that says `Signer spawned successfully. Waiting for messages to process...`.
-
-You may also see a message indicating that your signer is not registered, like this:
-
-```
-WARN [1712003997.160121] [stacks-signer/src/runloop.rs:247] [signer_runloop] Signer is not registered for reward cycle 556. Waiting for confirmed registration...
-```
-
-This means your signer is running successfully. Your next step is to begin stacking in order to get your signer registered. First, if you haven't yet, get your Stacks node up and running following the instructions below and then proceed to [How to Stack](../stack-stx/stacking-flow.md) to get started stacking.
-
-{% hint style="warning" %}
-Even after you Stack, you may still see a message that says:
-
-```
-Signer is not registered for the current reward cycle (557) or next reward cycle (558). Waiting for confirmed registration...
-```
-
-This is normal and means that you have stacked, but have not yet reach the prepare phase for your chosen reward cycle. Assuming you have met the stacking minimum, your signer will be picked up and registered during this prepare phase.
-{% endhint %}
-
-### Set Up Your Bitcoin Node
-
-While optional, we strongly recommend running your own Bitcoin node in order to optimize signer health and performance.
-
-We have created guides for running both a [full Bitcoin node](https://docs.stacks.co/guides-and-tutorials/nodes-and-miners/run-a-bitcoin-node) and a [pruned Bitcoin node](https://docs.stacks.co/guides-and-tutorials/nodes-and-miners/run-a-pruned-bitcoin-node) you can follow.
-
-### Set Up Your Stacks Node
-
-Once your signer is running, the next step is to set up and run a Stacks node. It’s important to have the signer already running, because the node will not run unless it is able to send events to the signer.
-
-#### Stacks Node Configuration
-
-Create a file called `node-config.toml`. On the [Sample Configuration Files](../../reference/sample-configuration-files.md) page you'll find the full configuration file contents you'll need to add to this file.
-
-The important aspects that you’ll need to change are:
-
-* `working_dir`: a directory path where the node will persist data
-* `auth_token`: an authentication token that your signer uses to authenticate certain requests to your node. This must match the value you used as `auth_password` in the signer’s configuration.
-* `events_observer.endpoint`: This is the host (IP address and port) where your signer is configured to listen for events. An example string would be ”`127.0.0.1:30000`” or ”`stacks-signer.local:30000`”
-
-#### Start with an archive
-
-It will be much faster to start with an archive of the chain state rather than syncing from genesis.
-
-Archives can be found at [https://archive.hiro.so](https://archive.hiro.so). For the Stacks node mainnet, the latest snapshot can be found at [https://archive.hiro.so/mainnet/stacks-blockchain/mainnet-stacks-blockchain-latest.tar.gz](https://archive.hiro.so/mainnet/stacks-blockchain/mainnet-stacks-blockchain-latest.tar.gz). You can also [browse all mainnet snapshots](https://archive.hiro.so/mainnet/stacks-blockchain/).
-
-You’ll want to download this on the same machine that will run the Stacks node. One way to do this is:
-
-```
-curl -# https://archive.hiro.so/mainnet/stacks-blockchain/mainnet-stacks-blockchain-latest.tar.gz -o stacks-snapshot.tar.gz
-tar -zxvf stacks-snapshot.tar.gz
-```
-
-This will decompress the snapshot and create a `mainnet` folder in the same place that you downloaded the archive.
-
-For the Stacks node to use this archive, you must specify `working_dir` in your config file to be the place where you can find the `mainnet` folder.
-
-For example:
-
-* The snapshot is available at /Users/blah/mainnet
-* You will set working\_dir to equal ”/Users/blah”
- * Note that the string does not include the `mainnet` part
-
-**Warning:** It is always better to keep a local snapshot of the chain state for fast recovery and redundancy. This ensures you can quickly restore your node in case of data loss or corruption.
-
-See [here](../best-practices-to-snapshot-the-chainstate.md) for additional best practices to create a local chainstate snapshot.
-{% endhint %}
-
-#### Run a Stacks Node with Docker
-
-You can run the Stacks node as a Docker container using the `blockstack/stacks-core` image, currently on [version 3.1.0.0.13](https://hub.docker.com/layers/blockstack/stacks-core/3.1.0.0.13/images/sha256:2f87331740c3afbe69b6e9bd572ebe991c95191731a9e135de66084871c1f2ad). When running the Docker container, you’ll need to ensure a few things:
-
-* The port configured for `p2p_bind` must be exposed to the internet
-* The port configured for `rpc_bind` must be accessible by your signer
-* `working_dir` needs to be on a volume with 500GB-1TB of available storage
-* You’ll need to include your `node-config.toml` file
-
-An example for running the node’s Docker image with docker run is below. Be sure to run this from the same directory as your `node-config.toml` file or change the `STX_NODE_CONFIG` option.
-
-```bash
-IMG="blockstack/stacks-core"
-VER="3.1.0.0.13"
-STX_NODE_CONFIG="./node-config.toml"
-
-docker run -d \
- -v $STX_NODE_CONFIG:/config.toml \
- -v /var/stacks \
- -p 20443:20443 \
- -p 20444:20444 \
- -e RUST_BACKTRACE=full \
- --name stacks-node \
- $IMG:$VER \
- stacks-node start \
- --config /config.toml
-```
-
-Or, using a custom Dockerfile:
-
-```docker
-FROM blockstack/stacks-core:3.1.0.0.13
-COPY node-config.toml /config.toml
-EXPOSE 20444
-EXPOSE 20443
-CMD ["stacks-node", "start", "--config", "/config.toml"]
-```
-
-If when running your node you get a connection refused error that looks like this, you may need to point your `event_observer`'s `endpoint` field to the Docker signer container.
-
-First, be sure that you have the proper entry point specified in your `node-config.toml` file.
-
-
-
-If you are inside a Docker container with default bridging mode, then localhost is not available, and you'll need to point to the Docker host.
-
-#### Run a Stacks Node with a Binary
-
-If you do not want to use Docker, you can alternatively run your stacks node as a binary.
-
-Official binaries are available from the [Stacks Core releases page on Github](https://github.com/stacks-network/stacks-core/releases). Each release includes pre-built binaries. Download the ZIP file for your server’s architecture and decompress it. Inside of that folder is a `stacks-node` binary.
-
-You can start the binary with the following command (be sure to replace node-config.toml with the actual path of your config file):
-
-```bash
-./stacks-node start --config node-config.toml
-```
-
-#### Verify Stacks Node is Running
-
-Once you’ve started the Stacks node, you’ll see logs that start like this:
-
-```bash
-Mar 6 19:35:08.212848 INFO stacks-node 0.1.0
-Mar 6 19:35:08.213084 INFO Loading config at path ./Stacks-config.toml
-Mar 6 19:35:08.216674 INFO Registering event observer at: localhost:30000
-Mar 6 19:35:08.221603 INFO Migrating sortition DB to the latest schema version
-Mar 6 19:35:08.224082 INFO Migrating chainstate DB to the latest schema version
-Mar 6 19:35:08.227404 INFO Start syncing Bitcoin headers, feel free to grab a cup of coffee, this can take a while
-```
-
-It’s important to ensure that you see the log message `Registering event observer at XXX` with your signer’s endpoint included. Once Bitcoin headers have been synced, you may also be able to send a GET request to `/v2/info` on your Stacks node’s RPC endpoint (port 20443 by default).
-
-You may see a lot of messages while the node is syncing with Bitcoin blocks. You can check the [How to Read the Signer Logs](how-to-read-signer-logs.md) section if any of these concern you, but in all likelihood you can ignore any messages until Bitcoin blocks are synced.
-
-### Setup Your Stacks Accounts
-
-{% hint style="info" %}
-For more information on the relationship between stacking and signing and how stacking works, check out the [Stack STX](../stack-stx/) guide.
-{% endhint %}
-
-As a signer you’ll need to fund and manage two Stacks accounts:
-
-1. A “pool operator” wallet, which commits delegated STX to your signer
-2. Your signer’s wallet
-
-{% hint style="warning" %}
-For testing, make sure that you are using testnet, and not mainnet STX. You can change network settings within your wallet, and testnet STX can be [requested from a faucet](https://explorer.hiro.so/sandbox/faucet?chain=testnet).
-{% endhint %}
-
-#### Setup Your Pool Operator Wallet
-
-You can set up your pool operator wallet using any Stacks wallet, such as [Leather](https://leather.io) or [Xverse](https://www.xverse.app). You may choose to generate a new account or use an existing one. If you prefer to use a hardware wallet, Leather has support for the Ledger hardware wallet.
-
-Once your wallet has been created, you’ll need to fund it with enough STX to cover transaction fees. For testnet, you can use a [faucet exposed by the Stacks Explorer](https://explorer.hiro.so/sandbox/faucet?chain=testnet).
-
-Finally, share this wallet’s STX address with the parties that will be delegating STX to you. For improved user experience, you might want to use the helper contract that allows to specify a btc address for stackers ([pox4-pools](https://explorer.hiro.so/txid/SP001SFSMC2ZY76PD4M68P3WGX154XCH7NE3TYMX.pox4-pools?chain=mainnet)) and to add your pool to [earn.leather.io](https://earn.leather.io).
diff --git a/guides-and-tutorials/running-a-signer/best-practices-to-run-a-signer.md b/guides-and-tutorials/running-a-signer/best-practices-to-run-a-signer.md
deleted file mode 100644
index dc2493cd45..0000000000
--- a/guides-and-tutorials/running-a-signer/best-practices-to-run-a-signer.md
+++ /dev/null
@@ -1,67 +0,0 @@
-# Best practices for running a Signer
-
-{% hint style="info" %}
-**Intended audience**: solo Stackers or Stacking pool operators.
-{% endhint %}
-
-The following best practices suggest how to create a resilient setup for running your Signer.
-
-{% hint style="info" %}
-tl;dr: avoid single point of failures, introduce redundancy, monitor things.
-{% endhint %}
-
-### Monitor your Signer and collect logs
-
-* See [here](how-to-monitor-signer.md) on how to set up monitoring.
-* Retain at least 1 week of logs for both the Signer and the Stacks node.
-
-### Downstream components
-
-* Run a _dedicated_ Bitcoin node and Stacks node per Signer.
- * Ensure the nodes are provisioned with the minimum hardware requirements described [here](https://docs.stacks.co/guides-and-tutorials/running-a-signer#minimum-system-requirements).
- * Nodes should be _exclusively dedicated_ to serve the Signer. Avoid re-using them to serve other clients as that may negatively affect performance (no _mock-signing_, no _Stacks API nodes_).
-* If running dedicated nodes is not possible, then ensure that the Bitcoin / Stacks nodes do not become single point of failures for _multiple_ signers depending on them.
- * Introduce redundancy, load balancing, rely on a robust Bitcoin RPC provider, etc.
-
-### Split voting power across multiple Signers
-
-* Distribute your voting power across multiple, distinct Signer public keys to mitigate the risk of loss or downtime from a single compromised key.
-* Each Signer should also limit voting power to a maximum amount and invite Stackers to use a different Signer when the limit is reached.
-
-### Monitor new software releases
-
-* Stay up-to-date with new releases, patches, and security advisories (e.g., GitHub, mailing lists, Discord).
-* Apply updates as quickly as possible, especially those addressing a security vulnerability.
-
-### Upgrade procedures
-
-* Upgrading one Signer instance at the time.
-* Test the update on one instance and, if successful, proceed to the others.
-* While your Signer is offline for upgrades, it won't sign any blocks. Ensure that the downtime is as short as possible.
-
-### Diversified hosting
-
-* Use different provider / configuration where feasible (e.g., a self-hosted instance and one in the cloud, or in two different data center regions, etc.).
-* Ensure each host has redundant power supply and network connectivity.
-
-### Fall-back deployments
-
-* Deploy additional Stacks nodes and Bitcoin nodes to be used as fall-back.
- * Use the same configuration as your _active_ instances.
- * For the Stacks node, comment out the `event_observer` section.
-* Prepare a backup Signer (same configuration) to be quickly activated, but _do not run it_.
- * At all times, there should be _exactly_ one Signer instance running for each Signer private key.
-* These instances should be hosted on separate physical hosts (see _diversified hosting_) from the instances usually active in operations (serving each Signer).
-* If an active instance (e.g., the Signer, the Stacks node or the Bitcoin node) fails, you can quickly switch to the fall-back configuration to continue operations. To do that:
- * Run the backup Signer.
- * Enable the `event_observer` section of the Node configuration.
- * Restart the node.
-
-### Redundancy in operations
-
-* Ensure that multiple, trusted users can manage and maintain signer instances.
-* Where feasible, users should span different timezones.
-
-### Backup signer keys in cold-storage
-
-* Keep an offline, secure backup of all Signer private keys (e.g., hardware security modules or encrypted storage devices).
diff --git a/guides-and-tutorials/running-a-signer/how-to-monitor-signer.md b/guides-and-tutorials/running-a-signer/how-to-monitor-signer.md
deleted file mode 100644
index 26eb99e91d..0000000000
--- a/guides-and-tutorials/running-a-signer/how-to-monitor-signer.md
+++ /dev/null
@@ -1,238 +0,0 @@
-# How to Monitor a Signer
-
-We will use [Grafana Cloud](https://grafana.com) to observe and monitor both the
-Signer and its corresponding Stacks node.
-
-## Requirements
-
-Grafana's application observability docs have a [great
-quick-start](https://grafana.com/docs/grafana-cloud/monitor-applications/application-observability/). We will use:
-
-- Grafana Cloud to collect metrics and visualize them.
-- Grafana Alloy, on the Signer host, to push the metrics.
-
-### Creating a Grafana Cloud account
-
-Before we begin, create a [Grafana
-Cloud](https://grafana.com/docs/grafana-cloud/monitor-applications/application-observability/grafana-cloud/) account (they offer a free tier that you can use).
-
-Once done, access your dashboard and:
-
-1. Click on "Connections", then
-2. "Add new connection", and
-3. select "Hosted Prometheus metrics".
-4. Now select "Via Grafana Alloy", then
-5. On step 2, select "Run Grafana Alloy" to generate an API token.
-
-Note the token `GCLOUD_RW_API_KEY` and the parameters `GCLOUD_HOSTED_METRICS_URL`
-and `GCLOUD_HOSTED_METRICS_ID`, we will use them later.
-
-### Configuring the Signer and the Stacks node
-
-Ensure both your Signer configuration and your node configuration include the
-following lines:
-
-```toml
-# signer-config.toml
-# ...
-# Adjust to 0.0.0.0:30001 if running in Docker.
-metrics_endpoint = "127.0.0.1:30001"
-```
-
-```toml
-# node-config.toml
-[node]
-# ...
-# Adjust to 0.0.0.0:9153 if running in Docker.
-prometheus_bind = "127.0.0.1:9153"
-```
-
-The pre-compiled binaries already include the monitoring feature. However, if you are compiling the application binaries yourself, remember to enable the Cargo feature `monitoring_prom` while building them, for example:
-
-```bash
-cargo build --features monitoring_prom,slog_json --release
-```
-
-Once both binaries are running with the updated configuration, you can peek
-at the metrics being exposed:
-
-```bash
-curl 127.0.0.1:30001/metrics
-
-# HELP stacks_signer_current_reward_cycle The current reward cycle
-# TYPE stacks_signer_current_reward_cycle gauge
-stacks_signer_current_reward_cycle 95
-# HELP stacks_signer_node_rpc_call_latencies_histogram Time (seconds) measuring round-trip RPC call latency to the Stacks node
-# TYPE stacks_signer_node_rpc_call_latencies_histogram histogram
-...
-stacks_signer_node_rpc_call_latencies_histogram_bucket{path="/v2/info",le="0.005"} 0
-stacks_signer_node_rpc_call_latencies_histogram_bucket{path="/v2/info",le="0.01"} 0
-stacks_signer_node_rpc_call_latencies_histogram_bucket{path="/v2/info",le="0.025"} 0
-stacks_signer_node_rpc_call_latencies_histogram_bucket{path="/v2/info",le="0.05"} 985
-stacks_signer_node_rpc_call_latencies_histogram_bucket{path="/v2/info",le="0.1"} 1194
-...
-```
-
-Also, you'll have a `/info` endpoint on the same port:
-
-```bash
-curl 127.0.0.1:30001/info
-```
-
-### Install Alloy
-
-Follow these instructions to install [Grafana
-Alloy](https://grafana.com/docs/alloy/latest/set-up/install/linux/).
-
-On Debian-based distributions:
-
-```bash
-sudo apt install gpg
-sudo mkdir -p /etc/apt/keyrings/
-wget -q -O - https://apt.grafana.com/gpg.key | gpg --dearmor | sudo tee /etc/apt/keyrings/grafana.gpg > /dev/null
-echo "deb [signed-by=/etc/apt/keyrings/grafana.gpg] https://apt.grafana.com stable main" | sudo tee /etc/apt/sources.list.d/grafana.list
-sudo apt-get update
-sudo apt-get install alloy
-```
-
-### Configure Alloy
-
-Edit the file `/etc/alloy/config.alloy` as follows, by taking care of replacing
-the placeholders related to the `prometheus` endpoint with the parameters
-obtained when creating a [Grafana Cloud account before](#creating-a-grafana-cloud-account):
-
-- `GCLOUD_HOSTED_METRICS_URL`
-- `GCLOUD_HOSTED_METRICS_ID`
-- `GCLOUD_RW_API_KEY`
-
-```conf
-// For a full configuration reference, see https://grafana.com/docs/alloy
-// For a default configuration, integrating all environmental variables from Grafana Cloud
-// see https://storage.googleapis.com/cloud-onboarding/alloy/config/config.alloy
-
-logging {
- level = "warn"
-}
-
-prometheus.exporter.unix "default" {
- include_exporter_metrics = true
- disable_collectors = ["mdadm"]
-}
-
-prometheus.scrape "default" {
- targets = array.concat(
- prometheus.exporter.unix.default.targets,
- [
- {
- // Self-collect metrics
- job = "alloy",
- __address__ = "127.0.0.1:12345",
- },
- {
- // stacks-signer
- job = "stacks-signer",
- __address__ = "127.0.0.1:30001",
- },
- {
- // stacks-node
- job = "stacks-node",
- __address__ = "127.0.0.1:9153",
- },
- ],
- )
-
- forward_to = [prometheus.remote_write.metrics_service.receiver]
-}
-
-prometheus.remote_write "metrics_service" {
- external_labels = {"instance" = constants.hostname}
- endpoint {
- # TODO: Edit the URL below with your Grafana production URL.
- # should end with /api/prom/push
- url = ""
-
- # TODO: Edit with your Grafana Cloud ID and Token
- basic_auth {
- username = ""
- password = ""
- }
- }
-}
-```
-
-```bash
-sudo systemctl daemon-reload
-sudo systemctl enable alloy.service
-sudo systemctl start alloy.service
-```
-
-Metrics from your Signer and node will now start being pushed to Grafana Cloud.
-
-## Visualizing the metrics
-
-You can now start building a dashboard to visualize the metrics.
-
-1. Log-in to Grafana Cloud and create a new Dashboard.
-2. Pick the Prometheus instance you created before as the data source.
-3. Create a new panel and pick `stacks_signer_current_reward_cycle` from the
- metrics.
-
-You should now be able to see Stacks' current reward cycle, as measured by the
-Signer, into the dashboard.
-
-Grafana comes with powerful data visualization tools. You can read about how to
-query and transform data
-[here](https://grafana.com/docs/grafana-cloud/visualizations/panels-visualizations/query-transform-data/),
-while here you will find examples on how to build
-[Prometheus queries](https://prometheus.io/docs/prometheus/latest/querying/basics/).
-
-[This template](https://grafana.com/grafana/dashboards/22137-stacks-signer-template/)
-will kick-start your dashboard.
-
-.
-
-## Bonus: monitoring the host
-
-Since we are here, we can also monitor the host itself. Debian-based
-distributions make it very easy for us by using
-[`node_exporter`](https://github.com/prometheus/node_exporter/tree/master).
-
-```bash
-sudo apt install prometheus-node-exporter
-sudo systemctl enable prometheus-node-exporter
-sudo systemctl start prometheus-node-exporter
-```
-
-This will expose metrics on port `9100` of `localhost`.
-
-We can now configure `alloy` to push them to Grafana. Edit your
-`/etc/alloy/config.alloy` file and add the following:
-
-```txt
-prometheus.scrape "default" {
- targets = array.concat([
-
- ...
-
- {
- job = "node_exporter",
- __address__ = "127.0.0.1:9100",
- }
-
- ...
-])}
-```
-
-Now reload `alloy` and check its status:
-
-```bash
-sudo systemctl reload alloy
-sudo systemctl status alloy
-```
-
-`node_exporter` provides a _lot_ of metrics. Poke at them through the Grafana
-Explorer or use one of the many prepared dashboard (e.g., [this
-one](https://grafana.com/grafana/dashboards/1860-node-exporter-full/)) to see
-comprehensive information. Once you have a dashboard ready, you can also
-use it to configure a few alerts (e.g., on disk space, etc).
diff --git a/guides-and-tutorials/running-a-signer/how-to-read-signer-logs.md b/guides-and-tutorials/running-a-signer/how-to-read-signer-logs.md
deleted file mode 100644
index d106e2c1c7..0000000000
--- a/guides-and-tutorials/running-a-signer/how-to-read-signer-logs.md
+++ /dev/null
@@ -1,49 +0,0 @@
-# How to Read Signer Logs
-
-There are a lot of different messages you can get in the logs when running a signer, getting a good grasp on what some of these logs mean can help you troubleshoot effectively and determine if your signer is running successfully or not.
-
-There are really three types of log messages we should be aware of:
-
-* Successful
-* Informational
-* Errors
-
-Successful log messages indicate that you are on track and everything is working as expected. However, there are various success stages depending on several factors including your stacking status and the timing of where we are in the current reward cycle.
-
-There are also several information/warning logs that you don't necessarily need to take action on, but may be informational about the status of something occurring in the network.
-
-Finally, error logs indicate something has gone wrong and you need to take some kind of action.
-
-Let's go through some of the common log messages you might see, what they mean, and what action to take.
-
-### Successful
-
-#### Signer uninitialized or not registered
-
-If you get a message like the following, saying that your signer is uninitialized, it means that your signer is not registered for the current or upcoming reward cycle (or the burnchain block height is not yet at the second block in the prepare phase) for the signer to know if it is registered. Your signer is running successfully, there is just another action you need to take.
-
-`Signer spawned successfully. Waiting for messages to process... INFO [1711088054.872542] [stacks-signer/src/runloop.rs:278] [signer_runloop] Running one pass for signer ID# 0. Current state: Uninitialized`
-
-This warning may also look like this:
-
-```
-WARN [1712003997.160121] [stacks-signer/src/runloop.rs:247] [signer_runloop] Signer is not registered for reward cycle 556. Waiting for confirmed registration...
-```
-
-At this point if you want your signer to do something you need someone to either delegate or you need to stack on your own for an upcoming reward cycle.
-
-For more on this, be sure to check out the [How to Stack](../stack-stx/stacking-flow.md) doc.
-
-### Informational
-
-#### Peer not connecting
-
-If you get an error about a peer not connecting that looks like the following:
-
-```
-INFO [1711988555.021567] [stackslib/src/net/neighbors/walk.rs:1015] [p2p-(0.0.0.0:20444,0.0.0.0:20443)] local.80000000://(bind=0.0.0.0:20444)(pub=Some(10.0.19.16:20444)): Failed to connect to facade0b+80000000://172.16.60.18:20444: PeerNotConnected
-```
-
-That means that your node is trying to connect to some external node on the network, but is unable to. This is common and can happen for a variety of reasons.
-
-It is not a cause for concern and doesn't impact whether or not your signer is running correctly.
diff --git a/guides-and-tutorials/running-a-signer/opsec-best-practices.md b/guides-and-tutorials/running-a-signer/opsec-best-practices.md
deleted file mode 100644
index 6293f0da82..0000000000
--- a/guides-and-tutorials/running-a-signer/opsec-best-practices.md
+++ /dev/null
@@ -1,75 +0,0 @@
-# OpSec Best Practices
-
-#### **Threat Modeling**
-
-A threat actor that is able to compromise > 70% of Signers (by stake weight) would be able to successfully propose Stacks blocks that would otherwise be considered invalid.
-
-Some potential vectors for signer key compromise are as follows:
-
-1. stacks-signer node is compromised and key is exfiltrated from the filesystem
-2. Signer key is compromised during generation or deployment
-3. Signer key is accidentally checked into SCM (eg Github or Gitlab)
-4. Social engineering attack against Signer community: eg a malicious link is posted to social media that harvests key material
-5. An undisclosed backdoor is discovered in the Signer binary.
-6. Supply chain attack against stacks-signer source code: threat actor compromises upstream dependencies of stacks-signer
-
-#### **Countermeasures**
-
-What can Signers do to mitigate the threat vectors identified above? Let's identify countermeasures in response to each of the threats identified above, starting with #1.
-
-#### **1. Stacks-signer node is compromised and key is exfiltrated from the filesystem**
-
-An obvious attack vector is a direct attack on the system running the stacks-signer software. Presently, the stacks-signer depends on a signing key that is both loaded into memory, and resident on the filesystem in cleartext. Thus a system or process level intrusion on the stacks-signer node will likely lead to compromise of the signing key.
-
-**Some countermeasures that can help mitigate this vector include:**
-
-1. **Run the stacks-signer on a separate system from the stacks-node.** This is important, as the IP addresses of systems running the stacks-signer cannot be trivially enumerated, but the same is not true for systems running stacks-node, due to the fact that stacks-node systems participate in the peer to peer network. If an attacker can't find your stacks-signer, they can't attack it (directly). It’s best practice to ensure that the stacks-node and stacks-signer communicate only over trusted networks, ideally using localhost (127.0.0.1) or a secure private subnet. While running the stacks-signer on a separate system is an option, it’s not necessary for security. Instead, running both on the same virtual machine within a private network, with traffic firewalled to allow only incoming peer-to-peer (P2P) connections (port 20444), provides a secure and easier setup. This minimizes the risk of exposure to attacks while avoiding the complexity of managing multiple systems.
-2. **Run the stacks-signer as a separate user from the stacks-node**. This is helpful in situations where due to resource constraints, it's not possible to separate the stacks-signer and stacks-node deployments onto separate workloads. Run the stacks-signer as a separate user from the stacks-node to enhance security, especially when resource constraints prevent deploying them on separate systems. The key here is ensuring that each user has exclusive ownership and access to its respective configuration files. For example, the user running the signer binary (e.g., signer) should own the signer’s config file, with permissions set restrictively to prevent other users from reading it. The same principle applies to the stacks-node user. This setup ensures that only the appropriate processes can access sensitive configuration details.
-3. **Harden the systemd configuration for the stacks-signer.** Hardening systemd can help mitigate the blast radius from an attack that successfully gets control of the stacks-signer process. An example stacks-signer.service systemd unit is below. Specifically, this systemd unit prevents certain filesystem writes (which can prevent an attacker from gaining persistence). Read more about [systemd hardening](https://www.ctrl.blog/entry/systemd-service-hardening.html).
-
-```
-[Unit]
-Description=Stacks Signer
-After=network.target
-StartLimitBurst=3
-StartLimitIntervalSec=300
-ConditionFileIsExecutable=/usr/local/bin/stacks-signer
-ConditionPathExists=/etc/stacks/signer
-ConditionFileNotEmpty=/etc/stacks/signer/signer-config.toml
-
-[Service]
-ExecStart=/usr/local/bin/stacks-signer run --config /home/etc/stacks/signer/signer-config.toml
-User={{ svc_user }}
-Group={{ svc_user }}
-Type=simple
-Restart=on-failure
-TimeoutStopSec=600
-KillSignal=SIGTERM
-#KillSignal=SIGINT
-# Provide a private /tmp and /var/tmp.
-PrivateTmp=true
-# Mount /usr, /boot/ and /etc read-only for the process.
-ProtectSystem=full
-# Deny access to /home, /root and /run/user
-ProtectHome=true
-# Disallow the process and all of its children to gain
-# new privileges through execve().
-NoNewPrivileges=true
-# Use a new /dev namespace only populated with API pseudo devices
-# such as /dev/null, /dev/zero and /dev/random.
-PrivateDevices=true
-
-[Install]
-WantedBy=multi-user.target
-```
-
-1. **Restrict access to unnecessary ports and protocols.** The stacks-signer requires _outbound_ TCP access to the stacks-node, but no other communications (except for what may be necessary to update the underlying OS).
-2. Harden the operating system. This is a broad topic, but the basics are:
- 1. Run stacks-signer as an unprivileged user (not root)
- 2. Set permissions on the stacks-signer key to be readable only by the user running the stacks-signer process, eg `sudo chmod 600 signer/signer-config.toml`
- 3. Require public-key authentication for remote SSH to the system running the stacks-signer and disable ssh root login.
- 4. Run sshd on a non-standard port to reduce noise from port scanners and credential stuffing attacks
-
-This post outlines essential operational security best practices for Stacks Signers, key actors in the Nakamoto architecture.
-
-By implementing these strategies, signer operators can effectively mitigate risks and maintain the security and reliability of the Stacks network.
diff --git a/guides-and-tutorials/running-a-signer/signer-quickstart.md b/guides-and-tutorials/running-a-signer/signer-quickstart.md
deleted file mode 100644
index 9e9c8ce7be..0000000000
--- a/guides-and-tutorials/running-a-signer/signer-quickstart.md
+++ /dev/null
@@ -1,444 +0,0 @@
-# Signer Quickstart
-
-{% hint style="info" %}
-**Current Signer and Stacks Node Versions**
-
-**Stacks Signer - latest**
-
-* [Docker Image](https://hub.docker.com/layers/blockstack/stacks-signer/latest)
-* [GitHub Release](https://github.com/stacks-network/stacks-core/releases/latest)
-
-**Stacks Node - latest**
-
-* [Docker Image](https://hub.docker.com/layers/blockstack/stacks-core/latest)
-* [GitHub Release](https://github.com/stacks-network/stacks-core/releases/latest)
-{% endhint %}
-
-If you want to get up and running as an active signer as quickly as possible, here is a list of the commands you need to run and actions to take.
-
-If you are not familiar with how signing works yet, be sure to check out the [Stackers and Signing](../../concepts/block-production/stackers-and-signing.md) concept guide.
-
-If you would like a more detailed walkthrough of all of these steps, take a look at the [Running a Signer](./) guide.
-
-{% hint style="danger" %}
-The CLI examples below may show outdated release versions. For the latest releases, always refer to the links above in the top info block.
-{% endhint %}
-
-## Step 1 - Prerequisites
-
-{% tabs %}
-{% tab title="Mainnet" %}
-```bash
-# Create the required directories
-mkdir -p ~/stacks-signer/data
-mkdir -p ~/stacks-node/data
-
-# Install needed packages
-sudo apt install -y npm wget unzip jq tar
-
-# Install Stacks CLI globally
-npm install --global @stacks/cli
-
-# Generate a new account and store details in a file
-stx make_keychain | jq > ~/stacks-signer/keychain.json
-```
-{% endtab %}
-
-{% tab title="Testnet" %}
-```bash
-# Create the required directories
-mkdir -p ~/stacks-signer/data
-mkdir -p ~/stacks-node/data
-
-# Install needed packages
-sudo apt install -y npm wget unzip jq tar
-
-# Install Stacks CLI globally
-npm install --global @stacks/cli
-
-# Generate a new account and store details in a file
-# '-t' option makes this a testnet account
-stx make_keychain -t | jq > ~/stacks-signer/keychain.json
-```
-{% endtab %}
-{% endtabs %}
-
-The account file previously created looks like this:
-
-```json
-{
- "mnemonic": "aaa bbb ccc ddd ...",
- "keyInfo": {
- "privateKey": "65f3...",
- "publicKey": "03a3...",
- "address": "SP1G...",
- "btcAddress": "19tg...",
- "wif": "Kzdt...",
- "index": 0
- }
-}
-```
-
-From this file, you'll need the `privateKey` value.
-
-## Step 2 - Set Up Your Stacks Signer
-
-### Download the stacks-signer binary
-
-Official binaries are available from the [Stacks Core releases page on Github](https://github.com/stacks-network/stacks-core/releases). Each release includes pre-built binaries. The version of stacks-signer compatible with this release is included on the same release page. Download the [latest signer release ZIP file](https://github.com/stacks-network/stacks-core/releases/latest) for your server’s architecture and decompress it. Inside of that folder is a `stacks-signer` binary.
-
-Assuming a `Linux x64 glibc` machine, the commands to download and uncompress the signer binary look like this:
-
-```bash
-# The CLI examples below may show outdated release versions.
-# Enter the signer directory
-cd ~/stacks-signer
-
-# Download the signer binary zip
-wget https://github.com/stacks-network/stacks-core/releases/latest/download/linux-glibc-x64.zip
-
-# Unzip the signer binary archive
-unzip linux-glibc-x64.zip
-```
-
-### Create the configuration file
-
-Create the configuration file required to start the signer (be sure to replace `` and `` with your auth token and private key values):
-
-{% tabs %}
-{% tab title="Mainnet" %}
-```bash
-# The CLI examples below may show outdated release versions.
-# Set environment variables
-AUTH_TOKEN= # Used for signer-node authentication
-PRIVATE_KEY= # privateKey from Step 1, this is the signer's private key
-
-# Create the signer's configuration file
-cat < ~/stacks-signer/signer-config.toml
-node_host = "127.0.0.1:20443"
-endpoint = "127.0.0.1:30000"
-network = "mainnet"
-db_path = "$HOME/stacks-signer/data/signer.sqlite"
-auth_password = "$AUTH_TOKEN"
-stacks_private_key = "$PRIVATE_KEY"
-metrics_endpoint = "127.0.0.1:9154"
-block_proposal_timeout_ms = 180000
-tenure_idle_timeout_secs = 120
-EOF
-```
-{% endtab %}
-
-{% tab title="Testnet" %}
-```bash
-# Set environment variables
-AUTH_TOKEN= # Used for signer-node authentication
-PRIVATE_KEY= # privateKey from Step 1, this is the signer's private key
-
-# Create the signer's configuration file
-cat < ~/stacks-signer/signer-config.toml
-node_host = "127.0.0.1:20443"
-endpoint = "127.0.0.1:30000"
-network = "testnet"
-db_path = "$HOME/stacks-signer/data/signer.sqlite"
-auth_password = "$AUTH_TOKEN"
-stacks_private_key = "$PRIVATE_KEY"
-metrics_endpoint = "127.0.0.1:9154"
-block_proposal_timeout_ms = 180000
-EOF
-```
-{% endtab %}
-{% endtabs %}
-
-### Verify the setup
-
-To ensure the signer has been set up correctly, you can run the following commands:
-
-```bash
-# The CLI examples below may show outdated release versions.
-# Verify the signer's version
-~/stacks-signer/stacks-signer --version
-
-# Output:
-stacks-signer stacks-signer signer-3.1.0.0.5.0 (release/signer-3.1.0.0.5.0:513dbc5, release build, linux [x86_64])
-
-# Verify the config file
-~/stacks-signer/stacks-signer check-config -c ~/stacks-signer/signer-config.toml
-
-# Output:
-Config:
-Stacks node host: 127.0.0.1:20443
-Signer endpoint: 127.0.0.1:30000
-Stacks address: SP1G... # address from keychain file
-Public key: 03a3... # publicKey from keychain file
-Network: mainnet # or testnet
-Chain ID: 0x1 # or 0x80000000 for testnet
-Database path: /home/admin/stacks-signer/data/signer.sqlite
-Metrics endpoint: 127.0.0.1:9154
-```
-
-### Start the signer
-
-If the outputs of the previous commands are correct, you can proceed and start the signer:
-
-```bash
-~/stacks-signer/stacks-signer run -c ~/stacks-signer/signer-config.toml
-```
-
-## Step 3a - Set up a Bitcoin node (Optional but strongly recommended)
-
-In order to optimize signer health and performance, we highly recommend setting up your own Bitcoin node rather than relying on a third-party node.
-
-We have created guides for running both a [full Bitcoin node](../nodes-and-miners/run-a-bitcoin-node.md) and a [pruned Bitcoin node](../nodes-and-miners/run-a-pruned-bitcoin-node.md) you can follow.
-
-## Step 3b - Set Up Your Stacks Node
-
-### Download the stacks-node binary
-
-Official binaries are available from the [Stacks Core releases page on Github](https://github.com/stacks-network/stacks-core/releases). Each release includes pre-built binaries. Download the [latest node release ZIP file](https://github.com/stacks-network/stacks-core/releases/latest) for your server’s architecture and decompress it. Inside of that folder is a `stacks-node` binary.
-
-Assuming a `Linux x64 glibc` machine, the commands to download and uncompress the node binary look like this:
-
-```bash
-# The CLI examples below may show outdated release versions.
-# Enter the node directory
-cd ~/stacks-node
-
-# Download the node binary zip
-wget https://github.com/stacks-network/stacks-core/releases/latest/download/linux-glibc-x64.zip
-
-# Unzip the node binary archive
-unzip linux-glibc-x64.zip
-```
-
-### Create the configuration file
-
-Create the configuration file required to start the node (be sure to replace `` with your auth token value):
-
-{% tabs %}
-{% tab title="Mainnet" %}
-{% hint style="warning" %}
-For mainnet, we strongly recommended that you run your own bitcoin node (you can follow guides on how to run a [full Bitcoin node](https://docs.stacks.co/guides-and-tutorials/nodes-and-miners/run-a-bitcoin-node) or a [pruned Bitcoin node](https://docs.stacks.co/guides-and-tutorials/nodes-and-miners/run-a-pruned-bitcoin-node)) in order to ensure you have no connection issues when downloading bitcoin blocks. A hosted bitcoin node may cause your stacks node to fall behind tip and remain unsynced.
-
-If you run your own bitcoin node, you'll have to update `peer_host` and optionally add `rpc_port`, `peer_port`, `username` and `password` fields under the `[burnchain]` section of the node's configuration file.
-{% endhint %}
-
-```bash
-# The CLI examples below may show outdated release versions.
-# Set environment variables
-AUTH_TOKEN= # Used for signer-node authentication, same token as the one set up in the signer configuration
-
-# Create the node's configuration file
-cat < ~/stacks-node/node-config.toml
-[node]
-working_dir = "$HOME/stacks-node/data"
-rpc_bind = "127.0.0.1:20443"
-p2p_bind = "0.0.0.0:20444"
-prometheus_bind = "127.0.0.1:9153"
-bootstrap_node = "02196f005965cebe6ddc3901b7b1cc1aa7a88f305bb8c5893456b8f9a605923893@seed.mainnet.hiro.so:20444,02539449ad94e6e6392d8c1deb2b4e61f80ae2a18964349bc14336d8b903c46a8c@cet.stacksnodes.org:20444,02ececc8ce79b8adf813f13a0255f8ae58d4357309ba0cedd523d9f1a306fcfb79@sgt.stacksnodes.org:20444,0303144ba518fe7a0fb56a8a7d488f950307a4330f146e1e1458fc63fb33defe96@est.stacksnodes.org:20444"
-stacker = true
-
-[burnchain]
-chain = "bitcoin"
-mode = "mainnet"
-peer_host = "bitcoin.mainnet.stacks.org"
-
-[connection_options]
-auth_token = "$AUTH_TOKEN"
-
-[[events_observer]]
-endpoint = "127.0.0.1:30000"
-events_keys = ["stackerdb", "block_proposal", "burn_blocks"]
-EOF
-```
-{% endtab %}
-
-{% tab title="Testnet" %}
-```bash
-# Set environment variables
-AUTH_TOKEN= # Used for signer-node authentication, same token as the one set up in the signer configuration
-
-# Create the node's configuration file
-cat < ~/stacks-node/node-config.toml
-[node]
-working_dir = "$HOME/stacks-node/data"
-rpc_bind = "127.0.0.1:20443"
-p2p_bind = "0.0.0.0:20444"
-bootstrap_node = "029266faff4c8e0ca4f934f34996a96af481df94a89b0c9bd515f3536a95682ddc@seed.testnet.hiro.so:30444"
-prometheus_bind = "127.0.0.1:9153"
-stacker = true
-pox_sync_sample_secs = 30
-always_use_affirmation_maps = true
-require_affirmed_anchor_blocks = true
-
-[burnchain]
-mode = "krypton"
-peer_host = "bitcoin.regtest.hiro.so"
-peer_port = 18444
-pox_prepare_length = 100
-pox_reward_length = 900
-
-[connection_options]
-auth_token = "$AUTH_TOKEN"
-private_neighbors = false
-
-[[events_observer]]
-endpoint = "127.0.0.1:30000"
-events_keys = ["stackerdb", "block_proposal", "burn_blocks"]
-
-[[ustx_balance]]
-address = "ST2QKZ4FKHAH1NQKYKYAYZPY440FEPK7GZ1R5HBP2"
-amount = 10000000000000000
-
-[[ustx_balance]]
-address = "ST319CF5WV77KYR1H3GT0GZ7B8Q4AQPY42ETP1VPF"
-amount = 10000000000000000
-
-[[ustx_balance]]
-address = "ST221Z6TDTC5E0BYR2V624Q2ST6R0Q71T78WTAX6H"
-amount = 10000000000000000
-
-[[ustx_balance]]
-address = "ST2TFVBMRPS5SSNP98DQKQ5JNB2B6NZM91C4K3P7B"
-amount = 10000000000000000
-
-[[burnchain.epochs]]
-epoch_name = "1.0"
-start_height = 0
-
-[[burnchain.epochs]]
-epoch_name = "2.0"
-start_height = 0
-
-[[burnchain.epochs]]
-epoch_name = "2.05"
-start_height = 1
-
-[[burnchain.epochs]]
-epoch_name = "2.1"
-start_height = 2
-
-[[burnchain.epochs]]
-epoch_name = "2.2"
-start_height = 3
-
-[[burnchain.epochs]]
-epoch_name = "2.3"
-start_height = 4
-
-[[burnchain.epochs]]
-epoch_name = "2.4"
-start_height = 5
-
-[[burnchain.epochs]]
-epoch_name = "2.5"
-start_height = 6
-
-[[burnchain.epochs]]
-epoch_name = "3.0"
-start_height = 1_900
-
-[[burnchain.epochs]]
-epoch_name = "3.1"
-start_height = 2_000
-EOF
-```
-{% endtab %}
-{% endtabs %}
-
-### Optional: Start the node with a data archive
-
-You can [download a chainstate archive](https://archive.hiro.so/) in order to quickly sync your node, otherwise it will take a long time to get up-to-date with the other nodes.
-
-{% tabs %}
-{% tab title="Mainnet" %}
-```bash
-# Enter the node's datadir
-cd ~/stacks-node/data
-
-# Download the archive
-wget https://archive.hiro.so/mainnet/stacks-blockchain/mainnet-stacks-blockchain-latest.tar.gz
-
-# Decompress the archive
-tar -xvf mainnet-stacks-blockchain-latest.tar.gz
-
-# Remove the archive
-rm mainnet-stacks-blockchain-latest.tar.gz
-```
-{% endtab %}
-
-{% tab title="Testnet" %}
-```bash
-# Enter the node's datadir
-cd ~/stacks-node/data
-
-# Download the archive
-wget https://archive.hiro.so/testnet/stacks-blockchain/testnet-stacks-blockchain-latest.tar.gz
-
-# Decompress the archive
-tar -xvf testnet-stacks-blockchain-latest.tar.gz
-
-# Remove the archive
-rm testnet-stacks-blockchain-latest.tar.gz
-```
-{% endtab %}
-{% endtabs %}
-
-### Verify the setup
-
-To ensure the node has been set up correctly, you can run the following commands:
-
-```bash
-# The CLI examples below may show outdated release versions.
-# Verify the node's version
-~/stacks-node/stacks-node version
-
-# Output:
-INFO [1738695915.769633] [testnet/stacks-node/src/main.rs:278] [main] stacks-node 3.1.0.0.5 (release/3.1.0.0.5:513dbc5, release build, linux [x86_64])
-stacks-node 3.1.0.0.5 (release/3.1.0.0.5:513dbc5, release build, linux [x86_64])
-
-# Verify the node's config
-~/stacks-node/stacks-node check-config --config ~/stacks-node/node-config.toml
-
-# Output:
-INFO [1738695915.769633] [testnet/stacks-node/src/main.rs:278] [main] stacks-node 3.1.0.0.5 (release/3.1.0.0.5:513dbc5, release build, linux [x86_64])
-INFO [1729788064.913175] [testnet/stacks-node/src/main.rs:318] [main] Loading config at path /home/admin/stacks-node/node-config.toml
-INFO [1729788064.969551] [testnet/stacks-node/src/main.rs:331] [main] Loaded config!
-```
-
-### Start the node
-
-If the outputs of the previous commands are correct, you can proceed and start the node:
-
-```bash
-~/stacks-node/stacks-node start --config ~/stacks-node/node-config.toml
-```
-
-## Step 5 - Generate your signer signature
-
-In order to stack, you'll need your signer signature. The fields required are further explained in the [Generate a signer key signature](https://docs.stacks.co/guides-and-tutorials/stack-stx/stacking-flow#step-2-generate-a-signer-key-signature) guide.
-
-The command to generate a signature looks like this:
-
-```bash
-~/stacks-signer/stacks-signer generate-stacking-signature \
- --method stack-stx \
- --max-amount 1000000000000 \
- --auth-id 195591226970828652622091037492597751808 \
- --period 12 \
- --reward-cycle 100 \
- --pox-address 19tg... \
- --config ~/stacks-signer/signer-config.toml \
- --json
-```
-
-The generated JSON can be then copy-pasted directly in the [Leather Earn](https://earn.leather.io) website mentioned in the next step.
-
-## Step 6 - Start stacking
-
-The simplest route is to solo stack. You can do that by using [Leather Earn](https://earn.leather.io). Click on the 'Stack Independently' button and follow the instructions there.
-
-If you would like to learn more about solo stacking or running a pool operator, take a look at the [Stack STX](https://docs.stacks.co/guides-and-tutorials/stack-stx) guide.
-
-## Step 7 - Monitoring
-
-If you would like to learn more about monitoring your signer and its corresponding node, you can check the [How to Monitor a Signer](https://docs.stacks.co/guides-and-tutorials/running-a-signer/how-to-monitor-signer) guide.
diff --git a/guides-and-tutorials/sbtc/README.md b/guides-and-tutorials/sbtc/README.md
deleted file mode 100644
index bb4e80f286..0000000000
--- a/guides-and-tutorials/sbtc/README.md
+++ /dev/null
@@ -1,7 +0,0 @@
-The guides in this section provide step-by-step instructions for interacting
-with sBTC, including operating as a signer and (coming soon) developer guides on
-how to interact with sBTC as an application developer.
-
-Note that in order to run a sBTC signer you must be one of the [approved
-signers](https://github.com/stacks-network/sbtc/discussions/624) described in
-[SIP-028](https://github.com/andrerserrano/sips/blob/main/sips/sip-028/sip-028-sbtc_peg.md).
diff --git a/guides-and-tutorials/sbtc/best-practices-for-running-an-sbtc-signer.md b/guides-and-tutorials/sbtc/best-practices-for-running-an-sbtc-signer.md
deleted file mode 100644
index 5ceabeb475..0000000000
--- a/guides-and-tutorials/sbtc/best-practices-for-running-an-sbtc-signer.md
+++ /dev/null
@@ -1,127 +0,0 @@
-# Best practices for running a sBTC signer
-
-The following best practices suggest how to create a resilient setup for running
-your sBTC Signer.
-
-## Protect your private key and have a cold-storage backup
-
-- Prevent unauthorised access to the sBTC Signer private key.
-- Keep an offline, secure backup of your sBTC Signer private key (e.g., hardware
- security modules or encrypted storage devices).
-
-## Backup your sBTC Signer PostgreSQL DB
-
-- Perform daily backups of the sBTC Signer PostgreSQL DB.
-- Periodically verify the integrity of backups, as instructed below.
-
-### Verifying integrity of PostgreSQL DB backups
-
-To verify the integrity of a backup, first import it into a fresh PostgreSQL
-instance (the database is enough, no need to spin up a Stacks / Bitcoin node or
-the sBTC signer).
-
-Then, perform the following query:
-
-```sql
-signer=> SELECT aggregate_key FROM sbtc_signer.dkg_shares WHERE
-dkg_shares_status = 'verified' ORDER BY created_at DESC;
-```
-
-It will return results as follows (your mileage might vary depending on the
-history of your sBTC signer, the following is provided for illustration purposes
-only):
-
-```sql
-
- aggregate_key
-----------------------------------------------------------------------
- \x03d8c4344861fc7590fd812c24884a3bfd9374d8ba865a787ff53c9060020aa967
- \x03f898f8a6ddb86dd4608dd168355ec6135fe2839222240c01942e8e7e50dd4c89
-(2 rows)
-```
-
-Now, ensure that the most recent `aggregate_key` (the first one) corresponds to
-the one returned by a read-only call to the
-`SM3VDXK3WZZSA84XXFKAFAF15NNZX32CTSG82JFQ4/sbtc-registry/get-current-aggregate-pubkey`
-smart contract method:
-
-```bash
-curl -s 'https://api.hiro.so/v2/contracts/call-read/SM3VDXK3WZZSA84XXFKAFAF15NNZX32CTSG82JFQ4/sbtc-registry/get-current-aggregate-pubkey' \
- -H 'content-type: application/json' --data-raw '{"sender":"SM3VDXK3WZZSA84XXFKAFAF15NNZX32CTSG82JFQ4","arguments":[]}' | jq .result
-
-"0x020000002103d8c4344861fc7590fd812c24884a3bfd9374d8ba865a787ff53c9060020aa967"⏎
-```
-
-You can discard the prefix `0x02000000210` (which is how Clarity encodes
-values). The suffix
-`3d8c4344861fc7590fd812c24884a3bfd9374d8ba865a787ff53c9060020aa967` matches the
-first row of the PostgreSQL query above (excluding `\x0` which indicates hex
-encoding).
-
-## Setup proper access control
-
-- Require hardware 2FA keys for access control (e.g., by using Yubikey) to
- connect through SSH, to authenticate to AWS, and for every other relevant
- action.
-- Follow the principle of _least privilege_: if you don’t need access, you don’t
- get access; if you get access, it expires after the action is taken.
-- _Optional, but strongly recommended_: Implement a "_4-eyes_" process (require that any activity by an individual must be controlled - reviewed, double checked - by a second individual) to access
- critical resources (e.g., deploy a new version of the sBTC signer).
-
-## Maintain a strict firewall configuration
-
-- Allow connections to your sBTC signer `listen_on` address (used for P2P
- communication).
-- Do not expose any non-essential service to the internet: use a `DEFAULT DENY` policy with explicit `ALLOW`s for necessary network traffic (such as sBTC signer p2p and SSH).
-
-## Maintain a robust secrets management program
-
-- Ensure all relevant secrets are safely managed and rotated (where possible),
- e.g. if someone leaves the team.
-
-## Monitor and observe your sBTC Signer
-
-- Retain at least 90 days of logs for both the sBTC Signer, the Stacks node, and
- the Bitcoin node.
-- The sBTC signer can optionally expose Prometheus metrics (see
- `prometheus_exporter_endpoint` configuration option).
- - You can use them to monitor its health ([this guide shows how to configure
- Alloy to collect metrics on Grafana
- cloud](../running-a-signer/how-to-monitor-signer.md)).
-
-## Provision dedicated downstream components
-
-- Run a _dedicated_ Bitcoin node and Stacks node for your sBTC Signer.
- - Ensure the nodes are provisioned with the minimum hardware requirements
- described [here][0].
- - Nodes should be _exclusively dedicated_ to serve the sBTC Signer. Avoid
- re-using them to serve other clients as that may negatively affect
- performance (no _mock-signing_, no _Stacks API nodes_).
-
-## Monitor new software releases
-
-- Stay up-to-date with new releases, patches, and security advisories for all
- used operating systems, software and packages:
- - [https://www.cve.org/](https://www.cve.org/) is a great resource for popular
- software packages.
- - Subscribe to receive security notifications from your vendors.
- - Join relevant messaging channels as applicable (i.e. on Discord, Slack,
- etc.).
-- Exercise vulnerability management for all packages.
-- Apply updates as quickly as possible, especially those addressing a security
- vulnerability.
-- Use inventory and patch management software, if available.
-
-## Ensure redundancy in operations
-
-- Ensure that multiple, trusted system administrators can manage and maintain
- your sBTC Signer instance.
-- Where feasible, system administrators should span different time zones.
-- Document your operations procedures and ensure that relevant personnel have
- access to them.
-
-## References
-
-[0]: https://docs.stacks.co/guides-and-tutorials/running-a-signer#minimum-system-requirements
-
-- [Best practices to run a Stacks Signer](../running-a-signer/best-practices-to-run-a-signer.md).
diff --git a/guides-and-tutorials/sbtc/earn-sbtc-rewards.md b/guides-and-tutorials/sbtc/earn-sbtc-rewards.md
deleted file mode 100644
index d3e91bdae1..0000000000
--- a/guides-and-tutorials/sbtc/earn-sbtc-rewards.md
+++ /dev/null
@@ -1,37 +0,0 @@
-# Earn sBTC Rewards
-
-As part of the launch of sBTC, you can enroll in the sBTC rewards program and earn real yield on your BTC, paid in sBTC.
-
-The rewards program is non-custodial, your sBTC remains in your wallet.
-
-There are only 3 steps to participate in the sBTC rewards.
-
-{% stepper %}
-{% step %}
-#### Mint sBTC
-
-To get started, first mint your sBTC by using the bridge at [app.stacks.co](https://app.stacks.co/).
-{% endstep %}
-
-{% step %}
-#### Connect your wallet
-
-After your sBTC has been minted to your wallet, visit the rewards program site at [bitcoinismore.org](https://bitcoinismore.org) and connect your wallet. The click the 'Earn Rewards' button.
-
-{% hint style="info" %}
-You may need to enable the sBTC token listing display in your wallet before it is visible. In Leather, you can do this by clicking 'Manage Tokens' and toggling on sBTC.
-
-
-{% endhint %}
-
-
-{% endstep %}
-
-{% step %}
-#### Enroll in the rewards program
-
-Finally, you'll simply execute a Stacks transaction using your connected wallet to enroll in the program. You will need enough STX to cover the transaction fee to enroll in the rewards program.
-
-
-{% endstep %}
-{% endstepper %}
diff --git a/guides-and-tutorials/sbtc/how-to-run-sbtc-signer.md b/guides-and-tutorials/sbtc/how-to-run-sbtc-signer.md
deleted file mode 100644
index b34942f8b1..0000000000
--- a/guides-and-tutorials/sbtc/how-to-run-sbtc-signer.md
+++ /dev/null
@@ -1,178 +0,0 @@
-# How to Run an sBTC Signer
-
-{% hint style="info" %}
-This documentation provides guidelines, best-practices and recommendations for
-running an sBTC Signer. Review it and adapt it to your infrastructure policy
-before deploying it.
-{% endhint %}
-
-{% hint style="warning" %}
-Each sBTC signer will control a set of signing shares used to sign transactions
-on both Bitcoin and Stacks.
-
-Such shares will be encrypted by using the `private_key` specified in the
-Signer's config and stored in the PostgreSQL database attached to each signer.
-
-It is of the utmost importance to:
-
-1. Prevent unauthorized access to the sBTC Signer infrastructure (the signer
- itself, its private key, and the associated PostgreSQL database);
-1. keep an offline, secure backup of the sBTC Signer private key;
-1. regularly backup the PosgreSQL database and store it in a secure location.
-
-See [here](./best-practices-for-running-an-sbtc-signer.md) for additional best
-practices to run an sBTC signer.
-{% endhint %}
-
-## Minimum System Requirements
-
-Below are the **minimum required specs** to be able to run a sBTC signer.
-
-- 2 CPU
-- 4GB memory
-- 50GB storage
-
-Note that these are in _addition_ to the hardware requirements for running a
-Stacks node and Bitcoin node outlined in the [How to Run a Signer
-doc](../running-a-signer/README.md).
-
-## Connection diagram
-
-
-
-## 1. Configure your Bitcoin node
-
-### Minimum version
-
-You will need `bitcoind` version 25 or higher.
-
-### Settings
-
-Your Bitcoin node must include these settings for sBTC signer operation:
-
-- `txindex=1`: Transaction indexing must be enabled
-- `server=1`: RPC server must be enabled
-
-### RPC-Based Block Detection
-
-Starting with sBTC v1.1.0, the signer uses RPC polling instead of ZeroMQ for
-block detection.
-
-The signer connects to Bitcoin Core via RPC and polls for new bitcoin blocks. This process works as follows:
-
-1. Bitcoin Core validates a new block
-1. Signer detects the block via RPC polling
-1. Signer processes relevant sBTC transactions
-
-### Example
-
-```bash
-bitcoind \
- -server \
- -datadir=${BITCOIN_DATA} \
- -rpcbind=0.0.0.0 \
- -rpcuser=${BITCOIN_RPC_USERNAME} \
- -rpcpassword=${BITCOIN_RPC_PASSWORD} \
- -rpcport=${BITCOIN_RPC_PORT} \
- -rpcallowip=0.0.0.0/0 \
- -rpcallowip=::/0 \
- -txindex
-```
-
-## 2. Configure your Stacks node
-
-### Minimum version
-
-Please ensure your Stacks version is up-to-date (using the latest release).
-
-### Event observer
-
-You will need to add a _new_ event observer that relays information from the
-sBTC smart contracts to the sBTC signer:
-
-```toml
-[[events_observer]]
-endpoint = "sbtc-signer:8801"
-events_keys = [
- "SM3VDXK3WZZSA84XXFKAFAF15NNZX32CTSG82JFQ4.sbtc-registry::print",
-]
-```
-
-### Reference configuration
-
-See
-[here](https://github.com/stacks-network/sbtc/blob/main/docker/mainnet/nodes/stacks/Config.toml.in).
-
-## 3. Configure your sBTC Signer
-
-The signer configuration file (`signer-config.toml`) defines the signer's
-operation parameters. The configuration sections include:
-
-### Blocklist Client Settings
-
-```toml
-[blocklist_client]
-endpoint = "http://blocklist-client:3032"
-```
-
-### Bitcoin Connection Settings
-
-Defines how the signer connects to Bitcoin Core:
-
-```toml
-[bitcoin]
-rpc_endpoints = ["http://user:pass@your-bitcoin-node:8332"]
-# Note: block_hash_stream_endpoints are no longer used as of v1.1.0
-# The signer now uses RPC polling for block detection
-```
-
-### Core Signer Parameters
-
-Defines the signer's identity and network participation:
-
-```toml
-[signer]
-private_key = "your-private-key" # 32 or 33-byte hex format
-network = "mainnet"
-deployer = "SM3VDXK3WZZSA84XXFKAFAF15NNZX32CTSG82JFQ4"
-```
-
-### P2P Network Configuration
-
-Controls how the signer communicates with other network participants:
-
-```toml
-[signer.p2p]
-listen_on = ["tcp://0.0.0.0:4122"]
-```
-
-The signer operates on port 4122 by default and supports both TCP and QUIC
-protocols for peer communication. The signer will attempt QUIC connections first
-for improved performance, automatically falling back to TCP if QUIC is
-unavailable or blocked on the network.
-
-### Reference configuration
-
-See
-[here](https://github.com/stacks-network/sbtc/blob/main/docker/mainnet/sbtc-signer/signer-config.toml.in).
-
-## 4. Set up your containers
-
-See
-[here](https://github.com/stacks-network/sbtc/blob/main/docker/mainnet/docker-compose.yml)
-for a Docker Compose including all the required components.
-
-{% hint style="warning" %}
-
-When deploying with Docker, always use [immutable image tags](https://docs.docker.com/reference/cli/docker/image/pull/#pull-an-image-by-digest-immutable-identifier) - the image digests are provided below. Verify the attestation of these images using this [guide](https://docs.github.com/en/actions/security-for-github-actions/using-artifact-attestations/using-artifact-attestations-to-establish-provenance-for-builds#verifying-artifact-attestations-with-the-github-cli).
-
-We publish our images on [GitHub Container Registry](https://github.com/stacks-sbtc/sbtc/pkgs/container/sbtc).
-{% endhint %}
-
-## Monitoring
-
-Monitoring Details TBD
-
-## Troubleshooting
-
-Troubleshooting Guide TBD
diff --git a/guides-and-tutorials/sbtc/how-to-use-the-sbtc-bridge.md b/guides-and-tutorials/sbtc/how-to-use-the-sbtc-bridge.md
deleted file mode 100644
index 522d675ef3..0000000000
--- a/guides-and-tutorials/sbtc/how-to-use-the-sbtc-bridge.md
+++ /dev/null
@@ -1,87 +0,0 @@
-# How to Use the sBTC Bridge
-
-The sBTC bridge is a web application allowing you to convert your BTC into sBTC on the Stacks chain.
-
-{% hint style="warning" %}
-Ensure that you are using the bridge located at [sbtc.stacks.co](https://sbtc.stacks.co/). This is the only official sBTC bridge.
-{% endhint %}
-
-If you aren't familiar with sBTC, be sure to check out the [sBTC Conceptual Guide](../../concepts/sbtc/) to understand how it works.
-
-The bridge has been designed to be as simple as possible to use. In order to utilize sBTC, all you need to do is send a Bitcoin transaction using a supported wallet (like [Leather](https://leather.io/) or [Xverse](https://www.xverse.app/)).
-
-Below you'll find both a video and written walkthrough of using the bridge.
-
-### Video Walkthrough
-
-
-
-{% embed url="https://youtu.be/XZruuDgTo4k" %}
-
-### Written Walkthrough
-
-There are 5 simple steps to convert your BTC to sBTC.
-
-{% stepper %}
-{% step %}
-### Connect your wallet
-
-First, you'll need to connect your wallet to the bridge UI. Currently Leather and Xverse are supported, with more on the way.
-
-
-{% endstep %}
-
-{% step %}
-### Choose the amount to deposit
-
-After your wallet is connected, choose how much BTC you would like to convert to sBTC.
-
-{% hint style="info" %}
-There are two transaction fees required to mint your sBTC. The first is set by the user manually when they initiate the deposit transaction within their wallet. The second is a fee used to consolidate the deposit UTXOs into the single signer UTXO. This separate transaction fee happens automatically and is set to a max of 80k sats. This is automatically deducted from your minted sBTC. This is not a signer fee but a regular Bitcoin transaction fee.
-{% endhint %}
-
-
-
-
-{% endstep %}
-
-{% step %}
-### Choose the Stacks address to mint to
-
-Next, enter the Stacks address you would like your sBTC minted to.
-
-
-{% endstep %}
-
-{% step %}
-### Initiate the transaction
-
-After you choose your Stacks address, you'll use your connected wallet to transfer the BTC.
-
-
-{% endstep %}
-
-{% step %}
-### Receive your sBTC
-
-In the UI, you can monitor the status of your transaction to see when it has been completed, at which point you can see the sBTC in your wallet. It will go through three stages:
-
-* Pending - Your Bitcoin transaction is processing
-* Minting - Your Bitcoin transaction has processed and the sBTC signers are minting your sBTC
-* Completed - Your sBTC has been minted to your wallet
-
-Note that you may need to enable the display of the sBTC token within your wallet by clicking on 'Manage Tokens' and enabling sBTC.
-
-
-{% endstep %}
-{% endstepper %}
-
-### Reclaiming BTC
-
-If your sBTC mint fails, you can reclaim your sBTC. You can do this via the bridge by visiting the reclaim page at https://sbtc.stacks.co/\/reclaim and replacing the bracketed text with your transaction ID, eg. [https://sbtc.stacks.co/8f37f750b6646f0a217121201967170bd3cfef5f2ebd4f30f359b5e9308470c4/reclaim](https://sbtc.stacks.co/8f37f750b6646f0a217121201967170bd3cfef5f2ebd4f30f359b5e9308470c4/reclaim)
-
-There is an intermediate step in between depositing BTC and the sBTC signers consolidating it into the single signer UTXO. If the transaction is not picked up by signers, you can reclaim it using this UI. Note there is a 'Lock Time' field on the Reclaim page. That indicates the amount of blocks that must have passed in order to reclaim your BTC.
-
-This initiates a Bitcoin transaction that will transfer your BTC back to you.
-
-
diff --git a/guides-and-tutorials/sbtc/sbtc-builder-quickstart.md b/guides-and-tutorials/sbtc/sbtc-builder-quickstart.md
deleted file mode 100644
index f5873b3954..0000000000
--- a/guides-and-tutorials/sbtc/sbtc-builder-quickstart.md
+++ /dev/null
@@ -1,122 +0,0 @@
-# sBTC Builder Quickstart
-
-Get up and running with sBTC in 30 minutes or less. This guide covers the essentials for working with sBTC as a SIP-010 token in your smart contracts.
-
-### What is sBTC?
-
-sBTC is Bitcoin on Stacks. It's a SIP-010 fungible token that maintains a 1:1 peg with Bitcoin, enabling you to use Bitcoin in smart contracts and DeFi applications on the Stacks blockchain.
-
-Key points:
-
-* **1:1 Bitcoin peg**: 1 sBTC always equals 1 BTC
-* **SIP-010 token**: Works like any other fungible token on Stacks
-* **Programmable**: Use Bitcoin in smart contracts, DeFi protocols, and dApps
-
-### Quick Setup
-
-#### Prerequisites
-
-In order to get the most from this quickstart, you should familiarize yourself with Clarity, Clarinet, Stacks.js, and the Hiro Platform. These are the fundamental building blocks of building Stacks applications.
-
-* [Stacks Developer Quickstart](../hello-stacks-quickstart-tutorial.md) - For a quick holistic introduction to the Stacks development process, tools, and fundamentals
-* [Clarity Crash Course](../clarity-crash-course.md) - For a quick introduction to Clarity
-* [Clarinet Docs](https://docs.hiro.so/tools/clarinet)
-* [Stacks.js Docs](https://docs.hiro.so/reference/stacks.js)
-
-Choose your preferred development environment:
-
-#### Option 1: Hiro Platform (Recommended)
-
-The fastest way to start building with sBTC is using the Hiro Platform's hosted devnet. The Platform integrates with your GitHub account. You can either import an existing project from GitHub or start with a Platform template and have it synced with your GitHub account.
-
-After you create the project in the Platform, you can clone it locally and work with the Platform's cloud devnet by connecting your API key as described in the template's README files. This will allow you to work on your code locally but let Platform handle the complexities of actually running the devnet.
-
-1. **Create an account** at [platform.hiro.so](https://platform.hiro.so)
-2. **Create or import a project**
- * Select a template or import your own project from GitHub. There are several templates available to use as a starting point. Some have only smart contracts and some are full-stack dapp templates. Starting with one of these ensures you are building with best practices.
- * Navigate to your project dashboard
-3. **Start devnet**
- * Click the "Devnet" tab
- * Click "Start Devnet"
- * Wait for status to show "Active"
-4. **Connect your wallet**
- * Your devnet wallets are automatically funded with STX and sBTC
- * Use the provided wallet addresses within the templates
- * The platform templates are automatically connected to Devnet, and there are instructions in the READMEs of the templates for how to connect your frontend to your Devnet instance
-
-#### Option 2: Local with Clarinet
-
-If you would prefer to have your devnet running locally instead of in the Platform cloud, you can run one yourself
-
-1. **Install Clarinet** (version 3.x)
-
- ```bash
- brew install clarinet
- ```
-2. **Create a new project**
-
- ```bash
- clarinet new my-sbtc-project
- cd my-sbtc-project
- ```
-3. **Add sBTC requirements**
-
- ```bash
- clarinet requirements add SM3VDXK3WZZSA84XXFKAFAF15NNZX32CTSG82JFQ4.sbtc-deposit
- ```
-
- This automatically includes the sBTC token contract in your Clarinet context so you can reference it within your contracts.
-4. **Start devnet**
-
- ```bash
- clarinet devnet start
- ```
-
-With either of these options, your Devnet wallets are automatically funded with sBTC. You just need to include the sBTC contract in your contract requirements as shown above.
-
-### Working with sBTC in Smart Contracts
-
-sBTC follows the SIP-010 standard, making it easy to integrate into your contracts.
-
-The primary function you'll be using is the `transfer` function. That's because sBTC exists as a 1:1 Bitcoin peg via a SIP-010 token. Minting is handled by the protocol, the main function of writing smart contracts that use sBTC is to move it around, which means using the `transfer` function.
-
-Here's a very basic example of how to transfer sBTC within your contract.
-
-#### Basic Transfer Example
-
-Create a new contract that accepts sBTC payments. You can do this within the Clarinet project folder with `clarinet contract new sbtc-payment`.
-
-```clarity
-;; contracts/sbtc-payment.clar
-
-;; Define the sBTC token contract reference
-(define-constant sbtc-token 'SM3VDXK3WZZSA84XXFKAFAF15NNZX32CTSG82JFQ4.sbtc-token)
-
-;; Error codes
-(define-constant err-insufficient-balance (err u100))
-(define-constant err-transfer-failed (err u101))
-
-;; Accept sBTC payment
-(define-public (pay-with-sbtc (amount uint) (recipient principal))
- (contract-call? sbtc-token transfer
- amount
- tx-sender
- recipient
- none))
-```
-
-You can test out this contract by either using the UI within the Platform to call the functions directly if you have devnet running or by opening the console with `clarinet console`.
-
-Once you do that you'll see that your devnet accounts have automatically been funded with sBTC.
-
-
-
-Once you are ready to deploy to testnet, you can do so by editing your deployment plan as outlined in [this guide](https://docs.hiro.so/tools/clarinet/sbtc-integration).
-
-### Conclusion
-
-You can build pretty much anything you want using this simple foundation, as all of the complexity of sBTC is handled behind the scenes by the protocol.
-
-What's needed now is for builders to take this foundation and build interesting, useful things with it. sBTC unlocks a lot of additional functionality for Bitcoin that previously would have only been possible with either custodied solutions or slow, complex solutions with poor UX.
-
-If you are interested, you can read more about how sBTC works in the [sBTC Concept Guide](../../concepts/sbtc/).
diff --git a/guides-and-tutorials/stack-stx/README.md b/guides-and-tutorials/stack-stx/README.md
deleted file mode 100644
index d6cf00d441..0000000000
--- a/guides-and-tutorials/stack-stx/README.md
+++ /dev/null
@@ -1,114 +0,0 @@
-# Stack STX
-
-Stacking is an essential component of Stacks.
-
-There are three different ways you can potentially stack your STX tokens and we have a dedicated guide for each of these scenarios.
-
-If you aren't familiar with how stacking works, especially as it relates to signing after the Nakamoto upgrade, besure to check out the following concept guides:
-
-* [Stackers and signing](../../concepts/block-production/stackers-and-signing.md)
-* [Stacking](../../concepts/block-production/stacking.md)
-
-In Nakamoto, stacking flows have significant changes in comparison to previous versions of Stacks. Because Nakamoto requires stackers to run a signer, which validates blocks produced by Stacks miners, stackers need to provide new information when making Stacking transactions.
-
-These changes affect both solo Stacking and delegated Stacking. This document outlines the new flows for solo stacking. The next doc outlines the flow and steps for operating a pool.
-
-If you aren't familiar with the general block production process under Nakamoto and what role signers and stackers play, you may want to read [Nakamoto in 10 Minutes](../../nakamoto-upgrade/nakamoto-in-10-minutes.md) to get up to speed.
-
-The following sections will walk you through how to begin operating as a solo stacker.
-
-Stacking utilizes the `pox-4` contract. There is a detailed [walkthrough of the stacking contract](../../example-contracts/stacking.md) that you can look at to see what functions are being called at each phase and some common errors you may encounter. This will be especially useful for pool operators who need to call these functions.
-
-This doc is also useful if you run into errors when calling stacking functions, as it both walks through several common error scenarios and walks through each function call so you can more easily trace what might be happening.
-
-Before we get into the step-by-step of how to actually stack, it's important to make sure you have an understanding of the different roles, processes and functions involved in Stacking.
-
-### Definitions and Roles
-
-* **Stacker**: an entity locking their STX to receive PoX rewards. This is a broad term including solo Stackers and Stackers who use pools.
-* **Solo stacker**: an entity that locks their own STX and runs a signer. They don’t receive delegation.
-* **Delegator**: a stacker who locks their STX by delegating to a pool operator that runs a signer. They don’t run the signer.
-* **Pool operator**: an entity that runs a Signer and allows others to delegate their STX to them. A pool operator doesn’t need to Stack their own STX, but they can. They will also run a signer, but the pool operator and signer address may be different
-* **Signer**: an entity that runs the stacks-signer software and participates in block validation. This can be either a solo Stacker or an entity receiving delegated STX. Depending on context, this may also refer to the signer software that validates blocks.
-
-{% hint style="info" %}
-It's important to understand that in the context of the pool operator and signer, these are likely the same _entity_ but may not be the same Stacks address.
-
-This distinction will be discussed further as we cover the step-by-step process below.
-{% endhint %}
-
-As mentioned above, there are three primary ways you can stack:
-
-1. Solo stacking
-2. Pool operator
-3. Delegator
-
-The following pages in this section will walk through the practical steps for stacking for all three scenarios.
-
-As you read through these, it may be helpful to follow along with the functions in the [pox-4 contract](https://explorer.hiro.so/txid/SP000000000000000000002Q6VF78.pox-4?chain=mainnet) to get an idea of what each function is doing.
-
-### Solo Stack
-
-If you meet the minimum and want to [solo stack](stacking-flow.md), you will either need to run a signer, collaborate with an existing one, or use [stacking.tools](https://stacking.tools/). This guide will walk you through all options.
-
-### Operate a Pool
-
-You can also [operate a pool](operate-a-pool.md) and have others delegate their STX to you. If you are a pool operator, you will need to run a signer, collaborate with an existing one, or use [stacking.tools](https://stacking.tools/).
-
-### Stack with a Pool
-
-If you do not meet the minimum amount of STX to solo stack, you can [delegate your STX to a pool operator ](stack-with-a-pool.md)and have them stack on your behalf. The minimum stacking amount is dynamic and can be found by visiting the [https://api.hiro.so/v2/pox](https://api.hiro.so/v2/pox) endpoint and looking at the `min_threshold_ustx` field. Note it is denoted in uSTX (1 STX = 1,000,000 uSTX). This is the most common stacking scenario.
-
-### Relationship between manual stacking transactions and the running signer
-
-This section describes the various transactions that signer entities need to make in order to be registered as a signer for a certain reward cycle. The order of operations between the automated signer and the stacking transactions that need to be done “manually” is important for ensuring that a signer is fully set up for a certain reward cycle.
-
-
-
-#### Prerequisite: ensure the signer is hosted and running
-
-It's important to emphasize the importance of getting the signer running in a hosted environment before making Stacking transactions. If the signer doesn’t do that, they run the risk of being registered as a signer without their signer software being ready to run DKG and other important consensus mechanisms.
-
-Some of the important things to double check to ensure the signer is “running” are:
-
-* The signer software is configured with a private key that the user can access (either through SSH or other means). This is important because their signer needs to utilize this private key to generate signer key signatures that are used in Stacking transactions.
-* The signer software is properly configured to make RPC calls to a Stacks node. This refers to the `endpoint` signer configuration field. If properly configured, there should be logs in the Stacks node that show the RPC calls being made from the signer.
-* The stacks node is properly configured to send events to the signer. This refers to the \[\[`event_observers`]] field in the Stacks Node’s configuration. If properly configured, the signer should have logs indicating that it’s receiving events from the Stacks node.
-
-### How a signer becomes registered in the signer set
-
-Each of the stacking transactions described above are done “manually”. More specifically, this means that none of these transactions are executed automatically by the signer software. The transactions must be done “out of band”.
-
-In order for a signer to actually be registered in a reward cycle, there need to be manual transactions made in the `pox-4` contract. While the signer software is running, it is continually polling the Stacks node and asking “am I a signer in reward cycle N?”.
-
-If these manual transactions are confirmed, and the signer has enough STX associated with the signer’s public key, the signer will be registered as a signer in the signer set.
-
-#### Solo stacking
-
-The workflow for solo stackers is simpler, because there are less stacking transactions that need to be made.
-
-For solo stacking, the only transaction that needs to be made is `stack-stx`. Included in this transaction’s payload is the signer’s public key.
-
-In order for the signer to be registered in reward cycle N+1, the `stack-stx` transaction must be confirmed during the first 2000 blocks of reward cycle N. The last 100 blocks of cycle N (the “prepare phase”) is where DKG occurs.
-
-The start of the prepare phase is when Stacks nodes determine the official signer set of the next reward cycle.
-
-#### Delegated Stacking
-
-The workflow for delegated signers is more complex, because it requires more transactions.
-
-This workflow is explained more in detail in the [operate a pool](operate-a-pool.md) guide, but the high-level workflow is:
-
-1. Stackers delegate their STX to a pool operator
-2. The pool operator makes `delegate-stack-stx` transactions to “approve” specific stackers. This needs to be called for every individual stacker that delegates to them.
-3. The pool operator makes a `stack-aggregation-commit` transaction to “commit” all of its delegated STX up to this point.
-
-Similar to solo stacking, these steps must be made before the prepare phase of an upcoming reward cycle.
-
-### Once a signer is registered in the signer set
-
-During the prepare phase before a reward cycle, Stacks nodes automatically determine the signer set for the upcoming cycle. When this occurs, the Stacks nodes make an “internal” transaction to update the `.signers` contract with the list of signers.
-
-The signer software is continuously polling the Stacks node to see if it is registered for a cycle. If the signer software finds that it is registered (by matching its public key to the signers stored in the `signers` contract) it begins performing its duties as a signer.
-
-During the prepare phase, the signers perform DKG through StackerDB messages. Once an aggregate public key is determined, the signer automatically makes a `vote-for-aggregate-key` transaction. No out-of-band action is needed to be taken for this to occur.
diff --git a/guides-and-tutorials/stack-stx/increase-stacking.md b/guides-and-tutorials/stack-stx/increase-stacking.md
deleted file mode 100644
index e527f06bc5..0000000000
--- a/guides-and-tutorials/stack-stx/increase-stacking.md
+++ /dev/null
@@ -1,476 +0,0 @@
-# Increase Stacked Position
-
-This guide explains how to increase your stacked STX position. The process depends on your role:
-
-- **Solo Stackers** use the `stack-increase` function.
-- **Delegators** must first revoke their current delegation using `revoke-delegate-stx` and then re-delegate with a higher amount to the same pool operator using `delegate-stx`.
-- **Pool Operators** increase their delegators' locked amount by calling `delegate-stack-increase` and then stacking the increased amount with either `stack-aggregation-commit-indexed` (if not already committed) or `stack-aggregation-increase` (if the commit has already been made).
-
-## Solo Stackers
-
-Solo stackers can add more STX to their active stacking position by calling the `stack-increase` function. The new amount takes effect from the next stacking cycle.
-
-The `stack-increase` function locks an additional amount of STX from your account. Your account must be actively stacking and not delegating, and you must have enough unlocked STX to cover the increase.
-
-
-
-Function source code
-
-```clojure
-;; Increase the number of STX locked.
-;; *New in Stacks 2.1*
-;; This method locks up an additional amount of STX from `tx-sender`'s, indicated
-;; by `increase-by`. The `tx-sender` must already be Stacking & must not be
-;; straddling more than one signer-key for the cycles effected.
-;; Refer to `verify-signer-key-sig` for more information on the authorization parameters
-;; included here.
-(define-public (stack-increase
- (increase-by uint)
- (signer-sig (optional (buff 65)))
- (signer-key (buff 33))
- (max-amount uint)
- (auth-id uint))
- (let ((stacker-info (stx-account tx-sender))
- (amount-stacked (get locked stacker-info))
- (amount-unlocked (get unlocked stacker-info))
- (unlock-height (get unlock-height stacker-info))
- (cur-cycle (current-pox-reward-cycle))
- (first-increased-cycle (+ cur-cycle u1))
- (stacker-state (unwrap! (map-get? stacking-state
- { stacker: tx-sender })
- (err ERR_STACK_INCREASE_NOT_LOCKED)))
- (cur-pox-addr (get pox-addr stacker-state))
- (cur-period (get lock-period stacker-state)))
- ;; tx-sender must be currently locked
- (asserts! (> amount-stacked u0)
- (err ERR_STACK_INCREASE_NOT_LOCKED))
- ;; must be called with positive `increase-by`
- (asserts! (>= increase-by u1)
- (err ERR_STACKING_INVALID_AMOUNT))
- ;; stacker must have enough stx to lock
- (asserts! (>= amount-unlocked increase-by)
- (err ERR_STACKING_INSUFFICIENT_FUNDS))
- ;; must be called directly by the tx-sender or by an allowed contract-caller
- (asserts! (check-caller-allowed)
- (err ERR_STACKING_PERMISSION_DENIED))
- ;; stacker must be directly stacking
- (asserts! (> (len (get reward-set-indexes stacker-state)) u0)
- (err ERR_STACKING_IS_DELEGATED))
- ;; stacker must not be delegating
- (asserts! (is-none (get delegated-to stacker-state))
- (err ERR_STACKING_IS_DELEGATED))
-
- ;; Validate that amount is less than or equal to `max-amount`
- (asserts! (>= max-amount (+ increase-by amount-stacked)) (err ERR_SIGNER_AUTH_AMOUNT_TOO_HIGH))
-
- ;; Verify signature from delegate that allows this sender for this cycle
- (try! (consume-signer-key-authorization cur-pox-addr cur-cycle "stack-increase" cur-period signer-sig signer-key increase-by max-amount auth-id))
-
- ;; update reward cycle amounts
- (asserts! (is-some (fold increase-reward-cycle-entry
- (get reward-set-indexes stacker-state)
- (some { first-cycle: first-increased-cycle,
- reward-cycle: (get first-reward-cycle stacker-state),
- stacker: tx-sender,
- add-amount: increase-by,
- signer-key: signer-key })))
- (err ERR_INVALID_INCREASE))
- ;; NOTE: stacking-state map is unchanged: it does not track amount-stacked in PoX-4
- (ok { stacker: tx-sender, total-locked: (+ amount-stacked increase-by)})))
-```
-
-
-The arguments are:
-
-* Increase by: the amount of uSTX to add to your lock amount.
-* Signer public key: the public key used for signing. This can stay the same, or you can use a new key.
-* Signer signature: a signature proving control of your signing key
-* Max Amount: This parameter is used to validate the signer signature provided. It represents the maximum number of uSTX (1 STX = 1,000,000 uSTX) that can be stacked in this transaction.
-* Auth Id: This parameter is used to validate the signer signature provided. It is a random integer that prevents the re-use of this particular signer signature.
-
-## Delegators
-
-Delegators have to increase their delegated amount in two steps.
-
-### Step 1: Revoke Your Current Delegation
-
-Before increasing your delegation, cancel your current delegation through the `revoke-delegate-stx` function, so that you can delegate an increased amount of STX afterwards.
-
-
-
-Function source code
-
-```clojure
-;; Revokes the delegation to the current stacking pool.
-;; New in pox-4: Fails if the delegation was already revoked.
-;; Returns the last delegation state.
-(define-public (revoke-delegate-stx)
- (let ((last-delegation-state (get-check-delegation tx-sender)))
- ;; must be called directly by the tx-sender or by an allowed contract-caller
- (asserts! (check-caller-allowed)
- (err ERR_STACKING_PERMISSION_DENIED))
- (asserts! (is-some last-delegation-state) (err ERR_DELEGATION_ALREADY_REVOKED))
- (asserts! (map-delete delegation-state { stacker: tx-sender }) (err ERR_DELEGATION_ALREADY_REVOKED))
- (ok last-delegation-state)))
-```
-
-
-### Step 2: Delegate with a Higher Amount
-
-After revoking, call the `delegate-stx` function with your new, higher amount. This function does not directly delegate the STX, but rather allows the pool operator to issue the stacking lock on behalf of the user calling this function.
-
-
-
-Function source code
-
-```clojure
-;; Delegate to `delegate-to` the ability to stack from a given address.
-;; This method _does not_ lock the funds, rather, it allows the delegate
-;; to issue the stacking lock.
-;; The caller specifies:
-;; * amount-ustx: the total amount of ustx the delegate may be allowed to lock
-;; * until-burn-ht: an optional burn height at which this delegation expires
-;; * pox-addr: an optional address to which any rewards *must* be sent
-(define-public (delegate-stx (amount-ustx uint)
- (delegate-to principal)
- (until-burn-ht (optional uint))
- (pox-addr (optional { version: (buff 1), hashbytes: (buff 32) })))
-
- (begin
- ;; must be called directly by the tx-sender or by an allowed contract-caller
- (asserts! (check-caller-allowed)
- (err ERR_STACKING_PERMISSION_DENIED))
-
- ;; delegate-stx no longer requires the delegator to not currently
- ;; be stacking.
- ;; delegate-stack-* functions assert that
- ;; 1. users can't swim in two pools at the same time.
- ;; 2. users can't switch pools without cool down cycle.
- ;; Other pool admins can't increase or extend.
- ;; 3. users can't join a pool while already directly stacking.
-
- ;; pox-addr, if given, must be valid
- (match pox-addr
- address
- (asserts! (check-pox-addr-version (get version address))
- (err ERR_STACKING_INVALID_POX_ADDRESS))
- true)
-
- ;; tx-sender must not be delegating
- (asserts! (is-none (get-check-delegation tx-sender))
- (err ERR_STACKING_ALREADY_DELEGATED))
-
- ;; add delegation record
- (map-set delegation-state
- { stacker: tx-sender }
- { amount-ustx: amount-ustx,
- delegated-to: delegate-to,
- until-burn-ht: until-burn-ht,
- pox-addr: pox-addr })
-
- (ok true)))
-```
-
-
-
-The arguments here are unchanged from previous versions of PoX:
-
-* Amount: Denoted in uSTX (1 STX = 1,000,000 uSTX)
-* Delegate to: the STX address of the pool operator they're delegating to. Note that this is different from the “signer key” used. Instead, this is the STX address that is used to make PoX transactions.
-* Until burn height: an optional argument representing the BTC block height when the delegation expires. If none is used, the delegation permission expires only when explicitly revoked.
-* Pox Address: an optional BTC address that, if specified, the signer must use to accept this delegation
-
-{% hint style="info" %}
-Make sure the revocation is successful before initiating a new delegation. Otherwise, the `delegate-stx` transaction will fail.
-{% endhint %}
-
-## Pool Operators
-
-Pool operators can increase the total stacking amount through a two-step process. First, you have to update the delegation's locked amount with `delegate-stack-increase`. Then, you can stack the increased amount by committing it in a future cycle, or increasing an already committed position.
-
-### Step 1: Increase the Locked Amount
-
-The `delegate-stack-increase` function allows a pool operator to add more STX to the existing locked position for a given delegator. It performs necessary checks and updates the delegation state with the increased amount.
-
-
-
-Function source code
-
-```clojure
-;; As a delegator, increase an active Stacking lock, issuing a "partial commitment" for the
-;; increased cycles.
-;; *New in Stacks 2.1*
-;; This method increases `stacker`'s current lockup and partially commits the additional
-;; STX to `pox-addr`
-(define-public (delegate-stack-increase
- (stacker principal)
- (pox-addr { version: (buff 1), hashbytes: (buff 32) })
- (increase-by uint))
- (let ((stacker-info (stx-account stacker))
- (existing-lock (get locked stacker-info))
- (available-stx (get unlocked stacker-info))
- (unlock-height (get unlock-height stacker-info)))
-
- ;; must be called with positive `increase-by`
- (asserts! (>= increase-by u1)
- (err ERR_STACKING_INVALID_AMOUNT))
-
- (let ((unlock-in-cycle (burn-height-to-reward-cycle unlock-height))
- (cur-cycle (current-pox-reward-cycle))
- (first-increase-cycle (+ cur-cycle u1))
- (last-increase-cycle (- unlock-in-cycle u1))
- (cycle-count (try! (if (<= first-increase-cycle last-increase-cycle)
- (ok (+ u1 (- last-increase-cycle first-increase-cycle)))
- (err ERR_STACKING_INVALID_LOCK_PERIOD))))
- (new-total-locked (+ increase-by existing-lock))
- (stacker-state
- (unwrap! (map-get? stacking-state { stacker: stacker })
- (err ERR_STACK_INCREASE_NOT_LOCKED))))
-
- ;; must be called directly by the tx-sender or by an allowed contract-caller
- (asserts! (check-caller-allowed)
- (err ERR_STACKING_PERMISSION_DENIED))
-
- ;; stacker must not be directly stacking
- (asserts! (is-eq (len (get reward-set-indexes stacker-state)) u0)
- (err ERR_STACKING_NOT_DELEGATED))
-
- ;; stacker must be delegated to tx-sender
- (asserts! (is-eq (unwrap! (get delegated-to stacker-state)
- (err ERR_STACKING_NOT_DELEGATED))
- tx-sender)
- (err ERR_STACKING_PERMISSION_DENIED))
-
- ;; stacker must be currently locked
- (asserts! (> existing-lock u0)
- (err ERR_STACK_INCREASE_NOT_LOCKED))
-
- ;; stacker must have enough stx to lock
- (asserts! (>= available-stx increase-by)
- (err ERR_STACKING_INSUFFICIENT_FUNDS))
-
- ;; stacker must have delegated to the caller
- (let ((delegation-info (unwrap! (get-check-delegation stacker) (err ERR_STACKING_PERMISSION_DENIED)))
- (delegated-to (get delegated-to delegation-info))
- (delegated-amount (get amount-ustx delegation-info))
- (delegated-pox-addr (get pox-addr delegation-info))
- (delegated-until (get until-burn-ht delegation-info)))
- ;; must have delegated to tx-sender
- (asserts! (is-eq delegated-to tx-sender)
- (err ERR_STACKING_PERMISSION_DENIED))
- ;; must have delegated enough stx
- (asserts! (>= delegated-amount new-total-locked)
- (err ERR_DELEGATION_TOO_MUCH_LOCKED))
- ;; if pox-addr is set, must be equal to pox-addr
- (asserts! (match delegated-pox-addr
- specified-pox-addr (is-eq pox-addr specified-pox-addr)
- true)
- (err ERR_DELEGATION_POX_ADDR_REQUIRED))
- ;; delegation must not expire before lock period
- (asserts! (match delegated-until
- until-burn-ht
- (>= until-burn-ht unlock-height)
- true)
- (err ERR_DELEGATION_EXPIRES_DURING_LOCK)))
-
- ;; delegate stacking does minimal-can-stack-stx
- (try! (minimal-can-stack-stx pox-addr new-total-locked first-increase-cycle (+ u1 (- last-increase-cycle first-increase-cycle))))
-
- ;; register the PoX address with the amount stacked via partial stacking
- ;; before it can be included in the reward set, this must be committed!
- (add-pox-partial-stacked pox-addr first-increase-cycle cycle-count increase-by)
-
- ;; stacking-state is unchanged, so no need to update
-
- ;; return the lock-up information, so the node can actually carry out the lock.
- (ok { stacker: stacker, total-locked: new-total-locked}))))
-```
-
-
-The arguments are:
-
-* Stacker: the STX address of the delegator
-* Pox Address: The BTC address of the pool operator where they will receive the BTC rewards. If the delegator has set his own BTC address in the `delegate-stx` call, this address will have to be the same one, otherwise the contract call will fail.
-* Increase by: the amount of uSTX to add to the delegator's locked amount.
-
-### Step 2: Stack the Increased Amount
-
-Once the locked amount is updated, the operator must commit the change. There are two functions that can be used to stack the increased amount:
-
-#### A. If the Commit Has Not Yet Been Made: `stack-aggregation-commit-indexed`
-
-This function stacks the total locked amount for an upcoming reward cycle. Note that the `stack-aggregation-commit-indexed` function wraps the `inner-stack-aggregation-commit` function. The wrapped inner function is included here.
-
-
-
-Function source code
-
-```clojure
-;; Commit partially stacked STX and allocate a new PoX reward address slot.
-;; This allows a stacker/delegate to lock fewer STX than the minimal threshold in multiple transactions,
-;; so long as: 1. The pox-addr is the same.
-;; 2. This "commit" transaction is called _before_ the PoX anchor block.
-;; This ensures that each entry in the reward set returned to the stacks-node is greater than the threshold,
-;; but does not require it be all locked up within a single transaction
-;;
-;; Returns (ok uint) on success, where the given uint is the reward address's index in the list of reward
-;; addresses allocated in this reward cycle. This index can then be passed to `stack-aggregation-increase`
-;; to later increment the STX this PoX address represents, in amounts less than the stacking minimum.
-;;
-;; *New in Stacks 2.1.*
-(define-private (inner-stack-aggregation-commit (pox-addr { version: (buff 1), hashbytes: (buff 32) })
- (reward-cycle uint)
- (signer-sig (optional (buff 65)))
- (signer-key (buff 33))
- (max-amount uint)
- (auth-id uint))
- (let ((partial-stacked
- ;; fetch the partial commitments
- (unwrap! (map-get? partial-stacked-by-cycle { pox-addr: pox-addr, sender: tx-sender, reward-cycle: reward-cycle })
- (err ERR_STACKING_NO_SUCH_PRINCIPAL))))
- ;; must be called directly by the tx-sender or by an allowed contract-caller
- (asserts! (check-caller-allowed)
- (err ERR_STACKING_PERMISSION_DENIED))
- (let ((amount-ustx (get stacked-amount partial-stacked)))
- (try! (consume-signer-key-authorization pox-addr reward-cycle "agg-commit" u1 signer-sig signer-key amount-ustx max-amount auth-id))
- (try! (can-stack-stx pox-addr amount-ustx reward-cycle u1))
- ;; Add the pox addr to the reward cycle, and extract the index of the PoX address
- ;; so the delegator can later use it to call stack-aggregation-increase.
- (let ((add-pox-addr-info
- (add-pox-addr-to-ith-reward-cycle
- u0
- { pox-addr: pox-addr,
- first-reward-cycle: reward-cycle,
- num-cycles: u1,
- reward-set-indexes: (list),
- stacker: none,
- signer: signer-key,
- amount-ustx: amount-ustx,
- i: u0 }))
- (pox-addr-index (unwrap-panic
- (element-at (get reward-set-indexes add-pox-addr-info) u0))))
-
- ;; don't update the stacking-state map,
- ;; because it _already has_ this stacker's state
- ;; don't lock the STX, because the STX is already locked
- ;;
- ;; clear the partial-stacked state, and log it
- (map-delete partial-stacked-by-cycle { pox-addr: pox-addr, sender: tx-sender, reward-cycle: reward-cycle })
- (map-set logged-partial-stacked-by-cycle { pox-addr: pox-addr, sender: tx-sender, reward-cycle: reward-cycle } partial-stacked)
- (ok pox-addr-index)))))
-```
-
-
-The arguments are:
-
-* Pox Address: the BTC address to receive rewards
-* Reward-cycle: a reward cycle in the future (see the note above on passing the correct reward cycle)
-* Signer public key: the public key of your signer
-* Signer signature: A signature proving control of your signing key
-* Max Amount: This parameter is used to validate the signer signature provided. It represents the maximum number of uSTX (1 stx = 1,000,000 uSTX) that can be stacked in this transaction.
-* Auth Id: This parameter is used to validate the signer signature provided. It is a random integer that prevents the re-use of this particular signer signature.
-
-#### B. If the Commit Has Already Been Made: `stack-aggregation-increase`
-
-If you have previously committed an amount, you can further increase the stacked position by calling `stack-aggregation-increase`. This function adds an additional amount of STX to the already committed delegation.
-
-
-
-Function source code
-
-```clojure
-;; Commit partially stacked STX to a PoX address which has already received some STX (more than the Stacking min).
-;; This allows a delegator to lock up marginally more STX from new delegates, even if they collectively do not
-;; exceed the Stacking minimum, so long as the target PoX address already represents at least as many STX as the
-;; Stacking minimum.
-;;
-;; The `reward-cycle-index` is emitted as a contract event from `stack-aggregation-commit` when the initial STX are
-;; locked up by this delegator. It must be passed here to add more STX behind this PoX address. If the delegator
-;; called `stack-aggregation-commit` multiple times for the same PoX address, then any such `reward-cycle-index` will
-;; work here.
-;;
-;; *New in Stacks 2.1*
-;;
-(define-public (stack-aggregation-increase (pox-addr { version: (buff 1), hashbytes: (buff 32) })
- (reward-cycle uint)
- (reward-cycle-index uint))
- (let ((partial-stacked
- ;; fetch the partial commitments
- (unwrap! (map-get? partial-stacked-by-cycle { pox-addr: pox-addr, sender: tx-sender, reward-cycle: reward-cycle })
- (err ERR_STACKING_NO_SUCH_PRINCIPAL))))
-
- ;; must be called directly by the tx-sender or by an allowed contract-caller
- (asserts! (check-caller-allowed)
- (err ERR_STACKING_PERMISSION_DENIED))
-
- ;; reward-cycle must be in the future
- (asserts! (> reward-cycle (current-pox-reward-cycle))
- (err ERR_STACKING_INVALID_LOCK_PERIOD))
-
- (let ((amount-ustx (get stacked-amount partial-stacked))
- ;; reward-cycle must point to an existing record in reward-cycle-total-stacked
- ;; infallible; getting something from partial-stacked-by-cycle succeeded so this must succeed
- (existing-total (unwrap-panic (map-get? reward-cycle-total-stacked { reward-cycle: reward-cycle })))
- ;; reward-cycle and reward-cycle-index must point to an existing record in reward-cycle-pox-address-list
- (existing-entry (unwrap! (map-get? reward-cycle-pox-address-list { reward-cycle: reward-cycle, index: reward-cycle-index })
- (err ERR_DELEGATION_NO_REWARD_SLOT)))
- (increased-ustx (+ (get total-ustx existing-entry) amount-ustx))
- (total-ustx (+ (get total-ustx existing-total) amount-ustx)))
-
- ;; must be stackable
- (try! (minimal-can-stack-stx pox-addr total-ustx reward-cycle u1))
-
- ;; new total must exceed the stacking minimum
- (asserts! (<= (get-stacking-minimum) total-ustx)
- (err ERR_STACKING_THRESHOLD_NOT_MET))
-
- ;; there must *not* be a stacker entry (since this is a delegator)
- (asserts! (is-none (get stacker existing-entry))
- (err ERR_DELEGATION_WRONG_REWARD_SLOT))
-
- ;; the given PoX address must match the one on record
- (asserts! (is-eq pox-addr (get pox-addr existing-entry))
- (err ERR_DELEGATION_WRONG_REWARD_SLOT))
-
- ;; update the pox-address list -- bump the total-ustx
- (map-set reward-cycle-pox-address-list
- { reward-cycle: reward-cycle, index: reward-cycle-index }
- { pox-addr: pox-addr,
- total-ustx: increased-ustx,
- stacker: none,
- ;; TODO: this must be authorized with a signature, or tx-sender allowance!
- signer: (get signer existing-entry) })
-
- ;; update the total ustx in this cycle
- (map-set reward-cycle-total-stacked
- { reward-cycle: reward-cycle }
- { total-ustx: total-ustx })
-
- ;; don't update the stacking-state map,
- ;; because it _already has_ this stacker's state
- ;; don't lock the STX, because the STX is already locked
- ;;
- ;; clear the partial-stacked state, and log it
- (map-delete partial-stacked-by-cycle { pox-addr: pox-addr, sender: tx-sender, reward-cycle: reward-cycle })
- (map-set logged-partial-stacked-by-cycle { pox-addr: pox-addr, sender: tx-sender, reward-cycle: reward-cycle } partial-stacked)
- (ok true))))
-```
-
-
-The arguments are:
-
-* Pox Address: the BTC address to receive rewards
-* Reward Cycle: a reward cycle in the future (see the note above on passing the correct reward cycle)
-* Reward Cycle Index: the index returned by the successful `stack-aggregation-commit-indexed` function for the given cycle
-* Signer signature: A signature proving control of your signing key
-* Signer public key: the public key of your signer
-* Max Amount: This parameter is used to validate the signer signature provided. It represents the maximum number of uSTX (1 stx = 1,000,000 uSTX) that can be stacked in this transaction.
-* Auth Id: This parameter is used to validate the signer signature provided. It is a random integer that prevents the re-use of this particular signer signature.
-
-{% hint style="warning" %}
-- **Sequential Process:** First call `delegate-stack-increase` to update the locked amount of a delegation. Then, commit the change:
- - Using `stack-aggregation-commit-indexed` if this is the first commit in the given cycle.
- - Using `stack-aggregation-increase` if you have already committed in the cycle you want to increase.
-
-Failing to commit (or properly increase after a commit) will result in the increased delegation not taking effect in upcoming stacking cycles.
-{% endhint %}
diff --git a/guides-and-tutorials/stack-stx/operate-a-pool.md b/guides-and-tutorials/stack-stx/operate-a-pool.md
deleted file mode 100644
index 32df43dc84..0000000000
--- a/guides-and-tutorials/stack-stx/operate-a-pool.md
+++ /dev/null
@@ -1,597 +0,0 @@
-# Operate a Pool
-
-This doc assumes you are familiar with stacking at a conceptual level. If not, you may want to read the [Stacking](../../concepts/block-production/stacking.md) concept guide.
-
-The guide below applies to those who want to operate a pool, meaning they want to have stackers delegate STX tokens to them. If you choose to operate a pool you will either need to run your own signer or collaborate with one.
-
-### Pool Operator Stacking Flow
-
-For pool operators, the flow is a bit different than solo stacking. Remember that as a pool operator, other stackers are delegating their STX to you to stack on behalf of them. This additional role adds a couple of extra steps to your stacking flow if operating as a pool operator.
-
-Similar to the changes to solo Stacking, the big difference for delegation flows is the inclusion of signer keys and signatures. Because pool operators need to make transactions to “finalize” a delegation, these new arguments add new complexities to the stacking flow.
-
-#### Delegator initiates delegation
-
-{% hint style="info" %}
-This step is not required to apply to pool operators/signers. It is included here to illustrate the end-to-end flow, but if you are operating as a pool operator/signer you will not have to perform this step. Instead, users delegate their STX to you as the pool operator.
-{% endhint %}
-
-The first step, where the delegator sets up their delegation to a pool operator, is to call `delegate-stx`. This function does not directly delegate the STX, but rather allows the pool operator to issue the stacking lock on behalf of the user calling this function. You can think of calling this function as the delegator giving permission to the pool operator to stack on their behalf.
-
-
-
-Function source code
-
-```clojure
-;; Delegate to `delegate-to` the ability to stack from a given address.
-;; This method _does not_ lock the funds, rather, it allows the delegate
-;; to issue the stacking lock.
-;; The caller specifies:
-;; * amount-ustx: the total amount of ustx the delegate may be allowed to lock
-;; * until-burn-ht: an optional burn height at which this delegation expires
-;; * pox-addr: an optional address to which any rewards *must* be sent
-(define-public (delegate-stx (amount-ustx uint)
- (delegate-to principal)
- (until-burn-ht (optional uint))
- (pox-addr (optional { version: (buff 1), hashbytes: (buff 32) })))
-
- (begin
- ;; must be called directly by the tx-sender or by an allowed contract-caller
- (asserts! (check-caller-allowed)
- (err ERR_STACKING_PERMISSION_DENIED))
-
- ;; delegate-stx no longer requires the delegator to not currently
- ;; be stacking.
- ;; delegate-stack-* functions assert that
- ;; 1. users can't swim in two pools at the same time.
- ;; 2. users can't switch pools without cool down cycle.
- ;; Other pool admins can't increase or extend.
- ;; 3. users can't join a pool while already directly stacking.
-
- ;; pox-addr, if given, must be valid
- (match pox-addr
- address
- (asserts! (check-pox-addr-version (get version address))
- (err ERR_STACKING_INVALID_POX_ADDRESS))
- true)
-
- ;; tx-sender must not be delegating
- (asserts! (is-none (get-check-delegation tx-sender))
- (err ERR_STACKING_ALREADY_DELEGATED))
-
- ;; add delegation record
- (map-set delegation-state
- { stacker: tx-sender }
- { amount-ustx: amount-ustx,
- delegated-to: delegate-to,
- until-burn-ht: until-burn-ht,
- pox-addr: pox-addr })
-
- (ok true)))
-```
-
-
-
-The arguments here are unchanged from previous versions of PoX:
-
-* Amount: Denoted in uSTX (1 STX = 1,000,000 uSTX)
-* Delegate to: the STX address of the pool operator they're delegating to. Note that this is different from the “signer key” used. Instead, this is the STX address that is used to make PoX transactions.
-* Until burn height: an optional argument representing the BTC block height when the delegation expires. If none is used, the delegation permission expires only when explicitly revoked.
-* Pox Address: an optional BTC address that, if specified, the signer must use to accept this delegation
-
-#### Pool operator “activates” the delegation
-
-Just as in the older PoX contract, after a delegator calls the `delegate-stx` function, the pool operator calls `delegate-stack-stx` to commit the delegator’s STX.
-
-
-
-Function source code
-
-```clojure
-;; As a delegate, stack the given principal's STX using partial-stacked-by-cycle
-;; Once the delegate has stacked > minimum, the delegate should call stack-aggregation-commit
-(define-public (delegate-stack-stx (stacker principal)
- (amount-ustx uint)
- (pox-addr { version: (buff 1), hashbytes: (buff 32) })
- (start-burn-ht uint)
- (lock-period uint))
- ;; this stacker's first reward cycle is the _next_ reward cycle
- (let ((first-reward-cycle (+ u1 (current-pox-reward-cycle)))
- (specified-reward-cycle (+ u1 (burn-height-to-reward-cycle start-burn-ht)))
- (unlock-burn-height (reward-cycle-to-burn-height (+ (current-pox-reward-cycle) u1 lock-period))))
- ;; the start-burn-ht must result in the next reward cycle, do not allow stackers
- ;; to "post-date" their `stack-stx` transaction
- (asserts! (is-eq first-reward-cycle specified-reward-cycle)
- (err ERR_INVALID_START_BURN_HEIGHT))
-
- ;; must be called directly by the tx-sender or by an allowed contract-caller
- (asserts! (check-caller-allowed)
- (err ERR_STACKING_PERMISSION_DENIED))
-
- ;; stacker must have delegated to the caller
- (let ((delegation-info (unwrap! (get-check-delegation stacker) (err ERR_STACKING_PERMISSION_DENIED))))
- ;; must have delegated to tx-sender
- (asserts! (is-eq (get delegated-to delegation-info) tx-sender)
- (err ERR_STACKING_PERMISSION_DENIED))
- ;; must have delegated enough stx
- (asserts! (>= (get amount-ustx delegation-info) amount-ustx)
- (err ERR_DELEGATION_TOO_MUCH_LOCKED))
- ;; if pox-addr is set, must be equal to pox-addr
- (asserts! (match (get pox-addr delegation-info)
- specified-pox-addr (is-eq pox-addr specified-pox-addr)
- true)
- (err ERR_DELEGATION_POX_ADDR_REQUIRED))
- ;; delegation must not expire before lock period
- (asserts! (match (get until-burn-ht delegation-info)
- until-burn-ht (>= until-burn-ht
- unlock-burn-height)
- true)
- (err ERR_DELEGATION_EXPIRES_DURING_LOCK))
- )
-
- ;; stacker principal must not be stacking
- (asserts! (is-none (get-stacker-info stacker))
- (err ERR_STACKING_ALREADY_STACKED))
-
- ;; the Stacker must have sufficient unlocked funds
- (asserts! (>= (stx-get-balance stacker) amount-ustx)
- (err ERR_STACKING_INSUFFICIENT_FUNDS))
-
- ;; ensure that stacking can be performed
- (try! (minimal-can-stack-stx pox-addr amount-ustx first-reward-cycle lock-period))
-
- ;; register the PoX address with the amount stacked via partial stacking
- ;; before it can be included in the reward set, this must be committed!
- (add-pox-partial-stacked pox-addr first-reward-cycle lock-period amount-ustx)
-
- ;; add stacker record
- (map-set stacking-state
- { stacker: stacker }
- { pox-addr: pox-addr,
- first-reward-cycle: first-reward-cycle,
- reward-set-indexes: (list),
- lock-period: lock-period,
- delegated-to: (some tx-sender) })
-
- ;; return the lock-up information, so the node can actually carry out the lock.
- (ok { stacker: stacker,
- lock-amount: amount-ustx,
- unlock-burn-height: unlock-burn-height })))
-```
-
-
-
-The arguments are:
-
-* Stacker: the STX address of the delegator
-* Amount: denoted in uSTX (1 STX = 1,000,000 uSTX)
-* Pox Address: The BTC address of the pool operator where they will receive the BTC rewards. If the delegator has set his own BTC address in the `delegate-stx` call, this address will have to be the same one, otherwise the contract call will fail.
-* Start burn height: The BTC block height in which delegation can begin. This field is used to ensure that an old transaction intended for an earlier cycle will fail, and also prevents callers from "post-dating" the call to a future cycle. The best option here is to add 1 or 2 to the current BTC block height when you initiate this transaction. Note that the delegation will not actively be stacked at this block height, but whatever reward cycle is passed in the aggregation commit function (explained below).
-* Lock period: number of cycles to lock for. If the delegator provided the until burn height argument, then the end of these cycles cannot be past the expiration provided. The maximum lock period that a pool operator can provide in this function call is 12.
-
-This step also allows the pool operator to proactively choose which Stackers they’ll accept delegation from. For “closed” pools, the pool operator will only call this function for approved Stackers. It is up to each pool operator who runs a closed pool to implement this process.
-
-This step can be repeated for multiple Stackers before going to the next step.
-
-{% hint style="info" %}
-If you look at the function source code, you'll see that the `delegate-stack-stx` function sets the stacker's first reward cycle to be the _next_ reward cycle.
-
-When generating your signature and your `stack-aggregation-commit-indexed` transaction, you'll want to make sure that the reward cycles match.
-
-So if you are in cycle 557 when you call the `delegate-stack-stx` function, you'll want to pass in cycle 558 or higher when you generate your signature and your `stack-aggregation-commit-indexed` transaction.
-
-With `stack-aggregation-commit-indexed`, the `reward-cycle` arg is saying "I'm commiting these stacks to be stacked in cycle N". But the `delegate-stack-stx` transaction gets you setup for next cycles, aka 558 and higher.
-
-Also make sure that, when you generate your signature, you use 558 or higher as the reward cycle. In solo stacking methods, you use the current reward cycle in the signature, but not for `stack-aggregation-commit-indexed`. This is because with `stack-aggregation-commit-indexed` you can commit stacks for future cycles, not just the N+1 cycle.
-{% endhint %}
-
-#### Pool operator “commits” delegated STX
-
-The next step is for the pool operator to call `stack-aggregation-commit-indexed`.
-
-{% hint style="info" %}
-In the contract source code, you'll notice a similarly named function called `stack-aggregation-commit`. This is a legacy function that makes it difficult to increase the stacking amount, as it does not return the reward index of the stacking slot, which is required in order to call the `stack-aggregation-increase` function. We recommend using `stack-aggregation-commit-indexed`.
-{% endhint %}
-
-
-
-Function source code
-
-Note that the `stack-aggregation-commit-indexed` function wraps the `inner-stack-aggregation-commit` function. The wrapped inner function is included here.
-
-Check out the [deployed contract](https://explorer.hiro.so/txid/SP000000000000000000002Q6VF78.pox-4?chain=mainnet) to see the flow of contract calls.
-
-```clojure
-;; Commit partially stacked STX and allocate a new PoX reward address slot.
-;; This allows a stacker/delegate to lock fewer STX than the minimal threshold in multiple transactions,
-;; so long as: 1. The pox-addr is the same.
-;; 2. This "commit" transaction is called _before_ the PoX anchor block.
-;; This ensures that each entry in the reward set returned to the stacks-node is greater than the threshold,
-;; but does not require it be all locked up within a single transaction
-;;
-;; Returns (ok uint) on success, where the given uint is the reward address's index in the list of reward
-;; addresses allocated in this reward cycle. This index can then be passed to `stack-aggregation-increase`
-;; to later increment the STX this PoX address represents, in amounts less than the stacking minimum.
-;;
-;; *New in Stacks 2.1.*
-(define-private (inner-stack-aggregation-commit (pox-addr { version: (buff 1), hashbytes: (buff 32) })
- (reward-cycle uint)
- (signer-sig (optional (buff 65)))
- (signer-key (buff 33))
- (max-amount uint)
- (auth-id uint))
- (let ((partial-stacked
- ;; fetch the partial commitments
- (unwrap! (map-get? partial-stacked-by-cycle { pox-addr: pox-addr, sender: tx-sender, reward-cycle: reward-cycle })
- (err ERR_STACKING_NO_SUCH_PRINCIPAL))))
- ;; must be called directly by the tx-sender or by an allowed contract-caller
- (asserts! (check-caller-allowed)
- (err ERR_STACKING_PERMISSION_DENIED))
- (let ((amount-ustx (get stacked-amount partial-stacked)))
- (try! (consume-signer-key-authorization pox-addr reward-cycle "agg-commit" u1 signer-sig signer-key amount-ustx max-amount auth-id))
- (try! (can-stack-stx pox-addr amount-ustx reward-cycle u1))
- ;; Add the pox addr to the reward cycle, and extract the index of the PoX address
- ;; so the delegator can later use it to call stack-aggregation-increase.
- (let ((add-pox-addr-info
- (add-pox-addr-to-ith-reward-cycle
- u0
- { pox-addr: pox-addr,
- first-reward-cycle: reward-cycle,
- num-cycles: u1,
- reward-set-indexes: (list),
- stacker: none,
- signer: signer-key,
- amount-ustx: amount-ustx,
- i: u0 }))
- (pox-addr-index (unwrap-panic
- (element-at (get reward-set-indexes add-pox-addr-info) u0))))
-
- ;; don't update the stacking-state map,
- ;; because it _already has_ this stacker's state
- ;; don't lock the STX, because the STX is already locked
- ;;
- ;; clear the partial-stacked state, and log it
- (map-delete partial-stacked-by-cycle { pox-addr: pox-addr, sender: tx-sender, reward-cycle: reward-cycle })
- (map-set logged-partial-stacked-by-cycle { pox-addr: pox-addr, sender: tx-sender, reward-cycle: reward-cycle } partial-stacked)
- (ok pox-addr-index)))))
-```
-
-
-
-At this point, the STX are committed to the pool operator, and the pool operator has some “aggregate balance” of committed STX. The pool operator is not actually eligible for reward slots and signer initialization until this step is finished.
-
-The pool operator cannot call this function until the total number of STX committed is larger than the minimum threshold required to Stack. This minimum stacking threshold is a function of the total number of STX stacked divided by the available number of reward slots.
-
-{% hint style="info" %}
-This number varies and can be found by visiting the pox endpoint of Hiro's API at [https://api.hiro.so/v2/pox](https://api.hiro.so/v2/pox) and looking at the `min_threshold_ustx` field. (1 STX = 1,000,000 uSTX).
-{% endhint %}
-
-Once the threshold is reached, the pool operator calls `stack-aggregation-commit-indexed`. This is the point where you as the pool operator must provide your signer key and signer key signature. The arguments are:
-
-* Pox Address: the BTC address to receive rewards
-* Reward-cycle: a reward cycle in the future (see the note above on passing the correct reward cycle)
-* Signer public key: the public key of your signer (remember that this may be different than the address you are using to operate the pool, but this step is how you associate the two together)
-* Signer signature: A signature proving control of your signing key (details on how to do this are below)
-* Max Amount: This parameter is used to validate the signer signature provided. It represents the maximum number of uSTX (1 stx = 1,000,000 uSTX) that can be stacked in this transaction.
-* Auth Id: This parameter is used to validate the signer signature provided. It is a random integer that prevents the re-use of this particular signer signature.
-
-{% hint style="info" %}
-In the Definitions and Roles section in the previous document, we described how the pool operator and signer may be the same entity, but not necessarily have the same address.
-
-Signers who are also pool operators and wish to have STX delegated to them should have a separate keychain associated with their pool operator account in order to make Stacking transactions such as `delegate-stack-stx` and `stack-aggregation-commit-indexed`.
-
-So, as a signing entity operating a pool, you should have two accounts:
-
-* Your pool operator account, which you will use to conduct all of the stacking operations we have covered here.
-* Your signer account, which is what you used to set up your signer. This signer public key is what you will pass in to the above aggregation commit function, and is also the key you will use when generating your signer signature.
-
-If you are operating as a signer and a pool operator, you should have a separate key because you might need to rotate your signer key when necessary.
-
-The PoX contract is designed to support rotating the signer key without needing your Stackers to un-stack and re-stack later. You cannot rotate a pool operator key without needing to wait for all delegated Stackers to un-stack and finally re-stack to the new pool operator address.
-
-Because of this limitation of being unable to rotate pool operator addresses, it’s highly recommended to have a separate pool operator key. The benefit of a separate pool operator key is that it can easily be used in existing wallets, including hardware wallets.
-{% endhint %}
-
-Once this succeeds, the signer is eligible for reward slots. The number of reward slots depends on the amount of STX committed to this signer. Even if the signer commits more than the “global minimum”, the minimum amount to receive a slot depends on the amount of STX locked for each cycle.
-
-To act as a signer, each step up to this point must be taken before the prepare phase of the next cycle begins. It is crucial that the signer software is running.
-
-#### Pool operator increases amount committed
-
-Even after the signer commits to a certain amount of STX in the previous step, the signer can increase this amount once more delegations are received. The initial steps must be taken for each Stacker (`delegate-stx` and then `delegate-stack-stx`), and then `stack-aggregation-increase` can be called with the index returned from the first `stack-aggregation-commit-indexed` call and a new signature.
-
-
-
-Function source code
-
-```
-;; Commit partially stacked STX to a PoX address which has already received some STX (more than the Stacking min).
-;; This allows a delegator to lock up marginally more STX from new delegates, even if they collectively do not
-;; exceed the Stacking minimum, so long as the target PoX address already represents at least as many STX as the
-;; Stacking minimum.
-;;
-;; The `reward-cycle-index` is emitted as a contract event from `stack-aggregation-commit` when the initial STX are
-;; locked up by this delegator. It must be passed here to add more STX behind this PoX address. If the delegator
-;; called `stack-aggregation-commit` multiple times for the same PoX address, then any such `reward-cycle-index` will
-;; work here.
-;;
-;; *New in Stacks 2.1*
-;;
-(define-public (stack-aggregation-increase (pox-addr { version: (buff 1), hashbytes: (buff 32) })
- (reward-cycle uint)
- (reward-cycle-index uint))
- (let ((partial-stacked
- ;; fetch the partial commitments
- (unwrap! (map-get? partial-stacked-by-cycle { pox-addr: pox-addr, sender: tx-sender, reward-cycle: reward-cycle })
- (err ERR_STACKING_NO_SUCH_PRINCIPAL))))
-
- ;; must be called directly by the tx-sender or by an allowed contract-caller
- (asserts! (check-caller-allowed)
- (err ERR_STACKING_PERMISSION_DENIED))
-
- ;; reward-cycle must be in the future
- (asserts! (> reward-cycle (current-pox-reward-cycle))
- (err ERR_STACKING_INVALID_LOCK_PERIOD))
-
- (let ((amount-ustx (get stacked-amount partial-stacked))
- ;; reward-cycle must point to an existing record in reward-cycle-total-stacked
- ;; infallible; getting something from partial-stacked-by-cycle succeeded so this must succeed
- (existing-total (unwrap-panic (map-get? reward-cycle-total-stacked { reward-cycle: reward-cycle })))
- ;; reward-cycle and reward-cycle-index must point to an existing record in reward-cycle-pox-address-list
- (existing-entry (unwrap! (map-get? reward-cycle-pox-address-list { reward-cycle: reward-cycle, index: reward-cycle-index })
- (err ERR_DELEGATION_NO_REWARD_SLOT)))
- (increased-ustx (+ (get total-ustx existing-entry) amount-ustx))
- (total-ustx (+ (get total-ustx existing-total) amount-ustx)))
-
- ;; must be stackable
- (try! (minimal-can-stack-stx pox-addr total-ustx reward-cycle u1))
-
- ;; new total must exceed the stacking minimum
- (asserts! (<= (get-stacking-minimum) total-ustx)
- (err ERR_STACKING_THRESHOLD_NOT_MET))
-
- ;; there must *not* be a stacker entry (since this is a delegator)
- (asserts! (is-none (get stacker existing-entry))
- (err ERR_DELEGATION_WRONG_REWARD_SLOT))
-
- ;; the given PoX address must match the one on record
- (asserts! (is-eq pox-addr (get pox-addr existing-entry))
- (err ERR_DELEGATION_WRONG_REWARD_SLOT))
-
- ;; update the pox-address list -- bump the total-ustx
- (map-set reward-cycle-pox-address-list
- { reward-cycle: reward-cycle, index: reward-cycle-index }
- { pox-addr: pox-addr,
- total-ustx: increased-ustx,
- stacker: none,
- ;; TODO: this must be authorized with a signature, or tx-sender allowance!
- signer: (get signer existing-entry) })
-
- ;; update the total ustx in this cycle
- (map-set reward-cycle-total-stacked
- { reward-cycle: reward-cycle }
- { total-ustx: total-ustx })
-
- ;; don't update the stacking-state map,
- ;; because it _already has_ this stacker's state
- ;; don't lock the STX, because the STX is already locked
- ;;
- ;; clear the partial-stacked state, and log it
- (map-delete partial-stacked-by-cycle { pox-addr: pox-addr, sender: tx-sender, reward-cycle: reward-cycle })
- (map-set logged-partial-stacked-by-cycle { pox-addr: pox-addr, sender: tx-sender, reward-cycle: reward-cycle } partial-stacked)
- (ok true))))
-```
-
-
-
-### Step by Step Stacking Guide
-
-Now that you are familiar with the overall stacking flow and the different roles played, let's dive into the step-by-step guide for actually conducting the stacking process as a pool operator.
-
-{% hint style="info" %}
-There are several ways you can go about stacking. This guide will cover using [Leather Earn](https://earn.leather.io), which is a stacking web application and the simplest option.
-
-Additionally, you can choose to call the stacking functions directly from the [deployed contract](https://explorer.hiro.so/txid/SP000000000000000000002Q6VF78.pox-4?chain=mainnet) in the explorer.
-
-The fields and process will be the same, but the UI will differ.
-
-Finally, you can stack using JS and the [@stacks/stacking](https://github.com/hirosystems/stacks.js/tree/main/packages/stacking) package if you prefer. Again, the functions and parameters will be the same, you will just be writing your JS code directly instead of using a UI.
-
-If you are interested in using this method, you'll want to follow the [stacking guide](https://docs.hiro.so/stacks.js/guides/how-to-integrate-stacking) created by Hiro, and be sure to integrate the new parameters described in [Hiro's Nakamoto update doc](https://docs.hiro.so/nakamoto/stacks-js).
-{% endhint %}
-
-### Step 1: Run or work with a signer
-
-This is a necessary prerequisite to stacking as a pool operator. You will either need to run your own signer or work with one and have them conduct step 2 on your behalf and give you their signer signature.
-
-Running a signer involves setting up a hosted production environment that includes both a Stacks Node and the Stacks Signer. For more information, refer to the [running a signer doc](../running-a-signer/).
-
-Once the signer software is running, you'll to keep track of the `stacks_private_key` that you used when configuring your signer software. This will be used in subsequent Stacking transactions.
-
-{% hint style="info" %}
-In the note above about pool operator vs signer keys, this corresponds to your signer key, not your pool operator wallet
-{% endhint %}
-
-### Step 2: Generate a signer key signature
-
-#### Overview of signer keys and signatures
-
-The main difference with Stacking in Nakamoto is that the Signer needs to include new parameters in their Stacking transactions. These are Clarity transactions that pool operators will call when interacting with the `pox-4.clar` contract. Interacting with that contract is how you as a pool operator actually stack the delegated STX tokens.
-
-{% hint style="info" %}
-The current pox-4 contract address can be found by visiting the following endpoint of the Hiro API: [https://api.hiro.so/v2/pox](https://api.hiro.so/v2/pox).
-
-You can then visit the [Stacks Explorer](https://explorer.hiro.so) to view the contract and pass in the contract id.
-
-You may want to review this contract to familiarize yourself with it.
-{% endhint %}
-
-Here is an overview of the new fields you will need to pass in some of your stacking transactions:
-
-1. `signer-key`: the public key that corresponds to the `stacks_private_key` your signer is using.
-2. `signer-signature`: a signature that demonstrates that you actually control your `signer-key`. Because signer keys need to be unique, this is also a safety check to ensure that other Stackers can’t use someone else’s signer key.
-3. `max-amount`: The maximum amount of uSTX (1 STX = 1,000,000 uSTX) that can be locked in the transaction that uses this signature. For example, if calling `stack-aggregation-increase`, then this parameter dictates the maximum amount of uSTX that can be used to add more locked STX to the already committed position.
-4. `auth-id`: a random integer that prevents re-use of a particular signature, similar to how nonces are used with transactions.
-
-Signer signatures are signatures created using a particular signer key. They demonstrate that the controller of that signer key is allowing a Stacker to use their signer's public key. The signer signature’s message hash is created using the following data:
-
-* `method`: a string that indicates the Stacking method that is allowed to utilize this signature. The valid options are `stack-stx`, `stack-extend`, `stack-increase`, `agg-commit` (for `stack-aggregation-commit-indexed`) and `agg-increase` (for `stack-aggregation-increase`).
-* `max-amount`: described above.
-* `auth-id`: described above.
-* `period`: a value between 1 and 12, which indicates how long the Stacker is allowed to lock their STX for in this particular Stacking transaction. For `agg-commit`, this must be equal to 1.
-* `reward-cycle`: This represents the reward cycle in which the Stacking transaction can be confirmed (for `stack-aggregation-commit-indexed`, this has to be set to 1).
-* `pox-address`: The Bitcoin address that is allowed to be used for receiving rewards. This corresponds to the Bitcoin address associated with your signer
-* `config`: This represents the signer configuration file path where the `stacks_private_key` is located, and it is used for signing the generated signature.
-
-Now that we have an overview of role and contents of signatures, let's see how to actually generate them. You have several options available.
-
-**Generating your signature with Degen Lab's stacks.tools**
-
-Degen Lab has a signature generation tool that will generate a signature using their signer. This is the quickest and simplest option. To generate a signature using this method, all you need to do is visit their [signature tool](https://signature.stacking.tools/) and pass in the relevant information as covered on the page.
-
-#### Generating your signature with stacks.js
-
-The [@stacks/stacking](https://www.npmjs.com/package/@stacks/stacking) NPM package provides interfaces to generate and use signer signatures.
-
-There is a function called `signPoxSignature` that will allow you to generate this signature and pass it in to the stacking function.
-
-More information and code samples can be found on [Hiro's Nakamoto docs](https://docs.hiro.so/nakamoto/stacks-js).
-
-#### Generating your signature using the stacks-signer CLI
-
-If you already have your signer configured and set up, you can use the `stacks-signer` CLI to generate this signature. You can either SSH into your running signer or use the `stacks-signer` CLI locally. If using the CLI locally, you will need to ensure you have a matching configuration file located on your filesystem. Having a matching configuration file is important to ensure that the signer public key you make in Stacking transactions is the same as in your hosted signer.
-
-The CLI command is:
-
-```bash
-# Max Amount equivallent to 1M STX
-# Auth Id should be a random string less than 14 characters
-stacks-signer generate-stacking-signature \
- --method agg-commit \
- --max-amount 1000000000000 \
- --auth-id 71948271489 \
- --period 1 \
- --reward-cycle 100 \
- --pox-address bc1... \
- --config ./config.toml \
- --json
-```
-
-These arguments match those described in section [Overview of signer keys and signatures](operate-a-pool.md#overview-of-signer-keys-and-signatures), with the addition of:
-
-* `--json`, to optionally output the resulting signature in JSON.
-
-You can use the following command to generate a random `32` bit integer as `auth-id`:
-
-```bash
-python3 -c 'import secrets; print(secrets.randbits(32))'
-```
-
-Once the `generate-stacking-signature` command is run, the CLI will output a JSON:
-
-```json
-{"authId":"12345","maxAmount":"1234","method":"agg-commit","period":1,"poxAddress":"bc1...","rewardCycle":100,"signerKey":"aaaaaaaa","signerSignature":"bbbbbbbbbbb"}
-```
-
-You will use the JSON when calling Stacking transactions from your pool operator address as outlined above. Remember that this may be different than your signer address.
-
-#### Generating your signature with Leather Earn
-
-Leather Earn is a web application that provides an easy-to-use interface for stacking and generating signatures. We'll cover using Leather Earn for stacking at the end of this document, here we will cover how to use it to generate a signature.
-
-{% hint style="info" %}
-At the time of writing, this has only been tested using the [Leather](https://leather.io) wallet.
-{% endhint %}
-
-You can visit [earn.leather.io](https://earn.leather.io) to generate a signer key signature. Make sure you’re connected to the correct network.\
-\
-To generate a signer key signature, it’s important that you’ve logged in Leather with the same secret key that was used to [generate your signer key](../running-a-signer/#preflight-setup-1), not the account that will serve as your pool operator address. Once you’ve setup that account on Leather, you can log in to Leather Earn.\
-\
-Click the link “Signer key signature” at the bottom of the page. This will open the “generate a signer key signature” page.
-
-
-
-The fields are:
-
-* Reward cycle:
- * For all solo stacking transactions, this must equal the current reward cycle, not the cycle in which they will start stacking. The field defaults to the current reward cycle.
- * For stack-aggregation-commit-indexed, this field must equal the cycle used in that function’s “reward cycle” argument. Typically, that equates to current\_cycle + 1.
-* Bitcoin address: the PoX reward address that can be used
-* Topic: the stacking function that will use this signature
-* Max amount: max amount of STX that can be used. Defaults to “max possible amount”
-* Auth ID: defaults to random int
-* Duration: must match the number of cycles used in the stacking transaction. **For stack-aggregation-commit-indexed, use “1”**.
-
-{% hint style="warning" %}
-Each of these fields must be exactly matched in order for the Stacking transaction to work. Future updates to Leather Earn will verify the signature before the transaction is made.
-{% endhint %}
-
-Click the “generate signature” button to popup a Leather page where you can generate the signature. Once you submit that popup, Leather Earn will have the signer key and signature you generated.
-
-After you sign that message, you'll see the information you can use in your Stacking transactions, including the signer public key and signature.
-
-You can click the “copy” icon next to “signer details to share with stackers”. This will copy a JSON string, which can be directly pasted into the Leather Earn page where you make your Stacking transaction. Alternatively, this information can be entered manually.
-
-We'll cover the Leather Earn pages for actually making those transactions in the next section of this document.
-
-#### Using a hardware or software wallet to generate signatures
-
-When the signer is configured with a `stacks_private_key`, the signer may want to be able to use that key in a wallet to make stacking signatures.
-
-If the signer uses a tool like [@stacks/cli](https://docs.hiro.so/get-started/command-line-interface) to generate the key, the CLI also outputs a mnemonic (aka “seed phrase”) that can be imported into a wallet. Because the Stacks CLI uses the standard derivation path for generating Stacks keys, any Stacks wallet will default to having that same private key when the wallet is imported from a derivation path. Similarly, if a hardware wallet is setup with that mnemonic, then the Signer can use a wallet like Leather to make stacking signatures.
-
-The workflow for using a setting up a wallet to generate signatures would be:
-
-1. Use @stacks/cli to generate the keychain and private key.
- 1. Typically, when using a hardware wallet, it’s better to generate the mnemonic on the hardware wallet. For this use case, however, the signer software needs the private key, and hardware wallets (by design) don’t allow exporting private keys.
-2. Take the `privateKey` from the CLI output and add it to your signer’s configuration.
-3. Take the mnemonic (24 words) and either:
- 1. Setup a new hardware wallet with this mnemonic
- 2. Store it somewhere securely, like a password manager. When the signer needs to generate signatures for Stacking transactions, they can import it into either Leather or XVerse.
-
-When the user needs to generate signatures:
-
-1. Setup your wallet with your signer key’s private key. Either:
- 1. Setup your Leather wallet with a Ledger hardware wallet
- 2. Import your mnemonic into Leather, XVerse, or another Stacks wallet
-2. Open an app that has stacking signature functionality built-in
-3. Connect your wallet to the app (aka sign in)
-4. In the app, enter your PoX address and “submit”
-5. The app will popup a window in your wallet that prompts you to sign the information
- 1. The app will show clear information about what you’re signing
-6. Create the signature
- 1. If using a Ledger, confirm on your device
-7. The app will display two results:
- 1. Your signer key, which is the public key associated with your signer’s key
- 2. Your signer signature
-8. Finally, make a Stacking transaction using the signer key and signer signature.
-
-Now that you have your signer signature generated, it's time to start stacking. This process will vary depending on your chosen method. We've included instructions for solo stacking using [Leather Earn](https://earn.leather.io) below.
-
-### Step 3: Stack as a pool operator
-
-The first step with delegated stacking involves a stacker delegating their Stacks to a specific pool operator. Stackers can do this by visiting the “Stack in a pool” page on Leather Earn.
-
-As the pool operator, you must provide a STX address (a “pool admin address”) that will manage delegations. As discussed in previous sections, this is a separate address from the signer’s private key, and this can be any address. This address is what will be used when making transactions to confirm and aggregate delegated STX.
-
-Pool operators can log in to Leather Earn and visit [https://earn.leather.io/pool-admin](https://earn.leather.io/pool-admin) to make pool management transactions.
-
-#### delegate-stack-stx
-
-Once a user has delegated to a pool operator, the pool operator must call `delegate-stack-stx` for each individual stacker.
-
-#### stack-aggregation-commit
-
-Once a pool has enough delegated STX to become a signer, the pool admin needs to visit the `Stack Aggregation Commit` page on Leather Earn. The pool operator enters the following information:
-
-* Reward cycle: the reward cycle where the operator is “commiting” delegated STX. This must be done for every individual reward cycle where the pool will be acting as a signer.
-* BTC address
-* New fields:
- * Signer public key
- * Signer key signature (generated in a previous step using the signer key)
- * Auth ID
- * Max amount
-
-Once this transaction has been confirmed, the pool operator is eligible to be a signer for an upcoming reward cycle.
-
-For more on the relationship between automated signing and manual stacking transactions, be sure to check out the main [Stack STX](./) doc.
diff --git a/guides-and-tutorials/stack-stx/stack-with-a-pool.md b/guides-and-tutorials/stack-stx/stack-with-a-pool.md
deleted file mode 100644
index 8d2f78e8c5..0000000000
--- a/guides-and-tutorials/stack-stx/stack-with-a-pool.md
+++ /dev/null
@@ -1,59 +0,0 @@
-# Stack with a Pool
-
-The most common stacking scenario is to be an individual stacker that does not meet the stacking minimum and to stack with a pool.
-
-This is also the least complex version and is very easy to accomplish.
-
-Be sure you are familiar with the [concept of stacking](../../concepts/block-production/stacking.md) before digging into this.
-
-The dynamic minimum required to stack STX changes based on the total liquid supply of STX in the network and can be found by looking at the `pox` endpoint of the Hiro API: [https://api.hiro.so/v2/pox](https://api.hiro.so/v2/pox).
-
-If you do not meet this minimum, you'll need to delegate your STX to a pool operator.
-
-This is a non-custodial delegation, meaning that your STX do not actually leave your wallet.
-
-{% hint style="info" %}
-Pool operators have a lot of control over exactly how they implement stacking. Usually users will be interacting with a wrapper contract that the pool operator has created to utilize the core stacking contract.
-{% endhint %}
-
-Delegating your STX to a pool operator involves a few steps:
-
-1. Find a pool to delegate to
-2. Use the pool's UI with your wallet of choice to call a delegate function with a few parameters
-3. Pool operator will then stack your STX tokens on your behalf
-4. Pool operator will allocate rewards proportionally based on how much you have stacked
-5. Pool operator will distribute your rewards at the end of the stacking cycle
-
-Let's dig into each of these. If you want to learn more about the specific functions and the contract that handles the stacking process, be sure to take a look at the [stacking contract walkthrough](../../example-contracts/stacking.md).
-
-### Find a pool
-
-The first step is to find a stacking pool you would like to stack with. Pool operators have a lot of control over exactly how they implement stacking and reward distribution, and they all do things a bit differently, so it's important to do your research. The Stacks website has a great [page on stacking](https://www.stacks.co/learn/stacking) that links to several pool operators for you to research.
-
-### Call the delegate function
-
-After you've chosen your pool operator, you'll need to get set up with a [Stacks-compatible wallet](https://www.stacks.co/explore/ecosystem?category=All+Teams#wallets) like Leather, Xverse, or Asigna.
-
-Then you'll use your chosen pool operator's UI to call their delegation function. You may need to pass a couple of parameters here like how long you want to grant delegation permission for.
-
-### Pool operator stacks tokens
-
-Once you grant permission for the pool operator to delegate, they will take over and call a separate function in the stacking contract to actually stack those delegated tokens. At this point your STX will be locked.
-
-Depending on how the pool operator handles things, they may offer the option to automatically continue to stack your STX for up to 12 continuous cycles.
-
-### Pool operator allocates rewards
-
-Next, the pool operator will track what proportion of rewards you should earn based on the proportion of STX you delegated. If distributing rewards directly in Bitcoin, the pool operator will need to take custody of the Bitcoin and manually distribute it.
-
-This is why it is important to do your research and stack with a pool operator whose reward distribution mechanism you trust. Different operators have different methods to make this process transparent and as trust-minimized as possible.
-
-### Pool operator distributes rewards
-
-Finally, the pool operator will distribute those rewards to you in either BTC or STX, depending on the model they use.
-
-### Liquid Stacking
-
-Liquid stacking is when you delegate your STX tokens to a liquid stacking provider and they issue you a new token such as stSTX that you can then use in the ecosystem. This makes it so that stackers can still use their STX to participate in DeFi protocols and other apps even while their STX are locked.
-
-This works a bit differently than traditional stacking and links to liquid stacking providers for you to research can be found on the [Stacks website](https://www.stacks.co/learn/stacking).
diff --git a/guides-and-tutorials/stack-stx/stacking-flow.md b/guides-and-tutorials/stack-stx/stacking-flow.md
deleted file mode 100644
index 630a75b3e1..0000000000
--- a/guides-and-tutorials/stack-stx/stacking-flow.md
+++ /dev/null
@@ -1,559 +0,0 @@
-# Solo Stack
-
-This doc assumes you are familiar with stacking at a conceptual level. If not, you may want to read the [Stacking](../../concepts/block-production/stacking.md) concept guide.
-
-The guide below applies to those who want to solo stack, meaning they meet the minimum stacking requirement and need to either run a signer or collaborate with a signer.
-
-{% hint style="info" %}
-There is a dapp created by Degen Lab for [solo stacking](https://solo.stacking.tools/) without needing a signer, as Degen Lab operates a signer. This is likely the easiest option for solo stacking. We'll cover this option below.
-{% endhint %}
-
-If you prefer to participate in a pool by delegating your STX, you do not need to operate a signer either. If you fall into this category, check out the [Stack with a Pool](stack-with-a-pool.md) guide.
-
-### Solo Stacker Flow
-
-{% hint style="info" %}
-Note that in order to solo stack, you need to have the minimum number of STX tokens. This number can be found by visiting the pox endpoint of Hiro's API at [https://api.mainnet.hiro.so/v2/pox](https://api.mainnet.hiro.so/v2/pox) and looking at the `min_threshold_ustx` field. (1 STX = 1,000,000 uSTX)
-{% endhint %}
-
-#### Call the function `stack-stx`
-
-
-
-Function source code
-
-```clojure
-;; Lock up some uSTX for stacking! Note that the given amount here is in micro-STX (uSTX).
-;; The STX will be locked for the given number of reward cycles (lock-period).
-;; This is the self-service interface. tx-sender will be the Stacker.
-;;
-;; * The given stacker cannot currently be stacking.
-;; * You will need the minimum uSTX threshold. This will be determined by (get-stacking-minimum)
-;; at the time this method is called.
-;; * You may need to increase the amount of uSTX locked up later, since the minimum uSTX threshold
-;; may increase between reward cycles.
-;; * You need to provide a signer key to be used in the signer DKG process.
-;; * The Stacker will receive rewards in the reward cycle following `start-burn-ht`.
-;; Importantly, `start-burn-ht` may not be further into the future than the next reward cycle,
-;; and in most cases should be set to the current burn block height.
-;;
-;; To ensure that the Stacker is authorized to use the provided `signer-key`, the stacker
-;; must provide either a signature have an authorization already saved. Refer to
-;; `verify-signer-key-sig` for more information.
-;;
-;; The tokens will unlock and be returned to the Stacker (tx-sender) automatically.
-(define-public (stack-stx (amount-ustx uint)
- (pox-addr (tuple (version (buff 1)) (hashbytes (buff 32))))
- (start-burn-ht uint)
- (lock-period uint)
- (signer-sig (optional (buff 65)))
- (signer-key (buff 33))
- (max-amount uint)
- (auth-id uint))
- ;; this stacker's first reward cycle is the _next_ reward cycle
- (let ((first-reward-cycle (+ u1 (current-pox-reward-cycle)))
- (specified-reward-cycle (+ u1 (burn-height-to-reward-cycle start-burn-ht))))
- ;; the start-burn-ht must result in the next reward cycle, do not allow stackers
- ;; to "post-date" their `stack-stx` transaction
- (asserts! (is-eq first-reward-cycle specified-reward-cycle)
- (err ERR_INVALID_START_BURN_HEIGHT))
-
- ;; must be called directly by the tx-sender or by an allowed contract-caller
- (asserts! (check-caller-allowed)
- (err ERR_STACKING_PERMISSION_DENIED))
-
- ;; tx-sender principal must not be stacking
- (asserts! (is-none (get-stacker-info tx-sender))
- (err ERR_STACKING_ALREADY_STACKED))
-
- ;; tx-sender must not be delegating
- (asserts! (is-none (get-check-delegation tx-sender))
- (err ERR_STACKING_ALREADY_DELEGATED))
-
- ;; the Stacker must have sufficient unlocked funds
- (asserts! (>= (stx-get-balance tx-sender) amount-ustx)
- (err ERR_STACKING_INSUFFICIENT_FUNDS))
-
- ;; Validate ownership of the given signer key
- (try! (consume-signer-key-authorization pox-addr (- first-reward-cycle u1) "stack-stx" lock-period signer-sig signer-key amount-ustx max-amount auth-id))
-
- ;; ensure that stacking can be performed
- (try! (can-stack-stx pox-addr amount-ustx first-reward-cycle lock-period))
-
- ;; register the PoX address with the amount stacked
- (let ((reward-set-indexes (try! (add-pox-addr-to-reward-cycles pox-addr first-reward-cycle lock-period amount-ustx tx-sender signer-key))))
- ;; add stacker record
- (map-set stacking-state
- { stacker: tx-sender }
- { pox-addr: pox-addr,
- reward-set-indexes: reward-set-indexes,
- first-reward-cycle: first-reward-cycle,
- lock-period: lock-period,
- delegated-to: none })
-
- ;; return the lock-up information, so the node can actually carry out the lock.
- (ok { stacker: tx-sender, lock-amount: amount-ustx, signer-key: signer-key, unlock-burn-height: (reward-cycle-to-burn-height (+ first-reward-cycle lock-period)) }))))
-```
-
-
-
-The first thing solo stackers will need to do is call the `stack-stx` function.
-
-Just like in previous versions of PoX, Stackers call `stack-stx`, but with the new arguments added in Nakamoto. The arguments are:
-
-* Amount: Denoted in uSTX (1 STX = 1,000,000 uSTX)
-* PoX Address: the BTC wallet address where to receive Stacking rewards
-* Start burn height: the current BTC block height
-* Lock period: the number of cycles to lock for (between 1 and 12)
-* Signer key: the **public** key that your signer is using
-* Signer signature: the signature that proves control of this signer key
-* Max Amount: This parameter is used to validate the signer signature provided. It represents the maximum number of uSTX that can be stacked in this transaction.
-* Auth Id: This parameter is used to validate the signer signature provided. It is a random integer that prevents the re-use of this particular signer signature.
-
-Solo stackers have two choices when it comes to operating as a signer. They can choose to run a signer themselves or work with a signer on their behalf.
-
-#### Option 1: Act as a signer
-
-In the “prepare phase” before the next stacking cycle (last 100 blocks), the exact set of Stackers will be selected based on the amount of STX stacked. Just like in previous versions of PoX, each Stacker will have some number of reward slots based on the amount of STX locked.
-
-**It is critical that solo stackers have their signer running during this period.** The prepare phase is when distributed key generation (DKG) occurs, which is used when validating blocks by signers.
-
-In general, you don’t need to do anything actively during this period, other than monitoring your signer software to ensure it’s running properly.
-
-#### Option 2: Work with a signer
-
-If you do not want to operate a signer on your own, you can work with another signer. To do this, you will need to collaborate with them to get their signer key and signer signature (details in the following sections), which will have to be passed when calling the stacking functions.
-
-Rather than needing to find a signer to collaborate with, you can use the solo stacking dapp created by Degen Lab in order to use their signer to solo stack. They've created a UI that makes this process really simple.
-
-They also have a tool for you to generate a signer signature if you prefer to call the stacking functions yourself.
-
-#### Extending the stacking period
-
-Just like in the current version of PoX, you can extend your lock period while still Stacking. The function called is `stack-extend`.
-
-
-
-Function source code
-
-```clojure
-;; Extend an active Stacking lock.
-;; *New in Stacks 2.1*
-;; This method extends the `tx-sender`'s current lockup for an additional `extend-count`
-;; and associates `pox-addr` with the rewards, The `signer-key` will be the key
-;; used for signing. The `tx-sender` can thus decide to change the key when extending.
-;;
-;; Because no additional STX are locked in this function, the `amount` field used
-;; to verify the signer key authorization is zero. Refer to `verify-signer-key-sig` for more information.
-(define-public (stack-extend (extend-count uint)
- (pox-addr { version: (buff 1), hashbytes: (buff 32) })
- (signer-sig (optional (buff 65)))
- (signer-key (buff 33))
- (max-amount uint)
- (auth-id uint))
- (let ((stacker-info (stx-account tx-sender))
- ;; to extend, there must already be an etry in the stacking-state
- (stacker-state (unwrap! (get-stacker-info tx-sender) (err ERR_STACK_EXTEND_NOT_LOCKED)))
- (amount-ustx (get locked stacker-info))
- (unlock-height (get unlock-height stacker-info))
- (cur-cycle (current-pox-reward-cycle))
- ;; first-extend-cycle will be the cycle in which tx-sender *would have* unlocked
- (first-extend-cycle (burn-height-to-reward-cycle unlock-height))
- ;; new first cycle should be max(cur-cycle, stacker-state.first-reward-cycle)
- (cur-first-reward-cycle (get first-reward-cycle stacker-state))
- (first-reward-cycle (if (> cur-cycle cur-first-reward-cycle) cur-cycle cur-first-reward-cycle)))
-
- ;; must be called with positive extend-count
- (asserts! (>= extend-count u1)
- (err ERR_STACKING_INVALID_LOCK_PERIOD))
-
- ;; stacker must be directly stacking
- (asserts! (> (len (get reward-set-indexes stacker-state)) u0)
- (err ERR_STACKING_IS_DELEGATED))
-
- ;; stacker must not be delegating
- (asserts! (is-none (get delegated-to stacker-state))
- (err ERR_STACKING_IS_DELEGATED))
-
- ;; Verify signature from delegate that allows this sender for this cycle
- (try! (consume-signer-key-authorization pox-addr cur-cycle "stack-extend" extend-count signer-sig signer-key u0 max-amount auth-id))
-
- ;; TODO: add more assertions to sanity check the `stacker-info` values with
- ;; the `stacker-state` values
-
- (let ((last-extend-cycle (- (+ first-extend-cycle extend-count) u1))
- (lock-period (+ u1 (- last-extend-cycle first-reward-cycle)))
- (new-unlock-ht (reward-cycle-to-burn-height (+ u1 last-extend-cycle))))
-
- ;; first cycle must be after the current cycle
- (asserts! (> first-extend-cycle cur-cycle) (err ERR_STACKING_INVALID_LOCK_PERIOD))
- ;; lock period must be positive
- (asserts! (> lock-period u0) (err ERR_STACKING_INVALID_LOCK_PERIOD))
-
- ;; must be called directly by the tx-sender or by an allowed contract-caller
- (asserts! (check-caller-allowed)
- (err ERR_STACKING_PERMISSION_DENIED))
-
- ;; tx-sender must be locked
- (asserts! (> amount-ustx u0)
- (err ERR_STACK_EXTEND_NOT_LOCKED))
-
- ;; tx-sender must not be delegating
- (asserts! (is-none (get-check-delegation tx-sender))
- (err ERR_STACKING_ALREADY_DELEGATED))
-
- ;; standard can-stack-stx checks
- (try! (can-stack-stx pox-addr amount-ustx first-extend-cycle lock-period))
-
- ;; register the PoX address with the amount stacked
- ;; for the new cycles
- (let ((extended-reward-set-indexes (try! (add-pox-addr-to-reward-cycles pox-addr first-extend-cycle extend-count amount-ustx tx-sender signer-key)))
- (reward-set-indexes
- ;; use the active stacker state and extend the existing reward-set-indexes
- (let ((cur-cycle-index (- first-reward-cycle (get first-reward-cycle stacker-state)))
- (old-indexes (get reward-set-indexes stacker-state))
- ;; build index list by taking the old-indexes starting from cur cycle
- ;; and adding the new indexes to it. this way, the index is valid starting from the current cycle
- (new-list (concat (default-to (list) (slice? old-indexes cur-cycle-index (len old-indexes)))
- extended-reward-set-indexes)))
- (unwrap-panic (as-max-len? new-list u12)))))
- ;; update stacker record
- (map-set stacking-state
- { stacker: tx-sender }
- { pox-addr: pox-addr,
- reward-set-indexes: reward-set-indexes,
- first-reward-cycle: first-reward-cycle,
- lock-period: lock-period,
- delegated-to: none })
-
- ;; return lock-up information
- (ok { stacker: tx-sender, unlock-burn-height: new-unlock-ht })))))
-```
-
-
-
-You can “rotate” your signing key when extending your lock period.
-
-The arguments are:
-
-* Extend count: the number of cycles to add to your lock period. The resulting lock period cannot be larger than 12. For example, if you're currently locked with 6 cycles remaining, the maximum number you can extend is 6.
-* Pox Address: the BTC address to receive rewards
-* Signer public key: the public key used for signing. This can stay the same, or you can use a new key.
-* Signer signature: a signature proving control of your signing key
-* Max Amount: This parameter is used to validate the signer signature provided. It represents the maximum number of uSTX (1 stx = 1,000,000 uSTX) that can be stacked in this transaction.
-* Auth Id: This parameter is used to validate the signer signature provided. It is a random integer that prevents the re-use of this particular signer signature.
-
-#### Increasing the stacking amount
-
-The stacking amount can also be increased while actively Stacking. The increased position will take effect starting with the next Stacking cycle. The function called is `stack-increase`.
-
-
-
-Function source code
-
-```clojure
-;; Increase the number of STX locked.
-;; *New in Stacks 2.1*
-;; This method locks up an additional amount of STX from `tx-sender`'s, indicated
-;; by `increase-by`. The `tx-sender` must already be Stacking & must not be
-;; straddling more than one signer-key for the cycles effected.
-;; Refer to `verify-signer-key-sig` for more information on the authorization parameters
-;; included here.
-(define-public (stack-increase
- (increase-by uint)
- (signer-sig (optional (buff 65)))
- (signer-key (buff 33))
- (max-amount uint)
- (auth-id uint))
- (let ((stacker-info (stx-account tx-sender))
- (amount-stacked (get locked stacker-info))
- (amount-unlocked (get unlocked stacker-info))
- (unlock-height (get unlock-height stacker-info))
- (cur-cycle (current-pox-reward-cycle))
- (first-increased-cycle (+ cur-cycle u1))
- (stacker-state (unwrap! (map-get? stacking-state
- { stacker: tx-sender })
- (err ERR_STACK_INCREASE_NOT_LOCKED)))
- (cur-pox-addr (get pox-addr stacker-state))
- (cur-period (get lock-period stacker-state)))
- ;; tx-sender must be currently locked
- (asserts! (> amount-stacked u0)
- (err ERR_STACK_INCREASE_NOT_LOCKED))
- ;; must be called with positive `increase-by`
- (asserts! (>= increase-by u1)
- (err ERR_STACKING_INVALID_AMOUNT))
- ;; stacker must have enough stx to lock
- (asserts! (>= amount-unlocked increase-by)
- (err ERR_STACKING_INSUFFICIENT_FUNDS))
- ;; must be called directly by the tx-sender or by an allowed contract-caller
- (asserts! (check-caller-allowed)
- (err ERR_STACKING_PERMISSION_DENIED))
- ;; stacker must be directly stacking
- (asserts! (> (len (get reward-set-indexes stacker-state)) u0)
- (err ERR_STACKING_IS_DELEGATED))
- ;; stacker must not be delegating
- (asserts! (is-none (get delegated-to stacker-state))
- (err ERR_STACKING_IS_DELEGATED))
-
- ;; Validate that amount is less than or equal to `max-amount`
- (asserts! (>= max-amount (+ increase-by amount-stacked)) (err ERR_SIGNER_AUTH_AMOUNT_TOO_HIGH))
-
- ;; Verify signature from delegate that allows this sender for this cycle
- (try! (consume-signer-key-authorization cur-pox-addr cur-cycle "stack-increase" cur-period signer-sig signer-key increase-by max-amount auth-id))
-
- ;; update reward cycle amounts
- (asserts! (is-some (fold increase-reward-cycle-entry
- (get reward-set-indexes stacker-state)
- (some { first-cycle: first-increased-cycle,
- reward-cycle: (get first-reward-cycle stacker-state),
- stacker: tx-sender,
- add-amount: increase-by,
- signer-key: signer-key })))
- (err ERR_INVALID_INCREASE))
- ;; NOTE: stacking-state map is unchanged: it does not track amount-stacked in PoX-4
- (ok { stacker: tx-sender, total-locked: (+ amount-stacked increase-by)})))
-```
-
-
-
-The arguments are:
-
-* Increase by: the amount of uSTX to add to your lock amount.
-* Signer public key: the public key used for signing. This can stay the same, or you can use a new key.
-* Signer signature: a signature proving control of your signing key
-* Max Amount: This parameter is used to validate the signer signature provided. It represents the maximum number of uSTX (1 stx = 1,000,000 uSTX) that can be stacked in this transaction.
-* Auth Id: This parameter is used to validate the signer signature provided. It is a random integer that prevents the re-use of this particular signer signature.
-
-### Step by Step Stacking Guide
-
-Now that you are familiar with the overall stacking flow and the different roles played, let's dive into the step-by-step guide for actually conducting the stacking process.
-
-{% hint style="info" %}
-There are several ways you can go about stacking. This guide will cover using Leather Earn, which is a stacking web application and the simplest option.
-
-Additionally, you can choose to call the stacking functions directly from the [deployed contract](https://explorer.hiro.so/txid/SP000000000000000000002Q6VF78.pox-4?chain=mainnet) in the explorer.
-
-The fields and process will be the same, but the UI will differ.
-
-Finally, you can stack using JS and the [@stacks/stacking](https://github.com/hirosystems/stacks.js/tree/main/packages/stacking) package if you prefer. Again, the functions and parameters will be the same, you will just be writing your JS code directly instead of using a UI.
-
-If you are interested in using this method, you'll want to follow the [stacking guide](https://docs.hiro.so/stacks.js/guides/how-to-integrate-stacking) created by Hiro, and be sure to integrate the new parameters described in [Hiro's Nakamoto update doc](https://docs.hiro.so/nakamoto/stacks-js).
-{% endhint %}
-
-### Step 1: Run or work with a signer
-
-This is a necessary prerequisite to stacking as a solo stacker or pool operator.
-
-Running a signer involves setting up a hosted production environment that includes both a Stacks Node and the Stacks Signer. For more information, refer to the [running a signer doc](../running-a-signer/).
-
-Once the signer software is running, you'll have to keep track of the `stacks_private_key` that you used when configuring your signer software. This will be used in subsequent Stacking transactions.
-
-{% hint style="info" %}
-In the note above about pool operator vs signer keys, this corresponds to your signer key, not your pool operator wallet
-{% endhint %}
-
-Alternatively, you can work with a signer and have them perform step 2 below on your behalf.
-
-### Step 2: Generate a signer key signature
-
-#### Overview of signer keys and signatures
-
-The main difference with Stacking in Nakamoto is that the Signer (either solo Stacker or signer running a pool) needs to include new parameters in their Stacking transactions. These are Clarity transactions that Stackers will call when interacting with the `pox-4.clar` contract. Interacting with this contract is how you as a Stacker actually stack your STX tokens.
-
-{% hint style="info" %}
-The current pox-4 contract address can be found by visiting the following endpoint of the Hiro API: [https://api.mainnet.hiro.so/v2/pox](https://api.mainnet.hiro.so/v2/pox).
-
-You can then visit the [Explorer](https://explorer.hiro.so/?chain=mainnet) to view the contract and pass in the contract id.
-
-You may want to review this contract to familiarize yourself with it.
-{% endhint %}
-
-Here is an overview of the fields you will need to pass. We'll cover how to get and pass these fields as we dive further into this doc:
-
-1. `signer-key`: the public key that corresponds to the `stacks_private_key` your signer is using
-2. `signer-signature`: a signature that demonstrates that you actually controls your `signer-key`. Because signer keys need to be unique, this is also a safety check to ensure that other Stackers can’t use someone else’s public key
-3. `max-amount`: The maximum amount of ustx (1 STX = 1,000,000 uSTX) that can be locked in the transaction that uses this signature. For example, if calling `stack-increase`, then this parameter dictates the maximum amount of uSTX that can be used to add more locked STX
-4. `auth-id`: a random integer that prevents the re-use of a particular signature, similar to how nonces are used with transactions. Must be less than 14 characters
-
-Signer signatures are signatures created using a particular signer key. They demonstrate that the controller of that signer key is allowing a Stacker to use their signing key. The signer signature’s message hash is created using the following data:
-
-* `method`: a string that indicates the Stacking method that is allowed to utilize this signature. The valid options are `stack-increase`, `stack-stx`, `stack-extend`, `agg-commit` (for stack-aggregation-commit-indexed), or `agg-increase` (for stack-aggregation-increase)
-* `max-amount`: described above
-* `auth-id`: described above
-* `period`: a value between 1 and 12, which indicates the number of cycles that the Stacker is allowed to lock their STX for in this particular Stacking transaction. For `agg-commit`, this must be equal to 1
-* `reward-cycle`: This represents the reward cycle in which the Stacking transaction can be confirmed. For solo stacking operations (`stack-stx`, `stack-extend` and `stack-increase`), this has to be set as the current cycle.
-* `pox-address`: The Bitcoin address that is allowed to be used for receiving rewards. This can be set to any Bitcoin address that you have access to.
-* `config`: This represents the signer configuration file path where the `stacks_private_key` is located, and it is used for signing the generated signature.
-
-Now that we have an overview of role and contents of signatures, let's see how to actually generate them. You have several options available.
-
-**Generating your signature with Degen Lab's stacks.tools**
-
-Degen Lab has a signature generation tool that will generate a signature using their signer. This is the quickest and simplest option. To generate a signature using this method, all you need to do is visit their [signature tool](https://signature.stacking.tools/) and pass in the relevant information as covered on this page.
-
-#### Generating your signature with stacks.js
-
-The [@stacks/stacking](https://www.npmjs.com/package/@stacks/stacking) NPM package provides interfaces to generate and use signer signatures.
-
-There is a function called `signPoxSignature` that will allow you to generate this signature and pass it in to the stacking function.
-
-More information and code samples can be found on [Hiro's Nakamoto docs](https://docs.hiro.so/nakamoto/stacks-js).
-
-#### Generating your signature using the stacks-signer CLI
-
-If you already have your signer configured and set up, you can use the `stacks-signer` CLI to generate this signature. You can either SSH into your running signer or use the `stacks-signer` CLI locally. If using the CLI locally, you will need to ensure you have a matching configuration file located on your filesystem. Having a matching configuration file is important to ensure that the signer public key you make in Stacking transactions is the same as in your hosted signer.
-
-The CLI command is:
-
-```bash
-# Max Amount equivallent to 1M STX
-# Auth Id should be a random string less than 14 characters
-stacks-signer generate-stacking-signature \
- --method stack-stx \
- --max-amount 1000000000000 \
- --auth-id 71948271489 \
- --period 1 \
- --reward-cycle 100 \
- --pox-address bc1... \
- --config ./config.toml \
- --json
-```
-
-These arguments match those described in section [Overview of signer keys and signatures](stacking-flow.md#overview-of-signer-keys-and-signatures), with the addition of:
-
-* `--json`, to optionally output the resulting signature in JSON
-
-You can use the following command to generate a random `32` bit integer as `auth-id`:
-
-```bash
-python3 -c 'import secrets; print(secrets.randbits(32))'
-```
-
-Once the `generate-stacking-signature` command is run, the CLI will output a JSON:
-
-```json
-{"authId":"1234","maxAmount":"12345","method":"stack-stx","period":1,"poxAddress":"bc1...","rewardCycle":100,"signerKey":"aaaaaaaa","signerSignature":"bbbbbbbbbbb"}
-```
-
-You will use the JSON when calling Stacking transactions from your Stacker address as outlined above. Remember that this may be different than your signer address.
-
-#### Generating your signature with Leather Earn
-
-Leather Earn is a web application that provides an easy-to-use interface for stacking and generating signatures. We'll cover using Leather Earn for stacking at the end of this document, here we will cover how to use it to generate a signature.
-
-{% hint style="info" %}
-At the time of writing, this has only been tested using the [Leather](https://leather.io) wallet.
-{% endhint %}
-
-You can visit [earn.leather.io](https://earn.leather.io) to generate a signer key signature. Make sure you’re connected to the correct network.\
-\
-To generate a signer key signature, it’s important that you’ve logged in Leather with the same secret key that was used to [generate your signer key](../running-a-signer/#preflight-setup-1), not the account that will serve as your pool operator address. Once you’ve setup that account on Leather, you can log in to Leather Earn.\
-\
-Click the link “Signer key signature” at the bottom of the page. This will open the “generate a signer key signature” page.
-
-
-
-The fields are:
-
-* Reward cycle:
- * For all solo stacking transactions, this must equal the current reward cycle, not the cycle in which they will start stacking. The field defaults to the current reward cycle.
- * For stack-aggregation-commit-indexed, this field must equal the cycle used in that function’s “reward cycle” argument. Typically, that equates to current\_cycle + 1.
-* Bitcoin address: the PoX reward address that can be used
-* Topic: the stacking function that will use this signature
-* Max amount: max amount of STX that can be used. Defaults to “max possible amount”
-* Auth ID: defaults to random int
-* Duration: must match the number of cycles used in the stacking transaction. **For stack-aggregation-commit-indexed, use “1”**.
-
-{% hint style="warning" %}
-Each of these fields must be exactly matched in order for the Stacking transaction to work. Future updates to Leather Earn will verify the signature before the transaction is made.
-{% endhint %}
-
-Click the “generate signature” button to popup a Leather page where you can generate the signature. Once you submit that popup, Leather Earn will have the signer key and signature you generated.
-
-After you sign that message, you'll see the information you can use in your Stacking transactions, including the signer public key and signature.
-
-You can click the “copy” icon next to “signer details to share with stackers”. This will copy a JSON string, which can be directly pasted into the Leather Earn page where you make your Stacking transaction. Alternatively, this information can be entered manually.
-
-We'll cover the Leather Earn pages for actually making those transactions in the next section of this document.
-
-#### Using a hardware or software wallet to generate signatures
-
-When the signer is configured with a `stacks_private_key`, the signer may want to be able to use that key in a wallet to make stacking signatures.
-
-If the signer uses a tool like [@stacks/cli](https://docs.hiro.so/get-started/command-line-interface) to generate the key, the CLI also outputs a mnemonic (aka “seed phrase”) that can be imported into a wallet. Because the Stacks CLI uses the standard derivation path for generating Stacks keys, any Stacks wallet will default to having that same private key when the wallet is imported from a derivation path. Similarly, if a hardware wallet is setup with that mnemonic, then the Signer can use a wallet like Leather to make stacking signatures.
-
-The workflow for using a setting up a wallet to generate signatures would be:
-
-1. Use @stacks/cli to generate the keychain and private key.
- 1. Typically, when using a hardware wallet, it’s better to generate the mnemonic on the hardware wallet. For this use case, however, the signer software needs the private key, and hardware wallets (by design) don’t allow exporting private keys.
-2. Take the `privateKey` from the CLI output and add it to your signer’s configuration.
-3. Take the mnemonic (24 words) and either:
- 1. Setup a new hardware wallet with this mnemonic
- 2. Store it somewhere securely, like a password manager. When the signer needs to generate signatures for Stacking transactions, they can import it into either Leather or XVerse.
-
-When the user needs to generate signatures:
-
-1. Setup your wallet with your signer key’s private key. Either:
- 1. Setup your Leather wallet with a Ledger hardware wallet
- 2. Import your mnemonic into Leather, XVerse, or another Stacks wallet
-2. Open an app that has stacking signature functionality built-in
-3. Connect your wallet to the app (aka sign in)
-4. In the app, enter your PoX address and “submit”
-5. The app will popup a window in your wallet that prompts you to sign the information
- 1. The app will show clear information about what you’re signing
-6. Create the signature
- 1. If using a Ledger, confirm on your device
-7. The app will display two results:
- 1. Your signer key, which is the public key associated with your signer’s key
- 2. Your signer signature
-8. Finally, make a Stacking transaction using the signer key and signer signature.
-
-Now that you have your signer signature generated, it's time to start stacking. This process will vary depending on your chosen method. We've included instructions for solo stacking using [Leather Earn](https://earn.leather.io) below.
-
-### Step 3: Stack your STX
-
-#### stack-stx
-
-To start, you'll visit [Leather Earn](https://earn.leather.io) and click the “Stack independently” button on the home page.
-
-This page will allow you to input the following input:
-
-* The amount of STX you want to lock
-* The duration (in number of cycles) to lock for
-* Your BTC address where you will receive Stacking rewards
-* New fields:
- * Your signer public key
- * Your signer key signature (this is what you generated in the previous step)
- * Auth ID
- * Max amount
-
-#### stack-extend
-
-If you want to extend the time that your STX will be locked for, you can use the stack-extend page on Leather Earn.
-
-If you’re already stacking, the home page will provide a link to “view stacking details”. From there, you can choose to extend.
-
-On this page are the following fields:
-
-* The number of cycles you want to extend for
-* Your BTC address to receive rewards
-* New fields:
- * Signer public key
- * Signer key signature
- * Auth ID
- * Max amount
-
-#### stack-increase
-
-If you want to increase the amount of STX locked, you can use the stack-increase page on Leather Earn.
-
-If you’re already stacking, the home page will provide a link to “view stacking details”. From there, you can choose to increase.
-
-On this page are the following fields:
-
-* The amount of STX you want to increase by
-* New fields:
- * Signer public key
- * Signer key signature
- * Auth ID
- * Max amount
diff --git a/guides-and-tutorials/stack-stx/stop-stacking.md b/guides-and-tutorials/stack-stx/stop-stacking.md
deleted file mode 100644
index 85d8f816a0..0000000000
--- a/guides-and-tutorials/stack-stx/stop-stacking.md
+++ /dev/null
@@ -1,59 +0,0 @@
-# Stop Stacking
-
-When you decide it's time to stop stacking your STX tokens, the process depends on whether you are stacking solo or delegating your tokens to a pool operator. This guide explains the steps for both scenarios.
-
----
-
-## Stopping Solo Stacking
-
-When stacking solo using the `stack-stx` function, your STX is locked for a fixed period (the lock period) defined when you initiated stacking or when you extended the lock period. **No additional action is required to stop stacking**, you simply have to wait until the lock period expires.
-
-{% hint style="info" %}
-In solo stacking, both the `stack-stx` and `stack-extend` functions emits an event that includes the `unlock-burn-height` field. This is the burn block height at which your tokens will be automatically unlocked.
-{% endhint %}
-
-## Stopping Pooled Stacking
-
-If you're stacking with a pool (where you delegate your STX via the `delegate-stx` function), the process to stop stacking requires one extra step before your STX is eventually unlocked.
-
-### Step 1: Revoke Delegation
-
-Before your STX can be unlocked, you must cancel the delegation with the pool operator. This is done by calling the `revoke-delegate-stx` function through the pool's interface, or within the [pox-4](https://explorer.hiro.so/txid/SP000000000000000000002Q6VF78.pox-4?chain=mainnet) contract.
-
-
-
-Function source code
-
-```clojure
-;; Revokes the delegation to the current stacking pool.
-;; New in pox-4: Fails if the delegation was already revoked.
-;; Returns the last delegation state.
-(define-public (revoke-delegate-stx)
- (let ((last-delegation-state (get-check-delegation tx-sender)))
- ;; must be called directly by the tx-sender or by an allowed contract-caller
- (asserts! (check-caller-allowed)
- (err ERR_STACKING_PERMISSION_DENIED))
- (asserts! (is-some last-delegation-state) (err ERR_DELEGATION_ALREADY_REVOKED))
- (asserts! (map-delete delegation-state { stacker: tx-sender }) (err ERR_DELEGATION_ALREADY_REVOKED))
- (ok last-delegation-state)))
-```
-
-
-
-Calling `revoke-delegate-stx` cancels your STX delegation, revoking the pool operator's access to further lock/stack your funds. Even after revoking the delegation, your STX will remain locked until the end of the last stacking cycle chosen by the pool (can be at most 12 cycles in the future).
-
-{% hint style="warning" %}
-Failing to revoke your delegation will mean that you continue to allow the pool to stack your STX until the reach of the burn block height mentioned in the delegate function (`delegate-stx`). Ensure that you have successfully called `revoke-delegate-stx` if you want to stop stacking sooner.
-{% endhint %}
-
-### Step 2: Wait for Funds to Unlock
-After revoking your delegation, your STX tokens will still remain locked until the last stacking cycle chosen by the pool operator completes. The unlock occurs automatically at the predefined unlock burn height for that cycle.
-
-{% hint style="info" %}
-Even in pooled stacking, the unlocking mechanism follows the same blockchain timing as solo stacking. Revoking delegation only stops future stacking actions, it does not immediately unlock your tokens.
-{% endhint %}
-
-## Considerations
-- Monitor Your Stacking Status: Use your wallet's interface or the [Hiro Explorer](https://explorer.hiro.so?chain=mainnet) to track the status of your lock period and confirm when your tokens are available.
-- Using the API: Hiro's API offers an endpoint to [Get account STX balance](https://docs.hiro.so/stacks/api/accounts/stx-balances), which contains the `burnchain_unlock_height` height, representing the burn block height where your STX unlocks.
-- Plan Ahead: Since the unlocking is bound to cycle's timing, plan your stacking period or revocation accordingly to minimize delays in accessing your funds.
\ No newline at end of file
diff --git a/guides-and-tutorials/testing-smart-contracts/README.md b/guides-and-tutorials/testing-smart-contracts/README.md
deleted file mode 100644
index 34a61d518b..0000000000
--- a/guides-and-tutorials/testing-smart-contracts/README.md
+++ /dev/null
@@ -1,12 +0,0 @@
-# Testing Smart Contracts
-
-Smart contracts are immutable once deployed. Bugs are permanent. Test them\
-thoroughly.
-
-This section covers testing Clarity contracts.
-
-* [Fuzz Testing](fuzz-testing.md): Use Rendezvous to hammer your contract with random\
- inputs. It helps expose edge cases and vulnerabilities.
-* [Clarity Unit Testing](https://github.com/stacks-network/clarunit)
-
-More guides will follow.
diff --git a/guides-and-tutorials/testing-smart-contracts/fuzz-testing.md b/guides-and-tutorials/testing-smart-contracts/fuzz-testing.md
deleted file mode 100644
index b79865edfc..0000000000
--- a/guides-and-tutorials/testing-smart-contracts/fuzz-testing.md
+++ /dev/null
@@ -1,129 +0,0 @@
-# Fuzz Testing with Rendezvous
-
-Smart contracts on Stacks are immutable. Bugs are forever. Test early. Test often. Fuzzing finds edge cases that unit tests often miss.
-
-## What is Fuzz Testing?
-
-Fuzzing hits your code with random inputs. It helps uncover unexpected behavior and subtle bugs. Unlike unit tests, it explores paths you didn't think of.
-
-## What is Rendezvous?
-
-Rendezvous (`rv`) is a Clarity fuzzer. It supports:
-
-### Property-Based Testing
-
-You extract properties about your smart contract using Clarity. Rendezvous checks them multiple times with random inputs, in a stateful manner (the smart contract's state is not refreshed during the run).
-
-**What is a property?**
-
-A property is a universal truth about your smart contract's state, functions, etc.
-
-**How to extract a property?**
-
-Say that your smart contract has a function that reverses a list of `uint`s. In this case, one property can be that "reversing a list twice returns the original list". The property will look like this:
-
-```clarity
-(define-public (test-reverse-list (seq (list 127 uint)))
- (begin
- (asserts!
- (is-eq seq
- (reverse-uint
- (reverse-uint seq)
- )
- )
- (err u999)
- )
- (ok true)
- )
-)
-```
-
-**Making your property valid for Rendezvous**
-
-> For a property to be cosidered valid by Rendezvous, it has to comply with the following rules:
->
-> - Function name starts with `test-`
-> - Function is declared as `public`
-> - Test passes when it returns `(ok true)`
-> - Test would be discarded if it returned `(ok false)`
-> - Test fails if it returns an error or throws an exception
-
----
-
-### Invariant Testing
-
-You define read-only conditions in Clarity that must always hold true. Rendezvous attempts to create state transitions in your smart contract and continuously checks the conditions you defined to hold.
-
-**What is an invariant?**
-
-An invariant is a general truth regarding your smart contract's internal state. It will not be able to mutate the state, its role being solely to check the integrity of the state.
-
-**How to extract an invariant?**
-
-Say that you have a counter contract, having functions to `increment` and `decrement`. In this case, you could use the Rendezvous [`context`](https://stacks-network.github.io/rendezvous/chapter_6.html?#the-rendezvous-context) to extract an invariant regarding your smart contract's internal state:
-
-```clarity
-(define-read-only (invariant-counter-gt-zero)
- (let
- (
- (increment-num-calls
- (default-to u0 (get called (map-get? context "increment")))
- )
- (decrement-num-calls
- (default-to u0 (get called (map-get? context "decrement")))
- )
- )
- (if
- (<= increment-num-calls decrement-num-calls)
- true
- (> (var-get counter) u0)
- )
- )
-)
-```
-
-**Making your invariant valid for Rendezvous**
-
-> For an invariant to be cosidered valid by Rendezvous, it has to complain to the following ruleset:
->
-> - Function name starts with invariant-
-> - Function is declared as read-only (not public)
-> - Function returns a boolean value (true if the invariant holds, false if violated)
-> - The test can use the special context map to access execution history
-
-## Why Test in Clarity?
-
-Rendezvous tests run in Clarity, just like your contracts.
-
-1. Tests operate under the exact same constraints as production code.
-2. Better understanding of Clarity.
-3. No need to expose internals as public functions.
-4. Fewer tools to manage.
-
-## Getting Started
-
-Put tests next to contracts. Rendezvous will find them.
-
-```
-my-project/
-├── Clarinet.toml
-├── contracts/
-│ ├── my-contract.clar # Contract
-│ ├── my-contract.tests.clar # Tests
-└── settings/
- └── Devnet.toml
-```
-
-### Installation
-
-To install Rendezvous as a dependency in your project, use `npm`:
-
-```
-npm install @stacks/rendezvous
-```
-
-This will add Rendezvous to your project's `node_modules` and update your `package.json`.
-
-## Rendezvous Docs
-
-See full docs at: [https://stacks-network.github.io/rendezvous](https://stacks-network.github.io/rendezvous/)
diff --git a/guides-and-tutorials/tokens/README.md b/guides-and-tutorials/tokens/README.md
deleted file mode 100644
index 1a6bc52a92..0000000000
--- a/guides-and-tutorials/tokens/README.md
+++ /dev/null
@@ -1,3 +0,0 @@
-# Tokens
-
-Rather than needing to work with external libraries, Clarity has built-in functions that make working with fungible and non-fungible tokens a breeze.
diff --git a/guides-and-tutorials/tokens/creating-a-fungible-token.md b/guides-and-tutorials/tokens/creating-a-fungible-token.md
deleted file mode 100644
index 1761d3e21c..0000000000
--- a/guides-and-tutorials/tokens/creating-a-fungible-token.md
+++ /dev/null
@@ -1,96 +0,0 @@
-# Creating a Fungible Token
-
-Much the same as creating an NFT, Clarity also makes creating a fungible token (FT) trivial as well.
-
-The process and code are much the same.
-
-### Trait
-
-Just like with the NFT, it's a good idea to create a trait when you create a fungible token so that different tools and protocols and be confident in building interfaces for those tokens.
-
-Since FTs may be divisible, the [FT official mainnet deployment trait address](https://explorer.stacks.co/txid/0x99e01721e57adc2c24f7d371b9d302d581dba1d27250c7e25ea5f241af14c387?chain=mainnet) has additional functions.
-
-```clarity
-(define-trait sip-010-trait
- (
- ;; Transfer from the caller to a new principal
- (transfer (uint principal principal (optional (buff 34))) (response bool uint))
-
- ;; the human readable name of the token
- (get-name () (response (string-ascii 32) uint))
-
- ;; the ticker symbol, or empty if none
- (get-symbol () (response (string-ascii 32) uint))
-
- ;; the number of decimals used, e.g. 6 would mean 1_000_000 represents 1 token
- (get-decimals () (response uint uint))
-
- ;; the balance of the passed principal
- (get-balance (principal) (response uint uint))
-
- ;; the current total supply (which does not need to be a constant)
- (get-total-supply () (response uint uint))
-
- ;; an optional URI that represents metadata of this token
- (get-token-uri () (response (optional (string-utf8 256)) uint))
- )
-)
-```
-
-Now let's see how we might implement this in Clarity, just like we would an NFT.
-
-### Clarity Code
-
-```clarity
-(impl-trait 'SP3FBR2AGK5H9QBDH3EEN6DF8EK8JY7RX8QJ5SVTE.sip-010-trait-ft-standard.sip-010-trait)
-
-
-(define-constant contract-owner tx-sender)
-(define-constant err-owner-only (err u100))
-(define-constant err-not-token-owner (err u101))
-
-;; No maximum supply!
-(define-fungible-token clarity-coin)
-
-(define-public (transfer (amount uint) (sender principal) (recipient principal) (memo (optional (buff 34))))
- (begin
- (asserts! (is-eq tx-sender sender) err-not-token-owner)
- (try! (ft-transfer? clarity-coin amount sender recipient))
- (match memo to-print (print to-print) 0x)
- (ok true)
- )
-)
-
-(define-read-only (get-name)
- (ok "Clarity Coin")
-)
-
-(define-read-only (get-symbol)
- (ok "CC")
-)
-
-(define-read-only (get-decimals)
- (ok u6)
-)
-
-(define-read-only (get-balance (who principal))
- (ok (ft-get-balance clarity-coin who))
-)
-
-(define-read-only (get-total-supply)
- (ok (ft-get-supply clarity-coin))
-)
-
-
-(define-read-only (get-token-uri)
- (ok none)
-)
-
-
-(define-public (mint (amount uint) (recipient principal))
- (begin
- (asserts! (is-eq tx-sender contract-owner) err-owner-only)
- (ft-mint? clarity-coin amount recipient)
- )
-)
-```
diff --git a/guides-and-tutorials/tokens/creating-a-nft.md b/guides-and-tutorials/tokens/creating-a-nft.md
deleted file mode 100644
index 6ce6a6a78d..0000000000
--- a/guides-and-tutorials/tokens/creating-a-nft.md
+++ /dev/null
@@ -1,82 +0,0 @@
-# Creating a NFT
-
-Clarity makes creating NFTs incredibly easy. With built-in functions for creating and working with the token, you can have an NFT created in less than 10 minutes of work.
-
-Let's see how.
-
-:::tip For a more in-depth discussion of NFTs in Clarity and how to create them, check out the [NFTs chapter in the Clarity book](https://book.clarity-lang.org/ch10-01-sip009-nft-standard.html). :::
-
-### Trait
-
-The first thing we need when we create an NFT is a trait. A trait is an interface that allows us to create an NFT with a defined set of functions. Its primary purpose is to ensure that NFTs are composable and different tools know how to interact with them.
-
-By implementing a trait that the community agrees on, all protocols and products know how they can interact with an NFT.
-
-The official mainnet trait can be [found on the Stacks Explorer](https://explorer.stacks.co/txid/0x80eb693e5e2a9928094792080b7f6d69d66ea9cc881bc465e8d9c5c621bd4d07?chain=mainnet) and looks like this:
-
-```clarity
-(define-trait nft-trait
- (
- ;; Last token ID, limited to uint range
- (get-last-token-id () (response uint uint))
-
- ;; URI for metadata associated with the token
- (get-token-uri (uint) (response (optional (string-ascii 256)) uint))
-
- ;; Owner of a given token identifier
- (get-owner (uint) (response (optional principal) uint))
-
- ;; Transfer from the sender to a new principal
- (transfer (uint principal principal) (response bool uint))
- )
-)
-```
-
-All we are doing here is defining the function signatures for functions we'll need to implement in our Clarity contract, which we can see a simple version of below.
-
-### Clarity Code
-
-This is the Clarity code we need in order to create an NFT, with one additional function, `mint` that allows us to actually create a new NFT. This `mint` function is not needed to adhere to the trait.
-
-```clarity
-(impl-trait 'SP2PABAF9FTAJYNFZH93XENAJ8FVY99RRM50D2JG9.nft-trait.nft-trait)
-
-(define-non-fungible-token amazing-aardvarks uint)
-
-(define-data-var last-token-id uint u0)
-
-(define-constant contract-owner tx-sender)
-(define-constant err-owner-only (err u100))
-(define-constant err-not-token-owner (err u101))
-
-(define-read-only (get-last-token-id)
- (ok (var-get last-token-id))
-)
-
-(define-read-only (get-token-uri (token-id uint))
- (ok none)
-)
-
-(define-read-only (get-owner (token-id uint))
- (ok (nft-get-owner? amazing-aardvarks token-id))
-)
-
-(define-public (transfer (token-id uint) (sender principal) (recipient principal))
- (begin
- (asserts! (is-eq tx-sender sender) err-not-token-owner)
- (nft-transfer? amazing-aardvarks token-id sender recipient)
- )
-)
-
-(define-public (mint (recipient principal))
- (let
- (
- (token-id (+ (var-get last-token-id) u1))
- )
- (asserts! (is-eq tx-sender contract-owner) err-owner-only)
- (try! (nft-mint? amazing-aardvarks token-id recipient))
- (var-set last-token-id token-id)
- (ok token-id)
- )
-)
-```
diff --git a/nakamoto-upgrade/nakamoto-activation-guide-for-signers.md b/nakamoto-upgrade/nakamoto-activation-guide-for-signers.md
deleted file mode 100644
index 6cfa8e3bbc..0000000000
--- a/nakamoto-upgrade/nakamoto-activation-guide-for-signers.md
+++ /dev/null
@@ -1,53 +0,0 @@
----
-hidden: true
-noIndex: true
----
-
-# Nakamoto Activation Guide for Signers
-
-{% hint style="info" %}
-The block for Nakamoto activation has been chosen as Bitcoin block 867,867, which is currently expected on October 28th. This block is subject to change should core developers need additional time for testing or unexpected issues.
-
-Binaries will be provided roughly a week in advance and your normal upgrade procedure should apply here, you’ll want to be running the latest node and Signer software. Note that if you do not upgrade ahead of the hard fork, your nodes will be dropped from the network.
-{% endhint %}
-
-#### Testnet Activation Window (August 19)
-
-This initial phase focuses on testing Signer 3.0 readiness in a testnet environment (Primary Testnet).
-
-**Action Required:**
-
-1. Update stacks-node to version 3.1.0.0.5 ([here](https://github.com/stacks-network/stacks-core/releases/latest))
-2. Update signer to version 3.1.0.0.5.0 ([here](https://github.com/stacks-network/stacks-core/releases/tag/signer-3.1.0.0.5.0))
-3. [Run a Primary Testnet node](setting-up-a-primary-post-nakamoto-testnet-node.md) alongside your Signer
-4. Create a testnet wallet address
-5. Complete the provided form ([here](https://blocksurvey.io/signer-nakamoto-activation-upgrade-GrOV5aivQ2.z2fh3bqEyLQ?v=o))
-6. Await testnet STX delegation from our team
-
-The goal(s) of this phase is to: monitor for issues, implement fixes, and test Signing and Signer hand-off for multiple Epoch 2.5 cycles.
-
-Moving forward, please report any Signer-related bugs, issues or feature requests using the issue template in the stacks-core repo (here)
-
-#### Mainnet Activation Window (Starting August 28)
-
-Pending successful testnet phases, we will initiate the mainnet activation window.
-
-**Action Required:**
-
-* ALL Mainnet Signers must update to the latest Stacks-Core and Signer binary versions (specifics to be confirmed)
-
-We will test for at least 1.5 Stacking Cycles to ensure stability.
-
-#### Key Points
-
-* Your participation in all phases is crucial
-* Report any issues or unexpected behavior immediately
-* Stay alert for further communications
-
-#### Conclusion
-
-Your dedication to the Stacks network's security and efficiency is invaluable. We appreciate your prompt attention to these critical steps and your ongoing support.
-
-For any questions or concerns, please don't hesitate to reach out.
-
-Thank you for your commitment to the Stacks ecosystem.
diff --git a/nakamoto-upgrade/nakamoto-in-10-minutes.md b/nakamoto-upgrade/nakamoto-in-10-minutes.md
deleted file mode 100644
index 467d460b99..0000000000
--- a/nakamoto-upgrade/nakamoto-in-10-minutes.md
+++ /dev/null
@@ -1,63 +0,0 @@
----
-hidden: true
----
-
-# Nakamoto in 10 Minutes
-
-On the previous page, we outlined three primary changes to the way Stacks works that Nakamoto introduces:
-
-* **Fast blocks:** The time taken for a user-submitted transaction to be mined within a block (and thus confirmed) will now take on the order of seconds, instead of tens of minutes. This is achieved by separating block production from cryptographic sortitions -- a winning miner may produce many blocks between two subsequent sortitions.
-* **Bitcoin finality:** Once a transaction is confirmed, reversing it is at least as hard as reversing a Bitcoin transaction. The Stacks blockchain no longer forks on its own.
-* **Bitcoin Miner MEV Resistance:** This proposal alters the sortition algorithm to ensure that Bitcoin miners do not have an advantage as Stacks miners. They must spend competitive amounts of Bitcoin currency to have a chance of earning STX.
-
-Here is a video that covers exactly what happens to a Stacks transaction under Nakamoto rules. In it we cover exactly how Nakamoto achieves Bitcoin finality.
-
-{% embed url="https://www.youtube.com/watch?v=DFBZTSsZUOs" %}
-
-In the rest of this doc, we'll cover some of the key components of Nakamoto in a bit more detail.
-
-Fore a more detailed technical explanation of how this is all accomplished, check out the [Block Production](../concepts/block-production/) section.
-
-### Fast Blocks
-
-One of the most significant changes coming in Nakamoto is how new blocks are produced. Historically, because Stacks blocks have been anchored 1:1 to Bitcoin blocks, slow block times and transaction times have been one of the biggest pain points for Stacks users and developers.
-
-Nakamoto brings significantly faster block times by decoupling Stacks block production from Bitcoin block production. In Nakamoto, new Stacks blocks are produced roughly every 5 seconds.
-
-#### Tenure-Based Block Production
-
-This is achieved via the use of tenure-based block production. Each Bitcoin block introduces a new tenure, in which a single miner cryptographically selected for that tenure is responsible for producing all Stacks blocks.
-
-Rather than single Stacks blocks being tied to a single Bitcoin block, Bitcoin blocks are now tied to a miner tenure, during which they mine several Stacks blocks which settle in around 5 seconds.
-
-But if a single miner is only cryptographically selected for their tenure, and not their produced blocks, what mechanisms exist to ensure the validity of their block production?
-
-#### Stackers
-
-This is where Stackers come in. In pre-Nakamoto Stacks, Stackers were responsible only for locking their STX tokens to contribute to the economic security of the network.
-
-In Nakamoto, Stackers are responsible for validating and approving each block produced during a miner's tenure.
-
-To ensure network consistency, the Stacks protocol commits to the state of the Stacks blockchain with each new Bitcoin block by referencing the first Stacks block produced in the previous tenure. Such a design reinforces the fidelity of transaction data and the synchronization between the two chains. It also links the Stacker’s actions with the actions of miners producing a partnership between the two to create both fast and secure blocks.
-
-As part of this tenure change, Stackers also agree on a last signed block and require the next miner to build off of this, which prevents new Stacks forks. Stacks does not fork on its own and automatically forks with Bitcoin.
-
-This symbiotic relationship between Stackers and miners is what creates the capability for both fast blocks and 100% Bitcoin finality.
-
-This elegant design creates a cooperative relationship between miners and stackers while achieving the best of both worlds with block production and transaction speed and security.
-
-Here is a diagram outlining miner and signer behavior.
-
-
-
-### Bitcoin MEV Mitigation
-
-Miner Extractable Value (MEV) has been a longstanding issue across many blockchains, including Stacks pre-Nakamoto.
-
-MEV refers to the potential profit miners can extract from the manipulation of transaction inclusion and ordering within the blocks they produce, which can lead to unfair practices and diminished trust in the network.
-
-Specifically in pre-Nakamoto releases of Stacks, Bitcoin miners with a significant percentage of Bitcoin’s hashrate had the ability to censor commitment transactions of other Stacks miners ensuring they were able to win the block rewards and fees of Stacks blocks where they were also the winner of the Bitcoin block as a Bitcoin miner.
-
-The Nakamoto system uses a variation of the Assumed Total Commitment with Carryforward (ATC-C) MEV mitigation strategy described in [this document](https://github.com/stacksgov/sips/blob/main/sips/sip-021/MEV-Report.pdf) to allocate block rewards to miners. The probability a miner will win the block and be granted the current tenure will be based on a function that accounts for the total block commit spend on the blocks leading up to the current block.
-
-The ATC solution leaves the option for a block to have no valid winner. The TenureChange-Extend transaction mitigates the majority of adverse effects caused by a missed block.
diff --git a/nakamoto-upgrade/nakamoto-rollout-plan/README.md b/nakamoto-upgrade/nakamoto-rollout-plan/README.md
deleted file mode 100644
index 7c122aefa4..0000000000
--- a/nakamoto-upgrade/nakamoto-rollout-plan/README.md
+++ /dev/null
@@ -1,44 +0,0 @@
----
-description: >-
- Testnet and mainnet rollout sequencing for the Nakamoto upgrade. Several key
- steps bring more features live in a safe, step-by-step process that will give
- builders and partners time to integrate.
-hidden: true
----
-
-# Nakamoto Rollout Plan
-
-{% hint style="info" %}
-Nakamoto has completed step 1 of the rollout (Instantiation). Next, a hard fork that follows an Activation sequence outlined below will make Nakamoto features available to the whole network.
-{% endhint %}
-
-### Step 1, Step 2: Instantiation & Activation
-
-The rollout will follow this two-step process, each of which is implemented via hard fork.
-
-1. **Step 1 - Instantiation:** The pox-4 contract and the majority of the Nakamoto code are shipped, but Nakamoto rules are inactive. This is so other aspects of the contract can be tested before layering on the complexity that comes with the testnet (and later mainnet) being dependent on it. Importantly, this phase also allows time for Signers to register without the network being dependent on them to sign blocks.
-2. **Step 2 - Activation:** Once completely rolled out, the full set of Nakamoto features including Signer-based functions, fast blocks, and Bitcoin finality. In other words, ‘the switch is flipped’! This switch is scheduled to occur at Bitcoin Block #867867 (\~October 29th).
-
-It’s important to note the heaviest lift of any hard fork is historically the sync from genesis. With the two Nakamoto forks, one goal is not to require this, making the upgrade more akin to a push-button software update and much simpler for all node operators.
-
-
-
-What are ‘Nakamoto Rules’?
-
-Nakamoto rules are the logic that makes Nakamoto different than the version before it called Stacks 2.4. The key difference is that under Nakamoto, block validation logic requires Signers to sign the blocks to be confirmed as anchor blocks. At Step 1 (Instantiation), this logic, or the ‘Nakamoto Rules’ remains inactive, meaning the network follows the block validation rules of Stacks 2.4. Once the testnet (and later mainnet) reaches Activation, the network switches to running these Nakamoto rules and all the features we’re excited about go live for everybody.
-
-
-
-### Nakamoto Activation Sequence
-
-
Step
Overview
Date/Period
✅ A, B
Activation Window Opens & Binaries Delivered
Pending no new bugs, final binaries are delivered - this is all the code Signers, Miners, and Node Operators need to run the network.
Aug 28th
✅ C
Cycle Handoff - Signers
At the end of Cycle 92, core developers will watch for a successful ‘handoff’, meaning a successful change of the Signer sets between Stacking cycles.
Cycle 92 to Cycle 93
✅ D
First Testnet Hard Fork
Core developers performed a successful testnet hardfork (on Nakamoto testnet).
Sept 27
✅ E
Determine Hard Fork Block
Core developers have selected Bitcoin block #867867.
October 17
F
Epoch 3.0 - Nakamoto Rules Start
Fast blocks, full Bitcoin finality! Nakamoto rules go live on mainnet at hard fork block.
~October 29
-
-### Factors that could affect timelines:
-
-* **Testing & Audit Results:** A top-notch group of researchers, contractors, and testers, along with security auditors from Clarity Alliance and Quantstamp, continue to hammer away at Nakamoto as they have for the past several months. This testing is ongoing, so there is always the possibility they surface an issue that needs to be addressed before the final hard fork.
-* **Signer Needs:** The ecosystem is proud to have industry leaders comprising its leading Signer network. Signers are a critical new network player so if a clear issue or unexpected need arises during activation, additional time would be taken to address it.
-* **Miner adoption:** As always, miners must choose to adopt the new code. Should they be delayed or experience issues with their setups, it could cause a delay in Activation.
-
-Factors that could affect timelines: As always, core developers are committed to a safe, secure launch. As such, several factors _could_ warrant additional time added to the Nakamoto activation sequence outlined above and result in a new hard fork block being selected:
-
-\
diff --git a/nakamoto-upgrade/nakamoto-rollout-plan/nakamoto-for-exchanges.md b/nakamoto-upgrade/nakamoto-rollout-plan/nakamoto-for-exchanges.md
deleted file mode 100644
index ac56171a86..0000000000
--- a/nakamoto-upgrade/nakamoto-rollout-plan/nakamoto-for-exchanges.md
+++ /dev/null
@@ -1,38 +0,0 @@
-# Nakamoto for Exchanges
-
-
-
-What is the Nakamoto upgrade?
-
-The Nakamoto release brings many new capabilities and improvements to the Stacks blockchain by focusing on a set of core advancements: improving transaction speed, enhancing finality guarantees for transactions, mitigating Bitcoin miner MEV (miner extractable value) opportunities that affect PoX, and boosting robustness against chain reorganizations. This strategic upgrade aims to solidify trust in the Stacks network, offer greater alignment with Bitcoin's immutable nature, and foster an environment ripe for advanced Decentralized Finance (DeFi) applications. The expected outcome is a versatile, scalable, and secure platform that closely integrates with, yet distinctly enhances, the Bitcoin ecosystem.\
-\
-Learn more: [nakamoto-in-10-minutes.md](../nakamoto-in-10-minutes.md "mention")
-
-
-
-### What does the Nakamoto upgrade mean for exchanges?
-
-The main thing exchanges will notice when the Nakamoto rollout is complete is the faster blocks! Gone are the days of waiting for Bitcoin blocks for confirmations. In addition to fast blocks, exchanges will benefit from:
-
-* Smoother block production
-* No forking at the Stacks layer, once a transaction is confirmed in an anchor block, it is as irreversible as a Bitcoin transaction (and therefore, can update confirmation rules (number of confirmations) to match Bitcoin's)
-* For exchanges offering Stacking pools, likely increased BTC rewards thanks to MEV improvements
-
-
-
-### Other Recommendations:
-
-* With just a bit of extra work, exchanges can support the [Stacks SIP-10 token standard](https://github.com/stacksgov/sips/blob/main/sips/sip-010/sip-010-fungible-token-standard.md). This allows an exchange to easily list any of a growing number of tokens built on Stacks as well as the upcoming [sBTC asset](broken-reference/).
-* Exchanges that already offer staking type services to their users (programs often called Earn/Stake/etc.) should consider adding [Stacking](../../concepts/block-production/stacking.md) to their platform alongside other offerings. Users can earn BTC by participating in Stacks consensus through a simple pool.
-* The Stacks Foundation is seeking a handful of exchanges to pilot rapid BTC withdrawals via the upcoming sBTC asset, expected to closely follow the Nakamoto hard fork. Interest exchange can reach out to their usual point of contact or complete [this form](https://stacks.org/exchanges).
-
-### Resources:
-
-* [Testnet documentation](https://docs.stacks.co/nakamoto-upgrade/nakamoto)
-* [API documentation](https://docs.hiro.so/nakamoto/stacks-js)
-* [Stacks Core Binaries](https://github.com/stacks-network/stacks-core/releases/latest)
-* [Stacks Signer Binary](https://github.com/stacks-network/stacks-core/releases/tag/signer-3.1.0.0.5.0)
-* [Stacks Core Docker Images](https://hub.docker.com/r/blockstack/stacks-core/tags?page=1\&name=3.1.0.0.5)
-* [Stacks Signer Docker Image](https://hub.docker.com/r/blockstack/stacks-signer/tags?page=1\&name=3.1.0.0.5.0)
-* [Stacks Blockchain API](https://github.com/hirosystems/stacks-blockchain-api/releases/latest)
-* [Stacks Blockchain API Docker Images](https://hub.docker.com/r/hirosystems/stacks-blockchain-api/tags?page=1\&name=8.4.0)
diff --git a/nakamoto-upgrade/nakamoto-rollout-plan/nakamoto-for-stackers.md b/nakamoto-upgrade/nakamoto-rollout-plan/nakamoto-for-stackers.md
deleted file mode 100644
index ec5e04dbb6..0000000000
--- a/nakamoto-upgrade/nakamoto-rollout-plan/nakamoto-for-stackers.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-description: >-
- Learn how you can earn a BTC yield by locking your STX and supporting network
- consensus
----
-
-# Nakamoto for Stackers
-
-### Learn about Stacking basics:
-
-{% content-ref url="../../concepts/block-production/stacking.md" %}
-[stacking.md](../../concepts/block-production/stacking.md)
-{% endcontent-ref %}
-
-### Stacking Providers:
-
-Find the current list at [stacks.co](https://www.stacks.co/learn/stacking)
-
-### Stacking Tools
-
-Check out these valuable Stacking resources:
-
-* Stacking Calendar and more! [https://stacking.tools/](https://stacking.tools/)
-* Stacking Tracker: [https://www.stacking-tracker.com/](https://www.stacking-tracker.com/)
-* Lockstacks (access various pools): [https://lockstacks.com/](https://lockstacks.com/)
-* Find Stacking data:
- * [https://app.signal21.io/](https://app.signal21.io/)
- * [https://app.ortege.ai/superset/dashboard/stacks/](https://app.ortege.ai/superset/dashboard/stacks/)
diff --git a/nakamoto-upgrade/nakamoto-rollout-plan/nakamoto-for-stacking-providers.md b/nakamoto-upgrade/nakamoto-rollout-plan/nakamoto-for-stacking-providers.md
deleted file mode 100644
index 8337f9fe9f..0000000000
--- a/nakamoto-upgrade/nakamoto-rollout-plan/nakamoto-for-stacking-providers.md
+++ /dev/null
@@ -1,24 +0,0 @@
----
-hidden: true
-noIndex: true
----
-
-# Nakamoto for Stacking Providers
-
-## Upgrading your Stacking pool or service
-
-There are a few basic steps you'll need to follow to get your Stacking pool set up to work with this first Nakamoto hard fork as this fork brings us the new [pox-4 contract](../../example-contracts/stacking.md):
-
-1. Setup a Stacks node and signer by following the [How to Run a Signer](../../guides-and-tutorials/running-a-signer/) doc.
-2. Update your user-facing products and contracts to point to the new pox-4 contract
- * i.e. if you use a wrapper contract with pox-3 hardcoded, you'll need to deploy a new contract referencing pox-4
-3. Update any internal infrastructure or automation that you use to manage your pool
-4. Familiarize yourself with the new `stack-aggregation-commit` [function arguments](../../guides-and-tutorials/stack-stx/stacking-flow.md#pool-operator-commits-delegated-stx), along with [how to generate a signer key signature](../../guides-and-tutorials/stack-stx/stacking-flow.md#step-2-generate-a-signer-key-signature).
-
-#### Other notes:
-
-* Once you are running a signer as described in the [How to Run a Signer](../../guides-and-tutorials/running-a-signer/) doc, you'll initiate Stacking transactions as normal, but you'll need to pass an additional Signer signature field. This is covered extensively in the [How to Stack](../../guides-and-tutorials/stack-stx/stacking-flow.md) doc.
-* For delegated stacking flows, the functions `delegate-stx` and `delegate-stack-stx` are unchanged. If your pool makes use of custom smart contracts for allowing Stackers to delegate to you, those contracts may need to be updated to point to the new `pox-4` address.
-* The function `stack-aggregation-commit` now requires pool operators to provide their Signer’s public key, along with other related information. Learn more about generating Signer key signatures using the [stacks-signer CLI](https://docs.stacks.co/nakamoto-upgrade/signing-and-stacking/stacking-flow#generating-your-signature-using-the-stacks-signer-cli) or with [Lockstacks](https://docs.stacks.co/nakamoto-upgrade/signing-and-stacking/stacking-flow#generating-your-signature-with-lockstacks). Again, this entire flow is covered extensively in the [How to Stack](../../guides-and-tutorials/stack-stx/stacking-flow.md) doc.
-* Depending on your pool’s infrastructure, you may need to update any tools or automations that you use to finalize your pool’s delegations.
-
diff --git a/nakamoto-upgrade/nakamoto-rollout-plan/nakamoto.md b/nakamoto-upgrade/nakamoto-rollout-plan/nakamoto.md
deleted file mode 100644
index ec491eddc9..0000000000
--- a/nakamoto-upgrade/nakamoto-rollout-plan/nakamoto.md
+++ /dev/null
@@ -1,50 +0,0 @@
----
-hidden: true
----
-
-# Nakamoto for App Developers
-
-### API Endpoints
-
-* API status
- * Tesnet: [https://api.testnet.hiro.so/extended/](https://api.testnet.hiro.so/extended/)
- * Mainnet: [https://api.hiro.so/extended/](https://api.hiro.so/extended/)
-* Burn Block endpoint. This will allow you to get the hashes of fast Stacks blocks as they are added to the chain and see their associated burn blocks.
- * Testnet: [https://api.testnet.hiro.so/extended/v2/burn-blocks](https://api.testnet.hiro.so/extended/v2/burn-blocks)
- * Mainnet: [https://api.hiro.so/extended/v2/burn-blocks](https://api.hiro.so/extended/v2/burn-blocks)
-* Pox endpoint. This allows you to get information about proof of transfer, including the currently deployed pox-4 contract. This will be helpful for anyone looking to incorporate stacking into their app.
- * Testnet: [https://api.testnet.hiro.so/v2/pox](https://api.testnet.hiro.so/v2/pox)
- * Mainnet: [https://api.hiro.so/v2/pox](https://api.hiro.so/v2/pox)
-
-#### PoX-4 Contract
-
-`pox-4.clar` is the stacking contract. If you are interested in experimenting with proof of transfer use cases including state changes, solo stacking, and pool stacking, all the functions you’ll need can be found at the deployed contract:
-
-* Testnet: [https://explorer.hiro.so/txid/0xfba7f786fae1953fa56f4e56aeac053575fd48bf72360523366d739e96613da3?chain=testnet](https://explorer.hiro.so/txid/0xfba7f786fae1953fa56f4e56aeac053575fd48bf72360523366d739e96613da3?chain=testnet)
-* Mainnet: [https://explorer.hiro.so/txid/0xc6d6e6ec82cabb2d7a9f4b85fcc298778d01186cabaee01685537aca390cdb46?chain=mainnet](https://explorer.hiro.so/txid/0xc6d6e6ec82cabb2d7a9f4b85fcc298778d01186cabaee01685537aca390cdb46?chain=mainnet)
-
-#### Signers Voting Contract
-
-After a DKG (Distributed Key Generation) round, signer votes are submitted to this contract. For more on DKG, you can read the [Stackers and Signing](../../concepts/block-production/stackers-and-signing.md) section of Nakamoto In-Depth.
-
-[https://explorer.hiro.so/txid/0x69af1dbed501acdbc0d1c79e1ecbc17e1904edacc15cf4b39d6783e720e21c00?chain=testnet](https://explorer.hiro.so/txid/0x69af1dbed501acdbc0d1c79e1ecbc17e1904edacc15cf4b39d6783e720e21c00?chain=testnet)
-
-#### Block Explorer
-
-The explorer will allow you to view fast blocks as they come in. Be sure to turn on “Live updates” to see them coming in in real time. [https://explorer.hiro.so/?chain=testnet](https://explorer.hiro.so/?chain=testnet)
-
-
Turn on Live Updates to view blocks coming in in real time
-
-#### Local Development Environment
-
-Clarinet has been updated to work with Nakamoto using as of [version 2.4](https://github.com/hirosystems/clarinet/releases/tag/v2.4.0). That means you can use Clarinet to build locally using Nakamoto rules in your local development environment and use Clarinet and deployment plans to deploy to Nakamoto Testnet.
-
-Be sure to [update Clarinet](https://docs.hiro.so/clarinet/getting-started) to the newest version.
-
-#### Running a signer
-
-If you are interested in running a signer, you can take a look at the [How to Run a Signer](../../guides-and-tutorials/running-a-signer/) doc which will get you up to speed on how to get the signer software set up using Nakamoto.
-
-#### Office Hours
-
-If you need support or just want to ask questions while experimenting with the Nakamoto Testnet, you can [join the weekly office hours](https://events.stacks.co/event/HD16484710) with the Stacks' Foundation's Developer Advocate, Kenny Rogers.
diff --git a/nakamoto-upgrade/nakamoto-upgrade-start-here.md b/nakamoto-upgrade/nakamoto-upgrade-start-here.md
deleted file mode 100644
index f2d057d825..0000000000
--- a/nakamoto-upgrade/nakamoto-upgrade-start-here.md
+++ /dev/null
@@ -1,44 +0,0 @@
----
-hidden: true
-noIndex: true
----
-
-# Nakamoto Upgrade - Start Here
-
-The Nakamoto Upgrade is a major upgrade to the Stacks blockchain that instantiated at Bitcoin block 840,360. This marked the start of the [Nakamoto mainnet rollout](nakamoto-rollout-plan/).
-
-There are several important things to be aware of when it comes to how the Nakamoto upgrade will be rolled out and different actions you may need to take depending on your role in the ecosystem.
-
-### The Basics
-
-First of all, if you aren't familiar with what Nakamoto is, you'll want to [get up to speed](what-is-the-nakamoto-release.md).
-
-Next, you'll want to make sure you understand the rollout plan. Nakamoto is a major change to the network, and there are several moving parts and a specific, intentional [rollout plan and timeline](nakamoto-rollout-plan/).
-
-After you familiarize yourself with what Nakamoto is and how it is being rolled out, you can check to see what specific actions you need to take and knowledge you need to have depending on your role. Those are each outlined below.
-
-### Users/STX Holders
-
-The upgrade is simple for you, you don't have to do anything. No token transfers, etc. For most of you, your wallets will be upgraded automatically and you'll be on the upgraded network without even realizing there was a change.
-
-In terms of buying/trading/withdrawing, exchanges _may_ briefly suspend STX-related activities, as they upgrade their nodes. Communicating a deposit/withdrawal suspension is the typical process, but in practice, these suspensions are either very brief or don't end up happening at all assuming their upgrade went smoothly. If an exchange decides to suspend activity they will communicate this to you directly. Again, typically these suspensions are quite brief and most exchanges don't suspend at all. If you have an issue with your exchange, please get in touch with them directly.
-
-### Stackers
-
-After Nakamoto activation, stackers will need to either operate or work with a signer. If you are stacking in a pool, your pool operator will be responsible for running the signer. If you are solo stacking, you can either run your own signer or collaborate with an existing signer in order to stack your STX. For more information on how stacking and signing work together, visit the [Stack STX guide](../guides-and-tutorials/stack-stx/).
-
-### Stacking Pool Operators
-
-If you are a pool operator, you'll need to make sure you are ready to accept delegations and that you have an operational signer you can stack with. Details for this process can be found in the [How to Operate a Pool guide](../guides-and-tutorials/stack-stx/operate-a-pool.md).
-
-### Signers
-
-If you are operating as a signer, you'll want to make sure you familiarize yourself with both the [stacking guide](../guides-and-tutorials/stack-stx/) and the [running a signer guide](../guides-and-tutorials/running-a-signer/). These will give you all the information you need to not only run a signer but understand how signing and stacking work together.
-
-### Application Developers
-
-The instantiation phase (current phase) focuses on activation the new stacking rules in pox-4. Fast blocks won't be available until after Activation, projected \~October 29th. This means that most developers won't need to do anything different, although there are some changes to various Hiro products and tools you should be aware of. Details on this can be found in the [Nakamoto for App Developers](nakamoto-rollout-plan/nakamoto.md) guide.
-
-### Exchanges
-
-For exchanges, your role will be much the same as other upgrades, and really only involves upgrading your node to the newest version. Depending on your setup, you may also want to take a look at some changes to the API and stacks.js. Details can be found in the [Nakamoto for Exchanges](nakamoto-rollout-plan/nakamoto-for-exchanges.md) guide.
diff --git a/nakamoto-upgrade/setting-up-a-primary-post-nakamoto-testnet-node.md b/nakamoto-upgrade/setting-up-a-primary-post-nakamoto-testnet-node.md
deleted file mode 100644
index 1cc99c7d15..0000000000
--- a/nakamoto-upgrade/setting-up-a-primary-post-nakamoto-testnet-node.md
+++ /dev/null
@@ -1,288 +0,0 @@
----
-hidden: true
----
-
-# Setting Up a Primary Nakamoto Testnet Node - Signers
-
-### **Setup A Stacks Primary Testnet Node**
-
-Once your signer is upgraded to version 3.1.0.0.5.0 ([here](https://github.com/stacks-network/stacks-core/releases/tag/signer-3.1.0.0.5.0)) you’ll need to run a primary testnet node alongside it.
-
-You have two options here. The first is to run the Bash script below and it will handle everything for you, including creating the configuration file, downloading and extracting a chain state archive, and getting the node up and running.
-
-If you prefer to handle these yourself, step-by-step instructions are included below the Bash script.
-
-### Automated Bash Script
-
-{% hint style="warning" %}
-Be sure to edit your `auth_token` (previously `block_proposal_token`) field here to match the `auth_password` field in your signer config.
-{% endhint %}
-
-```bash
-STACKS_DIR="${HOME}/nakamoto-testnet"
-STACKS_RPC_PORT="40443"
-STACKS_P2P_PORT="40444"
-
-IMG="blockstack/stacks-core"
-VER="3.1.0.0.5"
-STX_NODE_CONFIG="${STACKS_DIR}/Config.toml"
-
-mkdir -p ${STACKS_DIR}/data
-curl -# -o ${STACKS_DIR}/data/testnet-stacks-blockchain-latest.tar.gz
-tar -xzvf ${STACKS_DIR}/data/testnet-stacks-blockchain-latest.tar.gz -C ${STACKS_DIR}/data/
-
-cat < ${STX_NODE_CONFIG}
-[node]
-working_dir = "/stacks-blockchain/data"
-rpc_bind = "0.0.0.0:20443"
-p2p_bind = "0.0.0.0:20444"
-bootstrap_node = "029266faff4c8e0ca4f934f34996a96af481df94a89b0c9bd515f3536a95682ddc@seed.testnet.hiro.so:30444"
-prometheus_bind = "0.0.0.0:9153"
-stacker = true
-
-[burnchain]
-chain = "bitcoin"
-mode = "krypton"
-peer_host = "bitcoin.regtest.hiro.so"
-peer_port = 18444
-pox_prepare_length = 100
-pox_reward_length = 900
-
-# Set your auth token, which the signer uses
-# This should match the auth_password field of your signer config
-[connection_options]
-auth_token = "12345"
-
-[[events_observer]]
-endpoint = "0.0.0.0.0:30000"
-events_keys = ["stackerdb", "block_proposal", "burn_blocks"]
-
-[[ustx_balance]]
-address = "ST2QKZ4FKHAH1NQKYKYAYZPY440FEPK7GZ1R5HBP2"
-amount = 10000000000000000
-
-[[ustx_balance]]
-address = "ST319CF5WV77KYR1H3GT0GZ7B8Q4AQPY42ETP1VPF"
-amount = 10000000000000000
-
-[[ustx_balance]]
-address = "ST221Z6TDTC5E0BYR2V624Q2ST6R0Q71T78WTAX6H"
-amount = 10000000000000000
-
-[[ustx_balance]]
-address = "ST2TFVBMRPS5SSNP98DQKQ5JNB2B6NZM91C4K3P7B"
-amount = 10000000000000000
-
-[fee_estimation]
-fee_estimator = "fuzzed_weighted_median_fee_rate"
-
-[[burnchain.epochs]]
-epoch_name = "1.0"
-start_height = 0
-
-[[burnchain.epochs]]
-epoch_name = "2.0"
-start_height = 0
-
-[[burnchain.epochs]]
-epoch_name = "2.05"
-start_height = 1
-
-[[burnchain.epochs]]
-epoch_name = "2.1"
-start_height = 2
-
-[[burnchain.epochs]]
-epoch_name = "2.2"
-start_height = 3
-
-[[burnchain.epochs]]
-epoch_name = "2.3"
-start_height = 4
-
-[[burnchain.epochs]]
-epoch_name = "2.4"
-start_height = 5
-
-[[burnchain.epochs]]
-epoch_name = "2.5"
-start_height = 6
-
-[[burnchain.epochs]]
-epoch_name = "3.0"
-start_height = 1_900
-
-[[burnchain.epochs]]
-epoch_name = "3.1"
-start_height = 2_000
-
-[[burnchain.epochs]]
-epoch_name = "3.2"
-start_height = 71_525
-EOF
-
-docker run -d \\
- -v ${STX_NODE_CONFIG}:/config.toml \\
- -v ${STACKS_DIR}/data:/stacks-blockchain/data \\
- -p ${STACKS_RPC_PORT}:20443 \\
- -p ${STACKS_P2P_PORT}:20444 \\
- -e RUST_BACKTRACE=full \\
- --name stacks-node \\
- $IMG:$VER \\
- stacks-node start --config /config.toml
-```
-
-### **Manual Setup**
-
-#### **Node Configuration**
-
-Create a file called `node-config.toml`. Below is a sample of the configuration file you’ll need to use.
-
-**Sample Configuration File**
-
-```toml
-[node]
-working_dir = "/stacks-blockchain/data"
-rpc_bind = "0.0.0.0:20443"
-p2p_bind = "0.0.0.0:20444"
-bootstrap_node = "029266faff4c8e0ca4f934f34996a96af481df94a89b0c9bd515f3536a95682ddc@seed.testnet.hiro.so:30444"
-prometheus_bind = "0.0.0.0:9153"
-
-[burnchain]
-chain = "bitcoin"
-mode = "krypton"
-peer_host = "bitcoin.regtest.hiro.so"
-peer_port = 18444
-pox_prepare_length = 100
-pox_reward_length = 900
-
-[[events_observer]]
-endpoint = "0.0.0.0.0:30000"
-events_keys = ["stackerdb", "block_proposal", "burn_blocks"]
-
-# Set your auth token, which the signer uses
-# This should match the auth_password field of your signer config
-[connection_options]
-auth_token = "12345"
-
-[[ustx_balance]]
-address = "ST2QKZ4FKHAH1NQKYKYAYZPY440FEPK7GZ1R5HBP2"
-amount = 10000000000000000
-
-[[ustx_balance]]
-address = "ST319CF5WV77KYR1H3GT0GZ7B8Q4AQPY42ETP1VPF"
-amount = 10000000000000000
-
-[[ustx_balance]]
-address = "ST221Z6TDTC5E0BYR2V624Q2ST6R0Q71T78WTAX6H"
-amount = 10000000000000000
-
-[[ustx_balance]]
-address = "ST2TFVBMRPS5SSNP98DQKQ5JNB2B6NZM91C4K3P7B"
-amount = 10000000000000000
-
-[fee_estimation]
-fee_estimator = "fuzzed_weighted_median_fee_rate"
-
-[[burnchain.epochs]]
-epoch_name = "1.0"
-start_height = 0
-
-[[burnchain.epochs]]
-epoch_name = "2.0"
-start_height = 0
-
-[[burnchain.epochs]]
-epoch_name = "2.05"
-start_height = 1
-
-[[burnchain.epochs]]
-epoch_name = "2.1"
-start_height = 2
-
-[[burnchain.epochs]]
-epoch_name = "2.2"
-start_height = 3
-
-[[burnchain.epochs]]
-epoch_name = "2.3"
-start_height = 4
-
-[[burnchain.epochs]]
-epoch_name = "2.4"
-start_height = 5
-
-[[burnchain.epochs]]
-epoch_name = "2.5"
-start_height = 6
-
-[[burnchain.epochs]]
-epoch_name = "3.0"
-start_height = 1_900
-
-[[burnchain.epochs]]
-epoch_name = "3.1"
-start_height = 2_000
-
-[[burnchain.epochs]]
-epoch_name = "3.2"
-start_height = 71_525
-```
-
-The important aspects that you’ll need to change are:
-
-`auth_token`: an authentication token that your signer uses to authenticate certain requests to your node. This must match the value you used as `auth_password` in the signer’s configuration.
-
-`events_observer.endpoint`: This is the host (IP address and port) where your signer is configured to listen for events. An example string would be ”`127.0.0.1:30000`” or ”`my-signer.local:30000`”
-
-#### **Start with an archive**
-
-If you are running your Stacks node on the primary testnet, it will be much faster to start with an archive of the chain state rather than syncing from genesis.
-
-Archives can be found from[https://archive.hiro.so](https://archive.hiro.so). For the Stacks node testnet, the latest snapshot can be found at [https://archive.hiro.so/testnet/stacks-blockchain/testnet-stacks-blockchain-latest.tar.gz](https://archive.hiro.so/testnet/stacks-blockchain/testnet-stacks-blockchain-latest.tar.gz). You can also [browse all testnet snapshots](https://archive.hiro.so/testnet/stacks-blockchain/).
-
-You’ll want to download this on the same machine that will run the Stacks node. One way to do this is:
-
-`curl -# -o stacks-snapshot.tar.gz -o /stacks-blockchain/data/latest.tar.gz`
-
-`tar -xzvf /stacks-blockchain/data/latest.tar.gz -C /stacks-blockchain/data`
-
-#### **Run a Stacks Node with Docker**
-
-You can run the Stacks node as a Docker container using the `blockstack/stacks-core` image. When running the Docker container, you’ll need to ensure a few things:
-
-* The port configured for `p2p_bind` must be exposed to the internet for egress
-* The port configured for `rpc_bind` must be accessible by your signer
-* `working_dir` needs to be on a volume with 3-5GB of available storage
-* You’ll need to include your `node-config.toml` file
-
-An example for running the node’s Docker image with docker run is below. Be sure to run this from the same directory as your node-config.toml file or change the STX\_NODE\_CONFIG option.
-
-```bash
-IMG="blockstack/stacks-core"
-
-VER="3.1.0.0.5"
-
-STX_NODE_CONFIG="./node-config.toml"
-
-docker run -d \\
--v $STX_NODE_CONFIG:/config.toml \\
--v /var/stacks \\
--p 20443:20443 \\
--p 20444:20444 \\
--e RUST_BACKTRACE=full \\
---name stacks-node \\
-$IMG:$VER \\
-stacks-node start \\
---config /config.toml
-```
-
-Or, using a custom Dockerfile:
-
-```docker
-FROM blockstack/stacks-core:3.1.0.0.5
-COPY node-config.toml /config.toml
-EXPOSE 20444
-EXPOSE 20443
-CMD ["stacks-node", "start", "--config", "/config.toml"]
-```
diff --git a/nakamoto-upgrade/what-is-the-nakamoto-release.md b/nakamoto-upgrade/what-is-the-nakamoto-release.md
deleted file mode 100644
index 12b584adc4..0000000000
--- a/nakamoto-upgrade/what-is-the-nakamoto-release.md
+++ /dev/null
@@ -1,55 +0,0 @@
----
-hidden: true
----
-
-# What is the Nakamoto Upgrade?
-
-The Nakamoto Release is a recent hard fork on the Stacks network designed to bring several benefits, chief among them are increased transaction throughput and 100% Bitcoin finality.
-
-With Nakamoto, Stacks block production would no longer be tied to miner elections. Instead, miners produce blocks at a fixed cadence, and the set of PoX Stackers rely on the miner elections to determine when the current miner should stop producing blocks and a new miner should start. This blockchain will only fork if 70% of Stackers approve the fork, and chain reorganization will be as difficult as reorganizing Bitcoin.
-
-The Nakamoto release brings many new capabilities and improvements to the Stacks blockchain by focusing on a set of core advancements: improving transaction speed, enhancing finality guarantees for transactions, mitigating Bitcoin miner MEV (miner extractable value) opportunities that affect PoX, and boosting robustness against chain reorganizations.
-
-### Previous Stacks Block Production Design
-
-The Stacks blockchain today produces blocks in accordance with the algorithms described in [SIP-001](https://github.com/stacksgov/sips/blob/main/sips/sip-001/sip-001-burn-election.md) and [SIP-007](https://github.com/stacksgov/sips/blob/main/sips/sip-007/sip-007-stacking-consensus.md), and [SIP-015](https://github.com/stacksgov/sips/blob/main/sips/sip-015/sip-015-network-upgrade.md). Miners compete to append a block to the blockchain through the miner selection process facilitated by a VRF backed sortition process. Miners submit a block-commit transaction to Bitcoin, which commits to the hash of the block the miner intends to append. The sortition process selects at most one block-commit in the subsequent Bitcoin block, which entitles the submitter to propagate their block and earn a block reward.
-
-{% hint style="info" %}
-Throughout this documentation and the SIPs, you'll frequently see the term "cryptographic sortition" or some variation thereof (miner sortition, the sortition, etc.). A Cryptographic sortition is a process of randomly selecting one or more entities from a set using cryptography. This is a decentralized and verifiable way to select participants for a variety of tasks, such as consensus protocols, lotteries, and auctions.
-
-More specifically, miner sortition in the context of Stacks is the weighted cryptographic sortition process by which a miner candidate is selected as the next miner (leader). Details of this process are in [SIP-001](https://github.com/stacksgov/sips/blob/main/sips/sip-001/sip-001-burn-election.md) with mechanism alterations in [SIP-007](https://github.com/stacksgov/sips/blob/main/sips/sip-007/sip-007-stacking-consensus.md).
-
-Nakamoto will introduce further mechanism alterations to this process.
-{% endhint %}
-
-### The Problems
-
-Over the last three years the Stacks community has identified several issues with the current system design:
-
-1. **Slow Bitcoin blocks, Stacks forks, and missed sortitions are disruptive to on-chain applications.** The act of waiting to produce a new block until after a sortition elects a valid miner ties best-case Stacks block production rate to the block production rate of Bitcoin, leading to very high transaction confirmation latency.
-2. **Microblocks are not effective in speeding up transaction confirmation time.** While microblocks have the potential to mitigate missed sortitions and improve transaction inclusion time, they do not work in practice because the protocol cannot ensure that microblocks will be confirmed until the next sortition happens. Additionally, new miners will often orphan recently-confirmed transactions from the old miner that were included in microblocks because there is no consensus-critical procedure that forces the next miner to build upon the latest microblock.
-3. **Stacks forks are not tied to Bitcoin forks, allowing cheap reorgs** The cost to reorg the last N blocks in the Stacks blockchain is the cost to produce the next N + 1 Stacks blocks (i.e. by spending BTC), which is cheap compared to the cost of reorging the Bitcoin. This SIP describes an opportunity to tie the canonical Stacks fork to the Bitcoin blockchain such that the act of reorging Stacks chain history requires the Stacks miner to produce the fork with 70% of stacker sign-off.
-4. **Stacks forks arise due to poorly-connected miners.** If a set of miners has a hard time learning the canonical Stacks chain tip when they submit block-commits, then they will collectively orphan other miners who are better-connected. This has happened in practice.
-5. **Some Bitcoin miners run their own Stacks miners and deliberately exclude other Stacks miners' `block-commits` from their Bitcoin blocks.** Once the STX block reward became sufficiently large this allowed them to pay a trivial PoX payout while guaranteeing that they would win the cryptographic sortition in their Bitcoin block. This was anticipated in the original design but the regularity with which it happens today is greater than the original protocol accounted for, and thus must be addressed now.
-
-### The Solutions
-
-To address these shortcomings, Nakamoto applies three fundamental changes to the way Stacks works.
-
-* **Fast blocks:** The time taken for a user-submitted transaction to be mined within a block (and thus confirmed) will now take on the order of seconds, instead of tens of minutes. This is achieved by separating block production from cryptographic sortitions -- a winning miner may produce many blocks between two subsequent sortitions.
-* **Bitcoin finality:** Once a transaction is confirmed, reversing it is at least as hard as reversing a Bitcoin transaction. The Stacks blockchain no longer forks on its own.
-* **Bitcoin Miner MEV Resistance:** This proposal alters the sortition algorithm to ensure that Bitcoin miners do not have an advantage as Stacks miners. They must spend competitive amounts of Bitcoin currency to have a chance of earning STX.
-
-### Nakamoto Design
-
-To achieve these goals Nakamoto introduced the following changes to the Stacks protocol:
-
-1. **Decouple Stacks tenure changes from Bitcoin block arrivals.** In both today's system and Nakamoto, miners take turns appending blocks to the Stacks blockchain -- the next miner is selected by cryptographic sortition, and the miner has the duration of the Bitcoin block (its tenure) to announce a new block state. Nakamoto allows a miner to produce many Stacks blocks per Bitcoin block instead of one, and requiring the next miner to confirm all of them. There are no more microblocks or Bitcoin-anchored blocks; instead, there are only Nakamoto Stacks blocks. This will achieve fast block times.
-2. **Require stackers to collaborate before the next block can be produced.** Stackers will need to collectively validate, store, sign, and propagate each Nakamoto Stacks block the miner produces before the next block can be produced. Stackers must do this in order to earn their PoX payouts and unlock their STX (i.e. PoX is now treated as compensation from the miner for playing this essential role). In Nakamoto, a sortition only selects a new miner; it does not give the miner the power to unilaterally orphan confirmed transactions as it does today. This will ensure that miners do not produce forks and are able to confirm all prior Stacks blocks prior to selection.
-3. **Use stackers to police miner behavior.** A sortition causes the Stackers to carry out a tenure change by (a) agreeing on a "last-signed" block from the current miner, and (b) agreeing to only sign blocks from the new miner which descend from this last-signed block. Thus, Stackers police miner behavior -- Stackers prevent miners from mining forks during their tenure, and ensure that they begin their tenures by building atop the canonical chain tip. The new miner cannot orphan recently-confirmed transactions from the old miner because the signers who approved the tenure change are necessarily aware of all Stacks blocks that came before it. This **further prevents miners from forking the Stacks blockchain.**
-4. **Require Stacks miners to commit the indexed block hash of the first block produced by the last Stacks miner in their block-commit transactions on the Bitcoin blockchain.** This is the SHA512/256 hash of both the consensus hash of all previously-accepted Bitcoin transactions that Stacks recognizes, as well as the hash of the block itself (a block-commit today only contains the hash of the Stacks block). This will anchor the Stacks chain history to the Bitcoin up to the start of the previous miner's tenure, as well as all causally-dependent Bitcoin state that Stacks has processed. This **ensures Bitcoin finality and resolves miner connectivity issues** by putting fork prevention on Stackers.
-5. **Adopt a Bitcoin MEV solution which punishes block-commit censorship.** The probability a stacks miner wins a sortition should be altered such that omitting block commits of honest Stacks miners is not profitable to Bitcoin miners. The mechanics of this are outlined below.
-
-Although Nakamoto is a breaking change, all smart contracts published prior to this its activation will be usable after it activates.
-
-Let's dive into how each of these pieces work so we can get an in-depth understanding of exactly how Nakamoto works.
diff --git a/press-and-top-links/2024/README.md b/press-and-top-links/2024/README.md
deleted file mode 100644
index 1d2f6eddf0..0000000000
--- a/press-and-top-links/2024/README.md
+++ /dev/null
@@ -1,63 +0,0 @@
----
-description: >-
- This page indexes top stories, press, and reports related to Stacks on a
- monthly basis.
-cover: ../../.gitbook/assets/+ (6).svg
-coverY: 0
----
-
-# 🔶 2024
-
-For weekly stories delivered to your inbox, subscribe to [Stacks Snacks](https://stackssnacks.com/). For quarterly ecosystem recaps, subscribe to the [Stacks Foundation newsletter](https://newsletters.stacks.org).
-
-{% content-ref url="january-2024.md" %}
-[january-2024.md](january-2024.md)
-{% endcontent-ref %}
-
-{% content-ref url="february-2024.md" %}
-[february-2024.md](february-2024.md)
-{% endcontent-ref %}
-
-{% content-ref url="march-2024.md" %}
-[march-2024.md](march-2024.md)
-{% endcontent-ref %}
-
-{% content-ref url="april-2024.md" %}
-[april-2024.md](april-2024.md)
-{% endcontent-ref %}
-
-{% content-ref url="may-2024.md" %}
-[may-2024.md](may-2024.md)
-{% endcontent-ref %}
-
-{% content-ref url="may-2024-1.md" %}
-[may-2024-1.md](may-2024-1.md)
-{% endcontent-ref %}
-
-{% content-ref url="may-2024-2.md" %}
-[may-2024-2.md](may-2024-2.md)
-{% endcontent-ref %}
-
-{% content-ref url="may-2024-3.md" %}
-[may-2024-3.md](may-2024-3.md)
-{% endcontent-ref %}
-
-{% content-ref url="september-2024.md" %}
-[september-2024.md](september-2024.md)
-{% endcontent-ref %}
-
-{% content-ref url="october-2024.md" %}
-[october-2024.md](october-2024.md)
-{% endcontent-ref %}
-
-{% content-ref url="october-2024-1.md" %}
-[october-2024-1.md](october-2024-1.md)
-{% endcontent-ref %}
-
-{% content-ref url="october-2024-1-1.md" %}
-[october-2024-1-1.md](october-2024-1-1.md)
-{% endcontent-ref %}
-
-{% hint style="info" %}
-
-{% endhint %}
diff --git a/press-and-top-links/2024/april-2024.md b/press-and-top-links/2024/april-2024.md
deleted file mode 100644
index 46b84d43ba..0000000000
--- a/press-and-top-links/2024/april-2024.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-description: >-
- In April, the Nakamoto mainnet rollout began and news about Stacks and the
- upgrade was impossible to miss. Stacks was featured as a leading L2 across
- major crypto publications, newsletters, and more.
----
-
-# 🔸 April 2024
-
-
diff --git a/press-and-top-links/2024/february-2024.md b/press-and-top-links/2024/february-2024.md
deleted file mode 100644
index 6da3dd3742..0000000000
--- a/press-and-top-links/2024/february-2024.md
+++ /dev/null
@@ -1,21 +0,0 @@
-# 🔸 February 2024
-
-_For weekly stories delivered to your inbox, subscribe to_ [_Stacks Snacks_](https://stackssnacks.com/)_. For quarterly ecosystem recaps, subscribe to the_ [_Stacks Foundation newsletter_](https://newsletters.stacks.org)_._
-
-
-
-📊 Messari's Q4 2023 'State of Stacks' Report
-
-[https://messari.io/report/state-of-stacks-q4-2023](https://messari.io/report/state-of-stacks-q4-2023)
-
-#### Key Insights
-
-* **Stacks revenue (USD) increased 3,386% QoQ and 3,028% YoY to $637,000.** Much of this revenue was driven by inscription protocol STX20.
-* **STX’s market cap increased 203% QoQ and 598% YoY to $2.0 billion.** STX’s growth outpaced BTC and the overall crypto market.
-* **DeFi TVL (USD) increased 363% QoQ and 763% YoY to $61 million.** ALEX firmly remained the leader in TVL, but Arkadiko and StackingDAO considerably increased their own TVL dominance in Q3 and Q4.
-* **Average daily miner revenue increased 1,015% YoY to $78,000.** STX’s price increase and Stacks’ increased revenue made it significantly more profitable for Bitcoin miners to participate in Stacks’ consensus.
-* **The Nakamoto upgrade is expected in April 2024.** This update will enable faster blocks, give transactions 100% Bitcoin finality, reduce MEV, and eliminate forking on the Stacks layer to set the stage for the upcoming sBTC release.
-
-
-
-
diff --git a/press-and-top-links/2024/january-2024.md b/press-and-top-links/2024/january-2024.md
deleted file mode 100644
index 6a38dae037..0000000000
--- a/press-and-top-links/2024/january-2024.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# 🔸 January 2024
-
-For weekly stories delivered to your inbox, subscribe to [Stacks Snacks](https://stackssnacks.com/). For quarterly ecosystem recaps, subscribe to the [Stacks Foundation newsletter](https://newsletters.stacks.org).
-
-
-
-📙 Bitcoin Layers Report by Spartan Group
-
-
-
-#### **Tapestry of a Trustless Financial Era**
-
-Diving deep into the layers of Bitcoin's blossoming ecosystem, the first edition of the Bitcoin Layers Report unveils the emerging reality of a financial world where trust is embedded in technology rather than institutions. As Bitcoin evolves beyond a Store of Value, we stand on the cusp of a revolution in trustless finance and a new era of economic possibilities. [https://bitcoinlayersreport.com/](https://bitcoinlayersreport.com/)
-
-
-
-
diff --git a/press-and-top-links/2024/may-2024-1.md b/press-and-top-links/2024/may-2024-1.md
deleted file mode 100644
index 3e0bb0ca60..0000000000
--- a/press-and-top-links/2024/may-2024-1.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
-description: >-
- In June, the Haruko partnership was announced and new voices were added to the
- growing Bitcoin layer-2 movement.
----
-
-# 🔸 June 2024
-
-
diff --git a/press-and-top-links/2024/may-2024-2.md b/press-and-top-links/2024/may-2024-2.md
deleted file mode 100644
index c37589e0d6..0000000000
--- a/press-and-top-links/2024/may-2024-2.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-description: >-
- Bitcoin Summer continued in July: BitGo stepped up to join the Stacks signer
- network, Stacks teams Bitflow and Hermetica landed their own media and
- builders everywhere convened in Nashville.
----
-
-# 🔸 July 2024
-
-
diff --git a/reference/api.md b/reference/api.md
deleted file mode 100644
index eca1fca0d8..0000000000
--- a/reference/api.md
+++ /dev/null
@@ -1,229 +0,0 @@
-# API
-
-### Introduction
-
-The Stacks Blockchain API allows you to query the Stacks blockchain and interact with smart contracts. It was built to maintain pageable materialized views of the Stacks Blockchain.
-
-Note that the [Stacks Node RPC API](https://github.com/stacks-network/stacks-blockchain/) and the [Hiro Stacks API](https://www.hiro.so/stacks-api) are two different things. The Hiro API is a centralized service run by Hiro, a developer tooling company, that makes it easy to get onboarded and begin interacting with the Stacks blockchain in a RESTful way. You can also [run your own API server](https://docs.hiro.so/get-started/running-api-node).
-
-The Hiro Stacks API is a proxy for the Stacks Node API that makes it a bit easier to work with by providing additional functionality.
-
-The RPC API is generated by every Stacks node and allows developers to self-host their own node and API for a more decentralized architecture.
-
-The RPC API can be used without any authorization. The basepath for the API is:
-
-```bash
-# for mainnet, replace `testnet` with `mainnet`
-https://api.testnet.hiro.so/
-```
-
-{% hint style="warning" %}
-If you run a local node, it exposes an HTTP server on port `20443`. The info endpoint would be `localhost:20443/v2/info`.
-{% endhint %}
-
-
-
-### Stacks Node RPC API endpoints
-
-The Stacks 2.0 Blockchain API (Hiro's API) is centrally hosted. However, every running Stacks node exposes an RPC API, which allows you to interact with the underlying blockchain. Instead of using a centrally hosted API, you can directly access the RPC API of a locally hosted Node.
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v2/contracts/interface/{contract_address}/{contract_name}" method="get" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v2/transactions" method="post" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v2/map_entry/{contract_address}/{contract_name}/{map_name}" method="post" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v3/blocks/upload" method="post" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v2/mempool/query" method="post" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v2/blocks/upload/{consensus_hash}" method="post" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v2/transactions/unconfirmed/{txid}" method="get" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v3/tenures/tip/{consensus_hash}" method="get" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v3/tenures/fork_info/{start}/{stop}" method="get" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v2/neighbors" method="get" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v2/blocks/{block_id}" method="get" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v2/headers/{quantity}" method="get" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v2/data_var/{principal}/{contract_name}/{var_name}" method="get" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v2/stackerdb/{principal}/{contract_name}/replicas" method="get" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v2/stackerdb/{principal}/{contract_name}/chunks" method="post" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v2/stackerdb/{principal}/{contract_name}" method="get" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v2/stackerdb/{principal}/{contract_name}/{slot_id}/{slot_version}" method="get" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v2/stackerdb/{principal}/{contract_name}/{slot_id}" method="get" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v2/microblocks" method="post" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v2/microblocks/unconfirmed/{block_id}/{seq}" method="get" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v2/microblocks/{microblock_id}" method="get" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v2/microblocks/confirmed/{block_id}" method="get" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v2/attachments/inv" method="get" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v2/attachments/{hash}" method="get" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v3/health" method="get" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v3/transaction/{txid}" method="get" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v3/signer/{signer_pubkey}/{cycle_number}" method="get" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v3/sortitions/burn_height/{height}" method="get" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v3/sortitions/burn/{burn_header_hash}" method="get" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v3/sortitions/consensus/{consensus_hash}" method="get" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v3/sortitions/latest_and_last" method="get" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v3/sortitions" method="get" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v3/tenures/{block_id}" method="get" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v3/tenures/info" method="get" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v3/blocks/height/{block_height}" method="get" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v3/blocks/{block_id}" method="get" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v3/stacker_set/{cycle_number}" method="get" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v3/block_proposal" method="post" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v2/constant_val/{contract_address}/{contract_name}/{constant_name}" method="get" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v2/clarity/metadata/{contract_address}/{contract_name}/{clarity_metadata_key}" method="get" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v2/clarity/marf/{marf_key_hash}" method="get" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v2/traits/{contract_address}/{contract_name}/{trait_contract_address}/{trait_contract_name}/{trait_name}" method="get" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v2/pox" method="get" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v2/info" method="get" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v2/fees/transfer" method="get" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v2/fees/transaction" method="post" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v2/accounts/{principal}" method="get" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v3/contracts/fast-call-read/{contract_address}/{contract_name}/{function_name}" method="post" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v2/contracts/call-read/{contract_address}/{contract_name}/{function_name}" method="post" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
-{% openapi-operation spec="stacks-blockchain-api" path="/v2/contracts/source/{contract_address}/{contract_name}" method="get" %}
-[OpenAPI stacks-blockchain-api](https://raw.githubusercontent.com/stacks-network/stacks-core/master/docs/rpc/openapi.yaml)
-{% endopenapi-operation %}
-
diff --git a/reference/functions.md b/reference/functions.md
deleted file mode 100644
index f92d3b95c5..0000000000
--- a/reference/functions.md
+++ /dev/null
@@ -1,2968 +0,0 @@
-# Functions
-
-## \* (multiply)
-
-Introduced in: **Clarity 1**
-
-**input:** `int, ... | uint, ...`
-
-**output:** `int | uint`
-
-**signature:** `(* i1 i2...)`
-
-**description:**
-
-Multiplies a variable number of integer inputs and returns the result. In the event of an _overflow_, throws a runtime error.
-
-**example:**
-
-```
-(* 2 3) ;; Returns 6
-(* 5 2) ;; Returns 10
-(* 2 2 2) ;; Returns 8
-```
-
-## + (add)
-
-Introduced in: **Clarity 1**
-
-**input:** `int, ... | uint, ...`
-
-**output:** `int | uint`
-
-**signature:** `(+ i1 i2...)`
-
-**description:**
-
-Adds a variable number of integer inputs and returns the result. In the event of an _overflow_, throws a runtime error.
-
-**example:**
-
-```
-(+ 1 2 3) ;; Returns 6
-```
-
-## - (subtract)
-
-Introduced in: **Clarity 1**
-
-**input:** `int, ... | uint, ...`
-
-**output:** `int | uint`
-
-**signature:** `(- i1 i2...)`
-
-**description:**
-
-Subtracts a variable number of integer inputs and returns the result. In the event of an _underflow_, throws a runtime error.
-
-**example:**
-
-```
-(- 2 1 1) ;; Returns 0
-(- 0 3) ;; Returns -3
-```
-
-## / (divide)
-
-Introduced in: **Clarity 1**
-
-**input:** `int, ... | uint, ...`
-
-**output:** `int | uint`
-
-**signature:** `(/ i1 i2...)`
-
-**description:**
-
-Integer divides a variable number of integer inputs and returns the result. In the event of division by zero, throws a runtime error.
-
-**example:**
-
-```
-(/ 2 3) ;; Returns 0
-(/ 5 2) ;; Returns 2
-(/ 4 2 2) ;; Returns 1
-```
-
-## < (less than)
-
-Introduced in: **Clarity 1**
-
-**input:** `int, int | uint, uint | string-ascii, string-ascii | string-utf8, string-utf8 | buff, buff`
-
-**output:** `bool`
-
-**signature:** `(< i1 i2)`
-
-**description:**
-
-Compares two integers, returning `true` if `i1` is less than `i2` and `false` otherwise. i1 and i2 must be of the same type. Starting with Stacks 1.0, the `<`-comparable types are `int` and `uint`. Starting with Stacks 2.1, the `<`-comparable types are expanded to include `string-ascii`, `string-utf8` and `buff`.
-
-**example:**
-
-```
-(< 1 2) ;; Returns true
-(< 5 2) ;; Returns false
-(< "aaa" "baa") ;; Returns true
-(< "aa" "aaa") ;; Returns true
-(< 0x01 0x02) ;; Returns true
-(< 5 u2) ;; Throws type error
-```
-
-## <= (less than or equal)
-
-Introduced in: **Clarity 1**
-
-**input:** `int, int | uint, uint | string-ascii, string-ascii | string-utf8, string-utf8 | buff, buff`
-
-**output:** `bool`
-
-**signature:** `(<= i1 i2)`
-
-**description:**
-
-Compares two integers, returning true if `i1` is less than or equal to `i2` and `false` otherwise. i1 and i2 must be of the same type. Starting with Stacks 1.0, the `<=`-comparable types are `int` and `uint`. Starting with Stacks 2.1, the `<=`-comparable types are expanded to include `string-ascii`, `string-utf8` and `buff`.
-
-**example:**
-
-```
-(<= 1 1) ;; Returns true
-(<= 5 2) ;; Returns false
-(<= "aaa" "baa") ;; Returns true
-(<= "aa" "aaa") ;; Returns true
-(<= 0x01 0x02) ;; Returns true
-(<= 5 u2) ;; Throws type error
-```
-
-## > (greater than)
-
-Introduced in: **Clarity 1**
-
-**input:** `int, int | uint, uint | string-ascii, string-ascii | string-utf8, string-utf8 | buff, buff`
-
-**output:** `bool`
-
-**signature:** `(> i1 i2)`
-
-**description:**
-
-Compares two integers, returning `true` if `i1` is greater than `i2` and false otherwise. i1 and i2 must be of the same type. Starting with Stacks 1.0, the `>`-comparable types are `int` and `uint`. Starting with Stacks 2.1, the `>`-comparable types are expanded to include `string-ascii`, `string-utf8` and `buff`.
-
-**example:**
-
-```
-(> 1 2) ;; Returns false
-(> 5 2) ;; Returns true
-(> "baa" "aaa") ;; Returns true
-(> "aaa" "aa") ;; Returns true
-(> 0x02 0x01) ;; Returns true
-(> 5 u2) ;; Throws type error
-```
-
-## >= (greater than or equal)
-
-Introduced in: **Clarity 1**
-
-**input:** `int, int | uint, uint | string-ascii, string-ascii | string-utf8, string-utf8 | buff, buff`
-
-**output:** `bool`
-
-**signature:** `(>= i1 i2)`
-
-**description:**
-
-Compares two integers, returning `true` if `i1` is greater than or equal to `i2` and `false` otherwise. i1 and i2 must be of the same type. Starting with Stacks 1.0, the `>=`-comparable types are `int` and `uint`. Starting with Stacks 2.1, the `>=`-comparable types are expanded to include `string-ascii`, `string-utf8` and `buff`.
-
-**example:**
-
-```
-(>= 1 1) ;; Returns true
-(>= 5 2) ;; Returns true
-(>= "baa" "aaa") ;; Returns true
-(>= "aaa" "aa") ;; Returns true
-(>= 0x02 0x01) ;; Returns true
-(>= 5 u2) ;; Throws type error
-```
-
-## and
-
-Introduced in: **Clarity 1**
-
-**input:** `bool, ...`
-
-**output:** `bool`
-
-**signature:** `(and b1 b2 ...)`
-
-**description:**
-
-Returns `true` if all boolean inputs are `true`. Importantly, the supplied arguments are evaluated in-order and lazily. Lazy evaluation means that if one of the arguments returns `false`, the function short-circuits, and no subsequent arguments are evaluated.
-
-**example:**
-
-```
-(and true false) ;; Returns false
-(and (is-eq (+ 1 2) 1) (is-eq 4 4)) ;; Returns false
-(and (is-eq (+ 1 2) 3) (is-eq 4 4)) ;; Returns true
-```
-
-## append
-
-Introduced in: **Clarity 1**
-
-**input:** `list A, A`
-
-**output:** `list`
-
-**signature:** `(append (list 1 2 3 4) 5)`
-
-**description:**
-
-The `append` function takes a list and another value with the same entry type, and outputs a list of the same type with max\_len += 1.
-
-**example:**
-
-```
-(append (list 1 2 3 4) 5) ;; Returns (1 2 3 4 5)
-```
-
-## as-contract
-
-Introduced in: **Clarity 1**
-
-**input:** `A`
-
-**output:** `A`
-
-**signature:** `(as-contract expr)`
-
-**description:**
-
-The `as-contract` function switches the current context's `tx-sender` value to the _contract's_ principal and executes `expr` with that context. It returns the resulting value of `expr`.
-
-**example:**
-
-```
-(as-contract tx-sender) ;; Returns S1G2081040G2081040G2081040G208105NK8PE5.docs-test
-```
-
-## as-max-len?
-
-Introduced in: **Clarity 1**
-
-**input:** `sequence_A, uint`
-
-**output:** `(optional sequence_A)`
-
-**signature:** `(as-max-len? sequence max_length)`
-
-**description:**
-
-The `as-max-len?` function takes a sequence argument and a uint-valued, literal length argument. The function returns an optional type. If the input sequence length is less than or equal to the supplied max\_length, this returns `(some sequence)`, otherwise it returns `none`. Applicable sequence types are `(list A)`, `buff`, `string-ascii` and `string-utf8`.
-
-**example:**
-
-```
-(as-max-len? (list 2 2 2) u3) ;; Returns (some (2 2 2))
-(as-max-len? (list 1 2 3) u2) ;; Returns none
-(as-max-len? "hello" u10) ;; Returns (some "hello")
-(as-max-len? 0x010203 u10) ;; Returns (some 0x010203)
-```
-
-## asserts!
-
-Introduced in: **Clarity 1**
-
-**input:** `bool, C`
-
-**output:** `bool`
-
-**signature:** `(asserts! bool-expr thrown-value)`
-
-**description:**
-
-The `asserts!` function admits a boolean argument and asserts its evaluation: if bool-expr is `true`, `asserts!` returns `true` and proceeds in the program execution. If the supplied argument is returning a false value, `asserts!` _returns_ `thrown-value` and exits the current control-flow.
-
-**example:**
-
-```
-(asserts! (is-eq 1 1) (err 1)) ;; Returns true
-```
-
-## at-block
-
-Introduced in: **Clarity 1**
-
-**input:** `(buff 32), A`
-
-**output:** `A`
-
-**signature:** `(at-block id-block-hash expr)`
-
-**description:**
-
-The `at-block` function evaluates the expression `expr` _as if_ it were evaluated at the end of the block indicated by the _block-hash_ argument. The `expr` closure must be read-only.
-
-Note: The block identifying hash must be a hash returned by the `id-header-hash` block information property. This hash uniquely identifies Stacks blocks and is unique across Stacks forks. While the hash returned by `header-hash` is unique within the context of a single fork, it is not unique across Stacks forks.
-
-The function returns the result of evaluating `expr`.
-
-**example:**
-
-```
-(define-data-var data int 1)
-(at-block 0x0000000000000000000000000000000000000000000000000000000000000000 block-height) ;; Returns u0
-(at-block (get-block-info? id-header-hash 0) (var-get data)) ;; Throws NoSuchDataVariable because `data` wasn't initialized at block height 0
-```
-
-## begin
-
-Introduced in: **Clarity 1**
-
-**input:** `AnyType, ... A`
-
-**output:** `A`
-
-**signature:** `(begin expr1 expr2 expr3 ... expr-last)`
-
-**description:**
-
-The `begin` function evaluates each of its input expressions, returning the return value of the last such expression. Note: intermediary statements returning a response type must be checked.
-
-**example:**
-
-```
-(begin (+ 1 2) 4 5) ;; Returns 5
-```
-
-## bit-and
-
-Introduced in: **Clarity 2**
-
-**input:** `int, ... | uint, ...`
-
-**output:** `int | uint`
-
-**signature:** `(bit-and i1 i2...)`
-
-**description:**
-
-Returns the result of bitwise and'ing a variable number of integer inputs.
-
-**example:**
-
-```
-(bit-and 24 16) ;; Returns 16
-(bit-and 28 24 -1) ;; Returns 24
-(bit-and u24 u16) ;; Returns u16
-(bit-and -128 -64) ;; Returns -128
-(bit-and 28 24 -1) ;; Returns 24
-```
-
-## bit-not
-
-Introduced in: **Clarity 2**
-
-**input:** `int | uint`
-
-**output:** `int | uint`
-
-**signature:** `(bit-not i1)`
-
-**description:**
-
-Returns the one's complement (sometimes also called the bitwise compliment or not operator) of `i1`, effectively reversing the bits in `i1`. In other words, every bit that is `1` in ì1`will be`0`in the result. Conversely, every bit that is`0`in`i1`will be`1\` in the result.
-
-**example:**
-
-```
-(bit-not 3) ;; Returns -4
-(bit-not u128) ;; Returns u340282366920938463463374607431768211327
-(bit-not 128) ;; Returns -129
-(bit-not -128) ;; Returns 127
-```
-
-## bit-or
-
-Introduced in: **Clarity 2**
-
-**input:** `int, ... | uint, ...`
-
-**output:** `int | uint`
-
-**signature:** `(bit-or i1 i2...)`
-
-**description:**
-
-Returns the result of bitwise inclusive or'ing a variable number of integer inputs.
-
-**example:**
-
-```
-(bit-or 4 8) ;; Returns 12
-(bit-or 1 2 4) ;; Returns 7
-(bit-or 64 -32 -16) ;; Returns -16
-(bit-or u2 u4 u32) ;; Returns u38
-```
-
-## bit-shift-left
-
-Introduced in: **Clarity 2**
-
-**input:** `int, uint | uint, uint`
-
-**output:** `int | uint`
-
-**signature:** `(bit-shift-left i1 shamt)`
-
-**description:**
-
-Shifts all the bits in `i1` to the left by the number of places specified in `shamt` modulo 128 (the bit width of Clarity integers).
-
-Note that there is a deliberate choice made to ignore arithmetic overflow for this operation. In use cases where overflow should be detected, developers should use `*`, `/`, and `pow` instead of the shift operators.
-
-**example:**
-
-```
-(bit-shift-left 2 u1) ;; Returns 4
-(bit-shift-left 16 u2) ;; Returns 64
-(bit-shift-left -64 u1) ;; Returns -128
-(bit-shift-left u4 u2) ;; Returns u16
-(bit-shift-left 123 u9999999999) ;; Returns -170141183460469231731687303715884105728
-(bit-shift-left u123 u9999999999) ;; Returns u170141183460469231731687303715884105728
-(bit-shift-left -1 u7) ;; Returns -128
-(bit-shift-left -1 u128) ;; Returns -1
-```
-
-## bit-shift-right
-
-Introduced in: **Clarity 2**
-
-**input:** `int, uint | uint, uint`
-
-**output:** `int | uint`
-
-**signature:** `(bit-shift-right i1 shamt)`
-
-**description:**
-
-Shifts all the bits in `i1` to the right by the number of places specified in `shamt` modulo 128 (the bit width of Clarity integers). When `i1` is a `uint` (unsigned), new bits are filled with zeros. When `i1` is an `int` (signed), the sign is preserved, meaning that new bits are filled with the value of the previous sign-bit.
-
-Note that there is a deliberate choice made to ignore arithmetic overflow for this operation. In use cases where overflow should be detected, developers should use `*`, `/`, and `pow` instead of the shift operators.
-
-**example:**
-
-```
-(bit-shift-right 2 u1) ;; Returns 1
-(bit-shift-right 128 u2) ;; Returns 32
-(bit-shift-right -64 u1) ;; Returns -32
-(bit-shift-right u128 u2) ;; Returns u32
-(bit-shift-right 123 u9999999999) ;; Returns 0
-(bit-shift-right u123 u9999999999) ;; Returns u0
-(bit-shift-right -128 u7) ;; Returns -1
-(bit-shift-right -256 u1) ;; Returns -128
-(bit-shift-right 5 u2) ;; Returns 1
-(bit-shift-right -5 u2) ;; Returns -2
-```
-
-## bit-xor
-
-Introduced in: **Clarity 2**
-
-**input:** `int, ... | uint, ...`
-
-**output:** `int | uint`
-
-**signature:** `(bit-xor i1 i2...)`
-
-**description:**
-
-Returns the result of bitwise exclusive or'ing a variable number of integer inputs.
-
-**example:**
-
-```
-(bit-xor 1 2) ;; Returns 3
-(bit-xor 120 280) ;; Returns 352
-(bit-xor -128 64) ;; Returns -64
-(bit-xor u24 u4) ;; Returns u28
-(bit-xor 1 2 4 -1) ;; Returns -8
-```
-
-## buff-to-int-be
-
-Introduced in: **Clarity 2**
-
-**input:** `(buff 16)`
-
-**output:** `int`
-
-**signature:** `(buff-to-int-be (buff 16))`
-
-**description:**
-
-Converts a byte buffer to a signed integer use a big-endian encoding. The byte buffer can be up to 16 bytes in length. If there are fewer than 16 bytes, as this function uses a big-endian encoding, the input behaves as if it is zero-padded on the _left_.
-
-Note: This function is only available starting with Stacks 2.1.
-
-**example:**
-
-```
-(buff-to-int-be 0x01) ;; Returns 1
-(buff-to-int-be 0x00000000000000000000000000000001) ;; Returns 1
-(buff-to-int-be 0xffffffffffffffffffffffffffffffff) ;; Returns -1
-(buff-to-int-be 0x) ;; Returns 0
-```
-
-## buff-to-int-le
-
-Introduced in: **Clarity 2**
-
-**input:** `(buff 16)`
-
-**output:** `int`
-
-**signature:** `(buff-to-int-le (buff 16))`
-
-**description:**
-
-Converts a byte buffer to a signed integer use a little-endian encoding. The byte buffer can be up to 16 bytes in length. If there are fewer than 16 bytes, as this function uses a little-endian encoding, the input behaves as if it is zero-padded on the _right_.
-
-Note: This function is only available starting with Stacks 2.1.
-
-**example:**
-
-```
-(buff-to-int-le 0x01) ;; Returns 1
-(buff-to-int-le 0x01000000000000000000000000000000) ;; Returns 1
-(buff-to-int-le 0xffffffffffffffffffffffffffffffff) ;; Returns -1
-(buff-to-int-le 0x) ;; Returns 0
-```
-
-## buff-to-uint-be
-
-Introduced in: **Clarity 2**
-
-**input:** `(buff 16)`
-
-**output:** `uint`
-
-**signature:** `(buff-to-uint-be (buff 16))`
-
-**description:**
-
-Converts a byte buffer to an unsigned integer use a big-endian encoding. The byte buffer can be up to 16 bytes in length. If there are fewer than 16 bytes, as this function uses a big-endian encoding, the input behaves as if it is zero-padded on the _left_.
-
-Note: This function is only available starting with Stacks 2.1.
-
-**example:**
-
-```
-(buff-to-uint-be 0x01) ;; Returns u1
-(buff-to-uint-be 0x00000000000000000000000000000001) ;; Returns u1
-(buff-to-uint-be 0xffffffffffffffffffffffffffffffff) ;; Returns u340282366920938463463374607431768211455
-(buff-to-uint-be 0x) ;; Returns u0
-```
-
-## buff-to-uint-le
-
-Introduced in: **Clarity 2**
-
-**input:** `(buff 16)`
-
-**output:** `uint`
-
-**signature:** `(buff-to-uint-le (buff 16))`
-
-**description:**
-
-Converts a byte buffer to an unsigned integer use a little-endian encoding.. The byte buffer can be up to 16 bytes in length. If there are fewer than 16 bytes, as this function uses a little-endian encoding, the input behaves as if it is zero-padded on the _right_.
-
-Note: This function is only available starting with Stacks 2.1.
-
-**example:**
-
-```
-(buff-to-uint-le 0x01) ;; Returns u1
-(buff-to-uint-le 0x01000000000000000000000000000000) ;; Returns u1
-(buff-to-uint-le 0xffffffffffffffffffffffffffffffff) ;; Returns u340282366920938463463374607431768211455
-(buff-to-uint-le 0x) ;; Returns u0
-```
-
-## concat
-
-Introduced in: **Clarity 1**
-
-**input:** `sequence_A, sequence_A`
-
-**output:** `sequence_A`
-
-**signature:** `(concat sequence1 sequence2)`
-
-**description:**
-
-The `concat` function takes two sequences of the same type, and returns a concatenated sequence of the same type, with the resulting sequence\_len = sequence1\_len + sequence2\_len. Applicable sequence types are `(list A)`, `buff`, `string-ascii` and `string-utf8`.
-
-**example:**
-
-```
-(concat (list 1 2) (list 3 4)) ;; Returns (1 2 3 4)
-(concat "hello " "world") ;; Returns "hello world"
-(concat 0x0102 0x0304) ;; Returns 0x01020304
-```
-
-## contract-call?
-
-Introduced in: **Clarity 1**
-
-**input:** `ContractName, PublicFunctionName, Arg0, ...`
-
-**output:** `(response A B)`
-
-**signature:** `(contract-call? .contract-name function-name arg0 arg1 ...)`
-
-**description:**
-
-The `contract-call?` function executes the given public function of the given contract. You _may not_ use this function to call a public function defined in the current contract. If the public function returns _err_, any database changes resulting from calling `contract-call?` are aborted. If the function returns _ok_, database changes occurred.
-
-**example:**
-
-```
-;; instantiate the sample-contracts/tokens.clar contract first
-(as-contract (contract-call? .tokens mint! u19)) ;; Returns (ok u19)
-```
-
-## contract-of
-
-Introduced in: **Clarity 1**
-
-**input:** `Trait`
-
-**output:** `principal`
-
-**signature:** `(contract-of .contract-name)`
-
-**description:**
-
-The `contract-of` function returns the principal of the contract implementing the trait.
-
-**example:**
-
-```
-(use-trait token-a-trait 'SPAXYA5XS51713FDTQ8H94EJ4V579CXMTRNBZKSF.token-a.token-trait)
-(define-public (forward-get-balance (user principal) (contract ))
- (begin
- (ok (contract-of contract)))) ;; returns the principal of the contract implementing
-```
-
-## default-to
-
-Introduced in: **Clarity 1**
-
-**input:** `A, (optional A)`
-
-**output:** `A`
-
-**signature:** `(default-to default-value option-value)`
-
-**description:**
-
-The `default-to` function attempts to 'unpack' the second argument: if the argument is a `(some ...)` option, it returns the inner value of the option. If the second argument is a `(none)` value, `default-to` it returns the value of `default-value`.
-
-**example:**
-
-```
-(define-map names-map { name: (string-ascii 12) } { id: int })
-(map-set names-map { name: "blockstack" } { id: 1337 })
-(default-to 0 (get id (map-get? names-map (tuple (name "blockstack"))))) ;; Returns 1337
-(default-to 0 (get id (map-get? names-map (tuple (name "non-existant"))))) ;; Returns 0
-```
-
-## define-constant
-
-Introduced in: **Clarity 1**
-
-**input:** `MethodSignature, MethodBody`
-
-**output:** `Not Applicable`
-
-**signature:** `(define-constant name expression)`
-
-**description:**
-
-`define-constant` is used to define a private constant value in a smart contract. The expression passed into the definition is evaluated at contract launch, in the order that it is supplied in the contract. This can lead to undefined function or undefined variable errors in the event that a function or variable used in the expression has not been defined before the constant.
-
-Like other kinds of definition statements, `define-constant` may only be used at the top level of a smart contract definition (i.e., you cannot put a define statement in the middle of a function body).
-
-**example:**
-
-```
-(define-constant four (+ 2 2))
-(+ 4 four) ;; Returns 8
-```
-
-## define-data-var
-
-Introduced in: **Clarity 1**
-
-**input:** `VarName, TypeDefinition, Value`
-
-**output:** `Not Applicable`
-
-**signature:** `(define-data-var var-name type value)`
-
-**description:**
-
-`define-data-var` is used to define a new persisted variable for use in a smart contract. Such variable are only modifiable by the current smart contract.
-
-Persisted variable are defined with a type and a value.
-
-Like other kinds of definition statements, `define-data-var` may only be used at the top level of a smart contract definition (i.e., you cannot put a define statement in the middle of a function body).
-
-**example:**
-
-```
-(define-data-var size int 0)
-(define-private (set-size (value int))
- (var-set size value))
-(set-size 1)
-(set-size 2)
-```
-
-## define-fungible-token
-
-Introduced in: **Clarity 1**
-
-**input:** `TokenName, `
-
-**output:** `Not Applicable`
-
-**signature:** `(define-fungible-token token-name )`
-
-**description:**
-
-`define-fungible-token` is used to define a new fungible token class for use in the current contract.
-
-The second argument, if supplied, defines the total supply of the fungible token. This ensures that all calls to the `ft-mint?` function will never be able to create more than `total-supply` tokens. If any such call were to increase the total supply of tokens passed that amount, that invocation of `ft-mint?` will result in a runtime error and abort.
-
-Like other kinds of definition statements, `define-fungible-token` may only be used at the top level of a smart contract definition (i.e., you cannot put a define statement in the middle of a function body).
-
-Tokens defined using `define-fungible-token` may be used in `ft-transfer?`, `ft-mint?`, and `ft-get-balance` functions
-
-**example:**
-
-```
-(define-fungible-token stacks)
-(define-fungible-token limited-supply-stacks u100)
-```
-
-## define-map
-
-Introduced in: **Clarity 1**
-
-**input:** `MapName, TypeDefinition, TypeDefinition`
-
-**output:** `Not Applicable`
-
-**signature:** `(define-map map-name key-type value-type)`
-
-**description:**
-
-`define-map` is used to define a new datamap for use in a smart contract. Such maps are only modifiable by the current smart contract.
-
-Maps are defined with a key type and value type, often these types are tuple types.
-
-Like other kinds of definition statements, `define-map` may only be used at the top level of a smart contract definition (i.e., you cannot put a define statement in the middle of a function body).
-
-**example:**
-
-```
-(define-map squares { x: int } { square: int })
-(define-private (add-entry (x int))
- (map-insert squares { x: 2 } { square: (* x x) }))
-(add-entry 1)
-(add-entry 2)
-(add-entry 3)
-(add-entry 4)
-(add-entry 5)
-```
-
-## define-non-fungible-token
-
-Introduced in: **Clarity 1**
-
-**input:** `AssetName, TypeSignature`
-
-**output:** `Not Applicable`
-
-**signature:** `(define-non-fungible-token asset-name asset-identifier-type)`
-
-**description:**
-
-`define-non-fungible-token` is used to define a new non-fungible token class for use in the current contract. Individual assets are identified by their asset identifier, which must be of the type `asset-identifier-type`. Asset identifiers are _unique_ identifiers.
-
-Like other kinds of definition statements, `define-non-fungible-token` may only be used at the top level of a smart contract definition (i.e., you cannot put a define statement in the middle of a function body).
-
-Assets defined using `define-non-fungible-token` may be used in `nft-transfer?`, `nft-mint?`, and `nft-get-owner?` functions
-
-**example:**
-
-```
-(define-non-fungible-token names (buff 50))
-```
-
-## define-private
-
-Introduced in: **Clarity 1**
-
-**input:** `MethodSignature, MethodBody`
-
-**output:** `Not Applicable`
-
-**signature:** `(define-private (function-name (arg-name-0 arg-type-0) (arg-name-1 arg-type-1) ...) function-body)`
-
-**description:**
-
-`define-private` is used to define _private_ functions for a smart contract. Private functions may not be called from other smart contracts, nor may they be invoked directly by users. Instead, these functions may only be invoked by other functions defined in the same smart contract.
-
-Like other kinds of definition statements, `define-private` may only be used at the top level of a smart contract definition (i.e., you cannot put a define statement in the middle of a function body).
-
-Private functions may return any type.
-
-**example:**
-
-```
-(define-private (max-of (i1 int) (i2 int))
- (if (> i1 i2)
- i1
- i2))
-(max-of 4 6) ;; Returns 6
-```
-
-## define-public
-
-Introduced in: **Clarity 1**
-
-**input:** `MethodSignature, MethodBody`
-
-**output:** `Not Applicable`
-
-**signature:** `(define-public (function-name (arg-name-0 arg-type-0) (arg-name-1 arg-type-1) ...) function-body)`
-
-**description:**
-
-`define-public` is used to define a _public_ function and transaction for a smart contract. Public functions are callable from other smart contracts and may be invoked directly by users by submitting a transaction to the Stacks blockchain.
-
-Like other kinds of definition statements, `define-public` may only be used at the top level of a smart contract definition (i.e., you cannot put a define statement in the middle of a function body).
-
-Public functions _must_ return a ResponseType (using either `ok` or `err`). Any datamap modifications performed by a public function is aborted if the function returns an `err` type. Public functions may be invoked by other contracts via `contract-call?`.
-
-**example:**
-
-```
-(define-public (hello-world (input int))
- (begin
- (print (+ 2 input))
- (ok input)))
-```
-
-## define-read-only
-
-Introduced in: **Clarity 1**
-
-**input:** `MethodSignature, MethodBody`
-
-**output:** `Not Applicable`
-
-**signature:** `(define-read-only (function-name (arg-name-0 arg-type-0) (arg-name-1 arg-type-1) ...) function-body)`
-
-**description:**
-
-`define-read-only` is used to define a _public read-only_ function for a smart contract. Such functions are callable from other smart contracts.
-
-Like other kinds of definition statements, `define-read-only` may only be used at the top level of a smart contract definition (i.e., you cannot put a define statement in the middle of a function body).
-
-Read-only functions may return any type. However, read-only functions may not perform any datamap modifications, or call any functions which perform such modifications. This is enforced both during type checks and during the execution of the function. Public read-only functions may be invoked by other contracts via `contract-call?`.
-
-**example:**
-
-```
-(define-read-only (just-return-one-hundred)
- (* 10 10))
-```
-
-## define-trait
-
-Introduced in: **Clarity 1**
-
-**input:** `VarName, [MethodSignature]`
-
-**output:** `Not Applicable`
-
-**signature:** `(define-trait trait-name ((func1-name (arg1-type arg2-type ...) (return-type))))`
-
-**description:**
-
-`define-trait` is used to define a new trait definition for use in a smart contract. Other contracts can implement a given trait and then have their contract identifier being passed as a function argument in order to be called dynamically with `contract-call?`.
-
-Traits are defined with a name, and a list functions, defined with a name, a list of argument types, and return type.
-
-In Clarity 1, a trait type can be used to specify the type of a function parameter. A parameter with a trait type can be used as the target of a dynamic `contract-call?`. A principal literal (e.g. `ST1PQHQKV0RJXZFY1DGX8MNSNYVE3VGZJSRTPGZGM.foo`) may be passed as a trait parameter if the specified contract implements all of the functions specified by the trait. A trait value (originating from a parameter with trait type) may also be passed as a trait parameter if the types are the same.
-
-Beginning in Clarity 2, a trait can be used in all of the same ways that a built-in type can be used, except that it cannot be stored in a data var or map, since this would inhibit static analysis. This means that a trait type can be embedded in a compound type (e.g. `(optional )` or `(list 4 )`) and a trait value can be bound to a variable in a `let` or `match` expression. In addition to the principal literal and trait value with matching type allowed in Clarity 1, Clarity 2 also supports implicit casting from a compatible trait, meaning that a value of type `trait-a` may be passed to a parameter with type `trait-b` if `trait-a` includes all of the requirements of `trait-b` (and optionally additional functions).
-
-Like other kinds of definition statements, `define-trait` may only be used at the top level of a smart contract definition (i.e., you cannot put a define statement in the middle of a function body).
-
-**example:**
-
-```
-(define-trait token-trait
- ((transfer? (principal principal uint) (response uint uint))
- (get-balance (principal) (response uint uint))))
-```
-
-## element-at
-
-Introduced in: **Clarity 1**
-
-**input:** `sequence_A, uint`
-
-**output:** `(optional A)`
-
-**signature:** `(element-at? sequence index)`
-
-**description:**
-
-The `element-at?` function returns the element at `index` in the provided sequence. Applicable sequence types are `(list A)`, `buff`, `string-ascii` and `string-utf8`, for which the corresponding element types are, respectively, `A`, `(buff 1)`, `(string-ascii 1)` and `(string-utf8 1)`. In Clarity1, `element-at` must be used (without the `?`). The `?` is added in Clarity2 for consistency -- built-ins that return responses or optionals end in `?`. The Clarity1 spelling is left as an alias in Clarity2 for backwards compatibility.
-
-**example:**
-
-```
-(element-at? "blockstack" u5) ;; Returns (some "s")
-(element-at? (list 1 2 3 4 5) u5) ;; Returns none
-(element-at? (list 1 2 3 4 5) (+ u1 u2)) ;; Returns (some 4)
-(element-at? "abcd" u1) ;; Returns (some "b")
-(element-at? 0xfb01 u1) ;; Returns (some 0x01)
-```
-
-## element-at?
-
-Introduced in: **Clarity 2**
-
-**input:** `sequence_A, uint`
-
-**output:** `(optional A)`
-
-**signature:** `(element-at? sequence index)`
-
-**description:**
-
-The `element-at?` function returns the element at `index` in the provided sequence. Applicable sequence types are `(list A)`, `buff`, `string-ascii` and `string-utf8`, for which the corresponding element types are, respectively, `A`, `(buff 1)`, `(string-ascii 1)` and `(string-utf8 1)`. In Clarity1, `element-at` must be used (without the `?`). The `?` is added in Clarity2 for consistency -- built-ins that return responses or optionals end in `?`. The Clarity1 spelling is left as an alias in Clarity2 for backwards compatibility.
-
-**example:**
-
-```
-(element-at? "blockstack" u5) ;; Returns (some "s")
-(element-at? (list 1 2 3 4 5) u5) ;; Returns none
-(element-at? (list 1 2 3 4 5) (+ u1 u2)) ;; Returns (some 4)
-(element-at? "abcd" u1) ;; Returns (some "b")
-(element-at? 0xfb01 u1) ;; Returns (some 0x01)
-```
-
-## err
-
-Introduced in: **Clarity 1**
-
-**input:** `A`
-
-**output:** `(response A B)`
-
-**signature:** `(err value)`
-
-**description:**
-
-The `err` function constructs a response type from the input value. Use `err` for creating return values in public functions. An _err_ value indicates that any database changes during the processing of the function should be rolled back.
-
-**example:**
-
-```
-(err true) ;; Returns (err true)
-```
-
-## filter
-
-Introduced in: **Clarity 1**
-
-**input:** `Function(A) -> bool, sequence_A`
-
-**output:** `sequence_A`
-
-**signature:** `(filter func sequence)`
-
-**description:**
-
-The `filter` function applies the input function `func` to each element of the input sequence, and returns the same sequence with any elements removed for which `func` returned `false`. Applicable sequence types are `(list A)`, `buff`, `string-ascii` and `string-utf8`, for which the corresponding element types are, respectively, `A`, `(buff 1)`, `(string-ascii 1)` and `(string-utf8 1)`. The `func` argument must be a literal function name.
-
-**example:**
-
-```
-(filter not (list true false true false)) ;; Returns (false false)
-(define-private (is-a (char (string-utf8 1)))
- (is-eq char u"a"))
-(filter is-a u"acabd") ;; Returns u"aa"
-(define-private (is-zero (char (buff 1)))
- (is-eq char 0x00))
-(filter is-zero 0x00010002) ;; Returns 0x0000
-```
-
-## fold
-
-Introduced in: **Clarity 1**
-
-**input:** `Function(A, B) -> B, sequence_A, B`
-
-**output:** `B`
-
-**signature:** `(fold func sequence_A initial_B)`
-
-**description:**
-
-The `fold` function condenses `sequence_A` into a value of type `B` by recursively applies the function `func` to each element of the input sequence _and_ the output of a previous application of `func`.
-
-`fold` uses `initial_B` in the initial application of `func`, along with the first element of `sequence_A`. The resulting value of type `B` is used for the next application of `func`, along with the next element of `sequence_A` and so on. `fold` returns the last value of type `B` returned by these successive applications `func`.
-
-Applicable sequence types are `(list A)`, `buff`, `string-ascii` and `string-utf8`, for which the corresponding element types are, respectively, `A`, `(buff 1)`, `(string-ascii 1)` and `(string-utf8 1)`. The `func` argument must be a literal function name.
-
-**example:**
-
-```
-(fold * (list 2 2 2) 1) ;; Returns 8
-(fold * (list 2 2 2) 0) ;; Returns 0
-;; calculates (- 11 (- 7 (- 3 2)))
-(fold - (list 3 7 11) 2) ;; Returns 5
-(define-private (concat-string (a (string-ascii 20)) (b (string-ascii 20)))
- (unwrap-panic (as-max-len? (concat a b) u20)))
-(fold concat-string "cdef" "ab") ;; Returns "fedcab"
-(fold concat-string (list "cd" "ef") "ab") ;; Returns "efcdab"
-(define-private (concat-buff (a (buff 20)) (b (buff 20)))
- (unwrap-panic (as-max-len? (concat a b) u20)))
-(fold concat-buff 0x03040506 0x0102) ;; Returns 0x060504030102
-```
-
-## from-consensus-buff?
-
-Introduced in: **Clarity 2**
-
-**input:** `type-signature(t), buff`
-
-**output:** `(optional t)`
-
-**signature:** `(from-consensus-buff? type-signature buffer)`
-
-**description:**
-
-`from-consensus-buff?` is a special function that will deserialize a buffer into a Clarity value, using the SIP-005 serialization of the Clarity value. The type that `from-consensus-buff?` tries to deserialize into is provided by the first parameter to the function. If it fails to deserialize the type, the method returns `none`.
-
-**example:**
-
-```
-(from-consensus-buff? int 0x0000000000000000000000000000000001) ;; Returns (some 1)
-(from-consensus-buff? uint 0x0000000000000000000000000000000001) ;; Returns none
-(from-consensus-buff? uint 0x0100000000000000000000000000000001) ;; Returns (some u1)
-(from-consensus-buff? bool 0x0000000000000000000000000000000001) ;; Returns none
-(from-consensus-buff? bool 0x03) ;; Returns (some true)
-(from-consensus-buff? bool 0x04) ;; Returns (some false)
-(from-consensus-buff? principal 0x051fa46ff88886c2ef9762d970b4d2c63678835bd39d) ;; Returns (some SZ2J6ZY48GV1EZ5V2V5RB9MP66SW86PYKKQ9H6DPR)
-(from-consensus-buff? { abc: int, def: int } 0x0c00000002036162630000000000000000000000000000000003036465660000000000000000000000000000000004) ;; Returns (some (tuple (abc 3) (def 4)))
-```
-
-## ft-burn?
-
-Introduced in: **Clarity 1**
-
-**input:** `TokenName, uint, principal`
-
-**output:** `(response bool uint)`
-
-**signature:** `(ft-burn? token-name amount sender)`
-
-**description:**
-
-`ft-burn?` is used to decrease the token balance for the `sender` principal for a token type defined using `define-fungible-token`. The decreased token balance is _not_ transferred to another principal, but rather destroyed, reducing the circulating supply.
-
-On a successful burn, it returns `(ok true)`. In the event of an unsuccessful burn it returns one of the following error codes:
-
-`(err u1)` -- `sender` does not have enough balance to burn this amount or the amount specified is not positive
-
-**example:**
-
-```
-(define-fungible-token stackaroo)
-(ft-mint? stackaroo u100 'SPAXYA5XS51713FDTQ8H94EJ4V579CXMTRNBZKSF) ;; Returns (ok true)
-(ft-burn? stackaroo u50 'SPAXYA5XS51713FDTQ8H94EJ4V579CXMTRNBZKSF) ;; Returns (ok true)
-```
-
-## ft-get-balance
-
-Introduced in: **Clarity 1**
-
-**input:** `TokenName, principal`
-
-**output:** `uint`
-
-**signature:** `(ft-get-balance token-name principal)`
-
-**description:**
-
-`ft-get-balance` returns `token-name` balance of the principal `principal`. The token type must have been defined using `define-fungible-token`.
-
-**example:**
-
-```
-(define-fungible-token stackaroo)
-(ft-mint? stackaroo u100 'SZ2J6ZY48GV1EZ5V2V5RB9MP66SW86PYKKQ9H6DPR)
-(ft-get-balance stackaroo 'SZ2J6ZY48GV1EZ5V2V5RB9MP66SW86PYKKQ9H6DPR) ;; Returns u100
-```
-
-## ft-get-supply
-
-Introduced in: **Clarity 1**
-
-**input:** `TokenName`
-
-**output:** `uint`
-
-**signature:** `(ft-get-supply token-name)`
-
-**description:**
-
-`ft-get-balance` returns `token-name` circulating supply. The token type must have been defined using `define-fungible-token`.
-
-**example:**
-
-```
-(define-fungible-token stackaroo)
-(ft-mint? stackaroo u100 'SZ2J6ZY48GV1EZ5V2V5RB9MP66SW86PYKKQ9H6DPR)
-(ft-get-supply stackaroo) ;; Returns u100
-```
-
-## ft-mint?
-
-Introduced in: **Clarity 1**
-
-**input:** `TokenName, uint, principal`
-
-**output:** `(response bool uint)`
-
-**signature:** `(ft-mint? token-name amount recipient)`
-
-**description:**
-
-`ft-mint?` is used to increase the token balance for the `recipient` principal for a token type defined using `define-fungible-token`. The increased token balance is _not_ transfered from another principal, but rather minted.
-
-If a non-positive amount is provided to mint, this function returns `(err 1)`. Otherwise, on successfully mint, it returns `(ok true)`.
-
-**example:**
-
-```
-(define-fungible-token stackaroo)
-(ft-mint? stackaroo u100 'SPAXYA5XS51713FDTQ8H94EJ4V579CXMTRNBZKSF) ;; Returns (ok true)
-```
-
-## ft-transfer?
-
-Introduced in: **Clarity 1**
-
-**input:** `TokenName, uint, principal, principal`
-
-**output:** `(response bool uint)`
-
-**signature:** `(ft-transfer? token-name amount sender recipient)`
-
-**description:**
-
-`ft-transfer?` is used to increase the token balance for the `recipient` principal for a token type defined using `define-fungible-token` by debiting the `sender` principal. In contrast to `stx-transfer?`, any user can transfer the assets. When used, relevant guards need to be added.
-
-This function returns (ok true) if the transfer is successful. In the event of an unsuccessful transfer it returns one of the following error codes:
-
-`(err u1)` -- `sender` does not have enough balance to transfer `(err u2)` -- `sender` and `recipient` are the same principal `(err u3)` -- amount to send is non-positive
-
-**example:**
-
-```
-(define-fungible-token stackaroo)
-(ft-mint? stackaroo u100 'SZ2J6ZY48GV1EZ5V2V5RB9MP66SW86PYKKQ9H6DPR)
-(ft-transfer? stackaroo u50 'SZ2J6ZY48GV1EZ5V2V5RB9MP66SW86PYKKQ9H6DPR 'SPAXYA5XS51713FDTQ8H94EJ4V579CXMTRNBZKSF) ;; Returns (ok true)
-(ft-transfer? stackaroo u60 'SZ2J6ZY48GV1EZ5V2V5RB9MP66SW86PYKKQ9H6DPR 'SPAXYA5XS51713FDTQ8H94EJ4V579CXMTRNBZKSF) ;; Returns (err u1)
-```
-
-## get
-
-Introduced in: **Clarity 1**
-
-**input:** `KeyName, (tuple) | (optional (tuple))`
-
-**output:** `A`
-
-**signature:** `(get key-name tuple)`
-
-**description:**
-
-The `get` function fetches the value associated with a given key from the supplied typed tuple. If an `Optional` value is supplied as the inputted tuple, `get` returns an `Optional` type of the specified key in the tuple. If the supplied option is a `(none)` option, get returns `(none)`.
-
-**example:**
-
-```
-(define-map names-map { name: (string-ascii 12) } { id: int })
-(map-insert names-map { name: "blockstack" } { id: 1337 }) ;; Returns true
-(get id (tuple (name "blockstack") (id 1337))) ;; Returns 1337
-(get id (map-get? names-map (tuple (name "blockstack")))) ;; Returns (some 1337)
-(get id (map-get? names-map (tuple (name "non-existent")))) ;; Returns none
-```
-
-## get-block-info?
-
-Introduced in: **Clarity 1**
-
-**input:** `BlockInfoPropertyName, uint`
-
-**output:** `(optional buff) | (optional uint)`
-
-**signature:** `(get-block-info? prop-name block-height)`
-
-**description:**
-In Clarity 3, `get-block-info?` is removed. In its place, `get-stacks-block-info?` can be used to retrieve information about a Stacks block and `get-tenure-info?` can be used to get information pertaining to the tenure. The `get-block-info?` function fetches data for a block of the given *Stacks* block height. The value and type returned are determined by the specified `BlockInfoPropertyName`. If the provided `block-height` does not correspond to an existing block prior to the current block, the function returns `none`. The currently available property names are as follows:
-
-- `burnchain-header-hash`: This property returns a `(buff 32)` value containing the header hash of the burnchain (Bitcoin) block that selected the Stacks block at the given Stacks chain height.
-
-- `id-header-hash`: This property returns a `(buff 32)` value containing the _index block hash_ of a Stacks block. This hash is globally unique, and is derived from the block hash and the history of accepted PoX operations. This is also the block hash value you would pass into `(at-block)`.
-
-- `header-hash`: This property returns a `(buff 32)` value containing the header hash of a Stacks block, given a Stacks chain height. **WARNING* this hash is not guaranteed to be globally unique, since the same Stacks block can be mined in different PoX forks. If you need global uniqueness, you should use `id-header-hash`.
-
-- `miner-address`: This property returns a `principal` value corresponding to the miner of the given block. **WARNING** In Stacks 2.1, this is not guaranteed to be the same `principal` that received the block reward, since Stacks 2.1 supports coinbase transactions that pay the reward to a contract address. This is merely the address of the `principal` that produced the block.
-
-- `time`: This property returns a `uint` value of the block header time field. This is a Unix epoch timestamp in seconds which roughly corresponds to when the block was mined. This timestamp comes from the burnchain block. **Note**: this does not increase monotonically with each block and block times are accurate only to within two hours. See [BIP113](https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki) for more information. For blocks mined after epoch 3.0, all Stacks blocks in one tenure will share the same timestamp. To get the Stacks block time for a block in epoch 3.0+, use `get-stacks-block-info?`.
-
-- `vrf-seed`: This property returns a `(buff 32)` value of the VRF seed for the corresponding block.
-
-- `block-reward`: This property returns a `uint` value for the total block reward of the indicated Stacks block. This value is only available once the reward for the block matures. That is, the latest `block-reward` value available is at least 101 Stacks blocks in the past (on mainnet). The reward includes the coinbase, the anchored block's transaction fees, and the shares of the confirmed and produced microblock transaction fees earned by this block's miner. Note that this value may be smaller than the Stacks coinbase at this height, because the miner may have been punished with a valid `PoisonMicroblock` transaction in the event that the miner published two or more microblock stream forks. Added in Clarity 2.
-
-- `miner-spend-total`: This property returns a `uint` value for the total number of burnchain tokens (i.e. satoshis) spent by all miners trying to win this block. Added in Clarity 2.
-
-- `miner-spend-winner`: This property returns a `uint` value for the number of burnchain tokens (i.e. satoshis) spent by the winning miner for this Stacks block. Note that this value is less than or equal to the value for `miner-spend-total` at the same block height. Added in Clarity 2.
-
-**example:**
-
-```
-(get-block-info? time u0) ;; Returns (some u1557860301)
-(get-block-info? header-hash u0) ;; Returns (some 0x374708fff7719dd5979ec875d56cd2286f6d3cf7ec317a3b25632aab28ec37bb)
-(get-block-info? vrf-seed u0) ;; Returns (some 0xf490de2920c8a35fabeb13208852aa28c76f9be9b03a4dd2b3c075f7a26923b4)
-```
-
-## get-burn-block-info?
-
-Introduced in: **Clarity 2**
-
-**input:** `BurnBlockInfoPropertyName, uint`
-
-**output:** `(optional buff) | (optional (tuple (addrs (list 2 (tuple (hashbytes (buff 32)) (version (buff 1))))) (payout uint)))`
-
-**signature:** `(get-burn-block-info? prop-name block-height)`
-
-**description:**
-
-The `get-burn-block-info?` function fetches data for a block of the given _burnchain_ block height. The value and type returned are determined by the specified `BlockInfoPropertyName`. Valid values for `block-height` only include heights between the burnchain height at the time the Stacks chain was launched, and the last-processed burnchain block. If the `block-height` argument falls outside of this range, then `none` shall be returned.
-
-The following `BlockInfoPropertyName` values are defined:
-
-* The `header-hash` property returns a 32-byte buffer representing the header hash of the burnchain block at burnchain height `block-height`.
-* The `pox-addrs` property returns a tuple with two items: a list of up to two PoX addresses that received a PoX payout at that block height, and the amount of burnchain tokens paid to each address (note that per the blockchain consensus rules, each PoX payout will be the same for each address in the block-commit transaction). The list will include burn addresses -- that is, the unspendable addresses that miners pay to when there are no PoX addresses left to be paid. During the prepare phase, there will be exactly one burn address reported. During the reward phase, up to two burn addresses may be reported in the event that some PoX reward slots are not claimed.
-
-The `addrs` list contains the same PoX address values passed into the PoX smart contract:
-
-* They each have type signature `(tuple (hashbytes (buff 32)) (version (buff 1)))`
-* The `version` field can be any of the following:
- * `0x00` means this is a p2pkh address, and `hashbytes` is the 20-byte hash160 of a single public key
- * `0x01` means this is a p2sh address, and `hashbytes` is the 20-byte hash160 of a redeemScript script
- * `0x02` means this is a p2wpkh-p2sh address, and `hashbytes` is the 20-byte hash160 of a p2wpkh witness script
- * `0x03` means this is a p2wsh-p2sh address, and `hashbytes` is the 20-byte hash160 of a p2wsh witness script
- * `0x04` means this is a p2wpkh address, and `hashbytes` is the 20-byte hash160 of the witness script
- * `0x05` means this is a p2wsh address, and `hashbytes` is the 32-byte sha256 of the witness script
- * `0x06` means this is a p2tr address, and `hashbytes` is the 32-byte sha256 of the witness script
-
-**example:**
-
-```
-(get-burn-block-info? header-hash u677050) ;; Returns (some 0xe67141016c88a7f1203eca0b4312f2ed141531f59303a1c267d7d83ab6b977d8)
-(get-burn-block-info? pox-addrs u677050) ;; Returns (some (tuple (addrs ( (tuple (hashbytes 0x395f3643cea07ec4eec73b4d9a973dcce56b9bf1) (version 0x00)) (tuple (hashbytes 0x7c6775e20e3e938d2d7e9d79ac310108ba501ddb) (version 0x01)))) (payout u123)))
-```
-
-## get-stacks-block-info?
-
-Introduced in: **Clarity 3**
-
-**input:** `StacksBlockInfoPropertyName, uint`
-
-**output:** `(optional buff), (optional uint)`
-
-**signature:** `(get-stacks-block-info? prop-name stacks-block-height)`
-
-**description:**
-
-The `get-stacks-block-info?` function fetches data for a block of the given *Stacks* block height. The value and type returned are determined by the specified `StacksBlockInfoPropertyName`. If the provided `stacks-block-height` does not correspond to an existing block prior to the current block, the function returns `none`. The currently available property names are as follows:
-
-- `id-header-hash`: This property returns a `(buff 32)` value containing the _index block hash_ of a Stacks block. This hash is globally unique, and is derived from the block hash and the history of accepted PoX operations. This is also the block hash value you would pass into `(at-block)`.
-- `header-hash`: This property returns a `(buff 32)` value containing the header hash of a Stacks block, given a Stacks chain height. **WARNING** this hash is not guaranteed to be globally unique, since the same Stacks block can be mined in different PoX forks. If you need global uniqueness, you should use `id-header-hash`.
-- `time`: This property returns a `uint` value of the block header time field. This is a Unix epoch timestamp in seconds which roughly corresponds to when the block was mined. For a block mined before epoch 3.0, this timestamp comes from the burnchain block. **Note**: this does not increase monotonically with each block and block times are accurate only to within two hours. See [BIP113](https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki) for more information.
-For a block mined after epoch 3.0, this timestamp comes from the Stacks block header. **Note**: this is the time, according to the miner, when the mining of this block started, but is not guaranteed to be accurate. This time will be validated by the signers to be:
-- Greater than the timestamp of the previous block
-- At most 15 seconds into the future (according to their own local clocks)
-
-**example:**
-```
-(get-stacks-block-info? time u0) ;; Returns (some u1557860301)
-(get-stacks-block-info? header-hash u0) ;; Returns (some 0x374708fff7719dd5979ec875d56cd2286f6d3cf7ec317a3b25632aab28ec37bb)
-```
-
-## get-tenure-info?
-
-Introduced in: **Clarity 3**
-
-**input:** `TenureInfoPropertyName, uint`
-
-**output:** `(optional buff) | (optional uint)`
-
-**signature:** `(get-tenure-info? prop-name stacks-block-height)`
-
-**description:**
-
-The `get-tenure-info?` function fetches data for the tenure at the given block height. The value and type returned are determined by the specified `TenureInfoPropertyName`. If the provided `stacks-block-height` does not correspond to an existing block prior to the current block, the function returns `none`. The currently available property names are as follows:
-
-- `burnchain-header-hash`: This property returns a `(buff 32)` value containing the header hash of the burnchain (Bitcoin) block that selected the tenure at the given height.
-- `miner-address`: This property returns a `principal` value corresponding to the miner of the given tenure. **WARNING** This is not guaranteed to be the same `principal` that received the block reward, since Stacks 2.1+ supports coinbase transactions that pay the reward to a contract address. This is merely the address of the `principal` that produced the tenure.
-- `time`: This property returns a `uint` Unix epoch timestamp in seconds which roughly corresponds to when the tenure was started. This timestamp comes from the burnchain block. **Note**: this does not increase monotonically with each tenure and tenure times are accurate only to within two hours. See [BIP113](https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki) for more information.
-- `vrf-seed`: This property returns a `(buff 32)` value of the VRF seed for the corresponding tenure.
-- `block-reward`: This property returns a `uint` value for the total block reward of the indicated tenure. This value is only available once the reward for the tenure matures. That is, the latest `block-reward` value available is at least 101 Stacks blocks in the past (on mainnet). The reward includes the coinbase, the anchored tenure's transaction fees, and the shares of the confirmed and produced microblock transaction fees earned by this block's miner. Note that this value may be smaller than the Stacks coinbase at this height, because the miner may have been punished with a valid `PoisonMicroblock` transaction in the event that the miner published two or more microblock stream forks.
-- `miner-spend-total`: This property returns a `uint` value for the total number of burnchain tokens (i.e. satoshis) spent by all miners trying to win this tenure.
-- `miner-spend-winner`: This property returns a `uint` value for the number of burnchain tokens (i.e. satoshis) spent by the winning miner for this tennure. Note that this value is less than or equal to the value for `miner-spend-total` at the same tenure height.
-
-**example:**
-```
-(get-tenure-info? time u0) ;; Returns (some u1557860301)
-(get-tenure-info? vrf-seed u0) ;; Returns (some 0xf490de2920c8a35fabeb13208852aa28c76f9be9b03a4dd2b3c075f7a26923b4)
-```
-
-## hash160
-
-Introduced in: **Clarity 1**
-
-**input:** `buff|uint|int`
-
-**output:** `(buff 20)`
-
-**signature:** `(hash160 value)`
-
-**description:**
-
-The `hash160` function computes `RIPEMD160(SHA256(x))` of the inputted value. If an integer (128 bit) is supplied the hash is computed over the little-endian representation of the integer.
-
-**example:**
-
-```
-(hash160 0) ;; Returns 0xe4352f72356db555721651aa612e00379167b30f
-```
-
-## if
-
-Introduced in: **Clarity 1**
-
-**input:** `bool, A, A`
-
-**output:** `A`
-
-**signature:** `(if bool1 expr1 expr2)`
-
-**description:**
-
-The `if` function admits a boolean argument and two expressions which must return the same type. In the case that the boolean input is `true`, the `if` function evaluates and returns `expr1`. If the boolean input is `false`, the `if` function evaluates and returns `expr2`.
-
-**example:**
-
-```
-(if true 1 2) ;; Returns 1
-(if (> 1 2) 1 2) ;; Returns 2
-```
-
-## impl-trait
-
-Introduced in: **Clarity 1**
-
-**input:** `TraitIdentifier`
-
-**output:** `Not Applicable`
-
-**signature:** `(impl-trait trait-identifier)`
-
-**description:**
-
-`impl-trait` can be use for asserting that a contract is fully implementing a given trait. Additional checks are being performed when the contract is being published, rejecting the deployment if the contract is violating the trait specification.
-
-Trait identifiers can either be using the sugared syntax (.token-a.token-trait), or be fully qualified ('SPAXYA5XS51713FDTQ8H94EJ4V579CXMTRNBZKSF.token-a.token-trait).
-
-Like other kinds of definition statements, `impl-trait` may only be used at the top level of a smart contract definition (i.e., you cannot put such a statement in the middle of a function body).
-
-**example:**
-
-```
-(impl-trait 'SPAXYA5XS51713FDTQ8H94EJ4V579CXMTRNBZKSF.token-a.token-trait)
-(define-public (get-balance (account principal))
- (ok u0))
-(define-public (transfer? (from principal) (to principal) (amount uint))
- (ok u0))
-```
-
-## index-of
-
-Introduced in: **Clarity 1**
-
-**input:** `sequence_A, A`
-
-**output:** `(optional uint)`
-
-**signature:** `(index-of? sequence item)`
-
-**description:**
-
-The `index-of?` function returns the first index at which `item` can be found, using `is-eq` checks, in the provided sequence. Applicable sequence types are `(list A)`, `buff`, `string-ascii` and `string-utf8`, for which the corresponding element types are, respectively, `A`, `(buff 1)`, `(string-ascii 1)` and `(string-utf8 1)`. If the target item is not found in the sequence (or if an empty string or buffer is supplied), this function returns `none`. In Clarity1, `index-of` must be used (without the `?`). The `?` is added in Clarity2 for consistency -- built-ins that return responses or optionals end in `?`. The Clarity1 spelling is left as an alias in Clarity2 for backwards compatibility.
-
-**example:**
-
-```
-(index-of? "blockstack" "b") ;; Returns (some u0)
-(index-of? "blockstack" "k") ;; Returns (some u4)
-(index-of? "blockstack" "") ;; Returns none
-(index-of? (list 1 2 3 4 5) 6) ;; Returns none
-(index-of? 0xfb01 0x01) ;; Returns (some u1)
-```
-
-## index-of?
-
-Introduced in: **Clarity 2**
-
-**input:** `sequence_A, A`
-
-**output:** `(optional uint)`
-
-**signature:** `(index-of? sequence item)`
-
-**description:**
-
-The `index-of?` function returns the first index at which `item` can be found, using `is-eq` checks, in the provided sequence. Applicable sequence types are `(list A)`, `buff`, `string-ascii` and `string-utf8`, for which the corresponding element types are, respectively, `A`, `(buff 1)`, `(string-ascii 1)` and `(string-utf8 1)`. If the target item is not found in the sequence (or if an empty string or buffer is supplied), this function returns `none`. In Clarity1, `index-of` must be used (without the `?`). The `?` is added in Clarity2 for consistency -- built-ins that return responses or optionals end in `?`. The Clarity1 spelling is left as an alias in Clarity2 for backwards compatibility.
-
-**example:**
-
-```
-(index-of? "blockstack" "b") ;; Returns (some u0)
-(index-of? "blockstack" "k") ;; Returns (some u4)
-(index-of? "blockstack" "") ;; Returns none
-(index-of? (list 1 2 3 4 5) 6) ;; Returns none
-(index-of? 0xfb01 0x01) ;; Returns (some u1)
-```
-
-## int-to-ascii
-
-Introduced in: **Clarity 2**
-
-**input:** `int | uint`
-
-**output:** `(string-ascii 40)`
-
-**signature:** `(int-to-ascii (int|uint))`
-
-**description:**
-
-Converts an integer, either `int` or `uint`, to a `string-ascii` string-value representation.
-
-Note: This function is only available starting with Stacks 2.1.
-
-**example:**
-
-```
-(int-to-ascii 1) ;; Returns "1"
-(int-to-ascii u1) ;; Returns "1"
-(int-to-ascii -1) ;; Returns "-1"
-```
-
-## int-to-utf8
-
-Introduced in: **Clarity 2**
-
-**input:** `int | uint`
-
-**output:** `(string-utf8 40)`
-
-**signature:** `(int-to-utf8 (int|uint))`
-
-**description:**
-
-Converts an integer, either `int` or `uint`, to a `string-utf8` string-value representation.
-
-Note: This function is only available starting with Stacks 2.1.
-
-**example:**
-
-```
-(int-to-utf8 1) ;; Returns u"1"
-(int-to-utf8 u1) ;; Returns u"1"
-(int-to-utf8 -1) ;; Returns u"-1"
-```
-
-## is-eq
-
-Introduced in: **Clarity 1**
-
-**input:** `A, A, ...`
-
-**output:** `bool`
-
-**signature:** `(is-eq v1 v2...)`
-
-**description:**
-
-Compares the inputted values, returning `true` if they are all equal. Note that _unlike_ the `(and ...)` function, `(is-eq ...)` will _not_ short-circuit. All values supplied to is-eq _must_ be the same type.
-
-**example:**
-
-```
-(is-eq 1 1) ;; Returns true
-(is-eq true false) ;; Returns false
-(is-eq "abc" 234 234) ;; Throws type error
-(is-eq "abc" "abc") ;; Returns true
-(is-eq 0x0102 0x0102) ;; Returns true
-```
-
-## is-err
-
-Introduced in: **Clarity 1**
-
-**input:** `(response A B)`
-
-**output:** `bool`
-
-**signature:** `(is-err value)`
-
-**description:**
-
-`is-err` tests a supplied response value, returning `true` if the response was an `err`, and `false` if it was an `ok`.
-
-**example:**
-
-```
-(is-err (ok 1)) ;; Returns false
-(is-err (err 1)) ;; Returns true
-```
-
-## is-none
-
-Introduced in: **Clarity 1**
-
-**input:** `(optional A)`
-
-**output:** `bool`
-
-**signature:** `(is-none value)`
-
-**description:**
-
-`is-none` tests a supplied option value, returning `true` if the option value is `(none)`, and `false` if it is a `(some ...)`.
-
-**example:**
-
-```
-(define-map names-map { name: (string-ascii 12) } { id: int })
-(map-set names-map { name: "blockstack" } { id: 1337 })
-(is-none (get id (map-get? names-map { name: "blockstack" }))) ;; Returns false
-(is-none (get id (map-get? names-map { name: "non-existant" }))) ;; Returns true
-```
-
-## is-ok
-
-Introduced in: **Clarity 1**
-
-**input:** `(response A B)`
-
-**output:** `bool`
-
-**signature:** `(is-ok value)`
-
-**description:**
-
-`is-ok` tests a supplied response value, returning `true` if the response was `ok`, and `false` if it was an `err`.
-
-**example:**
-
-```
-(is-ok (ok 1)) ;; Returns true
-(is-ok (err 1)) ;; Returns false
-```
-
-## is-some
-
-Introduced in: **Clarity 1**
-
-**input:** `(optional A)`
-
-**output:** `bool`
-
-**signature:** `(is-some value)`
-
-**description:**
-
-`is-some` tests a supplied option value, returning `true` if the option value is `(some ...)`, and `false` if it is a `none`.
-
-**example:**
-
-```
-(define-map names-map { name: (string-ascii 12) } { id: int })
-(map-set names-map { name: "blockstack" } { id: 1337 })
-(is-some (get id (map-get? names-map { name: "blockstack" }))) ;; Returns true
-(is-some (get id (map-get? names-map { name: "non-existant" }))) ;; Returns false
-```
-
-## is-standard
-
-Introduced in: **Clarity 2**
-
-**input:** `principal`
-
-**output:** `bool`
-
-**signature:** `(is-standard standard-or-contract-principal)`
-
-**description:**
-
-Tests whether `standard-or-contract-principal` _matches_ the current network type, and therefore represents a principal that can spend tokens on the current network type. That is, the network is either of type `mainnet`, or `testnet`. Only `SPxxxx` and `SMxxxx` _c32check form_ addresses can spend tokens on a mainnet, whereas only `STxxxx` and `SNxxxx` _c32check forms_ addresses can spend tokens on a testnet. All addresses can _receive_ tokens, but only principal _c32check form_ addresses that match the network type can _spend_ tokens on the network. This method will return `true` if and only if the principal matches the network type, and false otherwise.
-
-Note: This function is only available starting with Stacks 2.1.
-
-**example:**
-
-```
-(is-standard 'STB44HYPYAT2BB2QE513NSP81HTMYWBJP02HPGK6) ;; returns true on testnet and false on mainnet
-(is-standard 'STB44HYPYAT2BB2QE513NSP81HTMYWBJP02HPGK6.foo) ;; returns true on testnet and false on mainnet
-(is-standard 'SP3X6QWWETNBZWGBK6DRGTR1KX50S74D3433WDGJY) ;; returns true on mainnet and false on testnet
-(is-standard 'SP3X6QWWETNBZWGBK6DRGTR1KX50S74D3433WDGJY.foo) ;; returns true on mainnet and false on testnet
-(is-standard 'SZ2J6ZY48GV1EZ5V2V5RB9MP66SW86PYKKQ9H6DPR) ;; returns false on both mainnet and testnet
-```
-
-## keccak256
-
-Introduced in: **Clarity 1**
-
-**input:** `buff|uint|int`
-
-**output:** `(buff 32)`
-
-**signature:** `(keccak256 value)`
-
-**description:**
-
-The `keccak256` function computes `KECCAK256(value)` of the inputted value. Note that this differs from the `NIST SHA-3` (that is, FIPS 202) standard. If an integer (128 bit) is supplied the hash is computed over the little-endian representation of the integer.
-
-**example:**
-
-```
-(keccak256 0) ;; Returns 0xf490de2920c8a35fabeb13208852aa28c76f9be9b03a4dd2b3c075f7a26923b4
-```
-
-## len
-
-Introduced in: **Clarity 1**
-
-**input:** `sequence_A`
-
-**output:** `uint`
-
-**signature:** `(len sequence)`
-
-**description:**
-
-The `len` function returns the length of a given sequence. Applicable sequence types are `(list A)`, `buff`, `string-ascii` and `string-utf8`.
-
-**example:**
-
-```
-(len "blockstack") ;; Returns u10
-(len (list 1 2 3 4 5)) ;; Returns u5
-(len 0x010203) ;; Returns u3
-```
-
-## let
-
-Introduced in: **Clarity 1**
-
-**input:** `((name1 AnyType) (name2 AnyType) ...), AnyType, ... A`
-
-**output:** `A`
-
-**signature:** `(let ((name1 expr1) (name2 expr2) ...) expr-body1 expr-body2 ... expr-body-last)`
-
-**description:**
-
-The `let` function accepts a list of `variable name` and `expression` pairs, evaluating each expression and _binding_ it to the corresponding variable name. `let` bindings are sequential: when a `let` binding is evaluated, it may refer to prior binding. The _context_ created by this set of bindings is used for evaluating its body expressions. The let expression returns the value of the last such body expression. Note: intermediary statements returning a response type must be checked
-
-**example:**
-
-```
-(let
- ( (a 2) (b (+ 5 6 7)))
- (print a)
- (print b)
- (+ a b)) ;; Returns 20
-(let
- ( (a 5) (c (+ a 1)) (d (+ c 1)) (b (+ a c d)))
- (print a)
- (print b)
- (+ a b)) ;; Returns 23
-```
-
-## list
-
-Introduced in: **Clarity 1**
-
-**input:** `A, ...`
-
-**output:** `(list A)`
-
-**signature:** `(list expr1 expr2 expr3 ...)`
-
-**description:**
-
-The `list` function constructs a list composed of the inputted values. Each supplied value must be of the same type.
-
-**example:**
-
-```
-(list (+ 1 2) 4 5) ;; Returns (3 4 5)
-```
-
-## log2
-
-Introduced in: **Clarity 1**
-
-**input:** `int | uint`
-
-**output:** `int | uint`
-
-**signature:** `(log2 n)`
-
-**description:**
-
-Returns the power to which the number 2 must be raised to to obtain the value `n`, rounded down to the nearest integer. Fails on a negative numbers.
-
-**example:**
-
-```
-(log2 u8) ;; Returns u3
-(log2 8) ;; Returns 3
-(log2 u1) ;; Returns u0
-(log2 1000) ;; Returns 9
-```
-
-## map
-
-Introduced in: **Clarity 1**
-
-**input:** `Function(A, B, ..., N) -> X, sequence_A, sequence_B, ..., sequence_N`
-
-**output:** `(list X)`
-
-**signature:** `(map func sequence_A sequence_B ... sequence_N)`
-
-**description:**
-
-The `map` function applies the function `func` to each corresponding element of the input sequences, and outputs a _list_ of the same type containing the outputs from those function applications. Applicable sequence types are `(list A)`, `buff`, `string-ascii` and `string-utf8`, for which the corresponding element types are, respectively, `A`, `(buff 1)`, `(string-ascii 1)` and `(string-utf8 1)`. The `func` argument must be a literal function name. Also, note that, no matter what kind of sequences the inputs are, the output is always a list.
-
-**example:**
-
-```
-(map not (list true false true false)) ;; Returns (false true false true)
-(map + (list 1 2 3) (list 1 2 3) (list 1 2 3)) ;; Returns (3 6 9)
-(define-private (a-or-b (char (string-utf8 1)))
- (if (is-eq char u"a") u"a" u"b"))
-(map a-or-b u"aca") ;; Returns (u"a" u"b" u"a")
-(define-private (zero-or-one (char (buff 1)))
- (if (is-eq char 0x00) 0x00 0x01))
-(map zero-or-one 0x000102) ;; Returns (0x00 0x01 0x01)
-```
-
-## map-delete
-
-Introduced in: **Clarity 1**
-
-**input:** `MapName, tuple`
-
-**output:** `bool`
-
-**signature:** `(map-delete map-name key-tuple)`
-
-**description:**
-
-The `map-delete` function removes the value associated with the input key for the given map. If an item exists and is removed, the function returns `true`. If a value did not exist for this key in the data map, the function returns `false`.
-
-**example:**
-
-```
-(define-map names-map { name: (string-ascii 10) } { id: int })
-(map-insert names-map { name: "blockstack" } { id: 1337 }) ;; Returns true
-(map-delete names-map { name: "blockstack" }) ;; Returns true
-(map-delete names-map { name: "blockstack" }) ;; Returns false
-(map-delete names-map (tuple (name "blockstack"))) ;; Same command, using a shorthand for constructing the tuple
-```
-
-## map-get?
-
-Introduced in: **Clarity 1**
-
-**input:** `MapName, tuple`
-
-**output:** `(optional (tuple))`
-
-**signature:** `(map-get? map-name key-tuple)`
-
-**description:**
-
-The `map-get?` function looks up and returns an entry from a contract's data map. The value is looked up using `key-tuple`. If there is no value associated with that key in the data map, the function returns a `none` option. Otherwise, it returns `(some value)`.
-
-**example:**
-
-```
-(define-map names-map { name: (string-ascii 10) } { id: int })
-(map-set names-map { name: "blockstack" } { id: 1337 })
-(map-get? names-map (tuple (name "blockstack"))) ;; Returns (some (tuple (id 1337)))
-(map-get? names-map { name: "blockstack" }) ;; Same command, using a shorthand for constructing the tuple
-```
-
-## map-insert
-
-Introduced in: **Clarity 1**
-
-**input:** `MapName, tuple_A, tuple_B`
-
-**output:** `bool`
-
-**signature:** `(map-insert map-name key-tuple value-tuple)`
-
-**description:**
-
-The `map-insert` function sets the value associated with the input key to the inputted value if and only if there is not already a value associated with the key in the map. If an insert occurs, the function returns `true`. If a value already existed for this key in the data map, the function returns `false`.
-
-Note: the `value-tuple` requires 1 additional byte for storage in the materialized blockchain state, and therefore the maximum size of a value that may be inserted into a map is MAX\_CLARITY\_VALUE - 1.
-
-**example:**
-
-```
-(define-map names-map { name: (string-ascii 10) } { id: int })
-(map-insert names-map { name: "blockstack" } { id: 1337 }) ;; Returns true
-(map-insert names-map { name: "blockstack" } { id: 1337 }) ;; Returns false
-(map-insert names-map (tuple (name "blockstack")) (tuple (id 1337))) ;; Same command, using a shorthand for constructing the tuple
-```
-
-## map-set
-
-Introduced in: **Clarity 1**
-
-**input:** `MapName, tuple_A, tuple_B`
-
-**output:** `bool`
-
-**signature:** `(map-set map-name key-tuple value-tuple)`
-
-**description:**
-
-The `map-set` function sets the value associated with the input key to the inputted value. This function performs a _blind_ update; whether or not a value is already associated with the key, the function overwrites that existing association.
-
-Note: the `value-tuple` requires 1 additional byte for storage in the materialized blockchain state, and therefore the maximum size of a value that may be inserted into a map is MAX\_CLARITY\_VALUE - 1.
-
-**example:**
-
-```
-(define-map names-map { name: (string-ascii 10) } { id: int })
-(map-set names-map { name: "blockstack" } { id: 1337 }) ;; Returns true
-(map-set names-map (tuple (name "blockstack")) (tuple (id 1337))) ;; Same command, using a shorthand for constructing the tuple
-```
-
-## match
-
-Introduced in: **Clarity 1**
-
-**input:** `(optional A) name expression expression | (response A B) name expression name expression`
-
-**output:** `C`
-
-**signature:** `(match opt-input some-binding-name some-branch none-branch) | (match-resp input ok-binding-name ok-branch err-binding-name err-branch)`
-
-**description:**
-
-The `match` function is used to test and destructure optional and response types.
-
-If the `input` is an optional, it tests whether the provided `input` is a `some` or `none` option, and evaluates `some-branch` or `none-branch` in each respective case.
-
-Within the `some-branch`, the _contained value_ of the `input` argument is bound to the provided `some-binding-name` name.
-
-Only _one_ of the branches will be evaluated (similar to `if` statements).
-
-If the `input` is a response, it tests whether the provided `input` is an `ok` or `err` response type, and evaluates `ok-branch` or `err-branch` in each respective case.
-
-Within the `ok-branch`, the _contained ok value_ of the `input` argument is bound to the provided `ok-binding-name` name.
-
-Within the `err-branch`, the _contained err value_ of the `input` argument is bound to the provided `err-binding-name` name.
-
-Only _one_ of the branches will be evaluated (similar to `if` statements).
-
-Note: Type checking requires that the type of both the ok and err parts of the response object be determinable. For situations in which one of the parts of a response is untyped, you should use `unwrap-panic` or `unwrap-err-panic` instead of `match`.
-
-**example:**
-
-```
-(define-private (add-10 (x (optional int)))
- (match x
- value (+ 10 value)
- 10))
-(add-10 (some 5)) ;; Returns 15
-(add-10 none) ;; Returns 10
-(define-private (add-or-pass-err (x (response int (string-ascii 10))) (to-add int))
- (match x
- value (ok (+ to-add value))
- err-value (err err-value)))
-(add-or-pass-err (ok 5) 20) ;; Returns (ok 25)
-(add-or-pass-err (err "ERROR") 20) ;; Returns (err "ERROR")
-```
-
-## merge
-
-Introduced in: **Clarity 1**
-
-**input:** `tuple, tuple`
-
-**output:** `tuple`
-
-**signature:** `(merge tuple { key1: val1 })`
-
-**description:**
-
-The `merge` function returns a new tuple with the combined fields, without mutating the supplied tuples.
-
-**example:**
-
-```
-(define-map users { id: int } { name: (string-ascii 12), address: (optional principal) })
-(map-insert users { id: 1337 } { name: "john", address: none }) ;; Returns true
-(let
- ( (user (unwrap-panic (map-get? users { id: 1337 }))))
- (merge user { address: (some 'SPAXYA5XS51713FDTQ8H94EJ4V579CXMTRNBZKSF) })) ;; Returns (tuple (address (some SPAXYA5XS51713FDTQ8H94EJ4V579CXMTRNBZKSF)) (name "john"))
-```
-
-## mod
-
-Introduced in: **Clarity 1**
-
-**input:** `int, int | uint, uint | string-ascii, string-ascii | string-utf8, string-utf8 | buff, buff`
-
-**output:** `int | uint`
-
-**signature:** `(mod i1 i2)`
-
-**description:**
-
-Returns the integer remainder from integer dividing `i1` by `i2`. In the event of a division by zero, throws a runtime error.
-
-**example:**
-
-```
-(mod 2 3) ;; Returns 2
-(mod 5 2) ;; Returns 1
-(mod 7 1) ;; Returns 0
-```
-
-## nft-burn?
-
-Introduced in: **Clarity 1**
-
-**input:** `AssetName, A, principal`
-
-**output:** `(response bool uint)`
-
-**signature:** `(nft-burn? asset-class asset-identifier sender)`
-
-**description:**
-
-`nft-burn?` is used to burn an asset that the `sender` principal owns. The asset must have been defined using `define-non-fungible-token`, and the supplied `asset-identifier` must be of the same type specified in that definition.
-
-On a successful burn, it returns `(ok true)`. In the event of an unsuccessful burn it returns one of the following error codes:
-
-`(err u1)` -- `sender` does not own the specified asset `(err u3)` -- the asset specified by `asset-identifier` does not exist
-
-**example:**
-
-```
-(define-non-fungible-token stackaroo (string-ascii 40))
-(nft-mint? stackaroo "Roo" 'SPAXYA5XS51713FDTQ8H94EJ4V579CXMTRNBZKSF) ;; Returns (ok true)
-(nft-burn? stackaroo "Roo" 'SPAXYA5XS51713FDTQ8H94EJ4V579CXMTRNBZKSF) ;; Returns (ok true)
-```
-
-## nft-get-owner?
-
-Introduced in: **Clarity 1**
-
-**input:** `AssetName, A`
-
-**output:** `(optional principal)`
-
-**signature:** `(nft-get-owner? asset-class asset-identifier)`
-
-**description:**
-
-`nft-get-owner?` returns the owner of an asset, identified by `asset-identifier`, or `none` if the asset does not exist. The asset type must have been defined using `define-non-fungible-token`, and the supplied `asset-identifier` must be of the same type specified in that definition.
-
-**example:**
-
-```
-(define-non-fungible-token stackaroo (string-ascii 40))
-(nft-mint? stackaroo "Roo" 'SPAXYA5XS51713FDTQ8H94EJ4V579CXMTRNBZKSF)
-(nft-get-owner? stackaroo "Roo") ;; Returns (some SPAXYA5XS51713FDTQ8H94EJ4V579CXMTRNBZKSF)
-(nft-get-owner? stackaroo "Too") ;; Returns none
-```
-
-## nft-mint?
-
-Introduced in: **Clarity 1**
-
-**input:** `AssetName, A, principal`
-
-**output:** `(response bool uint)`
-
-**signature:** `(nft-mint? asset-class asset-identifier recipient)`
-
-**description:**
-
-`nft-mint?` is used to instantiate an asset and set that asset's owner to the `recipient` principal. The asset must have been defined using `define-non-fungible-token`, and the supplied `asset-identifier` must be of the same type specified in that definition.
-
-If an asset identified by `asset-identifier` _already exists_, this function will return an error with the following error code:
-
-`(err u1)`
-
-Otherwise, on successfuly mint, it returns `(ok true)`.
-
-**example:**
-
-```
-(define-non-fungible-token stackaroo (string-ascii 40))
-(nft-mint? stackaroo "Roo" 'SPAXYA5XS51713FDTQ8H94EJ4V579CXMTRNBZKSF) ;; Returns (ok true)
-```
-
-## nft-transfer?
-
-Introduced in: **Clarity 1**
-
-**input:** `AssetName, A, principal, principal`
-
-**output:** `(response bool uint)`
-
-**signature:** `(nft-transfer? asset-class asset-identifier sender recipient)`
-
-**description:**
-
-`nft-transfer?` is used to change the owner of an asset identified by `asset-identifier` from `sender` to `recipient`. The `asset-class` must have been defined by `define-non-fungible-token` and `asset-identifier` must be of the type specified in that definition. In contrast to `stx-transfer?`, any user can transfer the asset. When used, relevant guards need to be added.
-
-This function returns (ok true) if the transfer is successful. In the event of an unsuccessful transfer it returns one of the following error codes:
-
-`(err u1)` -- `sender` does not own the asset `(err u2)` -- `sender` and `recipient` are the same principal `(err u3)` -- asset identified by asset-identifier does not exist
-
-**example:**
-
-```
-(define-non-fungible-token stackaroo (string-ascii 40))
-(nft-mint? stackaroo "Roo" 'SZ2J6ZY48GV1EZ5V2V5RB9MP66SW86PYKKQ9H6DPR)
-(nft-transfer? stackaroo "Roo" 'SZ2J6ZY48GV1EZ5V2V5RB9MP66SW86PYKKQ9H6DPR 'SPAXYA5XS51713FDTQ8H94EJ4V579CXMTRNBZKSF) ;; Returns (ok true)
-(nft-transfer? stackaroo "Roo" 'SZ2J6ZY48GV1EZ5V2V5RB9MP66SW86PYKKQ9H6DPR 'SPAXYA5XS51713FDTQ8H94EJ4V579CXMTRNBZKSF) ;; Returns (err u1)
-(nft-transfer? stackaroo "Stacka" 'SZ2J6ZY48GV1EZ5V2V5RB9MP66SW86PYKKQ9H6DPR 'SPAXYA5XS51713FDTQ8H94EJ4V579CXMTRNBZKSF) ;; Returns (err u3)
-```
-
-## not
-
-Introduced in: **Clarity 1**
-
-**input:** `bool`
-
-**output:** `bool`
-
-**signature:** `(not b1)`
-
-**description:**
-
-Returns the inverse of the boolean input.
-
-**example:**
-
-```
-(not true) ;; Returns false
-(not (is-eq 1 2)) ;; Returns true
-```
-
-## ok
-
-Introduced in: **Clarity 1**
-
-**input:** `A`
-
-**output:** `(response A B)`
-
-**signature:** `(ok value)`
-
-**description:**
-
-The `ok` function constructs a response type from the input value. Use `ok` for creating return values in public functions. An _ok_ value indicates that any database changes during the processing of the function should materialize.
-
-**example:**
-
-```
-(ok 1) ;; Returns (ok 1)
-```
-
-## or
-
-Introduced in: **Clarity 1**
-
-**input:** `bool, ...`
-
-**output:** `bool`
-
-**signature:** `(or b1 b2 ...)`
-
-**description:**
-
-Returns `true` if any boolean inputs are `true`. Importantly, the supplied arguments are evaluated in-order and lazily. Lazy evaluation means that if one of the arguments returns `true`, the function short-circuits, and no subsequent arguments are evaluated.
-
-**example:**
-
-```
-(or true false) ;; Returns true
-(or (is-eq (+ 1 2) 1) (is-eq 4 4)) ;; Returns true
-(or (is-eq (+ 1 2) 1) (is-eq 3 4)) ;; Returns false
-(or (is-eq (+ 1 2) 3) (is-eq 4 4)) ;; Returns true
-```
-
-## pow
-
-Introduced in: **Clarity 1**
-
-**input:** `int, int | uint, uint | string-ascii, string-ascii | string-utf8, string-utf8 | buff, buff`
-
-**output:** `int | uint`
-
-**signature:** `(pow i1 i2)`
-
-**description:**
-
-Returns the result of raising `i1` to the power of `i2`. In the event of an _overflow_, throws a runtime error. Note: Corner cases are handled with the following rules:
-
-* if both `i1` and `i2` are `0`, return `1`
-* if `i1` is `1`, return `1`
-* if `i1` is `0`, return `0`
-* if `i2` is negative or greater than `u32::MAX`, throw a runtime error
-
-**example:**
-
-```
-(pow 2 3) ;; Returns 8
-(pow 2 2) ;; Returns 4
-(pow 7 1) ;; Returns 7
-```
-
-## principal-construct?
-
-Introduced in: **Clarity 2**
-
-**input:** `(buff 1), (buff 20), [(string-ascii 40)]`
-
-**output:** `(response principal { error_code: uint, principal: (option principal) })`
-
-**signature:** `(principal-construct? (buff 1) (buff 20) [(string-ascii 40)])`
-
-**description:**
-
-A principal value represents either a set of keys, or a smart contract. The former, called a _standard principal_, is encoded as a `(buff 1)` _version byte_, indicating the type of account and the type of network that this principal can spend tokens on, and a `(buff 20)` _public key hash_, characterizing the principal's unique identity. The latter, a _contract principal_, is encoded as a standard principal concatenated with a `(string-ascii 40)` _contract name_ that identifies the code body.
-
-The `principal-construct?` function allows users to create either standard or contract principals, depending on which form is used. To create a standard principal, `principal-construct?` would be called with two arguments: it takes as input a `(buff 1)` which encodes the principal address's `version-byte`, a `(buff 20)` which encodes the principal address's `hash-bytes`. To create a contract principal, `principal-construct?` would be called with three arguments: the `(buff 1)` and `(buff 20)` to represent the standard principal that created the contract, and a `(string-ascii 40)` which encodes the contract's name. On success, this function returns either a standard principal or contract principal, depending on whether or not the third `(string-ascii 40)` argument is given.
-
-This function returns a `Response`. On success, the `ok` value is a `Principal`. The `err` value is a value tuple with the form `{ error_code: uint, value: (optional principal) }`.
-
-If the single-byte `version-byte` is in the valid range `0x00` to `0x1f`, but is not an appropriate version byte for the current network, then the error will be `u0`, and `value` will contain `(some principal)`, where the wrapped value is the principal. If the `version-byte` is not in this range, however, then the `value` will be `none`.
-
-If the `version-byte` is a `buff` of length 0, if the single-byte `version-byte` is a value greater than `0x1f`, or the `hash-bytes` is a `buff` of length not equal to 20, then `error_code` will be `u1` and `value` will be `None`.
-
-If a name is given, and the name is either an empty string or contains ASCII characters that are not allowed in contract names, then `error_code` will be `u2`.
-
-Note: This function is only available starting with Stacks 2.1.
-
-**example:**
-
-```
-(principal-construct? 0x1a 0xfa6bf38ed557fe417333710d6033e9419391a320) ;; Returns (ok ST3X6QWWETNBZWGBK6DRGTR1KX50S74D3425Q1TPK)
-(principal-construct? 0x1a 0xfa6bf38ed557fe417333710d6033e9419391a320 "foo") ;; Returns (ok ST3X6QWWETNBZWGBK6DRGTR1KX50S74D3425Q1TPK.foo)
-(principal-construct? 0x16 0xfa6bf38ed557fe417333710d6033e9419391a320) ;; Returns (err (tuple (error_code u0) (value (some SP3X6QWWETNBZWGBK6DRGTR1KX50S74D3433WDGJY))))
-(principal-construct? 0x16 0xfa6bf38ed557fe417333710d6033e9419391a320 "foo") ;; Returns (err (tuple (error_code u0) (value (some SP3X6QWWETNBZWGBK6DRGTR1KX50S74D3433WDGJY.foo))))
-(principal-construct? 0x 0xfa6bf38ed557fe417333710d6033e9419391a320) ;; Returns (err (tuple (error_code u1) (value none)))
-(principal-construct? 0x16 0xfa6bf38ed557fe417333710d6033e9419391a3) ;; Returns (err (tuple (error_code u1) (value none)))
-(principal-construct? 0x20 0xfa6bf38ed557fe417333710d6033e9419391a320) ;; Returns (err (tuple (error_code u1) (value none)))
-(principal-construct? 0x1a 0xfa6bf38ed557fe417333710d6033e9419391a320 "") ;; Returns (err (tuple (error_code u2) (value none)))
-(principal-construct? 0x1a 0xfa6bf38ed557fe417333710d6033e9419391a320 "foo[") ;; Returns (err (tuple (error_code u2) (value none)))
-```
-
-## principal-destruct?
-
-Introduced in: **Clarity 2**
-
-**input:** `principal`
-
-**output:** `(response (tuple (hash-bytes (buff 20)) (name (optional (string-ascii 40))) (version (buff 1))) (tuple (hash-bytes (buff 20)) (name (optional (string-ascii 40))) (version (buff 1))))`
-
-**signature:** `(principal-destruct? principal-address)`
-
-**description:**
-
-A principal value represents either a set of keys, or a smart contract. The former, called a _standard principal_, is encoded as a `(buff 1)` _version byte_, indicating the type of account and the type of network that this principal can spend tokens on, and a `(buff 20)` _public key hash_, characterizing the principal's unique identity. The latter, a _contract principal_, is encoded as a standard principal concatenated with a `(string-ascii 40)` _contract name_ that identifies the code body.
-
-`principal-destruct?` will decompose a principal into its component parts: either`{version-byte, hash-bytes}` for standard principals, or `{version-byte, hash-bytes, name}` for contract principals.
-
-This method returns a `Response` that wraps this data as a tuple.
-
-If the version byte of `principal-address` matches the network (see `is-standard`), then this method returns the pair as its `ok` value.
-
-If the version byte of `principal-address` does not match the network, then this method returns the pair as its `err` value.
-
-In both cases, the value itself is a tuple containing three fields: a `version` value as a `(buff 1)`, a `hash-bytes` value as a `(buff 20)`, and a `name` value as an `(optional (string-ascii 40))`. The `name` field will only be `(some ..)` if the principal is a contract principal.
-
-Note: This function is only available starting with Stacks 2.1.
-
-**example:**
-
-```
-(principal-destruct? 'STB44HYPYAT2BB2QE513NSP81HTMYWBJP02HPGK6) ;; Returns (ok (tuple (hash-bytes 0x164247d6f2b425ac5771423ae6c80c754f7172b0) (name none) (version 0x1a)))
-(principal-destruct? 'STB44HYPYAT2BB2QE513NSP81HTMYWBJP02HPGK6.foo) ;; Returns (ok (tuple (hash-bytes 0x164247d6f2b425ac5771423ae6c80c754f7172b0) (name (some "foo")) (version 0x1a)))
-(principal-destruct? 'SP3X6QWWETNBZWGBK6DRGTR1KX50S74D3433WDGJY) ;; Returns (err (tuple (hash-bytes 0xfa6bf38ed557fe417333710d6033e9419391a320) (name none) (version 0x16)))
-(principal-destruct? 'SP3X6QWWETNBZWGBK6DRGTR1KX50S74D3433WDGJY.foo) ;; Returns (err (tuple (hash-bytes 0xfa6bf38ed557fe417333710d6033e9419391a320) (name (some "foo")) (version 0x16)))
-```
-
-## principal-of?
-
-Introduced in: **Clarity 1**
-
-**input:** `(buff 33)`
-
-**output:** `(response principal uint)`
-
-**signature:** `(principal-of? public-key)`
-
-**description:**
-
-The `principal-of?` function returns the principal derived from the provided public key. If the `public-key` is invalid, it will return the error code `(err u1).`.
-
-Note: Before Stacks 2.1, this function has a bug, in that the principal returned would always be a testnet single-signature principal, even if the function were run on the mainnet. Starting with Stacks 2.1, this bug is fixed, so that this function will return a principal suited to the network it is called on. In particular, if this is called on the mainnet, it will return a single-signature mainnet principal.
-
-**example:**
-
-```
-(principal-of? 0x03adb8de4bfb65db2cfd6120d55c6526ae9c52e675db7e47308636534ba7786110) ;; Returns (ok ST1AW6EKPGT61SQ9FNVDS17RKNWT8ZP582VF9HSCP)
-```
-
-## print
-
-Introduced in: **Clarity 1**
-
-**input:** `A`
-
-**output:** `A`
-
-**signature:** `(print expr)`
-
-**description:**
-
-The `print` function evaluates and returns its input expression. On Stacks Core nodes configured for development (as opposed to production mining nodes), this function prints the resulting value to `STDOUT` (standard output).
-
-**example:**
-
-```
-(print (+ 1 2 3)) ;; Returns 6
-```
-
-## replace-at?
-
-Introduced in: **Clarity 2**
-
-**input:** `sequence_A, uint, A`
-
-**output:** `(optional sequence_A)`
-
-**signature:** `(replace-at? sequence index element)`
-
-**description:**
-
-The `replace-at?` function takes in a sequence, an index, and an element, and returns a new sequence with the data at the index position replaced with the given element. The given element's type must match the type of the sequence, and must correspond to a single index of the input sequence. The return type on success is the same type as the input sequence.
-
-If the provided index is out of bounds, this functions returns `none`.
-
-**example:**
-
-```
-(replace-at? u"ab" u1 u"c") ;; Returns (some u"ac")
-(replace-at? 0x00112233 u2 0x44) ;; Returns (some 0x00114433)
-(replace-at? "abcd" u3 "e") ;; Returns (some "abce")
-(replace-at? (list 1) u0 10) ;; Returns (some (10))
-(replace-at? (list (list 1) (list 2)) u0 (list 33)) ;; Returns (some ( (33) (2)))
-(replace-at? (list 1 2) u3 4) ;; Returns none
-```
-
-## secp256k1-recover?
-
-Introduced in: **Clarity 1**
-
-**input:** `(buff 32), (buff 65)`
-
-**output:** `(response (buff 33) uint)`
-
-**signature:** `(secp256k1-recover? message-hash signature)`
-
-**description:**
-
-The `secp256k1-recover?` function recovers the public key used to sign the message which sha256 is `message-hash` with the provided `signature`. If the signature does not match, it will return the error code `(err u1).`. If the signature is invalid, it will return the error code `(err u2).`. The signature includes 64 bytes plus an additional recovery id (00..03) for a total of 65 bytes.
-
-**example:**
-
-```
-(secp256k1-recover? 0xde5b9eb9e7c5592930eb2e30a01369c36586d872082ed8181ee83d2a0ec20f04 0x8738487ebe69b93d8e51583be8eee50bb4213fc49c767d329632730cc193b873554428fc936ca3569afc15f1c9365f6591d6251a89fee9c9ac661116824d3a1301) ;; Returns (ok 0x03adb8de4bfb65db2cfd6120d55c6526ae9c52e675db7e47308636534ba7786110)
-```
-
-## secp256k1-verify
-
-Introduced in: **Clarity 1**
-
-**input:** `(buff 32), (buff 64) | (buff 65), (buff 33)`
-
-**output:** `bool`
-
-**signature:** `(secp256k1-verify message-hash signature public-key)`
-
-**description:**
-
-The `secp256k1-verify` function verifies that the provided signature of the message-hash was signed with the private key that generated the public key. The `message-hash` is the `sha256` of the message. The signature includes 64 bytes plus an optional additional recovery id (00..03) for a total of 64 or 65 bytes.
-
-**example:**
-
-```
-(secp256k1-verify 0xde5b9eb9e7c5592930eb2e30a01369c36586d872082ed8181ee83d2a0ec20f04 0x8738487ebe69b93d8e51583be8eee50bb4213fc49c767d329632730cc193b873554428fc936ca3569afc15f1c9365f6591d6251a89fee9c9ac661116824d3a1301 0x03adb8de4bfb65db2cfd6120d55c6526ae9c52e675db7e47308636534ba7786110) ;; Returns true
-(secp256k1-verify 0xde5b9eb9e7c5592930eb2e30a01369c36586d872082ed8181ee83d2a0ec20f04 0x8738487ebe69b93d8e51583be8eee50bb4213fc49c767d329632730cc193b873554428fc936ca3569afc15f1c9365f6591d6251a89fee9c9ac661116824d3a13 0x03adb8de4bfb65db2cfd6120d55c6526ae9c52e675db7e47308636534ba7786110) ;; Returns true
-(secp256k1-verify 0x0000000000000000000000000000000000000000000000000000000000000000 0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0x03adb8de4bfb65db2cfd6120d55c6526ae9c52e675db7e47308636534ba7786110) ;; Returns false
-```
-
-## sha256
-
-Introduced in: **Clarity 1**
-
-**input:** `buff|uint|int`
-
-**output:** `(buff 32)`
-
-**signature:** `(sha256 value)`
-
-**description:**
-
-The `sha256` function computes `SHA256(x)` of the inputted value. If an integer (128 bit) is supplied the hash is computed over the little-endian representation of the integer.
-
-**example:**
-
-```
-(sha256 0) ;; Returns 0x374708fff7719dd5979ec875d56cd2286f6d3cf7ec317a3b25632aab28ec37bb
-```
-
-## sha512
-
-Introduced in: **Clarity 1**
-
-**input:** `buff|uint|int`
-
-**output:** `(buff 64)`
-
-**signature:** `(sha512 value)`
-
-**description:**
-
-The `sha512` function computes `SHA512(x)` of the inputted value. If an integer (128 bit) is supplied the hash is computed over the little-endian representation of the integer.
-
-**example:**
-
-```
-(sha512 1) ;; Returns 0x6fcee9a7b7a7b821d241c03c82377928bc6882e7a08c78a4221199bfa220cdc55212273018ee613317c8293bb8d1ce08d1e017508e94e06ab85a734c99c7cc34
-```
-
-## sha512/256
-
-Introduced in: **Clarity 1**
-
-**input:** `buff|uint|int`
-
-**output:** `(buff 32)`
-
-**signature:** `(sha512/256 value)`
-
-**description:**
-
-The `sha512/256` function computes `SHA512/256(x)` (the SHA512 algorithm with the 512/256 initialization vector, truncated to 256 bits) of the inputted value. If an integer (128 bit) is supplied the hash is computed over the little-endian representation of the integer.
-
-**example:**
-
-```
-(sha512/256 1) ;; Returns 0x515a7e92e7c60522db968d81ff70b80818fc17aeabbec36baf0dda2812e94a86
-```
-
-## slice?
-
-Introduced in: **Clarity 2**
-
-**input:** `sequence_A, uint, uint`
-
-**output:** `(optional sequence_A)`
-
-**signature:** `(slice? sequence left-position right-position)`
-
-**description:**
-
-The `slice?` function attempts to return a sub-sequence of that starts at `left-position` (inclusive), and ends at `right-position` (non-inclusive). If `left_position`==`right_position`, the function returns an empty sequence. If either `left_position` or `right_position` are out of bounds OR if `right_position` is less than `left_position`, the function returns `none`.
-
-**example:**
-
-```
-(slice? "blockstack" u5 u10) ;; Returns (some "stack")
-(slice? (list 1 2 3 4 5) u5 u9) ;; Returns none
-(slice? (list 1 2 3 4 5) u3 u4) ;; Returns (some (4))
-(slice? "abcd" u1 u3) ;; Returns (some "bc")
-(slice? "abcd" u2 u2) ;; Returns (some "")
-(slice? "abcd" u3 u1) ;; Returns none
-```
-
-## some
-
-Introduced in: **Clarity 1**
-
-**input:** `A`
-
-**output:** `(optional A)`
-
-**signature:** `(some value)`
-
-**description:**
-
-The `some` function constructs a `optional` type from the input value.
-
-**example:**
-
-```
-(some 1) ;; Returns (some 1)
-(is-none (some 2)) ;; Returns false
-```
-
-## sqrti
-
-Introduced in: **Clarity 1**
-
-**input:** `int | uint`
-
-**output:** `int | uint`
-
-**signature:** `(sqrti n)`
-
-**description:**
-
-Returns the largest integer that is less than or equal to the square root of `n`.\
-Fails on a negative numbers.
-
-**example:**
-
-```
-(sqrti u11) ;; Returns u3
-(sqrti 1000000) ;; Returns 1000
-(sqrti u1) ;; Returns u1
-(sqrti 0) ;; Returns 0
-```
-
-## string-to-int?
-
-Introduced in: **Clarity 2**
-
-**input:** `(string-ascii 1048576) | (string-utf8 262144)`
-
-**output:** `(optional int)`
-
-**signature:** `(string-to-int? (string-ascii|string-utf8))`
-
-**description:**
-
-Converts a string, either `string-ascii` or `string-utf8`, to an optional-wrapped signed integer. If the input string does not represent a valid integer, then the function returns `none`. Otherwise it returns an integer wrapped in `some`.
-
-Note: This function is only available starting with Stacks 2.1.
-
-**example:**
-
-```
-(string-to-int? "1") ;; Returns (some 1)
-(string-to-int? u"-1") ;; Returns (some -1)
-(string-to-int? "a") ;; Returns none
-```
-
-## string-to-uint?
-
-Introduced in: **Clarity 2**
-
-**input:** `(string-ascii 1048576) | (string-utf8 262144)`
-
-**output:** `(optional uint)`
-
-**signature:** `(string-to-uint? (string-ascii|string-utf8))`
-
-**description:**
-
-Converts a string, either `string-ascii` or `string-utf8`, to an optional-wrapped unsigned integer. If the input string does not represent a valid integer, then the function returns `none`. Otherwise it returns an unsigned integer wrapped in `some`.
-
-Note: This function is only available starting with Stacks 2.1.
-
-**example:**
-
-```
-(string-to-uint? "1") ;; Returns (some u1)
-(string-to-uint? u"1") ;; Returns (some u1)
-(string-to-uint? "a") ;; Returns none
-```
-
-## stx-account
-
-Introduced in: **Clarity 2**
-
-**input:** `principal`
-
-**output:** `(tuple (locked uint) (unlock-height uint) (unlocked uint))`
-
-**signature:** `(stx-account owner)`
-
-**description:**
-
-`stx-account` is used to query the STX account of the `owner` principal.
-
-This function returns a tuple with the canonical account representation for an STX account. This includes the current amount of unlocked STX, the current amount of locked STX, and the unlock height for any locked STX, all denominated in microstacks.
-
-**example:**
-
-```
-(stx-account 'SZ2J6ZY48GV1EZ5V2V5RB9MP66SW86PYKKQ9H6DPR) ;; Returns (tuple (locked u0) (unlock-height u0) (unlocked u0))
-(stx-account (as-contract tx-sender)) ;; Returns (tuple (locked u0) (unlock-height u0) (unlocked u1000))
-```
-
-## stx-burn?
-
-Introduced in: **Clarity 1**
-
-**input:** `uint, principal`
-
-**output:** `(response bool uint)`
-
-**signature:** `(stx-burn? amount sender)`
-
-**description:**
-
-`stx-burn?` decreases the `sender` principal's STX holdings by `amount`, specified in microstacks, by destroying the STX. The `sender` principal _must_ be equal to the current context's `tx-sender`.
-
-This function returns (ok true) if the transfer is successful. In the event of an unsuccessful transfer it returns one of the following error codes:
-
-`(err u1)` -- `sender` does not have enough balance to transfer `(err u3)` -- amount to send is non-positive `(err u4)` -- the `sender` principal is not the current `tx-sender`
-
-**example:**
-
-```
-(as-contract (stx-burn? u60 tx-sender)) ;; Returns (ok true)
-(as-contract (stx-burn? u50 'SZ2J6ZY48GV1EZ5V2V5RB9MP66SW86PYKKQ9H6DPR)) ;; Returns (err u4)
-```
-
-## stx-get-balance
-
-Introduced in: **Clarity 1**
-
-**input:** `principal`
-
-**output:** `uint`
-
-**signature:** `(stx-get-balance owner)`
-
-**description:**
-
-`stx-get-balance` is used to query the STX balance of the `owner` principal.
-
-This function returns the STX balance, in microstacks (1 STX = 1,000,000 microstacks), of the `owner` principal. In the event that the `owner` principal isn't materialized, it returns 0.
-
-**example:**
-
-```
-(stx-get-balance 'SZ2J6ZY48GV1EZ5V2V5RB9MP66SW86PYKKQ9H6DPR) ;; Returns u0
-(stx-get-balance (as-contract tx-sender)) ;; Returns u1000
-```
-
-## stx-transfer-memo?
-
-Introduced in: **Clarity 2**
-
-**input:** `uint, principal, principal, buff`
-
-**output:** `(response bool uint)`
-
-**signature:** `(stx-transfer-memo? amount sender recipient memo)`
-
-**description:**
-
-`stx-transfer-memo?` is similar to `stx-transfer?`, except that it adds a `memo` field.
-
-This function returns (ok true) if the transfer is successful, or, on an error, returns the same codes as `stx-transfer?`.
-
-**example:**
-
-```
-(as-contract (stx-transfer-memo? u60 tx-sender 'SZ2J6ZY48GV1EZ5V2V5RB9MP66SW86PYKKQ9H6DPR 0x010203)) ;; Returns (ok true)
-```
-
-## stx-transfer?
-
-Introduced in: **Clarity 1**
-
-**input:** `uint, principal, principal`
-
-**output:** `(response bool uint)`
-
-**signature:** `(stx-transfer? amount sender recipient)`
-
-**description:**
-
-`stx-transfer?` is used to increase the STX balance for the `recipient` principal by debiting the `sender` principal by `amount`, specified in microstacks. The `sender` principal _must_ be equal to the current context's `tx-sender`.
-
-This function returns (ok true) if the transfer is successful. In the event of an unsuccessful transfer it returns one of the following error codes:
-
-`(err u1)` -- `sender` does not have enough balance to transfer `(err u2)` -- `sender` and `recipient` are the same principal `(err u3)` -- amount to send is non-positive `(err u4)` -- the `sender` principal is not the current `tx-sender`
-
-**example:**
-
-```
-(as-contract (stx-transfer? u60 tx-sender 'SZ2J6ZY48GV1EZ5V2V5RB9MP66SW86PYKKQ9H6DPR)) ;; Returns (ok true)
-(as-contract (stx-transfer? u60 tx-sender 'SZ2J6ZY48GV1EZ5V2V5RB9MP66SW86PYKKQ9H6DPR)) ;; Returns (ok true)
-(as-contract (stx-transfer? u50 'SZ2J6ZY48GV1EZ5V2V5RB9MP66SW86PYKKQ9H6DPR tx-sender)) ;; Returns (err u4)
-```
-
-## to-consensus-buff?
-
-Introduced in: **Clarity 2**
-
-**input:** `any`
-
-**output:** `(optional buff)`
-
-**signature:** `(to-consensus-buff? value)`
-
-**description:**
-
-`to-consensus-buff?` is a special function that will serialize any Clarity value into a buffer, using the SIP-005 serialization of the Clarity value. Not all values can be serialized: some value's consensus serialization is too large to fit in a Clarity buffer (this is because of the type prefix in the consensus serialization).
-
-If the value cannot fit as serialized into the maximum buffer size, this returns `none`, otherwise, it will be `(some consensus-serialized-buffer)`. During type checking, the analyzed type of the result of this method will be the maximum possible consensus buffer length based on the inferred type of the supplied value.
-
-**example:**
-
-```
-(to-consensus-buff? 1) ;; Returns (some 0x0000000000000000000000000000000001)
-(to-consensus-buff? u1) ;; Returns (some 0x0100000000000000000000000000000001)
-(to-consensus-buff? true) ;; Returns (some 0x03)
-(to-consensus-buff? false) ;; Returns (some 0x04)
-(to-consensus-buff? none) ;; Returns (some 0x09)
-(to-consensus-buff? 'SZ2J6ZY48GV1EZ5V2V5RB9MP66SW86PYKKQ9H6DPR) ;; Returns (some 0x051fa46ff88886c2ef9762d970b4d2c63678835bd39d)
-(to-consensus-buff? { abc: 3, def: 4 }) ;; Returns (some 0x0c00000002036162630000000000000000000000000000000003036465660000000000000000000000000000000004)
-```
-
-## to-int
-
-Introduced in: **Clarity 1**
-
-**input:** `uint`
-
-**output:** `int`
-
-**signature:** `(to-int u)`
-
-**description:**
-
-Tries to convert the `uint` argument to an `int`. Will cause a runtime error and abort if the supplied argument is >= `pow(2, 127)`
-
-**example:**
-
-```
-(to-int u238) ;; Returns 238
-```
-
-## to-uint
-
-Introduced in: **Clarity 1**
-
-**input:** `int`
-
-**output:** `uint`
-
-**signature:** `(to-uint i)`
-
-**description:**
-
-Tries to convert the `int` argument to a `uint`. Will cause a runtime error and abort if the supplied argument is negative.
-
-**example:**
-
-```
-(to-uint 238) ;; Returns u238
-```
-
-## try!
-
-Introduced in: **Clarity 1**
-
-**input:** `(optional A) | (response A B)`
-
-**output:** `A`
-
-**signature:** `(try! option-input)`
-
-**description:**
-
-The `try!` function attempts to 'unpack' the first argument: if the argument is an option type, and the argument is a `(some ...)` option, `try!` returns the inner value of the option. If the argument is a response type, and the argument is an `(ok ...)` response, `try!` returns the inner value of the `ok`. If the supplied argument is either an `(err ...)` or a `none` value, `try!` _returns_ either `none` or the `(err ...)` value from the current function and exits the current control-flow.
-
-**example:**
-
-```
-(define-map names-map { name: (string-ascii 12) } { id: int })
-(map-set names-map { name: "blockstack" } { id: 1337 })
-(try! (map-get? names-map { name: "blockstack" })) ;; Returns (tuple (id 1337))
-(define-private (checked-even (x int))
- (if (is-eq (mod x 2) 0)
- (ok x)
- (err false)))
-(define-private (double-if-even (x int))
- (ok (* 2 (try! (checked-even x)))))
-(double-if-even 10) ;; Returns (ok 20)
-(double-if-even 3) ;; Returns (err false)
-```
-
-## tuple
-
-Introduced in: **Clarity 1**
-
-**input:** `(key-name A), (key-name-2 B), ...`
-
-**output:** `(tuple (key-name A) (key-name-2 B) ...)`
-
-**signature:** `(tuple (key0 expr0) (key1 expr1) ...)`
-
-**description:**
-
-The `tuple` special form constructs a typed tuple from the supplied key and expression pairs. A `get` function can use typed tuples as input to select specific values from a given tuple. Key names may not appear multiple times in the same tuple definition. Supplied expressions are evaluated and associated with the expressions' paired key name.
-
-There is a shorthand using curly brackets of the form {key0: expr0, key1: expr, ...}
-
-**example:**
-
-```
-(tuple (name "blockstack")
-(id 1337)) ;; using tuple
-{name: "blockstack", id: 1337} ;; using curly brackets
-```
-
-## unwrap!
-
-Introduced in: **Clarity 1**
-
-**input:** `(optional A) | (response A B), C`
-
-**output:** `A`
-
-**signature:** `(unwrap! option-input thrown-value)`
-
-**description:**
-
-The `unwrap!` function attempts to 'unpack' the first argument: if the argument is an option type, and the argument is a `(some ...)` option, `unwrap!` returns the inner value of the option. If the argument is a response type, and the argument is an `(ok ...)` response, `unwrap!` returns the inner value of the `ok`. If the supplied argument is either an `(err ...)` or a `(none)` value, `unwrap!` _returns_ `thrown-value` from the current function and exits the current control-flow.
-
-**example:**
-
-```
-(define-map names-map { name: (string-ascii 12) } { id: int })
-(map-set names-map { name: "blockstack" } { id: 1337 })
-(define-private (get-name-or-err (name (string-ascii 12)))
- (let ( (raw-name (unwrap! (map-get? names-map { name: name }) (err 1))))
- (ok raw-name)))
-(get-name-or-err "blockstack") ;; Returns (ok (tuple (id 1337)))
-(get-name-or-err "non-existant") ;; Returns (err 1)
-```
-
-## unwrap-err!
-
-Introduced in: **Clarity 1**
-
-**input:** `(response A B), C`
-
-**output:** `B`
-
-**signature:** `(unwrap-err! response-input thrown-value)`
-
-**description:**
-
-The `unwrap-err!` function attempts to 'unpack' the first argument: if the argument is an `(err ...)` response, `unwrap-err!` returns the inner value of the `err`. If the supplied argument is an `(ok ...)` value, `unwrap-err!` _returns_ `thrown-value` from the current function and exits the current control-flow.
-
-**example:**
-
-```
-(unwrap-err! (err 1) false) ;; Returns 1
-```
-
-## unwrap-err-panic
-
-Introduced in: **Clarity 1**
-
-**input:** `(response A B)`
-
-**output:** `B`
-
-**signature:** `(unwrap-err-panic response-input)`
-
-**description:**
-
-The `unwrap-err` function attempts to 'unpack' the first argument: if the argument is an `(err ...)` response, `unwrap` returns the inner value of the `err`. If the supplied argument is an `(ok ...)` value, `unwrap-err` throws a runtime error, aborting any further processing of the current transaction.
-
-**example:**
-
-```
-(unwrap-err-panic (err 1)) ;; Returns 1
-(unwrap-err-panic (ok 1)) ;; Throws a runtime exception
-```
-
-## unwrap-panic
-
-Introduced in: **Clarity 1**
-
-**input:** `(optional A) | (response A B)`
-
-**output:** `A`
-
-**signature:** `(unwrap-panic option-input)`
-
-**description:**
-
-The `unwrap` function attempts to 'unpack' its argument: if the argument is an option type, and the argument is a `(some ...)` option, this function returns the inner value of the option. If the argument is a response type, and the argument is an `(ok ...)` response, it returns the inner value of the `ok`. If the supplied argument is either an `(err ...)` or a `(none)` value, `unwrap` throws a runtime error, aborting any further processing of the current transaction.
-
-**example:**
-
-```
-(define-map names-map { name: (string-ascii 12) } { id: int })
-(map-set names-map { name: "blockstack" } { id: 1337 })
-(unwrap-panic (map-get? names-map { name: "blockstack" })) ;; Returns (tuple (id 1337))
-(unwrap-panic (map-get? names-map { name: "non-existant" })) ;; Throws a runtime exception
-```
-
-## use-trait
-
-Introduced in: **Clarity 1**
-
-**input:** `VarName, TraitIdentifier`
-
-**output:** `Not Applicable`
-
-**signature:** `(use-trait trait-alias trait-identifier)`
-
-**description:**
-
-`use-trait` is used to bring a trait, defined in another contract, to the current contract. Subsequent references to an imported trait are signaled with the syntax ``.
-
-Traits import are defined with a name, used as an alias, and a trait identifier. Trait identifiers can either be using the sugared syntax (.token-a.token-trait), or be fully qualified ('SPAXYA5XS51713FDTQ8H94EJ4V579CXMTRNBZKSF.token-a.token-trait).
-
-Like other kinds of definition statements, `use-trait` may only be used at the top level of a smart contract definition (i.e., you cannot put such a statement in the middle of a function body).
-
-**example:**
-
-```
-(use-trait token-a-trait 'SPAXYA5XS51713FDTQ8H94EJ4V579CXMTRNBZKSF.token-a.token-trait)
-(define-public (forward-get-balance (user principal) (contract ))
- (begin (ok 1)))
-```
-
-## var-get
-
-Introduced in: **Clarity 1**
-
-**input:** `VarName`
-
-**output:** `A`
-
-**signature:** `(var-get var-name)`
-
-**description:**
-
-The `var-get` function looks up and returns an entry from a contract's data map. The value is looked up using `var-name`.
-
-**example:**
-
-```
-(define-data-var cursor int 6)
-(var-get cursor) ;; Returns 6
-```
-
-## var-set
-
-Introduced in: **Clarity 1**
-
-**input:** `VarName, AnyType`
-
-**output:** `bool`
-
-**signature:** `(var-set var-name expr1)`
-
-**description:**
-
-The `var-set` function sets the value associated with the input variable to the inputted value. The function always returns `true`.
-
-**example:**
-
-```
-(define-data-var cursor int 6)
-(var-get cursor) ;; Returns 6
-(var-set cursor (+ (var-get cursor) 1)) ;; Returns true
-(var-get cursor) ;; Returns 7
-```
-
-## xor
-
-Introduced in: **Clarity 1**
-
-**input:** `int, int | uint, uint | string-ascii, string-ascii | string-utf8, string-utf8 | buff, buff`
-
-**output:** `int | uint`
-
-**signature:** `(xor i1 i2)`
-
-**description:**
-
-Returns the result of bitwise exclusive or'ing `i1` with `i2`.
-
-**example:**
-
-```
-(xor 1 2) ;; Returns 3
-(xor 120 280) ;; Returns 352
-```
diff --git a/reference/keywords.md b/reference/keywords.md
deleted file mode 100644
index a3c83b877f..0000000000
--- a/reference/keywords.md
+++ /dev/null
@@ -1,255 +0,0 @@
-# Clarity Keywords
-
-### block-height
-
-{% hint style="info" %}
-The Nakamoto hard fork will introduce a few new Clarity keywords. It's important to note that even with the new [block production mechanism](../concepts/block-production/), the `block-height` keyword behavior will not change. It will simply correspond to the current tenure height. This means any Clarity contracts using this keyword will be backwards compatible after the Nakamoto Upgrade.
-{% endhint %}
-
-Introduced in: Clarity 1
-
-**output: `uint`**
-
-**description:**
-
-Returns the current block height of the Stacks blockchain in Clarity 1 and 2. Upon activation of epoch 3.0, `block-height` will return the same value as `tenure-height`. In Clarity 3, `block-height` is removed and has been replaced with `stacks-block-height`.
-
-**example:**
-
-```
-(> block-height u1000) ;; returns true if the current block-height has passed 1000 blocks.
-
-```
-
-### burn-block-height
-
-{% hint style="warning" %}
-There is a bug in Clarity 3 when `burn-block-height` is used within an `at-block` expression. Normally, keywords executed within an `at-block` expression will return the data for that specified block. This bug causes `burn-block-height` to always return the burn block at the current chain tip, even within an `at-block` expression. This behavior affects any Clarity 3 contracts and will be fixed in a future hard fork.
-{% endhint %}
-
-Introduced in: Clarity 1
-
-**output: `uint`**
-
-**description:**
-
-Returns the current block height of the underlying burn blockchain as a uint
-
-**example:**
-
-```
-(> burn-block-height 1000) ;; returns true if the current height of the underlying burn blockchain has passed 1000 blocks.
-```
-
-### chain-id
-
-Introduced in: Clarity 2
-
-**output: `uint`**
-
-**description:**
-
-Returns the 32-bit chain ID of the blockchain running this transaction
-
-**example:**
-
-```
-(print chain-id) ;; Will print 'u1' if the code is running on mainnet, and 'u2147483648' on testnet, and other values on different chains.
-```
-
-### contract-caller
-
-Introduced in: Clarity 1
-
-**output: `principal`**
-
-**description:**
-
-Returns the caller of the current contract context. If this contract is the first one called by a signed transaction, the caller will be equal to the signing principal. If `contract-call?` was used to invoke a function from a new contract, `contract-caller` changes to the _calling_ contract's principal. If `as-contract` is used to change the `tx-sender` context, `contract-caller` _also_ changes to the same contract principal.
-
-**example:**
-
-```
-(print contract-caller) ;; Will print out a Stacks address of the transaction sender
-```
-
-{% hint style="warning" %}
-Use caution when leveraging all contract calls, particularly tx-sender and contract-caller as based on the design, you can unintentionally introduce attack surface area. [Read more](https://www.setzeus.com/community-blog-posts/clarity-carefully-tx-sender).
-{% endhint %}
-
-### false
-
-Introduced in: Clarity 1
-
-**output: `bool`**
-
-**description:**
-
-Boolean false constant.
-
-**example:**
-
-```
-(and true false) ;; Evaluates to false
-(or false true) ;; Evaluates to true
-```
-
-### is-in-mainnet
-
-Introduced in: Clarity 2
-
-**output: `bool`**
-
-**description:**
-
-Returns a boolean indicating whether or not the code is running on the mainnet
-
-**example:**
-
-```
-(print is-in-mainnet) ;; Will print 'true' if the code is running on the mainnet
-```
-
-### is-in-regtest
-
-Introduced in: Clarity 1
-
-**output: `bool`**
-
-**description:**
-
-Returns whether or not the code is running in a regression test
-
-**example:**
-
-```
-(print is-in-regtest) ;; Will print 'true' if the code is running in a regression test
-```
-
-### none
-
-Introduced in: Clarity 1
-
-**output: `(optional ?)`**
-
-**description:**
-
-Represents the _none_ option indicating no value for a given optional (analogous to a null value).
-
-**example:**
-
-```
-(define-public (only-if-positive (a int))
- (if (> a 0)
- (some a)
- none))
-(only-if-positive 4) ;; Returns (some 4)
-(only-if-positive (- 3)) ;; Returns none
-```
-
-```
-(print stx-liquid-supply) ;; Will print out the total number of liqui
-```
-
-### **stacks-block-height**
-
-Introduced in: Clarity 3
-
-**output: `uint`**
-
-**description:**
-
-Returns the current Stacks block height.
-
-**example:**
-
-```
-(print stacks-block-height) ;; Will print out the current Stacks block height
-```
-
-### stx-liquid-supply
-
-Introduced in: Clarity 1
-
-**output: `uint`**
-
-**description:**
-
-Returns the total number of micro-STX (uSTX) that are liquid in the system as of this block.
-
-**example:**
-
-```
-(print stx-liquid-supply) ;; Will print out the total number of liquid uSTX
-```
-
-### **tenure-height**
-
-Introduced in: Clarity 3
-
-**output: `uint`**
-
-**description:**
-
-Returns the number of tenures that have passed. When the Nakamoto block-processing starts, this will be equal to the chain length.
-
-**example:**
-
-```
-(print tenure-height) ;; Will print out the current tenure height
-```
-
-### true
-
-Introduced in: Clarity 1
-
-**output: `bool`**
-
-**description:**
-
-Boolean true constant.
-
-**example:**
-
-```
-(and true false) ;; Evaluates to false
-(or false true) ;; Evaluates to true
-```
-
-### tx-sender
-
-Introduced in: Clarity 1
-
-**output: `principal`**
-
-**description:**
-
-Returns the original sender of the current transaction, or if `as-contract` was called to modify the sending context, it returns that contract principal.
-
-**example:**
-
-```
-(print tx-sender) ;; Will print out a Stacks address of the transaction sender
-```
-
-{% hint style="warning" %}
-Use caution when leveraging all contract calls, particularly tx-sender and contract-caller as based on the design, you can unintentionally introduce attack surface area. [Read more](https://www.setzeus.com/community-blog-posts/clarity-carefully-tx-sender).
-{% endhint %}
-
-
-
-### tx-sponsor?
-
-Introduced in: Clarity 2
-
-**output: `optional principal`**
-
-**description:**
-
-Returns the sponsor of the current transaction if there is a sponsor, otherwise returns None.
-
-**example:**
-
-```
-(print tx-sponsor?) ;; Will print out an optional value containing the Stacks address of the transaction sponsor
-```
diff --git a/reference/sample-configuration-files.md b/reference/sample-configuration-files.md
deleted file mode 100644
index f498e8637e..0000000000
--- a/reference/sample-configuration-files.md
+++ /dev/null
@@ -1,235 +0,0 @@
-# Signer Configuration
-
-{% hint style="info" %}
-Note that in this version, the Stacks node will not boot if it sees config values that are unused. If your node is not booting, be sure to check your logs for any messages indicating
-{% endhint %}
-
-### Signer Configuration File Options
-
-The signer configuration file is a TOML file that contains the configuration options for your signer. Below are the options you can set in the signer configuration file.
-
-| Name | Required | Description |
-| ---------------------------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| node\_host | ✓ | IP:PORT where your Stacks node can be accessed. The port 20443 is the default RPC endpoint for Stacks nodes. Note that you must use an IP address - DNS hosts are not supported at this time. |
-| endpoint | ✓ | IP:PORT where the signer will expose an RPC endpoint for receiving events from your Stacks node. |
-| stacks\_private\_key | ✓ | Hex representation of the signer's Stacks private key used for communicating with the Stacks Node, including writing to the Stacker DB instance. |
-| network | ✓ | Network to use. One of "mainnet", "testnet" or "mocknet". |
-| auth\_password | ✓ | Authorization token for HTTP requests made from the signer to your Stacks node. |
-| db\_path | ✓ | Path to the signer's database file |
-| block\_proposal\_timeout\_ms | | Specifies the maximum time (in milliseconds) a signer waits after a Bitcoin block for a miner to produce their first Nakamoto block. If the miner exceeds this time, the signer marks their tenure as invalid and rejects subsequent block proposals. Default value of 600\_000 (10 minutes). |
-| metrics\_endpoint | | IP:PORT for Prometheus metrics collection. |
-| chain\_id | | An optional ChainID, only used for custom networks (like Nakamoto Testnet) |
-
-### Example Configs
-
-Below are sample configuration files for running a Stacks node and signer provided in one place for convenience. You'll need to modify some of these according to the [How to Run a Signer](../guides-and-tutorials/running-a-signer/) doc.
-
-### Testnet Signer
-
-```toml
-# The IP address and port where your Stacks node can be accessed.
-# The port 20443 is the default RPC endpoint for Stacks nodes.
-# Note that you must use an IP address - DNS hosts are not supported at this time.
-# This should be the IP address accessible via Docker, usually via a network.
-node_host = "127.0.0.1:20443"
-
-# This is the location where the signer will expose an RPC endpoint for
-# receiving events from your Stacks node.
-endpoint = "127.0.0.1:30000"
-
-# Either “testnet” or “mainnet”
-network = "testnet"
-
-# this is a file path where your signer will persist data. If using Docker,
-# this must be within a volume, so that data can be persisted across restarts
-db_path = "/var/stacks/signer.sqlite"
-
-# an authentication token that is used for some HTTP requests made from the
-# signer to your Stacks node. You’ll need to use this later on when configuring
-# your Stacks node. You create this field yourself, rather than it being generated
-# with your private key.
-auth_password = "$your_http_auth_token"
-
-# This is the privateKey field from the keys you generated in the
-# previous step.
-stacks_private_key = "$your_stacks_private_key"
-```
-
-### Stacks Node Testnet Config
-
-{% hint style="warning" %}
-Note that the `block_proposal_token` field has changed to `auth_token` in the Stacks node configuration file.
-{% endhint %}
-
-This is the configuration you'll need to run a Stacks follower node if you are also running a signer. Be sure to change the commented lines to the appropriate data for your setup. If you are not familiar with the process of setting up a signer, be sure to follow the [How to Run a Signer](../guides-and-tutorials/running-a-signer/) guide.
-
-An overview of all Stacks node configuration options can be found in the [Stacks Node Configuration](stacks-node-configuration.md) doc.
-
-Additions necessary specifically to run a signer are the `[connection_options]` and `[[events_observer]]` sections and the `stacker = true` line. There are also a few comments detailing other lines that need to change.
-
-```toml
-[node]
-
-rpc_bind = "0.0.0.0:20443"
-p2p_bind = "0.0.0.0:20444"
-bootstrap_node = "029266faff4c8e0ca4f934f34996a96af481df94a89b0c9bd515f3536a95682ddc@seed.testnet.hiro.so:30444"
-prometheus_bind = "127.0.0.1:9153"
-working_dir = "/hirosystems/data"
-local_peer_seed = "{{ redacted }}"
-# Required for nodes attached to signers, optional for other nodes
-stacker = true
-
-[burnchain]
-chain = "bitcoin"
-mode = "krypton"
-peer_host = "bitcoin.regtest.hiro.so"
-peer_port = 18444
-pox_prepare_length = 100
-pox_reward_length = 900
-
-# Set your auth token, which the signer uses
-# This should match the auth_password field of your signer config
-[connection_options]
-auth_token = "12345"
-
-# Set your signer as an event observer
-[[events_observer]]
-# This endpoint is where your signer will communicate with your Stacks node
-endpoint = "127.0.0.1:30000"
-events_keys = ["stackerdb", "block_proposal", "burn_blocks"]
-
-[[ustx_balance]]
-address = "ST2QKZ4FKHAH1NQKYKYAYZPY440FEPK7GZ1R5HBP2"
-amount = 10000000000000000
-
-[[ustx_balance]]
-address = "ST319CF5WV77KYR1H3GT0GZ7B8Q4AQPY42ETP1VPF"
-amount = 10000000000000000
-
-[[ustx_balance]]
-address = "ST221Z6TDTC5E0BYR2V624Q2ST6R0Q71T78WTAX6H"
-amount = 10000000000000000
-
-[[ustx_balance]]
-address = "ST2TFVBMRPS5SSNP98DQKQ5JNB2B6NZM91C4K3P7B"
-amount = 10000000000000000
-
-[fee_estimation]
-fee_estimator = "fuzzed_weighted_median_fee_rate"
-
-[[burnchain.epochs]]
-epoch_name = "1.0"
-start_height = 0
-
-[[burnchain.epochs]]
-epoch_name = "2.0"
-start_height = 0
-
-[[burnchain.epochs]]
-epoch_name = "2.05"
-start_height = 1
-
-[[burnchain.epochs]]
-epoch_name = "2.1"
-start_height = 2
-
-[[burnchain.epochs]]
-epoch_name = "2.2"
-start_height = 3
-
-[[burnchain.epochs]]
-epoch_name = "2.3"
-start_height = 4
-
-[[burnchain.epochs]]
-epoch_name = "2.4"
-start_height = 5
-
-[[burnchain.epochs]]
-epoch_name = "2.5"
-start_height = 6
-
-[[burnchain.epochs]]
-epoch_name = "3.0"
-start_height = 1_900
-
-[[burnchain.epochs]]
-epoch_name = "3.1"
-start_height = 2_000
-
-[[burnchain.epochs]]
-epoch_name = "3.2"
-start_height = 71_525
-```
-
-### Mainnet Signer
-
-This config is very similar to the testnet config, except the `network` field is changed.
-
-```toml
-# The IP address and port where your Stacks node can be accessed.
-# The port 20443 is the default RPC endpoint for Stacks nodes.
-# Note that you must use an IP address - DNS hosts are not supported at this time.
-# This should be the IP address accessible via Docker, usually via a network.
-node_host = "127.0.0.1:20443"
-
-# This is the location where the signer will expose an RPC endpoint for
-# receiving events from your Stacks node.
-endpoint = "127.0.0.1:30000"
-
-# Either “testnet” or “mainnet”
-network = "mainnet"
-
-# this is a file path where your signer will persist data. If using Docker,
-# this must be within a volume, so that data can be persisted across restarts
-db_path = "/var/stacks/signer.sqlite"
-
-# an authentication token that is used for some HTTP requests made from the
-# signer to your Stacks node. You’ll need to use this later on when configuring
-# your Stacks node. You create this field yourself, rather than it being generated
-# with your private key.
-auth_password = "$your_http_auth_token"
-
-# This is the privateKey field from the keys you generated in the
-# previous step.
-stacks_private_key = "$your_stacks_private_key"
-
-# The IP address and port where prometheus metrics can be accessed.
-metrics_endpoint = "127.0.0.1:9154"
-
-# Determining when a time-based tenure extend will be accepted
-tenure_idle_timeout_secs = 120
-```
-
-### Mainnet Stacks Node
-
-With a mainnet Stacks node config, you'll need to change the bootstrap node field and the burnchain fields. Other than that, the `ustx_balance` fields are not necessary.
-
-```toml
-[node]
-# Set this based on where you downloaded
-# the chain state archive as described in the How to Run a Signer guide:
-working_dir = "/data-dir-somewhere"
-rpc_bind = "0.0.0.0:20443"
-p2p_bind = "0.0.0.0:20444"
-# This is the node that your node will use to begin syncing chain state
-bootstrap_node = "02196f005965cebe6ddc3901b7b1cc1aa7a88f305bb8c5893456b8f9a605923893@seed.mainnet.hiro.so:20444,02539449ad94e6e6392d8c1deb2b4e61f80ae2a18964349bc14336d8b903c46a8c@cet.stacksnodes.org:20444,02ececc8ce79b8adf813f13a0255f8ae58d4357309ba0cedd523d9f1a306fcfb79@sgt.stacksnodes.org:20444,0303144ba518fe7a0fb56a8a7d488f950307a4330f146e1e1458fc63fb33defe96@est.stacksnodes.org:20444"
-# Required for nodes attached to signers, optional for other nodes
-stacker = true
-
-[burnchain]
-chain = "bitcoin"
-mode = "mainnet"
-peer_host = "bitcoin.mainnet.stacks.org"
-
-# Set your auth token, which the signer uses
-# This should match the auth_password field of your signer config
-[connection_options]
-auth_token = "12345"
-
-# Set your signer as an event observer
-[[events_observer]]
-# This endpoint is where your signer will communicate with your Stacks node
-endpoint = "127.0.0.1:30000"
-events_keys = ["stackerdb", "block_proposal", "burn_blocks"]
-```
diff --git a/reference/stacks-node-configuration.md b/reference/stacks-node-configuration.md
deleted file mode 100644
index 6d2c2fdebf..0000000000
--- a/reference/stacks-node-configuration.md
+++ /dev/null
@@ -1,231 +0,0 @@
-# Stacks Node Configuration
-
-{% hint style="info" %}
-Note that these config fields are for a Stacks follower node. If you are running a signer alongside your Stacks node, you'll want to use the sample file found on the [Signer Configuration](sample-configuration-files.md) page as it contains additional parameters needed for your signer and Stacks node to function properly.
-{% endhint %}
-
-### Usage
-
-```bash
-stacks-node sub-command [--subcommand-option ]
-```
-
-#### Subcommands
-
-* `mocknet`: start a mocknet instance using defaults
-* `testnet`: start a testnet instance using defaults (chainstate is not persistent)
-* `mainnet`: start a mainnet instance using defaults (chainstate is not persistent)
-* `start`: combined with `--config`, starts an instance with a specified configuration file
-* `version`: displays binary version
-* `help`: displays the help message
-
-### Configuration File Options
-
-The Stacks Blockchain configuration file has multiple sections under which an option may be placed.
-
-* node
-* events\_observer
-* connection\_options
-* burnchain
-* ustx\_balance
-* miner
-
-For reference, several configuration file examples are [available here](https://github.com/stacks-network/stacks-core/tree/master/sample/conf).
-
-#### node
-
-Contains various configuration options for the stacks-node binary.
-
-| Name | Required | Description |
-| ---------------------------- | -------- | ---------------------------------------------------------------------------------------------------------- |
-| rpc\_bind | ✓ | IPv4 address and port to open for RPC connections |
-| p2p\_bind | ✓ | IPv4 address and port to open for P2P connections |
-| working\_dir | | Absolute path to the directory where chainstate data will be stored |
-| data\_url | | IPv4 address and port for incoming RPC connections |
-| p2p\_address | | IPv4 address and port for incoming P2P connections |
-| bootstrap\_node | | Public key, IPv4 address, and port to bootstrap the chainstate |
-| wait\_time\_for\_microblocks | | The amount of time in ms to wait before trying to mine a block after catching up to the anchored chain tip |
-| seed | | The private key to use for mining. Only needed if `miner` is set to `true` |
-| local\_peer\_seed | | The private key to use for signing P2P messages in the networking stack |
-| miner | | Determines whether the node is running a follower (`false`) or a miner (`true`). Defaults to `false` |
-| mock\_mining | | Simulates running a miner (typically used for debugging) |
-| mock\_mining\_output\_dir | | Folder for mock mining data |
-| mine\_microblocks | | Determines whether the node will mine microblocks. Will only take effect if `miner` is set to `true` |
-| prometheus\_bind | | Address and port for Prometheus metrics collection. |
-| deny\_nodes | | List of ip addresses of nodes that should be ignored |
-| stacker | | Determines whether the node is running a stacker (`true`) that issues events for signer binary |
-
-#### events\_observer
-
-{% hint style="info" %}
-This section is _optional_ and not required
-
-However, if this section is added, **all** fields are required.
-{% endhint %}
-
-Contains options for sending events emitted to the [stacks-blockchain-api](https://github.com/hirosystems/stacks-blockchain-api) service.
-
-| Name | Required | Description |
-| ------------ | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| endpoint | ✓ | Address and port to a [stacks-blockchain-api](https://github.com/hirosystems/stacks-blockchain-api) service |
-| events\_keys | ✓ | Event keys for which to watch. The emitted node events can be restricted by account, function name and event type. Asterix ("\*") can be used to emit all events. |
-
-#### connection\_options
-
-{% hint style="info" %}
-This section is _optional_ and not required.
-{% endhint %}
-
-Specifies configuration options for others connecting to the stacks node.
-
-| Name | Required | Description |
-| ------------------------------------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| public\_ip\_address | | Public IPv4 to advertise to other nodes |
-| download\_interval | | Time (in seconds) between attempts to download blocks |
-| walk\_interval | | Time (in seconds) between attempts to walk the list of neighbors |
-| private\_neighbors | | If false, this node won't announce or accept neighbors that are behind private networks. Defaults to true. |
-| read\_only\_call\_limit\_read\_length | | Total number of bytes allowed to be read by an individual read-only function call |
-| read\_only\_call\_limit\_read\_count | | Total number of independent read operations permitted for an individual read-only function call |
-| read\_only\_call\_limit\_runtime | | [Runtime cost](https://github.com/stacksgov/sips/blob/main/sips/sip-006/sip-006-runtime-cost-assessment.md) limit for an individual read-only function call |
-
-#### burnchain
-
-This section contains configuration options pertaining to the blockchain the stacks-node binds to on the backend for proof-of-transfer (BTC).
-
-| Name | Required | Description |
-| ---------- | -------- | --------------------------------------------------------------------------------------------------------------------- |
-| chain | ✓ | The blockchain stacks-node binds to on the backend for proof-of-transfer. Only value supported: `bitcoin` |
-| mode | ✓ | The profile or test phase of which to run stacks-node. Valid values are \[ `mocknet`, `testnet`, `xenon`, `mainnet` ] |
-| peer\_host | | FQDN of the host running the backend Bitcoin blockchain |
-| rpc\_port | | RPC port of `peer_host` |
-| peer\_port | | P2P port of `peer_host` |
-
-**Mining**
-
-| Name | Required | Description |
-| -------------------------------- | -------- | -------------------------------------------------------------------------------------------------- |
-| burn\_fee\_cap | ✓ | Maximum amount (in sats) of "burn commitment" to broadcast for the next block's leader election |
-| satoshis\_per\_byte | ✓ | [Amount (in sats) per byte](https://bitcoinfees.net/) - Used to calculate the transaction fees |
-| commit\_anchor\_block\_within | | Sets the time period (in milliseconds) for commitments. Only used when `mode` is set to `mocknet`. |
-| tenure\_extend\_cost\_threshold | | Percentage of block budget that must be used before attempting a time-based tenure extend |
-| block\_rejection\_timeout\_steps | | Define the timeout to apply while waiting for signers responses, based on the amount of rejections |
-
-#### ustx\_balance
-
-{% hint style="info" %}
-This section is only required for the `testnet` and `mocknet` networks.
-
-However, if this section is added, **all** fields are required.
-{% endhint %}
-
-This section contains configuration options allocating microSTX per address in the genesis block
-
-This section can repeat multiple times, but each section can only define a single address.
-
-| Name | Required | Description |
-| ------- | -------- | --------------------------------------------------------------------- |
-| address | ✓ | Address which maintains a microSTX balance |
-| amount | ✓ | The balance of microSTX given to the address at the start of the node |
-
-### Example Mainnet Follower Configuration
-
-```toml
-[node]
-working_dir = "/stacks-blockchain"
-rpc_bind = "0.0.0.0:30443"
-p2p_bind = "0.0.0.0:20444"
-bootstrap_node = "02196f005965cebe6ddc3901b7b1cc1aa7a88f305bb8c5893456b8f9a605923893@seed.mainnet.hiro.so:20444,02539449ad94e6e6392d8c1deb2b4e61f80ae2a18964349bc14336d8b903c46a8c@cet.stacksnodes.org:20444,02ececc8ce79b8adf813f13a0255f8ae58d4357309ba0cedd523d9f1a306fcfb79@sgt.stacksnodes.org:20444,0303144ba518fe7a0fb56a8a7d488f950307a4330f146e1e1458fc63fb33defe96@est.stacksnodes.org:20444"
-
-[burnchain]
-chain = "bitcoin"
-mode = "mainnet"
-peer_host = "localhost"
-peer_port = 8333
-
-[[events_observer]]
-endpoint = "localhost:3700"
-events_keys = ["*"]
-```
-
-### Example Testnet Follower Configuration
-
-```toml
-[node]
-
-rpc_bind = "0.0.0.0:20443"
-p2p_bind = "0.0.0.0:20444"
-bootstrap_node = "029266faff4c8e0ca4f934f34996a96af481df94a89b0c9bd515f3536a95682ddc@seed.testnet.hiro.so:30444"
-prometheus_bind = "127.0.0.1:9153"
-working_dir = "/stacks-blockchain"
-
-[burnchain]
-chain = "bitcoin"
-mode = "krypton"
-peer_host = "bitcoin.regtest.hiro.so"
-peer_port = 18444
-pox_prepare_length = 100
-pox_reward_length = 900
-
-[[ustx_balance]]
-address = "ST2QKZ4FKHAH1NQKYKYAYZPY440FEPK7GZ1R5HBP2"
-amount = 10000000000000000
-
-[[ustx_balance]]
-address = "ST319CF5WV77KYR1H3GT0GZ7B8Q4AQPY42ETP1VPF"
-amount = 10000000000000000
-
-[[ustx_balance]]
-address = "ST221Z6TDTC5E0BYR2V624Q2ST6R0Q71T78WTAX6H"
-amount = 10000000000000000
-
-[[ustx_balance]]
-address = "ST2TFVBMRPS5SSNP98DQKQ5JNB2B6NZM91C4K3P7B"
-amount = 10000000000000000
-
-[fee_estimation]
-fee_estimator = "fuzzed_weighted_median_fee_rate"
-
-[[burnchain.epochs]]
-epoch_name = "1.0"
-start_height = 0
-
-[[burnchain.epochs]]
-epoch_name = "2.0"
-start_height = 0
-
-[[burnchain.epochs]]
-epoch_name = "2.05"
-start_height = 1
-
-[[burnchain.epochs]]
-epoch_name = "2.1"
-start_height = 2
-
-[[burnchain.epochs]]
-epoch_name = "2.2"
-start_height = 3
-
-[[burnchain.epochs]]
-epoch_name = "2.3"
-start_height = 4
-
-[[burnchain.epochs]]
-epoch_name = "2.4"
-start_height = 5
-
-[[burnchain.epochs]]
-epoch_name = "2.5"
-start_height = 6
-
-[[burnchain.epochs]]
-epoch_name = "3.0"
-start_height = 1_900
-
-[[burnchain.epochs]]
-epoch_name = "3.1"
-start_height = 2_000
-
-[[burnchain.epochs]]
-epoch_name = "3.2"
-start_height = 71_525
-```
diff --git a/reference/the-stack.md b/reference/the-stack.md
deleted file mode 100644
index 80a45bd8e1..0000000000
--- a/reference/the-stack.md
+++ /dev/null
@@ -1,97 +0,0 @@
-# Stacks Tooling
-
-New to developing on Stacks or looking for a quick reference guide for all the important components and links? You're in the right place.
-
-We'll go over all the building blocks you need to be aware of to build high-quality Stacks dapps. This page exists to serve as a reference to the Stacks developer's tool chest. In addition to the tools below, stacks.co houses an index of [apps, services, and other integrations available on Stacks](https://www.stacks.co/explore/ecosystem?category=All+Teams#tools).
-
-### Building Blocks
-
-#### Clarity
-
-[Clarity](broken-reference) is the smart contract language on Stacks. If you want to build the next decentralized social network, DeFi protocol, or any other Stacks dapp, you'll need to know Clarity.
-
-#### Post Conditions
-
-[Post conditions](the-stack.md#post-conditions) are a cool feature of the Stacks blockchain that allow you to verify the legitimacy of a transaction on the client side before it is executed. This adds an additional layer of defense against malicious smart contracts.
-
-#### Proof of Transfer
-
-[PoX](../concepts/stacks-101/proof-of-transfer.md) is the unique consensus mechanism of Stacks that facilitates new block production and also allows Stackers to earn real Bitcoin yield by participating in locking their STX tokens.
-
-#### Stacking
-
-Speaking of [Stacking](../concepts/block-production/stacking.md), it's the mechanism that helps to secure the Stacks chain and allows Stackers to earn real Bitcoin yield transferred by miners.
-
-#### SIP-009 and SIP-010 Tokens
-
-Fungible and non-fungible tokens in Clarity are defined by [SIP-009](../) and [SIP-010](https://github.com/stacksgov/sips/blob/main/sips/sip-010/sip-010-fungible-token-standard.md) standards. You can learn more about how to work with these tokens in the Clarity book.
-
-### Tools
-
-#### Wallets
-
-Wallets are a key tool in any web3 ecosystem, and Stacks is no different. There are several options available including:
-
-* [Leather](https://leather.io/)
-* [Xverse](https://www.xverse.app/)
-* [Asigna](https://asigna.io/)
-
-#### Platform
-
-The [Hiro Platform](https://www.hiro.so/platform) is your all-in-one cloud development environment for Stacks development, and is integrated with most of the tools listed below.
-
-It's by far the easiest way to get up and running quickly. Plus, they have SSH integration
-
-#### Explorer
-
-Every developer needs a block explorer to see take a look at information about blocks and transactions being submitted to the chain. You have two choices here: the [Hiro Explorer](https://explorer.hiro.so/) and [STXScan](https://stxscan.co/).
-
-#### API
-
-If you want to interact with or read data from the chain, there's a good chance the [Hiro API](https://docs.hiro.so/stacks-blockchain-api) has an endpoint for that.
-
-#### Stacks.js
-
-[Stacks.js](https://www.hiro.so/stacks-js) is the de-facto JavaScript library for the Stacks ecosystem. There are several packages here that will help you build robust frontends for your applications.
-
-#### Clarinet
-
-All good developer tooling needs a robust, easy-to-use development environment. Enter [Clarinet](https://www.hiro.so/clarinet). Clarinet provides everything you need to write, test, and deploy Clarity smart contracts, including a fully-featured local devnet blockchain.
-
-#### Chainhook
-
-One of the key use cases for Stacks is being able to directly interact with the Bitcoin chain. Hiro's [Chainhook](https://docs.hiro.so/chainhook) makes this easier by providing an IFTTT system for responding and reacting to events on both the Bitcoin and Stacks chains.
-
-#### Stacking Tools
-
-The Degen Lab team has created a [suite of tools](https://stacking.tools/) to make stacking significantly easier including a signer signature generator, a solo stacking dapp to stack without needing to run a signer, and a TypeScript library for mocking stacking functions.
-
-#### Oracles and Price Feeds
-
-DIA and Pyth provide oracle services for the Stacks layer. Find [documentation for DIA here](https://docs.diadata.org/use-nexus-product/nexus/data-delivery-usage/integrated-blockchains/stacks-price-oracles) and learn more about the [developer release of Pyth here](https://www.pyth.network/blog/developer-release-pyth-on-stacks).
-
-### Educational Resources
-
-#### Docs
-
-These docs you are currently looking at are a great place to get a comprehensive view of all things in the Stacks ecosystem, as well as providing some links out to additional resources you'll find helpful.
-
-#### Hiro Docs
-
-Hiro is a key player in the Stacks ecosystem, providing several developer tools to make your life easier. They also publish excellent [guides and docs](https://docs.hiro.so/) to make using these tools a breeze.
-
-#### Clarity Book
-
-The [Clarity Book](https://book.clarity-lang.org/) is the go-to resource for learning how to be a Clarity developer. In it you'll not only get the basics of Clarity but go through several practice projects and learn best practices.
-
-#### LearnWeb3
-
-LearnWeb3 is one of the best education providers in the game. They have recently begun publishing courses as part of their [Stacks Developer Degree](https://learnweb3.io/degrees/stacks-developer-degree/). LearnWeb3 courses will teach you everything you need to know about building Stacks Dapps.
-
-#### EasyA
-
-[EasyA](https://www.easya.io/) is a mobile app with a Stacks course built in. The EasyA app allows you to learn on the go and is a great way to learn the basics of Stacks and Clarity development all directly in their app.
-
-#### Bitcoin Primer
-
-If you're new to Bitcoin, interested in how it works, and how you can build Stacks dapps that interact with it, the [Bitcoin Primer](https://start.bitcoinprimer.dev/) is a great place to start.
diff --git a/reference/types.md b/reference/types.md
deleted file mode 100644
index e45502243e..0000000000
--- a/reference/types.md
+++ /dev/null
@@ -1,19 +0,0 @@
-# Types
-
-### Clarity Type System
-
-The type system contains the following types:
-
-| Types | Notes |
-| ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| `int` | signed 128-bit integer |
-| `uint` | unsigned 128-bit integer |
-| `bool` | boolean value (`true` or `false`) |
-| `principal` | object representing a principal (whether a contract principal or standard principal) |
-| `(buff max-len)` | byte buffer of maximum length `max-len`. |
-| `(string-ascii max-len)` | ASCII string of maximum length `max-len` |
-| `(string-utf8 max-len)` | UTF-8 string of maximum length `max-len` (u"A smiley face emoji \u{1F600} as a utf8 string") |
-| `(list max-len entry-type)` | list of maximum length `max-len`, with entries of type `entry-type` |
-| `{label-0: value-type-0, label-1: value-type-1, ...}` | tuple, group of data values with named fields |
-| `(optional some-type)` | an option type for objects that can either be `(some value)` or `none` |
-| `(response ok-type err-type)` | object used by public functions to commit their changes or abort. May be returned or used by other functions as well, however, only public functions have the commit/abort behavior. |