From 8d261072f1e58c5aea89e27cf48642601cacecfb Mon Sep 17 00:00:00 2001 From: Gas <86567384+gas1cent@users.noreply.github.com> Date: Wed, 10 Apr 2024 12:44:33 +0400 Subject: [PATCH] docs: proofreading Co-authored-by: moebius <132487952+0xmoebius@users.noreply.github.com> --- docs/src/content/modules/README.md | 4 ++-- docs/src/content/modules/response/bonded_response_module.md | 2 +- solidity/interfaces/modules/resolution/IArbitratorModule.sol | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/src/content/modules/README.md b/docs/src/content/modules/README.md index 660e69e8..18e5bdb9 100644 --- a/docs/src/content/modules/README.md +++ b/docs/src/content/modules/README.md @@ -12,8 +12,8 @@ Here you can find the list and the details of each module available in Prophet You can notice that many modules follow the same structure. This is because they all inherit from the `IModule` interface which defines the common functions and modifiers that all modules should have. - `moduleName` is required to properly show the module in Prophet UI. -- `RequestParameters` is what parameters are required for the request to be processed with the module. -- `decodeRequestData` decodes the ABI encoded parameters using the `RequestParameters` struct and returns them as a list. This is useful for both on-chain and off-chain parts. +- `RequestParameters` is which parameters are required for the request to be processed with the module. +- `decodeRequestData` decodes the ABI encoded parameters using the `RequestParameters` struct and returns them as a list. This is useful for both on-chain and off-chain components. ## Best Practices diff --git a/docs/src/content/modules/response/bonded_response_module.md b/docs/src/content/modules/response/bonded_response_module.md index bb66c690..fd313859 100644 --- a/docs/src/content/modules/response/bonded_response_module.md +++ b/docs/src/content/modules/response/bonded_response_module.md @@ -26,4 +26,4 @@ The Bonded Response Module is a contract that allows users to propose a response - **Early finalization**: It is possible for pre-dispute modules to atomically calculate the correct response on-chain, decide on the result of a dispute and finalize the request before its deadline. - **Dispute window**: Prevents proposers from submitting a response 1 block before the deadline and finalizing it in the next block, leaving disputers no time to dispute the response. -- **Unutilized response**: A correct response that has not been used to finalize the request. Consider what happens when the first response to a request is disputed maliciously and someone send a second response with the same content. In that case if the second response isn't disputed and the first one comes back from the dispute and is accepted as the final response, the second proposer should be able to get their bond back. +- **Unutilized response**: A correct response that has not been used to finalize the request. Consider what happens when the first response to a request is disputed maliciously and someone sends a second response with the same content. In that case if the second response isn't disputed and the first one comes back from the dispute and is accepted as the final response, the second proposer should be able to get his bond back. diff --git a/solidity/interfaces/modules/resolution/IArbitratorModule.sol b/solidity/interfaces/modules/resolution/IArbitratorModule.sol index 8b988f03..28544801 100644 --- a/solidity/interfaces/modules/resolution/IArbitratorModule.sol +++ b/solidity/interfaces/modules/resolution/IArbitratorModule.sol @@ -37,7 +37,7 @@ interface IArbitratorModule is IResolutionModule { * @notice Available status of the arbitration process * @param Unknown The arbitration process has not started (default) * @param Active The arbitration process is active - * @param ResolvedThe The arbitration process is finished + * @param Resolved The The arbitration process is finished */ enum ArbitrationStatus { Unknown,