An atomic transfer on Algorand is a group of up to 16 transactions that the network treats as one: either every transaction in the group is confirmed, or none is. It lets two parties exchange an asset for payment without either of them going first, and without a third party holding anything in between.
How an atomic transfer works
An atomic transfer works by binding several ordinary transactions together so that the network accepts or rejects them as a single unit. Nothing new is invented: a payment is still a payment and an asset transfer is still an asset transfer. What changes is that each of them is only valid alongside the others.
The steps are short. The parties agree what will move: for example, the buyer's payment to the seller and the seller's units to the buyer. Each transaction is created, and the set is grouped, which gives every transaction "the same group ID derived from the ordered set" (Algorand Developer Portal, Atomic Transaction Groups, checked 3 October 2026). Each party then signs only its own transaction. The signed group is submitted together, and the network confirms all of it in one block or none of it.
Two transactions, one outcome: both settle or neither does.
Because the group ID is calculated from the exact transactions in their exact order, nobody can change an amount, swap a recipient or drop a leg after the others have signed. Any change produces a different group, and the signatures no longer match it.
The limits are set by the protocol. A group can hold at most 16 transactions, and a transaction is valid for at most 1,000 rounds, which at Algorand's current block time is under an hour (Algorand protocol parameters, checked 3 October 2026). Every party therefore has to sign within that window.
The problem it solves: who goes first
Every exchange has the same weak point: one side has to move first. If the seller delivers before being paid, they can lose the asset. If the buyer pays before delivery, they can lose the money. Payment specialists call this principal risk, and the standard answer has a name, delivery versus payment, defined by the Bank for International Settlements' payments committee as a mechanism that ensures "delivery occurs if and only if the corresponding payment occurs" (CPMI glossary, checked 3 October 2026).
In traditional markets, delivery versus payment is provided by an intermediary: a settlement system, a central securities depository or an escrow agent who holds one side until the other arrives. An atomic transfer gives the same guarantee for assets and payments that are both on the blockchain, without an intermediary holding either side. It comes from the rule that the group settles whole or not at all.
For a tokenised asset this matters in a practical way. A sale of units recorded on Algorand, paid for in a currency token on Algorand, can settle in one step a few seconds after both parties sign. There is no period in which one side has performed and the other has not, so there is nothing to chase, reconcile or unwind.
What you can build with atomic transfers
Most uses are variations on one idea: several movements that only make sense together. The Algorand documentation lists exchanges of one asset for another, group payments in which "everyone pays or no one pays", payments split between several recipients, and circular trades (Algorand Developer Portal).
An asset exchanged for payment. The basic case: units in one direction, payment in the other.
A sale with a fee. The buyer's payment to the seller and a separate fee to the platform or agent sit in the same group, so the fee is paid only if the sale happens.
A first purchase. On Algorand an account must agree to hold an asset before it can receive it: "Before an account can receive an ASA, it must explicitly opt in" (Algorand Developer Portal, Asset Operations). The buyer's opt-in can be the first transaction of the group, so the buyer opts in, pays and receives in one step.
Fees paid by someone else. One transaction in a group can cover the network fees of the others, so a platform or an issuer can carry the cost of an exchange instead of each party paying its own fee.
A first purchase in one group: opt in, pay, pay the fee, receive.
Atomic transfers happen on one blockchain. Moving value between two different blockchains is a different problem with different risks, covered in cross-chain bridges explained.
What atomic transfers do not do
An atomic transfer guarantees that a set of on-chain movements happens together. It guarantees nothing beyond that.
It does not reach money that is not on the blockchain. A card payment or a bank transfer cannot be part of the group. When payment happens off-chain, the sale becomes two steps again, and the system needs states for "paid but not yet delivered". Trusty Digital's own NFT marketplace works this way: buyers pay by card, the NFT is delivered afterwards, and the platform has to handle what happens if delivery cannot complete, from re-checking the buyer's opt-in to a refund. An atomic transfer removes that work only when both sides are on-chain.
A card payment leaves a gap between paying and receiving. An atomic transfer has none.
It does not decide who may hold an asset. Eligibility, verification and transfer restrictions come from the asset's legal documents and its configuration, not from the group.
It does not override the asset's controls. If an asset is frozen for one of the accounts, its transfer fails and the whole group fails with it. A clawback address can still move the asset later. Settling atomically does not make a holding immune to the issuer's powers, as the section on what can go wrong in What is asset tokenisation? explains.
It does not wait. All parties must sign within the validity window. Conditions that run over days or weeks, such as "release the funds if the campaign reaches its target by the deadline", need a smart contract, not an atomic transfer.
It does not agree the price. The group settles whatever the parties put in it. Negotiating terms, and checking that the transactions match them, happens before anyone signs.
Where atomic transfers go wrong
The buyer has not opted in. The asset transfer fails, so the whole group fails. Include the opt-in in the group or check it first.
An account lacks the minimum balance. Each asset an Algorand account holds raises the balance it must keep by 0.1 ALGO. An account that cannot cover it cannot opt in, and the group fails.
Someone signs late. If one party signs after the validity window has closed, the group can no longer be submitted and has to be built again. This is the usual failure when signatures are collected by email or chat rather than in one session.
A signer cannot see what they are signing. A party signs only its own transaction, but its consent is to the whole group. A wallet that shows one transaction and hides the rest asks a person to approve an exchange they have not seen. Good wallets show every transaction in the group before signing.
The group is edited after signing. Changing any amount, recipient or order breaks the group, which is the safeguard working as intended. Fix the terms, rebuild the group, and collect fresh signatures.
Atomic transfer or smart contract escrow?
Use an atomic transfer when every party can sign at the same time and the exchange is complete in one moment: a sale, a swap, a payment with fees. It needs no code, has no contract to audit, and leaves nothing on the chain except the transactions themselves.
Use a smart contract when the exchange depends on something that happens later or on someone who is not present: a deadline, a target, a release on a condition, a refund if it is not met. The contract holds one side under published rules until the condition is decided. That brings code that has to be reviewed and maintained, which is why most issuers should write less custom code, not more.
Many real arrangements use both: a contract that decides when something may happen, and an atomic group that makes the final exchange settle whole.
Is an atomic transfer right for your exchange?
It fits when both the asset and the payment are recorded on Algorand, when the parties can sign within the same hour, and when the terms are agreed before signing. It does not fit when payment comes from a card or a bank account, when an exchange must wait for an outside event, or when a group would need more than 16 transactions.
Questions people also ask
Is an atomic transfer a smart contract? No. It is a feature of the Algorand protocol: ordinary transactions grouped so they settle together. No code is deployed and nothing needs to be audited, although a group can include calls to smart contracts when an exchange needs them.
How many transactions can an atomic group contain? Up to 16, a limit set in the protocol parameters. Larger exchanges have to be split into several groups, and then they are no longer atomic as a whole.
Can an atomic transfer be reversed? No. Once the group is confirmed, every transaction in it is final, like any other Algorand transaction. Correcting a mistake takes a new transaction that the receiving party agrees to.
Is an atomic transfer the same as an atomic swap? No. An atomic swap usually means exchanging assets between two different blockchains under a time-locked arrangement. An atomic transfer happens on one blockchain, and the protocol itself enforces the all-or-nothing rule.
The short version
An atomic transfer is Algorand's built-in delivery versus payment: both sides of an exchange settle in the same moment, or neither does, with no intermediary holding either side. It removes the question of who goes first, but only for movements that are already on the blockchain, between parties who can sign within the hour, under terms agreed beforehand. For conditions that unfold over time, it is the final step of a smart contract, not a substitute for one.
To see where atomic settlement sits in a full tokenisation project, read What is asset tokenisation?.
This article is general information, not legal, tax or investment advice.
10 min read
