Proof of Payment
for ATProtocol

Documentation

Guides for every role in the attested payments ecosystem.

Overview

Payment proofs replace centralized payment databases with cryptographic attestation records distributed across ATProtocol repositories. Any application can independently verify a payment—no single platform controls the relationship.

Three-party attestation

Every payment creates records across three independent repositories. The supporter declares intent, the creator confirms receipt, and a broker—which facilitates and witnesses the exchange—writes its own proof. Each record is content-addressed and bound to its repository, preventing replay attacks.

graph LR
  subgraph SR["Supporter's Repo"]
    PAY["Payment Record
oneTime | recurring | scheduled"]
    SIG["signatures: [strongRef, ...]"]
  end

  subgraph CR["Creator's Repo"]
    CP["payment.proof
Attests via CID"]
  end

  subgraph BR["Broker's Repo"]
    BP["payment.proof
Attests via CID"]
  end

  SIG -- "strongRef" --> CP
  SIG -- "strongRef" --> BP
      

Payment Intent

When a recipient wants to accept a payment, a structured discovery and initiation flow connects payer, recipient, and payment servicer:

1. The recipient signals which payment servicers they use by publishing an ordered list of DIDs that have a #AttestedNetwork service endpoint in their DID document
2. The payer’s client resolves these DIDs and presents the available servicers. The payer selects which one to use
3. The payer’s client makes an authenticated request (using inter-service authentication) to network.attested.payment.initiate on the selected servicer, passing the product identifier. The response includes a token and a URL
4. The payer is directed through a browser to the URL to complete the payment process (entering payment details, confirming terms, etc.)
5. The payer’s client polls network.attested.payment.status with the token. The response is either a strongRef pointing to the completed payment record, or a failed status

sequenceDiagram
    participant P as Payer's Client
    participant R as Recipient
    participant S as Payment Servicer
    participant B as Browser

    P->>R: Resolve DID document
    R-->>P: Service endpoints with #AttestedNetwork DIDs
    P->>P: Select servicer from list

    P->>S: network.attested.payment.initiate (authenticated)
    Note right of P: Sends product identifier
    S-->>P: { token, url }

    P->>B: Redirect payer to URL
    B->>S: Complete payment flow
    S-->>B: Payment confirmed

    P->>S: network.attested.payment.status (token)
    S-->>P: { strongRef } or { failed }
      

Verification

Any application can verify a payment by checking the cryptographic chain:

1. Strip the signatures array from the payment record
2. Prepare attestation metadata—add the repository DID, strip cid and signature fields
3. Insert metadata as the $sig field, serialize to DAG-CBOR
4. Hash with SHA-256 and wrap as CIDv1 (codec 0x71)
5. Fetch proof records via strongRef URIs and confirm CIDs match

Trust Models

Applications can implement different validation strategies:

• Strict Require proofs from both the creator and a specific trusted broker. Highest assurance.
• Creator-Trusted Accept any payment the creator has attested. Simpler, trusts creators to vouch for supporters.
• Federated Accept attestations from a set of trusted brokers. Enables regional verification networks.

Lexicon

Four record types and three XRPC methods define the payment specification. Payment records live in the supporter’s repository and carry a signatures array referencing proof records from creators and brokers.

Examples

Complete record examples showing how attested payments work in practice, using badge.blue remote attestations with com.atproto.repo.strongRef entries.

One-time tip with dual attestation

A supporter sends a $25 tip to a creator. Both the creator and broker independently attest the payment by writing proof records to their own repositories.

{
  "$type": "network.attested.payment.oneTime",
  "subject": "did:plc:v5jkrb2oncmnhc7rtqhrdzwi",
  "amount": 2500,
  "currency": "USD",
  "txnid": "01J5K9P3XQHV7WNBCM2G8RFAT",
  "memo": "Great stream, keep it up!",
  "createdAt": "2025-07-14T19:22:00.000Z",
  "signatures": [
    {
      "$type": "com.atproto.repo.strongRef",
      "uri": "at://did:plc:v5jkrb2oncmnhc7rtqhrdzwi/network.attested.payment.proof/3la7qxz2vbc2s",
      "cid": "bafyreigyh7s6lqf5n3xke4jt6r2x3mqkzf4wpgicbqhqg5k3vdjn7aomfe"
    },
    {
      "$type": "com.atproto.repo.strongRef",
      "uri": "at://did:plc:broker-payments-xyz/network.attested.payment.proof/3la7qy2kbrc2t",
      "cid": "bafyreih7wwfa3tcoqd2ne5gqkvrulzpfnwjmcc5fsgqjdx4huswnhzaehqu"
    }
  ]
}

{
  "$type": "network.attested.payment.proof",
  "cid": "bafyreifdw3gy6ef4mcep5forx72cilu6wbsvuajkgsxnluqemkpa5xvzrwu"
}

Monthly recurring subscription

A $10/month recurring support commitment. The record is immutable—to change the amount, the supporter cancels and creates a new subscription.

{
  "$type": "network.attested.payment.recurring",
  "subject": "did:plc:v5jkrb2oncmnhc7rtqhrdzwi",
  "amount": 1000,
  "currency": "USD",
  "unit": "monthly",
  "frequency": 1,
  "txnid": "01J5KBR4WMHV8XNBDM3G9SFBT",
  "createdAt": "2025-08-01T00:00:00.000Z",
  "entitlements": [
    {
      "$type": "com.atproto.repo.strongRef",
      "uri": "at://did:plc:v5jkrb2oncmnhc7rtqhrdzwi/com.example.product/3miemuswqbyiw",
      "cid": "bafyreik3xxgb5tcoqd3ne6gqkvrulzpfnwjmcc5fsgqjdx4huswnhzbekaa"
    }
  ],
  "signatures": [
    {
      "$type": "com.atproto.repo.strongRef",
      "uri": "at://did:plc:v5jkrb2oncmnhc7rtqhrdzwi/network.attested.payment.proof/3lb2rxz3vdc3t",
      "cid": "bafyreigyh7s6lqf5n3xke4jt6r2x3mqkzf4wpgicbqhqg5k3vdjn7aomfe"
    },
    {
      "$type": "com.atproto.repo.strongRef",
      "uri": "at://did:plc:broker-payments-xyz/network.attested.payment.proof/3lb2ry4ldsc3u",
      "cid": "bafyreih7wwfa3tcoqd2ne5gqkvrulzpfnwjmcc5fsgqjdx4huswnhzaehqu"
    }
  ]
}

Scheduled payment series

Six monthly payments of $50 each, terminating automatically after the final installment. Useful for project-based sponsorships or fixed commitments.

{
  "$type": "network.attested.payment.scheduled",
  "subject": "did:plc:v5jkrb2oncmnhc7rtqhrdzwi",
  "amount": 5000,
  "currency": "USD",
  "unit": "monthly",
  "count": 6,
  "txnid": "01J5KCS5XRHW9YOCEN4H0TGCU",
  "createdAt": "2025-09-01T00:00:00.000Z",
  "signatures": [
    {
      "$type": "com.atproto.repo.strongRef",
      "uri": "at://did:plc:broker-payments-xyz/network.attested.payment.proof/3lc3syz4wec4u",
      "cid": "bafyreif4xxgb5tcoqd3ne6gqkvrulzpfnwjmcc5fsgqjdx4huswnhzbekru"
    }
  ]
}

Broker proof record

The broker’s independent attestation, stored in their own repository. This is the record referenced by the second strongRef in the examples above.

{
  "$type": "network.attested.payment.proof",
  "cid": "bafyreih7wwfa3tcoqd2ne5gqkvrulzpfnwjmcc5fsgqjdx4huswnhzaehqu"
}

Verification flow

How an application verifies a one-time payment with dual attestation:

sequenceDiagram
    participant App as Verifying App
    participant S as Supporter's Repo
    participant C as Creator's Repo
    participant B as Broker's Repo

    App->>S: Fetch payment record
    S-->>App: payment.oneTime + signatures[]

    par Verify creator attestation
        App->>C: Fetch proof via strongRef URI
        C-->>App: payment.proof (cid)
        App->>App: Recompute CID from payment + supporter DID
        App->>App: Confirm CID matches proof.cid
    and Verify broker attestation
        App->>B: Fetch proof via strongRef URI
        B-->>App: payment.proof (cid)
        App->>App: Recompute CID from payment + supporter DID
        App->>App: Confirm CID matches proof.cid
    end

    App->>App: Payment verified ✓