Solana on KeeperHub: Why Now, How We Built It in Two Weeks
We just shipped Solana support on KeeperHub. See the announcement if you haven't already. This is the story of why Solana, why now, and how the two-week build was possible.
Before adding SVM support, we spent years making sure the platform could support millions of EVM-based workflows. That meant getting four things right:
- Reliability. Provider failover, transactions that neither stall nor double-spend, and deduplication everywhere, because a workflow that fires twice has spent money twice.
- Security. Spending limits enforced by the platform before a transaction is built, not discovered after it lands.
- Scalability. Ingestion, matching, and execution pulled apart so that no one of them can drown the others.
- Developer experience, for our customers and for ourselves. A self-describing node surface, validation before creation, retries that cannot double-fire, and workflows that stay switched off until a human turns them on.
We run a single code path across Ethereum, Base, Arbitrum, and the rest, so hardening it once hardens it everywhere. None of this is EVM-specific: it's the shape any chain integration needs.
We Built With Other Kinds of Blockchains in Mind
Solana was part of our plan from the start. We didn't decide to support it and then scramble to find a way in: we built EVM support properly first, making every foundational choice with a second chain family in mind.
That's why we already had three pieces sitting in the platform with nothing Solana-shaped to do yet:
- The chain adapter: one interface describing what a chain must be able to do, without saying what a chain is.
- Turnkey-backed wallets: capable of signing whatever key material an organization holds.
- The ingestion tier: never told which blockchain it was watching.
We built each piece because it made the EVM implementation cleaner, and each was also the first thing we'd need in order to add SVM support. That's what made the two-week build possible: the pieces were already there.
The Ask, and the Wait
The reason to build came from an unexpected direction. Almost two months before we built it, an enterprise client running more than 50 workflows (clearing roughly 360,000 executions a month) asked us for Solana support. We didn't say yes right away: letting the last pieces of EVM click into place first would hand us the final insights, preparation, and security posture to build out SVM, and any other chain family after it, quickly instead of carefully. So we asked the client to sit tight, and finished what we'd started.
We'd just closed out the last stretch of that groundwork (a security patching push, a testing coverage push, and a new onboarding process) when a community member looked at what was now in place: Turnkey, the chain adapter, the dev tooling, the infrastructure. Their conclusion was that Solana was closer than it looked. They were right, and that judgment kicked off the two-week build. The timing wasn't luck: Solana is where a large share of on-chain activity happens, and the roadmap had been pointed here for a long time. A patient client just gave us the reason to call it.
Why Two Weeks, Not Two Quarters
Once we called it, two weeks was the target. Three things made that estimate hold.
The chain adapter carried the design. Every chain-touching operation already went through a single interface, with a registry picking the implementation for a given chain. Adding Solana meant writing one new implementation behind that interface, not threading a chain-family conditional through every action, every balance read, and every explorer link. That interface already had to handle EVM chains that differ in gas mechanics; it was drawn wide enough that a chain family sharing none of those mechanics still fits behind it, which was the point of drawing it that way.
An outside contributor built the primitives. KeeperHub is open source, and this is what that means in practice: the two pieces everything else stands on were landed in July by an outside contributor, Maitreya Gaikwad (@Assassin859). The read side: balances and provider failover against Solana, satisfying the same interface the EVM side does. The write side: signing Solana transactions with the organization's Turnkey-held key, routing between account types, and separating broadcast from retryable reads, so a retry can never re-send a transaction that already landed. He read a public codebase, saw what it was ready for, and built it. If you have been waiting for a reason to contribute to execution infrastructure, this is what it can look like.
Balances and signatures are the two primitives you cannot fake. With those in place, we spent the remaining two weeks on node surface and ingestion.
AI coding agents did the volume. Most of the implementation was agent-written against tickets, then reviewed and iterated. That's real, but it's also the least interesting of the three: agents multiply the throughput of a codebase that's ready to be extended. They don't create that readiness.
Keeping Up With a 400-Millisecond Chain
Not everything in those two weeks was work we could hand to an agent. Solana ingestion reuses the tier the EVM watchers already occupy. What the block time forced was a decision we never had to make on EVM: how to pull. Three interchangeable sources sit behind one interface.
| Source | How it works | Serves | Use when |
|---|---|---|---|
| Whole blocks | Polls blocks in batches, unfiltered | Event + block triggers | Low-volume chains. This is the default |
| Per-program lookups | Asks the chain only for activity touching a watched program | Event triggers only; it never sees a whole block | You want filtering without a stream |
| Geyser | A filtered stream pushed to us | Event + block triggers | Mainnet scale |
Which source a chain uses is configuration, not a rewrite: the same bet as the chain adapter, one layer down.
This is part 2 of 3. The announcement covers what shipped. Part 3, a devnet tutorial that runs every node end to end, is up next.
