diff --git a/docs/pages/build/changelog.mdx b/docs/pages/build/changelog.mdx
index 6b904f7..c241b8f 100644
--- a/docs/pages/build/changelog.mdx
+++ b/docs/pages/build/changelog.mdx
@@ -21,7 +21,7 @@
 
 #### Other changes
 
-- Updates in [CLI](https://www.npmjs.com/package/@stackr/cli) `v0.1.8`, [ESLint Plugin](https://www.npmjs.com/package/@stackr/eslint-plugin) `v0.1.2` and Playground for the above breaking changes. (Use latest for both for compatibility)
+- Updates in [CLI](https://www.npmjs.com/package/@stackr/cli) `v0.1.8`, [ESLint Plugin](https://www.npmjs.com/package/@stackr/eslint-plugin) `v0.1.2` and Playground for the above breaking changes. (Use the latest for both for compatibility)
 
 ## v0.5.5
 
@@ -37,7 +37,7 @@
 #### Improvements
 
 - Enable [WAL](https://www.sqlite.org/draft/wal.html) for SQLite. This enables better concurrency between readers and writers.
-- Optimized execution time by removing duplicate calculation of state root before and after applying all of the block's actions.
+- Optimized execution time by removing duplicate calculations of state root before and after applying all of the block's actions.
 - Enforce max size on action's payload during submission (~128kb). This limit is also enforced when collecting actions for block building.
 
 #### Other changes
@@ -82,7 +82,7 @@
 
 #### Features / Improvements
 
-- Micro-rollups can now be ran in "Sandbox" mode, without registration. The new config changes removes dependencies on `deployment.json` and `stackrApp` fields.
+- Micro-rollups can now be run in "Sandbox" mode, without registration. The new config changes removes dependencies on `deployment.json` and `stackrApp` fields.
 - Expose `emit` in block hooks as well (previously it was available only in STFs). [Learn more](/build/framework/state-machine/block-hooks#custom-execution-logs).
 - Add ability to [unsubscribe](/build/framework/events#unsubscribing-from-events) or [inspect/list active listeners](/build/framework/events/#inspecting-active-subscriptions) to MRU events.
 - Perform C2, C3A and C3B syncs for stale blocks on MRU start-up. This is useful to quickly sync latest states if you re-run the MRU after some downtime.
@@ -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 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).
 - 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.
 
@@ -117,7 +117,7 @@
 - Pre and post Block execution hooks. [Learn more](/build/framework/state-machine/block-hooks).
 - Ability to create empty blocks by setting `sequencer.enableEmptyBlocks` to `true` in `StackrConfig`.
 - Add `logs` and `errors` fields to `ActionExecutionStatusEventArgs` interface.
-- Make `syncer.slotTime` an optional field (in `StackrConfig`) having a default value of `max(1000, blockTime)` ms. If provided value is less than `1000` ms, it defaults to `max(1000, blockTime)` ms too.
+- Make `syncer.slotTime` an optional field (in `StackrConfig`) having a default value of `max(1000, blockTime)` ms. If the provided value is less than `1000` ms, it defaults to `max(1000, blockTime)` ms too.
 - Add `C1X` as a new action confirmation level that represents failed execution.
 - [CLI] Use dynamic linking for reduced Wasm binary size.
 
@@ -247,7 +247,7 @@ 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]
diff --git a/docs/pages/build/development-paradigm.mdx b/docs/pages/build/development-paradigm.mdx
index ed38779..78306cd 100644
--- a/docs/pages/build/development-paradigm.mdx
+++ b/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.
 
diff --git a/docs/pages/build/faq.mdx b/docs/pages/build/faq.mdx
index 418ca2a..8a23521 100644
--- a/docs/pages/build/faq.mdx
+++ b/docs/pages/build/faq.mdx
@@ -11,14 +11,14 @@ 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.
+It takes a 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.
 :::
 
 :::details[Getting `trace trap` when using Bun?]
-If you are getting `trace trap` error when using Bun. This is a known issue with Bun and SQLite, which got introduced in `v1.1.27` of bun. [More details here](https://discord.com/channels/876711213126520882/1282959007589601280/1283307017158791222).
+If you are getting `trace trap` error when using Bun. This is a known issue with Bun and SQLite, which was introduced in `v1.1.27` of bun. [More details here](https://discord.com/channels/876711213126520882/1282959007589601280/1283307017158791222).
 
 They've fixed the issue in `v1.1.28` and you can upgrade by running:
 
diff --git a/docs/pages/build/what-to-build.mdx b/docs/pages/build/what-to-build.mdx
index 450762c..197181c 100644
--- a/docs/pages/build/what-to-build.mdx
+++ b/docs/pages/build/what-to-build.mdx
@@ -10,7 +10,7 @@ Micro-Rollups are essentially sufficiently decentralised backends. Building your
 
 #### Free from the shackles of a Virtual Machine.
 
-Micro-Rollups enable truly single-app rollups. Your application's business logic is the state transition function of the rollup. This is unlike to other approaches like deploying a permissioned EVM rollup and building your app in Solidity on the rollup for sovereign block space. With Stackr’s micro-rollups, the developers get to design and build their applications in general purpose programming languages, free from the constraints of a specialised VM.
+Micro-Rollups enable truly single-app rollups. Your application's business logic is the state transition function of the rollup. This is unlike other approaches like deploying a permissioned EVM rollup and building your app in Solidity on the rollup for sovereign block space. With Stackr’s micro-rollups, the developers get to design and build their applications in general purpose programming languages, free from the constraints of a specialised VM.
 
 #### Verifiable compute & sturdy security guarantees.