Archer Protocol

Archer Protocol is the platform where agents go to get stuff done. Today, the majority of commerce is human-to-human. But tomorrow, we predict it will be predominantly agent-to-agent. And that means these consumer agents will need a clear picture on how to discover, pick, and pay for the best agents and services given a plain language requirement.

It also means that developers, from vibe coder to enterprise, will need an easy way to make their services not just visible, but executable and immediately monetizeable to other agentic users across the globe.

Archer is that solution, and it's live today at app.archerprotocol.com.

A non-custodial web3 backbone acts as the payment rails, and a user friendly agent deployment / connection form allows any service, whether it be an MCP server or a REST API endpoint, to plug right in and become accessible to humans and agents everywhere.

What I built for the hackathon were a series of open source adapters that make external protocols invocable as plain language intents inside Archer. It is a small microcosm of the universe of connectors and adapters that can be easily built and connected into the Archer railway. Archer does not build any intents; we merely amplify, and supercharge the distribution of these services, and make them extremely accessible to agents (and humans too!).

I chose the continuity track, so the platform bones have been built out already which includes a NextJS frontend web app for the primary search interface, PostgresDB storage, Privy embedded wallets and server signing, and Railway-hosted services, and MCP client connection skeleton.

The adapters are built out as a series Typescript-based services, and they are hosted on Railway. They are lightweight and do not persistently store user data, although the Walrus service indexes inbound identifiers from storage requests sent to it from Archer, so that the Walrus adapter can recognize where requests are coming from without duplication. In order to ensure the adapters cannot get exploited for infinite usage (which would hurt both Archer and the service provider), the adapters store within its surface an Ed25519 public key that corresponds to a private key held on Archer's deployed API service. If the adapter cannot prove it authenticates its endpoint against Archer's private key, then the adapter is blocked from contributing its endpoint to Archer.

To see more on how my adapters authenticate for Archer: https://github.com/Archer-Laboratories/ETH-Global-Archer/blob/test/shared/public-key-fetcher.ts

These adapters repackage what would traditionally be highly fragmented external APIs that would take a normal person ages to fully set up and call themselves. These adapters were deployed by me, and i set a fee recipient address for each toll that remits micropayments to my Base EVM wallet. An agent anywhere can make a request ranging from storing a file on Walrus from a claude code instance without needing to provision and fund a SUI wallet, to deploying an ENS address with plain language, to finding the right Canton data analytics provider and paying for an answer instantly with USDC leveraging EIP-3009.