Runrail

Reliability-first scheduler for recurring EVM contract calls. Private beta. Built for explicit execution outcomes, receipts, alerts, and no silent missed runs.

[Runrail @runrailapp]

Recurring protocol maintenance should not depend on a script nobody wants to debug at 2am.

Runrail is a private-beta scheduler for recurring EVM contract calls, built around explicit execution outcomes, receipts, alerts, and no silent missed runs.

Narrow scope. Reliability first.

[Runrail @runrailapp]

Runrail is opening up beyond closed beta.

We’re working on a public Base Sepolia sandbox with wallet sign-in, so anyone will be able to try scheduling real onchain executions without asking for access.

If you have a recurring onchain task you’d use this for, let me know.

[Runrail @runrailapp]

@DefiDebauchery We're building almost exactly this with Runrail: recurring EVM contract calls from a web console, using a stable relayer address you fund — no private key sharing.

We're still invite-only on Base Sepolia, but if that fits what you're trying to do, happy to get you into the beta.

[Runrail @runrailapp]

@carbonhoodeco That separation makes sense. When reconciliation finds a confirmed-but-unanchored record, does it hand it back to the relayer and track the outcome, or just flag it until an operator steps in?

[Runrail @runrailapp]

I wonder if the missing piece is less a universal bot and more a standard crank interface: the program exposes when work is eligible and how it can be advanced safely, while any operator can pick it up. That keeps execution permissionless without every protocol maintaining its own bespoke bot.

[Runrail @runrailapp]

This is a real Runrail PREPROD execution, opened in the console after it finished.

One scheduled call.
Primary path.
Attempt 1.
Confirmed on Base Sepolia.

🧾 The receipt and execution details are still there to inspect.

Running the transaction is only half the job. You should also be able to see exactly how it ended.

[Runrail @runrailapp]

@vanishree_rao One more thing to count: who owns failure when one of those dependencies breaks. The risk isn’t just outsourcing the primitive — it’s losing a clear owner for whether the job ran, reverted, or never resolved.

[Runrail @runrailapp]

@davidarngar @KrystalDeFi Strategy and execution should be measured separately. A good rebalance signal can still underperform once reverts, retries, gas and slippage are counted. Tracking each decision through execution would make the comparison much easier to trust.

[Runrail @runrailapp]

Infinite retries are not reliability.

Retries need a defined limit.

If recovery still fails after the final attempt, the execution should end explicitly as exhausted — not remain unresolved or start another cycle.

Runrail keeps retries bounded and exhaustion explicit.

[Runrail @runrailapp]

Attempt 2 should not become a second execution.

A retry is another bounded attempt to resolve the same scheduled slot.

Same slot. Same execution identity. One terminal outcome.

Lose that identity, and retry logic can execute the same scheduled call twice.

Each attempt stays bound to the execution it belongs to.

https://t.co/cPzimfjnqQ

[Runrail @runrailapp]

@Levison_Newsong @ritualfnd Explorer success isn’t a terminal state if eth_getTransactionReceipt is still null and eth_getCode is empty at later blocks. That’s unresolved state ambiguity until an independent RPC confirms the same chain state.

[Runrail @runrailapp]

A tx hash is not a success state.

Runrail does not mark a scheduled call successful at submission.

It tracks the execution to an explicit terminal outcome—confirmed or failed—then records a receipt.

There is no success state for “probably ran.”

[Runrail @runrailapp]

If your protocol relies on cron jobs, keeper scripts, or custom bots for recurring on-chain maintenance, what usually breaks first?

I’m looking for concrete failure cases:

missed runs
unclear retry behavior
gas or relayer issues
weak alerts
hard-to-debug incidents

Runrail is being built around one narrow problem:

making scheduled protocol maintenance fail visibly, recoverably, and without silent misses.

[Runrail @runrailapp]

Runrail v1 is intentionally narrow.

It is not a generic automation platform.

It is for one painful category: recurring on-chain maintenance calls that should either execute, fail explicitly, retry within policy, or leave a receipt.

No silent “maybe it ran, maybe it didn’t.”