To handle duplicates, retries, and verification, we should identify a way to have an idempotency key for each transaction.
This should be loosely structured, and largely left up to the plugin to decide - however, they must make a PR to the verifier server containing the structure and predictable key generation flows.
For example, for a DCA transaction it may take the form of {pair}-{resolved-schedule}-{size}-{execution slot} - so the first swap from ETH to USDC on a daily schedule for 1 ETH may look like ETHUSDC-daily-20250501-100-0 and the second one may look like ETHUSDC-daily-20250502-100-1
For payrolls, it could be a mix of schedule + recipient + token.
They naturally cannot contain variable data, such as the on-chain txid of the attempted transaction, or other unpredictable or non-determinstic values
To handle duplicates, retries, and verification, we should identify a way to have an idempotency key for each transaction.
This should be loosely structured, and largely left up to the plugin to decide - however, they must make a PR to the verifier server containing the structure and predictable key generation flows.
For example, for a DCA transaction it may take the form of
{pair}-{resolved-schedule}-{size}-{execution slot}- so the first swap from ETH to USDC on a daily schedule for 1 ETH may look likeETHUSDC-daily-20250501-100-0and the second one may look likeETHUSDC-daily-20250502-100-1For payrolls, it could be a mix of schedule + recipient + token.
They naturally cannot contain variable data, such as the on-chain txid of the attempted transaction, or other unpredictable or non-determinstic values