When an On-Chain Agent Goes Down, Who Is Liable?

1. "Nothing to do" versus "not running" — how do you tell them apart

An agent going quiet has two very different possible causes: the market and position state genuinely never crossed any threshold that would trigger an action, so doing nothing is correct behavior; or the agent's off-chain component has crashed, hung, or lost communication with its on-chain side, and nobody happened to notice. From the outside these look identical — both show up as "no transactions for a while." The absence of new on-chain transactions alone can't distinguish the two, and the default assumption most users make is exactly backwards: treating silence as "everything's fine, nothing needs doing" rather than actively confirming the agent is still alive. The only reliable signal is a heartbeat or liveness check independent of business logic — does the agent, separate from sending transactions when conditions are met, emit a signal on a fixed cadence that exists purely to prove "I'm still running": a tiny periodic on-chain heartbeat transaction, a health-check endpoint an external party can poll, or a status report to an independent monitoring service. Without that kind of mechanism designed in, a user has no way to tell "the agent chose not to act" from "the agent has stopped" — until the damage has already happened.

2. Three buckets for assigning fault: the agent, an external dependency, or user misconfiguration

Once you've confirmed the agent has actually stalled, the next question is who's at fault — and that determines how liability and compensation get negotiated. Failures generally fall into three buckets. First, a problem in the agent itself: the process running it crashed, an uncovered edge case in the code, or a key-management failure that broke signing. Second, a failure in infrastructure the agent depends on: the RPC endpoint it connects to went down or started returning bad data, the oracle price feed it reads went stale or stopped updating, or the destination chain got congested enough that gas spiked past the agent's preset ceiling and its transactions never got included. Third, a misconfiguration on the user's own side: an approval allowance set too low, insufficient gas-token balance in the agent's wallet, or a whitelist missing a necessary contract address. These three buckets carry entirely different liability: the operator generally bears responsibility for the first, liability for the second depends on how the service terms allocate it, and the third generally isn't the operator's fault at all. Without first placing a failure into one of these three buckets, there's no meaningful basis for a liability discussion.

3. What verifiable trace each type of failure leaves behind

The good news is that these three failure types usually leave distinct technical traces, and with deliberate checking you can largely reconstruct what actually happened. A crash in the agent itself typically stops the heartbeat too — a sign the whole process or service is down, not just one category of business transaction; if the operator kept internal error logs or stack traces, those point directly to the code path. An external-dependency failure looks different: the heartbeat may keep running fine while business transactions visibly stall at one specific step — you can check whether a public status page or third-party monitor logged an outage for the RPC endpoint the agent used during that window, check the last on-chain update timestamp on the oracle contract the agent reads against the failure window, or pull the actual gas-price curve for the destination chain during that period to see whether it genuinely exceeded the agent's configured ceiling. A user misconfiguration usually leaves a trace directly on-chain: insufficient allowance or balance produces a failed or rejected transaction when the agent tries to act, and that record is itself the most direct evidence. Verification should proceed in order — check whether the heartbeat stopped, check whether the external dependency had a publicly documented anomaly at the time, check on-chain for a rejected transaction tied to a configuration issue — rather than settling for the operator's bare claim of "system normal" or "external cause."

4. "Best effort" clauses: they read like a promise, but rarely function like one

Most agent service terms include language along the lines of "best effort to maintain continuity and timeliness of service," which reads like a liability commitment at first glance but rarely functions as an enforceable compensation obligation once you unpack it: it gives no concrete uptime figure, no defined threshold for how long a failure has to last before it counts as a breach, and no stated formula or cap for what gets paid out if it does. A genuinely binding clause, by contrast, needs several concrete elements: a specific availability or response-time metric (e.g., heartbeat silence beyond N minutes counts as unavailable); a clear allocation of fault, spelling out which external-dependency failures the operator is on the hook for and which it isn't; a concrete compensation formula — refund of a service period's fee, or actual-loss reimbursement; and whether that compensation is capped, and whether the cap is reasonable relative to what a user could plausibly lose. Common loopholes include: using unquantifiable phrases like "best effort" or "commercially reasonable effort" as the entire service commitment; limiting compensation to a fee refund while excluding any financial loss caused by the failure outright; and preemptively disclaiming all liability for any third-party infrastructure failure, without distinguishing whether the operator chose and configured that infrastructure itself. The most direct test of whether a clause has real teeth: if the agent's own fault genuinely caused a loss, can you point to the clause and demand a specific, calculable payout — if the answer is no, the clause is functionally just a disclaimer.

5. Don't rely on the agent alone: user-side self-monitoring and circuit breakers

Even a clearly written compensation clause only reimburses damage after the fact — it can't retroactively fire a missed liquidation-avoidance action or recover a payment that already failed to send, so anything with real financial consequences shouldn't rest its full trust on a single path through the agent. Practical user-side backstops include: a monitoring script independent of the agent, controlled by the user, that periodically checks the agent's heartbeat and key position metrics and fires an alert the moment silence exceeds a preset threshold; a circuit breaker set up for the worst case, such as a user-controlled stop-loss or liquidation-protection order that sits independently of the agent and still functions even if the agent goes fully dark; and for automated-payment use cases, a hard cap on the amount per transaction and per period, so a logic bug in the agent can't produce an unbounded loss. The common thread across all of these is not depending on the agent to self-report that it's fine, but keeping an independent verification and fallback mechanism the agent can't unilaterally bypass — so that even while a liability determination and compensation process plays out over time, the actual financial exposure has already been bounded to something tolerable.

6. What to verify before trusting an agent with real money

Before handing an AI agent anything with real financial consequences, it's worth verifying, item by item: does the agent expose a heartbeat or health-check mechanism independent of its business transactions, and can a user subscribe to or poll it directly rather than waiting to be notified; do the service terms state concrete availability and compensation figures rather than unquantifiable language like "best effort"; do the terms clearly separate liability for the agent's own faults from liability for external-dependency failures; is the compensation cap reasonable relative to the scale of funds the agent manages, or is it low enough to be effectively meaningless; can a user set an independent stop-loss, liquidation protection, or amount cap outside the agent without it conflicting with or being overridden by the agent's own logic; and has the operator had downtime or failure incidents before, and how were they handled and disclosed at the time. Clear answers to these before entrusting real funds to an agent make liability determination and remediation far smoother if a failure does occur; if these questions can't currently be answered, the scale of funds under the agent's management should be capped at whatever amount you can tolerate losing if it fails.

7. Summary and a verification checklist

• Absence of new on-chain transactions alone isn't proof the agent is fine — a heartbeat or liveness signal independent of business logic is needed to separate "nothing to do" from "already stopped."
• Fault falls into three buckets — the agent itself, external dependencies like RPC/oracles, or user misconfiguration — and liability differs entirely across them.
• Verify in order: whether the heartbeat stopped, whether the external dependency had a documented anomaly at the time, and whether on-chain records show a transaction rejected due to misconfiguration.
• "Best effort" language rarely constitutes an enforceable compensation obligation; a binding clause needs a concrete availability metric, fault allocation, and payout formula.
• Don't put full trust in a single path through the agent — user-controlled monitoring alerts, independent stop-loss/liquidation protection, and amount caps are necessary backstops.
• Before trusting an agent with real funds, verify its heartbeat mechanism, concrete contract terms, fault allocation, compensation cap, and whether self-backstops are actually usable.

Frequently asked: does an agent going quiet for a while mean it has failed? Not necessarily — it may simply be that market conditions never triggered an action; an independent heartbeat signal is needed to tell the two apart. Is the operator always liable for downtime? It depends on the failure type — the operator typically bears responsibility for faults in the agent itself, while liability for external-dependency failures or user misconfiguration depends on the specific terms and evidence. Can a "best effort" commitment be used to demand compensation? Rarely — that kind of language usually doesn't constitute a concrete, enforceable obligation; check whether the terms give a quantifiable metric and payout formula. This article is for learning and research purposes only, discusses abstract mechanisms without naming any real product, and does not constitute investment advice; please make your own judgment and take responsibility for your own decisions.