Introducing Atmosphere Money

The Atmosphere has begun to separate people’s identities, data and social relationships from the applications they use. People can switch apps without starting over, publish once for use across services, and build new experiences on shared records. Commerce is still emerging in the Atmosphere. Without a shared commercial layer, we risk recreating the same silos: creators rebuilding products, memberships and payout arrangements in every app; developers creating value without a practical way to share in it; and supporters finding their purchases and relationships locked inside individual apps’ walls.

If interoperability stops where money starts, much of its value gets left at the toll booth. To compete with established platforms, the Atmosphere needs that openness to extend to how people pay, how creators earn and how apps share value.

In Let’s Talk Money, I asked what an economy designed for the Atmosphere might look like. How can developers monetize earlier? How can creators earn wherever they are found? How should value be shared when discovery, publishing, checkout, community and fulfillment happen across different services without rebuilding another platform that owns the whole relationship?

Atmosphere Money (ATM) is our answer. ATM is social payments for the Atmosphere: shared infrastructure connecting identity, commerce and the services that create value around them. ATM's mission is to help build an economy in which creators, apps and services can all be rewarded for their contributions without any one application owning the entire relationship. Rather than concentrating value in one or two monolithic entities built on lock-in and closed data, the Atmosphere can support a thriving creator economy across a sea of sustainable apps and services. ATM helps make this possible through interoperable commerce; creating economic network effects that benefit the ecosystem as a whole.

This post introduces ATM's model, with technical designs and schemas to follow.

A financial position that belongs to you#

Most internet commerce is vertically integrated. One platform owns the audience, catalog, checkout, subscriptions, customer history, payment relationships and access controls. That can be convenient, but it also makes a creator’s business inseparable from the platform running it. If the creator leaves, much of the financial position they built stays behind.

ATM starts from a different assumption: a creator’s financial position in the Atmosphere should belong to the creator. That includes the products they sell, the prices they offer, the memberships they create, the commercial relationships they approve and the portable history showing what supporters have purchased from them.

A creator should be able to establish a payment relationship once and then approve multiple apps to help them earn. They might sell a digital product through a publishing app, tickets through an events app, merchandise through a social storefront and memberships through several different experiences. They can change those experiences without abandoning the commercial foundation underneath them. One Atmosphere account, and one place to manage the apps & services they monetize with.

ATM Phase 1 establishes a shared commerce layer around products, prices, memberships and storefronts. Its public records carry the minimum facts that compatible services need to understand what is being offered and on what terms without dictating presentation. Different apps can render the same products or shop in different ways and add their own merchandising, recommendations and app-specific features. Private buyer data, payment processing details, payout reconciliation and other sensitive information remain in the systems responsible for them.

Apps should be able to build sustainable businesses without owning a creator or trapping their audience. An app can provide discovery, checkout, publishing, community, fulfillment or another valuable service and be compensated according to terms the creator has accepted. Supporters can use saved payment details across participating experiences, complete checkout in a few steps and keep useful receipts and membership relationships connected to their Atmosphere identity.

ATM is not intended to become the one app everyone must use. A supporter may interact with it only briefly through ATM Checkout before returning to the experience they were already using. The app remains the experience; ATM provides the shared commercial infrastructure underneath it.

At a high level, an ATM payment connects three roles: a payer, a recipient and a broker. The recipient may be a creator, an event organizer or an app selling its own product. ATM is the broker for payments made through ATM Checkout: it coordinates the transaction, verifies settlement on the selected payment rail and publishes an attestation under its own identity. For an identified public payment, the payer can authorize a receipt in their account and the recipient can publish an acknowledgment in theirs. Compatible apps that trust the broker can then verify the historical payment evidence without relying on ATM’s private database as the only source of truth. Current access and later payment changes are separate questions.

This separation is also how ATM limits broker lock-in. Products, prices, memberships, agreements, receipts and payment proofs are designed to exist above any one broker or payment rail. Another broker could adopt the same economic architecture, support the same records and attest payments through its own systems. Creators and apps could take their public catalog, signed agreement & portable payment history with them rather than rebuilding that position from scratch. A compatible broker would still decide which records it supports under its own terms and require its own onboarding, KYC, payment credentials and migration of necessary private data. Portable records do not automatically transfer an existing billing relationship, but the creator’s broader economic position should not be trapped inside ATM.

One membership across several apps#

Consider a writer creating a paid membership. A supporter might discover the writer through a social app, read their public work through a publishing app, purchase through ATM Checkout and join conversations through a community app. Today, one platform would normally own that entire journey, including the payment relationship, subscriber list and content experience.

In the Atmosphere, those responsibilities can be separated. The creator defines the membership and decides which apps may participate. ATM manages the shared payment and membership status underneath them. The supporter simply sees a membership they want, pays for it and receives access. The creator is no longer forced to choose one permanent interface for the business.

A storefront could sell a membership without needing access to its members-only articles. A reading app could display those articles to entitled supporters regardless of where they paid. The same app can do both, but permission to sell should not automatically grant access to private content.

Products and prices describe the offer and its commercial terms. A subscription manages recurring billing, while a membership describes what an active relationship unlocks, whether that is articles, videos, events, community access or downloads. Keeping these concepts separate allows the membership to become larger than the app that happens to collect the payment.

Brendan (@schlage.town) described a useful way of thinking about this in “On Atmospheric Stacks…”. The Atmosphere does not have to replace a large incumbent with one equally large application. Different services can replace different parts of the stack while becoming more useful together.

The best creator monetization tools in the Atmosphere will emerge in the same way. A creator might use one app for publishing, one for video, one for member discussions and another for events. Each can specialize without becoming the creator’s permanent home. The creator assembles the membership offering, supporters consume it through compatible experiences, and ATM supplies the shared economic relationship that makes the stack coherent.

Atmosphere revenue sharing#

When several services contribute to one economic journey, we need a reliable way to describe who should earn what. ATM uses Atmosphere Revenue Agreements, or ARAs, to record the revenue terms participants have accepted.

Each ARA identifies the relevant relationship between creators, apps and services. When an ARA applies to a payment, ATM freezes the resulting allocation and preserves its history through refunds and corrections. The agreement describes the commercial relationship above the payment rail, so compatible brokers can implement the same allocation model independently.

An app publishes the exact rate it requests for a role, and the creator accepts those terms. A different negotiated rate requires a separate offer. A creator can accept several independent agreements for the same offering, provided their combined allocation stays within the creator’s approved ceiling. One app might provide fulfillment, another a video experience and another an ongoing community service.

A service can also agree to share part of its own allocation with another service. These child agreements draw from the parent’s accepted share without increasing the creator’s agreed total. We will explain the mechanics in a separate post.

Consent is central. An app cannot simply announce that it helped and take a percentage of somebody else’s sale. The creator knows which relationships they are enabling, what each service provides and what those relationships can cost before a payment happens.

Some forms of attribution are easier to establish than others. ATM can verify which approved app originated a checkout. Discovery-based attribution is harder - say when someone discovers an article on one app, yet purchases and reads it in another. The ARA model provides agreement and allocation primitives, but trustworthy discovery attribution will require community standards for signed handoffs, conflicts and fraud prevention. ATM will begin with deterministic, auditable attribution and expand carefully.

Shared infrastructure for independent sellers#

Moving money safely requires operational infrastructure that would be unreasonable for every independent developer to recreate. ATM brings together shared checkout, processor events, payment reconciliation, payment proofs, accepted revenue shares and the events apps need to fulfill purchases.

Apps can integrate using familiar atproto patterns. They retain control over their experience and fulfillment logic while ATM handles the shared financial machinery. This allows a small developer to add sophisticated commerce without first becoming a payment platform. Creators KYC once, rather than with every app that wants to monetize. Atmosphere apps can tap into creators who are already verified and revenue share straight away, reducing the time needed to become sustainable.

That shared layer also needs acceptable-use policies, review, reporting and enforcement. ATM is building those capabilities alongside the payment infrastructure so participating apps can rely on common systems while retaining responsibility for their own services.

In ATM's launch model, the creator, organizer or app selling the product remains the seller and merchant of record. ATM provides infrastructure around that sale. Shared checkout does not remove the seller’s responsibilities for their product, fulfillment and customers, or the responsibilities applying to ATM and participating apps.

ATM is targeting initial app revenue-share settlement in USD, CAD, EUR and GBP on qualified routes. Creators may be able to settle in a broader range of currencies wherever the underlying processor and account configuration support them. Country support, onboarding, KYC, payout corridors and provider approval still apply, and conversion or cross-border costs will be disclosed where they occur.

Receipts and Spaces#

Not every piece of financial information belongs on a public protocol. Card details, bank accounts, legal identity documents, delivery addresses, tax information and raw processor records must remain private. That does not mean every useful economic fact should disappear into a private platform database.

ATM's model gives each settled checkout a public broker-authored proof under ATM’s identity. For a public-receipt checkout, ATM obtains the authenticated payer’s authorization to publish a receipt in their repository. Knowing someone’s account identifier alone does not grant that authority.

A guest payment can have broker-authored evidence without inventing a payer account or a payer-authored receipt. The public proof commits to the corresponding payment statement; it does not reveal the details of a private statement by itself. Recurring payments and later refunds have their own publication rules, which we will cover in the technical documentation.

A receipt is historical payment evidence. It is not automatically a current membership credential or a statement of what the seller ultimately received after fees. Those distinctions let other applications use the evidence without giving it meanings it cannot support.

ATM's approach can be described as pragmatic openness: portable where useful, private where necessary, and explicit about the difference. Public receipts can still reveal who paid whom, how much and for what, so their publication requires clear disclosure and authorization.

Atproto Spaces opens a path to portable membership content and private economic records across the Atmosphere. Alongside ATM’s ledger and public records, Spaces can give that content and those records a home independent of any one app, with explicit control over which people and compatible services can access them.

A creator-owned Space is intended to become the access boundary for membership content. ATM checks current paid membership status while the creator controls the Space and which compatible applications may access it. Supporters could pay through one approved sales app and read through another permitted client.

ATM is actively developing the design for private payment receipts as the Spaces specification matures. A payer-owned receipt space would make payment details available to the payer, recipient and broker without exposing them to the entire network. Access by other applications would require explicit authorization.

The atproto Spaces implementation is currently in alpha. During this time, ATM will test these schemas in spaces through controlled experiments with non-sensitive test payments, checking access control, payment verification and interoperability as the specification and implementations evolve. Private production receipts will follow once the relevant implementation and security checks are complete. I'm particularly excited by ATM's work with spaces and memberships. Spaces add an app-neutral, permissioned home for the content Atmospheric memberships unlock.

Building a sustainable shared layer#

ATM needs a business model of its own. Shared infrastructure is useful only if it can be operated, secured and improved over the long term, and we want that business model to remain aligned with the wider Atmosphere.

ATM's launch pricing model has no service fee for basic direct selling with no independent app revenue share. That includes a creator selling directly, an app selling its own product without a revenue-sharing split and ordinary creator-managed fulfillment for physical products sold through ATM Checkout. The normal costs of the selected processor and route still apply, but ATM does not add a fee simply because the transaction used its checkout, receipts, payment proofs or commerce infrastructure.

When a creator approves an independent app to earn from a sale, ATM collects the platform fee associated with the accepted agreements. Under this model, ATM owes each participating app its agreed share. It does not deduct a percentage tariff from that accepted allocation or charge more because one service shares its allocation with another.

An accepted revenue share describes an allocation before separately agreed payment and delivery costs. Provider costs can therefore reduce the amount actually received. Those costs are distinct from ATM’s own service fees, and allocation records should not be mistaken for proof of the final payout.

ATM may include a separate, clearly disclosed creator-funded service fee when it administers an eligible independent app revenue-sharing relationship. This fee would exist as any other ARA would - a transparent agreement just like one with any other app. This fee is calculated once for the covered purchase and would not be deducted from an app’s accepted revenue share. Direct sales without an app revenue share would not trigger it. More advanced managed services may have deliberately selected pricing of their own.

Scale creates another route to sustainability. Individual apps have little negotiating power with global payment providers, but collectively the Atmosphere can represent meaningful payment volume. As that volume grows, ATM may qualify for payment-partner economics that allow us to participate in a provider’s revenue without reducing what creators or apps receive.

ATM's intention is to use that scale to reduce participant costs over time and reinvest network-derived economics into infrastructure, tools and adoption throughout the ecosystem. ATM should become a stronger business by helping the Atmosphere grow, not by quietly taxing every transaction that crosses it.

The rails can change#

ATM will launch with Stripe as its first payment rail but ATM’s model of commerce is not defined as a collection of Stripe objects. Products, prices, storefronts, memberships, agreements, allocations and payment evidence exist above the processor. Processor-specific identifiers and sensitive financial details remain in the systems responsible for executing and reconciling the transaction.

Processor agnosticism does not mean another provider can be added by changing one configuration value. Every rail has different account structures, payment methods, refund behavior, recurring-payment capabilities, dunning, currencies, compliance requirements and settlement constraints. Each must be integrated and qualified deliberately, but the economic model does not have to be reinvented every time the rail changes. Other brokers can also build compatible systems around the same public economic primitives.

The second phase of ATM will introduce atcash, a wallet for AT Protocol, built for storing and spending digital dollars and euros across the Atmosphere. Its open payment rails would let ATM and other compatible brokers attest to the same underlying transactions, producing payment evidence in a shared format (Multi-broker attestation), as well as removing the need for a broker entirely (brokerless attestation) in peer to peer payment scenarios.

That could mean more broker choice, less dependence on ATM and lower fees, especially for small payments (e.g a single standard.site article). Phase 1 makes commerce more portable; Phase 2 begins opening the rails beneath it.

Like any other payment rail, atcash is optional: apps choose which payment methods to offer, and users choose how to pay from those available.

What comes next#

This is the broad view of Atmosphere Money: an economic layer intended to help creators build portable businesses, help developers monetize independent apps and reward more of the services that create value throughout the Atmosphere.

The next post will explain receipts, broker proofs, trust and what happens when a payment is refunded or disputed.

A separate follow-up will explain the shared commerce catalog, including products, prices and storefronts. Later posts will explore portable memberships and Spaces, followed by ARAs, revenue allocation, broker & seller terms and practical integration patterns. There is also much more to share about atcash, shared payment rails and smaller global payments that are uneconomical on traditional rails. Early-access documentation is available to pilot apps, and the public documentation will expand as the beta develops.

ATM is shared infrastructure for economic relationships that should not have to belong to one application. The Atmosphere has already shown that social identity can be bigger than an app. We think its economy can be too.

Building a paid experience in the Atmosphere? Join the waitlist using the button below, and tell us what you want to build.#