Proof of Trust

Part of the Vector Space series.

Email is decentralized. No single company runs it. Billions of messages route through competing servers every day. Spam filters work without a central authority deciding what’s legitimate. How does it work? And why can’t trust work the same way?

How to Trust Advertisers described the composite signal: payment history, reviews, semantic consistency, DNS records. Independently verifiable, no single gatekeeper. But each signal is isolated. A clean Stripe history doesn’t know about a Yelp rating. A domain age doesn’t know about a QuickBooks P&L.

A plumber who’s served the same neighborhood for twenty years has the evidence: Stripe transactions, customer reviews, a business license, supplier relationships. When she buys an ad, the platform treats her the same as a dropshipper who registered yesterday. The signals exist. They just don’t talk to each other.

What you’d need

To connect these signals into a trust graph, you’d need:

Cryptographic proof. Relationships need verification without asking either party. A signed attestation anyone can check.

Decentralized routing. No single company controls the exchange. Attestations need to reach multiple competing indices without a gatekeeper.

Universal adoption. The infrastructure needs to already exist. Builds on deployed identity and routing systems, not new wallets, blockchain nodes, or key management.

Federated curation. No single authority decides what counts as trust. Competing curators publish standards, publishers choose which to follow.

Blockchain tried this. PGP tried this. Both failed. Blockchain requires nodes, wallets, transaction fees, and consensus: too much infrastructure for incremental adoption. PGP requires key management, manual verification, and technical expertise: too complex for businesses. LinkedIn has endorsements but they’re locked in a closed platform. Certificate authorities have attestations but they’re only for domains, not business relationships.

Every attempt required building new infrastructure or adding complexity to existing workflows. The adoption barrier killed them.

Email. Email is the protocol.

DKIM provides cryptographic signatures. Every mail server checks them. SMTP routes between competing servers without a central authority. Most business email uses DKIM. Stripe sends DKIM-signed emails. So does every payment processor, review platform, and business service.

DKIM proves origin, not truth. A DKIM signature proves Stripe’s mail server sent the email; it doesn’t prove the relationship claim inside is accurate. That gap narrows through structure: bilateral confirmation requires both parties to forward emails (mutual acknowledgement), the exchange publishes the graph publicly (anyone can audit), and curators decide what the topology means (reputation interpretation). The cryptography proves “this came from stripe.com.” The bilateral flow attests that “both parties agreed to claim this.” The public graph enables “anyone can audit the topology.” Curators decide “this pattern suggests trust.” Collusion is still possible—the system makes it expensive to fake at scale, not impossible.

The infrastructure has been running for twenty years. We just format attestations as JSON in email bodies and forward them to an exchange. The exchange is a mail server with a graph database. Curators query the graph and publish allowlists. Publishers compose trust policies from multiple curators.

The pattern is email spam filtering. Mail servers subscribe to blocklists (Spamhaus, Barracuda, SpamCop), each choosing which lists to trust. No single list controls the ecosystem. Federated curation has worked for twenty years.

ads.txt proved platforms will adopt voluntary protocols if the fraud reduction incentive is clear. The IAB got publishers, exchanges, and platforms to publish machine-readable seller declarations without central enforcement. New requirements: attestors emit structured JSON, exchanges parse and index, parties adopt forwarding workflows. Lower barrier than ads.txt: builds on email infrastructure already deployed, no new hosting needed. Bootstrap follows the stone soup pattern: early exchanges publish graphs, early curators publish standards, and each participant shows up for their own fraud-reduction advantage.

The declaration

An advertiser publishes a signed declaration of their trust relationships:

• Payment processor: “Stripe has processed my payments for three years. Here is Stripe’s attestation.”
• Customers: “These customers endorse my work. Here are their signed endorsements.”
• Vendors: “I source from these suppliers. Here is mutual attestation of the relationship.”
• Licensing: “I hold this license in this jurisdiction. Here is the registry link.”
• Platform history: “My Shopify store has this rating. Here is the verifiable export.”

Attestations come in two forms: bilateral (mutual relationships) and unilateral (observations).

Bilateral attestations require both parties to confirm. Stripe and the merchant both forward emails. The exchange creates a mutual edge: merchant ←→ Stripe. Relationships: payment processing, vendor partnerships, customer endorsements.

Unilateral attestations come from platforms observing public data. Google forwards an attestation about a restaurant’s reviews. The restaurant doesn’t confirm; Google attests to their own platform data. The exchange creates a one-directional edge: restaurant ← Google. Observations: ratings, licenses, public records.

The confirmation is cryptographic: a DKIM-signed payload anyone can verify without asking either party. Bilateral edges attest to mutual agreement. Unilateral edges attest to the platform’s claim about their own data.

The declarations are coarse by design. “This merchant has processed payments for three years,” not the transaction log. “This restaurant has 4.5 stars from 247 reviews,” not the review contents. Enough to verify topology, not enough to reconstruct private activity.

The exchange layer

An exchange is a specialized mail server that receives, verifies, and indexes attestation emails.

How it works:

1. Stripe sends merchant a DKIM-signed email: “We attest to 3 years of payment processing for merchant@example.com”
2. Merchant forwards the email to attestations@exchange.com
3. Exchange receives email, verifies DKIM signature, indexes the relationship
4. Merchant sends Stripe: “I confirm this relationship”
5. Stripe forwards to attestations@exchange.com
6. Exchange indexes: merchant ←→ Stripe (bilateral confirmation complete)

The exchange is just SMTP (receives emails) + DKIM verification (proves authenticity) + a graph database (indexes relationships) + a query API (exposes to curators).

Attestation emails contain structured data:

From: attestations@stripe.com
To: merchant@example.com
DKIM-Signature: [cryptographic signature]
Subject: Payment Processing Attestation

{
  "attestation_type": "payment_processor",
  "merchant_id": "merchant@example.com",
  "duration_years": 3,
  "status": "good_standing",
  "timestamp": "2026-03-18T15:00:00Z"
}

Bilateral confirmation requires emails from both parties. The merchant forwards Stripe’s attestation; Stripe forwards the merchant’s confirmation. Only when both emails arrive does the exchange create a mutual edge in the graph. One-sided relationship claims don’t count.

Unilateral attestations work differently. Google forwards an attestation about a restaurant’s reviews directly to the exchange:

From: attestations@google.com
DKIM-Signature: [cryptographic signature]

{
  "attestation_type": "platform_rating",
  "business_id": "restaurant@example.com",
  "rating": 4.5,
  "review_count": 247,
  "platform": "Google Reviews",
  "timestamp": "2026-03-18"
}

The restaurant doesn’t confirm; Google attests to their own platform data. The exchange creates a one-directional edge: restaurant ← Google. The restaurant can’t block unfavorable reviews (that’s the point), but platforms stake their reputation on accuracy. If Google claims reviews that don’t exist on their platform, anyone can verify and call them out.

The exchange builds a public graph: nodes are businesses, edges are attested relationships (bilateral) or observations (unilateral), edge weights are reported signal strength (duration, volume, consistency). The exchange passes through what attestors claim. Curators interpret what it means.

One advertiser has three years of clean payment processing, 47 mutual customer attestations, two vendor relationships with reciprocal endorsements. Another has a week-old domain and a self-reported rating. The exchange exposes both. Curators decide what qualifies.

The graph is public. Anyone can query it. That’s how trust works. Private attestations are just claims. Public attestations are verifiable topology. Curators read the graph to publish allowlists. Publishers verify curator criteria. Competitors audit each other’s relationships. The transparency makes forgery expensive: faking edges requires compromising multiple parties who each have reputations to lose. Like business licenses, domain WHOIS, court records: trust infrastructure is public by design. Merchants control field-level disclosure (transaction volumes are opt-in), but the edges themselves (who attests to whom) are visible to everyone.

The curation layer

Curators interpret the graph. A curator publishes an allowlist: advertisers that meet their trust criteria. Different curators, different standards.

A conservative health curator might require: licensed practitioner + clean payment history + minimum 20 patient attestations. A general commerce curator might require: 6 months payment history + business registration + semantic consistency. A community curator might require: 3 mutual endorsements from other businesses in the same locality.

Curators stake their reputation on their lists. A curator whose allowlist lets through scammers loses subscribers. A curator whose allowlist is too restrictive loses relevance. The competition between curators produces trust standards, imperfectly, but better than a monopoly. The design inverts credit rating agencies: curators are paid by subscribers (publishers), not by the entities they evaluate. The incentive points toward accuracy, not accommodation.

The curation layer is a market.

The publisher layer

Publishers compose their trust policy from curators:

trust_policy:
  require_any:
    - curator: health-trust-network
    - curator: general-commerce-verified
    - curator: local-biz-portland
  deny:
    - denylist: known-scam-advertisers
    - denylist: low-quality-supplements

Union the allowlists. Subtract the denylists. What remains is the set of advertisers eligible to appear on this publisher’s pages.

A health vibelogger subscribes to a strict health curator and a local business curator. A general tech blogger subscribes to a general commerce curator. Each publisher takes responsibility for what their audience sees. The trust policy is as public as the content.

Email’s curation layer works the same way. Mail servers subscribe to blocklists (Spamhaus, Barracuda, SpamCop). Each server chooses which lists to trust. No single list controls the ecosystem. The competitive pressure between lists keeps them honest. Twenty years of decentralized policy composition suggests the pattern scales. Imperfectly, with concentration and false positives, but better than any centralized alternative.

The stack

Five layers. No single point of control. The protocol is email.

The topology is the credential

The trust graph exposes topology. A business with deep, reciprocal, long-standing relationships occupies a different position than one with thin, one-directional, recent claims. The shape speaks.

You can’t forge the graph without forging the relationships. But you can outspend it. A well-funded actor with real relationships can try to dominate legitimately. That’s what federation solves. No single curator’s allowlist is the index.

The plumber’s signals finally talk to each other.

Appendix

Revocation

Either party can unlink at any time by sending a revocation email:

From: attestations@stripe.com
To: merchant@example.com
DKIM-Signature: [cryptographic signature]
Subject: Attestation Revocation

{
  "action": "revoke",
  "original_attestation_id": "merchant123_stripe_2023",
  "reason": "account_closed",
  "timestamp": "2026-03-18T16:00:00Z"
}

The merchant forwards it to the exchange. The exchange removes the edge. Unilateral: you don’t need the other party’s permission.

If Stripe detects fraud, they revoke. The merchant’s payment processor edge disappears, curators see a thinner topology, the merchant drops from allowlists.

If a business relationship ends, either party can unlink. The graph reflects current state, not historical claims.

Extensible schemas

Attestors can optionally declare additional fields. Merchants choose which fields to publish:

{
  "attestation_type": "payment_processor",
  "merchant_id": "merchant@example.com",

  "standard_fields": {
    "duration_years": 3,
    "status": "good_standing",
    "timestamp": "2026-03-18T15:00:00Z"
  },

  "optional_fields": {
    "transaction_count": 14250,
    "average_monthly_volume": 48000,
    "dispute_rate": 0.002,
    "chargeback_rate": 0.001,
    "on_time_settlement": true
  }
}

The merchant opts in to publish specific fields:

{
  "publish": ["duration_years", "status", "dispute_rate"],
  "redact": ["transaction_count", "average_monthly_volume"]
}

The exchange receives the full attestation but only publishes opted-in fields. Curators see “3 years, good standing, 0.2% disputes” but not transaction volumes.

Each attestor defines their own fields. The exchange stores what’s declared and publishes what’s opted in. Curators query whatever fields matter for their criteria.

Every edge is timestamped. The exchange records when attestations arrive, when they’re confirmed, when they’re revoked. Curators can weight recent attestations more heavily than old ones, or require minimum relationship duration. The timestamps make relationship age verifiable without trusting self-reported claims.

Design concerns

Written with Claude Opus 4.6 via Claude Code. I directed the argument; Claude drafted prose.