1. First Impression
The spec is great at separation of concerns. I think separation of the movement of money from the proof of access is critical here - the actual movement of money is a separate layer (and can be chosen)
It is an elegant, flexible primitive perfectly adapted to a network like atproto.
2. Utility
I think what is most useful here is the fact that the developer doesn’t need to know or care how a user paid, they can just query the network.attested.payment.lookup endpoint or fetch the records from the PDS to compute hashes locally. We can minimize added atproto complexity, which is always a plus in my book.
3. First Principles & What Stands Out
I think these three principles are really elegant:
-
The Three-Party Trust Model: The spec solves peer-to-peer spoofing (e.g., a Payer forging a receipt on their own PDS)
-
User-Sovereign Receipts: By writing the network.attested.payment.oneTime record to the user’s PDS, the user carries their purchase history across the network natively.
-
Elegant Invalidation (Solving Chargebacks): The mechanism for handling refunds or credit card chargebacks is clever. Simply deleting the broker’s own proof of record, breaking the verification chain.
4. Missing Use Cases (The Gaps)
While the spec is highly robust for standard one-off commerce and recurring subscriptions, it leaves some of the messier realities of digital goods and network economics unaddressed (I will note these are definitely things that can be added in future and are big asks - I’m aware I’m getting ahead of myself here but would love some thoughts):
-
Transferability and Gifting (Secondary Markets): The spec assumes the Payer and the Recipient of the entitlement are the same did:plc. If User A wants to buy a subscription and gift it to User B, or resell a limited-edition badge, there isn’t a clear protocol for transferring or re-attesting an entitlement to a new DID.
-
Metered or Consumable Entitlements (B2B Infrastructure): The spec handles binary states well (e.g., “User has access to Premium Feed”). But what about consumable balances, particularly for backend app-to-app infrastructure? For example, an AppView paying an independent Labeler for “100 hours of video moderated,” or a client paying stream.place for “50 hours of live-stream bandwidth.” Tracking the depletion of these metered services is difficult. Generating a new attestation for every hour consumed or byte streamed would quickly bloat the PDS. There doesn’t seem to be a stateful mechanism for “burning” or decrementing an entitlement over time as infrastructure services are rendered.
Can streaming payments replace static attestations? If a decentralized payment layer was to exist on top of atproto - one that natively supports high-frequency, zero-fee micro-transactions (state channels), do we even need static oneTime attestations for things like metered billing, or does the user just stream value directly to the AppView in real-time as they consume the bits?
This ties into my next point:
Ecosystem Value Capture & The Infrastructure Mismatch The spec solves the Payer-Recipient-Broker trust triangle, but it doesn’t take into account the rest of the AT Protocol stack - other parts that still add value and more importantly, incur costs. It solves for the authorization of access, but not cost of delivery - at least not right now. Again - this is probably getting ahead of ourselves but just something I’ve been thinking about a lot.
Serving a paywalled atproto post requires an entire federated supply chain: the PDS host, AppView, Labeler and Client all adding value (albeit different amounts with different cost-bases).
If a user subscribes to a creator’s paywalled standard.site blog through leaflet (acting as the Broker), leaflet captures the conversion and the broker fee. However, if that user subsequently consumes all of that creator’s content exclusively through the offprint Client - which relies on a third-party AppView, a community Labeler, and the creator’s PDS - those infrastructure providers bear 100% of the ongoing bandwidth, compute, and retention costs, but earn zero revenue from the transaction.
The attestation proves the user can view the post, but it provides no mechanism to compensate for the infrastructure actually serving the post. Without a primitive for value-share, I fear the Broker role will inevitably centralize. The entities that capture the initial transaction will hoard the ecosystem’s value, starving out the independent clients, AppViews, and PDS hosts that the protocol relies on for healthy competition and sustainability.
This leaves us with several critical, unresolved questions for the ecosystem:
-
How do we attach a “split” or “value-share” manifest natively to an attested.network receipt so that value flows to where the compute happens?
-
If an AppView or PDS verifies an entitlement before serving a payload, how can they programmatically claim a micro-fraction of the underlying transaction?
-
Should the network.attested.payment lexicon be expanded to include an infrastructureShares array to define how value is routed to the actors doing the work?
Ultimately I think this is what will lead to the Atmosphere’s long-term success. Enforcing cooperation and ensuring sustainability. I think attested.network is a great gateway to the first round of monetization on atproto!