Deposit memos carry swap instructions across chains

A deposit memo routes a cross-chain swap by attaching instructions to the inbound transaction, including the asset to receive and the destination address. Those fields determine whether the protocol can deliver the output as intended or must refund the deposit.

On THORChain, the memo is transaction data that nodes inspect alongside a deposit to a network vault, according to the protocol’s developer documentation. It tells the swap handler what to do with the funds; it does not itself move them or encode a path through every pool. The source transaction supplies the asset, while the memo specifies the requested swap.

That distinction helps explain why a thor swap can be initiated from one chain and paid out on another. THORChain’s docs describe swaps between native assets using its liquidity pools, with RUNE connecting the pools. For a closer look at how this route compares with bridge and DEX routes, see the fuller fee breakdown.

What does a swap memo tell the protocol?

A THORChain swap memo identifies the swap function, the target asset and the output destination. The documented format is SWAP:ASSET:DESTADDR:LIM/INTERVAL/QUANTITY:AFFILIATE:FEE, with some fields optional. The target asset tells the handler which pool or pools are needed; the destination address tells it where to send the resulting asset on that asset’s chain.

The limit field can set a minimum acceptable output, so the protocol refunds the deposit if the swap cannot meet that threshold. A refund address can also be supplied; absent one, THORChain’s memo documentation says a refund goes to the originator’s address. Affiliate fields can direct a specified fee, where applicable. These parameters make the memo an instruction set rather than a general-purpose description.

How does the deposit become an output on another chain?

After the inbound transaction reaches a THORChain vault, network nodes observe it and parse the memo. THORChain’s swap guide says the nodes process the transaction after a majority have observed it, then vaults sign the outbound transaction. The protocol executes the requested exchange against its liquidity pools and sends the output to the destination address recorded in the memo.

The memo therefore selects the intended result, while pool liquidity and the transaction’s amount determine what the swap can deliver. In a BTC-to-ETH example, the BTC deposit is exchanged through THORChain’s pools and native ETH is sent to the specified Ethereum address. The user does not need to send RUNE as a separate hop; the protocol uses it as the pool connector.

What should users check before sending?

Users should check that the asset, destination chain, address and any minimum-output limit match their intention. THORChain’s developer docs state that invalid transactions or memos can be refunded, while deposits below chain-specific dust thresholds may be ignored. Memo capacity also varies by chain, so an instruction that fits one transaction format may not fit another.

• Confirm the target asset and destination address are on the intended chain.
• Review the minimum-output limit and refund address, if provided.
• Use current deposit instructions; THORChain’s swap guide warns against reusing expired inbound addresses.
• Check that the memo fits the source chain’s available transaction field.

For users, the practical rule is to treat the memo and the deposit address as a matched set of instructions. The memo tells the protocol what output to attempt; the signed inbound transaction commits the funds that make the attempt possible.