debridge-finance · boulderuphillroller · Nov 30, 2023
diff --git a/Test.md b/Test.md
@@ -5,13 +5,13 @@
 ### General requirements
 
 1. Oracles allowed to submit the data are set by the admin.
-2. The number of the required confirmatios is set by the admin.
+2. The number of the required confirmations is set by the admin.
 3. The contract holds the Links.
 4. The oracles receives the reward to their virtual balance after submission.
 5. The reward can be withdrawn any time.
-6. The admin can withdraw unalocated Links any time.
+6. The admin can withdraw unallocated Links any time.
 7. The oracle's payment can be configured by the admin.
-8. The mint and burnt requests are confirmed only after requered amount of confirmations are received.
+8. The mint and burnt requests are confirmed only after required amount of confirmations are received.
 
 ### Test Item: admin-only functions
 
@@ -26,7 +26,7 @@
 - [x] admin
 - [x] one without admin permissions
 
-**Scenario 2**: Withdraw unalocated Links:
+**Scenario 2**: Withdraw unallocated Links:
 
 - [x] admin
 - [x] one without admin permissions
@@ -80,7 +80,7 @@
 3. Only minters can create new tokens.
 4. Only minters can burn tokens.
 
-### Test Item: admint-only functions
+### Test Item: admit-only functions
 
 **Scope**: Test the minter functions of the contract.
 
@@ -137,7 +137,7 @@
 7. Part of the fee can be withdrawn.
 8. The aggregator can be replaced.
 9. The part of locked tokens can be used in DEFI protocol.
-10. The transfers must be confirmed by the oracles to be compleated.
+10. The transfers must be confirmed by the oracles to be completed.
 
 ### Test Item: admin-only actions
 
@@ -168,7 +168,7 @@
 - [x] new
 - [x] added before
 
-**Scope**: Test fee managemnet.
+**Scope**: Test fee management.
 
 **Action**: Invoke the `fundAggregator`, `withdrawFee` methods.
 
@@ -254,9 +254,9 @@
 - [x] with the current chain
 - [x] with the different chain
 
-**Scenario 2**: Call burn with diffrent amounts when:
+**Scenario 2**: Call burn with different amounts when:
 
-- [x] enough tokens are transfered
+- [x] enough tokens are transferred
 - [x] too few tokens are sent
 
 **Scope**: Test claim.
@@ -272,7 +272,7 @@
 
 **Scenario 2**: Call claim with different confirmations when:
 
-- [x] the burnt is confiremd
+- [x] the burnt is confirmed
 - [x] the burnt isn't confirmed
 
 **Scenario 3**: Call claim few times:
@@ -360,7 +360,7 @@
 6. Part of the fee can be withdrawn.
 7. The aggregator can be replaced.
 8. The part of locked tokens can be used in DEFI protocol.
-9. The transfers must be confirmed by the oracles to be compleated.
+9. The transfers must be confirmed by the oracles to be completed.
 
 ### Test Item: admin-only actions
 
@@ -391,7 +391,7 @@
 - [x] new
 - [x] added before
 
-**Scope**: Test fee managemnet.
+**Scope**: Test fee management.
 
 **Action**: Invoke the `fundAggregator`, `withdrawFee` methods.
 
@@ -467,9 +467,9 @@
 - [x] with the current chain
 - [ ] with the different chain
 
-**Scenario 2**: Call burn with diffrent amounts when:
+**Scenario 2**: Call burn with different amounts when:
 
-- [x] enough tokens are transfered
+- [x] enough tokens are transferred
 - [x] too few tokens are sent
 
 **Scope**: Test claim.
@@ -485,7 +485,7 @@
 
 **Scenario 2**: Call claim with different confirmations when:
 
-- [x] the burnt is confiremd
+- [x] the burnt is confirmed
 - [x] the burnt isn't confirmed
 
 **Scenario 3**: Call claim few times:
@@ -602,7 +602,7 @@
 
 **Scenario 1**: Call `executeUnstake`:
 
-- [x] noraml withdrawal id
+- [x] normal withdrawal id
 - [x] withdrawal id from future
 
 **Scope**: Test unstaking at the different time.

diff --git a/docs/contracts/libraries/Flags.md b/docs/contracts/libraries/Flags.md
@@ -33,7 +33,7 @@ First 24 bytes from data is gas limit for external call
 ```solidity
   uint256 public constant MULTI_SEND;
 ```
-Support multi send for externall call
+Support multi send for external call
 
 # Functions
 ## getFlag

diff --git a/docs/contracts/transfers/DeBridgeGate.md b/docs/contracts/transfers/DeBridgeGate.md
@@ -675,7 +675,7 @@ Unlock the asset on the current chain and transfer to receiver.
 | :--- | :--- | :------------------------------------------------------------------- |
 |`_debridgeId` | bytes32 | Asset identifier.
 |`_receiver` | bytes32 | Receiver address.
-|`_amount` | address | Amount of the transfered asset (note: the fee can be applyed).
+|`_amount` | address | Amount of the transferred asset (note: the fee can be applied).
 
 ## _mintOrTransfer
 ```solidity

diff --git a/docs/contracts/transfers/DeBridgeTokenDeployer.md b/docs/contracts/transfers/DeBridgeTokenDeployer.md
@@ -13,7 +13,7 @@ Address of deBridgeToken implementation
 ```solidity
   address public deBridgeTokenAdmin;
 ```
-An addres to set as admin for any deployed deBridgeToken
+An address to set as admin for any deployed deBridgeToken
 ## debridgeAddress
 ```solidity
   address public debridgeAddress;

diff --git a/docs/contracts/transfers/SignatureVerifier.md b/docs/contracts/transfers/SignatureVerifier.md
@@ -83,7 +83,7 @@ Sets minimal required confirmations.
   ) external
 ```
 
-Sets core debridge conrtact address.
+Sets core debridge contract address.
 
 ### Parameters:
 | Name | Type | Description                                                          |

diff --git a/docs/the-core-protocol/transfers.md b/docs/the-core-protocol/transfers.md
@@ -35,7 +35,7 @@ submissionId = keccak256(
 `debridgeID` is a hash of concatenation of the token native chain Id and native token address.
 
 * deBridge validation nodes track events emitted by `deBridgeGate` smart contract and after a minimum number of blocks confirmations validators submit the transfer identifier (submissionId) to the `deBridgeAggregator` contract in the target chain. `submissionId` is calculated as a hash of concatenation:
-* The user or any arbitrary waller (e.g. Keeper service) can call `claim` method of `deBridgeGate` by passing all transaction parameters and all valudators' signatures. Smart contract will restore `submissionId` based on the set of passed parameters and if minimal required number of validators signatures is valid, the transaction is treated by protocol as valid and the asset is minted/unlocked to the receiver address and data is executed through the callProxy.
+* The user or any arbitrary waller (e.g. Keeper service) can call `claim` method of `deBridgeGate` by passing all transaction parameters and all validators' signatures. Smart contract will restore `submissionId` based on the set of passed parameters and if minimal required number of validators signatures is valid, the transaction is treated by protocol as valid and the asset is minted/unlocked to the receiver address and data is executed through the callProxy.
 
 deBridge protocol supports **multi-chain routing** when users can transfer deAssets between secondary chains directly, without the need to route them through the native chain. These transfers work in the same way, but deAsset is burnt in the chain where the transfer is originated and the corresponding amount of deAsset is minted in the target chain