Brian Chappell

The Agent Economy Needs Vetting. Blockchain Is Overkill.

By Brian Chappell on March 9, 2026

The agent-to-agent economy needs trust infrastructure. Blockchain is overkill. The answer is already in your DNS.

I’ve been watching the agent marketplace space evolve, and there’s a pattern I keep seeing: every new platform immediately jumps to blockchain-based reputation systems. It’s like we collectively forgot that we already solved this problem twenty years ago with email.

The Problem Nobody Wants to Solve Simply

Agent marketplaces are emerging everywhere. OpenAI’s GPT Store. Anthropic’s tool marketplace. Indie platforms letting you discover and hire AI agents for specific tasks.

But here’s the issue: How do you know the agent you’re hiring is legitimate? How does one agent verify another agent before engaging in a transaction?

The default answer I keep hearing: “Build a blockchain reputation system with token staking and on-chain reviews.”

That’s insane.

You’re telling me I need to:

• Pay gas fees to verify an agent?
• Wait for block confirmations before trusting a simple capability claim?
• Stake tokens just to publish my agent’s credentials?
• Navigate cross-chain complexity when agents live on different blockchains?

There’s a simpler way. It’s called domain-based verification, and it’s how email authentication works.

The Simple Solution: Borrow from Email

Email faced this exact problem in the early 2000s. How do you verify that an email actually came from who it claims? How do you prevent spoofing?

The answer: SPF, DKIM, and DMARC. Domain-based verification.

The trust model is elegant:

1. If you control the domain, you control what’s published at that domain
2. DNS is the source of truth
3. TLS infrastructure already secures the connection
4. No tokens, no gas fees, no blockchain needed

• Every agent is hosted somewhere (a domain)
• That domain owner can publish verification information
• Other agents can check that information programmatically
• Trust is transitive: “I trust example.com, so I trust agents published by example.com”

Enter: Agent Cards (.well-known/agent.json)

The A2A protocol (Agent-to-Agent) already includes this concept. It’s called an Agent Card, and it lives at .well-known/agent.json on your domain.

Here’s what a basic Agent Card looks like:

{
  "agent": {
    "id": "research-agent",
    "name": "Research Assistant",
    "version": "1.0.0",
    "provider": "example.com",
    "capabilities": [
      "web-search",
      "document-analysis",
      "citation-generation"
    ],
    "endpoints": {
      "api": "https://api.example.com/agents/research",
      "verification": "https://example.com/.well-known/agent-verify"
    },
    "contact": {
      "email": "[email protected]",
      "support": "https://example.com/support"
    }
  }
}

Any agent can fetch this file and know:

• What this agent can do
• How to call it
• Who to contact if something breaks

This is tier 1 verification: self-reported capabilities. Low barrier to entry. Anyone can publish this.

Adding DNS Verification (Tier 2)

But self-reported information isn’t enough for high-value transactions. You need proof that the Agent Card is actually authorized by the domain owner.

Enter DNS TXT records.

1. Publish a TXT record at your domain:

_agent-verify.example.com. TXT "v=agent1; id=research-agent; hash=sha256:abc123..."

1. The Agent Card includes a hash of its contents
2. Other agents verify by:

import dns.resolver
import hashlib
import json
import requests

def verify_agent(domain, agent_id):
    # Fetch Agent Card
    card_url = f"https://{domain}/.well-known/agent.json"
    response = requests.get(card_url)
    agent_card = response.json()

# Compute hash
    card_hash = hashlib.sha256(
        json.dumps(agent_card, sort_keys=True).encode()
    ).hexdigest()

# Check DNS
    txt_record = f"_agent-verify.{domain}"
    answers = dns.resolver.resolve(txt_record, 'TXT')

for rdata in answers:
        record = str(rdata).strip('"')
        if f"id={agent_id}" in record and f"hash=sha256:{card_hash}" in record:
            return True

return False

This is tier 2 verification: domain-proven authenticity. No blockchain needed.

DID:WBA – Decentralized Identity Without Blockchain

The newest proposal (2026) is DID:WBA (WebAgent DID). It’s a Decentralized Identifier spec that uses .well-known paths instead of blockchain ledgers.

did:wba:example.com:research-agent

1. Parse the DID to extract domain
2. Fetch https://example.com/.well-known/did/research-agent.json
3. Get public keys, service endpoints, verification methods
4. All verifiable via DNS TXT records

• No transaction costs (no gas fees)
• Instant updates (edit file, done—no block confirmations)
• Uses existing TLS infrastructure
• Easier key rotation (just update the file)
• Works offline (can cache .well-known responses)

• Cross-organizational reputation that nobody controls
• Permanent, immutable audit trails
• Token-gated agent access

For 95% of use cases? DID:WBA is simpler and cheaper.

The 3-Tier Implementation Model

Here’s how I’d implement agent verification progressively:

Tier 1: Agent Cards (Low Trust)

1. Publish .well-known/agent.json on your domain
2. List agent capabilities, endpoints, contact info
3. Any agent can fetch and discover what you offer

Tier 2: DNS Verification (Medium Trust)

1. Start with tier 1 (Agent Card)
2. Add DNS TXT record with card hash
3. Other agents verify DNS before trusting claims

Tier 3: Verifiable Credentials (High Trust)

1. Start with tier 2 (DNS verification)
2. Add cryptographic signatures to Agent Card
3. Issue W3C Verifiable Credentials for specific claims
4. Still domain-based (keys published at .well-known/jwks.json)

Why This Beats Blockchain

I’m not anti-blockchain. I’m anti-complexity-where-it’s-not-needed.

• No gas fees. You’re not paying per verification.
• Instant updates. Change your Agent Card, it’s live immediately.
• Familiar infrastructure. Developers already understand DNS and TLS.
• Transitive trust. “I trust this domain” extends to all agents published there.
• Works with existing tooling. HTTP clients, DNS libraries, JSON parsers.

• You need cross-organizational consensus (no single domain controls it)
• Immutability matters more than flexibility
• You’re building token-gated agent marketplaces

For most agent vetting? Start with domains. Add blockchain later if you actually need it.

The A2A Protocol and Linux Foundation

This isn’t hypothetical. The A2A (Agent-to-Agent) protocol moved to the Linux Foundation in June 2025. That’s a signal of maturity.

The protocol already includes:

• .well-known/agent.json specification
• Capability discovery mechanisms
• Agent-to-agent communication patterns
• Verification endpoint standards

The DID:WBA proposal is brand new (2026) and builds on this foundation.

• Standards are emerging
• Domain-based verification is the path forward
• Now is the time to implement, before blockchain complexity becomes default

Start Simple, Build Up

If you’re building an agent marketplace or deploying agents that need to interact with others:

• Publish an Agent Card at .well-known/agent.json
• List capabilities, endpoints, contact info
• Let other agents discover you

• Add DNS TXT record for verification
• Compute and publish your Agent Card hash
• Implement DNS verification in your agent code

• Add cryptographic signatures (if you need tier 3)
• Publish public keys at .well-known/jwks.json
• Issue Verifiable Credentials for high-trust claims

• Consider blockchain reputation if cross-organizational consensus is needed
• Evaluate token-gating for premium agent access
• Build on-chain audit trails if compliance requires it

The Takeaway

The agent economy is coming. Agents need to verify each other. But we don’t need to reinvent trust infrastructure.

• Works today
• Uses existing infrastructure
• Costs nothing
• Scales to billions of agents
• Proven by 20+ years of email authentication

Start with Agent Cards. Add DNS verification. Implement Verifiable Credentials if you need them.

Save blockchain for the rare cases where it’s actually necessary.

Building an agent marketplace? Start with Agent Cards today.

Sources & Further Reading