fix(docs): grammar

Author: nikerzetic-aflabs

docs/smart-accounts/1-overview.mdx

@@ -21,7 +21,7 @@ import ThemedImage from "@theme/ThemedImage";
 import useBaseUrl from "@docusaurus/useBaseUrl";
 
 The Flare Smart Accounts is an account abstraction that allows XRPL users to perform actions on the Flare chain without owning any FLR token.
-Each XRPL address is assigned a unique **smart account** on the Flare chain, that only they can control.
+Each XRPL address is assigned a unique **smart account** on the Flare chain, which only it can control.
 They do so through `Payment` transactions on the XRPL.
 The Flare Smart Accounts are especially useful as a way of interacting with the FAssets workflow.
 
@@ -36,12 +36,12 @@ The workflow for Flare Smart Accounts is comprised of the following steps.
 
 ## 1. Instructions on XRPL
 
-The Flare Smart Accounts allows XRPL users to perform actions on the Flare chain through instructions on the XRPL.
+The Flare Smart Accounts allow XRPL users to perform actions on the Flare chain through instructions on the XRPL.
 This is done through a `Payment` to an XRPL address, designated by the operator - a backend monitoring incoming transactions and interacting with the Flare chain.
 The payment must transfer sufficient funds, as specified by the operator, and must include the proper payment receipt in the memo field.
 
 The payment receipt is a `bytes32` value.
-The first byte is reserved for the instructions code, a byte-representation of a two-digit number.
+The first byte is reserved for the instruction code, a byte representation of a two-digit number.
 The remaining 31 bytes are the parameters for the chosen instruction.
 
 In practice, the payment receipt should be prepared by a backend, through a web form.

docs/smart-accounts/2-fasset-instructions.mdx

@@ -20,23 +20,23 @@ unlisted: false
 import ThemedImage from "@theme/ThemedImage";
 import useBaseUrl from "@docusaurus/useBaseUrl";
 
-In this guide we will take a closer look at the Flare Smart Accounts instructions related to FAssets.
+In this guide, we will take a closer look at the Flare Smart Accounts instructions related to FAssets.
 FAsset is a trustless, over-collateralized bridge between XRPL and the Flare chain.
 The FXRP is a token representation of XRP on the Flare chain.
 FAssets allow XRPL users to partake in Flare's DeFi ecosystem using their XRP assets, without exchanging them for the FLR token.
 
-Several steps of the FAsset process are performed as transactions on the Flare chain, which requires users to hold FLR token for paying gas fees.
+Several steps of the FAsset process are performed as transactions on the Flare chain, which requires users to hold FLR tokens for paying gas fees.
 The Flare Smart Accounts sidestep this by allowing XRPL users to trigger these actions through `Payment` transactions on XRPL.
 Thus, they eradicate completely the need for XRPL users to hold any non-XRPL assets.
 
 You can learn more about the FAssets in the [dedicated section](/fassets/overview/).
 
 ## `01` Deposit
 
-Deposit an `amount` of FXRP from you account into the Firelight vault `depositVault`.
+Deposit an `amount` of FXRP from your account into the Firelight vault `depositVault`.
 The address `depositVault` is designated by the `MasterAccountController` contract, and the `amount` is read from the last 31 bytes of the payment reference.
 
-A deposit payment reference is the 32 byte value:
+A deposit payment reference is the 32-byte value:
 
 - byte representation of `02` on the first byte,
 - byte representation of the `amount` number on the other 31 bytes.
@@ -66,7 +66,7 @@ The first part of the withdrawal process from a Firelight vault.
 Initiate a withdrawal request of an `amount` of FXRP from the Firelight vault `depositVault`.
 The address `depositVault` is designated by the `MasterAccountController` contract, and the `amount` is read from the last 31 bytes of the payment reference.
 
-A withdraw payment reference is the 32 byte value:
+A withdraw payment reference is the 32-byte value:
 
 - byte representation of `02` on the first byte,
 - byte representation of the `amount` number on the other 31 bytes.
@@ -91,12 +91,12 @@ A withdraw payment reference is the 32 byte value:
 
 ## `03` Approve (deprecated)
 
-_Approval has been made part of the deposit actions and is now deprecated._
+_Approval has been integrated into the deposit action and is now deprecated._
 
 Approve the `depositVault` address to withdraw an `amount` of FXRP from your smart account.
 The address `depositVault` is designated by the `MasterAccountController` contract, and the `amount` is read from the last 31 bytes of the payment reference.
 
-A withdraw payment reference is the 32 byte value:
+A withdraw payment reference is the 32-byte value:
 
 - byte representation of `03` on the first byte,
 - byte representation of the `amount` number on the other 31 bytes.
@@ -122,13 +122,13 @@ A withdraw payment reference is the 32 byte value:
 ## `04` Redeem
 
 Redemption is the process of converting FXRP back to XRP.
-A number of `lots` of FXRP are burned, and the same number of `lots` of XRP in returned to the user's XRPL account.
+A number of `lots` of FXRP are burned, and the same number of `lots` of XRP is returned to the user's XRPL account.
 
 The process is performed by an `executor` with `executorFee` (explained in the [minting guide](/fassets/minting#executor-role));
 both of these are defined by the `MasterAccountController` contract.
 The `lots` and `agentVault` values are both read from the payment reference.
 
-A redeem payment reference is the 32 byte value:
+A redeem payment reference is the 32-byte value:
 
 - byte representation of `04` on the first byte,
 - 19 empty bytes,
@@ -155,15 +155,15 @@ A redeem payment reference is the 32 byte value:
 ## `05` Reserve collateral
 
 Collateral reservation is the first step in the FAssets minting process.
-In anticipation of transfer of XRP to the agent's underlying address on XRPL a portion of its collateral is locked to prevent accidental under-collateralization.
+In anticipation of the transfer of XRP to the agent's underlying address on XRPL, a portion of its collateral is locked to prevent accidental under-collateralization.
 Since this action happens on the Flare chain, the gas fees need to be paid in the native FLR token.
 
 The reserveCollateral action reserves a number of `lots` of collateral of the `agentVault`.
 The process is performed by an `executor` with `executorFee` (explained in the [minting guide](/fassets/minting#executor-role));
 both of these are defined by the `MasterAccountController` contract.
 The `lots` and `agentVault` values are both read from the payment reference.
 
-A reserveCollateral payment reference is a 32 byte value:
+A reserveCollateral payment reference is a 32-byte value:
 
 - byte representation of `05` on the first byte,
 - `agentVault` address on the next 20 bytes,
@@ -194,7 +194,7 @@ Claim the pending withdrawal from the Firelight `depositVault`, specified by the
 The assets are transferred to the user's smart account.
 The action can only be performed after one full period has passed.
 
-A reserveCollateral payment reference is a 32 byte value:
+A reserveCollateral payment reference is a 32-byte value:
 
 - byte representation of `06` on the first byte,
 - 31 empty bytes.

docs/smart-accounts/3-custom-instruction.mdx

@@ -20,12 +20,12 @@ unlisted: false
 import ThemedImage from "@theme/ThemedImage";
 import useBaseUrl from "@docusaurus/useBaseUrl";
 
-Flare Smart Accounts allow users to execute custom function calls on the Flare chain, through instructions on XRPL.
+Flare Smart Accounts allow users to execute custom function calls on the Flare chain through instructions on XRPL.
 The process expands on the workflow for other actions by including an additional step at the beginning.
 
 In order for the `MasterAccountController` contract to be able to give a custom instruction to a personal account, the custom action must first be registered with the said contract.
-The custom instruction is stored in a mapper, with its 31 byte hash as a key.
-That hash is then sent as payment reference, along with the byte representation of the number 99 in the first byte.
+The custom instruction is stored in a mapper, with its 31-byte hash as a key.
+That hash is then sent as the payment reference, along with the byte representation of the number 99 in the first byte.
 
 <div
   style={{
@@ -74,7 +74,7 @@ In Solidity, we can obtain the calldata by doing the following:
 abi.encodeWithSignature("<functionName>(<type1>,<type2>,...,<typeN>)", [<value1>, <value2>, ..., <valueN>]);
 ```
 
-where `<functionName>` is the name of the function that we want to call, `<type1>`,`<type2>`, . . . ,`<typeN>` are its argument types, and `<value1>`, `<value2>`, . . . , `<valueN>` their values.
+where `<functionName>` is the name of the function that we want to call, `<type1>`, `<type2>`, . . . , `<typeN>` are its argument types, and `<value1>`, `<value2>`, . . . , `<valueN>` their values.
 
 Only function calls with specific parameter values included can be registered.
 That means that a new custom instruction needs to be registered for each unique action (though this can be done just seconds in advance).
@@ -84,10 +84,10 @@ It is also the reason why special FAsset actions have their own IDs, instead of
 
 To produce the custom instructions calldata, we first ABI encode the array of the `IMasterAccountController.CustomInstruction` struct.
 We then take the `keccak256` hash of that value, and drop the last byte.
-That is the call hash that that is provided as the payment reference for the custom action, and the ID under which the custom instructions are stored in the `MasterAccountController` contract.
+That is the call hash that is provided as the payment reference for the custom action, and the ID under which the custom instructions are stored in the `MasterAccountController` contract.
 
 ## 0. Register custom instructions
 
 We register a custom instruction by calling the `registerCustomInstruction` function on the `MasterAccountController` contract.
 The `IMasterAccountController.CustomInstruction` array is provided as an argument.
-It is encoded as described above, and stored to a `CustomInstructions` mapping.
+It is encoded as described above and stored in a `CustomInstructions` mapping.