diff --git a/.github/workflows/docs.yml b/.github/workflows/docs.yml deleted file mode 100644 index a1774a8..0000000 --- a/.github/workflows/docs.yml +++ /dev/null @@ -1,62 +0,0 @@ -name: Deploy docs - -on: - push: - branches: - - main - - dev - pull_request: - paths: - - 'docs/**' - branches: - - dev - -jobs: - deploy-docs: - name: Deploy docs - runs-on: ubuntu-latest - environment: - name: ${{ github.ref_name == 'main' && 'Prod' || 'Dev' }} - - steps: - - uses: actions/checkout@v3 - - - name: Setup mdBook - uses: peaceiris/actions-mdbook@v1 - - - name: Install node - uses: actions/setup-node@v3 - with: - node-version: ${{ matrix.node-version }} - cache: "yarn" - - - name: Install dependencies - run: yarn --frozen-lockfile --network-concurrency 1 - - - name: Install Foundry - uses: foundry-rs/foundry-toolchain@v1 - with: - version: nightly - - - name: Build Docs - run: yarn docs:build - - - name: Create book folder - run: mdbook build docs - - - uses: amondnet/vercel-action@v25 - id: vercel-deployment - with: - vercel-token: ${{ secrets.VERCEL_TOKEN }} # Required - vercel-org-id: ${{ secrets.ORG_ID}} # Required - scope: ${{ secrets.ORG_ID}} # Required - vercel-args: ${{ github.ref_name == 'main' && '--prod' || '' }} - vercel-project-id: ${{ secrets.PROJECT_ID}} # Required - working-directory: ./docs/book - - - name: Comment PR - if: github.event_name == 'pull_request' - uses: thollander/actions-comment-pull-request@v2 - with: - message: | - Preview: ${{ steps.vercel-deployment.outputs.preview-url }} diff --git a/README.md b/README.md index 41f3801..c5e73d9 100644 --- a/README.md +++ b/README.md @@ -23,18 +23,16 @@ yarn build Make sure to set `OPTIMISM_RPC` environment variable before running end-to-end tests. -| Yarn Command | Description | -| ------------------------- | ------------------------------------------------------------------------------------------------- | -| `yarn build` | Compile all contracts. | -| `yarn coverage` | See `forge coverage` report. | -| `yarn deploy` | Deploy the contracts to Optimism mainnet. | -| `yarn deploy:local` | Deploy the contracts to a local fork. | -| `yarn docs:build` | Generate documentation with [`forge doc`](https://book.getfoundry.sh/reference/forge/forge-doc). | -| `yarn docs:run` | Start the documentation server. | -| `yarn test` | Run all unit and integration tests. | -| `yarn test:unit` | Run unit tests. | -| `yarn test:integration` | Run integration tests. | -| `yarn test:gas` | Run all unit and integration tests, and make a gas report. | +| Yarn Command | Description | +| ----------------------- | ---------------------------------------------------------- | +| `yarn build` | Compile all contracts. | +| `yarn coverage` | See `forge coverage` report. | +| `yarn deploy` | Deploy the contracts to Optimism mainnet. | +| `yarn deploy:local` | Deploy the contracts to a local fork. | +| `yarn test` | Run all unit and integration tests. | +| `yarn test:unit` | Run unit tests. | +| `yarn test:integration` | Run integration tests. | +| `yarn test:gas` | Run all unit and integration tests, and make a gas report. | ## Licensing diff --git a/build-docs.sh b/build-docs.sh deleted file mode 100755 index ffaca2f..0000000 --- a/build-docs.sh +++ /dev/null @@ -1,63 +0,0 @@ -#!/bin/bash - -root_path="solidity/interfaces" -# generate docs in a temporary directory -temp_folder="technical-docs" - -FOUNDRY_PROFILE=docs forge doc --out "$temp_folder" - -# edit generated summary not to have container pages -# - [jobs](solidity/interfaces/jobs/README.md) -# should become -# - [jobs]() -# TODO - -# edit generated summary titles to start with an uppercase letter -# - [jobs]() -# should become -# - [Jobs]() -# TODO - -# edit the SUMMARY after the Interfaces section -# https://stackoverflow.com/questions/67086574/no-such-file-or-directory-when-using-sed-in-combination-with-find -if [[ "$OSTYPE" == "darwin"* ]]; then - sed -i '' -e '/Interfaces/q' docs/src/SUMMARY.md -else - sed -i -e '/Interfaces/q' docs/src/SUMMARY.md -fi - -# copy the generated SUMMARY, from the tmp directory, without the first 5 lines -# and paste them after the Interfaces section on the original SUMMARY -tail -n +5 $temp_folder/src/SUMMARY.md >> docs/src/SUMMARY.md - -# delete old generated interfaces docs -rm -rf docs/src/$root_path -# there are differences in cp and mv behavior between UNIX and macOS when it comes to non-existing directories -# creating the directory to circumvent them -mkdir -p docs/src/$root_path -# move new generated interfaces docs from tmp to original directory -cp -R $temp_folder/src/$root_path docs/src/solidity/ - -# delete tmp directory -rm -rf $temp_folder - -# function to replace text in all files (to fix the internal paths) -replace_text() { - for file in "$1"/*; do - if [ -f "$file" ]; then - if [[ "$OSTYPE" == "darwin"* ]]; then - sed -i '' "s|$temp_folder/src/||g" "$file" - else - sed -i "s|$temp_folder/src/||g" "$file" - fi - elif [ -d "$file" ]; then - replace_text "$file" - fi - done -} - -# path to the base folder -base_folder="docs/src/$root_path" - -# calling the function to fix the paths -replace_text "$base_folder" diff --git a/docs/book.toml b/docs/book.toml deleted file mode 100644 index c9a6aeb..0000000 --- a/docs/book.toml +++ /dev/null @@ -1,20 +0,0 @@ -[book] -src = 'src' -title = 'Prophet' -authors = ['Prophet', 'Wonderland'] -description = '' -language = 'en' - -[output.html] -copy-fonts = false # avoid copying default fonts to book -theme = 'src/prophet-theme' -additional-css = ['src/prophet-theme/css/fonts.css', 'src/prophet-theme/css/colors.css', 'src/prophet-theme/css/base.css'] -additional-js = ['src/prophet-theme/js/theme.js', 'src/prophet-theme/js/base.js', 'src/prophet-theme/js/solidity.min.js'] -git-repository-url = 'https://github.com/defi-wonderland/prophet-core' -git-repository-icon = 'fa-github' -no-section-label = true -mathjax-support = true - -[output.html.fold] -enable = true # whether or not to enable section folding -level = 1 # the depth to start folding diff --git a/docs/src/SUMMARY.md b/docs/src/SUMMARY.md deleted file mode 100644 index 3319afe..0000000 --- a/docs/src/SUMMARY.md +++ /dev/null @@ -1,89 +0,0 @@ -# Summary - -# Documentation - -- [Getting Started](content/intro/README.md) - - [Prophet Framework 101](content/intro/framework.md) - -- [Core Contracts](content/core/README.md) - - - [Oracle](content/core/oracle.md) - - [Module](content/core/module.md) - -- [Modules](content/modules/README.md) - - - [Request](content/modules/request.md) - - - [ContractCallRequestModule](content/modules/request/contract_call_request_module.md) - - [HttpRequestModule](content/modules/request/http_request_module.md) - - [SparseMerkleTreeRequestModule](content/modules/request/sparse_merkle_tree_request_module.md) - - - [Response](content/modules/response.md) - - - [BondedResponseModule](content/modules/response/bonded_response_module.md) - - - [Dispute](content/modules/dispute.md) - - - [BondedDisputeModule](content/modules/dispute/bonded_dispute_module.md) - - [BondEscalationModule](content/modules/dispute/bond_escalation_module.md) - - [CircuitResolverModule](content/modules/dispute/circuit_resolver_module.md) - - [RootVerificationModule](content/modules/dispute/root_verification_module.md) - - - [Resolution](content/modules/resolution.md) - - - [ArbitratorModule](content/modules/resolution/arbitrator_module.md) - - [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) - - [MultipleCallbacksModule](content/modules/finality/multiple_callbacks_module.md) - -- [Extensions](content/extensions/README.md) - - - [Accounting ](content/extensions/accounting.md) - - [Bond Escalation Accounting](content/extensions/bond_escalation_accounting.md) - -- [Libraries](content/libraries/README.md) - - [MerkleLib](content/libraries/merkle_lib.md) - -# Technical Documentation - -- [Interfaces]() - - [❱ extensions](solidity/interfaces/extensions/README.md) - - [IAccountingExtension](solidity/interfaces/extensions/IAccountingExtension.sol/interface.IAccountingExtension.md) - - [IBondEscalationAccounting](solidity/interfaces/extensions/IBondEscalationAccounting.sol/interface.IBondEscalationAccounting.md) - - [❱ external](solidity/interfaces/external/README.md) - - [IWETH9](solidity/interfaces/external/IWETH9.sol/interface.IWETH9.md) - - [❱ modules](solidity/interfaces/modules/README.md) - - [❱ dispute](solidity/interfaces/modules/dispute/README.md) - - [IBondEscalationModule](solidity/interfaces/modules/dispute/IBondEscalationModule.sol/interface.IBondEscalationModule.md) - - [IBondedDisputeModule](solidity/interfaces/modules/dispute/IBondedDisputeModule.sol/interface.IBondedDisputeModule.md) - - [ICircuitResolverModule](solidity/interfaces/modules/dispute/ICircuitResolverModule.sol/interface.ICircuitResolverModule.md) - - [IDisputeModule](solidity/interfaces/modules/dispute/IDisputeModule.sol/interface.IDisputeModule.md) - - [IRootVerificationModule](solidity/interfaces/modules/dispute/IRootVerificationModule.sol/interface.IRootVerificationModule.md) - - [❱ finality](solidity/interfaces/modules/finality/README.md) - - [ICallbackModule](solidity/interfaces/modules/finality/ICallbackModule.sol/interface.ICallbackModule.md) - - [IFinalityModule](solidity/interfaces/modules/finality/IFinalityModule.sol/interface.IFinalityModule.md) - - [IMultipleCallbacksModule](solidity/interfaces/modules/finality/IMultipleCallbacksModule.sol/interface.IMultipleCallbacksModule.md) - - [❱ request](solidity/interfaces/modules/request/README.md) - - [IContractCallRequestModule](solidity/interfaces/modules/request/IContractCallRequestModule.sol/interface.IContractCallRequestModule.md) - - [IHttpRequestModule](solidity/interfaces/modules/request/IHttpRequestModule.sol/interface.IHttpRequestModule.md) - - [IRequestModule](solidity/interfaces/modules/request/IRequestModule.sol/interface.IRequestModule.md) - - [ISparseMerkleTreeRequestModule](solidity/interfaces/modules/request/ISparseMerkleTreeRequestModule.sol/interface.ISparseMerkleTreeRequestModule.md) - - [❱ resolution](solidity/interfaces/modules/resolution/README.md) - - [IArbitratorModule](solidity/interfaces/modules/resolution/IArbitratorModule.sol/interface.IArbitratorModule.md) - - [IBondEscalationResolutionModule](solidity/interfaces/modules/resolution/IBondEscalationResolutionModule.sol/interface.IBondEscalationResolutionModule.md) - - [IERC20ResolutionModule](solidity/interfaces/modules/resolution/IERC20ResolutionModule.sol/interface.IERC20ResolutionModule.md) - - [IPrivateERC20ResolutionModule](solidity/interfaces/modules/resolution/IPrivateERC20ResolutionModule.sol/interface.IPrivateERC20ResolutionModule.md) - - [IResolutionModule](solidity/interfaces/modules/resolution/IResolutionModule.sol/interface.IResolutionModule.md) - - [ISequentialResolutionModule](solidity/interfaces/modules/resolution/ISequentialResolutionModule.sol/interface.ISequentialResolutionModule.md) - - [❱ response](solidity/interfaces/modules/response/README.md) - - [IBondedResponseModule](solidity/interfaces/modules/response/IBondedResponseModule.sol/interface.IBondedResponseModule.md) - - [IResponseModule](solidity/interfaces/modules/response/IResponseModule.sol/interface.IResponseModule.md) - - [IArbitrator](solidity/interfaces/IArbitrator.sol/interface.IArbitrator.md) - - [IModule](solidity/interfaces/IModule.sol/interface.IModule.md) - - [IOracle](solidity/interfaces/IOracle.sol/interface.IOracle.md) - - [ITreeVerifier](solidity/interfaces/ITreeVerifier.sol/interface.ITreeVerifier.md) diff --git a/docs/src/content/core/README.md b/docs/src/content/core/README.md deleted file mode 100644 index 0135c43..0000000 --- a/docs/src/content/core/README.md +++ /dev/null @@ -1,16 +0,0 @@ -# Core Contracts - -The core contracts of the Prophet project are the backbone of the system responsible for keeping track of the data and routing the calls to the appropriate modules. - -The core includes: -- The [`Oracle`](./oracle.md) contract, which is the main contract that connects different parts of a request -- The [`Module`](./module.md) abstract contract, which is the base for all modules -- The interfaces for the different modules, such as `IRequestModule`, `IResponseModule`, etc - -For more detailed information about each contract, please refer to the respective documentation pages. - -For the Request, Response, Dispute, Resolution and Finality modules, please refer to the respective sections in the [Modules](../modules/README.md) documentation. - -For more technical details about the interfaces of the core contracts, please refer to the `Interfaces` section in the technical documentation. - -⚠️ Please note that the code has not been audited yet, so use it with caution. diff --git a/docs/src/content/core/module.md b/docs/src/content/core/module.md deleted file mode 100644 index 7d7049e..0000000 --- a/docs/src/content/core/module.md +++ /dev/null @@ -1,26 +0,0 @@ -# Module - -See [IModule.sol](/solidity/interfaces/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 `_afterSetupRequest`. - -## 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. diff --git a/docs/src/content/core/oracle.md b/docs/src/content/core/oracle.md deleted file mode 100644 index 57b9614..0000000 --- a/docs/src/content/core/oracle.md +++ /dev/null @@ -1,51 +0,0 @@ -# Oracle - -See [IOracle.sol](/solidity/interfaces/IOracle.sol/interface.IOracle.md) for more details. - -## 1. Introduction - -The Oracle serves as the central part of the Prophet framework. It performs the following functions: - -- Managing requests, responses and disputes. -- Routing function calls to appropriate modules. -- Keeping data synchronized between different modules. -- Providing the users with the full picture of their request, response or dispute. - -The Oracle does not handle any transfers, utilizing the extensions for that functionality. - -## 2. Contract Details - -### Key Methods - -- `createRequest`: Creates a new request. -- `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. -- `updateDisputeStatus`: Updates the status of a dispute. -- `finalize`: Finalizes a request. - -## 3. Key Mechanisms & Concepts - -### Request vs Full Request vs New Request - -The oracle defines 3 structures representing a request: - -- `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. - -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. - -## 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. - -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/README.md b/docs/src/content/extensions/README.md deleted file mode 100644 index 0d2265e..0000000 --- a/docs/src/content/extensions/README.md +++ /dev/null @@ -1,7 +0,0 @@ -# Extensions - -Extensions are smart contracts that expand the functionality of modules. They're not required to be used but can provide safe space for storing the user balances outside of modules, making interactions with the Oracle easier. Extensions are supposed to be reused by multiple modules, handling multiple requests at the same time. - -Prophet's shipped with 2 extensions: -- [AccountingExtension](./accounting.md) that is used to keep track of the bonds and payments -- [BondEscalationAccountingExtension](./bond_escalation_accounting.md) that is similar to the `AccountingExtension` but tailored for the `BondEscalation` module diff --git a/docs/src/content/extensions/accounting.md b/docs/src/content/extensions/accounting.md deleted file mode 100644 index c03dcb7..0000000 --- a/docs/src/content/extensions/accounting.md +++ /dev/null @@ -1,35 +0,0 @@ -# Accounting Extension - -See [IAccountingExtension.sol](/solidity/interfaces/extensions/IAccountingExtension.sol/interface.IAccountingExtension.md) for more details. - -## 1. Introduction - -The Accounting Extension is a contract that allows users to deposit and bond funds to be used for payments and disputes. It provides a way to manage user balances within the system, supporting frictionless interactions with the Oracle and the modules. - -## 2. Contract Details - -### 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. - -## 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). - -- 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. - -- 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. - -## 4. Gotchas - -- Before depositing ERC20 tokens, users must first approve the Accounting Extension to transfer the tokens on their behalf. -- Users can only withdraw tokens that are not currently bonded. If a user has bonded tokens for a request, those tokens are locked until they are released by an allowed module. Attempting to withdraw bonded tokens will result in an error. Attempting to slash or pay out tokens that are not locked will also result in a transaction being reverted. -- The contract supports any ERC20 token, including wrapped Ether (WETH). However, if a user tries to deposit a non-ERC20 token or a token that the contract otherwise doesn't support, the transaction will fail. diff --git a/docs/src/content/extensions/bond_escalation_accounting.md b/docs/src/content/extensions/bond_escalation_accounting.md deleted file mode 100644 index 0f48708..0000000 --- a/docs/src/content/extensions/bond_escalation_accounting.md +++ /dev/null @@ -1,30 +0,0 @@ -# Bond Escalation Accounting Extension - -See [IBondEscalationAccounting.sol](/solidity/interfaces/extensions/IBondEscalationAccounting.sol/interface.IBondEscalationAccounting.md) for more details. - -## 1. Introduction - -The `BondEscalationAccounting` contract is an extension that allows users to deposit and pledge funds to be used for bond escalation. It provides mechanisms for pledging tokens and paying out rewards to the winning pledgers. - -## 2. Contract Details - -### 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. -- `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. -- `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. - -## 3. Key Mechanisms & Concepts - -- Pledging: Users can pledge tokens for or against a dispute. The pledged tokens are locked and cannot be used until the dispute is resolved. - -- Deposits: Users can deposit tokens into the extension. Deposits can be made in any ERC20 token, ETH deposits will be converted to WETH. - -- Withdrawals: Users can withdraw their tokens at any time. The withdrawal operation reduces the user's balance in the extension and transfers the tokens back to the user's address. Locked tokens can't be withdrawn until they're released by a module. - -## 4. Gotchas - -- Before depositing ERC20 tokens, users must first approve the extension to transfer the tokens on their behalf. diff --git a/docs/src/content/intro/README.md b/docs/src/content/intro/README.md deleted file mode 100644 index 221457f..0000000 --- a/docs/src/content/intro/README.md +++ /dev/null @@ -1,32 +0,0 @@ -# Getting Started - -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 - -### Repositories -- [Core Contracts](https://github.com/defi-wonderland/prophet-core) -- [Modules](https://github.com/defi-wonderland/prophet-modules) -- [Explorer](https://github.com/defi-wonderland/prophet-app) -- [Automation](https://github.com/defi-wonderland/prophet-automation) -- [SDK](https://github.com/defi-wonderland/prophet-sdk) - -## Deployments - - -## Licensing - -The primary license for Prophet contracts is MIT. - -## Contributors - -Prophet was built with ❤️ by [Wonderland](https://defi.sucks). - -Wonderland is a team of top Web3 researchers, developers, and operators who believe that the future needs to be open-source, permissionless, and decentralized. - -[DeFi sucks](https://defi.sucks), but Wonderland is here to make it better. diff --git a/docs/src/content/intro/framework.md b/docs/src/content/intro/framework.md deleted file mode 100644 index b241ece..0000000 --- a/docs/src/content/intro/framework.md +++ /dev/null @@ -1,69 +0,0 @@ -# Prophet Framework 101 - -## What is 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. - -- **Optimistic**: Prophet is an optimistic oracle, meaning that in most cases a request will be answered without any disputes. This allows for a fast and cheap capturing of the information. -- **Modular**: The framework is designed to support countless use cases by enabling the users to choose the logic of their requests. The users can choose from a variety of modules and extensions. -- **Permissionless**: Asking for or providing the data requires no approvals from any centralized party. Additionally, anyone is free to expand the system by building new modules and extensions. -- **Public good**: Prophet does not extract any value from its users. - -## Key Concents - -### Roles - -- **Requester** creates requests in the Oracle -- **Proposer** gets rewards for providing valid answers to the requests -- **Disputer** challenges answers and gets paid if the answer is found to be invalid - -### Request - -A request is what is being asked for. Example requests are: - -- What's the price of oil on April 1st? -- Was the temperature in Madrid above 30 degrees on 1st July 2023? - -At any time, a request will be in one of the following states - -1. No response has been proposed yet. In this case either a response can be proposed or, if the submission deadline has passed, the request's state can be changed to finalized without responses, meaning it will never be answered. - -2. A response has been proposed. The response is considered valid until claimed otherwise by a disputer. If undisputed, the response becomes finalized after the submission deadline is over. - -3. A response has been proposed and disputed. Disputing a response usually opens up a window for proposing a new response. If the dispute gets resolved in favor of the proposer, the request can be finalized. If the resolution favors the disputer, the proposer's bond is transferred to the disputer. Inconclusive results are possible, for instance if a vote fails to reach quorum. - -4. The request has been finalized. From this point it's unchangeable and if there is a response, it can be safely used by other contracts. - -### 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. - -### 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. - -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. - -In some cases a dispute can be resolved on-chain, unlocking atomical resolution and finalization of the request and eliminating the need for a resolution module. - -### Oracle - -This smart-contract coordinates and ensures the correct use and functionality of in-use modules. It's the entry point/proxy for external calls into the modules. - -The oracle only has power over storing requests data, everything else is decided by the modules used in the requests. - -### Modules - -Modules are the lego blocks for requests. They're responsible for the logic of the request, such as who is allowed to propose the answers, where to get them, and how to resolve disputes. - -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` - -### Extensions - -Extensions are smart-contracts that are extending the functionality of the modules. They can be used to store data, manage user balances, and more. One example of an extension would be the accounting extension, which is used to keep user funds and streamline user interactions with the oracle by eliminating the need for constant fund transfers. diff --git a/docs/src/content/intro/prophet.md b/docs/src/content/intro/prophet.md deleted file mode 100644 index 3352a32..0000000 --- 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/README.md b/docs/src/content/libraries/README.md deleted file mode 100644 index 3290d70..0000000 --- a/docs/src/content/libraries/README.md +++ /dev/null @@ -1 +0,0 @@ -# Libraries diff --git a/docs/src/content/libraries/merkle_lib.md b/docs/src/content/libraries/merkle_lib.md deleted file mode 100644 index 279f2f8..0000000 --- a/docs/src/content/libraries/merkle_lib.md +++ /dev/null @@ -1,19 +0,0 @@ -# MerkleLib - -## 1. Introduction - -The `MerkleLib` is a Solidity library that provides functionality for managing an incremental Merkle tree. The library includes functions for inserting nodes into the tree and calculating the root of the tree. - -The library is a part of the [Connext monorepo](https://github.com/connext/monorepo/blob/main/packages/deployments/contracts/contracts/messaging/libraries/MerkleLib.sol). - -## 2. Contract Details - -### 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. - -## 3. Key Mechanisms & Concepts - -The `MerkleLib` uses a struct `Tree` to represent the Merkle tree. This struct contains the current branch of the tree and the number of inserted leaves in the tree. - -The library also defines a set of constants `Z_i` that represent the hash values at different heights for a binary tree with leaf values equal to 0. These constants are used to shortcut calculation in root calculation functions. diff --git a/docs/src/content/modules/README.md b/docs/src/content/modules/README.md deleted file mode 100644 index a55ecc0..0000000 --- a/docs/src/content/modules/README.md +++ /dev/null @@ -1 +0,0 @@ -# Modules diff --git a/docs/src/content/modules/dispute.md b/docs/src/content/modules/dispute.md deleted file mode 100644 index a72f974..0000000 --- a/docs/src/content/modules/dispute.md +++ /dev/null @@ -1,28 +0,0 @@ -# Dispute - -## Introduction - -The Dispute module is a crucial component of the Prophet Framework that manages the process of challenging responses, improving the security and trustworthiness of the data. - -In Prophet, examples of Dispute modules include: -- [BondedDisputeModule](./dispute/bonded_dispute_module.md) that requires a challenger to post a bond first, which will be returned upon successful dispute resolution or slashed in case of an unsuccessful dispute. -- [BondEscalationModule](./dispute/bond_escalation_module.md) in which the sides take turns increasing the bond until one of them gives up or until they reach a limit. -- [CircuitResolverModule](./dispute/circuit_resolver_module.md) that allows for the dispute to be resolved on-chain. -- [RootVerificationModule](./dispute/root_verification_module.md) that, similarly to the `CircuitResolverModule`, enables atomical on-chain resolution of disputes. - -## 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. - -- 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: - -- Define the criteria for challengers to be able to initiate a dispute -- Set the rules for the disputes, such as validations or deadlines -- Handle the rewards or slashing resulting from the dispute resolution -- Specify the next steps if a dispute should be moved to the Resolution module - -Ensure that the dispute criteria are not too narrow to prevent valid disputes from being raised. Conversely, criteria that are too broad might result in a large number of unnecessary disputes. diff --git a/docs/src/content/modules/dispute/bond_escalation_module.md b/docs/src/content/modules/dispute/bond_escalation_module.md deleted file mode 100644 index 59187b8..0000000 --- a/docs/src/content/modules/dispute/bond_escalation_module.md +++ /dev/null @@ -1,38 +0,0 @@ -# Bond Escalation Module - -See [IBondEscalationModule.sol](/solidity/interfaces/modules/dispute/IBondEscalationModule.sol/interface.IBondEscalationModule.md) for more details. - -## 1. Introduction - -The Bond Escalation Module is a contract that allows users to have the first dispute of a request go through the bond escalation mechanism. This mechanism allows for a dispute to be escalated by pledging more funds in favor or against the dispute. The module is designed to prevent last-second breaking of ties by adding a tying buffer at the end of the bond escalation deadline. - -## 2. Contract Details - -### 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. - -### 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. -- `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. - -## 4. Gotchas - -- Only the first dispute of a request can go through the bond escalation mechanism. -- 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 deleted file mode 100644 index b86745c..0000000 --- a/docs/src/content/modules/dispute/bonded_dispute_module.md +++ /dev/null @@ -1,31 +0,0 @@ -# Bonded Dispute Module - -See [IBondedDisputeModule.sol](/solidity/interfaces/modules/dispute/IBondedDisputeModule.sol/interface.IBondedDisputeModule.md) for more details. - -## 1. Introduction - -The Bonded Dispute Module is a contract that allows users to dispute a proposed response by bonding tokens. Depending on the result of the dispute, the tokens are either returned to the disputer or to the proposer (slashed). - -## 2. Contract Details - -### Key Methods - -- `decodeRequestData(bytes32 _requestId)`: 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. - -### Request Parameters - -- `accountingExtension`: The address holding the bonded tokens. It must implement the [IAccountingExtension.sol](/solidity/interfaces/extensions/IAccountingExtension.sol/interface.IAccountingExtension.md) interface. -- `bondToken`: The ERC20 token used for bonding. -- `bondSize`: The amount of tokens the disputer must bond to be able to dispute a response. - -## 3. Key Mechanisms & Concepts - -Check out [Accounting Extension](../../extensions/accounting.md). - -## 4. Gotchas - -- The module does not handle the cases of inconclusive dispute, e.g. if a ERC20 vote has failed to reach the quorum. -- Choosing a non-ERC20 token might result in disputers not being able to use this module. diff --git a/docs/src/content/modules/dispute/circuit_resolver_module.md b/docs/src/content/modules/dispute/circuit_resolver_module.md deleted file mode 100644 index 4806899..0000000 --- a/docs/src/content/modules/dispute/circuit_resolver_module.md +++ /dev/null @@ -1,34 +0,0 @@ -# Circuit Resolver Module - -See [ICircuitResolverModule.sol](/solidity/interfaces/modules/dispute/ICircuitResolverModule.sol/interface.ICircuitResolverModule.md) for more details. - -## 1. Introduction - -The Circuit Resolver Module is a pre-dispute module that allows disputers to verify a zero-knowledge circuit for a given request and propose it as a response, starting and resolving the dispute atomically. - -## 2. Contract Details - -### Key Methods - -- `decodeRequestData(bytes32 _requestId)`: Returns the decoded data for a request. -- `disputeResponse(bytes32 _requestId, bytes32 _responseId, address _disputer, address _proposer)`: 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(bytes32 _requestId, IOracle.Dispute memory _dispute)`: Updates the status of the dispute and resolves it by proposing the correct circuit as a response and finalizing the request. -- `disputeEscalated(bytes32 _disputeId)`: This function is present to comply with the module interface but it is not implemented since this is a pre-dispute module. - -### Request Parameters - -- `callData`: The encoded data forwarded to the verifier. -- `verifier`: The address of the verifier contract. -- `accountingExtension`: The accounting extension to use for payments. -- `bondToken`: The token to use for payments, it must be the same token that was specified for the response module. -- `bondSize`: The size of the payment for winning a dispute, it must be the same amount that was specified for the response module. - -## 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. - -## 4. Gotchas - -- The disputer is not required to bond any tokens in order to start a dispute, because in case they're wrong the cost of calculating the answer will be the penalty. However, depending on the chosen response module, they might be required to bond as a proposer of a new response. -- The module relies on the correct implementation of the verifier. If the verifier's logic if flawed, the module may not be able to resolve disputes correctly. diff --git a/docs/src/content/modules/dispute/root_verification_module.md b/docs/src/content/modules/dispute/root_verification_module.md deleted file mode 100644 index 6bb6e1f..0000000 --- a/docs/src/content/modules/dispute/root_verification_module.md +++ /dev/null @@ -1,36 +0,0 @@ -# Root Verification Module - -See [IRootVerificationModule.sol](/solidity/interfaces/modules/dispute/IRootVerificationModule.sol/interface.IRootVerificationModule.md) for more details. - -## 1. Introduction - -The Root Verification Module is a pre-dispute module that allows disputers to calculate the correct Merkle root for a given request and propose it as a response, starting and resolving the dispute atomically. - -## 2. Contract Details - -### Key Methods - -- `decodeRequestData(bytes32 _requestId)`: Returns the decoded data for a request. -- `disputeResponse(bytes32 _requestId, bytes32 _responseId, address _disputer, address _proposer)`: 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(bytes32 _requestId, IOracle.Dispute memory _dispute)`: Updates the status of the dispute and resolves it by proposing the correct root as a response and finalizing the request. -- `disputeEscalated(bytes32 _disputeId)`: This function is present to comply with the module interface but it is not implemented since this is a pre-dispute module. - -### Request Parameters - -- `treeData`: The Merkle tree. -- `leavesToInsert`: The leaves to insert in the tree. -- `treeVerifier`: The tree verifier to use to calculate the correct root. -- `accountingExtension`: The accounting extension to use for payments. -- `bondToken`: The token to use for payments, it must be the same token that was specified for the response module. -- `bondSize`: The size of the payment for winning a dispute, it must be the same amount that was specified for the response module. - -## 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. - -## 4. Gotchas - -- The module is supposed to be paired with the sparse merkle tree module or a similar one. -- The disputer is not required to bond any tokens in order to start a dispute, because in case they're wrong the cost of calculating the correct root will be the penalty. However, depending on the chosen response module, they might be required to bond as a proposer of a new response. -- The module relies on the correct implementation of the tree verifier to calculate the Merkle root. If the tree verifier's logic if flawed, the module may not be able to resolve disputes correctly. diff --git a/docs/src/content/modules/finality.md b/docs/src/content/modules/finality.md deleted file mode 100644 index 3acbe1c..0000000 --- a/docs/src/content/modules/finality.md +++ /dev/null @@ -1,13 +0,0 @@ -# Finality - -## Introduction - -Finality modules are responsible for executing actions when a request is finalized, such as notifying a contact about the response to a request. - -Prophet's Finality modules: -- [CallbackModule](./finality/callback_module.md) sends a predefined callback to an external contract. -- [MultipleCallbacksModule](./finality/multiple_callbacks_module.md) that is similar to the `CallbackModule` but allows for multiple callbacks to be sent. - -## 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. diff --git a/docs/src/content/modules/finality/callback_module.md b/docs/src/content/modules/finality/callback_module.md deleted file mode 100644 index e2c1ce9..0000000 --- a/docs/src/content/modules/finality/callback_module.md +++ /dev/null @@ -1,28 +0,0 @@ -# Callback Module - -See [ICallbackModule.sol](/solidity/interfaces/modules/finality/ICallbackModule.sol/interface.ICallbackModule.md) for more details. - -## 1. Introduction - -The Callback Module is a finality module that allows users to call a function on a contract as a result of a request being finalized. It is useful to notify a contract about the outcome of a request. - -## 2. Contract Details - -### Key Methods - -- `decodeRequestData(bytes32 _requestId)`: Returns the decoded data for a request. -- `finalizeRequest(bytes32 _requestId, address)`: Executing the callback call on the target. - -### Request Parameters - -- `target`: The target address for the callback. -- `data`: The calldata forwarded to the target. - -## 3. Key Mechanisms & Concepts - -As any finality module, the `CallbackModule` implements the `finalizeRequest` function which executes the chosen function with the given parameters on the target contract. - -## 4. Gotchas - -- The success of the callback call in `finalizeRequest` is purposely not checked, specifying a function or parameters that lead to a revert will not stop the request from being finalized. -- The target must be a contract. diff --git a/docs/src/content/modules/finality/multiple_callbacks_module.md b/docs/src/content/modules/finality/multiple_callbacks_module.md deleted file mode 100644 index e941220..0000000 --- a/docs/src/content/modules/finality/multiple_callbacks_module.md +++ /dev/null @@ -1,28 +0,0 @@ -# Multiple Callbacks Module - -See [IMultipleCallbacksModule.sol](/solidity/interfaces/modules/finality/IMultipleCallbacksModule.sol/interface.IMultipleCallbacksModule.md) for more details. - -## 1. Introduction - -The `MultipleCallbacksModule` is a finality module that allows users to make multiple calls to different contracts as a result of a request being finalized. This module is useful when a single request needs to trigger actions in multiple contracts. - -## 2. Contract Details - -### Key Methods - -- `decodeRequestData(bytes32 _requestId)`: Returns the decoded data for a request. The returned data includes the target addresses for the callback and the calldata forwarded to the targets. -- `finalizeRequest(bytes32 _requestId, address)`: Finalizes the request by executing the callback calls on the targets. - -### Request Parameters - -- `targets`: The target addresses for the callbacks. -- `data`: The calldata forwarded to the targets. - -## 3. Key Mechanisms & Concepts - -The `MultipleCallbacksModule` works by storing the target addresses and the calldata for each request. When a request is finalized, the module executes the callback calls on the targets using the stored data. - -## 4. Gotchas - -- The success of the callback calls in `finalizeRequest` is purposely not checked, specifying a function or parameters that lead to a revert will not stop the request from being finalized. -- All targets must be contracts. diff --git a/docs/src/content/modules/request.md b/docs/src/content/modules/request.md deleted file mode 100644 index 7a37721..0000000 --- a/docs/src/content/modules/request.md +++ /dev/null @@ -1,19 +0,0 @@ -# Request - -## 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. - -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 -- [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. - -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 -- Providing a way for the requester to withdraw the reward if no valid answer is proposed diff --git a/docs/src/content/modules/request/contract_call_request_module.md b/docs/src/content/modules/request/contract_call_request_module.md deleted file mode 100644 index afbf631..0000000 --- a/docs/src/content/modules/request/contract_call_request_module.md +++ /dev/null @@ -1,32 +0,0 @@ -# Contract Call Request Module - -See [IContractCallRequestModule.sol](/solidity/interfaces/modules/request/IContractCallRequestModule.sol/interface.IContractCallRequestModule.md) for more details. - -## 1. Introduction - -The `ContractCallRequestModule` is a module for requesting on-chain information. It specifies the source and the reward for a correct response. - -## 2. Contract Details - -### Key Methods - -- `decodeRequestData(bytes32 _requestId)`: 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(bytes32 _requestId, address)`: This method finalizes a request by paying the response proposer. It is only callable by the oracle. - -### Request Parameters - -- `target`: The address of the contract to get the response from. -- `functionSelector`: The function that returns the response to the request. -- `data`: The data to pass to the function. -- `accountingExtension`: The address holding the bonded tokens. It must implement the [IAccountingExtension.sol](/solidity/interfaces/extensions/IAccountingExtension.sol/interface.IAccountingExtension.md) interface. -- `paymentToken`: The ERC20 token used for paying the proposer. -- `paymentAmount`: The amount of tokens the proposer will receive for a correct response. - -## 3. Key Mechanisms & Concepts - -Check out [Accounting Extension](../../extensions/accounting.md). - -## 4. Gotchas - -- The proposers must keep a list of allowed targets and function selectors and only interact with the contracts they trust. One obvious trick is to use `transfer` as the function to call, which would allow the requester to steal the proposer's funds. -- Misconfiguring the data or choosing a function that does not exist on the target would render the request impossible to answer. diff --git a/docs/src/content/modules/request/http_request_module.md b/docs/src/content/modules/request/http_request_module.md deleted file mode 100644 index 7b4a8eb..0000000 --- a/docs/src/content/modules/request/http_request_module.md +++ /dev/null @@ -1,33 +0,0 @@ -# HTTP Request Module - -See [IHttpRequestModule.sol](/solidity/interfaces/modules/request/IHttpRequestModule.sol/interface.IHttpRequestModule.md) for more details. - -## 1. Introduction - -The `HttpRequestModule` is a contract that allows users to request HTTP calls. - -## 2. Contract Details - -### Key Methods - -- `decodeRequestData(bytes32 _requestId)`: This method decodes the data for a request given its ID. It returns the URL, HTTP method, body, accounting extension, payment token, and payment amount associated with the request. -- `finalizeRequest(bytes32 _requestId, address)`: 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. - -### Request Parameters - -- `url`: The URL to make the HTTP request to. -- `method`: The HTTP method to use. -- `body`: The query or body parameters to send with the request. -- `accountingExtension`: The address of the accounting extension to use. -- `paymentToken`: The address of the token to use for payment. -- `paymentAmount`: The amount of tokens to pay for a correct response. - -## 3. Key Mechanisms & Concepts - -The `HttpRequestModule` uses an enum to represent the HTTP methods (GET, POST). - -## 4. Gotchas - -- No support for DELETE, PUT, PATCH because they usually require some sort of authorization. -- Keep in mind that the call to the URL will likely be made multiple times by different proposers, which is especially important for POST requests. -- Providing an invalid URL or HTTP method will cause the request to become impossible to answer. 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 deleted file mode 100644 index aa71ffe..0000000 --- a/docs/src/content/modules/request/sparse_merkle_tree_request_module.md +++ /dev/null @@ -1,32 +0,0 @@ -# Sparse Merkle Tree Request Module - -See [ISparseMerkleTreeRequestModule.sol](/solidity/interfaces/modules/request/ISparseMerkleTreeRequestModule.sol/interface.ISparseMerkleTreeRequestModule.md) for more details. - -## 1. Introduction - -The `SparseMerkleTreeRequestModule` is a contract that allows a user to request the calculation of a Merkle tree after inserting a set of leaves. - -## 2. Contract Details - -### Key Methods - -- `decodeRequestData(bytes32 _requestId)`: This function decodes the request data for a given request ID. It returns a RequestParameters struct that contains the parameters for the request. -- `finalizeRequest(bytes32 _requestId, address _finalizer)`: 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. - -### Request Parameters - -- `treeData`: The encoded Merkle tree data parameters for the tree verifier. -- `leavesToInsert`: The array of leaves to insert into the Merkle tree. -- `treeVerifier`: The tree verifier to calculate the root. -- `accountingExtension`: The accounting extension to use for the request. -- `paymentToken`: The payment token to use for the request. -- `paymentAmount`: The payment amount to use for the 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. - -## 4. Gotchas - -- The module is supposed to be paired with the root verification module. -- The verifier contract must follow the `ITreeVerifier` interface, otherwise the proposers won't be able to calculate the correct response. diff --git a/docs/src/content/modules/resolution.md b/docs/src/content/modules/resolution.md deleted file mode 100644 index 63d1822..0000000 --- a/docs/src/content/modules/resolution.md +++ /dev/null @@ -1,12 +0,0 @@ -# Resolution - -## Introduction - -The Resolution module is responsible for providing an answer to a dispute. It is the last step of the dispute resolution process. Because of the vast amount of resolution methods, there is no general guideline for creating a Resolution module but keep in mind that some disputes cannot be resolved, in which case the Resolution module should probably refund all involved parties. - -In Prophet, examples of Resolution modules include: -- [ArbitratorModule](./resolution/arbitrator_module.md) that uses an external arbitrator contract to resolve disputes. -- [ERC20ResolutionModule](./resolution/erc20_resolution_module.md) that resolves disputes based on a voting process using ERC20 tokens. -- [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. diff --git a/docs/src/content/modules/resolution/arbitrator_module.md b/docs/src/content/modules/resolution/arbitrator_module.md deleted file mode 100644 index b047617..0000000 --- a/docs/src/content/modules/resolution/arbitrator_module.md +++ /dev/null @@ -1,36 +0,0 @@ -# Arbitrator Module - -See [IArbitratorModule.sol](/solidity/interfaces/modules/resolution/IArbitratorModule.sol/interface.IArbitratorModule.md) for more details. - -## 1. Introduction - -The Arbitrator Module is a part of the dispute resolution system. It allows an external arbitrator contract to resolve a dispute. The module provides methods to start the arbitration process, resolve the dispute, and get the status and validity of a dispute. - -## 2. Contract Details - -### Key Methods - -- `getStatus(bytes32 _disputeId)`: Returns the arbitration status of a dispute. -- `isValid(bytes32 _disputeId)`: Indicates whether the dispute has been arbitrated. -- `startResolution(bytes32 _disputeId)`: Starts the arbitration process by calling `resolve` on the arbitrator and flags the dispute as `Active`. -- `resolveDispute(bytes32 _disputeId)`: Resolves the dispute by getting the answer from the arbitrator and notifying the oracle. -- `decodeRequestData(bytes32 _requestId)`: Returns the decoded data for a request. - -### Request Parameters - -- `arbitrator`: The address of the arbitrator. The contract must follow the `IArbitrator` interface. - -## 3. Key Mechanisms & Concepts - -The Arbitrator Module uses an external arbitrator contract to resolve disputes. The arbitration process can be in one of three states: -- Unknown (default) -- Active -- Resolved - -The process starts with the `startResolution` function, which sets the dispute status to `Active`. The `resolveDispute` function is then used to get the answer from the arbitrator and update the dispute status to `Resolved`. - -## 4. Gotchas - -- The status of the arbitration is stored in the `_disputeData` mapping along with the dispute status. They're both packed in a `uint256`. -- The `startResolution` function will revert if the arbitrator address is the address zero. -- If the chosen arbitrator does not implement `resolve` nor `getAnswer` function, the dispute will get stuck in the `Active` state. diff --git a/docs/src/content/modules/resolution/bond_escalation_resolution_module.md b/docs/src/content/modules/resolution/bond_escalation_resolution_module.md deleted file mode 100644 index 9dc4a11..0000000 --- a/docs/src/content/modules/resolution/bond_escalation_resolution_module.md +++ /dev/null @@ -1,28 +0,0 @@ -# Bond Escalation Resolution Module - -See [IBondEscalationResolutionModule.sol](/solidity/interfaces/modules/resolution/IBondEscalationResolutionModule.sol/interface.IBondEscalationResolutionModule.md) for more details. - -## 1. Introduction - -The `BondEscalationResolutionModule` is a resolution module that handles the bond escalation resolution process for disputes. During the resolution, the sides take turns pledging for or against a dispute by bonding tokens. - -## 2. Contract Details - -### 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. - -### Request Parameters - -- `accountingExtension`: The accounting extension to be used. -- `bondToken`: The token to be used for bonding. -- `percentageDiff`: The percentage difference for the dispute. -- `pledgeThreshold`: The pledge threshold for the dispute. -- `timeUntilDeadline`: The time until the main deadline. -- `timeToBreakInequality`: The time to break inequality. - -## 3. Key Mechanisms & Concepts - -The outcome of a dispute is determined by the total pledges for and against the dispute. If the total pledges for the dispute are greater than the pledges against, the disputer wins. If the total pledges against the dispute are greater than the pledges for, the disputer loses. The difference between this module and the simple voting is the inequality timer that kicks in when the difference in pledges between the sides exceeds a set threshold. When this happens, the side with the lower amount of pledges has a set amount of time to increase their pledges to match the other side. If they fail to do so, the dispute is resolved in favor of the other side. diff --git a/docs/src/content/modules/resolution/erc20_resolution_module.md b/docs/src/content/modules/resolution/erc20_resolution_module.md deleted file mode 100644 index e807369..0000000 --- a/docs/src/content/modules/resolution/erc20_resolution_module.md +++ /dev/null @@ -1,37 +0,0 @@ -# ERC20 Resolution Module - -See [IERC20ResolutionModule.sol](/solidity/interfaces/modules/resolution/IERC20ResolutionModule.sol/interface.IERC20ResolutionModule.md) for more details. - -## 1. Introduction - -The `ERC20ResolutionModule` is a dispute resolution module that decides on the outcome of a dispute based on a vote. - -## 2. Contract Details - -### Key Methods - -- `decodeRequestData(bytes32 _requestId)`: Decodes the request data associated with a given request ID. -- `startResolution(bytes32 _disputeId)`: Starts the resolution process for a given dispute. -- `castVote(bytes32 _requestId, bytes32 _disputeId, uint256 _numberOfVotes)`: Allows a user to cast votes for a dispute. -- `resolveDispute(bytes32 _disputeId)`: Resolves a dispute based on the votes cast. -- `getVoters(bytes32 _disputeId)`: Returns the addresses of the voters for a given dispute. - -### Request Parameters - -- `accountingExtension`: The accounting extension associated with the request. -- `token`: The ERC20 token used for voting. -- `minVotesForQuorum`: The minimum number of votes required for a quorum. -- `timeUntilDeadline`: The time from the escalation to the voting deadline. - -## 3. Key Mechanisms & Concepts - -The `ERC20ResolutionModule` uses ERC20 tokens as votes for dispute resolution. Users can cast votes for a dispute by calling the `castVote` function. The number of votes a user can cast is equal to the number of ERC20 tokens they hold. - -The resolution process starts with the startResolution function, which sets the start time for the voting phase. Once the voting phase is over, the `resolveDispute` function is called to resolve the dispute based on the votes cast. If the total number of votes cast meets the minimum requirement for a quorum, the dispute is resolved. - -## 4. Gotchas - -- It is implied that the voters are incentivized to vote either because they're the governing entity of the ERC20 and have a stake in the outcome of the dispute or because they expect to be rewarded by such an entity. -- The `castVote` function requires the user to have approved the contract to spend their ERC20 tokens. -- Setting a time until deadline that's too short may result in voters not being able to participate. -- Setting the quorum that's too low may result in the dispute being resolved too early and without much participation. diff --git a/docs/src/content/modules/resolution/private_erc20_resolution_module.md b/docs/src/content/modules/resolution/private_erc20_resolution_module.md deleted file mode 100644 index c73c0dd..0000000 --- a/docs/src/content/modules/resolution/private_erc20_resolution_module.md +++ /dev/null @@ -1,39 +0,0 @@ -# Private ERC20 Resolution Module - -See [IPrivateERC20ResolutionModule.sol](/solidity/interfaces/modules/resolution/IPrivateERC20ResolutionModule.sol/interface.IPrivateERC20ResolutionModule.md) for more details. - -## 1. Introduction - -The `PrivateERC20ResolutionModule` is a contract that allows users to vote on a dispute using ERC20 tokens. The voting process follows a commit/reveal pattern to ensure that votes are kept secret until the voting period ends. - -## 2. Contract Details - -### Key methods - -- `decodeRequestData(bytes32 _requestId)`: Returns the decoded data for a request. -- `startResolution(bytes32 _disputeId)`: Starts the committing phase for a dispute. -- `commitVote(bytes32 _requestId, bytes32 _disputeId, bytes32 _commitment)`: Stores a commitment for a vote cast by a voter. -- `revealVote(bytes32 _requestId, bytes32 _disputeId, uint256 _numberOfVotes, bytes32 _salt)`: Reveals a vote cast by a voter. -- `resolveDispute(bytes32 _disputeId)`: Resolves a dispute by tallying the votes and executing the winning outcome. -- `computeCommitment(bytes32 _disputeId, uint256 _numberOfVotes, bytes32 _salt)`: Computes a valid commitment for the revealing phase. - -### Request Parameters - -- `accountingExtension`: The address of the accounting extension associated with the given request. -- `votingToken`: The address of the token used for voting. -- `minVotesForQuorum`: The minimum number of votes required for a dispute to be resolved. -- `committingTimeWindow`: The time window for the committing phase. -- `revealingTimeWindow`: The time window for the revealing phase. - -## 3. Key Mechanisms & Concepts - -- Committing phase: From the beginning of the dispute until the committing deadline, the votes are free to cast their votes and store their commitments. -- Revealing phase: After the committing deadline until the revealing deadline, the voters can reveal their votes by providing the commitment and the salt used to generate it. -- Salt: A random value used to generate the commitment, making it impossible to guess. - -## 4. Gotchas - -- It is implied that the voters are incentivized to vote either because they're the governing entity of the ERC20 and have a stake in the outcome of the dispute or because they expect to be rewarded by such an entity. -- The `commitVote` function allows committing multiple times and overwriting a previous commitment. -- The `revealVote` function requires the user to have previously approved the module to transfer the tokens. - 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 bcf6b7e..0000000 --- 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 deleted file mode 100644 index e6fbb7c..0000000 --- a/docs/src/content/modules/response.md +++ /dev/null @@ -1,19 +0,0 @@ -# Response - -## 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. - -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. - -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 - -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 deleted file mode 100644 index b8c9880..0000000 --- a/docs/src/content/modules/response/bonded_response_module.md +++ /dev/null @@ -1,37 +0,0 @@ -# Bonded Response Module - -See [IBondedResponseModule.sol](/solidity/interfaces/modules/response/IBondedResponseModule.sol/interface.IBondedResponseModule.md) for more details. - -## 1. Introduction - -The Bonded Response Module is a contract that allows users to propose a response for a request by bonding tokens. - -## 2. Contract Details - -### Key Methods - -- `decodeRequestData(bytes32 _requestId)`: Returns the decoded data for a request. -- `propose(bytes32 _requestId, address _proposer, bytes calldata _responseData)`: Proposes a response for a request, bonding the proposer's tokens. -- `deleteResponse(bytes32 _requestId, bytes32 _responseId, address _proposer)`: Allows a user to delete an undisputed response they proposed before the deadline, releasing the bond. -- `finalizeRequest(bytes32 _requestId, address _finalizer)`: Finalizes the request. - -### Request Parameters - -- `accountingExtension`: The address holding the bonded tokens. It must implement the [IAccountingExtension.sol](/solidity/interfaces/extensions/IAccountingExtension.sol/interface.IAccountingExtension.md) interface. -- `bondToken`: The ERC20 token used for bonding. -- `bondSize`: The amount of tokens the disputer must bond to be able to dispute a response. -- `deadline`: The timestamp at which the module stops accepting new responses for a request and it becomes finalizable. - -## 3. Key Mechanisms & Concepts - -- Deleting a response: If a proposer realizes the response they've submitted is incorrect, they can delete it. Note that disputed responses cannot be taken back. - -- 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. - -## 4. Gotchas - -- In case of no valid responses, a request can be finalized after the deadline and the requester will get back their tokens. -- A proposer might submit a response 1 block before the deadline and finalize it in the next block, making it impossible to dispute. -- Users cannot propose a response after the deadline for a request. -- Users cannot propose a response if an undisputed response has already been proposed. -- Users cannot delete a response after the proposing deadline. diff --git a/docs/src/images/logo.svg b/docs/src/images/logo.svg deleted file mode 100644 index 12fee49..0000000 --- a/docs/src/images/logo.svg +++ /dev/null @@ -1,17 +0,0 @@ - - - - - - - - - - - - - - - - - diff --git a/docs/src/prophet-theme/css/base.css b/docs/src/prophet-theme/css/base.css deleted file mode 100644 index 17f522c..0000000 --- a/docs/src/prophet-theme/css/base.css +++ /dev/null @@ -1,74 +0,0 @@ -/* - * Side bar - */ -html.ayu .sidebar { - border-right: 2px solid var(--border); -} -html.light .sidebar { - border-right: 2px solid var(--border); -} -.sidebar .sidebar-scrollbox { - padding: 1.5em 1em; -} -.sidebar .logo { - width: 80%; - margin: 0 auto 1.5em auto; - display: block; - max-width: 11em; - aspect-ratio: 4 / 1; - background-size: contain; - background-repeat: no-repeat; - background-position: center center; - background-image: var(--logo-h); -} -.sidebar .chapter { - margin: 0; -} -.sidebar .chapter li > div { - color: var(--sidebar-fg); - cursor: pointer; -} -.sidebar .chapter li > div:hover { - color: var(--sidebar-active); -} - -/* - * Search bar - */ -#searchbar { - background: var(--bg); - border: 2px solid var(--border); - border-radius: 0; - padding: 5px 10px; - outline: none; - box-shadow: none; - transition: border-color 300ms ease-in-out; -} -#searchbar:focus, -#searchbar.active, -#searchbar:hover { - box-shadow: none; - border-color: var(--border-active); -} - -/* - * Links - */ -a, -#searchresults a, -.content a:link, -a > .hljs { - text-decoration: underline; - color: var(--fg); - font-weight: 500; -} -a:visited { - color: var(--link-visited); -} - -/* - * Scrollbar - */ -::-webkit-scrollbar { - width: 5px; -} diff --git a/docs/src/prophet-theme/css/colors.css b/docs/src/prophet-theme/css/colors.css deleted file mode 100644 index 7dc4056..0000000 --- a/docs/src/prophet-theme/css/colors.css +++ /dev/null @@ -1,114 +0,0 @@ -/* Replace theme toggle brush for custom light/dark icons */ -#theme-toggle { - display: none; -} -html.light #theme-toggle-light { - display: none; -} -html.ayu #theme-toggle-dark { - display: none; -} - -/* Overwrite dark theme colors */ -html.ayu { - --bg: #121212; - --fg: rgba(255, 255, 255, 0.87); - --sidebar-bg: #121212; - --sidebar-fg: rgba(255, 255, 255, 0.5); - --sidebar-active: #ff0420; - --border: rgba(255, 255, 255, 0.12); - --border-active: rgba(255, 255, 255, 0.3); - --link-visited: #acacac; - --logo-h: url(/images/logo.svg); - --quote-bg: #121212; -} - -/* Overwrite light theme colors */ -html.light { - --bg: #fff; - --fg: rgba(0, 0, 0, 0.87); - --sidebar-bg: #fff; - --sidebar-fg: rgba(0, 0, 0, 0.54); - --sidebar-active: #ff0420; - --border: rgba(0, 0, 0, 0.12); - --border-active: rgba(0, 0, 0, 0.3); - --link-visited: #909090; - --logo-h: url(/images/logo.svg); - --quote-bg: #fff; -} - -h1, -h2, -h3, -h4, -h5, -h6 { - letter-spacing: -0.05px; - padding: 0 24px; -} - -h1 { - font-size: 32px; -} - -h2 { - font-size: 24px; -} - -h3 { - font-size: 20px; -} - -p, -pre, -.table-wrapper { - padding: 0 24px; -} - -.content p { - line-height: 1.5; -} - -li, -li > p { - padding: unset; - margin: unset; - margin-top: 10px; -} - -blockquote { - margin: 12px 0; - font-style: italic; - border: unset; - border-left: 2px solid var(--fg); -} - -blockquote p { - font-style: italic; - padding: unset; -} - -.table-wrapper + h3 { - margin-top: 96px; -} - -@media screen and (max-width: 600px) { - h1, - h2, - h3, - h4, - h5, - h6 { - padding: 0 16px; - } - - p, - pre, - .table-wrapper { - padding: 0 16px; - } - - blockquote { - padding-left: 16px; - } -} diff --git a/docs/src/prophet-theme/css/fonts.css b/docs/src/prophet-theme/css/fonts.css deleted file mode 100644 index 59335f1..0000000 --- a/docs/src/prophet-theme/css/fonts.css +++ /dev/null @@ -1,10 +0,0 @@ -html, -input { - font-family: "Open Sans", sans-serif; - font-weight: 500; - font-synthesis: none; - text-rendering: optimizeLegibility; - -webkit-font-smoothing: antialiased; - -moz-osx-font-smoothing: grayscale; - -webkit-text-size-adjust: 100%; -} diff --git a/docs/src/prophet-theme/favicon.svg b/docs/src/prophet-theme/favicon.svg deleted file mode 100644 index bc47932..0000000 --- a/docs/src/prophet-theme/favicon.svg +++ /dev/null @@ -1,108 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/docs/src/prophet-theme/index.hbs b/docs/src/prophet-theme/index.hbs deleted file mode 100644 index 19a260c..0000000 --- a/docs/src/prophet-theme/index.hbs +++ /dev/null @@ -1,327 +0,0 @@ - - - - - - {{ title }} - {{#if is_print }} - - {{/if}} - {{#if base_url}} - - {{/if}} - - - - {{> head}} - - - - - - - - - - - - {{#if favicon_svg}} - - {{/if}} - {{#if favicon_png}} - - {{/if}} - - - - {{#if print_enable}} - - {{/if}} - - - - {{#if copy_fonts}} - - {{/if}} - - - - - - - - {{#each additional_css}} - - {{/each}} - - {{#if mathjax_support}} - - - {{/if}} - - - - - - - - - - - - - - - - -
- -
- {{> header}} - - - - {{#if search_enabled}} - - {{/if}} - - - - -
-
- {{{ content }}} -
- - -
-
- - - -
- - {{#if live_reload_endpoint}} - - - {{/if}} - - {{#if google_analytics}} - - - {{/if}} - - {{#if playground_line_numbers}} - - {{/if}} - - {{#if playground_copyable}} - - {{/if}} - - {{#if playground_js}} - - - - - - {{/if}} - - {{#if search_js}} - - - - {{/if}} - - - - - - - {{#each additional_js}} - - {{/each}} - - {{#if is_print}} - {{#if mathjax_support}} - - {{else}} - - {{/if}} - {{/if}} - - - diff --git a/docs/src/prophet-theme/js/base.js b/docs/src/prophet-theme/js/base.js deleted file mode 100644 index 0dae171..0000000 --- a/docs/src/prophet-theme/js/base.js +++ /dev/null @@ -1,13 +0,0 @@ -(function base() { - /** - * Make chapter containers without link clickable - * - * You don't always want for a chapter to have a page in itself, - * in that case, whenever clicked it should trigger the toggle button - */ - document.querySelectorAll('.chapter li > div').forEach((elm) => { - elm.addEventListener('click', () => { - elm.nextElementSibling.click(); // click on toggle - }); - }); -})(); diff --git a/docs/src/prophet-theme/js/solidity.min.js b/docs/src/prophet-theme/js/solidity.min.js deleted file mode 100644 index 1924932..0000000 --- a/docs/src/prophet-theme/js/solidity.min.js +++ /dev/null @@ -1,74 +0,0 @@ -hljs.registerLanguage("solidity",(()=>{"use strict";function e(){try{return!0 -}catch(e){return!1}} -var a=/-?(\b0[xX]([a-fA-F0-9]_?)*[a-fA-F0-9]|(\b[1-9](_?\d)*(\.((\d_?)*\d)?)?|\.\d(_?\d)*)([eE][-+]?\d(_?\d)*)?|\b0)(?!\w|\$)/ -;e()&&(a=a.source.replace(/\\b/g,"(?{ -var a=r(e),o=l(e),c=/[A-Za-z_$][A-Za-z_$0-9.]*/,d=e.inherit(e.TITLE_MODE,{ -begin:/[A-Za-z$_][0-9A-Za-z$_]*/,lexemes:c,keywords:n}),u={className:"params", -begin:/\(/,end:/\)/,excludeBegin:!0,excludeEnd:!0,lexemes:c,keywords:n, -contains:[e.C_LINE_COMMENT_MODE,e.C_BLOCK_COMMENT_MODE,a,o,s]},_={ -className:"operator",begin:/:=|->/};return{keywords:n,lexemes:c, -contains:[a,o,i,t,e.C_LINE_COMMENT_MODE,e.C_BLOCK_COMMENT_MODE,s,_,{ -className:"function",lexemes:c,beginKeywords:"function",end:"{",excludeEnd:!0, -contains:[d,u,e.C_LINE_COMMENT_MODE,e.C_BLOCK_COMMENT_MODE,_]}]}}, -solAposStringMode:r,solQuoteStringMode:l,HEX_APOS_STRING_MODE:i, -HEX_QUOTE_STRING_MODE:t,SOL_NUMBER:s,isNegativeLookbehindAvailable:e} -;const{baseAssembly:c,solAposStringMode:d,solQuoteStringMode:u,HEX_APOS_STRING_MODE:_,HEX_QUOTE_STRING_MODE:m,SOL_NUMBER:b,isNegativeLookbehindAvailable:E}=o -;return e=>{for(var a=d(e),s=u(e),n=[],i=0;i<32;i++)n[i]=i+1 -;var t=n.map((e=>8*e)),r=[];for(i=0;i<=80;i++)r[i]=i -;var l=n.map((e=>"bytes"+e)).join(" ")+" ",o=t.map((e=>"uint"+e)).join(" ")+" ",g=t.map((e=>"int"+e)).join(" ")+" ",M=[].concat.apply([],t.map((e=>r.map((a=>e+"x"+a))))),p={ -keyword:"var bool string int uint "+g+o+"byte bytes "+l+"fixed ufixed "+M.map((e=>"fixed"+e)).join(" ")+" "+M.map((e=>"ufixed"+e)).join(" ")+" enum struct mapping address new delete if else for while continue break return throw emit try catch revert unchecked _ function modifier event constructor fallback receive error virtual override constant immutable anonymous indexed storage memory calldata external public internal payable pure view private returns import from as using pragma contract interface library is abstract type assembly", -literal:"true false wei gwei szabo finney ether seconds minutes hours days weeks years", -built_in:"self this super selfdestruct suicide now msg block tx abi blockhash gasleft assert require Error Panic sha3 sha256 keccak256 ripemd160 ecrecover addmod mulmod log0 log1 log2 log3 log4" -},O={className:"operator",begin:/[+\-!~*\/%<>&^|=]/ -},C=/[A-Za-z_$][A-Za-z_$0-9]*/,N={className:"params",begin:/\(/,end:/\)/, -excludeBegin:!0,excludeEnd:!0,lexemes:C,keywords:p, -contains:[e.C_LINE_COMMENT_MODE,e.C_BLOCK_COMMENT_MODE,a,s,b,"self"]},f={ -begin:/\.\s*/,end:/[^A-Za-z0-9$_\.]/,excludeBegin:!0,excludeEnd:!0,keywords:{ -built_in:"gas value selector address length push pop send transfer call callcode delegatecall staticcall balance code codehash wrap unwrap name creationCode runtimeCode interfaceId min max" -},relevance:2},y=e.inherit(e.TITLE_MODE,{begin:/[A-Za-z$_][0-9A-Za-z$_]*/, -lexemes:C,keywords:p}),w={className:"built_in", -begin:(E()?"(? { - themeSetLightButton.click(); - }); - - // react to toggle dark button click - themeToggleDarkButton.addEventListener('click', () => { - themeSetAyuButton.click(); - }); -})(); diff --git a/foundry.toml b/foundry.toml index b5b961d..5ca1d40 100644 --- a/foundry.toml +++ b/foundry.toml @@ -24,9 +24,6 @@ via_ir = true out = 'out-via-ir' src = 'solidity/test' -[profile.docs] -src = 'solidity/interfaces/' - [fuzz] runs = 1000 diff --git a/package.json b/package.json index a73f646..cd28c71 100644 --- a/package.json +++ b/package.json @@ -16,8 +16,6 @@ "coverage": "forge coverage --match-contract Unit", "deploy": "dotenv -- bash -c 'forge script Deploy -vv --slow --broadcast --rpc-url $OPTIMISM_RPC'", "deploy:local": "dotenv -- bash -c 'forge script Deploy -vv --slow --broadcast --rpc-url $LOCAL_RPC'", - "docs:build": "./build-docs.sh", - "docs:run": "mdbook serve docs", "postinstall": "husky install", "lint:check": "yarn lint:sol-tests && yarn lint:sol-logic && forge fmt --check", "lint:fix": "sort-package-json && forge fmt && yarn lint:sol-tests --fix && yarn lint:sol-logic --fix", diff --git a/vercel.json b/vercel.json deleted file mode 100644 index 30b00e4..0000000 --- a/vercel.json +++ /dev/null @@ -1,7 +0,0 @@ -{ - "version": 2, - "public": false, - "github": { - "enabled": false - } -}