This article is Part 4 of our "Building Recurring Payments in Public" series.

In this series, we've talked about our architecture as locked open. In this closing article, we'll explain what that means and why it's important for the future of creator support on ATProtocol.

The Tri-Party Model

Every support relationship on ATProtoFans involves three parties:

The Supporter owns a record in their ATProtocol repository declaring who they support.

The Creator owns a proof record in their repository confirming the support relationship.

The Broker (that's us) owns a proof record attesting that the transaction happened, under what terms, and the relationship is valid.

There are three parties, each with their own repository, creating one verifiable truth. Each party keeps their part, and any app can check all three.

What a Broker Does

The broker role has four responsibilities:

  • Facilitate the payment. We connect supporters and creators, process transactions through Stripe, and handle money movement.

  • Create the broker proof. When a payment succeeds, we write a record to our repository attesting to the transaction.

  • Validate on request. Other apps can ask us to verify whether a support relationship is valid. We check our records and respond.

  • Invalidate when needed. If support ends due to cancellation, payment failure, or account termination, we update the broker proof to reflect that the relationship has ended.

That's it. Everything else is just an implementation detail.

Broker Is a Role

The key point is that ATProtoFans is a broker. We're just one example of how the broker role can work. The role itself is open to anyone.

Our lexicon schemas are public and available to anyone. These define the record structures as com.atprotofans.supporter, com.atprotofans.supporterProof, and com.atprotofans.brokerProof.

Our attestation algorithm is fully documented. How we compute content hashes, link proofs, and validate signatures is all explained in our technical documentation.

The verification logic works without us. If you have access to the three repositories involved in a support relationship, you can verify the proofs yourself. You can recompute the hashes and confirm everything matches.

We designed it this way on purpose. The system should keep working even if we're no longer around.

The serviceRef Pattern

One piece of the architecture deserves special attention: how we reference records that live on our service rather than in ATProtocol repositories.

Terms records, which are the contracts that creators publish and that supporters agree to, are stored in our database. They are service data, specific to the broker relationship. Sharing them across ATProtocol isn't needed; they only matter to the people in the transaction and the broker helping with it.

But broker proofs need to reference those terms. That's where com.atprotofans.serviceRef comes in.

A serviceRef contains three fields:

  • service: The DID of the service hosting the record (did:plc:7ewx3bksukdk6a4vycoykhhw#SupportBroker)

  • uri: The AT-URI identifying the record

  • cid: The content hash for immutability verification

When a broker proof refers to terms, it uses a serviceRef. Any app can use that reference to call our service, get the terms, and check that the CID matches. The terms are stored on our service, but anyone can verify them.

This pattern can be used again. Other brokers could keep their own terms records and refer to them in the same way. The serviceRef structure works for any data hosted by a service that needs to be referenced from ATProtocol records.

Alternative Brokers

What would other brokers look like?

A podcast network could run its own broker, attesting to supporter relationships for shows in its network. They'd maintain their own broker proofs, set their own fee structures, and maybe offer network-wide supporter benefits.

A regional broker could serve creators in specific markets, handling local payment methods and currencies that we might not support.

A non-profit broker could operate with lower fees or different incentives, serving communities that want alternatives to commercial options.

An alternate currency broker could use an alternative form of currency like cashu or other non-cryptocurrency tokens.

A crypto broker could handle cryptocurrency payments, creating the same attestation chain but with different payment rails.

Each broker would keep their own proof records. Supporter and creator records would still be in user repositories. The way verification works would stay the same. Apps could decide which brokers they trust.

What We're Building

We're building payment primitives for the ATProtocol ecosystem. Our contribution includes proof-of-payment and record-attestation infrastructure.

The supporter record schema. The proof record schemas. The terms record pattern. The serviceRef pattern. The attestation chain logic. The validation endpoints.

These are the building blocks we use to run ATProtoFans. Others can use them, or adapt them, to create their own versions.

Recurring payments use the same approach. The terms records set the agreement, and the attestation chain proves it's valid. When support ends, the chain breaks in a clear way. Any broker building recurring support would face the same design questions we did, and they could learn from or improve on our solutions.

The Multi-Broker Future

We expect there will be many brokers in the future, each serving different communities, markets, and needs. Some might use our schemas as they are, others might adapt them, and some could create new approaches that still work together at the verification level.

To make that future possible, the first broker needs to build for openness from the beginning. If we had made ATProtoFans a closed system, it would have been hard, or even impossible, to make it open later. That's why we built it to be open from the start.

We're the first broker. We hope we're one of many.

If you're building on ATProtocol and want to explore broker integration, or if you're thinking about becoming a broker yourself, get in touch. We're happy to share what we've learned and talk about where the ecosystem could go.

The series is finished, but we're still building. Follow along as we launch recurring payments and see how the design works in real use. Follow us online at @atprotofans.com and look for our community calls on https://smokesignal.events/@atprotofans.com