Making Bitcoin the Centre of the Agent Economy - In Practice

In Part 1, we introduced x402 - the protocol that lets agents pay for services within a single HTTP request. In Part 2, we explained how ERC-8004 adds the identity and trust layer that makes open agent markets possible.

Now comes the question we’ve been building toward: how do you actually build something?

This article is for developers who want to move from concept to code. Not a documentation walkthrough - the SDK handles the details - but a practical map of what’s possible, what it takes, and where to start.

What You Can Build

The x402 + 8004 stack unlocks a category of applications that simply couldn’t exist before: services where software pays software, at scale, without human mediation.

  1. Pay-per-call AI services.
    Instead of selling monthly API subscriptions, price each inference request individually. An agent calls your endpoint, pays $0.001, gets a response. No accounts, no rate limits tied to billing tiers, no invoice reconciliation. The payment is the authorization.

  2. Agent service marketplaces.
    Build platforms where agents discover, evaluate, and purchase capabilities from other agents. A research agent needs image generation? It queries available services, checks their 8004 reputation scores, pays via x402, and gets the result - all without human involvement.

  3. Monetized data feeds.
    Real-time market data, sentiment analysis, on-chain analytics - any information service can become pay-per-query. Agents subscribe to what they need, when they need it, paying only for what they consume.

  4. Trust-gated premium tiers.
    Use 8004 reputation to unlock service levels. New agents get basic access. Agents with established track records get priority queuing, better rates, or access to sensitive endpoints. Trust becomes programmable.

  5. Autonomous agent infrastructure.
    The agents themselves need services: compute, storage, coordination. Build the picks-and-shovels layer for the agent economy, where every resource is priced and purchasable by software.

And beyond this, the limit is your imagination.
But a common thread exists: removing humans from the transaction loop. Not because humans aren’t valuable, but because the sheer volume of agent-to-agent interactions will exceed what human oversight can manage.
The infrastructure needs to work without us in the middle.

The Integration Model

If you’ve built payment integrations before, x402 will feel familiar - but simpler.

Traditional payment flows require you to create accounts, generate invoices, handle webhooks, reconcile settlements, and manage subscription states. x402 collapses all of that into the HTTP layer itself.

Each transaction builds the trust graph for future counterparties

Here’s the mental model:

  1. You run a backend service that creates payment orders when a request comes in
  2. The client (agent or user) receives the order with a destination address and amount
  3. They pay by transferring tokens to that address
  4. Your backend confirms the payment landed
  5. You deliver the service

That’s it. No Stripe dashboard. No webhook endpoints. No subscription management. The payment is atomic with the request.

The SDK handles the cryptographic details - HMAC authentication, order creation, status polling, proof retrieval. Your job is to decide what to charge for and when to deliver.

Two Paths: Seller or Buyer

Most developers will start on one of two paths.

If you’re building a service (seller):

You want to monetize an API, model, or capability. Your integration looks like:

  1. Get merchant credentials from the GOAT Network team
  2. Install the server SDK (goatx402-sdk-server for TypeScript, or the Go module)
  3. Add order creation to your endpoint logic - when a request comes in, create an order for the price you want
  4. Poll for payment confirmation before delivering the response
  5. Handle cancellation for orders that don’t complete (this refunds your fees)

The SDK documentation walks through each step with working code. Start with the Developer Quick Start, then reference the API docs for edge cases.

A minimal integration can be running in an afternoon. A production-grade one - with proper error handling, monitoring, and cancellation flows - might take a few days.

If you’re building an agent or client (buyer):

You want your software to pay for services autonomously. Your integration looks like:

  1. Install the client SDK (goatx402-sdk)
  2. Connect to a wallet with tokens to spend
  3. Request a service and receive the payment order
  4. Execute payment via the SDK’s payment helper
  5. Handle the response once payment confirms
Same protocol. Two integration points. One agent economy.

The key architectural decision: where does your agent’s wallet live?

For prototypes, a hot wallet with limited funds works. For production, you’ll want more sophisticated key management - but that’s true of any system that holds value.

Adding Trust with 8004

x402 gets you payments. ERC-8004 gets you trust.

If you’re building a marketplace or any system where agents interact with unfamiliar counterparties, 8004 gives you the primitives to make trust queryable:

  • Register your agent or service with an on-chain identity and metadata URI
  • Query other agents’ reputation before deciding to transact
  • Record feedback after transactions to build the ecosystem’s trust graph

The 8004 spec is live on GOAT Network. Integration patterns are still emerging - we’re working with early builders to figure out what works - but the core infrastructure is ready.

If you’re building something where “should I trust this counterparty?” matters, reach out. This is an area where we’re actively collaborating with developers.

Why Build on GOAT Network?

You could implement x402 on any EVM chain. But here’s why GOAT Network is purpose-built for this:

  1. Agent-speed execution.
    Pay-per-call commerce doesn’t work if transactions take minutes. GOAT Network provides the latency profile agents need.

  2. Bitcoin settlement.
    Payments ultimately settle to BTC economics via BitVM2. Agents get the execution speed of an L2 with the trust properties of Bitcoin.

  3. Native SDK support.
    The x402 SDK is built for GOAT Network. Gas abstraction, cross-chain flows, and payment callbacks work out of the box.

  4. Decentralized sequencing.
    No single operator controls transaction ordering. For agents running 24/7, this removes a critical dependency.

And the list could go on. There is only one complete infrastructure designed for the use case. That infrastructure is GOAT Network.

Getting Started

The fastest path to getting something working:

  1. Read the SDK quick start: github.com/GOATNetwork/x402/blob/main/DEVELOPER_FAST.md
  2. Clone the repo and run the examples: Get a local payment flow working before customizing
  3. Request merchant credentials: Join the Discord and reach out to the team
  4. Build your first paid endpoint: Start simple - a single endpoint, a fixed price, basic error handling
  5. Iterate: Add cancellation flows, monitoring, and production hardening as you go

The documentation is technical but complete. If something’s unclear, ask in Discord - the team is actively supporting builders.

What’s Next?

The agent economy isn’t a future prediction anymore. It’s infrastructure being built right now.

x402 and 8004 are the payment and trust layers. GOAT Network is the execution environment. The SDK is ready. What’s missing is applications - the services, marketplaces, and agent systems that will define how this economy actually works.

That’s where you come in.

If you’re building something in this space - or even just exploring - we want to hear from you. The early builders will shape how agent commerce develops, and we’re actively working with teams who want to be part of that.

Reach out: discord.com/invite/goatrollup

The stack is ready. Let’s build.

Back to the Blog
Making Bitcoin the Centre of the Agent Economy - In Practice
Feb
12
By
GOAT
SHARE ON
Related Articles