Fixed typos

README.md

@@ -21,7 +21,7 @@ Why Bitcoin? Bitcoin is the most durable and secure blockchain. Bitcoin is minim
 
 Bitcoin's Stacks layer makes BTC productive in two ways:
 - Stacks consensus enables a trust-minimized Bitcoin peg mechanism, called sBTC. A dynamic group of economically incentivized actors operate the peg. See the [sBTC page](https://stacks.co/sbtc) for more details.
-- Further, through atomic swaps BTC can be trustlessly swaped and deployed into DeFi applications, NFT marketplaces etc. For example, see [Magic BTC atomic swaps](https://magic.fun) and [Catamaran BTC atomic swaps](https://www.hiro.so/blog/bitcoin-defi-is-here-a-deep-dive-into-trust-less-swaps), and [Lightning swaps](https://lnswap.org). 
+- Further, through atomic swaps BTC can be trustlessly swapped and deployed into DeFi applications, NFT marketplaces etc. For example, see [Magic BTC atomic swaps](https://magic.fun) and [Catamaran BTC atomic swaps](https://www.hiro.so/blog/bitcoin-defi-is-here-a-deep-dive-into-trust-less-swaps), and [Lightning swaps](https://lnswap.org). 
 
 You can see some applications built using Stacks [here](https://www.stacks.co/explore/discover-apps).
 
@@ -37,7 +37,7 @@ For details, see the [Clarity book](https://book.clarity-lang.org/) and [Clarity
 
 ## Proof-of-Transfer (PoX)
 
-[PoX consensus](https://blockstack.org/pox.pdf) is a new algorithm that spans consensus between the Bitcoin blockchain and the Stacks layer. Unlike burning electricity in proof-of-work, miners bid by spending BTC and get a random probability for becoming a leader. Leader election happens on Bitcoin and new blocks are written on the Stacks layer. Miners use BTC to mine newly minted STX. PoX recyles proof-of-work energy to provide Nakamoto-style consensus for the Stacks layer. 
+[PoX consensus](https://blockstack.org/pox.pdf) is a new algorithm that spans consensus between the Bitcoin blockchain and the Stacks layer. Unlike burning electricity in proof-of-work, miners bid by spending BTC and get a random probability for becoming a leader. Leader election happens on Bitcoin and new blocks are written on the Stacks layer. Miners use BTC to mine newly minted STX. PoX recycles proof-of-work energy to provide Nakamoto-style consensus for the Stacks layer. 
 
 See [this post](https://medium.com/@sonkaos999/the-bullish-case-for-stacks-8ef75849861f) on PoX for more details.
 

sBTC/clarity_vm.md

@@ -41,7 +41,7 @@ The plan to speed up the Clarity VM is to compile Clarity contracts into [WebAss
 
 The new compiler and runtime must execute all valid [Clarity](https://clarity-lang.org/) code, including all contracts currently supported by the existing runtime. If any changes are made to [Clarity](https://clarity-lang.org/) to simplify or improve the implementation, this runtime will be epoch gated (versioned), and the old runtime will be used before activation at a future block height.
 
-The [Stacks Blockchain](https://github.com/stacks-network/stacks-blockchain) will also need to efficiently store the compiled [Wasm](<(https://webassembly.org/)>) code alongside the [Clarity](https://clarity-lang.org/) source for all published contracts and willl need to retrieve it quickly when a contract is called. The stored [Wasm](https://webassembly.org/) will also need to be accessible via RPC calls for verification and debugging purposes.
+The [Stacks Blockchain](https://github.com/stacks-network/stacks-blockchain) will also need to efficiently store the compiled [Wasm](<(https://webassembly.org/)>) code alongside the [Clarity](https://clarity-lang.org/) source for all published contracts and will need to retrieve it quickly when a contract is called. The stored [Wasm](https://webassembly.org/) will also need to be accessible via RPC calls for verification and debugging purposes.
 
 The runtime needs to establish a mechanism to interact with the MARF using Clarity's native functions for reading/writing data-vars and maps.
 

sBTC/nakamoto.md

@@ -78,7 +78,7 @@ For a block to be validated, it must be signed by over 67% of the producer set b
 
 Each producer set term is 10 Bitcoin blocks in length. Stacks cost limits are applied to the term as a whole rather than individual Stacks blocks, and each term's cost limit is 10x the Stacks 2.4 single block limit (or the single block limit after improvements to the Clarity runtime and improved benchmark results).
 
-During a term, there is no distinction between Stacks blocks and microblocks: there are only blocks. Terms are not limited to 10 Stacks blocks (i.e., there may be more than one Stacks block produced during a given Bitcoin block), but rather the only limit applied to the term is the overall cost limit (which may be increased through application of a VDF to accomodate an unusually long term length; see [Extension: Overdue Term](./nakamoto/extensions/overdue_term.md)).
+During a term, there is no distinction between Stacks blocks and microblocks: there are only blocks. Terms are not limited to 10 Stacks blocks (i.e., there may be more than one Stacks block produced during a given Bitcoin block), but rather the only limit applied to the term is the overall cost limit (which may be increased through application of a VDF to accommodate an unusually long term length; see [Extension: Overdue Term](./nakamoto/extensions/overdue_term.md)).
 
 The first block of a term always builds off the last block stackers accepted from the prior term, which itself is a descendant of the last on-Bitcoin snapshot. Producers may not choose to reorganize a prior term, nor may they reorganize any stacker-accepted blocks. But, any unannounced or not-yet-accepted blocks from the prior term are dropped.
 

sBTC/nakamoto/block_signing_announcement.md

@@ -110,7 +110,7 @@ The `.block-producers` contract defines a Stacker DB with 300 slots. The first 1
 
 The number of DB signer slots are assigned to a producer represents the weight of the producer's signature. For example, if four producers each registered for tenure N, and each spent 10%, 20%, 30%, and 40% of the BTC, then the 10% producer would receive 10 slots, the 20% producer would receive 20 slots, the 30% 30 slots, and the 40% 40 slots. The 10% producer receives DB slots `0, 10, 20, 30, 40, 50, 60, 70, 80, ... 180, 190`; the 20% producer receives DB slots `1, 2, 11, 12, 21, 22, ..., 191, 192`; the 30% producer receives DB slots `3, 4, 5, 13, 14, 15, 23, 24, 25, ..., 193, 194, 195`; the 40% producer receives DB slots `6, 7, 8, 9, 16, 17, 18, 19, ..., 196, 197, 198, 199`. The `.block-producers` contract's `stackerdb-auth-write` function ensures that each producer can only write to their assigned slots; the requisite state for doing so is directly written into the contract's data space at the start of each tenure, which this function queries.
 
-The proposed block slots are alloted to producers in ascending order by BTC weight. In the above example, slot 200 is alloted to the 10% producer, slot 201 to the 20% producer, slot 202 to the 30% producer, and slot 203 to the 40% producer. If there are fewer than 100 producers, then the remaining slots are unused.
+The proposed block slots are allotted to producers in ascending order by BTC weight. In the above example, slot 200 is allotted to the 10% producer, slot 201 to the 20% producer, slot 202 to the 30% producer, and slot 203 to the 40% producer. If there are fewer than 100 producers, then the remaining slots are unused.
 
 ### Producer Signing Protocol
 
@@ -122,7 +122,7 @@ The signed block is automatically propagated to stackers via the `.block-produce
 
 ### Stacker Signer DB Setup
 
-Like the `.block-producers` contract, the `.pox-4` contract maintains a set of DB slots for storing FROST pre-computed data and signature data. The stacker signer DB has 8,000 slots. The first 4,000 are allotted to stackers based on how many reward slots they earn. These slots are assigned to stackers in contiguous ranges, based on the order in which their STX were stacked for this reward cycle (i.e. as determined by the `.pox-4` contract's `reward-cycle-pox-address-list` map), and are used to hold each stackers' signers' FROST pre-computation state. The last 4,000 are similarly alloted to stackers, but are used to contain in-flight signature metadata regarding the proposed block.
+Like the `.block-producers` contract, the `.pox-4` contract maintains a set of DB slots for storing FROST pre-computed data and signature data. The stacker signer DB has 8,000 slots. The first 4,000 are allotted to stackers based on how many reward slots they earn. These slots are assigned to stackers in contiguous ranges, based on the order in which their STX were stacked for this reward cycle (i.e. as determined by the `.pox-4` contract's `reward-cycle-pox-address-list` map), and are used to hold each stackers' signers' FROST pre-computation state. The last 4,000 are similarly allotted to stackers, but are used to contain in-flight signature metadata regarding the proposed block.
 
 ### Stacker Signing Protocol
 

sBTC/nakamoto/extensions/overdue_term.md

@@ -2,7 +2,7 @@
 
 > This extension suggests the implementation of a replicated verifiable delay function (VDF) to manage variations in tenure length within the Stacks blockchain. Block producers execute the VDF and submit proofs to increase their tenure's execution budget in case it takes longer than anticipated. VDF calibration adjusts the required ticks for a valid proof based on historical tenure data. Checkpoint blocks report the adjusted tick count, which is then recorded on-chain for reference by Clarity contracts. The primary objective is to eliminate idle time and enhance overall efficiency within the Stacks network.
 
-Naively, the execution budget available to block producers can be treated as equal to the number of Stacks blocks' budgets today, multipled by the tenure length. Ideally, block producers would produce blocks at a rate such that under network congestion, the tenure budget is completely consumed just as the tenure ends.
+Naively, the execution budget available to block producers can be treated as equal to the number of Stacks blocks' budgets today, multiplied by the tenure length. Ideally, block producers would produce blocks at a rate such that under network congestion, the tenure budget is completely consumed just as the tenure ends.
 
 It is very difficult in practice to realize this idealized block production schedule, because the length of a tenure has very high variance and is not known in advance. If the block producers reach their tenure budget before the tenure is over, then the Stacks network stalls, which significantly increases transaction latency and degrades the user experience.
 

sBTC/nakamoto/testing/stacks_block_storage_trait.md

@@ -4,7 +4,7 @@ API for committing processed Stacks blocks to storage.
 
 ## Dependencies
 
-- [Block and transaction defintions](./block_and_transaction_definitions.md)
+- [Block and transaction definitions](./block_and_transaction_definitions.md)
 
 ## Requirements
 

why-stx.md

@@ -11,7 +11,7 @@ The Stacks token (STX) is primarily meant to be used for two things (details in
 
 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 permissionsless system. The only way to have a decentralized mining process is through incentives. 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. 
 
-Simiarly, the way the decentralized BTC peg, called sBTC (see the [sBTC paper](https://stacks.co/sbtc.pdf)), is designed is that the group of signer 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.
+Similarly, the way the decentralized BTC peg, called sBTC (see the [sBTC paper](https://stacks.co/sbtc.pdf)), is designed is that the group of signer 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.
 
 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 with BTC in wallets and apps and pay gas fees in BTC. 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.