Typo corrections in documentation files (#402)

Co-authored-by: Derrek <[email protected]>

docs/docs/drafts/vision.md

@@ -28,25 +28,25 @@ When using Ethereum rollups, Ethereum becomes a co-processor to Bitcoin where th
 We see a staged approach to make use of the rollup PoW:
 
 - **Stage 1**: Dapps deployed on an EVM rollup can check the submitted PoW to the rollup and customize their interpretation. For example, a ordinals P2P exchange might want to pause their platform if insufficient PoW is attached to the rollup, Other dapps might ignore the PoW alltogether, making the model quite flexible.
-- **Stage 2**: Merged minig becomes a condition for a valid state transition of the rollup. Assuming that a rollup is launched on an L1 with smart contracts like Ethereum, the sequencer needs to ensure that at certain intervals a sufficient PoW is added. The rollup would be paused and its state could be invalidated through including the PoW as part of the fraud proofs (in optimistic rollups) and validity proofs (in zk rollups). Requiring PoW as part of a valid state transition for the rollup ensures that the state transition of the rollup on say Ethereum cannot settle without the explicit consent from Bitcoin miners.
-- **Stage 3**: Staking sequencers on Bitcoin and proving incorrect behavior through BitVM, one-time signatures, and other techniques ensures that sequencers are ecnomically incentivized on Bitcoin to correctly produce L2 blocks.
+- **Stage 2**: Merged mining becomes a condition for a valid state transition of the rollup. Assuming that a rollup is launched on an L1 with smart contracts like Ethereum, the sequencer needs to ensure that at certain intervals a sufficient PoW is added. The rollup would be paused and its state could be invalidated through including the PoW as part of the fraud proofs (in optimistic rollups) and validity proofs (in zk rollups). Requiring PoW as part of a valid state transition for the rollup ensures that the state transition of the rollup on say Ethereum cannot settle without the explicit consent from Bitcoin miners.
+- **Stage 3**: Staking sequencers on Bitcoin and proving incorrect behavior through BitVM, one-time signatures, and other techniques ensures that sequencers are economically incentivized on Bitcoin to correctly produce L2 blocks.
 - **Stage 4**: In the final stage, the rollup transitions to a fully zk-verified rollup that can then be verified by Bitcoin consensus without merged mining. We expect this to take about five years from now as it will require zk technology to mature and Bitcoin made capable of verifying zk proofs.
 
 :::info
 We will share a technical paper on optimistic sequenced merged mining detailing the technical protocol soon.
 :::
 
-:::note BOB Launch PLan
+:::note BOB Launch Plan
 BOB launches as an optimistic rollup using the OP Stack which may seem counterintuitive to the above goal of eventually being a ZK rollup. However, we see having full EVM compatibility and tooling a worthwhile trade-off to adopting zkEVM rollups. Moreover, we see promising progress around abstracting the entire EVM execution into higher level zkVM like Risc Zero. Executing entire rollup blocks in a zkVM requires no changes to the EVM while still allowing validity proof production that then can eventually be used for a Bitcoin-verified ZK rollup.
 
 We further will launch the merged mining option shortly after BOB will go live in the stage 1 option described above.
 :::
 
 ## Usable Decentralization
 
-Centralization is plaguing development on Bitcoin today. Due to Bitcoin's limited programmability, many applications building on Bitcoin, like the majority of Lightning wallets, are centralized as it allows for a better UX than their dencentralized counterparts.
+Centralization is plaguing development on Bitcoin today. Due to Bitcoin's limited programmability, many applications building on Bitcoin, like the majority of Lightning wallets, are centralized as it allows for a better UX than their decentralized counterparts.
 
-Lack of decentalized appliocations with great UX is a major issue that can be resolved by (1) allowing more epxressive smart contracts and piggy-backing off of the developments made on Ethereum and other L1 chains, and (2) ensuring that the EVM rollups are still secured by Bitcoin.
+Lack of decentralized applications with great UX is a major issue that can be resolved by (1) allowing more expressive smart contracts and piggy-backing off of the developments made on Ethereum and other L1 chains, and (2) ensuring that the EVM rollups are still secured by Bitcoin.
 
 ### Adoption Through UX
 
@@ -65,7 +65,7 @@ Lack of decentalized appliocations with great UX is a major issue that can be re
 - Complex programs like a BRC20 or Ordinals co-processor should be operated off-chain and its correct execution proven on-chain
 - Simple programs can be kept on-chain
 
-## Briding BTC, Ordinals, and BRC20s
+## Bridging BTC, Ordinals, and BRC20s
 
 We believe that in some cases, bridging BTC, Ordinals, and BRC20s to more chains with higher programmability than Bitcoin is required.
 

docs/docs/learn/builder-guides/local-development.md

@@ -80,7 +80,7 @@ bitcoin-cli -regtest -rpcwallet=alice generatetoaddress 101 $ADDRESS
 
 #### Wallet
 
-You can use `bitcoin-cli` to manage the wallet. However, if you prefer you a UI, you can use Bitcoin QT.
+You can use `bitcoin-cli` to manage the wallet. However, if you prefer a UI, you can use Bitcoin QT.
 
 Start Bitcoin QT (for wallet functionality):
 

docs/docs/learn/introduction/stack-overview.md

@@ -33,6 +33,6 @@ BOB provides trustless access to Bitcoin block and transactional data via a [BTC
 
 ### BOB SDK
 
-_A smart contract deveopers' universal toolkit for all things building on Bitcoin_
+_A smart contract developers' universal toolkit for all things building on Bitcoin_
 
 Similar to [OpenZeppelin](https://www.openzeppelin.com/) and other great Solidity libraries, BOB provides a powerful SDK for all things building on Bitcoin. This includes a wide range of Solidity contracts that can be used to interact with Bitcoin including core, [Ordinals](https://docs.ordinals.com/), [BRC20s](https://brc20.gitbook.io/brc20/overview/introduction), [Runes](https://rodarmor.com/blog/runes/), and [Lightning](https://lightning.network/), as well as improved inscription APIs and tools for a unified BTC and EVM wallet experience (e.g., manage Ordinals in your MetaMask wallet via [Snaps](https://metamask.io/snaps/)). Plus the ability to leverage [Account Abstraction](https://ethereum.org/en/roadmap/account-abstraction/) with bridged BTC.

docs/docusaurus.config.js

@@ -9,7 +9,7 @@ const GITHUB_LINK = "https://github.com/bob-collective/bob";
 const LANDING_PAGE = "https://gobob.xyz";
 const DOCS_PAGE = "https://docs.gobob.xyz";
 const DISCORD = "https://discord.gg/gobob";
-const TWITTER = "https://twitter.com/build_on_bob";
+const TWITTER = "https://x.com/build_on_bob";
 const TELEGRAM = "https://t.me/+CyIcLW2nfaFlNDc1";
 const FORUM = "https://forum.gobob.xyz";
 const PRESS_KIT =