fix: gelato relay

.env.example

@@ -1,7 +1,7 @@
 MAINNET_RPC=
 MAINNET_DEPLOYER_PK=
 
-GOERLI_RPC=
-GOERLI_DEPLOYER_PK=
+SEPOLIA_RPC=
+SEPOLIA_DEPLOYER_PK=
 
 ETHERSCAN_API_KEY=

README.md

@@ -1,33 +1,49 @@
-<div align="center"><strong>Keep3r Framework</strong></div>
+# XKeeper Core
 
-## Running tests
+[License: AGPL-3.0](https://github.com/defi-wonderland/xkeeper-core/blob/main/LICENSE)
 
-```bash
-yarn test
-```
+⚠️ The code has not been audited yet, tread with caution.
 
-In order to just run unit tests, run:
+## Overview
 
-```bash
-yarn test:unit
-```
+XKeeper is a public good for on-chain automation. It should be very easy to create a job which can be run both by Keep3r, Gelato, Autonolas, or any other keeper out there. We have also deployed compatible relays to ensure seamless integration, but XKeeper is designed to work with any keeper of your choice, providing you with the flexibility to select the one that best suits your needs.
 
-In order to run unit tests and run way more fuzzing than usual (5x), run:
+## Setup
 
-```bash
-yarn test:unit:deep
+This project uses [Foundry](https://book.getfoundry.sh/). To build it locally, run:
+
+```sh
+git clone [email protected]:defi-wonderland/xkeeper-core.git
+cd xkeeper-core
+yarn install
+yarn build
 ```
 
-In order to just run e2e tests, run:
+### Available Commands
 
-```bash
-yarn test:e2e
-```
+Make sure to set `MAINNET_RPC` environment variable before running integration tests.
+
+| Yarn Command            | Description                                                                                      |
+| ----------------------- | ------------------------------------------------------------------------------------------------ |
+| `yarn build`            | Compile all contracts.                                                                           |
+| `yarn coverage`         | See `forge coverage` report.                                                                     |
+| `yarn deploy:mainnet`   | Deploy the contracts to mainnet.                                                                 |
+| `yarn deploy:goerli`    | Deploy the contracts to goerli testnet                                                           |
+| `yarn docs:`            | 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.                                       |
+
+## Licensing
+
+The primary license for XKeeper contracts is AGPL-3.0, see [`LICENSE`](./LICENSE).
 
-# License
+## Contributors
 
-The scripts and documentation in this project are released under the [MIT License](LICENSE)
+XKeeper was built with ❤️ by [Wonderland](https://defi.sucks).
 
-# Contributors
+Wonderland is the largest core development group in web3. Our commitment is to a financial future that's open, decentralized, and accessible to all.
 
-Maintained with love by [Wonderland](https://defi.sucks). Made possible by viewers like you.
+[DeFi sucks](https://defi.sucks), but Wonderland is here to make it better.

build-docs.sh

@@ -7,14 +7,22 @@ excluded_path="external"
 temp_folder="technical-docs"
 FOUNDRY_PROFILE=docs forge doc --out "$temp_folder"
 
-# exclude the external folder from the generated docs
+# Exclude the external folder from the generated docs
 find "$temp_folder/src/$root_path" -type d -name "$excluded_path" -exec rm -rf {} \;
 
+# 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 '/Technical Documentation/q' docs/src/SUMMARY.md
+else
+  sed -i -e '/Technical Documentation/q' docs/src/SUMMARY.md
+fi
+
 # Copy the generated SUMMARY, from the tmp directory
 tail -n +4 $temp_folder/src/SUMMARY.md >> docs/src/SUMMARY_TEMP.md
 
 # Remove the external docs from the SUMMARY
-(head -n 1 docs/src/SUMMARY_TEMP.md && tail -n +12 docs/src/SUMMARY_TEMP.md) >> docs/src/SUMMARY.md
+(head -n 4 docs/src/SUMMARY_TEMP.md && tail -n +15 docs/src/SUMMARY_TEMP.md) >> docs/src/SUMMARY.md
 rm docs/src/SUMMARY_TEMP.md
 
 # Delete old generated interfaces docs
@@ -51,4 +59,4 @@ base_folder="docs/src/$root_path"
 replace_text "$base_folder"
 
 # Remove the external docs from the README
-perl -i -ne 'print if $. != 4' docs/src/solidity/interfaces/README.md
+perl -i -ne 'print if $. != 5' docs/src/solidity/interfaces/README.md

docs/src/SUMMARY.md

@@ -1 +1,32 @@
+# Summary
+
+# Documentation
+
+- [Getting Started](content/intro/README.md)
+
+  - [XKeeper](content/intro/xkeeper.md)
+
+- [How to use](content/howto/step_by_step.md)
+
+- [Core Contracts](content/core/README.md)
+
+  - [AutomationVault](content/core/automation_vault.md)
+  - [AutomationVaultFactory](content/core/automation_vault_factory.md)
+
+- [Relays Contracts](content/relays/README.md)
+
+  - [Keep3rRelay](content/relays/keep3r_relay.md)
+  - [Keep3rBondedRelay](content/relays/keep3r_bonded_relay.md)
+  - [GelatoRelay](content/relays/gelato_relay.md)
+  - [OpenRelay](content/relays/open_relay.md)
+
 # Technical Documentation
+  - [❱ interfaces](solidity/interfaces/README.md)
+    - [❱ core](solidity/interfaces/core/README.md)
+      - [IAutomationVault](solidity/interfaces/core/IAutomationVault.sol/interface.IAutomationVault.md)
+      - [IAutomationVaultFactory](solidity/interfaces/core/IAutomationVaultFactory.sol/interface.IAutomationVaultFactory.md)
+    - [❱ relays](solidity/interfaces/relays/README.md)
+      - [IGelatoRelay](solidity/interfaces/relays/IGelatoRelay.sol/interface.IGelatoRelay.md)
+      - [IKeep3rBondedRelay](solidity/interfaces/relays/IKeep3rBondedRelay.sol/interface.IKeep3rBondedRelay.md)
+      - [IKeep3rRelay](solidity/interfaces/relays/IKeep3rRelay.sol/interface.IKeep3rRelay.md)
+      - [IOpenRelay](solidity/interfaces/relays/IOpenRelay.sol/interface.IOpenRelay.md)

docs/src/content/core/README.md

@@ -0,0 +1,15 @@
+# Core Contracts
+
+The core contracts of the XKeeper project are the backbone of the framework. They can be used to generate new vaults, manage balances and approve and revoke permissions for callers and relays.
+
+## Core Contracts
+
+- The [`AutomationVault`](./automation_vault.md) contract manages on-chain job execution with relays, streamlining payment and serving as a core component in user-friendly on-chain automation.
+
+- The [`AutomationVaultFactory`](./automation_vault_factory..md) contract is responsible for deploying new instances of automation vaults.
+
+For more detailed information about each contract, please refer to the respective documentation pages.
+
+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.

docs/src/content/core/automation_vault.md

@@ -0,0 +1,13 @@
+# Automation Vault
+
+The `AutomationVault` contract is designed to facilitate the management of job execution with various relays and the payment of these relays for their services. The contract operates as a core component in the realm of on-chain automation. It provides a robust and user-friendly solution for defining and executing tasks while ensuring that payments are handled in a more straightforward manner.
+
+## Key Features
+
+- **Relay and Job Management**: The `AutomationVault` contract allows users to manage approved relays and jobs efficiently. It maintains a list of approved relays and jobs, providing control over who can perform specific tasks.
+
+- **Simplified Payment Handling**: Payment management has been simplified, allowing payments to be made in a more user-friendly manner. It supports both Ether (ETH) and ERC-20 tokens, ensuring that fees for job execution are processed seamlessly.
+
+- **Ownership Control**: The contract incorporates ownership management to ensure control over its functions. The owner has the authority to approve or revoke relays, callers, and selectors.
+
+- **Flexibility**: Users have the freedom to add or remove relays and select specific functions to be executed by jobs, granting them greater control over their automation processes.

docs/src/content/core/automation_vault_factory.md

@@ -0,0 +1,9 @@
+# Automation Vault Factory
+
+The `AutomationVaultFactory` contract is specifically designed to handle the deployment and management of automation vaults within the on-chain automation ecosystem. As a factory, it plays a crucial role in streamlining the creation of new automation vaults, each serving as a dedicated entity for job execution, relay management, and payment processing.
+
+## Key Features
+
+- **Efficient Deployment**: The primary function of the factory is to efficiently deploy new instances of automation vaults. This allows users to manage automation tasks, associated relays and handle balances.
+
+- **Automation Vaults Listing**: Enables users to retrieve a list of deployed automation vaults, allowing for efficient tracking and monitoring.

docs/src/content/howto/step_by_step.md

@@ -0,0 +1,43 @@
+## Tutorial: Deployment and Configuration of Automation Vault with Relays
+
+automation vault
+
+### Step 1: Deployment of the Automation Vault
+
+1. **Deploy Automation Vault:**
+
+   - Use the `AutomationVaultFactory` contract to deploy a new instance of `AutomationVault`. Make sure to provide the owner parameter.
+
+### Step 2: Adding Balance to the Automation Vault
+
+1. **Transfer Funds to the Vault:**
+
+   - Transfer the necessary funds to the automation vault to cover the costs associated with task execution. This could include ETH or ERC-20 tokens, depending on the protocol requirements.
+
+### Step 3: Approval of Callers and Relays
+
+1. **Approval of Callers:**
+
+   - Use functions in the automation vault to approve specific callers that should have permissions to interact with the automation vault.
+
+2. **Approval of Relays:**
+
+   - Ensure approval of relevant relays to be used for task execution. This might include relays such as `Keep3rRelay`, `Keep3rBondedRelay`, `GelatoRelay`, or `OpenRelay`, depending on the protocol's needs.
+
+### Step 4: Configuration of jobs and selectors
+
+1. **Approval of jobs:**
+
+   - To enable task executions, you need to approve specific jobs that the automation vault will interact with and will be allowed.
+
+2. **Approval of selectors:**
+
+   - Additionally, you need to approve specific function selectors for each approved job. This ensures that only designated functions within the approved jobs can be executed.
+
+### Step 5: Tracking and Monitoring
+
+2. **Tracking and Monitoring:**
+
+   - Monitor task executions through emitted events and other relevant metrics.
+
+With these steps, you should have a solid guide for a protocol to deploy its automation vault, configure necessary permissions and relays, add balance, and execute automated tasks.

docs/src/content/intro/README.md

@@ -0,0 +1,23 @@
+# Getting Started
+
+Keep3r Frameworks is a public good for on-chain automation. It should be very easy to create a job which can be run both by Keep3r, Gelato, Autonolas, or any other keeper out there. We have also deployed compatible relays to ensure seamless integration, but Keep3r Frameworks is designed to work with any keeper of your choice, providing you with the flexibility to select the one that best suits your needs.
+
+### Repositories
+
+- [Core Contracts](https://github.com/defi-wonderland/keep3r-framework-core)
+
+## Deployments
+
+<!-- TODO: List all contracts here -->
+
+## Licensing
+
+The primary license for Keep3r Framework contracts is MIT.
+
+## Contributors
+
+Keep3r Framework 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.

docs/src/content/intro/xkeeper.md

@@ -0,0 +1,13 @@
+# XKeeper
+
+## Why XKeeper?
+
+XKeeper offers a powerful solution for on-chain automation. Here's why you should consider using it:
+
+- **Simplicity**: With the assistance of our relays and vault, you'll be able to easily manage automation for your contracts, and the payment process will be smoother than ever before.
+
+- **Versatility**: XKeeper is built to be compatible with various keeper services, including Keep3r, Gelato, Autonolas, and others. You have the freedom to choose the keeper that best fits your requirements.
+
+- **Public Good**: We're committed to contributing to the blockchain community by offering XKeeper as an open and free resource, promoting automation and efficiency across the ecosystem.
+
+Join us in simplifying on-chain automation with XKeeper.

docs/src/content/relays/README.md

@@ -0,0 +1,19 @@
+# Relays Contracts
+
+Relay contracts in the XKeeper project play a key role in facilitating automated task executions from different networks. Each of these contracts provides specialized solutions to optimize task execution and manage the associated payments.
+
+## Relays Contracts
+
+- The [`Keep3rRelay`](./keep3r_relay.md): Orchestrates and executes tasks efficiently, ensuring a harmonious automation process within the Keep3r network.
+
+- The [`Keep3rBondedRelay`](./keep3r_bonded_relay.md): Introduces dynamic bonding requirements for automation vaults, enhancing security by validating tasks with bonded keepers.
+
+- The [`GelatoRelay`](./gelato_relay.md): Acts as a centralized hub for managing and executing tasks from the Gelato network, streamlining automation processes.
+
+- The [`OpenRelay`](./open_relay.md): Manages and facilitates the execution of tasks from various bots, ensuring efficient automation processes and fee payments.
+
+For more detailed information about each contract, please refer to the respective documentation pages.
+
+For more technical details about the interfaces of the relays 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.

docs/src/content/relays/gelato_relay.md

@@ -0,0 +1,15 @@
+## Gelato Relay
+
+The `GelatoRelay` contract, serves as a central hub for managing and executing tasks originating from the Gelato network, contributing to seamless automation processes and fee payments.
+
+## Key Features
+
+- **Task Execution Coordination**: The contract, in collaboration with the Gelato network, coordinates and executes tasks efficiently, ensuring a smooth and reliable automation process.
+
+- **Automation Vault Interaction**: This interaction centralizes multiple tasks within a single relay, streamlining the management of various tasks and their associated payments in a single function call. This feature enhances efficiency and reduces the complexity of task management, allowing users to handle multiple tasks simultaneously.
+
+- **Event Transparency**: Upon successful execution, the contract emits the `AutomationVaultExecuted` event, providing transparent insights into executed tasks and relay activities.
+
+## Gelato Network
+
+The `GelatoRelay` contract seamlessly integrates with the Gelato network, offering a robust solution for the execution of automated tasks while maintaining transparency in fee calculations and execution events.

docs/src/content/relays/keep3r_bonded_relay.md

@@ -0,0 +1,17 @@
+# Keep3r Bonded Relay
+
+The `Keep3rBondedRelay` contract efficiently manages executions originating from the Keep3r network when the job is bonded. This contract introduces bonding requirements for automation vaults, ensuring task executions are performed by legitimate bonded keepers.
+
+## Key Features
+
+- **Dynamic Bonding Requirements**: The contract introduces flexible bonding requirements for automation vaults. Vault owners can set specific bonding parameters, such as the required bond, minimum bond, earned rewards, and age, ensuring customizable security measures.
+
+- **Bonding Requirement Configuration**: Through the `setAutomationVaultRequirements` function, automation vault owners can dynamically configure bonding requirements. This feature grants control over the security measures necessary for task execution.
+
+- **Task Execution with Bonded Keepers**: The contract efficiently executes tasks with bonded keepers, validating their bonding status based on the configured requirements. This ensures that only legitimate bonded keepers can initiate and complete tasks.
+
+- **Event Emission**: Upon successful execution, the contract emits the `AutomationVaultExecuted` event. This event provides transparency into executed tasks, including details on the associated automation vault and the executed data.
+
+## Keep3r Network
+
+The `Keep3rBondedRelay` contract introduces a novel approach by incorporating dynamic bonding requirements for automation vaults. This design enhances security and control, allowing vault owners to customize bonding parameters and ensuring task executions are carried out by validated bonded keepers.

docs/src/content/relays/keep3r_relay.md

@@ -0,0 +1,17 @@
+# Keep3r Relay
+
+The `Keep3rRelay` is meticulously crafted to orchestrate and streamline task executions from the Keep3r network, offering a cohesive solution for efficient automation processes and fee payments.
+
+## Key Features
+
+- **Task Coordination**: The contract seamlessly coordinates task executions with an `AutomationVault`, ensuring a harmonious and streamlined automation process.
+
+- **Keeper Authorization**: Validation mechanisms guarantee that only authorized keepers within the Keep3r network can initiate and execute tasks, enhancing security and control.
+
+- **Optimized Execution Array**: The contract intelligently creates an array of executions, encompassing crucial steps such as keeper validation, injected execution data, and issuance of payments upon successful task completion.
+
+- **Event Transparency**: Upon successful execution, the contract emits the `AutomationVaultExecuted` event, providing transparent insights into executed tasks and relay activities.
+
+## Keep3r Network
+
+The `Keep3rRelay` combines task coordination, keeper validation, and event transparency to deliver a robust solution for streamlined automation processes within the Keep3r network. This design prioritizes efficiency, security, and user-friendly task execution.

docs/src/content/relays/open_relay.md

@@ -0,0 +1,21 @@
+# Open Relay
+
+The `OpenRelay` is designed to manage and facilitate the execution of tasks coming from various bots, ensuring efficient automation processes and fee payments.
+
+## Key Features
+
+- **Gas Management**: The contract employs gas management to optimize transaction costs. It calculates the gas spent and provides a gas bonus to ensure that the execution is efficient and cost-effective.
+
+- **Automated Fee Calculation**: The contract automatically calculates and handles fees for task execution. It uses gas metrics to determine the appropriate payment to be made to the automation vault.
+
+- **Seamless Task Execution**: The contract allows the execution of tasks within an automation vault. It ensures that all tasks are carried out smoothly, and fees are promptly paid to the designated fee recipient.
+
+- **Event Transparency**: Upon successful execution, the contract emits the `AutomationVaultExecuted` event, providing transparent insights into executed tasks and relay activities.
+
+## Gas Metrics
+
+- `GAS_BONUS`: 53,000
+- `GAS_MULTIPLIER`: 12,000
+- `BASE`: 10,000
+
+These gas metrics play a vital role in paying the caller for the work performed.

natspec-smells.config.js

@@ -0,0 +1,8 @@
+/** @type {import('@defi-wonderland/natspec-smells').Config} */
+module.exports = {
+  include: "solidity",
+  exclude: [
+    "solidity/(test|script)/**/*.sol",
+    "solidity/interfaces/external/**/*.sol",
+  ],
+};