All posts

That's a Wrap on our First Hackathon. Here Is What 180 Builders Taught Us.

KeeperHub ETHGlobal Open Agents hackathon wrap-up

We reviewed every single one.

Not sampling, not spot-checks. The entire KeeperHub team went through all 180 submissions from the ETHGlobal Open Agents hackathon. That decision took more time than we expected and gave us more signal than any other product exercise we have done this year. This post is about what we found.


What the numbers showed

Before we get to winners, the full picture is worth sitting with.

Of 180 projects, 52 integrated via MCP and 40 via x402. Those two numbers together tell you something about where builder instincts are pointing: toward agent-native execution surfaces, not API adapters they have to maintain themselves. Builders did not want to manage HTTP calls and key rotation. They wanted to plug KeeperHub in as a capability and let their agents use it natively.

The remaining 88 split three ways. Around seventeen called KeeperHub's HTTP endpoints directly, bypassing MCP entirely. More work on their end, and shallower integration as a result, though some did it intentionally — KeeperHub Agent SDK targeted Python and LangChain environments where MCP tooling is less mature, and that was a deliberate choice. Around twenty-five used a webhook pattern: the agent acts, KeeperHub gets notified and handles the onchain side. Legitimate, but passive: KeeperHub as a settlement layer rather than a reasoning surface. The last thirty were surface integrations, one workflow created, rarely executed meaningfully, no real agent loop. The MCP and x402 cohort is the one actually pointing somewhere. The rest is teams finding the path of least resistance to meet the integration requirement.

What we saw independently converging across dozens of teams, without coordination: reusable SDK connectors for LangChain, ElizaOS, and OpenClaw. Not one team, not two. Multiple teams, working in parallel, arrived at almost the same abstraction. That is not a coincidence. It means the integration surface exists and builders are willing to build it, repeatedly, because there is no canonical version yet. That is a product gap we now intend to close.

The DeFi cohort ran deeper than we anticipated. Several teams did not just connect an agent to a protocol. They built multi-agent swarms where KeeperHub served as the shared execution primitive across all agents in the system. One agent decides. Another critiques. KeeperHub executes. That architectural pattern showed up independently in enough projects that it is no longer an edge case.

The builder feedback bounty was a good call. The teams who submitted feedback gave us reproducible issues, named friction points in the docs, and surfaced gaps in the API surface. Some of the most actionable product input we have received. 197 findings across submissions and feedback reports, distilled into 47 Linear tickets with priorities assigned. We are still working through them, and several are already shaping what ships next.


Why picking three winners was harder than we expected

Our prize structure had five slots. We used three of them for the main track. That was a deliberate choice.

We did not fill the remaining slots because nothing else met the bar. The bar was: is this something KeeperHub can merge, adopt, or build on directly? A compelling demo that does not survive contact with a real codebase is not a winner. A shallow integration with a polished pitch is not a winner. Several projects came close and did not make it. We know how much work went into them. The decisions were not easy.

Every score was the result of the full team doing the evaluation. We split up the 180 submissions, each person reviewed their stack independently, debated the close calls, and reached consensus. There were genuine disagreements. A few projects that ended up off the prize list had strong advocates on the team. The process was serious because the builders were serious.

To every team that submitted: we read your code. We watched your demo. We looked at your README. The work does not go unnoticed even when the prize does not follow.


The main track winners

1. Tradewise Agentlab

Showcase · GitHub

An autonomous onchain agent (tradewise.agentlab.eth) that quotes Uniswap swaps for x402 USDC payments on Base Sepolia. Every paid call triggers three KeeperHub workflows: heartbeat monitoring, reputation caching, and compliance attestation. The agent itself is an ownership-transferable iNFT with onchain reputation credit and revenue sharing through splits.

What distinguished this submission was production seriousness under hackathon conditions. 125 tests. Live deployment. Webhook-driven architecture that wired real x402 payment flows into real KeeperHub execution paths. The team also submitted detailed, reproducible bug reports for issues they hit in the KeeperHub API. That is not what you do if you are trying to look good. That is what you do if you actually plan to ship.

The iNFT model for agent ownership is a genuinely novel direction. An agent that can be transferred, that accumulates reputation, that earns and distributes revenue: the infrastructure architecture for that is more interesting than the demo makes it look.


2. Keeper-Gate

Showcase · GitHub

Keeper-Gate is a framework-agnostic SDK that wraps KeeperHub's execution capabilities as native tools inside LangChain, ElizaOS, and OpenClaw. Ten blockchain capabilities exposed cleanly: transfers, contract calls, conditional execution, workflow creation and management. Any agent using one of these frameworks can reach KeeperHub without writing a single line of HTTP glue.

The architectural decision that made this stand out was the separation between @keepergate/core and the per-framework adapters. Universal logic lives once. Each framework adapter is roughly 100 lines. A developer using LangChain and a developer using ElizaOS both get the same capabilities with none of the shared complexity duplicated. That is the right abstraction. It is also the abstraction that the team discovered, not the one we suggested.

This is exactly what we meant when we said we wanted integrations that other developers could use. Projects like Keeper-Gate and KeeperHub-PluginHub and several more ship that directly.


3. ZW.ARM

Showcase · GitHub

Real money. Real protocol. Real results.

ZW.ARM is a three-agent yield rotation system running on Base mainnet. An alpha executor pulls live APYs from Aave, Compound, and Morpho via KeeperHub read-contract workflows every 30 seconds. On a rebalance decision, it triggers a multi-step KeeperHub workflow: redeem, approve, supply. A beta agent manages subscriber wallets. A gamma agent provides independent LLM critique of every decision before execution.

Over the hackathon period: 450 confirmed transactions, 98.4% optimal decision rate, 12,559 cycles across 6.9 days, 5.07% APY on the underlying positions. Those are not projected numbers. They are from a live system with real USDC.

The critique agent is worth calling out specifically. Adding an independent agent whose job is to challenge every decision before execution is the kind of failure-mode thinking that most hackathon projects skip. ZW.ARM did not skip it.

There is one more architectural detail worth noting. When a user subscribes to a strategy on ZW.ARM's marketplace, the system automatically provisions a dedicated KeeperHub-managed wallet for that subscriber, isolated from everyone else's. Not one shared wallet for the whole application: per-user wallet provisioning on the fly. That means ZW.ARM used KeeperHub as wallet infrastructure for their end users, not just as an execution layer for their own agent. It is a meaningfully broader use case than most teams attempted, and a pattern reusable by any application that needs isolated onchain execution environments per user.


Feedback bounty recipients

ComputePool and EvoYield both received the $250 feedback bounty. Both submitted structured, actionable reports with reproducible issues and specific documentation gaps. We appreciate the time that takes, especially under hackathon time pressure. If you have more to share, the Discord is open year-round: discord.gg/keeperhub.


Honourable mentions

So many projects stood out across the 180 submissions. A few that deserve specific recognition: Aaether, Hydra, DoorNo.402, Antibody, ClawForger, FlowWage, SB03L, tollgate, KeeperHub Agent SDK, Reckon402, zhgg, Alps, Crucible, OpenClaw KeeperLink, KeeperKit, The Hedge Room, taars, and KeeperHub-PluginHub.

Each of these teams built something real. Several of them came very close to the main track list. We will be reaching out.


What comes next

This was our first hackathon. It will not be our last.

The signal from 180 projects is clear enough that we are already moving on it. The MCP surface is being extended. The framework SDK gap that Keeper-Gate pointed at is on the roadmap. The feedback bounty issues are in the backlog with actual engineers assigned to them.

If you built something during Open Agents and want to continue the conversation: find us. Our Discord is open. Our docs are public. The engineering team reads the feedback and responds.

If you did not submit this time but are building agents that need reliable onchain execution, the door is open year-round. You do not need a hackathon deadline to integrate KeeperHub or to tell us where the friction is.

We run infrastructure for AI agents operating onchain. We have been doing it for seven years. We want to hear from the builders who are doing the work.

More hackathons are coming. Stay close.

Join the KeeperHub Discord

Stay in the loop

Get the latest on Web3 automation, product updates, and technical deep dives delivered to your inbox.