docs: 📝 cross docs typo amends

docs/learn/delivery-acknowledgements.md

@@ -15,10 +15,10 @@ import Author from '@site/src/components/Author';
 When a client signs a message, it creates a Delivery Acknowledgement that confirms a successful service computation delivery by a node. This [process](#node-vs-client-process-flow) ensures the immutability and integrity of the message (the client cannot change or reverse it) and also includes metadata about the commodities consumed by the node during the service execution. This metadata helps in calculating the reward that the node will receive.
 
 :::info
-The Narwhal and Bullshark consensus primary transaction is the order of batched Delivery Acknowledgements. Every time a node serves a request, it gathers Delivery Acknowledgments that, upon submission, reward the node at the end of an epoch (which is approximately 24 hours).
+The Narwhal and Bullshark consensus primary transaction is the order of batched Delivery Acknowledgements. Every time a node serves a request, it gathers Delivery Acknowledgements that, upon submission, reward the node at the end of an epoch (which is approximately 24 hours).
 :::
 
-To claim the reward and other fees, nodes can add received Delivery Acknowledgements to a local pool and periodically submit them in batches to reach a consensus. This process also ensures consistent updates to the client's balance in stablecoin.
+To claim the reward and other fees, nodes can add received Delivery Acknowledgements to a local pool and periodically submit them in batches to reach a consensus. This process also ensures consistent updates to the client's balance in stable coin.
 
 The amounts deducted from all clients during an epoch, move to a payout pool which is distributed fairly to node [account owners](/docs/learn/the-network#identity-on-the-fleek-network) based on the work performed in the epoch.
 
@@ -72,7 +72,7 @@ Thus, the entire network operates based on content addressing based on Blake3 ha
 
 Learn more about it in the [Content Addressing](/docs/learn/the-network#content-addressing) section.
 
-## Delivery Acknowledgement Customisation
+## Delivery Acknowledgement Customization
 
 A Service can have a custom configuration to specify how Delivery Acknowledgements should behave or work. Patterns and conventions should be expected to emerge from the Service builder community and best practices.
 

docs/learn/developers.md

@@ -22,7 +22,7 @@ This documentation is currently placeholder as the team prepares for an early te
 
 As a developer, you will be able to build or use services running on Fleek Network's decentralized edge infrastructure.
 
-This will be possible **after our initial Testnet rollouts in August, and after we publish our Service Development Kit (SDK) for service development**. Currently we are finalizing the core developments of the protocol and setting the foundations for the testnet release.
+This will be possible **after our initial Testnet rollouts in August, and after we publish our Service Development Kit (SDK) for service development**. Currently, we are finalizing the core developments of the protocol and setting the foundations for the testnet release.
 
 ## How can you Start Getting Involved Today?
 

docs/learn/the-network.md

@@ -93,14 +93,14 @@ When an epoch ends, which is about 24 hours, the rewards from all submitted Deli
 
 ## Delivery Acknowledgements (SNARKs)
 
-A Delivery Acknowledgement is a signed message by a client attesting that a node has successfully delivered a task to the client. These acknowledgments are instantly finalized locally and irreversible by the client.
+A Delivery Acknowledgement is a signed message by a client attesting that a node has successfully delivered a task to the client. These acknowledgements are instantly finalized locally and irreversible by the client.
 
 The Delivery Acknowledgements are cryptographically secured and tamper-proof, meaning that the transaction contains irrefutable details about all parts involved in the transaction.
 
 A Delivery Acknowledgement includes metadata about the commodities consumed by a node while executing or running a service. Also contains metadata that is used to determine the reward attributed to a Node.
 
 :::tip
-A Node provides the computational resources to the network and keeps track of doings in a list of Delivery Acknowledgements, on which the rewards mechanism is based at the end of each Epoch (about 24 hours).
+A Node provides the computational resources to the network and keeps track of doings in a list of Delivery Acknowledgements, on which the rewards' mechanism is based at the end of each Epoch (about 24 hours).
 :::
 
 Finally, Delivery Acknowledgements are gathered and batched by nodes before being submitted to the core protocol and committee as described in the [consensus](#consensus) section.
@@ -171,7 +171,7 @@ A developer is often described as a builder who enables the end-to-end experienc
 
 ### End-user
 
-An **End-user** is someone to whom the data or computation output is ultimately delivered, among others:
+An **End-user** is someone to whom the data or computation output is ultimately delivered, amongst others:
 
 - Static assets, such as images rendered on a website
 - Image optimization output for a very particular size request
@@ -243,7 +243,7 @@ The repository contains the source code for the implementation of the Fleek Netw
 
 ### Directory structure
 
-There are three top-level directories, namely `lib` , `core` and `services`.
+There are three top-level directories, namely `lib`, `core` and `services`.
 
 Lib - These are open-source libraries created to help tackle the project features and packaged with a friendly license in the Rust ecosystem (MIT, Apache).
 

docs/learn/token-and-economics.md

@@ -65,7 +65,7 @@ The TLDR of the current implementation being discussed is that the network will
 The algorithmic economic system has several goals, listed below in order of priority:
 
 - Provide an opportunity for receiving consistent blended earnings to node operators based on their work in most market conditions
-    - “Blended” means taking into account both the USD stablecoin fees that nodes are earning, as well as the FLK rewards they are earning (including factoring in the time-weighted average market price of FLK).
+    - “Blended” means taking into account both the USD stable coin fees that nodes are earning, and the FLK rewards they are earning (including factoring in the time-weighted average market price of FLK).
     - This means if network usage/revenue increases, FLK rewards will likely decrease, and vice versa. This also means that if the time-weighted average market price of FLK increases, nodes should reasonably expect that the amount of FLK rewards will decrease, but the value of FLK rewards received (in USD terms) will remain approximately the same.
 - Don’t overcompensate nodes, especially in times of market volatility
     - If the market price of FLK deviates from the NPV calculated in-protocol based on time-weighted average protocol-level revenue, nodes should reasonably expect that FLK rewards by number would be reduced.

docs/node/analyzing-logs.md

@@ -27,7 +27,7 @@ Standard out and standard error are two data streams created when we launch the
 By convention, most of the log files create on Linux are found under the directory `/var/log/`, a standard area where system messages are logged and recorded.
 :::
 
-Because normal output and error messages have their own channel, they can be handled independently of one another. Thus, we keep this in separate files that aggregate the output messages emited by the Lightning process.
+Because normal output and error messages have their own channel, they can be handled independently of one another. Thus, we keep this in separate files that aggregate the output messages emitted by the Lightning process.
 
 ## Watch logs
 

docs/node/install.md

@@ -366,7 +366,7 @@ cargo +stable build --release
 
 The installation process is long, as it compiles the application binary for us from the source code.
 
-🌈 Here's the output when successful! Note, that the output might differ slightly from time of writting.
+🌈 Here's the output when successful! Note, that the output might differ slightly from time of writing.
 
 ```sh
     Finished release [optimized] target(s) in 11m 22s
@@ -426,7 +426,7 @@ The keys will be generated and placed under the system directory `~/.lightning/k
 
 ### Set testnet in config.toml
 
-Set the testnet attribute to `true` in the `config.toml` lcated in the path `~/.lightning/config.toml`.
+Set the testnet attribute to `true` in the `config.toml` located in the path `~/.lightning/config.toml`.
 
 ```sh
 [application]
@@ -448,7 +448,7 @@ The configuration file should have more content, which was omitted here to keep
 To participate in the [alpha Testnet](/docs/roadmap), you have to through the onboarding process. Make sure you request access by following the [onboarding instructions](/docs/node/testnet-onboarding). If you fail to enable your node for testnet, it'll not run!
 :::
 
-To start the node, you should execute the sub-command `run`. Noteworthy that while it launches the node, you're recommended to setup a systemd service to run it for a long period.
+To start the node, you should execute the sub-command `run`. Noteworthy that while it launches the node, you're recommended to set up a systemd service to run it for a long period.
 
 ```sh
 lgtn run
@@ -573,7 +573,7 @@ sudo docker run \
 ```
 
 :::tip
-The command has a list of ports `-p` values that map ports in the container on the Docker host. While we try to keep the information accross our documentation in sync with latest changes or requirements e.g. port number changes, make sure that you check the section [ports](/docs/node/requirements#ports) to find the latest updates.
+The command has a list of ports `-p` values that map ports in the container on the Docker host. While we try to keep the information across our documentation in sync with the latest changes or requirements e.g. port number changes, make sure that you check the section [ports](/docs/node/requirements#ports) to find the latest updates.
 :::
 
 ### Build from source
@@ -595,7 +595,7 @@ sudo docker build -t lightning -f ./Dockerfile .
 ```
 
 :::tip
-Take note of the Docker image name `lightning`, as that's the name we'll use and pass to the `Docker run` to be succesfull. You can name it differently if that's your preference.
+Take note of the Docker image name `lightning`, as that's the name we'll use and pass to the `Docker run` to be successful. You can name it differently if that's your preference.
 :::
 
 Once the image is built, you can launch the Docker Container with a `--name` such as `lightning-node` from the `lightning` image we just created by running:
@@ -614,7 +614,7 @@ sudo docker run \
 ```
 
 :::tip
-The command has a list of ports `-p` values that map ports in the container on the Docker host. While we try to keep the information accross our documentation in sync with latest changes or requirements e.g. port number changes, make sure that you check the section [ports](/docs/node/requirements#ports) to find the latest updates.
+The command has a list of ports `-p` values that map ports in the container on the Docker host. While we try to keep the information across our documentation in sync with the latest changes or requirements e.g. port number changes, make sure that you check the section [ports](/docs/node/requirements#ports) to find the latest updates.
 :::
 
 If a `~/.lightning` directory or `~/.lightning/keystore` doesn't exist, one is created for you on `docker run`. You'll need to have the directory populated with the `config.toml` and `keystore` if you want to use a particular identity. Learn more about managing the keystore [here](/guides/Node%20Operators/managing-the-keystore).

docs/node/requirements.md

@@ -24,7 +24,7 @@ Only 64-bits distributions are supported. Do not try to install it on a 32-bits
 
 The Fleek Network node binary is only supported by a Linux server. Currently, we are only providing support for the following distros:
 - Debian (>= 11)
-- Ubuntu (>= 22.04 LTS  )
+- Ubuntu (>= 22.04 LTS)
 
 :::tip
 Support for other OS will be made available soon, e.g. CentOS and Fedora. Feel free to test running on older versions, but we reduce the number of versions to ease support and keep instructions less verbose, which should be easily translatable to your preferred OS Distro and Version. Any contributions to provide support for your favorite distro are welcomed! Feel free to [open a PR](https://github.com/fleek-network) in our repositories.

docs/node/systemd-service.md

@@ -15,7 +15,7 @@ import Author from '@site/src/components/Author';
 
 In this section we describe how to enable, disable, start, stop the Systemd Service.
 
-The service is setup by the [assisted installer](#assisted-installer) automatically, or manually as described in the [manual installation](/docs/node/install#manual-installation) and [docker install](/docs/node/install#docker-installation).
+The service is set up by the [assisted installer](#assisted-installer) automatically, or manually as described in the [manual installation](/docs/node/install#manual-installation) and [docker install](/docs/node/install#docker-installation).
 
 ### Reload the daemon
 
@@ -34,15 +34,15 @@ sudo systemctl enable lightning.service
 ```
 
 :::tip
-If you have installed or setup the Service as a Docker Container, prefix the service name with `docker-`.
+If you have installed or set up the Service as a Docker Container, prefix the service name with `docker-`.
 
 ```sh
 sudo systemctl enable docker-lightning
 ```
 :::
 
 :::caution
-You shouldn't have prefix the systemctl command with **sudo** when start/stop/status the service. Due to some VPS providers modifying the operating system, we had to present the examples prefixed with sudo for the wider audience. If you'd like to learn more about controlling Systemd services as a `user` check the reference [Systemd user-service](/references/Systemd/user-service).
+You shouldn't have prefixed the systemctl command with **sudo** when start/stop/status the service. Due to some VPS providers modifying the operating system, we had to present the examples prefixed with sudo for the wider audience. If you'd like to learn more about controlling Systemd services as a `user` check the reference [Systemd user-service](/references/Systemd/user-service).
 :::
 
 ### Disable
@@ -79,7 +79,7 @@ sudo systemctl start lightning
 
 
 :::tip
-If you have installed or setup the Service as a Docker Container, prefix the service name with `docker-`.
+If you have installed or set up the Service as a Docker Container, prefix the service name with `docker-`.
 
 ```sh
 sudo systemctl start docker-lightning
@@ -95,7 +95,7 @@ sudo systemctl stop lightning
 ```
 
 :::tip
-If you have installed or setup the Service as a Docker Container, prefix the service name with `docker-`.
+If you have installed or set up the Service as a Docker Container, prefix the service name with `docker-`.
 
 ```sh
 sudo systemctl stop docker-lightning
@@ -111,7 +111,7 @@ sudo systemctl restart lightning
 ```
 
 :::tip
-If you have installed or setup the Service as a Docker Container, prefix the service name with `docker-`.
+If you have installed or set up the Service as a Docker Container, prefix the service name with `docker-`.
 
 ```sh
 sudo systemctl restart docker-lightning
@@ -127,7 +127,7 @@ sudo systemctl status lightning.service
 ```
 
 :::tip
-If you have installed or setup the Service as a Docker Container, prefix the service name with `docker-`.
+If you have installed or set up the Service as a Docker Container, prefix the service name with `docker-`.
 
 ```sh
 sudo systemctl status docker-lightning