The protocol has no chain, no asset, and no settler of its own.
Those roles are named on the request. The Atum protocol is none of them.

Neutrality is by design. Atum is structurally unable to favor a rail, prop up a token, protect its own settlement, or hold the funds.

Before a single line of code was ever written at Atum, the decided direction was towards credible neutrality. At first it was just about not giving preferential treatment to any particular stablecoin or blockchain. As we started to build, that preference had to live somewhere it could not be walked back: in the shape of the protocol.

The protocol is shared declarations and per-rail contracts. It does not include a blockchain, an issued currency, or a settlement operation, and it does not depend on the services that consume it. A payment request names independent source and destination assets, a settlement vault, a fulfillment verifier, and who may quote. x402 and MPP are different ways in; underneath, the settlement is the same. That is neutrality as architecture — not a policy applied after the fact, but nowhere in the system to put a privileged path.

Liquidity fragmentation

Stablecoin liquidity is becoming increasingly fragmented: more issuers, more chains, a combinatorial explosion of possible routes. Each new rail that rises to prominence reduces the chances of a buyer and a seller being able to agree on how to settle a payment. A seller should receive the asset they want, and a buyer should pay with what they already have, without a coincidence of wants between them, and without either of them needing to think about how the conversion might happen.

Consider traveling in a foreign country, using a foreign currency, and paying with a debit or credit card that you brought from home. You walk into a store and swipe your card, and it just works. The merchant wants local currency; all you have is your home currency. The merchant doesn’t know or care what yours even is, and you don’t have to think about exchange rates. Paying with stablecoins should be just as easy.

Chain Agnostic

The Atum protocol is built to be chain agnostic. It leans heavily on Chain Agnostic Improvement Proposals, or CAIPs, standards for blockchain interoperability developed by the Chain Agnostic Standards Alliance.

Take CAIP-19, for example. Four parts, one string: which family of rails, the chain, the token type, and the contract address on that chain. For USDC on Ethereum, this becomes:

eip155 : 1 / erc20 : 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48
  │      │     │              │
 family  chain  token type    the contract on that chain

If you are using a different family, chain, token type, or contract address, CAIP-19 provides a unified way to express them all.

When a merchant presents instructions to pay on Atum, they specify the asset they want to receive, in the form of its CAIP-19 identifier. When you fill out those instructions for submission to the Atum network, you indicate the asset you want to pay with, as a completely independent CAIP-19 identifier.

You don’t need to even look at the merchant’s preferred CAIP-19 identifier, and they’ll probably never even see yours. Your payment request will be broadcast to the settlement operators in the Atum network, who subscribe to the assets and chains they support and quote to fulfill the request. Operators compete to settle your payment, and the network converges on a route, without you even realizing it.

Route abstraction

Settling a payment with different source and destination assets means someone has to pick a route. The Atum protocol does not. That choice sits outside the network.

The simplest case: the sender pays USDC on Base, the receiver wants USDC on Ethereum. You might think “just use CCTP.” Even that is already two products — a fast transfer and a slow one, at different prices — and there are completely different bridges besides. Same asset, two chains, and the route is already not unique.

A more complex case: USDT on Solana, to be received as USDC on Base. Now the route has an order. Swap on Solana, then bridge to Base via CCTP? Bridge to Base via LayerZero, then swap once it lands? Or are the most liquid AMMs on Ethereum, so you bridge there, swap, and then bridge the USDC to Base?

The number of possible routes for an asset/rail conversion in crypto is virtually endless. But the parties to the payment, the sender and the receiver, simply don’t care about any of these details. And neither does the Atum network.

Settlement providers on the Atum network are independent operators with their own private rail integrations and inventory management strategies. For any given conversion, one operator may bridge then swap, another may swap then bridge, and yet another may do neither. Some providers may deploy funds already in position for other purposes, some may simply be acting as a proxy for other liquidity venues, and some may actually be borrowing the necessary funds just in time for the settlement.

The Atum network architecture places all of these considerations outside of the network. The result is a marketplace where these different strategies compete against each other. The routes that are faster and cheaper will be utilized more often, and the routes that are slower and more expensive will disincentivize operators from continuing to offer them.

When a payment request is submitted to the Atum network, settlement providers quote to fulfill it. How exactly they go about fulfilling it is not of interest to any of the parties, nor to the network.

Identity and credentials

While liquidity fragmentation was the primary impetus for building Atum, the network’s remit is much, much larger.

Unlike a typical swaps provider, DEX aggregator, bridge or interop messaging framework, the Atum network is built to support the regulated payments industry. For this reason, it treats identity and credentials as first-class citizens, and implements them in a standards-compliant, neutral way.

Identity fragmentation

Just as liquidity fragmentation across venues is a hindrance to free flowing commerce, so too is the fragmentation of identity and credentials across different providers.

Over 20 years ago, Microsoft’s Kim Cameron wrote of The Laws of Identity. He wrote of the failure of Microsoft Passport due to its lack of relevance outside of the Microsoft ecosystem – in essence, its status as a walled garden. And as the solution to this problem, he called for an “identity metasystem” that can channel and enable the inter-working of multiple technologies and multiple providers, to allow an identity ecology to emerge, evolve and self-organize.

While many individual walled identity gardens have been quite successful as businesses, that success has been at the expense of their customers’ ability to transact with parties outside of the garden: the gardens’ mutual exclusion precludes such an interoperable metasystem.

Cameron called for a “simple encapsulating protocol” – in his words, “a way of agreeing on and transporting things.” Atum reads that as three distinct layers: a data model, a negotiation layer, and a transport. Atum’s position in the ecosystem is as a negotiation layer and a transport, and we’ve built on the W3C DID/VC tech stack as the data model.

Two decades after the call for the metasystem, an emerging ecosystem is finally taking advantage of that data model: in 2025 support for the Digital Credentials API shipped in Chrome 141 and Safari 26; on May 15, 2025 the Verifiable Credentials 2.0 spec became a W3C Recommendation, a finished standard rather than just a working draft; and under eIDAS 2.0 every EU member state must offer a wallet by end of 2026, and in 2027 large private platforms will be obligated to accept those wallets. With this consumer level adoption, the data model is solidifying, the ecosystem is evolving and self-organizing, and Atum is building on top of it.

Issuer agnostic

An Atum payment request can carry not just wallet addresses but also identities and credentials, as W3C Decentralized Identifiers (DIDs) and W3C Verifiable Credentials (VCs). Atum doesn’t require them. You or your firm may issue your own DID, and even your own credentials. A credential may be issued by a third party to attest to KYC or KYB status, or may simply be a stamp of recognition. Atum checks that a credential is well-formed, that its signature verifies, and that its issuer is one the network has admitted. It does not replace your onboarding.

The matter of what credentials are sufficient and necessary to transact is a private matter between the parties. Some counterparties will only transact when a certain credential from a certain issuer is present. Some may choose to transact even when no identity or credential data is present. This is a private matter, and the Atum network is neutral on these decisions.

Trust substitution

Atum was designed from top to bottom to give you explicit control over who you trust.

If you don’t trust a particular stablecoin issuer or blockchain network, choose a different rail. If you don’t trust a particular credential issuer, only accept the ones you do trust.

The Atum payment gateway solicits settlement operators to fulfill your payment request. By default, the gateway will automatically select a quote according to your criteria. But instead of trusting the gateway to do that, you are free to receive all of the quotes and choose one yourself, selecting on price, reputation, trust in the settler’s credentials, existing business relationships, or whatever private, arbitrary criteria you choose to apply.

The Atum protocol includes a “fulfillment verifier” role, which attests to the delivery of funds on the destination rail, in order to pay back the settlement operator with the source-rail funds locked in a settlement vault. Atum Labs is operating the first fulfillment verifier, but because the choice of verifier is embedded in each and every payment request (with Atum’s as the default), a completely different verifier may be substituted in. The verifier interface is defined by an open schema. Any verification authority may be used, as long as the parties agree on it.

Further still, even the Atum smart contracts are substitutable. There is an escrow contract on the source chain, which releases source funds once fulfillment is proven, and a simple proxy on the destination chain, which emits events for a standardized proof. Both contracts are specified by parameters in the payment request, so both may be substituted. And again, as long as all of the parties hold mutual trust in the contracts specified by the request, it proceeds seamlessly through the network.

From platform to protocol

Atum is establishing a network around a protocol, and the aim is for every point of trust within that network to be substitutable.

In these early stages Atum looks more like a platform than a protocol, with Atum playing many of the trusted roles in the network. However, already today the seams for those substitutions are well established and ready for new trusted participants to enter the network.

That is also what this is not. By design, Atum is not a blockchain of its own: every payment settles on the rails it started and ended on. It is not an issued currency. It is not a settlement operator — independent operators quote and fulfill; Atum does not take the other side. It is not a custodian: source funds lock in a contract with two exits, pay the operator once delivery is proven, or refund the payer. It is not a preferred-partner network: any qualified operator can quote.

Atum is structured for neutrality at its core: the protocol doesn’t care who you trust; it just provides the tools and the venue for you and your counterparties to agree.