xKeeper is a keeper network aggregator which aims to decentralise the on-chain automation of DeFi. xKeeper, facilitates the use of multiple keeper networks, such as Keep3r Network, Gelato, or others. xKeeper is a fully modular framework, designed to be the backbone of future on-chain automation.
Scope
Contest Results
On what chains are the smart contracts going to be deployed?
Any EVM-compatible network. Beta version already deployed on Optimism Mainnet and Ethereum Mainnet
If you are integrating tokens, are you allowing only whitelisted tokens to work with the codebase or any complying with the standard? Are they assumed to have certain properties, e.g. be non-reentrant? Are there any types of weird tokens you want to integrate?
Any ERC20 token could be added into the AutomationVault, and any relay could be built to accept that ERC20 as form of payment. The system is completely modular.
Are the admins of the protocols your contracts integrate with (if any) TRUSTED or RESTRICTED? If these integrations are trusted, should auditors also assume they are always responsive, for example, are oracles trusted to provide non-stale information, or VRF providers to respond within a designated timeframe?
Each approved relay by an automation vault has the capability of withdrawing all the vault deposited funds.
In the case of the GelatoRelay, because of how Gelato works, their bots are trusted and have the possibility, if malicious, to steal the vault funds. So yes, Gelato is TRUSTED.
As for the other protocol integrations, there is no relevance to protocol admins, so everything else is RESTRICTED.
Are there any protocol roles? Please list them and provide whether they are TRUSTED or RESTRICTED, or provide a more comprehensive description of what a role can and can't do/impact.
Each automation vault has an owner, that role is TRUSTED for the vault itself, but RESTRICTED for the whole protocol.
For permissioned functions, please list all checks and requirements that will be made before calling the function.
AutomationVault
XKeeperMetadata
Keep3rRelay
Keep3rBondedRelay
Is the codebase expected to comply with any EIPs? Can there be/are there any deviations from the specification?
No.
Are there any off-chain mechanisms or off-chain procedures for the protocol (keeper bots, arbitrage bots, etc.)?
Each relay can require different types of keeper bots. However, this is out of scope of xKeeper since it is a completely modular and permissionless system.
Are there any hardcoded values that you intend to change before (some) deployments?
xKeeper defines specific instances of The Keep3r Network and Gelato Automate contracts for each chain. These contract addresses are hardcoded in the deployment scripts, and may change depending on the deployment chain or upgrades of the external service.
If the codebase is to be deployed on an L2, what should be the behavior of the protocol in case of sequencer issues (if applicable)? Should Sherlock assume that the Sequencer won't misbehave, including going offline?
Sherlock should not assume that the Sequencer won't misbehave.
Nevertheless, we are aware that if the Sequencer experiences downtime, naturally scheduled tasks within the Automation Vault that require timely execution might be delayed.
Should potential issues, like broken assumptions about function behavior, be reported if they could pose risks in future integrations, even if they might not be an issue in the context of the scope? If yes, can you elaborate on properties/invariants that should hold?
Yes.
Please discuss any design choices you made.
In designing our Automation Vault, we chose to accept payments in any ERC20 token for flexibility. However, Open Relay and Gelato Relay are currently set to only accept ETH due to its easy payment calculation. On the other hand, the Keep3r Relay uses its KP3R credits system, aligning with its specific ecosystem needs.
These choices reflect a balance between operational efficiency and user convenience within each relay's context. We're open to adapting these payment protocols based on protocols feedback and evolving integration requirements.
Please list any known issues/acceptable risks that should not result in a valid finding.
We assume that Gelato is in charge of calculating the payout in the Gelato Relay and therefore, if gelato becomes malicious, it could extract the entire balance from the automation vault that has passed the Gelato Relay.
For both the OpenRelay and the Keep3rRelay, the priority fee of the keeper is not taken into account by design. Keepers paying high priority fee is disincentivized.
We will report issues where the core protocol functionality is inaccessible for at least 7 days. Would you like to override this value?
-
Please provide links to previous audits (if any).
-
Please list any relevant protocol resources.
Additional audit information.
-
Total Rewards
Contest Pool
Lead Senior Watson
Judging Pool
Lead Judge
10,500 USDC
5,500 USDC
400 USDC
600 USDC
Status
Scope
Start Time
End Time
Finished
438 nSLOC
Apr 10, 2024, 3:00 PM
Apr 13, 2024, 3:00 PM