docs: Rectify typographical inaccuracies

docs/docs/build/bob-sdk/relay.md

@@ -80,7 +80,7 @@ This approach is still experimental and not yet fully supported by the SDK. To c
 
 ### Checking Output Amounts
 
-To extract the output amount `BitcoinTx.processTxOutputs` can be be used to extract the amount transferred to a specific address. See [`test/BitcoinTx.t.sol`](https://github.com/bob-collective/bob/blob/master/test/BitcoinTx.t.sol) for an example. The address is the `keccak256` hash of the expected `scriptPubKey`.
+To extract the output amount `BitcoinTx.processTxOutputs` can be used to extract the amount transferred to a specific address. See [`test/BitcoinTx.t.sol`](https://github.com/bob-collective/bob/blob/master/test/BitcoinTx.t.sol) for an example. The address is the `keccak256` hash of the expected `scriptPubKey`.
 
 :::tip BOB SDK
 

docs/docs/build/getting-started/helloworld.mdx

@@ -445,7 +445,7 @@ contract HelloBitcoin {
         // Set the relay difficulty based on the Bitcoin headers in the proof
         testLightRelay.setDifficultyFromHeaders(proof.bitcoinHeaders);
 
-        // Validate the BTC transaction proof using the relay, in production a higher than 1 block confirmation shoul be used
+        // Validate the BTC transaction proof using the relay, in production a higher than 1 block confirmation should be used
         BitcoinTx.validateProof(relay, 1, transaction, proof);
 
         // Ensure that the BTC transaction input spends the specified UTXO associated with the ordinal sell order

docs/docs/build/how-to/bitcoin-testing.md

@@ -34,7 +34,7 @@ bitcoin-cli -regtest stop
 
 ### Using Nigiri Bitcoin
 
-For an alterantive development environment check out [Nigiri Bitcoin](https://github.com/vulpemventures/nigiri/) which also packages a Liquid daemon and an Electrum server.
+For an alternative development environment check out [Nigiri Bitcoin](https://github.com/vulpemventures/nigiri/) which also packages a Liquid daemon and an Electrum server.
 
 ## Funding a Wallet
 
@@ -70,4 +70,4 @@ bitcoin-cli -regtest -rpcwallet=Alice -named sendtoaddress address=${BOB_ADDRESS
 
 To use a supported Graphical User Interface (GUI) instead, terminate the `bitcoind` process and run `bitcoin-qt` instead:
 
-![Bitcoin Core Wallet GUI](https://bitcoin.org/img/bitcoin-core/clear-overview.png?1697494088)
+![Bitcoin Core Wallet GUI](https://bitcoin.org/img/bitcoin-core/clear-overview.png?1697494088)

docs/docs/drafts/roadmap.md

@@ -9,7 +9,7 @@ sidebar_position: 4
 The core things that need building is:
 
 - Adding the base EVM compatibility layer from frontier. Then, frontier would need to be extended to be compatible with OP Stack. First focus needs to be on the op-geth execution engine and then on the settlement/fraud proof contracts.
-- Adding Rust smart contracts. Ink is well supported in substrate and offers a developer experience very close to core Rust as it wraps the smart contracts inside a macro to handle its integration into a runtime (https://use.ink/basics/contract-template). From there, contracts need to be provided access to the existing runtime functions like the Bitcoin light client, AMM, lending, bridge, …. For a great dev experience, hackathon templates and a well-documented SDK needs to be created for devs to get started with a new contract as simply as possible. Setting up a new project that can itneract with the Bitcoin light client should take less than 20 minutes.
+- Adding Rust smart contracts. Ink is well supported in substrate and offers a developer experience very close to core Rust as it wraps the smart contracts inside a macro to handle its integration into a runtime (https://use.ink/basics/contract-template). From there, contracts need to be provided access to the existing runtime functions like the Bitcoin light client, AMM, lending, bridge, …. For a great dev experience, hackathon templates and a well-documented SDK needs to be created for devs to get started with a new contract as simply as possible. Setting up a new project that can interact with the Bitcoin light client should take less than 20 minutes.
 - Improving the core Bitcoin bridge. We already have the most decentralized Bitcoin bridge and it works as in we have Vaults providing collateral and support for LST and other yield bearing assets as collateral. However, the bridge needs improvements by separating out the asset minting backed by collateral and the cross-chain operation of bridging in and out of Bitcoin.
 
 ## What is already done?

docs/docs/drafts/vision.md

@@ -5,7 +5,7 @@ sidebar_position: 1
 
 We see BOB as a collective undertaking to scale Bitcoin the right way: inheriting security from Bitcoin while providing usable decentralization for builders today without waiting for hard forks.
 
-The technical vision outlines the endgame for BOB and describes how it differs from the first deployments. The discrepancy between endgame and current state forms opportunities to contribute and push the BOB stack further.
+The technical vision outlines the endgame for BOB and describes how it differs from the first deployments. The discrepancy between the endgame and current state forms opportunities to contribute and push the BOB stack further.
 
 ## Bringing Bitcoin Security to Rollups
 
@@ -77,4 +77,4 @@ We believe that in some cases, bridging BTC, Ordinals, and BRC20s to more chains
 
 :::note BOB Launch Plan
 BOB will launch with the tBTC bridge as it provides a good trade-off that features a 1:1 peg, a distribution of trust among many parties through their threshold signatures, and partial collateralization.
-:::
+:::