Best Practices for Compatible Contracts

This guide outlines the best practices when using Chainlink Automation. These best practices are important for using Chainlink Automation securely and reliably when you Create Compatible Contracts.

Revalidate performUpkeep on Automation-compatible contracts

We recommend that you revalidate the conditions and data in performUpkeep before work is performed. By default the performUpkeep is external and thus any party can call it, so revalidation is recommended. If you send data from your checkUpkeep to your performUpkeep and this data drives a critical function, please ensure you put adequate checks in place.

Performing actions ONLY when conditions are met in performUpkeep

Some actions must be performed only when specific conditions are met. Check all of the preconditions within performUpkeep to ensure that state change occurs only when necessary.

In this pattern, it is undesirable for the state change to occur until the next time the Upkeep is checked by the network and the conditions are met. It is a best practice to stop any state change or effects by performing the same checks or similar checks that you use in checkUpkeep. These checks validate the conditions before doing the work.

For example, if you have a contract where you create a timer in checkUpkeep that is designed to start a game at a specific time, validate the condition to ensure third-party calls to your performUpkeep function do not start the game at a different time.

Perform upkeep ONLY when data is verified via performData

Some actions must be performed using data you intend to use. Revalidate that the performData is allowed before execution.

For example, if you have a performUpkeep that funds a wallet and the address of the wallet is received via the performData parameter, ensure you have a list of permissable addresses to compare against to prevent third-party calling your function to send money to their address.

When performing actions in Automation-compatible contracts is not harmful

Sometimes actions must be performed when conditions are met, but performing actions when conditions are not met is still acceptable. Condition checks within performUpkeep might not be required, but it can still be a good practice to short circuit expensive and unnecessary on-chain processing when it is not required.

It might be desirable to call performUpkeep when the checkUpkeep conditions haven't yet been tested by Chainlink Automation, so any specific checks that you perform are entirely use case specific.

Always test your contract

As with all smart contract testing, it is important to test the boundaries of your smart contract in order to ensure it operates as intended. Similarly, it is important to make sure the compatible contract operates within the parameters of the KeeperRegistry.

Test all of your mission-critical contracts, and stress-test the contract to confirm the performance and correct operation of your use case under load and adversarial conditions. The Chainlink Automation Network will continue to operate under stress, but so should your contract. For a list of supported testnet blockchains, please review the supported networks page.