MinaProtocol · yash251 · Jan 12, 2025
diff --git a/docs/berkeley-upgrade/archive-migration/archive-migration-prerequisites.mdx b/docs/berkeley-upgrade/archive-migration/archive-migration-prerequisites.mdx
@@ -31,7 +31,7 @@ You can use any gsutil-compatible alternative to Google Cloud or a gsutil wrappe
 
 ## (Optional) Google Cloud bucket with Devnet/Mainnet precomputed blocks
 
-Precomputed blocks are the JSON files that a correctly configured node updloads to the Google Cloud bucket.
+Precomputed blocks are the JSON files that a correctly configured node uploads to the Google Cloud bucket.
 The Devnet/Mainnet to Berkeley archive data migration requires access to precomputed blocks that are uploaded by daemons that are connected to the Devnet or Mainnet networks. 
 
 The **berkeley-migration** app uses the gsutil app to download blocks. If you didn't store precomputed blocks during the first phase of migration, you can use the precomputed blocks provided by Mina Foundation.

diff --git a/docs/berkeley-upgrade/archive-migration/index.mdx b/docs/berkeley-upgrade/archive-migration/index.mdx
@@ -37,7 +37,7 @@ Finally, see the shell script example that is compatible with a stock Debian 11
 
 After the migration, you will have two databases:
 
-- The original Devnet/Mainnet database with small data adjustments (all pending blocks from last canoncial block until the fork block are converted to canoncial blocks)
+- The original Devnet/Mainnet database with small data adjustments (all pending blocks from last canonical block until the fork block are converted to canoncial blocks)
 - A new Berkeley database based on Devnet/Mainnet data, but:
   - Without Devnet/Mainnet orphaned blocks
   - Without pending blocks that are not in the canonical chain

diff --git a/docs/berkeley-upgrade/archive-migration/mainnet-database-maintenance.mdx b/docs/berkeley-upgrade/archive-migration/mainnet-database-maintenance.mdx
@@ -24,7 +24,7 @@ preserving some aspect of the database that is lost during the migration process
 Two databases exist after the successful migration:
 
 - The original Devnet/Mainnet database with small data adjustments:
-  - All pending blocks from last canoncial block until the fork block are converted to canonical blocks
+  - All pending blocks from last canonical block until the fork block are converted to canonical blocks
 
 - A new Berkeley database based on Devnet/Mainnet data with these differences:
   - Without Devnet/Mainnet orphaned blocks

diff --git a/docs/exchange-operators/faq.mdx b/docs/exchange-operators/faq.mdx
@@ -162,7 +162,7 @@ No, there are no official broadcast nodes at this time. However, you can  broadc
 
 ### Should I be staking my funds?
 
-Since Mina is a Proof of Stake (PoS) consensus network without lockup for staked tokens, it is recommended to stak these funds to support the quality of the Mina network. Additionally, by not staking, you are missing out on staking rewards that you can otherwise be receiving from the Mina blockchain.
+Since Mina is a Proof of Stake (PoS) consensus network without lockup for staked tokens, it is recommended to stake these funds to support the quality of the Mina network. Additionally, by not staking, you are missing out on staking rewards that you can otherwise be receiving from the Mina blockchain.
 
 You can look into staking this wallet, either by running your own block production node or just by delegating your funds to a staking pool on the network. Delegating to a staking pool is simpler to set up.
 

diff --git a/docs/exchange-operators/index.mdx b/docs/exchange-operators/index.mdx
@@ -29,7 +29,7 @@ Use Rosetta API if you are:
 - Integrating the Mina blockchain with your exchange
 - Building blockchain applications, such as explorers and wallets
 
-Using Rosetta for building your application is preferrable, as it's API is more appropriate for applications and far more stable than GraphQL.
+Using Rosetta for building your application is preferable, as it's API is more appropriate for applications and far more stable than GraphQL.
 
 
 - [Running with Docker](/exchange-operators/rosetta/run-with-docker) - How to install Rosetta from Docker image

diff --git a/docs/exchange-operators/rosetta/samples/scan-blocks.mdx b/docs/exchange-operators/rosetta/samples/scan-blocks.mdx
@@ -32,7 +32,7 @@ async function waitForBlock(blockHeight: number) {
 def wait_for_block(block_index):
     """
     Checks if block with given index exist
-    Once the /block response is succesful - returns the response
+    Once the /block response is successful - returns the response
     Otherwise, retries fetching it with 10 seconds delay
     """
 

diff --git a/docs/exchange-operators/rosetta/samples/send-transactions.mdx b/docs/exchange-operators/rosetta/samples/send-transactions.mdx
@@ -11,14 +11,14 @@ This flow is also described in the [Construction API Overview](https://docs.clou
 :::
 
 The steps needed to send payment in MINA token are following:
-1. Given a key pair, derive the account indentifier using `/construction/derive` endpoint
+1. Given a key pair, derive the account identifier using `/construction/derive` endpoint
 1. Call `/construction/preprocess` and `/construction/metadata` to construct parameters for `/construction/payloads` request
 1. Create an unsigned transaction blob using `construction/payloads` endpoint
 1. Call `construction/parse` (optional) to check if the unsigned transaction does what you expect
 1. Use detached signer to sign the transaction
 1. Call `construction/combine` to generate signed blob to be sent via `/construction/submit` endpoint
 1. Call `construction/parse` again (optional) to confirm correctness of the signed transaction
-1. Get a future transaction hash using `/construction/hash` enpoint
+1. Get a future transaction hash using `/construction/hash` endpoint
 1. Submit the signed transaction blob via `/construction/submit` endpoint
 
 For ease of readability, this sample implementation skips the sanity checks (steps 4 and 7) and combines steps 2 and 3 in a single `tx_payloads` function call.

diff --git a/docs/glossary.mdx b/docs/glossary.mdx
@@ -123,7 +123,7 @@ A digital asset or currency that uses cryptographic primitives to secure financi
 
 ### daemon
 
-The Mina daemon is a background process that implements the Mina protocol and runs on a node locally so a local client or wallet can talk to the Mina network. For example, when a CLI is used to issue a command to send a transaction, this request is made to the Mina daemon, which then broadcasts it to the peer-to-peer network. The daemon also listens for events like new blocks and relays this to the client by using a publish-subcribe model.
+The Mina daemon is a background process that implements the Mina protocol and runs on a node locally so a local client or wallet can talk to the Mina network. For example, when a CLI is used to issue a command to send a transaction, this request is made to the Mina daemon, which then broadcasts it to the peer-to-peer network. The daemon also listens for events like new blocks and relays this to the client by using a publish-subscribe model.
 
 ### DAO
 

diff --git a/docs/mina-protocol/scan-state.mdx b/docs/mina-protocol/scan-state.mdx
@@ -4,7 +4,7 @@ hide_title: true
 description: A data structure that allows decoupling the production of transaction SNARKs from block producers to snark workers. 
 keywords:
   - data structure
-  - blockchian
+  - blockchain
   - full binary tree
   - snark
   - snarked ledger

diff --git a/docs/mina-protocol/time-locked-accounts.mdx b/docs/mina-protocol/time-locked-accounts.mdx
@@ -26,7 +26,7 @@ A time-lock consists of the following fields `initial_minimum_balance`, `cliff`
 
 You can still use an account if it has a time-lock, as long as the account holds enough funds. The amount of funds that are time-locked starts off as `initial_minimum_balance` at the beginning of the network. Once the network reaches a block height equal to the `cliff`, the time-locked amount begins to decrease by the `vesting_increment` amount every `vesting_period`.
 
-For a more technical explanaition of this process, please see [RFC-0025](https://github.com/MinaProtocol/mina/blob/master/rfcs/0025-time-locked-accounts.md) which has a more in-depth overview.
+For a more technical explanation of this process, please see [RFC-0025](https://github.com/MinaProtocol/mina/blob/master/rfcs/0025-time-locked-accounts.md) which has a more in-depth overview.
 
 ### Liquid Balance Details:
 

diff --git a/docs/mina-protocol/whats-in-a-block.mdx b/docs/mina-protocol/whats-in-a-block.mdx
@@ -91,7 +91,7 @@ The consensus state is comprised of:
 * Block stake winner
 * Block creator
 * Coinbase receiver
-* Superchage coinbase
+* Supercharge coinbase
 
 #### Consensus Constants
 

diff --git a/docs/node-developers/sandbox-node.mdx b/docs/node-developers/sandbox-node.mdx
@@ -30,7 +30,7 @@ docker run \
 
 ```
 
-This command starts a daemon inside the docker container and exposes the GraphQL port (3085) to your computer. This port is used for communication with the client. This daemon automatical runs in the background with a block producer and SNARK worker.
+This command starts a daemon inside the docker container and exposes the GraphQL port (3085) to your computer. This port is used for communication with the client. This daemon automatically runs in the background with a block producer and SNARK worker.
 
 You can view logs by executing.
 

diff --git a/docs/node-operators/block-producer-node/connecting-to-the-network.mdx b/docs/node-operators/block-producer-node/connecting-to-the-network.mdx
@@ -238,7 +238,7 @@ The expected response includes these fields:
 
 - When sync status reaches `Synced` and the node is connected to 1 or more peers, the node is successfully connected to the network. A corresponding daemon log shows the sync status: `[Info] Mina daemon is now synced`.
 
-- An issue with your port configuration can causethe `Bootstrap` state to persist for more than an hour.
+- An issue with your port configuration can cause the `Bootstrap` state to persist for more than an hour.
 
 ## Step up your game
 

diff --git a/docs/node-operators/index.mdx b/docs/node-operators/index.mdx
@@ -44,7 +44,7 @@ This section describes operations on Mina and how node operators can run Mina no
 - [Archive Nodes](/node-operators/archive-node) - Running an Archive Node
 - [Seed Peers](/node-operators/seed-peers) - Running a Seed Peer
 - [Data and History](/node-operators/data-and-history) - A look at retrieving historic data.
-- [Delegation Program](/node-operators/delegation-program) - The Mina Foundation Delegation Prgram for Block Producers 
+- [Delegation Program](/node-operators/delegation-program) - The Mina Foundation Delegation Program for Block Producers 
 - [Staking Service Guidelines](/node-operators/staking-service-guidelines)
 - [Mina Signer](/node-operators/mina-signer)
 - [Mina CLI Reference](/node-operators/mina-cli-reference) - Guide to CLI interactions with Mina networks 

diff --git a/docs/node-operators/seed-peers/docker-compose.mdx b/docs/node-operators/seed-peers/docker-compose.mdx
@@ -54,7 +54,7 @@ services:
 
 To retrieve the status of the Mina Node, run `docker compose exec mina_node mina client status`
 
-In the client status, you should also see the _Adresses and ports_ section.
+In the client status, you should also see the _Addresses and ports_ section.
 
 ```shell
 Addresses and ports:

diff --git a/docs/node-operators/troubleshooting.mdx b/docs/node-operators/troubleshooting.mdx
@@ -1,7 +1,7 @@
 ---
 title: Troubleshooting
 hide_title: true
-description: Answers to comon problems when setting  up a Mina daemon
+description: Answers to common problems when setting  up a Mina daemon
 keywords:
   - syncing a node
   - networking
@@ -161,7 +161,7 @@ There is some behavior with our p2p networking module that triggers this warning
 
 Here is an example of this using the [ufw](https://help.ubuntu.com/community/UFW#UFW_-_Uncomplicated_Firewall) firewall tool. Thanks Ducca for sharing these rules and confirming they fix the issues on Hetzner.
 
-Allow SSH, HTTP, HTTPS porst:
+Allow SSH, HTTP, HTTPS ports:
 
 ```
 ufw allow 22

diff --git a/docs/using-mina/how-to-send-and-receive.mdx b/docs/using-mina/how-to-send-and-receive.mdx
@@ -96,7 +96,7 @@ When sending transactions on a blockchain, such as Mina, senders must include a
 
 :::
 
-### Viewing your transction on a blockchain explorer
+### Viewing your transaction on a blockchain explorer
 
 You can view your transactions using one of the community-run blockchain explorers:
 

diff --git a/docs/zkapps/o1js-reference/classes/DynamicProof.mdx b/docs/zkapps/o1js-reference/classes/DynamicProof.mdx
@@ -1,4 +1,4 @@
-The `DynamicProof` class enables circuits to verify proofs using in-ciruit verfication keys.
+The `DynamicProof` class enables circuits to verify proofs using in-circuit verification keys.
 This is opposed to the baked-in verification keys of the `Proof` class.
 
 In order to use this, a subclass of DynamicProof that specifies the public input and output types along with the maxProofsVerified number has to be created.

diff --git a/docs/zkapps/o1js-reference/namespaces/Experimental/classes/BatchReducer.mdx b/docs/zkapps/o1js-reference/namespaces/Experimental/classes/BatchReducer.mdx
@@ -836,7 +836,7 @@ the element of type `T` to put assertions on.
 
 A function that returns an element of type `T` from the given provable and "auxiliary" data.
 
-This function is the reverse operation of calling toFields and toAuxilary methods on an element of type `T`.
+This function is the reverse operation of calling toFields and toAuxiliary methods on an element of type `T`.
 
 **Param**
 an array of [Field](../../../classes/Field.mdx) elements describing the provable data of the new `T` element.
@@ -969,7 +969,7 @@ the element of type `T` to put assertions on.
 
 A function that returns an element of type `T` from the given provable and "auxiliary" data.
 
-This function is the reverse operation of calling toFields and toAuxilary methods on an element of type `T`.
+This function is the reverse operation of calling toFields and toAuxiliary methods on an element of type `T`.
 
 **Param**
 an array of [Field](../../../classes/Field.mdx) elements describing the provable data of the new `T` element.
@@ -1056,7 +1056,7 @@ the element of type `T` to put assertions on.
 
 A function that returns an element of type `T` from the given provable and "auxiliary" data.
 
-This function is the reverse operation of calling toFields and toAuxilary methods on an element of type `T`.
+This function is the reverse operation of calling toFields and toAuxiliary methods on an element of type `T`.
 
 **Param**
 an array of [Field](../../../classes/Field.mdx) elements describing the provable data of the new `T` element.
@@ -2104,7 +2104,7 @@ fromFields: {};
 
 A function that returns an element of type `T` from the given provable and "auxiliary" data.
 
-This function is the reverse operation of calling toFields and toAuxilary methods on an element of type `T`.
+This function is the reverse operation of calling toFields and toAuxiliary methods on an element of type `T`.
 
 ###### Param
 
@@ -2353,7 +2353,7 @@ fromFields: {};
 
 A function that returns an element of type `T` from the given provable and "auxiliary" data.
 
-This function is the reverse operation of calling toFields and toAuxilary methods on an element of type `T`.
+This function is the reverse operation of calling toFields and toAuxiliary methods on an element of type `T`.
 
 ###### Param
 
@@ -2509,7 +2509,7 @@ fromFields: {};
 
 A function that returns an element of type `T` from the given provable and "auxiliary" data.
 
-This function is the reverse operation of calling toFields and toAuxilary methods on an element of type `T`.
+This function is the reverse operation of calling toFields and toAuxiliary methods on an element of type `T`.
 
 ###### Param
 

diff --git a/docs/zkapps/o1js-reference/namespaces/Experimental/functions/IndexedMerkleMap.mdx b/docs/zkapps/o1js-reference/namespaces/Experimental/functions/IndexedMerkleMap.mdx
@@ -37,7 +37,7 @@ ZkProgram({
 
 Initially, every `IndexedMerkleMap` is populated by a single key-value pair: `(0, 0)`. The value for key `0` can be updated like any other.
 When keys and values are hash outputs, `(0, 0)` can serve as a convenient way to represent a dummy update to the tree, since 0 is not
-effciently computable as a hash image, and this update doesn't affect the Merkle root.
+efficiently computable as a hash image, and this update doesn't affect the Merkle root.
 
 ## Parameters
 

diff --git a/docs/zkapps/o1js-reference/namespaces/Mina/functions/LocalBlockchain.mdx b/docs/zkapps/o1js-reference/namespaces/Mina/functions/LocalBlockchain.mdx
@@ -225,7 +225,7 @@ A mock Mina blockchain running locally and useful for testing.
 > slotTime: UInt64;
 > ```
 >
-> Duration of 1 slot in millisecondw
+> Duration of 1 slot in milliseconds
 >
 > ### getNetworkState()
 >

diff --git a/docs/zkapps/o1js-reference/namespaces/Mina/type-aliases/NetworkConstants.mdx b/docs/zkapps/o1js-reference/namespaces/Mina/type-aliases/NetworkConstants.mdx
@@ -26,7 +26,7 @@ genesisTimestamp: UInt64;
 slotTime: UInt64;
 ```
 
-Duration of 1 slot in millisecondw
+Duration of 1 slot in milliseconds
 
 ## Source
 

diff --git a/docs/zkapps/o1js-reference/type-aliases/Provable.mdx b/docs/zkapps/o1js-reference/type-aliases/Provable.mdx
@@ -59,7 +59,7 @@ fromFields: (fields: Field[], aux: any[]) => T;
 
 A function that returns an element of type `T` from the given provable and "auxiliary" data.
 
-This function is the reverse operation of calling toFields and toAuxilary methods on an element of type `T`.
+This function is the reverse operation of calling toFields and toAuxiliary methods on an element of type `T`.
 
 #### Parameters
 

diff --git a/docs/zkapps/o1js/custom-tokens.mdx b/docs/zkapps/o1js/custom-tokens.mdx
@@ -121,7 +121,7 @@ class TokenContract extends SmartContract {
     amount: UInt64,
     callback: Experimental.Callback<any>
   ) {
-    // approves the callback which deductes the amount of tokens from the sender
+    // approves the callback which deducts the amount of tokens from the sender
     let senderAccountUpdate = this.approve(callback);
 
     // Create constraints for the sender account update and amount

diff --git a/docs/zkapps/o1js/keccak.mdx b/docs/zkapps/o1js/keccak.mdx
@@ -25,7 +25,7 @@ Because of the common usage of Keccak in Ethereum, it is a key component of o1js
 
 ## Keccak and Poseidon
 
-As an o1js developer, you are likely familar with the [Poseidon](https://o1-labs.github.io/proof-systems/specs/poseidon.html) zero knowledge native hash function. Poseidon operates over the native [Pallas base field](https://electriccoin.co/blog/the-pasta-curves-for-halo-2-and-beyond/) and uses parameters generated specifically for Mina which makes Poseidon the most efficient hash function available in o1js.
+As an o1js developer, you are likely familiar with the [Poseidon](https://o1-labs.github.io/proof-systems/specs/poseidon.html) zero knowledge native hash function. Poseidon operates over the native [Pallas base field](https://electriccoin.co/blog/the-pasta-curves-for-halo-2-and-beyond/) and uses parameters generated specifically for Mina which makes Poseidon the most efficient hash function available in o1js.
 
 In contrast, Keccak is a hash function that requires binary arithmetic. It operates over binary data and is not native to most zero knowledge proofs. For this reason, Keccak is not as efficient as Poseidon, but it is still very useful for verifying Ethereum transactions and blocks.
 So, when you choose what hash function to use, important considerations include the use case and the data that needs to be hashed.

diff --git a/docs/zkapps/o1js/sha256.mdx b/docs/zkapps/o1js/sha256.mdx
@@ -25,7 +25,7 @@ widely used for traditional Web2 applications and protocols and blockchain techn
 
 ## SHA-256 and Poseidon
 
-As an o1js developer, you are likely familar with the [Poseidon](https://o1-labs.github.io/proof-systems/specs/poseidon.html) zero knowledge native hash function. Poseidon operates over the native [Pallas base field](https://electriccoin.co/blog/the-pasta-curves-for-halo-2-and-beyond/) and uses parameters generated specifically for Mina which makes Poseidon the most efficient hash function available in o1js.
+As an o1js developer, you are likely familiar with the [Poseidon](https://o1-labs.github.io/proof-systems/specs/poseidon.html) zero knowledge native hash function. Poseidon operates over the native [Pallas base field](https://electriccoin.co/blog/the-pasta-curves-for-halo-2-and-beyond/) and uses parameters generated specifically for Mina which makes Poseidon the most efficient hash function available in o1js.
 
 In contrast, SHA-2 is a hash function that requires binary arithmetic. It operates over binary data and is not native to most zero knowledge proofs. For this reason, SHA-256 is not as efficient as Poseidon. However, it is still very useful for verifying Ethereum transactions and blocks.
 So, when you choose what hash function to use, important considerations include the use case and the data that needs to be hashed.

diff --git a/docs/zkapps/writing-a-zkapp/feature-overview/custom-tokens.mdx b/docs/zkapps/writing-a-zkapp/feature-overview/custom-tokens.mdx
@@ -30,7 +30,7 @@ If you want to create a fungible token you can use the
 Blockchain applications have various use cases for custom tokens, including a real-world financial asset, stake in an on-chain protocol, or even skill points in a game.
 
 Most blockchains, like Ethereum, do not natively support custom tokens. You implement custom tokens as smart contracts on top of the execution layer of the underlying protocol.
-Token standards ensure the interoperability of applications on Etherum, these standardisations are agree upon in ERCs, Ethereum Request for customElements, such as the fungible token standard [ERC-20](https://ethereum.org/en/developers/docs/standards/tokens/erc-20/).
+Token standards ensure the interoperability of applications on Ethereum, these standardisations are agree upon in ERCs, Ethereum Request for customElements, such as the fungible token standard [ERC-20](https://ethereum.org/en/developers/docs/standards/tokens/erc-20/).
 The Ethereum community has created and agreed upon other reference implementations and standardisation that are audited and easy to configure, such as [ERC-721](https://ethereum.org/en/developers/docs/standards/tokens/erc-721/) for NFTs.
 
 Mina supports custom token functionality at a low level in the tech stack. Mina treats custom tokens almost the same way as the native MINA token. This approach offers the following benefits:
@@ -107,7 +107,7 @@ Each subclass token contract that inherits the default `TokenContract` must impl
 approveBase(forest: AccountUpdateForest): void;
 ```
 
-The `TokenContract` also containts helper methods that make it easy to iterate through and approve a forest of child account updates.
+The `TokenContract` also contains helper methods that make it easy to iterate through and approve a forest of child account updates.
 The usual implementation is as easy as this:
 
 
@@ -174,7 +174,7 @@ abstract class TokenContract extends SmartContract {
 }
 ```
 
-Which utlizses the `Approvable` API to send token from an account to another one.
+Which utilizes the `Approvable` API to send token from an account to another one.
 
 ## Custom Token Terminology
-Original file line number
+Diff line change
@@ Expand Up @@
     ### daemon
-    The Mina daemon is a background process that implements the Mina protocol and runs on a node locally so a local client or wallet can talk to the Mina network. For example, when a CLI is used to issue a command to send a transaction, this request is made to the Mina daemon, which then broadcasts it to the peer-to-peer network. The daemon also listens for events like new blocks and relays this to the client by using a publish-subcribe model.
+    The Mina daemon is a background process that implements the Mina protocol and runs on a node locally so a local client or wallet can talk to the Mina network. For example, when a CLI is used to issue a command to send a transaction, this request is made to the Mina daemon, which then broadcasts it to the peer-to-peer network. The daemon also listens for events like new blocks and relays this to the client by using a publish-subscribe model.
     ### DAO
@@ Expand Down @@