Avatars will represent a separate entity from vaults later on in the future, when multiples will be deployed (still early stage). I envisioned that to reduce gas top-up txs and job registration in 3rd party system (either Gelato or CL) actions, an avatar registry could be leveraged to automate all of this, and to only have the gas-station sending gas to the registry itself, who will be in-charged of paying all transaction fees.
Also, similar to our registry_v2 we could leverage some specific informations such as: avatar status, version, taskID and general metadata.
Actions carried over
Once a new avatar is deployed, it will be register in the avatar registry (via techops) and automatically keepers will be watching for this addition registering the job into the gelato or CL infrastructure and keeping thetaskID reference into a mapping together with the avatar contract address. This will register the "performUpKeep" task method, which will be called in the avatar contract and which is the resolver address and resolver data which may differ between one avatar and another, depending on their own specifications.
Tools
Have checked the Ops contract and it will be easily doable to leverage their infra to automatised all this logic, while being able to leverage flashbot txs to by-pass the mempool. Still up for confirmation if CL offers the same feature regarding flashbot integration.
General overview
Avatars will represent a separate entity from vaults later on in the future, when multiples will be deployed (still early stage). I envisioned that to reduce gas top-up txs and job registration in 3rd party system (either Gelato or CL) actions, an avatar registry could be leveraged to automate all of this, and to only have the gas-station sending gas to the registry itself, who will be in-charged of paying all transaction fees.
Also, similar to our registry_v2 we could leverage some specific informations such as: avatar status, version, taskID and general metadata.
Actions carried over
Once a new avatar is deployed, it will be register in the avatar registry (via techops) and automatically keepers will be watching for this addition registering the job into the gelato or CL infrastructure and keeping the
taskID
reference into a mapping together with the avatar contract address. This will register the "performUpKeep" task method, which will be called in the avatar contract and which is the resolver address and resolver data which may differ between one avatar and another, depending on their own specifications.Tools
Have checked the Ops contract and it will be easily doable to leverage their infra to automatised all this logic, while being able to leverage flashbot txs to by-pass the mempool. Still up for confirmation if CL offers the same feature regarding flashbot integration.
Resources
miro dash