We're building delegated automation on canton [Seeking Feedback + Champion]

Our team at Vacuumlabs developed contract automation in Canton. Useful for running automated tasks with onchain checks (number of runs, cooldown time, expiration) before execution, to be run by parties on behalf of another party, with a revokable Authorization. Currently we only support cron based executions, if there’s a need, we can look into other triggers as well. Completely self hosted, no fees.

Looking to hear if there are teams who have a need for this

github.com/canton-foundation/canton-dev-fund

This is our first proposal on Canton ecosystem, would appreciate some feedback from the community (and a champion too). We’ve also got another one in the pipeline (a DeFi primitive), that we’ll be announcing next week

Yes. We need it.

We run an agent wallet with a spend cap. Something has to pay for the owner,
inside the cap, and be easy to switch off.

On triggers: we need one that checks the cap at the moment it runs, not a
clock.

Happy to be your test user.

Hi @orumedominic

Glad to hear about your usecase, we would be glad to help you build with our solution. To answer your questions

We need “run only if the cap still allows.”, right now."

This would be an on-chain check. In addition to our checks (expiration, cooldown, number of runs), we will allow for custom logic like this. So all you’ll have to do is add a single line of your check on the DAML template.

Since you mentioned “run it right now” only, you’ll not need our cron running service. All you need would be to implement our interfaces in your contracts, and it’ll be enough.

When a check stops a run, nothing commits, so the ledger holds no record that the control fired.
Does yours leave anything behind, or is it a log line?

Proposal: A ledger record for refused actions (RFP 27, Security Monitoring, Auditability and Evidence) by dominicrume · Pull Request #860 · canton-foundation/canton-dev-fund · GitHub There is a proposal targetting this very issue. There’s also a discussion here How do you prove your app didn't do something? - #5 by orumedominic which could be useful.
We plan to store the logs for all runs offchain since the aborted/failed actions aren’t natively stored on-chain, and since there’s no standard pattern out there to commit them on-chain, it didn’t make sense to implement it within this proposal.

We can commit when a check fails, but then there can be a case when checks pass but something else fails/reverts later on in the transaction, and that will not be committed and cause inconsistencies for what goes onchain, if we use chain as the source of truth.

Thank you for the questions, I’ll reach out after our development phase completes after the proposal acceptance.

Those are both mine. Thank you for pointing me at my own homework.

You are right, and my design has the same hole. Check passes, something later
reverts, everything rolls back, and nothing is left.

The trade-off is real. Write the record in the same transaction as the work.
and the two can never come apart, but both die on a revert.
Write it first in its own transaction, and it survives, but now it no longer matches what
happened. You cannot have both.

Where I landed is that the refuse branch does not have your problem. When the
The check says no; the record is the only thing in that transaction. There is no
later step that can revert it.

The allowed branch does have it. If the work reverts, then nothing happened, so
The ledger is still right about the state. It just lost the fact that something
was tried.

So I do not claim a complete log of attempts. Only a complete record of
refusals that were decided.

Which is why offchain is the right call for reverts. Nobody has an incentive.
to hide a crash. People do have an incentive to lose a refusal. That is the
one that needs to sit where it cannot be quietly dropped.

And thanks for saying I would not need the cron service. Most people would
have sold me the bigger thing.