Thoughts about autonomous transactions

[iFrostizz]

Autonomous transactions or transactions which are not triggered by an external actor are operations that can be used for various purposes, one of them being acting as a keeper.
Many protocols rely on people running these keepers in order to keep their system healthy, it is the case of decentralized exchanges or lending markets for instance. This operation costs gas and the keeper runners are incentivized to do so by receiving a reward in return.
If protocol designers are allowed to setup efficient autonomous transactions, then this value could stay in the protocol and be redistributed with more control.

@richardpringle brought the subject of efficiency, if we write these as event listeners, this won't scale very well because of all of the compute resources needed.

We may want to explore other ways of triggering autonomous transactions, such as pre/post processing.

This is an open discussion and can be used to talk about ideas around this concept.

[patrick-ogrady]

I could definitely imagine there being demand for begin/end block actions. I think "chain-owned" actions make total sense (where governance is allowed to setup/remove different mechanisms).

Allowing for "user-owned" actions seems a little hairier to me. There would probably need to be some way to limit them (otherwise, someone could queue 1M actions at the end of each block) and would need to pay fees (if utilization goes up, these actions shouldn't get a free pass). The fee may naturally limit the cardinality of said actions but we still may want an explicit limit in any case to avoid chain instability.

[iFrostizz]

I agree that these actions should incur a cost.
Hooks that could be triggered at the beginning or the end of a block would make sense. They would limit inter-block extractable value, but not the intra-block one. Arbitrageurs and liquidators usually compete for block space, either (or both) just before or after a transaction triggering an opportunity.
Some opportunities could be caught by a DEX if it is specially designed for that, which seems to be the case of Salty but it is very hard for these exchanges to coordinate to keep their price at a similar level, because they would need to put a lot of thought before deploying. Migrations are complex and not everyone wants to upgrade their protocols.

tldr; Having a post-hook would be useful to capture opportunities, but would probably start getting beaten by competitors pretty quickly because these opportunities will be known. The only executed operations would be those that are not profitable for searchers, so the economic incentive will probably dry out.

[patrick-ogrady]

When cleaning up the backlog, I found this related issue as well: #336

[iFrostizz]

Nice leftover! That would be a great entrypoint

[patrick-ogrady]

Upon thinking about this further, I think this makes less sense in a Post-Vryx world.

Builders could be given some space in each block to add their own transactions (on top of any included chunks) but there is no guarantee that they would have access to the pending state. Additionally, the requirement to specify state keys may make this even more fragile.

The path of registering special actions in state to execute at the end of each block (async) may make sense but the usefulness of this is unclear to me.

As a result, I'm removing this feature from the "Developer Ready" milestone.