Scheduled buying: the narrowest automation, and what it still requires
Buying a fixed amount on a fixed schedule is the simplest thing you can automate. There is no signal, no condition, no timing decision — just "every Friday, convert this much." It is the automation people reach for first, and often the only one they ever want.
Because the strategy is trivial, the interesting question is entirely about permissions: what does something need to be allowed to do, in order to do this?
The answer is less than most implementations ask for, and that gap is worth understanding before you grant anything.
We build Tradevo, so read accordingly.
What scheduled buying actually needs
To convert a fixed amount of one asset into another on a schedule, a system needs exactly three things:
- The ability to move a bounded amount — the amount you set, not your balance.
- The ability to act on a small, fixed set of assets — the pair you chose.
- A clock.
That is the whole requirement. Notably absent: the ability to sell, to touch anything else you hold, to move funds off the venue, or to decide when beyond the schedule you set.
Compare that with what most implementations are granted. An exchange API key with trading permission can place and cancel orders across your entire balance, in any pair the venue lists, at any time. That is a far larger permission than the task needs — not because anyone designed it badly, but because exchange API keys have one trading scope and it is account-wide. There is no "may only buy this pair, up to this much" checkbox.
Most of the time this does not matter, and it is not a reason to avoid exchange bots. It is worth knowing that the permission you grant for the simplest possible automation is the same permission you would grant for the most aggressive one.
Where each model draws the boundary
| Exchange scheduled buy | Bot with an API key | Scoped signing authorisation | |
|---|---|---|---|
| Who runs it | The venue | A third party | An operator, bounded by a signing policy and its own executor |
| Permission granted | Internal to your account | Trade across the whole balance | Swap allowlisted assets, within an allocation cap enforced by the operator's policy and executor |
| Can it act on other assets? | Per the venue's design | Yes, anything listed | No |
| Can it exceed the amount? | No | Yes, up to your balance | No |
| Where the assets sit | The venue | The venue | A wallet whose keys you hold |
| Stopping it | Cancel it in your account | Delete the key yourself | Cancel; the operator removes its signer, best-effort |
The middle column is the common case and the widest permission. The first is usually narrow but entirely inside one company. The third is narrow because the operator's executor applies the bound before signing — narrower in practice than an account-wide key, but kept by the operator rather than enforced by the chain. That is the argument for it, and the only argument worth making.
The part nobody mentions
Scheduled automation has a failure mode that has nothing to do with permissions: the schedule silently not running.
A buy that was supposed to happen and did not is invisible. There is no error, no notification, nothing to notice — the absence looks exactly like a quiet week. This is the most common real-world failure of scheduled strategies and it affects every implementation, hosted or self-run. Whatever you use, the question worth asking is not "can it execute" but "how would I know if it stopped."
An on-chain executor has one structural advantage here, and it is a small one: every execution is a public transaction. Whether it ran is a matter of record rather than a matter of trusting a dashboard.
When an exchange's own scheduled buy is the better choice
You already hold assets there and are comfortable with that. If the venue is already your custodian by choice, adding a wallet and an authorisation to automate a recurring purchase is complexity without a corresponding reduction in trust.
You want to buy with a bank transfer. Recurring purchases funded from a bank account are a venue feature. An on-chain executor cannot originate that.
You want the absolute minimum of moving parts. One account, one setting. Nothing about keys, networks or authorisations. For the simplest automation, the simplest setup is a defensible answer.
The asset only trades on centralised venues. No on-chain market, no on-chain execution.
When a scoped signing authorisation fits better
You want the permission to match the task. An allowlist and a cap describe what scheduled buying actually needs. An account-wide trading key describes far more.
You do not want the venue holding the assets between purchases. Scheduled buying means assets accumulating somewhere for a long time. Where that is matters more for a strategy measured in years than one measured in minutes.
You want to check it ran without trusting a dashboard. Public transactions answer "did it happen" without anyone's cooperation.
Related: What a trading bot can do with your exchange API keys · Tradevo's method
Tradevo Technologies builds evidence infrastructure for systematic trading. Nothing on this page is investment advice, and no part of it describes how any strategy performed. Crypto assets are volatile and you can lose your entire allocation.