-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add task templating framework #398
Comments
This is great, I was going to ask why we use the gnosis safe compatible JSON at this point if we never use the gnosis safe UI for signing. I think that we should optimize the file to be human readable, so a TOML file that includes a list of calls would be great. There should be an option to pass in raw calldata or to define an ABI encoding and the arguments to be encoded. Ideally this is written up as a design doc and shared with the protocol team before any implementation, as getting feedback from users is important |
the way we are thinking about this from a high level is having JSON file structures for different kinds of templatized tasks. We weren't planning on making things gnosis safe UI compatible for the JSON. ideally the templates would not take in raw calldata to make things as human readable as possible and allow for a standardized set of checks that are specific to each task type, e.g. bounds checking. |
queued |
@tynes the UX that we discussed (and ran by @sebastianst and @ajsutton, though mainly verbally, so we can write a design doc to ensure alignment) is that repeatable tasks have a template. Setting ProtocolVersions is a good example: The template is a single solidity file that defines the calls, and the validation checks. Those calls and checks are the same every time. Then, there are inputs (e.g. what should the new recommended protocol version be) that are read in from a TOML file. So creating a new task from a template would involve scaffolding the directory (like we already do), adding a TOML file with your input parameters, and running the solidity file from the template directory. It sounds like what you are describing is for bespoke tasks where you need custom calls and calldata. For those the UX will essentially be writing a regular forge script that holds the calls to make and the validation checks |
This will allow devs to create template tasks that can be easily created, and only require populating a TOML config file for execution
The text was updated successfully, but these errors were encountered: