fix typos

docs/pages/build/changelog.mdx

@@ -53,7 +53,7 @@
 
 - The EIP-712 domain for the app is now injected into the `stf.wasm`.
 - Outputs the actual error message if any step in `compile` (or `deploy`) command fails.
-- Fixes reading of leaf-level shorthand property assingments in `stackr.config.ts`.
+- Fixes reading of leaf-level shorthand property assignments in `stackr.config.ts`.
 - Fixes using the `deploymentFile` property from `stackr.config.ts` for deployment file name if specified (defaults to `deployment.json`).
 
 ## v0.5.4 (and CLI v0.1.4)
@@ -108,7 +108,7 @@
 
 #### Breaking Changes
 
-- Blocks are now rolled up into batches by Vulcan every some fixed interval. Therefore, C3A and above confirmation levels are now received on the batch level from Vulcan and L1. [Learn more](/build/framework/batch).
+- Blocks are now rolled up into batches by Vulcan at every fixed interval. Therefore, C3A and above confirmation levels are now received on the batch level from Vulcan and L1. [Learn more](/build/framework/batch).
 - State Updates are now stored on the Block level and not Action level. In case of a chain revert, the state reverts to the last block having status equal to or higher than `Sequenced`.
 - Renamed `batchSize` and `batchTime` fields in `StackrConfig` to `blockSize` and `blockTime` respectively.
 
@@ -237,7 +237,7 @@ Full Changelog: [v0.1.7...v0.2.0](https://github.com/stackrlabs/go-daash/compar
 2. [SDK] Simplified State structure by dropping `clone` method from requirement and making WrappedState optional for trivial states.
 3. [SDK] Type Safety on inputs in STF by adding `InputType` as optional second param to `STF<A, B>` type.
 4. [CLI] New Templates added for initialising a Micro-rollup.
-5. [CLI ]initialise projects with basic `README.md`
+5. [CLI] Initialise projects with basic `README.md`
 6. [CLI] Add `chainId` to `deployment.json` making it easier for user to get Chain Information for Signing Domain
 7. [CLI] Clean-up interim build files in process of making State Machine WASM
 8. [SDK] Take `stateMachines` in MRU constructor.
@@ -247,12 +247,12 @@ Full Changelog: [v0.1.7...v0.2.0](https://github.com/stackrlabs/go-daash/compar
 
 #### Fixes
 
-1. [SDK] Fix duplication batch submission to Vulcan incase of high response times.
+1. [SDK] Fix duplication batch submission to Vulcan in case of high response times.
 2. [CLI] Sanitise URLs and payload before sending deployment requests to Parent Chain and Vulcan.
 3. [CLI] Handle Registration with `falsy` Genesis states.
 4. [SDK] Initialisation of Parent Chain listeners in `sandbox` Mode. [Lazy Initialisation]
 5. [SDK] Serialisation of `bigint` entities to `number` before sending it in batch to Vulcan.
-6. [VULCAN] Compare `primitve` and `non-primitive` Genesis States separately, to avoid serialisation causing validation failures.
+6. [VULCAN] Compare `primitive` and `non-primitive` Genesis States separately, to avoid serialisation causing validation failures.
 
 ## v0.2.4-alpha to v0.2.11-alpha
 

docs/pages/build/development-paradigm.mdx

@@ -4,11 +4,11 @@
 
 Stackr is a blockchain development framework that provides a fresh perspective on decentralized app development. It takes away from the regular smart contract development paradigm and provides tooling that enables developers to <u>inject their application logic directly into the blockchain</u>.
 
-In a way it is similar to Polkadot's [Substrate framework](https://substrate.io/), but with a focus on Ethereum L2s, specially single-app rollups which we call "Micro-Rollups".
+In a way it is similar to Polkadot's [Substrate framework](https://substrate.io/), but with a focus on Ethereum L2s, especially single-app rollups which we call "Micro-Rollups".
 
 #### Build blockchains like apps
 
-With Stackr, Developers dont write smart contracts, they build _state machines_.
+With Stackr, Developers don't write smart contracts, they build _state machines_.
 
 They can define their state, actions, and state transition functions and the Stackr framework converts that into a blockchain. Stackr does not provide a VM that can run a smart contract. Instead, it provides a way to write state transition functions that contain the application logic.
 

docs/pages/build/faq.mdx

@@ -11,7 +11,7 @@ Read our [Hosting guide](/build/guides/hosting) for more information.
 :::
 
 :::details[Why is it taking so long to get C3A/C3B confirmation on my blocks?]
-If you send in multiple blocks from your Micro-rollup, they will be ordered and rolled-up into a single block on Vulcan. Vulcan is configured to create batches every 6 hours or max blob size of chosen DA which ever comes first.
+If you send in multiple blocks from your Micro-rollup, they will be ordered and rolled-up into a single block on Vulcan. Vulcan is configured to create batches every 6 hours or max blob size of chosen DA whichever comes first.
 Therefore, subsequent blocks will take more time to get C3A/C3B confirmation.
 It takes few minutes roughly how much time it takes to confirm data publication of the batch on a data availability layer.
 After this, depending on Sepolia's network congestion, it may take 10-30s to submit the batch to your app's inbox and receive C3B confirmation.

docs/pages/build/guides/community-examples.mdx

@@ -30,7 +30,7 @@ stAVL - Avail Liquid Staking Tokens
 
 ### [Stealth Micro-Rollup](https://github.com/Dhruv-2003/StealthMRU)
 
-A Stealth Address -based privacy enabling micro rollup for all EVM blockchains.
+A Stealth Address-based privacy enabling micro rollup for all EVM blockchains.
 
 ### [UTXO Micro-Rollup](https://github.com/Dhruv-2003/UTXO-rollup)
 

docs/pages/build/guides/tutorials/counter.mdx

@@ -50,7 +50,7 @@ export class CounterState extends State<number> {
 ```
 
 :::info
-The hashing function could be any function that takes the state as input and returns a hash determinitically. The hash should be a `BytesLike` type.
+The hashing function could be any function that takes the state as input and returns a hash deterministically. The hash should be a `BytesLike` type.
 :::
 
 ## Define State Transition Functions (STF)

docs/pages/concepts/micro-rollup/architecture/execution-layer.mdx

@@ -6,4 +6,4 @@ The execution layer hosts the main application logic. This environment delivers
 
 ![Execution Model](/assets/execution-model.png)
 
-MRUs deliver exceptionally high throughput, mirroring the instant interaction users expect from web2 applications. Upon receiving a user’s request, the application promptly attempts to execute the state changes. If successful, it instantly provides feedback to the user. Subsequently, in according to MRU configurations, the application dispatches the block containing the state update and the corresponding actions to the Vulcan layer. This layer is responsible for verifying the accuracy of the transactions before ultimately recording the data on the blockchain.
+MRUs deliver exceptionally high throughput, mirroring the instant interaction users expect from web2 applications. Upon receiving a user’s request, the application promptly attempts to execute the state changes. If successful, it instantly provides feedback to the user. Subsequently, according to MRU configurations, the application dispatches the block containing the state update and the corresponding actions to the Vulcan layer. This layer is responsible for verifying the accuracy of the transactions before ultimately recording the data on the blockchain.

docs/pages/concepts/micro-rollup/architecture/verification-layer.mdx

@@ -18,7 +18,7 @@ Therefore, Vulcan provides a flexible range of settlement-as-a-service options f
 <img src="/assets/deploy.png" alt="Deployment flow" />
 
 Before Vulcan can start verifying blocks, the developer must first build out their Stackr State machine (SSM) and deploy it as a microrollup (execution layer).
-The SSM is then compiled down to a WASM binary and sent to Vulcan, alongwith an initial genesis state. This all happens when executing the `deploy` CLI command.
+The SSM is then compiled down to a WASM binary and sent to Vulcan, along with an initial genesis state. This all happens when executing the `deploy` CLI command.
 
 <Callout type="info">
   In the future, Vulcan will post the binary and genesis state to a DA layer to
@@ -69,4 +69,4 @@ Vulcan behaves like a fast finality settlement layer, providing soft confirmatio
 
 Once an incoming block is verified, Vulcan will first ensure its availability by posting it to a DA layer of the developer's choice. This can be Avail, Celestia or EigenDA.
 After finalizing proof of data publication, Vulcan will emit a `C3A` confirmation event to denote guaranteed data availability and then proceed to submit the batch (a set of blocks) to the corresponding MRU's `AppInbox` smart contract on the parent chain.
-On successful submission, the batch (a set of blocks) will be appended to the canonical chain on L1 and Vulcan will emit a `C3B` confirmation event denoting succesful settlement of the batch onchain.
+On successful submission, the batch (a set of blocks) will be appended to the canonical chain on L1 and Vulcan will emit a `C3B` confirmation event denoting successful settlement of the batch onchain.

docs/pages/concepts/micro-rollup/motivation/modularity.mdx

@@ -4,4 +4,4 @@ Stackr is a modular system, you can use whatever you want. We firmly believe tha
 
 ## Modular by design
 
-External dependencies like sequencing, data availibility, settlement etc are customizable by the developers and they can choose to use anything they wish in the form of hot swappable modules. Stackr does not wish to lock the developers into a particular ecosystem and provides the ability to mix and match different tech stacks.
+External dependencies like sequencing, data availability, settlement etc are customizable by the developers and they can choose to use anything they wish in the form of hot swappable modules. Stackr does not wish to lock the developers into a particular ecosystem and provides the ability to mix and match different tech stacks.

docs/pages/concepts/micro-rollup/motivation/single-app-rollups.mdx

@@ -1,6 +1,6 @@
 # Single-App Rollups [Micro-Rollups are for standalone apps]
 
-Micro-rollups are oprimized for **single-app rollups**. By providing each application with its dedicated rollup, this approach effectively removes the battle for shared state, thus alleviating congestion and minimizing transaction fees.
+Micro-rollups are optimized for **single-app rollups**. By providing each application with its dedicated rollup, this approach effectively removes the battle for shared state, thus alleviating congestion and minimizing transaction fees.
 
 The core advantages of micro-rollups lie in their support for modular development and their ability to scale.
 

docs/pages/concepts/micro-rollup/motivation/traditional-rollups.mdx

@@ -28,4 +28,4 @@ Each app-specific rollup becomes an isolated environment, making it challenging
 
 The reliance on modified general-purpose languages does not fully escape the constraints and inefficiencies inherent to those systems. While customization can lead to improvements in certain areas, it often carries over the limitations and overhead of the underlying technology. As a result, app-specific rollups may still face issues related to scalability, flexibility, and developer accessibility, which they were meant to overcome.
 
-In summary, while app-specific rollup environments represent a step towards addressing the one- size-fits-all dilemma of general-purpose rollups, they are not without their own set of challenges. The complexity of customization, ecosystem fragmentation, and inherited limitations of modified general- purpose languages suggest that a more fundamental rethinking of rollup technology is necessary to unlock the full potential of scalable, interoperable, and developer-friendly blockchain applications.
+In summary, while app-specific rollup environments represent a step towards addressing the one-size-fits-all dilemma of general-purpose rollups, they are not without their own set of challenges. The complexity of customization, ecosystem fragmentation, and inherited limitations of modified general-purpose languages suggest that a more fundamental rethinking of rollup technology is necessary to unlock the full potential of scalable, interoperable, and developer-friendly blockchain applications.

docs/pages/concepts/micro-rollup/utility.mdx

@@ -2,7 +2,7 @@
 
 Micro rollups offer a transformative approach for developing a broad spectrum of applications, essentially enhancing anything traditionally built as a smart contract on a blockchain. This paradigm shift not only promises an improved developer experience by abstracting away the complexities of Layer 1 blockchain intricacies but also allows developers to leverage their existing skills in a more familiar development environment.
 
-Infact anything that can be built as a smart contract on a blockchain can be built better as a combination of MRU and a smart contract.
+In fact anything that can be built as a smart contract on a blockchain can be built better as a combination of MRU and a smart contract.
 
 ## 1. Sidecars to existing protocols