diff --git a/docs/src/SUMMARY.md b/docs/src/SUMMARY.md index 616e91f1..ab9db97b 100644 --- a/docs/src/SUMMARY.md +++ b/docs/src/SUMMARY.md @@ -35,7 +35,6 @@ - [BondEscalationResolutionModule](content/modules/resolution/bond_escalation_resolution_module.md) - [ERC20ResolutionModule](content/modules/resolution/erc20_resolution_module.md) - [PrivateERC20ResolutionModule](content/modules/resolution/private_erc20_resolution_module.md) - - [SequentialResolutionModule](content/modules/resolution/sequential_resolution_module.md) - [Finality](content/modules/finality.md) - [CallbackModule](content/modules/finality/callback_module.md) @@ -56,8 +55,6 @@ - [Interfaces]() - [❱ core](solidity/interfaces/core/README.md) - - [❱ external](solidity/interfaces/core/external/README.md) - - [IWETH9](solidity/interfaces/core/external/IWETH9.sol/interface.IWETH9.md) - [❱ modules](solidity/interfaces/core/modules/README.md) - [❱ dispute](solidity/interfaces/core/modules/dispute/README.md) - [IDisputeModule](solidity/interfaces/core/modules/dispute/IDisputeModule.sol/interface.IDisputeModule.md) diff --git a/docs/src/content/core/module.md b/docs/src/content/core/module.md index 7d7049ec..312449ac 100644 --- a/docs/src/content/core/module.md +++ b/docs/src/content/core/module.md @@ -1,26 +1,14 @@ # Module -See [IModule.sol](/solidity/interfaces/IModule.sol/interface.IModule.md) for more details. +See [IModule.sol](/solidity/interfaces/core/IModule.sol/interface.IModule.md) for more details. -## 1. Introduction +`Module` is an abstract contract that defines common functions and modifiers. A module is supposed to inherit the abstract contract and implement specific logic in one of the hooks, for example `finalizeRequest`. All public functions in the contract are callable only by the oracle, and there are internal functions ensuring the integrity of the data being passed around, such as `_validateResponse` and `_validateDispute`. -`Module` is an abstract contract that defines common functions and modifiers. A module is supposed to inherit the abstract contract and implement specific logic in one of the hooks, for example `_afterSetupRequest`. +In addition to the abstract contact, we've created interfaces for each type of module: +- [IRequestModule](/solidity/interfaces/core/modules/request/IRequestModule.sol/interface.IRequestModule.md) +- [IResponseModule](/solidity/interfaces/core/modules/response/IResponseModule.sol/interface.IResponseModule.md) +- [IDisputeModule](/solidity/interfaces/core/modules/dispute/IDisputeModule.sol/interface.IDisputeModule.md) +- [IResolutionModule](/solidity/interfaces/core/modules/resolution/IResolutionModule.sol/interface.IResolutionModule.md) +- [IFinalityModule](/solidity/interfaces/core/modules/finality/IFinalityModule.sol/interface.IFinalityModule.md) -## 2. Contract Details - -### Key Methods - -All public functions in the abstract contract are callable only by the oracle. - -- `setupRequest` is a hook executed on request creation. Apart from saving the request data in the module, it can run can run validations, bond funds or perform any other action specified in the `_afterSetupRequest` function. -- `finalizeRequest` is a hook executed on request finalization. It's vital to remember that there are [2 ways of finalizing a request](oracle.md#finalization) and this function must handle both of them. - -## 3. Key Mechanisms & Concepts - -### Request Data - -The `requestData` is a mapping that associates each request's unique identifier (`requestId`) with its corresponding parameters. This mapping is public, allowing for the data of any request to be accessed using its ID. - -## 4. Gotchas - -It's worth noting that if a module does not implement a hook, it will still be called by the oracle. +Each of them inherits the `IModule` interface and adds additional functions specific to the module type. diff --git a/docs/src/content/core/oracle.md b/docs/src/content/core/oracle.md index 57b9614e..a3f48409 100644 --- a/docs/src/content/core/oracle.md +++ b/docs/src/content/core/oracle.md @@ -1,6 +1,6 @@ # Oracle -See [IOracle.sol](/solidity/interfaces/IOracle.sol/interface.IOracle.md) for more details. +See [IOracle.sol](/solidity/interfaces/core/IOracle.sol/interface.IOracle.md) for more details. ## 1. Introduction @@ -18,34 +18,35 @@ The Oracle does not handle any transfers, utilizing the extensions for that func ### Key Methods - `createRequest`: Creates a new request. +- `createRequests`: Creates multiple requests at once. - `proposeResponse`: Proposes a response to a request. - `disputeResponse`: Disputes a response to a request. -- `deleteResponse`: Deletes a response to a request. - `escalateDispute`: Escalates a dispute to the next level. +- `resolveDispute`: Stores the resolution outcome and changes the dispute status. - `updateDisputeStatus`: Updates the status of a dispute. - `finalize`: Finalizes a request. ## 3. Key Mechanisms & Concepts -### Request vs Full Request vs New Request +### Stored data -The oracle defines 3 structures representing a request: +The oracle keeps almost no data in storage, instead relying on events to help off-chain agents track the state of requests, responses and disputes. + +### Request, response, dispute IDs +The IDs are calculated as keccak256 hash of the request, response or dispute data. This allows for easy verification of the data integrity and uniqueness. -- `Request` which is stored in `_requests` mapping. It includes the addresses of the modules and additional information like the requester address and the creation and finalization timestamps. It can be retrieved with `getRequest` function. -- `FullRequest` unlike the Request struct, this one also includes the data used to configure the modules. `getFullRequest` function can be used to retrieve it. -- `NewRequest` is a struct used in `createRequest`. It lacks the timestamps and the requester address, which are set by the oracle, but includes the modules data. ### Finalization The oracle supports 2 ways of finalizing a request. -1. In case there is a non-disputed response, the request can be finalized by calling `finalize` function and providing the response ID. The oracle will call `finalizeRequest` on the modules and mark the request as finalized. Generally the `finalizeRequest` hook will issue the reward to the proposer. +1. In case there is a non-disputed response, the request can be finalized by calling `finalize` function and providing the final response. The oracle will call `finalizeRequest` on the modules and mark the request as finalized. Usually the `finalizeRequest` hook will issue the reward to the proposer. -2. If no responses have been submitted, or they're all disputed, the request can be finalized by calling `finalize` function without a response ID. The same hook will be executed in all modules, refunding the requester and marking the request as finalized. +2. If no responses have been submitted, or they're all disputed, the request can be finalized by calling `finalize` function with a response that has its request ID set to 0. The same hook will be executed in all modules, refunding the requester and marking the request as finalized. ## 4. Gotchas ### Request misconfiguration -Due to the modular and open nature of the framework, the oracle does not have any rules or validations, and a request is deemed correct unless it reverts on creation (`setupRequest`). It’s the requester’s responsibility to choose sensible parameters and avoid the request being unattractive to proposers and disputers, impossible to answer or finalize. +Due to the modular and open nature of the framework, the oracle does not have any rules or validations, and a request is deemed correct unless it reverts on creation (`createRequest` hook). It’s the requester’s responsibility to choose sensible parameters and avoid the request being unattractive to proposers and disputers, impossible to answer or finalize. The same can be said about engaging with a request. Off-chain validation must be done prior to proposing or disputing any response to avoid the loss of funds. We strongly encourage keeping a list of trusted modules and extensions and avoid interactions with unverified ones. diff --git a/docs/src/content/extensions/accounting.md b/docs/src/content/extensions/accounting.md index c03dcb7b..bcd1ba87 100644 --- a/docs/src/content/extensions/accounting.md +++ b/docs/src/content/extensions/accounting.md @@ -10,23 +10,23 @@ The Accounting Extension is a contract that allows users to deposit and bond fun ### Key Methods -- `deposit(IERC20 _token, uint256 _amount)`: This function allows a user to deposit a specific amount of a token into the accounting extension. If ETH is being deposited, it is wrapped to WETH. -- `withdraw(IERC20 _token, uint256 _amount)`: By calling this function, a user can withdraw a specific amount of a token from the accounting extension. -- `bond(address _bonder, bytes32 _requestId, IERC20 _token, uint256 _amount)`: This function allows a user to lock a specific amount of a token for a specific request. The tokens stay in the accounting extension and will not be withdrawable until they are released by a module. -- `release(address _bonder, bytes32 _requestId, IERC20 _token, uint256 _amount)`: This function allows a module to release a specific amount of a token that was previously bonded to a request. The tokens will be moved back to the user's balance. -- `pay(bytes32 _requestId, address _payer, address _receiver, IERC20 _token, uint256 _amount)`: Transfers a specific amount of a bonded token from the payer to the receiver. This function can only be called by a module. +- `deposit`: Allows a user to deposit a specific amount of a token into the accounting extension. If ETH is being deposited, it is wrapped to WETH. +- `withdraw`: By calling this function, a user can withdraw a specific amount of a token from the accounting extension. +- `bond`: Allows a user to lock a specific amount of a token for a specific request. The tokens stay in the accounting extension and will not be withdrawable until they are released by a module. +- `release`: Allows a module to release a specific amount of a token that was previously bonded to a request. The tokens will be moved back to the user's balance. +- `pay`: Transfers a specific amount of a bonded token from the payer to the receiver. This function can only be called by a module. ## 3. Key Mechanisms & Concepts -- Deposits: Users can deposit tokens into the Accounting Extension. These deposits are tracked in a mapping that associates each user's address with their balance of each token. Deposits can be made in any ERC20 token, including wrapped Ether (WETH). +- **Deposits**: Users can deposit tokens into the Accounting Extension. These deposits are tracked in a mapping that associates each user's address with their balance of each token. Deposits can be made in any ERC20 token, including wrapped Ether (WETH). -- Withdrawals: Users can withdraw their deposited tokens at any time, provided they have sufficient balance. The withdrawal operation reduces the user's balance in the Accounting Extension and transfers the tokens back to the user's address. Locked tokens can't be withdrawn until they're released by a module. +- **Withdrawals**: Users can withdraw their deposited tokens at any time, provided they have sufficient balance. The withdrawal operation reduces the user's balance in the Accounting Extension and transfers the tokens back to the user's address. Locked tokens can't be withdrawn until they're released by a module. -- Bonding: Users can lock their tokens up for to be allowed to participate in a request. Tokens stay in the accounting extension but they cannot be withdrawn until the request is finalized or the tokens are released. +- **Bonding**: Users can lock their tokens up to be allowed to participate in a request. Tokens stay in the accounting extension but they cannot be withdrawn until the request is finalized or the tokens are released. -- Payments: The Accounting Extension allows for payments to be made from one user to another. This usually means rewards for correct proposers and disputers and slashing malicious actors. It's done by unlocking and transferring the bonded tokens from the payer to the receiver's balance. Payments can only be initiated by modules. +- **Payments**: The Accounting Extension allows for payments to be made from one user to another. This usually means rewards for correct proposers and disputers and slashing malicious actors. It's done by unlocking and transferring the bonded tokens from the payer to the receiver's balance. Payments can only be initiated by modules. -- Releasing Bonds: Bonds can be released by allowed modules, which moves the bonded tokens back to the user's balance, making them available for withdrawal or bonding to a different request. +- **Releasing Bonds**: Bonds can be released by allowed modules, which moves the bonded tokens back to the user's balance, making them available for withdrawal or bonding to a different request. ## 4. Gotchas diff --git a/docs/src/content/extensions/bond_escalation_accounting.md b/docs/src/content/extensions/bond_escalation_accounting.md index 0f487081..3c188103 100644 --- a/docs/src/content/extensions/bond_escalation_accounting.md +++ b/docs/src/content/extensions/bond_escalation_accounting.md @@ -10,12 +10,12 @@ The `BondEscalationAccounting` contract is an extension that allows users to dep ### Key Methods -- `deposit`: This function allows a user to deposit a specific amount of a token into the accounting extension. If ETH is being deposited, it is wrapped to WETH. +- `deposit`: Allows a user to deposit a specific amount of a token into the accounting extension. If ETH is being deposited, it is wrapped to WETH. - `withdraw`: By calling this function, a user can withdraw a specific amount of a token from the accounting extension. -- `pledge`: This function allows a user to pledge a certain amount of tokens for a specific dispute. The pledged tokens are deducted from the user's balance and added to the total pledges for the dispute. -- `settleBondEscalation`: This function unlocks the rewards for the winners. +- `pledge`: Allows a user to pledge a certain amount of tokens for a specific dispute. The pledged tokens are deducted from the user's balance and added to the total pledges for the dispute. +- `onSettleBondEscalation`: Unlocks the rewards for the winners. - `claimEscalationReward`: Calculates and transfers the caller's part of the reward to them. -- `releasePledge`: This function allows a module to release a user's tokens. +- `releasePledge`: Allows a module to release a user's tokens. ## 3. Key Mechanisms & Concepts diff --git a/docs/src/content/intro/README.md b/docs/src/content/intro/README.md index 221457fc..f859d9fb 100644 --- a/docs/src/content/intro/README.md +++ b/docs/src/content/intro/README.md @@ -3,11 +3,11 @@ Prophet presents a versatile and fully adaptable optimistic oracle solution, transcending the boundaries of conventional dispute resolution modules. With its emphasis on complete control and modularity across all aspects of the system, Prophet is an open-source public good for the Optimism community. ## Useful links -- Explorer [https://prophet.tech/](https://prophet.tech/) -- Discord -- Documentation [https://docs.prophet.tech](https://docs.prophet.tech) -- SDK Documentation -- Dune Dashboard +- [Explorer](https://prophet.tech/) +- [Discord](https://discord.gg/hhvA9CuQRR) +- [Documentation](https://docs.prophet.tech) + +- [Dune Dashboard](https://dune.com/defi_wonderland/prophet-metrics) ### Repositories - [Core Contracts](https://github.com/defi-wonderland/prophet-core) @@ -17,7 +17,26 @@ Prophet presents a versatile and fully adaptable optimistic oracle solution, tra - [SDK](https://github.com/defi-wonderland/prophet-sdk) ## Deployments - +The addresses of the contracts deployed on Optimism Goerli are listed below. + +| Contract | Goerli | +| -------- | ------ | +| [Oracle](/solidity/interfaces/core/IOracle.sol/interface.IOracle.md) | [`0x0000000000000000000000000000000000000000`](https://goerli-optimism.etherscan.io/address/0x0000000000000000000000000000000000000000) | +| [AccountingExtension](/solidity/interfaces/extensions/IAccountingExtension.sol/interface.IAccountingExtension.md) | [`0x0000000000000000000000000000000000000000`](https://goerli-optimism.etherscan.io/address/0x0000000000000000000000000000000000000000) | +| [BondEscalationAccounting](/solidity/interfaces/extensions/IBondEscalationAccounting.sol/interface.IBondEscalationAccounting.md) | [`0x0000000000000000000000000000000000000000`](https://goerli-optimism.etherscan.io/address/0x0000000000000000000000000000000000000000) | +| [HttpRequestModule](/solidity/interfaces/modules/request/IHttpRequestModule.sol/interface.IHttpRequestModule.md) | [`0x0000000000000000000000000000000000000000`](https://goerli-optimism.etherscan.io/address/0x0000000000000000000000000000000000000000) | +| [ContractCallRequestModule](/solidity/interfaces/modules/request/IContractCallRequestModule.sol/interface.IContractCallRequestModule.md) | [`0x0000000000000000000000000000000000000000`](https://goerli-optimism.etherscan.io/address/0x0000000000000000000000000000000000000000) | +| [SparseMerkleTreeRequestModule](/solidity/interfaces/modules/request/ISparseMerkleTreeRequestModule.sol/interface.ISparseMerkleTreeRequestModule.md) | [`0x0000000000000000000000000000000000000000`](https://goerli-optimism.etherscan.io/address/0x0000000000000000000000000000000000000000) | +| [BondedResponseModule](/solidity/interfaces/modules/response/IBondedResponseModule.sol/interface.IBondedResponseModule.md) | [`0x0000000000000000000000000000000000000000`](https://goerli-optimism.etherscan.io/address/0x0000000000000000000000000000000000000000) | +| [BondedDisputeModule](/solidity/interfaces/modules/dispute/IBondedDisputeModule.sol/interface.IBondedDisputeModule.md) | [`0x0000000000000000000000000000000000000000`](https://goerli-optimism.etherscan.io/address/0x0000000000000000000000000000000000000000) | +| [BondEscalationModule](/solidity/interfaces/modules/dispute/IBondEscalationModule.sol/interface.IBondEscalationModule.md) | [`0x0000000000000000000000000000000000000000`](https://goerli-optimism.etherscan.io/address/0x0000000000000000000000000000000000000000) | +| [CircuitResolverModule](/solidity/interfaces/modules/dispute/ICircuitResolverModule.sol/interface.ICircuitResolverModule.md) | [`0x0000000000000000000000000000000000000000`](https://goerli-optimism.etherscan.io/address/0x0000000000000000000000000000000000000000) | +| [RootVerificationModule](/solidity/interfaces/modules/dispute/IRootVerificationModule.sol/interface.IRootVerificationModule.md) | [`0x0000000000000000000000000000000000000000`](https://goerli-optimism.etherscan.io/address/0x0000000000000000000000000000000000000000) | +| [ArbitratorModule](/solidity/interfaces/modules/resolution/IArbitratorModule.sol/interface.IArbitratorModule.md) | [`0x0000000000000000000000000000000000000000`](https://goerli-optimism.etherscan.io/address/0x0000000000000000000000000000000000000000) | +| [BondEscalationResolutionModule](/solidity/interfaces/modules/resolution/IBondEscalationResolutionModule.sol/interface.IBondEscalationResolutionModule.md) | [`0x0000000000000000000000000000000000000000`](https://goerli-optimism.etherscan.io/address/0x0000000000000000000000000000000000000000) | +| [ERC20ResolutionModule](/solidity/interfaces/modules/resolution/IERC20ResolutionModule.sol/interface.IERC20ResolutionModule.md) | [`0x0000000000000000000000000000000000000000`](https://goerli-optimism.etherscan.io/address/0x0000000000000000000000000000000000000000) | +| [PrivateERC20ResolutionModule](/solidity/interfaces/modules/resolution/IPrivateERC20ResolutionModule.sol/interface.IPrivateERC20ResolutionModule.md) | [`0x0000000000000000000000000000000000000000`](https://goerli-optimism.etherscan.io/address/0x0000000000000000000000000000000000000000) | + ## Licensing diff --git a/docs/src/content/intro/framework.md b/docs/src/content/intro/framework.md index b241ece8..8943d894 100644 --- a/docs/src/content/intro/framework.md +++ b/docs/src/content/intro/framework.md @@ -36,11 +36,11 @@ At any time, a request will be in one of the following states ### Response -A response is a proposed answer to a request. The submission is open for anyone matching the criteria defined in the response module. For instance it could be an NFT holder, an address with a sufficient bond or an entity from a list of approved addresses. An undisputed response can be retracted by the proposer to give them a chance to correct a mistake. +A response is a proposed answer to a request. The submission is open for anyone matching the criteria defined in the response module. For instance it could be an NFT holder, an address with a sufficient bond or an entity from a list of approved addresses. ### Dispute -Disputes are the core mechanism of an optimistic oracle protecting it from malicious actors. A dispute can be raised by anyone meeting the requirements exposed by the dispute module of a particular request. A multitude of options is available for the dispute module, from simple voting to more complex mechanisms. +Disputes are the core mechanism of an optimistic oracle protecting it from malicious actors. A dispute can be raised by anyone meeting the requirements imposed by the dispute module of a particular request. A multitude of options is available for the dispute module, from simple voting to more complex mechanisms. Dispute modules are designed to reduce the number of calls to the resolution modules, for instance by allowing a bond escalation period before the dispute is escalated to the resolution module. @@ -58,11 +58,7 @@ Modules are the lego blocks for requests. They're responsible for the logic of t Since building a module is permissionless, the users should pay extra attention to the contracts they choose to interact with, verify their safety and compatibility with other modules. -Module-specific logic should be implemented in hooks such as -- `setupRequest` -- `afterSetupRequest` -- `finalizeRequest` -- `deleteResponse` +Module-specific logic should be implemented in hooks such as `createRequest` and `finalizeRequest`, that are called by the oracle contract when setting up or finalizing a request. They can be used to implement custom logic, such as storing the data in a custom format or sending a notification to a user. ### Extensions diff --git a/docs/src/content/intro/prophet.md b/docs/src/content/intro/prophet.md deleted file mode 100644 index 3352a321..00000000 --- a/docs/src/content/intro/prophet.md +++ /dev/null @@ -1,7 +0,0 @@ -# Introduction to Prophet - -Prophet presents a versatile and fully adaptable optimistic oracle solution, transcending the boundaries of conventional dispute resolution modules. - -It moves away from a one-fits-all resolution system and provides customizable modules that can be fine-tuned to meet the unique requirements of each user. - -With its emphasis on complete control and modularity across all aspects of the system, Prophet is an open-source public good for the Optimism community. diff --git a/docs/src/content/libraries/merkle_lib.md b/docs/src/content/libraries/merkle_lib.md index 279f2f87..ca6ea8d4 100644 --- a/docs/src/content/libraries/merkle_lib.md +++ b/docs/src/content/libraries/merkle_lib.md @@ -10,7 +10,7 @@ The library is a part of the [Connext monorepo](https://github.com/connext/monor ### Key Methods -- `insert(Tree memory tree, bytes32 node)`: This function inserts a given node (leaf) into the Merkle tree. It operates on an in-memory tree and returns an updated version of that tree. If the tree is already full, it reverts the transaction. +- `insert`: Inserts a given node (leaf) into the Merkle tree. It operates on an in-memory tree and returns an updated version of that tree. If the tree is already full, it reverts the transaction. ## 3. Key Mechanisms & Concepts diff --git a/docs/src/content/modules/dispute.md b/docs/src/content/modules/dispute.md index a72f974a..7f0f5997 100644 --- a/docs/src/content/modules/dispute.md +++ b/docs/src/content/modules/dispute.md @@ -12,13 +12,13 @@ In Prophet, examples of Dispute modules include: ## Dispute Types -- Pre-dispute: This type of Dispute modules aims to settle disputes before they reach the Resolution module. `BondEscalationModule` is an example of a pre-dispute module. +- **Pre-dispute**: This type of Dispute modules aims to settle disputes before they reach the Resolution module. `BondEscalationModule` is an example of a pre-dispute module. -- Atomical dispute: This type of dispute relies on an external contract to atomically resolve the dispute as soon as it's started. In this case the Resolution module might not be needed at all. `CircuitResolverModule` and `RootVerificationModule` are examples of atomical dispute modules. +- **Atomical dispute**: This type of dispute relies on an external contract to atomically resolve the dispute as soon as it's started. In this case the Resolution module might not be needed at all. `CircuitResolverModule` and `RootVerificationModule` are examples of atomical dispute modules. ## Developing a Dispute Module -When developing a Dispute module, you should: +When developing a Dispute module, after inheriting the [`IDisputeModule`](/solidity/interfaces/core/modules/dispute/IDisputeModule.sol/interface.IDisputeModule.md) interface, you should: - Define the criteria for challengers to be able to initiate a dispute - Set the rules for the disputes, such as validations or deadlines diff --git a/docs/src/content/modules/dispute/bond_escalation_module.md b/docs/src/content/modules/dispute/bond_escalation_module.md index 59187b8d..d2bccb86 100644 --- a/docs/src/content/modules/dispute/bond_escalation_module.md +++ b/docs/src/content/modules/dispute/bond_escalation_module.md @@ -10,29 +10,31 @@ The Bond Escalation Module is a contract that allows users to have the first dis ### Key Methods -- `disputeResponse(bytes32 _requestId, bytes32 _responseId, address _disputer, address _proposer)`: This function is called to dispute a response and start the bond escalation process. In case of a second and subsequent disputes, the function bonds the disputer's funds but does not start the bond escalation. -- `disputeEscalated(bytes32 _disputeId)`: This function is called when a dispute has been escalated, putting the bond escalation on hold. It is only possible if there is a tie between the sides of the dispute. -- `pledgeForDispute(bytes32 _disputeId)`: This function allows a user to pledge in favor of a dispute. -- `pledgeAgainstDispute(bytes32 _disputeId)`: This function allows a user to pledge against a dispute. -- `settleBondEscalation(bytes32 _requestId)`: This function settles the bond escalation process of a given request, allowing the winning pledgers to withdraw their funds from the bond escalation accounting extension. +- `decodeRequestData`: Decodes request parameters. +- `disputeResponse`: Start the bond escalation process. In case of a second and subsequent disputes, the function bonds the disputer's funds but does not start the bond escalation, instead escalating the dispute to the resolution module. +- `onDisputeStatusChange`: Handles any changes in the status of a dispute, pays the winning party. +- `disputeEscalated`: Called when a dispute has been escalated, putting the bond escalation on hold. It is only possible if there is a tie between the sides of the dispute. +- `pledgeForDispute`: Lets a user pledge in favor of a dispute. +- `pledgeAgainstDispute`: Lets a user pledge against a dispute. +- `settleBondEscalation`: Settles the bond escalation process of a given request, allowing the winning pledgers to withdraw their funds from the bond escalation accounting extension. ### Request Parameters - `accountingExtension`: The address of the accounting extension associated with the given request. - `bondToken`: The address of the token associated with the given request. - `bondSize`: The amount to bond to dispute or propose an answer for the given request. -- `numberOfEscalations`: The maximum allowed escalations or pledges for each side during the bond escalation process. +- `maxNumberOfEscalations`: The maximum allowed escalations or pledges for each side during the bond escalation process. - `bondEscalationDeadline`: The timestamp at which bond escalation process finishes when pledges are not tied. - `tyingBuffer`: The number of seconds to extend the bond escalation process to allow the losing party to tie if at the end of the initial deadline the pledges weren't tied. - `disputeWindow`: The number of seconds disputers have to challenge the proposed response since its creation. ## 3. Key Mechanisms & Concepts -- Bond Escalation: The process of rasing stakes and pledging for one of the sides of a dispute. The sides take turns bonding funds until the bond escalation deadline. If the number of pledges in favor of the dispute is not equal to the number of pledges against the dispute at the end of the bond escalation deadline plus the tying buffer, the bond escalation accountancy can settled. In case of a tie, the dispute must be escalated to the resolution module. -- Pledge: Bonded funds that are used to support or oppose a dispute. +- **Bond Escalation**: The process of raising stakes and pledging for one of the sides of a dispute. The sides take turns bonding funds until the bond escalation deadline is met. If the number of pledges in favor of the dispute is not equal to the number of pledges against the dispute at the end of the bond escalation deadline plus the tying buffer, the bond escalation accountancy can be settled. In case of a tie, the dispute must be escalated to the resolution module. +- **Pledge**: Bonded funds that are used to support or oppose a dispute. ## 4. Gotchas -- Only the first dispute of a request can go through the bond escalation mechanism. +- Only the first dispute of a request can go through the bond escalation mechanism. Any subsequent disputes will be forwarded to the resolution module. - After the bond escalation has finished, the winning side should withdraw their funds by calling `claimEscalationReward` on the bond escalation accounting extension. - The funds of the losing side of the bond escalation will be slashed and given to the winners. diff --git a/docs/src/content/modules/dispute/bonded_dispute_module.md b/docs/src/content/modules/dispute/bonded_dispute_module.md index 94d9dda3..6288d854 100644 --- a/docs/src/content/modules/dispute/bonded_dispute_module.md +++ b/docs/src/content/modules/dispute/bonded_dispute_module.md @@ -10,10 +10,10 @@ The Bonded Dispute Module is a contract that allows users to dispute a proposed ### Key Methods -- `decodeRequestData(bytes calldata _data)`: Returns the decoded data for a request. -- `disputeResponse(bytes32 _requestId, bytes32 _responseId, address _disputer, address _proposer)`: Starts a dispute. -- `onDisputeStatusChange(bytes32 _disputeId, IOracle.Dispute memory _dispute)`: Is a hook called by the oracle when a dispute status has been updated. -- `disputeEscalated(bytes32 _disputeId)`: Called by the oracle when a dispute has been escalated. Not implemented in this module. +- `decodeRequestData`: Decodes request parameters. +- `disputeResponse`: Starts a dispute. +- `onDisputeStatusChange`: Is a hook called by the oracle when a dispute status has been updated. +- `disputeEscalated`: Called by the oracle when a dispute has been escalated. Not implemented in this module. ### Request Parameters diff --git a/docs/src/content/modules/dispute/circuit_resolver_module.md b/docs/src/content/modules/dispute/circuit_resolver_module.md index 81ac72f4..c7837596 100644 --- a/docs/src/content/modules/dispute/circuit_resolver_module.md +++ b/docs/src/content/modules/dispute/circuit_resolver_module.md @@ -10,7 +10,7 @@ The Circuit Resolver Module is a pre-dispute module that allows disputers to ver ### Key Methods -- `decodeRequestData`: Returns the decoded data for a request. +- `decodeRequestData`: Decodes request parameters. - `disputeResponse`: Verifies the ZK circuit and compares it to the proposed one. Updates the dispute status after checking if the disputed response is indeed wrong. - `onDisputeStatusChange`: Updates the status of the dispute and resolves it by proposing the correct circuit as a response and finalizing the request. @@ -24,8 +24,8 @@ The Circuit Resolver Module is a pre-dispute module that allows disputers to ver ## 3. Key Mechanisms & Concepts -- Verifier: A contract implementing the verification logic, which will be consulted in case of a dispute. -- Atomical dispute: With this module, a dispute is initiated and resolved in the same transaction because the answer can be (somewhat expensively) calculated on-chain. +- **Verifier**: A contract implementing the verification logic, which will be consulted in case of a dispute. +- **Atomical dispute**: With this module, a dispute is initiated and resolved in the same transaction because the answer can be (somewhat expensively) calculated on-chain. ## 4. Gotchas diff --git a/docs/src/content/modules/dispute/root_verification_module.md b/docs/src/content/modules/dispute/root_verification_module.md index b2ad1935..d5dabc67 100644 --- a/docs/src/content/modules/dispute/root_verification_module.md +++ b/docs/src/content/modules/dispute/root_verification_module.md @@ -10,7 +10,7 @@ The Root Verification Module is a pre-dispute module that allows disputers to ca ### Key Methods -- `decodeRequestData`: Returns the decoded data for a request. +- `decodeRequestData`: Decodes request parameters. - `disputeResponse`: Calculates the correct root and compares it to the proposed one. Updates the dispute status after checking if the disputed response is indeed wrong. - `onDisputeStatusChange`: Updates the status of the dispute and resolves it by proposing the correct root as a response and finalizing the request. @@ -25,8 +25,8 @@ The Root Verification Module is a pre-dispute module that allows disputers to ca ## 3. Key Mechanisms & Concepts -- Tree verifier: A contract implementing the `ITreeVerifier` interface, which will be consulted in case of a dispute and will provide the correct root for the Merkle tree, taking into consideration the new leaves. -- Atomical dispute: With this module, a dispute is initiated and resolved in the same transaction because the answer can be (somewhat expensively) calculated on-chain. +- **Tree verifier**: A contract implementing the `ITreeVerifier` interface, which will be consulted in case of a dispute and will provide the correct root for the Merkle tree, taking into consideration the new leaves. +- **Atomical dispute**: With this module, a dispute is initiated and resolved in the same transaction because the answer can be (somewhat expensively) calculated on-chain. ## 4. Gotchas diff --git a/docs/src/content/modules/finality.md b/docs/src/content/modules/finality.md index 3acbe1c5..66983805 100644 --- a/docs/src/content/modules/finality.md +++ b/docs/src/content/modules/finality.md @@ -10,4 +10,4 @@ Prophet's Finality modules: ## Creating a Finality Module -To build a Finality module, inherit from `IFinalityModule` and the `Module` abstract contract, create the `RequestParameters` struct and define the logic in the `finalizeRequest` function. Most importantly, make sure to handle the finalization with and without a response. +To build a Finality module, inherit from [`IFinalityModule`](/solidity/interfaces/core/modules/finality/IFinalityModule.sol/interface.IFinalityModule.md) and the `Module` abstract contract, create the `RequestParameters` struct and define the logic in the `finalizeRequest` function. Most importantly, make sure to handle the finalization with and without a response. diff --git a/docs/src/content/modules/finality/callback_module.md b/docs/src/content/modules/finality/callback_module.md index 78409c9a..496f27b4 100644 --- a/docs/src/content/modules/finality/callback_module.md +++ b/docs/src/content/modules/finality/callback_module.md @@ -10,7 +10,7 @@ The Callback Module is a finality module that allows users to call a function on ### Key Methods -- `decodeRequestData`: Returns the decoded data for a request. +- `decodeRequestData`: Decodes request parameters. - `finalizeRequest`: Executing the callback call on the target. ### Request Parameters diff --git a/docs/src/content/modules/finality/multiple_callbacks_module.md b/docs/src/content/modules/finality/multiple_callbacks_module.md index 1b4134a3..45280dbb 100644 --- a/docs/src/content/modules/finality/multiple_callbacks_module.md +++ b/docs/src/content/modules/finality/multiple_callbacks_module.md @@ -10,7 +10,7 @@ The `MultipleCallbacksModule` is a finality module that allows users to make mul ### Key Methods -- `decodeRequestData`: Returns the decoded data for a request. The returned data includes the target addresses for the callback and the calldata forwarded to the targets. +- `decodeRequestData`: Decodes request parameters. The returned data includes the target addresses for the callback and the calldata forwarded to the targets. - `finalizeRequest`: Finalizes the request by executing the callback calls on the targets. ### Request Parameters diff --git a/docs/src/content/modules/request.md b/docs/src/content/modules/request.md index 7a377214..171bfd7f 100644 --- a/docs/src/content/modules/request.md +++ b/docs/src/content/modules/request.md @@ -2,18 +2,18 @@ ## Introduction -All modules in the Prophet Framework are designed to handle specific parts of a request's lifecycle and the Request module is responsible for asking for the information and configuring a reward. This includes declaring the source for the response and running any necessary validations or actions specified in the `_afterSetupRequest` function. +All modules in the Prophet Framework are designed to handle specific parts of a request's lifecycle and the Request module is responsible for asking for the information and configuring a reward. This includes declaring the source for the response and running any necessary validations or actions specified in the `createRequest` function. Prophet's Request modules: -- [ContractCallRequestModule](./request/contract_call_request_module.md) to request data from a smart contract - [HTTPRequestModule](./request/http_request_module.md) to request data from a URL +- [ContractCallRequestModule](./request/contract_call_request_module.md) to request data from a smart contract - [SparseMerkleTreeRequestModule](./request/sparse_merkle_tree_request_module.md) to request a verification of a Merkle tree ## Creating a Request Module -Creating a Request module is as simple as defining a contract that inherits from the `IRequestModule` interface and implements the necessary logic in the `_afterSetupRequest` and `finalizeRequest` hooks, as well as any custom logic. +Creating a Request module is as simple as following from the [`IRequestModule`](/solidity/interfaces/core/modules/request/IRequestModule.sol/interface.IRequestModule.md) interface and implementing the necessary logic in the `createRequest` and `finalizeRequest` hooks, as well as any custom logic. A good Request module should take care of the following: -- Declaring the data source for proposers to be able to answer the request -- Specifying the reward for proposing a valid answer +- Defining the `RequestParameters` struct with the necessary configuration for requests, such as the data source and the reward - Providing a way for the requester to withdraw the reward if no valid answer is proposed +- Securing the hooks with the `onlyOracle` modifier diff --git a/docs/src/content/modules/request/contract_call_request_module.md b/docs/src/content/modules/request/contract_call_request_module.md index 5ae50f9a..0eeb579a 100644 --- a/docs/src/content/modules/request/contract_call_request_module.md +++ b/docs/src/content/modules/request/contract_call_request_module.md @@ -10,8 +10,9 @@ The `ContractCallRequestModule` is a module for requesting on-chain information. ### Key Methods -- `decodeRequestData`: This method decodes the request data for a given request ID. It returns the target contract address, the function selector, the encoded arguments of the function to call, the accounting extension to bond and release funds, the payment token, and the payment amount. -- `finalizeRequest`: This method finalizes a request by paying the response proposer. It is only callable by the oracle. +- `decodeRequestData`: Decodes request parameters. It returns the target contract address, the function selector, the encoded arguments of the function to call, the accounting extension to bond and release funds, the payment token, and the payment amount. +- `createRequest`: Can be used to bond the requester's funds and validate the request parameters. +- `finalizeRequest`: Finalizes a request by paying the proposer if there is a valid response, or releasing the requester's bond if no valid response was provided. ### Request Parameters @@ -24,7 +25,7 @@ The `ContractCallRequestModule` is a module for requesting on-chain information. ## 3. Key Mechanisms & Concepts -Check out [Accounting Extension](../../extensions/accounting.md). +- Check out [Accounting Extension](../../extensions/accounting.md). ## 4. Gotchas diff --git a/docs/src/content/modules/request/http_request_module.md b/docs/src/content/modules/request/http_request_module.md index faf5de94..09ceeea1 100644 --- a/docs/src/content/modules/request/http_request_module.md +++ b/docs/src/content/modules/request/http_request_module.md @@ -10,8 +10,9 @@ The `HttpRequestModule` is a contract that allows users to request HTTP calls. ### Key Methods -- `decodeRequestData`: This method decodes request parameters. It returns the URL, HTTP method, body, accounting extension, payment token, and payment amount from the given data. -- `finalizeRequest`: This method finalizes a request by paying the proposer if there is a valid response, or releases the requester bond if no valid response was provided. +- `decodeRequestData`: Decodes request parameters. It returns the URL, HTTP method, body, accounting extension, payment token, and payment amount from the given data. +- `createRequest`: Can be used to bond the requester's funds and validating the request parameters. +- `finalizeRequest`: Finalizes a request by paying the proposer if there is a valid response, or releasing the requester's bond if no valid response was provided. ### Request Parameters @@ -24,7 +25,8 @@ The `HttpRequestModule` is a contract that allows users to request HTTP calls. ## 3. Key Mechanisms & Concepts -The `HttpRequestModule` uses an enum to represent the HTTP methods (GET, POST). +- The `HttpRequestModule` uses an enum to represent the HTTP methods (GET, POST). +- Check out [Accounting Extension](../../extensions/accounting.md). ## 4. Gotchas diff --git a/docs/src/content/modules/request/sparse_merkle_tree_request_module.md b/docs/src/content/modules/request/sparse_merkle_tree_request_module.md index 3968ba90..4f87fd26 100644 --- a/docs/src/content/modules/request/sparse_merkle_tree_request_module.md +++ b/docs/src/content/modules/request/sparse_merkle_tree_request_module.md @@ -10,8 +10,9 @@ The `SparseMerkleTreeRequestModule` is a contract that allows a user to request ### Key Methods -- `decodeRequestData`: This function decodes the request data for a given request ID. It returns a RequestParameters struct that contains the parameters for the request. -- `finalizeRequest`: This function is called by the Oracle to finalize the request. It either pays the proposer for the response or releases the requester's bond if no response was submitted. +- `decodeRequestData`: Decodes request parameters. It returns a RequestParameters struct that contains the parameters for the request. +- `createRequest`: Can be used to bond the requester's funds and validating the request parameters. +- `finalizeRequest`: Finalizes a request by paying the proposer if there is a valid response, or releasing the requester's bond if no valid response was provided. ### Request Parameters @@ -24,7 +25,8 @@ The `SparseMerkleTreeRequestModule` is a contract that allows a user to request ## 3. Key Mechanisms & Concepts -The `SparseMerkleTreeRequestModule` uses a Merkle tree to calculate the root from a set of leaves. The verified contract is used to calculate the Merkle root hash given a set of Merkle tree branches and Merkle tree leaves count. +- The `SparseMerkleTreeRequestModule` uses a Merkle tree to calculate the root from a set of leaves. The verifier contract is used to calculate the Merkle root hash given a set of Merkle tree branches and Merkle tree leaves count. +- Check out [Accounting Extension](../../extensions/accounting.md). ## 4. Gotchas diff --git a/docs/src/content/modules/resolution.md b/docs/src/content/modules/resolution.md index 63d1822e..9b7b1918 100644 --- a/docs/src/content/modules/resolution.md +++ b/docs/src/content/modules/resolution.md @@ -10,3 +10,5 @@ In Prophet, examples of Resolution modules include: - [PrivateERC20ResolutionModule](./resolution/private_erc20_resolution_module.md) that allows users to vote on a dispute using ERC20 tokens following a commit/reveal pattern. - [BondEscalationResolutionModule](./resolution/bond_escalation_resolution_module.md) that follows a bond escalation-like process to resolve disputes. - [SequentialResolutionModule](./resolution/sequential_resolution_module.md) that leverages multiple resolution modules to obtain an answer. + +They all follow the [IResolutionModule](/solidity/interfaces/core/modules/resolution/IResolutionModule.sol/interface.IResolutionModule.md) interface. diff --git a/docs/src/content/modules/resolution/arbitrator_module.md b/docs/src/content/modules/resolution/arbitrator_module.md index a46327f6..eb23fc80 100644 --- a/docs/src/content/modules/resolution/arbitrator_module.md +++ b/docs/src/content/modules/resolution/arbitrator_module.md @@ -10,11 +10,11 @@ The Arbitrator Module is a part of the dispute resolution system. It allows an e ### Key Methods +- `decodeRequestData`: Decodes request parameters. - `getStatus`: Returns the arbitration status of a dispute. - `isValid`: Indicates whether the dispute has been arbitrated. - `startResolution`: Starts the arbitration process by calling `resolve` on the arbitrator and flags the dispute as `Active`. - `resolveDispute`: Resolves the dispute by getting the answer from the arbitrator and notifying the oracle. -- `decodeRequestData`: Returns the decoded data for a request. ### Request Parameters diff --git a/docs/src/content/modules/resolution/bond_escalation_resolution_module.md b/docs/src/content/modules/resolution/bond_escalation_resolution_module.md index 9dc4a116..56bdd37c 100644 --- a/docs/src/content/modules/resolution/bond_escalation_resolution_module.md +++ b/docs/src/content/modules/resolution/bond_escalation_resolution_module.md @@ -10,9 +10,10 @@ The `BondEscalationResolutionModule` is a resolution module that handles the bon ### Key Methods -- `pledgeForDispute(bytes32 _requestId, bytes32 _disputeId, uint256 _pledgeAmount)`: Allows users to pledge in favor of a given dispute. -- `pledgeAgainstDispute(bytes32 _requestId, bytes32 _disputeId, uint256 _pledgeAmount)`: Allows users to pledge against a given dispute. -- `claimPledge(bytes32 _requestId, bytes32 _disputeId)`: Allows user to claim his corresponding pledges after a dispute is resolved. +- `decodeRequestData`: Decodes request parameters. +- `pledgeForDispute`: Allows users to pledge in favor of a given dispute. +- `pledgeAgainstDispute`: Allows users to pledge against a given dispute. +- `claimPledge`: Allows user to claim his corresponding pledges after a dispute is resolved. ### Request Parameters diff --git a/docs/src/content/modules/resolution/erc20_resolution_module.md b/docs/src/content/modules/resolution/erc20_resolution_module.md index 6be220b3..54a791cb 100644 --- a/docs/src/content/modules/resolution/erc20_resolution_module.md +++ b/docs/src/content/modules/resolution/erc20_resolution_module.md @@ -10,7 +10,7 @@ The `ERC20ResolutionModule` is a dispute resolution module that decides on the o ### Key Methods -- `decodeRequestData`: Decodes the request data associated with a given request ID. +- `decodeRequestData`: Decodes request parameters. - `startResolution`: Starts the resolution process for a given dispute. - `castVote`: Allows a user to cast votes for a dispute. - `resolveDispute`: Resolves a dispute based on the votes cast. diff --git a/docs/src/content/modules/resolution/private_erc20_resolution_module.md b/docs/src/content/modules/resolution/private_erc20_resolution_module.md index 73bad37a..8475e70d 100644 --- a/docs/src/content/modules/resolution/private_erc20_resolution_module.md +++ b/docs/src/content/modules/resolution/private_erc20_resolution_module.md @@ -10,7 +10,7 @@ The `PrivateERC20ResolutionModule` is a contract that allows users to vote on a ### Key methods -- `decodeRequestData`: Returns the decoded data for a request. +- `decodeRequestData`: Decodes request parameters. - `startResolution`: Starts the committing phase for a dispute. - `commitVote`: Stores a commitment for a vote cast by a voter. - `revealVote`: Reveals a vote cast by a voter. diff --git a/docs/src/content/modules/resolution/sequential_resolution_module.md b/docs/src/content/modules/resolution/sequential_resolution_module.md deleted file mode 100644 index bcf6b7e2..00000000 --- a/docs/src/content/modules/resolution/sequential_resolution_module.md +++ /dev/null @@ -1,38 +0,0 @@ -# Sequential Resolution Module - -See [ISequentialResolutionModule.sol](/solidity/interfaces/modules/resolution/ISequentialResolutionModule.sol/interface.ISequentialResolutionModule.md) for more details. - -## 1. Introduction - -The Sequential Resolution Module is a contract that leverages multiple resolution modules to obtain an answer. If the current resolution module returns no answer, the next resolution is started. The sequence of modules can be configured separately from a request and re-used in multiple requests. - -## 2. Contract Details - -### Key Methods - -- `decodeRequestData(bytes32 _requestId)`: Returns the decoded data for a request. -- `currentSequenceId()`: Returns the last sequence id that was created. -- `currentModuleIndex(bytes32 _disputeId)`: Returns the current index of the submodule in use for a dispute. -- `requestIdForDispute(bytes32 _disputeId)`: Returns the requestId corresponding to a dispute. -- `listSubmodules(uint256 _startFrom, uint256 _batchSize, uint256 _sequenceId)`: Returns the list of submodules in a sequence. -- `addResolutionModuleSequence(IResolutionModule[] memory _modules)`: Creates a sequence of modules. -- `getCurrentResolutionModule(bytes32 _disputeId)`: Returns the module that is currently resolving the specified dispute. -- `resolveDispute(bytes32 _disputeId)`: Resolves a dispute. -- `finalizeRequest(bytes32 _requestId, address _finalizer)`: Finalizes a request with each of the submodules. -- `startResolution(bytes32 _disputeId)`: Initiates the resolution of a dispute, using the first module from the sequence configured for the corresponding request. -- `updateDisputeStatus(bytes32 _disputeId, DisputeStatus _status)`: In case a resolution has been achieved, notifies the oracle. Otherwise, starts a resolution using the next submodule. - -### Request Parameters - -- `sequenceId`: The module sequence to use for resolution. -- `submoduleData`: The array of bytes that will be passed to each submodule. - -## 3. Key Mechanisms & Concepts - -- Sequence: a list of resolution modules, each of which is asked to resolve a dispute. If it fails, the resolution will continue with the next module in the sequence. It is worth noting that a sequence must be created prior to any requests using it, by calling `addResolutionModuleSequence` and specifying the list of submodules. - -## 4. Gotchas - -- The module follows the [IOracle.sol](/solidity/interfaces/IOracle.sol/interface.IOracle.md) interface but does not implement the non-view functions from the Oracle. -- Adding an invalid module to a sequence will result in the whole sequence becoming unusable. -- Only resolution modules that support the `NoResolution` status should be used as submodules. diff --git a/docs/src/content/modules/response.md b/docs/src/content/modules/response.md index e6fbb7c8..84840ce6 100644 --- a/docs/src/content/modules/response.md +++ b/docs/src/content/modules/response.md @@ -2,18 +2,19 @@ ## Introduction -The Response module is a vital part of any request that manages the requirements the requester has for the proposers, such as holding an NFT, being in a pre-defined list of addresses or providing a bond. +The Response module is a vital part of any request that manages the requirements the requester has for the proposers, such as holding an NFT, being in a pre-defined list of addresses or providing a bond, and pays out the rewards for accepted responses. Prophet's Response modules: - [BondedResponseModule](./response/bonded_response_module.md) that requires a proposer to post a bond first, which will be returned upon request finalization or slashed in case of a successful dispute. ## Creating a Response Module -To build a Response module, simply inherit from `IResponseModule` and the `Module` abstract contract, create the `RequestParameters` struct and define the logic for proposing, deleting and finalizing responses. +To build a Response module, simply inherit from [`IResponseModule`](/solidity/interfaces/core/modules/response/IResponseModule.sol/interface.IResponseModule.md) and the `Module` abstract contract, create the `RequestParameters` struct and define the logic for proposing, deleting and finalizing responses. A Response module should take care of the following: - Defining the criteria for proposers to be able to answer the request - Setting the rules for the responses, such as validations or deadlines - Handling the rewards for proposing a valid response +- Applying the `onlyOracle` modifier to the hooks to secure them While developing a Response module, keep in mind that the criteria that is too narrow might result in a lack of responses, while criteria that is too broad might result in a large number of invalid responses. diff --git a/docs/src/content/modules/response/bonded_response_module.md b/docs/src/content/modules/response/bonded_response_module.md index 4aaa6c67..97bf1c6b 100644 --- a/docs/src/content/modules/response/bonded_response_module.md +++ b/docs/src/content/modules/response/bonded_response_module.md @@ -10,9 +10,9 @@ The Bonded Response Module is a contract that allows users to propose a response ### Key Methods -- `decodeRequestData`: Returns the decoded data for a request. -- `propose`: Proposes a response for a request, bonding the proposer's tokens. -- `finalizeRequest`: Finalizes the request. +- `decodeRequestData`: Decodes request parameters. +- `propose`: Proposes a response for a request, bonding the proposer's tokens. A response cannot be proposed after the deadline or if an undisputed response has already been proposed. +- `finalizeRequest`: Finalizes the request, paying the proposer of the final response. ### Request Parameters @@ -23,12 +23,5 @@ The Bonded Response Module is a contract that allows users to propose a response ## 3. Key Mechanisms & Concepts -- 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. - -## 4. Gotchas - -- In case of no valid responses, a request can be finalized after the deadline and the requester will get back their tokens. -- Users cannot propose a response after the deadline for a request. -- Users cannot propose a response if an undisputed response has already been proposed. +- **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.