In Part 1, we argued that x402 makes a missing commercial primitive finally feel “native” to the internet: a service can price an HTTP request, an agent can pay programmatically, and the same request can complete without a subscription flow, an account, or an invoice.
We also explained why this matters. Agentic software doesn’t behave like a human buyer. It doesn’t pick one vendor, create one account, and stay within one billing silo. It routes across tools dynamically, fans out requests, retries, and arbitrages between providers based on price, latency, and quality. If the agent economy is real, the dominant economic unit is not the monthly subscription - it’s the individual call.
But once you remove the friction of paying per call, you run into the next bottleneck: trust. An open market of agents and services cannot run on “account reputations” and private platform allowlists. The moment the buyer is software and the seller is software, trust needs to become queryable infrastructure.
That’s where 8004 comes in.
x402 answers the question “How does an agent pay for a resource right now?”, but it doesn’t tell you who you are paying or whether they are credible. In human markets, we outsource that to brand, contracts, and long-lived relationships. But this doesn’t work in agent markets.
An agent needs to quickly decide whether to transact with an endpoint it just discovered, which is about much more than just price. It’s also about identity continuity, prior performance, and whether the claim “I will deliver X if you pay Y” can be relied on without a direct or prior relationship.
If this isn’t solved then x402-enabled payments become a limited tool for closed marketplaces - not an enabler of open composition.
8004 can be described as a thin trust substrate for agents: it standardizes how an agent is identified and how trust signals are published and retrieved across counterparties.
It introduces a portable way to represent agent identity, point to canonical metadata (such as endpoints and capability descriptions), and attach evolving trust signals - reputation and validation outcomes - that other agents can query. It makes reputation legible and interoperable in a way that software can consume.
This is the natural complement to x402:
When these two ideas are combined, you get an end-to-end interaction that looks like something agents can run at scale:
An agent discovers a service and resolves it to a stable identity and metadata surface via 8004. It checks trust signals - prior feedback, validation signals, whatever the ecosystem converges on - then decides whether the price and risk are acceptable for the current task. If yes, it executes the x402 purchase loop and obtains the result. The outcome of that result can then be recorded back into the trust surface, so future counterparties have more evidence to price the interaction.
That last step is where trust is built. Without it, every call is a fresh leap of faith. With it, the ecosystem can converge toward measurable service quality and relatively predictable counterparty behavior.
This is where the “agent economy” thesis tightens: agents are likely to transact constantly and globally. If the system is open, the settlement asset becomes a coordination point. A neutral, liquid base asset is structurally attractive because it minimizes platform dependency and issuer risk.
BTC is the obvious candidate on those criteria: internet native, deep liquidity, broad recognition, and low platform dependency.
But the Bitcoin L1 is not designed for high-frequency, low-latency, interactive pay-per-call commerce. If you want agents to transact at machine speed while still settling back to BTC economics, you need infrastructure that provides a fast execution environment plus a credible path to BTC settlement and exits.
That’s where GOAT Network comes in: as the place where x402-style pay-per-call commerce can run at useful latency while identity/reputation/validation primitives remain interoperable and queryable in the same environment.
GOAT Network is the execution and settlement substrate that makes this stack viable in BTC terms:
• per-call commerce can run at agent throughput in a Type-1 zkEVM execution environment (so builders can ship Ethereum-equivalent apps without relearning a new stack)
• ordered by a decentralized sequencer network (rather than a single operator/central point of failure)
• Ziren eliminates trust in facilitators, enabling agent work to be proven and independently checked (so counterparties don’t need to rely on a centralized verifier or platform discretion)
• BTC settlement and exits remain trust-minimized (via BitVM2) so payments don’t collapse into platform IOUs
• an x402-compatible SDK that abstracts gas, payments, and cross-chain flows by default, so users can purchase services without managing networks or assets
Now, with ERC-8004 emerging as a practical identity and reputation substrate, the agent-commerce stack is finally close to complete: pay-per-call via x402, plus portable trust signals that can compound across an open market.
We’re actively working on integrating 8004 into the GOAT Network stack so agents can transact in BTC terms and carry verifiable identity and reputation end-to-end.
If you’re interested in building agent-based applications on GOAT Network, reach out to the team: discord.com/invite/goatrollup
.png)
