THREE PROTOCOLS FOR THE AGENT ECONOMY

0. INTRODUCTION

The x402 playbook was simple: HTTP already had a status code reserved for payments (402 Payment Required) that was never implemented. Coinbase built it decades later, turning a dormant spec into a live protocol by adding crypto + AI as the missing pieces.

This document explores three more dormant or underused protocol features that are sitting there waiting for the same treatment. Each one has a moment where the protocol asks "who are you?" and accepts a weak answer.

The play is always the same: intercept that moment and replace the weak answer with a trust attestation — on-chain identity + reputation grade + cryptographic proof.

1. x407 — AGENT TRUST AT THE GATEWAY

The Dormant Code

HTTP 407 (Proxy Authentication Required) is one of the least-used status codes on the internet. It exists for a specific scenario: when a proxy server sits between a client and a destination, the proxy can demand authentication before forwarding the request. The client responds with a Proxy-Authorization header containing credentials. If they check out, the request passes through.

In practice, 407 is mostly encountered in corporate network environments. For the open web, it's essentially dead. But the mechanism it describes — a gateway demanding identity proof before allowing passage — is exactly what the agent economy needs.

The Opportunity

Repurpose 407 as the agent trust gate. When an AI agent hits a service through any gateway, proxy, or API router, the gateway responds with 407 and a new header:

Proxy-Authenticate: AgentTrust realm="origin-v1"

The agent responds not with a username and password, but with a trust attestation: its Birth Certificate hash, current trust grade, and a signed proof from the on-chain registry.

How the x407 Flow Works

┌──────────┐         ┌──────────┐         ┌──────────┐
│  AGENT   │──GET──►│ GATEWAY  │         │ SERVICE  │
│          │        │          │         │          │
│          │◄──407──│  "Prove  │         │          │
│          │        │  trust"  │         │          │
│          │        │          │         │          │
│          │──BC────│ Verify   │──OK───► │ Access   │
│          │  +sig  │ on-chain │         │ granted  │
└──────────┘        └──────────┘         └──────────┘

Why This Matters

x407 would be the agent-native equivalent of OAuth. Today, agents authenticate with static API keys or bearer tokens that say nothing about history or trustworthiness. A stolen API key works just as well in hands of a malicious agent. x407 replaces this with a dynamic, reputation-based credential that evolves over time.

Critical insight: 407 already exists in the HTTP spec. Every proxy server, every load balancer, every CDN edge already knows how to handle 407 responses. The infrastructure is built. What's missing is the authentication scheme. x407 defines that scheme as on-chain trust attestation.

Integration with ORIGIN

ORIGIN's existing infrastructure maps directly onto x407. The Birth Certificate is the identity credential. The AgentScoreRegistry provides the trust grade. The AgentWalletRegistry enables the EIP-712 signature. The bridge API at origindao.ai/api/agent/8004/[id] already serves as the verification endpoint.

x402 vs x407

2. AGENT DNS — THE TRUST DIRECTORY

The Existing Infrastructure

DNS is the backbone of the internet's naming system. TXT records store arbitrary text data and are used for email authentication (SPF, DKIM, DMARC), domain verification, and service configuration. The infrastructure is global, decentralized, cached everywhere, and virtually free.

Existing Work

IETF has BANDAID (Brokered Agent Network for DNS AI Discovery) for agent discovery. AID (Agent Identity & Discovery) uses _agent TXT records. MCP DNS Registry uses _mcp TXT records.

None include a reputation or trust layer. They answer "where is this agent?" and "what can it do?" but not "should I trust it?"

The Proposal — Trust-Enhanced Agent DNS

Extend emerging agent DNS standards with trust attestation fields pointing to on-chain reputation data.

_agent.example.com. 300 IN TXT "v=aid1; u=https://api.example.com/agent; p=mcp; t=A+; bc=0xac62...b0; chain=base; verify=https://origindao.ai/api/agent/8004/42"

New fields:

Trust-Gated Discovery Flow

Why DNS

Zero new infrastructure, decentralized by default, composable with BANDAID/AID/MCP standards. ORIGIN adds the reputation layer they're all missing.

Integration with ORIGIN

ORIGIN's bridge API is the verification backend. DNS record points to it. When trust grade changes on-chain, DNS TXT record updates. TTL matches update frequency.

3. AGENT IRC — TRUST-GATED COMMUNICATION

The Original Social Protocol

IRC launched in 1988, introduced channels, operators, user modes, permissions, bans, private messaging. Discord, Slack, Teams are all descendants. IRC's channel modes are the key primitive: +o (operator), +v (voice), +b (ban), +i (invite-only).

These modes are set manually by humans. Now imagine agents. The manual trust model collapses.

The Proposal — Trust-Automated Agent Channels

Build a modern agent communication protocol inheriting IRC's channel/mode architecture but replacing human judgment with on-chain trust verification.

Trust-Mapped Channel Modes

Channel Types for the Agent Economy

Why IRC's Model, Not A2A or MCP?

Current protocols are point-to-point. They handle structured task execution. But they don't model group dynamics. IRC's channel model is inherently multi-party: broadcasting, presence, persistent rooms, permission hierarchies.

A2A and MCP handle the work. Agent IRC handles the coordination.

4. THE FULL STACK: HOW THEY CONVERGE

These three protocols are layers of the same stack:

The Complete Agentic Web Stack

┌─────────────────────────────────────────────────┐
│  Layer 6 │ Agent IRC      │ Coordination       │
├──────────┼────────────────┼────────────────────┤
│  Layer 5 │ ThoughtProof   │ Decision Verify    │
├──────────┼────────────────┼────────────────────┤
│  Layer 4 │ x402           │ Payment            │
├──────────┼────────────────┼────────────────────┤
│  Layer 3 │ x407           │ Access             │
├──────────┼────────────────┼────────────────────┤
│  Layer 2 │ ORIGIN     ◄───── THE CENTER ────►  │
│          │ BC + Trust     │ Identity           │
├──────────┼────────────────┼────────────────────┤
│  Layer 1 │ Agent DNS      │ Discovery          │
├──────────┼────────────────┼────────────────────┤
│  Layer 0 │ World ID       │ Proof of Human     │
└─────────────────────────────────────────────────┘

x407 — REFERENCE IMPLEMENTATION

x407 is open source and ready to use. The reference implementation includes Express.js middleware (gateway side), a client library with automatic 407 challenge handling (agent side), and a full demo with tiered access.

const { x407 } = require("x407");

app.get("/api/data",
  x407({ minimumTrustGrade: 70 }),  // <-- that's it
  handler
);

const response = await trustedFetch(url, {
  tokenId: 42,
  wallet: agentWallet,
});