Offchain Automation Pentest: Keepers, Relayers and Bots

Video transcript

Keepers, relayers and bots hold funded keys and act with nobody watching. If they are wrong, a sound contract faithfully carries out the wrong instruction.

Some of the largest crypto losses came through signing services and operational keys. None of them needed a contract bug.

Start with every key. Guardian found one Synthetix key holding three separate roles, GMX keepers able to claim excess fees, and a private key returned as a raw string.

At THORChain, a validator failed a signing step on purpose 864 times, leaking key material until it rebuilt the key. About ten million dollars was lost, THORChain said.

Next, inputs and queues. Watch for unvalidated swap quotes, zero block confirmations, tiny transfers that trigger paid runs, and messages acknowledged before the work is done.

Then cloud and alerting. Rekt reported that Ronin's attack went unnoticed for six days. Test public endpoints, secrets in logs, and alerts on failed signings and stalled jobs.

Guardian first defines what the automation must guarantee, then attacks its triggers and state transitions, key handling and retries, using a partly compromised signer set. Source code access is required.

The GMX keeper review produced 55 findings, eight of them High, all resolved. The Avantis backend review ran beside Guardian's V2 contract review, with both Criticals fixed while it was still running.

Read the full guide for the testing checklists, or talk to Guardian at guardian.security.

Keepers, relayers and bots hold funded keys and act with nobody watching. They decide what the contracts are asked to do, and when.

If the service driving a sound contract is wrong, the contract carries out the wrong instruction faithfully.

This guide covers what an offchain automation pentest tests, with real incidents and findings from Guardian's public reports.

Why the Backend Is Half the System

Some of the largest crypto losses came through signing services and operational keys, not contract code.

None of these needed a contract bug. Each turned on a key or signer that acted for the system.

Binance's initial report says the attacker used access to an internal wallet signing service to start transactions outside the normal withdrawal process.

Our Binance hack explainer covers the timeline and other estimates of the loss.

Keys and Transaction Policy

Start with every key the automation holds, and what each one can do.

Wintermute's hacked hot wallet was an admin of its DeFi vault, Rekt reported. The likely cause was a weakness in Profanity, a tool for making vanity addresses.

The firm had emptied that address of ether, but had not removed its admin role.

Bots are a direct target. The @solana/web3.js advisory said its malicious versions could drain "dapps, like bots, that handle private keys directly."

Guardian's public reports show the same pattern inside automation code:

• Synthetix withdrawal relayer (H-14): one key held the relayer, watcher and teller roles, though the contract was designed for independent watchers.
• GMX fee automation (M-01): payouts were measured against the keeper's own balance, so keepers could claim more fees than they were due.
• Synthetix LP vault keeper (M-08): the private key was returned as a raw string that downstream code could log.

What to test

• List every automated key, what it can call and the most one run can move.
• Give each role its own key. The key that requests should never approve.
• Enforce caps, allowlists and rate limits onchain where you can.
• Keep keys in a KMS or HSM, with a policy check before signing.
• Generate keys with vetted tooling, not vanity address generators.
• Revoke roles and allowlists the day they stop being needed.

For the key store itself, see HSM vs KMS for crypto signing keys.

Threshold Signers and Relayers

Threshold signing spreads one key across many parties. The test is what a few bad participants can force.

At THORChain, a validator planted a malformed key during vault setup. It then failed a signing step on purpose, 864 times over two and a half days.

Each failure leaked a fragment of other validators' key material. With enough, the attacker rebuilt the key, and its signature was "indistinguishable" from a proper one, THORChain said.

THORChain traced the flaw to the signing library it inherited, which implements GG20. It is adding monitoring of key-sign failures at the validator level.

Ronin shows the permissions side. The Axie DAO had let Sky Mavis sign on its behalf, as a temporary measure, and that access was never revoked, Rekt reported.

What to test

• What a sub-threshold subset can force, delay or learn.
• How participants authenticate and where key shares are stored.
• Recovery after one node is compromised.
• That every signing request binds the full payload, a nonce and an expiry.

Inputs, Queues and Replay

Automation acts on what it reads. Test every input it cannot verify, and every way a job can run twice or not at all.

• GMX keeper review: most of the eight Highs sat where the keeper's picture of a position disagreed with the contracts.
• Synthetix LP vault keeper (M-06): it executed whatever swap the ODOS API quoted, without validating it.
• GMX fee automation (M-02): event triggers used zero block confirmations, so a reorg could replay or skip events.
• GMX fee automation (M-03): any GMX transfer into the vault, even 1 wei, triggered a run, so an attacker could drain keeper balances.
• Synthetix withdrawal backend (H-06): a failed submission, as in an RPC outage, still acknowledged the message, so the withdrawal was lost.

What to test

• Staleness and deviation limits on every oracle and price feed.
• Simulate quoted trades and bound the result before signing.
• Wait for chain-appropriate confirmations before acting on events.
• Acknowledge a message only after its work is durable.
• Make jobs idempotent, so a duplicate run changes nothing.
• Set a floor on what can trigger a paid run.

Cloud, Admin Surfaces and Alerting

Automation usually runs in a cloud account with its keys close by. One loose permission can reach them.

• Synthetix LP vault keeper (M-03): a public API Gateway endpoint had no authorizer, so anyone with the URL could invoke it.
• The same keeper wrote private keys to CloudWatch in full payload logs, one of 20+ Web2 issues.
• Its new IAM role (remediation M-03) could read any secret in the account.
• Bounce Tech automation (M-03): the Kubernetes control plane was open to 0.0.0.0/0.

Then alerting. Ronin's attack went unnoticed for six days, Rekt reported, until a user could not withdraw 5,000 ETH.

• Alert on failed signings, unknown callers and sudden balance drops.
• Alert when a job stops, stalls or runs twice.
• Give operators a tested way to halt the automation mid-incident.

How Guardian Tests Automation

Guardian's offchain automation pentest covers keepers, relayers, bots and threshold signers, tested with hostile inputs and a partly compromised signer set.

The review first establishes what the automation must guarantee. Then it works through the triggers, state transitions, key handling and retries that break it.

It is scoped like a code review, and source code access is required.

Two case studies show the approach:

• GMX keeper review: 55 findings, eight High, all eight resolved. A fuzzing harness ran keeper logic against the contracts.
• Avantis backend review: run beside Guardian's V2 contract review. Two Criticals, both fixed while the review was still running.

For more results, read our offchain pentest findings report. For the wider surface, see what offchain security covers.

Frequently Asked Questions

What is an offchain automation pentest?

A security review of the keepers, relayers, bots and signing services that act for a protocol. Testers read the source and attack the logic with hostile inputs, failing dependencies and a partly compromised signer set.

Does a smart contract audit cover keepers?

Usually not. A contract audit reviews onchain code. A keeper decides offchain what to submit and when, so its math, keys, inputs and infrastructure need their own review, ideally beside the contract audit.

Why should each automated role have its own key?

So one stolen key cannot do everything. If the key that requests a withdrawal can also approve and pay it, a multi-party check becomes one party. Guardian's Synthetix withdrawal review found that pattern (H-14).

How is threshold signing attacked?

It can be attacked from inside the signer set. At THORChain in May 2026, a validator planted a malformed key, failed a signing step 864 times to leak others' key material, then signed alone. About $10M was lost, THORChain said.

Sources

• Rekt: Ronin Network, Rekt (March 29, 2022)
• Rekt: Wintermute, Rekt 2 (September 20, 2022)
• THORChain: THORChain Exploit Report #2 (July 3, 2026)
• Binance: 29 October 2026 Binance Security Incident, Initial Findings and Response Update (November 3, 2026)
• GitHub Advisory Database: @solana/web3.js malicious versions, GHSA-jcxm-7wvp-g6p5 (December 4, 2024)
• Guardian: Synthetix Withdrawal Flow (December 15, 2025)
• Guardian: Synthetix Auto-Compounding LP Vault (May 14, 2025)
• Guardian: GMX Fee Automation (August 25, 2025)
• Guardian: Bounce Tech Automation Layer and Contract Updates (December 10, 2025)
• Guardian: GMX Keeper Review case study
• Guardian: Avantis Offchain Review case study
• Guardian: Synthetix Auto-Compound LP Vault case study
• Guardian: Offchain Automation Pentest