Best automation & keepers in 2026

Automation & Keepers evaluated across what the automation network is authorised to do, and whether you can keep the address, exactly-once execution and stuck-queue recovery, what a stolen API credential can do before anyone notices, and where the gas float sits and how you get it back.

TukTuk (Helium)

#1 of 7 · published ranking

TukTuk (Helium)

80ChainChoice Score

Why it leads

11 points ahead of KeeperHub: +4.5 pts visibility of the non event, +3.7 pts survives the vendor

Cost

Not priced · No comparable price is published

Below the table

How this ranking works

Everything the table draws on continues here: how firm the #1 is, the per-criterion arithmetic behind each score, who pays ChainChoice, and the full guide to choosing.

Direct answer

What is the best automation & keepers in 2026?

TukTuk (Helium) ranks #1 overall for automation & keepers on ChainChoice. An open-source Solana crank protocol: the buyer posts a task with a per-crank SOL reward and any anonymous signer may execute it, so firing is time-only, but the executor set, the due-condition and the failed run are all public chain state — and a task can return its own successor, keeping a conditional loop entirely onchain. It holds that rank under an affiliate-blind methodology scored across 4 published, weighted criteria — the code that ranks providers physically cannot read affiliate payouts (CI-enforced), so a payout can't move a rank. The verdict re-computes on every fee change, incident, or regulatory action; full reasoning and the audit receipt are below.

Best picks

Best automation & keepers in 2026

Weighted on whether the job survives the vendor: who else can turn the crank, and what end-of-life is published, what can fire the call, against what target, and who can check the condition was true, whether a run that never happened is visible, or the job just goes quiet, and the lateness the vendor will put in writing, and the conditions under which it declines to execute, in that order. THE FAILURE THIS CATEGORY EXISTS TO PREVENT IS INSTRUMENTED BY NOBODY — 0 of 7. Not one vendor documents an alert that fires when a scheduled run does not happen, and the absence was established by exhausting each vendor's own corpus rather than by spot-check. Keep3r: 'notification', 'alert', 'monitor' and 'webhook' return zero hits across all 41 pages indexed at https://docs.keep3r.network/llms.txt.

Best overall

TukTuk (Helium)

Data checked Aug 2026

An open-source Solana crank protocol: the buyer posts a task with a per-crank SOL reward and any anonymous signer may execute it, so firing is time-only, but the executor set, the due-condition and the failed run are all public chain state — and a task can return its own successor, keeping a conditional loop entirely onchain. Strongest on what can fire the call, against what target, and who can check the condition was true (8/10): RE-VERIFIED 2026-08-14; all 23 published tuktuk.fun pages re-fetched. TRIGGER SURFACE — three documented types, all on one axis: time. The API reference at https://www.tuktuk.fun/docs/api/tuktuk-sdk carries a 'TriggerV0' table whose complete contents are two variants, 'Now' and 'Timestamp | i64'; the same two-variant… Weakest on the lateness the vendor will put in writing, and the conditions under which it declines to execute (6/10): (a) ANY PUBLISHED BOUND — none, established exhaustively rather than by spot-check. A full-corpus text search across all 23 live tuktuk.fun pages returns ZERO occurrences of 'SLA', 'uptime', 'guarantee' or any percentage figure of any kind. There is no stated check cadence and no blocks-per-turn figure anywhere. What… Published price: Creators of Task Queues set their payment per-crank turn in SOL. Crankers that run the tasks are paid out in SOL for each crank they complete. There is a minimum deposit of 1 SOL to create a task queue to discourage spam.

Best for: What can fire the call, against what target, and who can check the condition was true — 8/10

Why this score4 published criteria · leads 2 of 4

Published criterionWtScore, and the best hereGap/10Pts

What can fire the call, against what target, and who can check the condition was true6.7·87.2

Whether the job survives the vendor: who else can turn the crank, and what end-of-life is published7.2−187.7

Whether a run that never happened is visible, or the job just goes quiet5.8·75.4

The lateness the vendor will put in writing, and the conditions under which it declines to execute4.3−363.5

Σ methodology points23.7/32

Each bar is the score on that criterion’s own 0–10 scale, never rescaled to the pool. The dark line is the best any product here reached on that axis. Wt is the most the criterion can add to the 86-point weighted total. Pts is weight × score × 32; the sum is the methodology score, and each weighted point behind the leader costs 2.6 on the displayed score. how these are weighted

Considered and not ranked

12 products we looked at and left out

A shortlist is only honest if it says who it turned away. Each of these was assessed against the same published criteria as the ranked table and excluded for a stated reason — not overlooked.

We assessed 16 products here and rank 4 — 25% of what we looked at. That share is of the products we assessed, not of the category: how many exist is not something we can count, so we do not claim a number for it.

Tenderly Web3 ActionsGelato Web3 Functions / Gelato Automate· Ranked elsewhereOpenZeppelin Defender (Actions / Autotasks)· No longer operatingPyth Express Relay· No longer operatingDitto Network· Evidence incompletePowerPool / Power Agent v2· No longer operatingBrahma (Console / Automation Accounts)· No longer operatingClockwork (Solana)· No longer operatingAutonomy NetworkOlas / AutonolasOtimHalliday

Why it ranks first

Why TukTuk (Helium) leads this category right now

Best for

What can fire the call, against what target, and who can check the condition was true — 8/10

Main tradeoff

Read this before committing: the programs are UPGRADEABLE and one authority controls both. tuktukUrfhXT6ZT77QTU8RQtvgL967uRuVagWF57zVA and cronAjRZnJn3MTP3B9kE62NWDrjSuAPVXf9c4hu4grM are owned by BPFLoaderUpgradeab1e11111111111111111111111, and their programData accounts both report the SAME upgrade authority, pULUgsYtKvT7qhsL8QJ2oJXYQUeCCdjtfawPnBqEr3U (read via getAccountInfo on mainnet-beta, 2026-08-14). That account is system-owned with zero data and 2,426.04 SOL; whether it is a single keypair or a multisig vault cannot be determined from the account, and the vendor publishes nothing about who holds it. Everything this product scores well on — the unconstrained `crank_turner: Signer` that lets anyone execute your task — is code one key can replace, and there is no published continuity statement, sunset policy or security contact anywhere on the site or in the repo (no SECURITY.md, no CHANGELOG.md, /terms and /status both HTTP 404, status.tuktuk.fun NXDOMAIN). Three further things. (1) Firing is time-only: the published TriggerV0 enum is exactly {Now, Timestamp(i64)}, with cron expressions layered on by a second onchain program. There is no event, state, HTTP or cross-chain trigger. Unlike the draft's reading, a conditional loop IS supported without a server you own — a task's program can return its successor via RunTaskReturnV0, and the vendor publishes an instruction named `recurring_task` at https://www.tuktuk.fun/docs/api/cpi-example-sdk — but you must write and deploy that Solana program yourself; the platform evaluates nothing but the clock. (2) The executor count needs its caveat carried with it: seven distinct addresses ran RunTaskV0 in the verified window, but four of them have their FIRST-EVER transaction funded from one wallet, 4SP9UEdkdPsFgEVmERLXZ4aUAFGCJ2JUuBgFyYAnv8AF, on 2026-08-11 — three in a single transaction. The chain supports 'at least two independent operator groups', not 'seven independent operators'. (3) Nothing pushes: across all 23 published pages there is no webhook, alert, notification or email of any kind, so a defunded cron stops forever until a human polls — and the field the vendor's own monitoring page tells you to poll, removed_from_queue, is marked '// Deprecated: You should use the next_schedule_task instead' in the program source, while next_schedule_task appears on no page of the site. Separately, the homepage states the contracts are 'currently being audited. Use at your own risk.' with no auditor, report or date. PRICING, recorded as disclosure and ranked in no criterion: there is no subscription, no per-execution rate card and no vendor invoice. The buyer sets crank_reward per task in lamports (the CLI example at https://www.tuktuk.fun/docs/learn/create_a_task_queue uses --crank-reward 1000000, i.e. 0.001 SOL) and whichever anonymous signer executes it collects it; a live successful run logged 'Program log: Paying out reward 15000' (15,000 lamports) in signature 3iRR1cX8S7gbe3KiLDkG3KMhFu4V5D156YsaRPvibA9nnqhc7D6afoHxJpTraQsouKmhT3ewppsxfTR5fKXZSoLQ, slot 439184245, read on mainnet-beta 2026-08-14. That the crank reward is the ONLY fee is now verified rather than assumed: across all 17 .rs files of the tuktuk program, `uncollected_protocol_fees` appears exactly three times — twice as a struct field declaration in state.rs and once initialised to 0 in initialize_task_queue_v0.rs — with no code path anywhere that increments it. Pricing-shaped URLs tried, all HTTP 404 on 2026-08-14: /pricing, /docs/pricing, /terms.

Verify before signup

Creators of Task Queues set their payment per-crank turn in SOL. Crankers that run the tasks are paid out in SOL for each crank they complete. There is a minimum deposit of 1 SOL to create a task queue to discourage spam. This deposit is refunded when the task queue is closed.

Recommendation summary

What should decide this category

If this vendor shut down tomorrow, could anyone else call your job — or does it simply stop?

Does your condition live in code a third party can replay, or inside the vendor’s own servers?

How would you find out that a scheduled run silently stopped happening?

Quick picks

Strong options in this category

Start with the lead choice first, then use the shortlist only if you still need a challenger or stronger fit for a specific setup.

Best overall

TukTuk (Helium)

Best for: What can fire the call, against what target, and who can check the condition was true — 8/10

What can fire the call, against what target, and who can check the condition was true · 28%

8/10

Whether the job survives the vendor: who else can turn the crank, and what end-of-life is published · 30%

8/10

Whether a run that never happened is visible, or the job just goes quiet · 24%

7/10

The lateness the vendor will put in writing, and the conditions under which it declines to execute · 18%

6/10

Quick pick

KeeperHub

Hosted visual workflow runner for onchain automation: five documented trigger types (schedule/cron, per-block, contract event, webhook, manual) firing arbitrary contract calls from a Turnkey wallet, with the condition evaluated entirely inside vendor infrastructure — offset by an Apache-2.0 self-hostable scheduler and executor whose production Kubernetes values are published, and a numeric SLA that only begins at the $299 tier. Strongest on the lateness the vendor will put in writing, and the conditions under which it declines to execute (7/10): RE-VERIFIED 2026-08-14; score LOWERED from 8 to 7 after finding a third, contradictory availability figure the draft did not read, partly offset by a published retry bound it missed. (a) PUBLISHED BOUND — yes, numeric, pre-signature. keeperhub.com/pricing comparison table, row character-exact: "SLA | — | — | 99.9% |… Weakest on whether a run that never happened is visible, or the job just goes quiet (4/10): RE-VERIFIED 2026-08-14; score LOWERED from 5 to 4 on a strict reading of the fixed bands. (a) EXECUTION HISTORY AND WHO CAN READ IT — rich, and it does materialise the non-event, but vendor-only. docs.keeperhub.com/keeper-runs/status-logs documents a full per-run trace: a Trigger Log carrying "Trigger type (Scheduled… Published price: Re-verified character-exact on keeperhub.com/pricing, 2026-08-14. Pay per execution — "$0.01" / "Free to start. No commitments." / Executions 5,000 / Gas credits $1.

Best for: The lateness the vendor will put in writing, and the conditions under which it declines to execute — 7/10

What can fire the call, against what target, and who can check the condition was true · 28%

6/10

Whether the job survives the vendor: who else can turn the crank, and what end-of-life is published · 30%

6/10

Whether a run that never happened is visible, or the job just goes quiet · 24%

4/10

The lateness the vendor will put in writing, and the conditions under which it declines to execute · 18%

7/10

Quick pick

Same score, not joint · ordered by weighted total (41.90 against 41.60)

Reactive Network

An EVM chain whose contracts subscribe to origin-chain event logs and to validator-emitted CRON events, then fire arbitrary calldata at any of 12 mainnets through a callback proxy — the predicate is Solidity anyone can replay, but one single EOA delivers every callback on every chain. Strongest on what can fire the call, against what target, and who can check the condition was true (8/10): FOUR documented trigger types, each with a docs URL, all four re-confirmed against chain state on 2026-08-14. (1) Onchain log/event with filters — https://dev.reactive.network/subscriptions: "Subscriptions define which events reactive contracts listen to." filtering on the origin contract's chain ID, address and all… Weakest on whether the job survives the vendor: who else can turn the crank, and what end-of-life is published (2/10): (a) PERMISSIONLESS CALLABILITY AND SELF-RESCUE — no, and the refusal is in verified onchain source I re-read on 2026-08-14. The Ethereum CallbackProxy 0x1D5267C1bb7D8bA68964dDF3990601BDB7902D76 is verified on Blockscout (name CallbackProxy, compiler 0.8.28+commit.7893614a) and reads, character-exact: "modifier… Published price: No pricing page exists on either domain.

Best for: What can fire the call, against what target, and who can check the condition was true — 8/10

What can fire the call, against what target, and who can check the condition was true · 28%

8/10

Whether the job survives the vendor: who else can turn the crank, and what end-of-life is published · 30%

2/10

Whether a run that never happened is visible, or the job just goes quiet · 24%

7/10

The lateness the vendor will put in writing, and the conditions under which it declines to execute · 18%

6/10

Quick pick

DeFi Saver Automation

Closed-catalogue DeFi position automation: pre-deployed, individually auditable onchain Trigger contracts fire pre-registered Action recipes against a user's own Safe or DSProxy, executed exclusively by an onchain-allowlisted DeFi Saver bot fleet. 48 individual trigger pages are documented; 47 Trigger-named contracts carry deployed Ethereum mainnet addresses. Strongest on the lateness the vendor will put in writing, and the conditions under which it declines to execute (9/10): (a) PUBLISHED BOUND: a numeric check cadence, stated pre-signature on a public help page the buyer reads before enabling anything - character-exact, re-fetched 2026-08-14, https://help.defisaver.com/automations/when-are-automation-transactions-made.md: "The system checks all automated positions every minute in order… Weakest on whether the job survives the vendor: who else can turn the crank, and what end-of-life is published (4/10): (a) PERMISSIONLESS CALLABILITY AND SELF-RESCUE: none, and I re-verified it onchain rather than accepting the draft. Character-exact, re-fetched 2026-08-14: "In the current implementation, only DeFi Saver approved bots have access to calling strategy execution.

Best for: The lateness the vendor will put in writing, and the conditions under which it declines to execute — 9/10

What can fire the call, against what target, and who can check the condition was true · 28%

4/10

Whether the job survives the vendor: who else can turn the crank, and what end-of-life is published · 30%

4/10

Whether a run that never happened is visible, or the job just goes quiet · 24%

6/10

The lateness the vendor will put in writing, and the conditions under which it declines to execute · 18%

9/10

Frequently asked

Questions people ask before choosing keepers

How would I know if my job silently stopped running?

On the evidence here, you would not be told. Zero of the seven document an alert that fires when a scheduled run does not happen, and the absence was established by exhausting each vendor’s own documentation rather than by spot-check — on Keep3r the words “notification”, “alert”, “monitor” and “webhook” return zero hits across the corpus. This is the category’s signature failure and the reason to read the visibility axis before the price: a missed run produces no transaction, no revert and no error, so the only possible evidence is a record of an absence. Four of the seven at least leave a chain-reconstructible history a third party can audit without the vendor’s cooperation; the rest keep it inside a dashboard behind tiered log retention.

Is Chainlink Automation still a safe default?

Not today, and this is the clearest case in the pool of a product that looks alive to every check short of an event scan. Its registry emitted its last UpkeepPerformed on 5 August 2026 and none since, across full block coverage — while getState() still answers normally, reports paused=false, and the contract still holds over 19,000 LINK. Its own app says “Chainlink Automation is being deprecated”. The successor runtime genuinely is executing, but you cannot deploy to it without a human approving your request, it carries an Early Access notice, and no price is published anywhere. It is marked as sunset here, so it ranks below every operating product.

What does “decentralised execution” actually survive?

Two of the seven. Only Keep3r and TukTuk let a stranger turn the crank without asking anyone: Keep3r’s documentation states that “To become a keeper, you simply need to call bond(address,uint)”, with zero allowlist or whitelist hits across 41 documentation pages. Everywhere else the executor set is the vendor’s, so “decentralised” describes the network the job runs on rather than the party that decides whether it runs. That distinction is what the heaviest axis measures, and it is why the ranking here disagrees with brand recognition.

Will anyone tell me how late a call can land?

No. Zero of the seven publish any bound on the interval between the condition becoming true and the call landing — the one quantity the category exists to control. Six of the seven publish schedule granularity instead, which is a different thing: a thirty-second cron resolution says how finely you may express a schedule, not how long the network may take to honour it. Treat a granularity figure as a specification of the request, never as a guarantee about the response, and read the conditions under which each vendor declines to execute at all — that half is unmarketed and, where it is undisclosed, lateness is unbounded.

Free advisorNo signup needed

Still unsure? Get your best keepers pick

Answer a few quick questions and get one clear recommendation based on how you actually plan to use crypto — then review the evidence before deciding.

No signupFree first pass · PrivateNo spam · No account

Not financial advice · Independent · Always do your own research

Browse this network

How this ranking is built

Reviewed on what can fire the call and who can replay the condition, whether the job survives the vendor, whether a run that never happened is visible, and the lateness the vendor will put in writing. Weights are the engine’s: 30 / 28 / 24 / 18. There is deliberately no cost axis — per-execution price is already scored on the sibling page that ranks bundlers and paymasters, so it appears here only as recorded disclosure.

Data checked Aug 2026 · Independent rankings · We show our work

Not financial advice · For informational purposes only · Always do your own research