
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.
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.
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.
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.

Here’s the mental model:
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.
Most developers will start on one of two paths.
You want to monetize an API, model, or capability. Your integration looks like:
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.
You want your software to pay for services autonomously. Your integration looks like:

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.
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:
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.
You could implement x402 on any EVM chain. But here’s why GOAT Network is purpose-built for this:
And the list could go on. There is only one complete infrastructure designed for the use case. That infrastructure is GOAT Network.
The fastest path to getting something working:
The documentation is technical but complete. If something’s unclear, ask in Discord - the team is actively supporting builders.
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.
