[ { "network": "Akash", "id": "akash", "tickers": [ "AKT" ], "field": "Memo", "required": "exchange-deposits", "valueType": "text", "limits": "Not documented. Akash's architecture docs list a 'Memo size limit' ante check without a value. The SDK default is 256 and chains can change it by governance.", "addressFormatsWithMemo": null, "ifMissing": "The tokens still arrive at the shared deposit address; the receiver cannot match them to a customer automatically.", "notes": "Cosmos SDK chain: the memo is one text field for the whole transaction (TxBody.memo). Current SDK command-line tools use the flag --note (previously --memo). The limit parameter is called max_memo_characters, but the SDK code measures the memo in bytes, so a non-ASCII character counts as more than one. A transaction whose memo is over the limit is rejected with the error 'memo too large'; an empty memo is always accepted by the protocol. IBC token transfers carry a separate packet memo (ICS-20), which ibc-go caps at 32768 bytes.", "status": "active", "statusNote": "Active as its own chain (akashnet-2). AEP-79 (status Final) plans a move to shared security with an estimated completion of 2026-12-31; memo rules may change after that move.", "sources": [ "https://akash.network/docs/node-operators/architecture/application-layer/", "https://akash.network/roadmap/aep-79/", "https://github.com/cosmos/cosmos-sdk/blob/main/proto/cosmos/tx/v1beta1/tx.proto", "https://github.com/cosmos/cosmos-sdk/blob/main/x/auth/types/params.go", "https://github.com/cosmos/cosmos-sdk/blob/main/x/auth/ante/basic.go", "https://github.com/cosmos/cosmos-sdk/blob/main/client/flags/flags.go", "https://docs.cosmos.network/ibc/latest/apps/transfer/messages" ], "checkedAt": "2026-09-19", "formats": [ { "kind": "text", "maxBytes": null, "typicalMaxBytes": 256 } ] }, { "network": "BNB Beacon Chain", "id": "bnb-beacon-chain", "tickers": [ "BNB" ], "field": "Memo", "required": "exchange-deposits", "valueType": "text", "limits": "max 128 bytes", "addressFormatsWithMemo": null, "ifMissing": "The chain is shut down, so no new transfers are possible. While it ran: the tokens arrived at the shared address and the receiver could not match them automatically, unless the receiving address had turned on the BEP-12 memo check, in which case a transfer without a valid memo was rejected.", "notes": "BEP-12 describes exchanges using a single deposit address and asking clients to enter a memo (also called a tag). It let a receiving address require a non-empty, digits-only memo on incoming transfers. Addresses started with bnb1 (BEP2 tokens). One archived docs page's pseudocode also rejects memos longer than 100; BEP-12 and the node code do not contain that check (see report).", "status": "sunset", "statusNote": "Shut down at block height 385,251,927 on December 3, 2024 (BNB Chain Fusion). Official Beacon Chain docs survive only in the archived branch of the docs repo.", "sources": [ "https://docs.bnbchain.org/bc-fusion/overview/", "https://github.com/bnb-chain/bnb-chain.github.io/blob/archive-branch/docs/beaconchain/transfer.md", "https://github.com/bnb-chain/node/blob/master/common/tx/ante.go", "https://github.com/bnb-chain/BEPs/blob/master/BEPs/BEP12.md" ], "checkedAt": "2026-09-19", "formats": [ { "kind": "text", "maxBytes": 128 } ] }, { "network": "Casper", "id": "casper", "tickers": [ "CSPR" ], "field": "Transfer ID", "required": "exchange-deposits", "valueType": "uint64", "limits": "unsigned 64-bit integer (0 to 18446744073709551615); optional at protocol level (Option)", "addressFormatsWithMemo": null, "ifMissing": "The CSPR still arrives in the receiving account; a receiver that tracks many users' balances inside one account cannot tell who to credit automatically.", "notes": "Casper's docs call the transfer ID 'a memo field' that is necessary when transferring to some recipients, for example an account whose sub-balances are tracked off-chain, and say to pass 0 or any u64 if it is not needed. CLI flag: --transfer-id (argument 'id'). The older casper-client transfer command requires --transfer-id; in Casper 2.0 (Condor) the new transaction transfer command makes it optional. Casper 2.0 docs describe it as a 'Unique transfer identifier (prevents replay attacks)' (see report). Accounts are hex public keys (prefix 01 or 02) with no embedded ID.", "status": "active", "statusNote": null, "sources": [ "https://docs.casper.network/developers/cli/transfers/direct-token-transfer", "https://docs.casper.network/condor/transactions", "https://docs.casper.network/resources/tutorials/advanced/list-cspr", "https://docs.casper.network/concepts/accounts-and-keys", "https://github.com/casper-network/casper-node/blob/dev/types/src/system/mint/entry_points.rs" ], "checkedAt": "2026-09-19", "formats": [ { "kind": "integer", "name": "Transfer ID", "max": "18446744073709551615" } ] }, { "network": "Celestia", "id": "celestia", "tickers": [ "TIA" ], "field": "Memo", "required": "exchange-deposits", "valueType": "text", "limits": "256 bytes (auth.MaxMemoCharacters, 'Largest allowed size for a memo in bytes'; changeable by governance)", "addressFormatsWithMemo": null, "ifMissing": "The tokens still arrive at the shared deposit address; the receiver cannot match them to a customer automatically.", "notes": "docs.celestia.org does not discuss memos; the limit comes from the official celestia-app specification. Cosmos SDK chain: the memo is one text field for the whole transaction (TxBody.memo). Current SDK command-line tools use the flag --note (previously --memo). The limit parameter is called max_memo_characters, but the SDK code measures the memo in bytes, so a non-ASCII character counts as more than one. A transaction whose memo is over the limit is rejected with the error 'memo too large'; an empty memo is always accepted by the protocol. IBC token transfers carry a separate packet memo (ICS-20), which ibc-go caps at 32768 bytes.", "status": "active", "statusNote": null, "sources": [ "https://celestiaorg.github.io/celestia-app/parameters_v10.html", "https://celestiaorg.github.io/celestia-app/ante_handler_v10.html", "https://github.com/cosmos/cosmos-sdk/blob/main/proto/cosmos/tx/v1beta1/tx.proto", "https://github.com/cosmos/cosmos-sdk/blob/main/x/auth/types/params.go", "https://github.com/cosmos/cosmos-sdk/blob/main/x/auth/ante/basic.go", "https://github.com/cosmos/cosmos-sdk/blob/main/client/flags/flags.go", "https://docs.cosmos.network/ibc/latest/apps/transfer/messages" ], "checkedAt": "2026-09-19", "formats": [ { "kind": "text", "maxBytes": 256 } ] }, { "network": "Cosmos Hub", "id": "cosmos-hub", "tickers": [ "ATOM" ], "field": "Memo", "required": "exchange-deposits", "valueType": "text", "limits": "512 (cosmoshub-4 genesis value of max_memo_characters; changeable by governance)", "addressFormatsWithMemo": null, "ifMissing": "The tokens still arrive at the shared deposit address; the receiver cannot match them to a customer automatically.", "notes": "The Hub's own parameter docs say an exchange may use a common deposit address for all of its users and tell deposits apart using the memo field. Cosmos SDK chain: the memo is one text field for the whole transaction (TxBody.memo). Current SDK command-line tools use the flag --note (previously --memo). The limit parameter is called max_memo_characters, but the SDK code measures the memo in bytes, so a non-ASCII character counts as more than one. A transaction whose memo is over the limit is rejected with the error 'memo too large'; an empty memo is always accepted by the protocol. IBC token transfers carry a separate packet memo (ICS-20), which ibc-go caps at 32768 bytes.", "status": "active", "statusNote": null, "sources": [ "https://github.com/cosmos/governance/blob/master/params-change/Auth.md", "https://docs.cosmos.network/sdk/latest/modules/auth/auth", "https://github.com/cosmos/ibc/blob/main/spec/app/ics-020-fungible-token-transfer/README.md", "https://github.com/cosmos/cosmos-sdk/blob/main/proto/cosmos/tx/v1beta1/tx.proto", "https://github.com/cosmos/cosmos-sdk/blob/main/x/auth/types/params.go", "https://github.com/cosmos/cosmos-sdk/blob/main/x/auth/ante/basic.go", "https://github.com/cosmos/cosmos-sdk/blob/main/client/flags/flags.go", "https://docs.cosmos.network/ibc/latest/apps/transfer/messages" ], "checkedAt": "2026-09-19", "formats": [ { "kind": "text", "maxBytes": 512 } ] }, { "network": "Cronos POS Chain (formerly Crypto.org Chain)", "id": "cronos-pos", "tickers": [ "CRO" ], "field": "Memo", "required": "exchange-deposits", "valueType": "text", "limits": "Chain value not stated: the genesis docs describe the parameter ('Maximum number of characters in a memo of a transaction') without a value. Standard Cosmos SDK memo check; SDK default 256.", "addressFormatsWithMemo": null, "ifMissing": "The tokens still arrive at the shared deposit address; the receiver cannot match them to a customer automatically.", "notes": "The chain's wallet guide says to leave the memo blank for normal transfers, but that you will need to provide a memo when sending to an exchange. Cosmos SDK chain: the memo is one text field for the whole transaction (TxBody.memo). Current SDK command-line tools use the flag --note (previously --memo). The limit parameter is called max_memo_characters, but the SDK code measures the memo in bytes, so a non-ASCII character counts as more than one. A transaction whose memo is over the limit is rejected with the error 'memo too large'; an empty memo is always accepted by the protocol. IBC token transfers carry a separate packet memo (ICS-20), which ibc-go caps at 32768 bytes.", "status": "active", "statusNote": "Active. Renamed from Crypto.org Chain to Cronos POS Chain on October 16, 2023; the chain ID is still crypto-org-chain-mainnet-1.", "sources": [ "https://docs.cronos-pos.org/for-users/wallets/keplr_ibc_guide", "https://docs.cronos-pos.org/cronos-pos-chain-protocol/chain-details/genesis_file", "https://blog.cronos-pos.org/p/cryptoorg-chain-becomes-cronos-pos", "https://github.com/cosmos/cosmos-sdk/blob/main/proto/cosmos/tx/v1beta1/tx.proto", "https://github.com/cosmos/cosmos-sdk/blob/main/x/auth/types/params.go", "https://github.com/cosmos/cosmos-sdk/blob/main/x/auth/ante/basic.go", "https://github.com/cosmos/cosmos-sdk/blob/main/client/flags/flags.go", "https://docs.cosmos.network/ibc/latest/apps/transfer/messages" ], "checkedAt": "2026-09-19", "formats": [ { "kind": "text", "maxBytes": null, "typicalMaxBytes": 256 } ] }, { "network": "dYdX Chain", "id": "dydx", "tickers": [ "DYDX" ], "field": "Memo", "required": "exchange-deposits", "valueType": "text", "limits": "Chain value not stated in the chain's official docs. The chain uses the standard Cosmos SDK memo check; the SDK default is 256 and chains can change it by governance.", "addressFormatsWithMemo": null, "ifMissing": "The tokens still arrive at the shared deposit address; the receiver cannot match them to a customer automatically.", "notes": "dYdX's docs only show an optional 'memo' parameter in client method signatures. Cosmos SDK chain: the memo is one text field for the whole transaction (TxBody.memo). Current SDK command-line tools use the flag --note (previously --memo). The limit parameter is called max_memo_characters, but the SDK code measures the memo in bytes, so a non-ASCII character counts as more than one. A transaction whose memo is over the limit is rejected with the error 'memo too large'; an empty memo is always accepted by the protocol. IBC token transfers carry a separate packet memo (ICS-20), which ibc-go caps at 32768 bytes.", "status": "active", "statusNote": null, "sources": [ "https://docs.dydx.xyz/", "https://github.com/dydxprotocol/v4-chain/blob/main/protocol/app/ante.go", "https://github.com/cosmos/cosmos-sdk/blob/main/proto/cosmos/tx/v1beta1/tx.proto", "https://github.com/cosmos/cosmos-sdk/blob/main/x/auth/types/params.go", "https://github.com/cosmos/cosmos-sdk/blob/main/x/auth/ante/basic.go", "https://github.com/cosmos/cosmos-sdk/blob/main/client/flags/flags.go", "https://docs.cosmos.network/ibc/latest/apps/transfer/messages" ], "checkedAt": "2026-09-19", "formats": [ { "kind": "text", "maxBytes": null, "typicalMaxBytes": 256 } ] }, { "network": "Hedera", "id": "hedera", "tickers": [ "HBAR" ], "field": "Memo", "required": "exchange-deposits", "valueType": "text", "limits": "max 100 bytes of UTF-8 (network setting transaction.maxMemoUtf8Bytes, default 100); a zero byte (0x00) is not allowed", "addressFormatsWithMemo": null, "ifMissing": "The HBAR still arrives in the receiving account; a service that shares one account among many users cannot match it to a customer automatically.", "notes": "The transaction memo is optional and visible to everyone. It is different from the account memo, which is a property of the account itself. Official docs say a memo may be needed for transferring to exchange accounts. Accounts are IDs of the form 0.0.. Some official pages say '100 characters' while the protobuf spec and node code count UTF-8 bytes (see report). If an account has Receiver Signature Required turned on (off by default), it must sign every incoming transfer.", "status": "active", "statusNote": null, "sources": [ "https://docs.hedera.com/learn/core-concepts/transactions/properties", "https://docs.hedera.com/learn/core-concepts/transactions", "https://github.com/hashgraph/hedera-protobufs/blob/main/services/transaction.proto", "https://docs.hedera.com/evm/integrations/wallets/metamask-snap-tutorial", "https://docs.hedera.com/native/transactions/modify-fields", "https://docs.hedera.com/learn/core-concepts/accounts/account-properties" ], "checkedAt": "2026-09-19", "formats": [ { "kind": "text", "maxBytes": 100, "noZeroByte": true } ] }, { "network": "Injective", "id": "injective", "tickers": [ "INJ" ], "field": "Memo", "required": "exchange-deposits", "valueType": "text", "limits": "Chain value not stated in the chain's official docs; Injective's auth module page reproduces the Cosmos SDK table, which shows 256 as an example value. The SDK default is 256 and chains can change it by governance.", "addressFormatsWithMemo": null, "ifMissing": "The tokens still arrive at the shared deposit address; the receiver cannot match them to a customer automatically.", "notes": "Injective's docs show the CLI flag --note ('Note to add a description to the transaction (previously --memo)'). Cosmos SDK chain: the memo is one text field for the whole transaction (TxBody.memo). Current SDK command-line tools use the flag --note (previously --memo). The limit parameter is called max_memo_characters, but the SDK code measures the memo in bytes, so a non-ASCII character counts as more than one. A transaction whose memo is over the limit is rejected with the error 'memo too large'; an empty memo is always accepted by the protocol. IBC token transfers carry a separate packet memo (ICS-20), which ibc-go caps at 32768 bytes.", "status": "active", "statusNote": null, "sources": [ "https://docs.injective.network/developers-native/core/auth", "https://docs.injective.network/developers-cosmwasm/mainnet-deployment-guide", "https://github.com/cosmos/cosmos-sdk/blob/main/proto/cosmos/tx/v1beta1/tx.proto", "https://github.com/cosmos/cosmos-sdk/blob/main/x/auth/types/params.go", "https://github.com/cosmos/cosmos-sdk/blob/main/x/auth/ante/basic.go", "https://github.com/cosmos/cosmos-sdk/blob/main/client/flags/flags.go", "https://docs.cosmos.network/ibc/latest/apps/transfer/messages" ], "checkedAt": "2026-09-19", "formats": [ { "kind": "text", "maxBytes": null, "typicalMaxBytes": 256 } ] }, { "network": "Kava", "id": "kava", "tickers": [ "KAVA" ], "field": "Memo", "required": "exchange-deposits", "valueType": "text", "limits": "Chain value not stated in the chain's official docs. The chain uses the standard Cosmos SDK memo check; the SDK default is 256 and chains can change it by governance.", "addressFormatsWithMemo": null, "ifMissing": "The tokens still arrive at the shared deposit address; the receiver cannot match them to a customer automatically. Kava's FAQ warns that funds sent to such an exchange without a memo can be lost.", "notes": "Kava's own FAQ says some exchanges require a memo for cross-chain transfers and that funds sent without one can be lost. Kava's CLI guide shows the flag --memo, while the SDK version in Kava's source (v0.47) uses --note. Cosmos SDK chain: the memo is one text field for the whole transaction (TxBody.memo). Current SDK command-line tools use the flag --note (previously --memo). The limit parameter is called max_memo_characters, but the SDK code measures the memo in bytes, so a non-ASCII character counts as more than one. A transaction whose memo is over the limit is rejected with the error 'memo too large'; an empty memo is always accepted by the protocol. IBC token transfers carry a separate packet memo (ICS-20), which ibc-go caps at 32768 bytes.", "status": "active", "statusNote": null, "sources": [ "https://docs.kava.io/docs/faq/earn/", "https://docs.kava.io/docs/cosmos/cli/quick-guide/", "https://github.com/Kava-Labs/kava/blob/master/go.mod", "https://github.com/cosmos/cosmos-sdk/blob/main/proto/cosmos/tx/v1beta1/tx.proto", "https://github.com/cosmos/cosmos-sdk/blob/main/x/auth/types/params.go", "https://github.com/cosmos/cosmos-sdk/blob/main/x/auth/ante/basic.go", "https://github.com/cosmos/cosmos-sdk/blob/main/client/flags/flags.go", "https://docs.cosmos.network/ibc/latest/apps/transfer/messages" ], "checkedAt": "2026-09-19", "formats": [ { "kind": "text", "maxBytes": null, "typicalMaxBytes": 256 } ] }, { "network": "Mina", "id": "mina", "tickers": [ "MINA" ], "field": "Memo", "required": "exchange-deposits", "valueType": "text", "limits": "max 32 bytes of content (stored in a fixed 34-byte field); the number comes from the node and official signer source code, not the docs site", "addressFormatsWithMemo": null, "ifMissing": "Mina's docs say such funds are NOT lost: they reach the exchange's address, but the exchange may not be able to match the deposit to the user's account automatically without the memo.", "notes": "Mina's docs say some exchanges require users to include a unique memo when depositing, recommend that exchanges do NOT require a memo for deposits, and recommend that wallets expose an optional memo field. CLI flag: --memo.", "status": "active", "statusNote": null, "sources": [ "https://docs.minaprotocol.com/node-operators/faq", "https://docs.minaprotocol.com/node-operators/reference/mina-cli-reference", "https://github.com/MinaProtocol/mina/blob/compatible/src/lib/mina_base/signed_command_memo.ml", "https://github.com/o1-labs/o1js/blob/main/src/mina-signer/src/memo.ts" ], "checkedAt": "2026-09-19", "formats": [ { "kind": "text", "maxBytes": 32 } ] }, { "network": "Osmosis", "id": "osmosis", "tickers": [ "OSMO" ], "field": "Memo", "required": "exchange-deposits", "valueType": "text", "limits": "Chain value not stated in the chain's official docs. The chain uses the standard Cosmos SDK memo check; the SDK default is 256 and chains can change it by governance.", "addressFormatsWithMemo": null, "ifMissing": "The tokens still arrive at the shared deposit address; the receiver cannot match them to a customer automatically.", "notes": "On Osmosis the IBC packet memo (not the transaction memo) can trigger contract calls (IBC hooks) and onward forwarding (packet forward middleware) when it holds JSON in a specific form. Cosmos SDK chain: the memo is one text field for the whole transaction (TxBody.memo). Current SDK command-line tools use the flag --note (previously --memo). The limit parameter is called max_memo_characters, but the SDK code measures the memo in bytes, so a non-ASCII character counts as more than one. A transaction whose memo is over the limit is rejected with the error 'memo too large'; an empty memo is always accepted by the protocol. IBC token transfers carry a separate packet memo (ICS-20), which ibc-go caps at 32768 bytes.", "status": "active", "statusNote": null, "sources": [ "https://docs.osmosis.zone/build/chain/ibc-hooks/", "https://docs.osmosis.zone/integrate/features/packet-forward-middleware/", "https://github.com/osmosis-labs/osmosis/blob/main/app/ante.go", "https://github.com/cosmos/cosmos-sdk/blob/main/proto/cosmos/tx/v1beta1/tx.proto", "https://github.com/cosmos/cosmos-sdk/blob/main/x/auth/types/params.go", "https://github.com/cosmos/cosmos-sdk/blob/main/x/auth/ante/basic.go", "https://github.com/cosmos/cosmos-sdk/blob/main/client/flags/flags.go", "https://docs.cosmos.network/ibc/latest/apps/transfer/messages" ], "checkedAt": "2026-09-19", "formats": [ { "kind": "text", "maxBytes": null, "typicalMaxBytes": 256 } ] }, { "network": "Sei", "id": "sei", "tickers": [ "SEI" ], "field": "Memo", "required": "exchange-deposits", "valueType": "text", "limits": "Cosmos-side (sei1...) transactions: chain value not stated in Sei's docs; standard Cosmos SDK memo check (SDK default 256). EVM (0x...) transactions: no memo at all.", "addressFormatsWithMemo": null, "ifMissing": "The tokens still arrive at the shared deposit address; the receiver cannot match them to a customer automatically.", "notes": "Sei's user quickstart says withdrawals from exchanges typically need no memo, but depositing back may require one. The memo exists only on Cosmos-side (sei1...) transactions: Sei's docs say an EVM transaction that sets the Cosmos memo field is rejected. Cosmos SDK chain: the memo is one text field for the whole transaction (TxBody.memo). Current SDK command-line tools use the flag --note (previously --memo). The limit parameter is called max_memo_characters, but the SDK code measures the memo in bytes, so a non-ASCII character counts as more than one. A transaction whose memo is over the limit is rejected with the error 'memo too large'; an empty memo is always accepted by the protocol. IBC token transfers carry a separate packet memo (ICS-20), which ibc-go caps at 32768 bytes.", "status": "deprecated", "statusNote": "Under SIP-3 the Cosmos side (sei1... addresses, and with it the memo) is being removed and Sei becomes EVM-only. Official pages gave June 15, 2026 as the deadline for exchanges to move to EVM (0x...) addresses; IBC was disabled in both directions by July 2026. As of 2026-09-19 some official pages still describe the Cosmos shutdown as upcoming, so the exact switch-off date is not confirmed.", "sources": [ "https://docs.sei.io/learn/user-quickstart", "https://docs.sei.io/evm/differences-with-ethereum", "https://docs.sei.io/learn/sip-03-migration", "https://docs.sei.io/learn/sip-03-exchange-migration", "https://blog.sei.io/announcements/what-sip-03-means-for-exchanges-and-custodians/", "https://github.com/cosmos/cosmos-sdk/blob/main/proto/cosmos/tx/v1beta1/tx.proto", "https://github.com/cosmos/cosmos-sdk/blob/main/x/auth/types/params.go", "https://github.com/cosmos/cosmos-sdk/blob/main/x/auth/ante/basic.go", "https://github.com/cosmos/cosmos-sdk/blob/main/client/flags/flags.go", "https://docs.cosmos.network/ibc/latest/apps/transfer/messages" ], "checkedAt": "2026-09-19", "formats": [ { "kind": "text", "maxBytes": null, "typicalMaxBytes": 256 } ] }, { "network": "Stellar", "id": "stellar", "tickers": [ "XLM" ], "field": "Memo", "required": "exchange-deposits", "valueType": "text | uint64 | hash32", "limits": "MEMO_TEXT: ASCII or UTF-8 string up to 28 bytes; MEMO_ID: 64-bit unsigned integer (0 to 18446744073709551615); MEMO_HASH: 32-byte hash; MEMO_RETURN: 32-byte hash of the transaction being refunded", "addressFormatsWithMemo": "Muxed account (SEP-23 strkey, starts with M, 69 characters) encodes the base G... account plus a 64-bit ID, so no separate memo is needed when the receiver gives an M... address", "ifMissing": "The payment still lands in the shared (pooled) account; the receiver cannot match it to a customer automatically. Under SEP-29, an account can publish the data entry config.memo_required = 1 so that wallets and SDKs that follow SEP-29 refuse to submit a payment without a memo; this is a client-side check, not a network rule, and payments to muxed (M...) destinations are exempt.", "notes": "Memo types: MEMO_NONE, MEMO_TEXT, MEMO_ID, MEMO_HASH, MEMO_RETURN. The memo is set once per transaction, not per operation. Text, ID and hash memos are different types, so the type the receiver asks for matters as well as the value. Official docs call muxed accounts better in the long term but note they are not yet supported by all wallets and exchanges, and suggest supporting both memos and muxed accounts for a while. Muxed accounts do not exist on the ledger; funds go to the underlying G... account.", "status": "active", "statusNote": null, "sources": [ "https://developers.stellar.org/docs/learn/fundamentals/transactions/operations-and-transactions", "https://developers.stellar.org/docs/build/guides/transactions/pooled-accounts-muxed-accounts-memos", "https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0023.md", "https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0029.md" ], "checkedAt": "2026-09-19", "formats": [ { "kind": "integer", "name": "MEMO_ID", "max": "18446744073709551615" }, { "kind": "text", "maxBytes": 28, "name": "MEMO_TEXT" }, { "kind": "hex", "name": "MEMO_HASH", "bytes": 32 } ] }, { "network": "Terra (phoenix-1)", "id": "terra", "tickers": [ "LUNA" ], "field": "Memo", "required": "exchange-deposits", "valueType": "text", "limits": "512 (max memo characters, genesis value)", "addressFormatsWithMemo": null, "ifMissing": "The tokens still arrive at the shared deposit address; the receiver cannot match them to a customer automatically.", "notes": "Terra's docs show the flag --note ('Note to add a description to the transaction (previously --memo)'). Cosmos SDK chain: the memo is one text field for the whole transaction (TxBody.memo). Current SDK command-line tools use the flag --note (previously --memo). The limit parameter is called max_memo_characters, but the SDK code measures the memo in bytes, so a non-ASCII character counts as more than one. A transaction whose memo is over the limit is rejected with the error 'memo too large'; an empty memo is always accepted by the protocol. IBC token transfers carry a separate packet memo (ICS-20), which ibc-go caps at 32768 bytes.", "status": "active", "statusNote": null, "sources": [ "https://docs.terra.money/develop/module-specifications/spec-auth/", "https://docs.terra.money/develop/terrad/commands/transactions/terrad_tx_bank_send/", "https://github.com/cosmos/cosmos-sdk/blob/main/proto/cosmos/tx/v1beta1/tx.proto", "https://github.com/cosmos/cosmos-sdk/blob/main/x/auth/types/params.go", "https://github.com/cosmos/cosmos-sdk/blob/main/x/auth/ante/basic.go", "https://github.com/cosmos/cosmos-sdk/blob/main/client/flags/flags.go", "https://docs.cosmos.network/ibc/latest/apps/transfer/messages" ], "checkedAt": "2026-09-19", "formats": [ { "kind": "text", "maxBytes": 512 } ] }, { "network": "Terra Classic (columbus-5)", "id": "terra-classic", "tickers": [ "LUNC" ], "field": "Memo", "required": "exchange-deposits", "valueType": "text", "limits": "256 (max memo characters, documented default)", "addressFormatsWithMemo": null, "ifMissing": "The tokens still arrive at the shared deposit address; the receiver cannot match them to a customer automatically.", "notes": "Terra Classic caps the memo on outgoing IBC transfers at 1024 bytes, lower than the ibc-go limit. Cosmos SDK chain: the memo is one text field for the whole transaction (TxBody.memo). Current SDK command-line tools use the flag --note (previously --memo). The limit parameter is called max_memo_characters, but the SDK code measures the memo in bytes, so a non-ASCII character counts as more than one. A transaction whose memo is over the limit is rejected with the error 'memo too large'; an empty memo is always accepted by the protocol. IBC token transfers carry a separate packet memo (ICS-20), which ibc-go caps at 32768 bytes.", "status": "active", "statusNote": "Active, run by its community; documented on a separate Classic docs site.", "sources": [ "https://classic-docs.terra.money/docs/develop/module-specifications/spec-auth.html", "https://github.com/classic-terra/core/blob/main/custom/auth/ante/ibc_spamming_prevention.go", "https://github.com/cosmos/cosmos-sdk/blob/main/proto/cosmos/tx/v1beta1/tx.proto", "https://github.com/cosmos/cosmos-sdk/blob/main/x/auth/types/params.go", "https://github.com/cosmos/cosmos-sdk/blob/main/x/auth/ante/basic.go", "https://github.com/cosmos/cosmos-sdk/blob/main/client/flags/flags.go", "https://docs.cosmos.network/ibc/latest/apps/transfer/messages" ], "checkedAt": "2026-09-19", "formats": [ { "kind": "text", "maxBytes": 256 } ] }, { "network": "TON (The Open Network)", "id": "ton", "tickers": [ "GRAM", "TON" ], "field": "Comment", "required": "exchange-deposits", "valueType": "text", "limits": "Plain comment: message body starting with the 32-bit opcode 0x00000000, followed by UTF-8 text; the official docs state no fixed maximum length for plain comments. Encrypted comment (opcode 0x2167da4b): plaintext max 960 bytes.", "addressFormatsWithMemo": null, "ifMissing": "The coins still arrive at the shared deposit wallet. The official payments guide states that deposits without the correct invoice identifier may be lost and advises services to reject or hold unmatched deposits and offer a recovery workflow.", "notes": "The official payments guide describes two designs: invoice-based deposits (one shared address, a unique identifier in the transaction comment) and unique deposit addresses (one wallet per user, no comment needed). The same comment format is used for native coin transfers, Jetton (token) transfers and NFT transfers. The docs present encrypted comments for private wallet-to-wallet notes; the deposit flow in the payments guide reads plain-text comments. The native coin is now called Gram (GRAM) in the official docs; it was previously called Toncoin (TON).", "status": "active", "statusNote": null, "sources": [ "https://docs.ton.org/payments/toncoin", "https://docs.ton.org/contracts/standard/wallets/interact", "https://docs.ton.org/start-here" ], "checkedAt": "2026-09-19", "formats": [ { "kind": "text", "maxBytes": null, "name": "Comment" } ] }, { "network": "Vaulta (formerly EOS)", "id": "vaulta", "tickers": [ "A", "EOS" ], "field": "Memo", "required": "exchange-deposits", "valueType": "text", "limits": "max 256 bytes (checked by the token contract: memo.size() <= 256, error 'memo has more than 256 bytes')", "addressFormatsWithMemo": null, "ifMissing": "The tokens still arrive in the receiving account; a service that shares one account among many users cannot match them to a customer automatically.", "notes": "The memo is a parameter of the token contract's transfer action, so the limit comes from the contract, not the base protocol; the same 256-byte check is in eosio.token (EOS) and in the Vaulta system contract (A). The memo is optional for normal transfers. The official 'Watching Transfers' tutorial, written for exchanges and wallets, shows a deposit to an exchange-style account with a numeric memo. There are no per-user addresses: accounts are names of up to 12 characters (a-z, 1-5 and '.').", "status": "active", "statusNote": "The EOS Network rebranded to Vaulta; the new token symbol is A (contract core.vaulta), with a 1:1 swap from EOS that began on May 14, 2025. EOS tokens remain on-chain.", "sources": [ "https://github.com/VaultaFoundation/system-contracts/blob/main/contracts/eosio.token/src/eosio.token.cpp", "https://github.com/VaultaFoundation/vaulta-system-contract/blob/main/contracts/system.entry.cpp", "https://github.com/AntelopeIO/reference-contracts/blob/main/contracts/eosio.token/src/eosio.token.cpp", "https://github.com/VaultaFoundation/docs/blob/main/native/07_node-operation/50_tutorials/10_watching-transfers.md", "https://github.com/VaultaFoundation/docs/blob/main/native/02_core-concepts/20_accounts.md", "https://docs.vaulta.com/docs/latest/advanced-topics/upgrading-to-vaulta", "https://www.vaulta.com/resources/vaulta-token-swap-a-begins-may-14" ], "checkedAt": "2026-09-19", "formats": [ { "kind": "text", "maxBytes": 256 } ] }, { "network": "XRP Ledger", "id": "xrp", "tickers": [ "XRP" ], "field": "Destination tag", "required": "exchange-deposits", "valueType": "uint32", "limits": "32-bit unsigned integer: 0 to 4294967295", "addressFormatsWithMemo": "X-address (XLS-5, status Final) packs the classic r... address and the destination tag into one address; starts with X on Mainnet, T on Testnet", "ifMissing": "If the receiving account has the RequireDest flag (lsfRequireDestTag) set, the payment fails with tecDST_TAG_NEEDED: no XRP is delivered, and only the small transaction cost is charged, as with any tec result. If the flag is not set, the payment lands in the shared account and the receiver cannot tell automatically which customer to credit; the docs say this can require manual intervention.", "notes": "DestinationTag is an optional field of the Payment transaction. A separate SourceTag field (also UInt32) identifies the sender side. The Memos field is a different, free-form field (hex blobs, max 1 KB serialized) and is not the destination tag. The official docs describe lsfRequireDestTag as commonly used on exchanges and other shared accounts. Classic addresses start with r and are 25 to 35 characters long.", "status": "active", "statusNote": null, "sources": [ "https://xrpl.org/docs/concepts/transactions/source-and-destination-tags", "https://xrpl.org/docs/references/protocol/transactions/types/payment", "https://xrpl.org/docs/references/protocol/transactions/common-fields", "https://xrpl.org/docs/references/protocol/ledger-data/ledger-entry-types/accountroot", "https://xrpl.org/docs/references/protocol/transactions/transaction-results/tec-codes", "https://xrpl.org/docs/concepts/accounts/addresses", "https://github.com/XRPLF/XRPL-Standards/tree/master/XLS-0005-tagged-addresses" ], "checkedAt": "2026-09-19", "formats": [ { "kind": "integer", "name": "Destination tag", "max": "4294967295" } ] }, { "network": "Algorand", "id": "algorand", "tickers": [ "ALGO" ], "field": "Note", "required": "optional", "valueType": "bytes", "limits": "up to 1024 bytes at the normal fee, or up to 4096 bytes for an additional per-byte fee (MaxAbsoluteTxnNoteBytes, consensus version v42, 2026)", "addressFormatsWithMemo": null, "ifMissing": "The payment still arrives at the address; a receiver that relies on notes to tell senders apart cannot match it automatically.", "notes": "The note is optional arbitrary data on any transaction. The official docs make no statement that exchanges need a note for deposits; if a receiving service asks for one, it must be included. ARC-90 payment links (algorand://) can carry a note (note=) or a fixed, non-editable note (xnote=); the address itself never contains a note. Some official spec and docs pages still show only the older 1024-byte limit (see report).", "status": "active", "statusNote": null, "sources": [ "https://dev.algorand.co/concepts/transactions/reference/", "https://dev.algorand.co/concepts/transactions/fees#larger-transactions", "https://github.com/algorand/go-algorand/blob/master/config/consensus.go", "https://github.com/algorandfoundation/ARCs/blob/main/ARCs/arc-0090.md" ], "checkedAt": "2026-09-19", "formats": [ { "kind": "text", "maxBytes": 1024, "name": "Note" } ] }, { "network": "Internet Computer", "id": "icp", "tickers": [ "ICP" ], "field": "Memo", "required": "optional", "valueType": "uint64 | bytes", "limits": "ICP ledger legacy transfer: memo is a nat64 (0 to 18446744073709551615). ICRC-1 transfer: optional blob; the ICP ledger accepts up to 32 bytes; other ICRC-1 ledgers default to 32 bytes but can be configured (published as icrc1:max_memo_length); the ICRC-1 standard says ledgers SHOULD allow at least 32 bytes.", "addressFormatsWithMemo": "Per-user subaccounts instead of memos: an ICRC-1 account is a principal plus an optional 32-byte subaccount, written in text as -.; the legacy account identifier (64 hex characters) is a hash of principal plus subaccount.", "ifMissing": "The memo has no meaning to the ledger. Deposits to a per-user subaccount are identified by the account itself; if a receiver did rely on a memo on one shared account, the transfer still arrives but cannot be matched automatically.", "notes": "The official docs describe deposit flows where each user gets a unique deposit subaccount, rather than memos. ICP ledger blocks can hold both memo types (memo u64 and icrc1_memo blob). The 32-byte ICRC limits come from ledger source code; no docs page states the number.", "status": "active", "statusNote": null, "sources": [ "https://github.com/dfinity/ic/blob/master/rs/ledger_suite/icp/ledger.did", "https://github.com/dfinity/portal/blob/master/docs/references/ledger.mdx", "https://github.com/dfinity/ICRC-1/blob/main/standards/ICRC-1/README.md", "https://github.com/dfinity/ICRC-1/blob/main/standards/ICRC-1/TextualEncoding.md", "https://github.com/dfinity/ic/blob/master/rs/ledger_suite/icp/src/lib.rs", "https://github.com/dfinity/ic/blob/master/rs/ledger_suite/icrc1/ledger/src/lib.rs", "https://docs.internetcomputer.org/guides/digital-assets/ledgers/", "https://docs.internetcomputer.org/concepts/ledgers/" ], "checkedAt": "2026-09-19", "formats": [ { "kind": "integer", "name": "ICP ledger memo (nat64)", "max": "18446744073709551615" }, { "kind": "text", "maxBytes": 32, "name": "ICRC-1 memo" } ] }, { "network": "Monero", "id": "monero", "tickers": [ "XMR" ], "field": "Payment ID", "required": "optional", "valueType": "bytes", "limits": "Only the 8-byte (64-bit, 16 hex characters) encrypted payment ID remains, carried inside an integrated address. Long 32-byte (64 hex) payment IDs were removed in release 0.15 (2019) and can no longer be used.", "addressFormatsWithMemo": "Integrated address (106 characters, starts with 4) = standard address + encrypted 8-byte payment ID. Subaddresses (95 characters, start with 8) give each payer or payment its own address instead, with no payment ID.", "ifMissing": "If the sender pays the plain standard address instead of the integrated address, the XMR still reaches the receiving wallet but without a payment ID, so the receiver cannot match it to a customer automatically. With subaddresses there is nothing extra to enter.", "notes": "No separate memo field needs to be typed: when a service gives an integrated address, the payment ID is inside the address. One transaction cannot pay to more than one integrated address. The official docs say subaddresses are what you should use by default to receive Monero, and the 2019 deprecation notice encouraged services to move to subaddresses directly; the current integrated-address docs page says businesses accepting payments in an automated way should prefer integrated addresses (see report).", "status": "active", "statusNote": null, "sources": [ "https://www.getmonero.org/resources/moneropedia/paymentid.html", "https://www.getmonero.org/resources/moneropedia/address.html", "https://www.getmonero.org/2019/06/04/Long-Payment-ID-Deprecation.html", "https://docs.getmonero.org/public-address/integrated-address/", "https://docs.getmonero.org/public-address/subaddress/", "https://www.getmonero.org/resources/developer-guides/wallet-rpc.html" ], "checkedAt": "2026-09-19", "formats": [] }, { "network": "Stacks", "id": "stacks", "tickers": [ "STX" ], "field": "Memo", "required": "optional", "valueType": "bytes", "limits": "34 bytes: stored as exactly 34 bytes, zero-padded; the official JS SDK rejects memos longer than 34 UTF-8 bytes", "addressFormatsWithMemo": null, "ifMissing": "The STX still arrives at the address; a receiver that shares one address among many users cannot match it to a customer automatically.", "notes": "The memo is part of the STX token-transfer transaction. SIP-010 fungible tokens have an optional 34-byte memo on transfer as well. The official docs make no statement that exchanges need a memo for deposits; if a receiving service asks for one, it must be included. SIP-005 describes the token-transfer payload without mentioning the memo.", "status": "active", "statusNote": null, "sources": [ "https://docs.stacks.co/learn/network-fundamentals/technical-specifications", "https://github.com/stacks-network/stacks-core/blob/main/stacks-codec/src/transaction.rs", "https://github.com/stx-labs/stacks.js/blob/main/packages/transactions/src/constants.ts", "https://github.com/stacksgov/sips/blob/main/sips/sip-010/sip-010-fungible-token-standard.md" ], "checkedAt": "2026-09-19", "formats": [ { "kind": "text", "maxBytes": 34 } ] }, { "network": "Bitcoin", "id": "bitcoin", "tickers": [ "BTC" ], "field": "None", "required": "never", "valueType": "none", "limits": null, "addressFormatsWithMemo": null, "ifMissing": "Not applicable: receivers tell payments apart by giving a separate address for each payment.", "notes": "The official developer guide says using a separate address for each incoming payment makes it trivial to see which customers have paid. BIP-21 payment links can carry a label and message, but these are never added to the transaction. An OP_RETURN (null data) output can carry arbitrary data, but it is not a deposit memo.", "status": "active", "statusNote": null, "sources": [ "https://developer.bitcoin.org/devguide/payment_processing.html", "https://developer.bitcoin.org/devguide/transactions.html", "https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki" ], "checkedAt": "2026-09-19", "formats": [] }, { "network": "Ethereum", "id": "ethereum", "tickers": [ "ETH" ], "field": "None", "required": "never", "valueType": "none", "limits": null, "addressFormatsWithMemo": null, "ifMissing": "Not applicable: an ETH transfer has no memo field; the receiving address identifies the recipient.", "notes": "A transaction names a recipient ('to') and an amount ('value'). The optional 'input data' field holds arbitrary data and is mainly used to call contracts; it is not a deposit memo. A simple transfer uses 21000 gas. Official docs do not discuss exchange deposits; 'no memo' follows from the transaction format.", "status": "active", "statusNote": null, "sources": [ "https://ethereum.org/en/developers/docs/transactions/", "https://ethereum.org/en/developers/docs/accounts/" ], "checkedAt": "2026-09-19", "formats": [] }, { "network": "Kaspa", "id": "kaspa", "tickers": [ "KAS" ], "field": "None", "required": "never", "valueType": "none", "limits": null, "addressFormatsWithMemo": null, "ifMissing": "Not applicable: normal Kaspa transfers have no memo or tag; the receiving address identifies the recipient.", "notes": "UTXO model with kaspa: addresses (bech32 with checksum). Since the Crescendo hard fork (KIP-14, May 2025) normal transactions may carry arbitrary data in a payload field, but no official source describes it as a deposit identifier, and the official command-line wallet's send command does not set it. No official statement says 'no memo' in so many words; this follows from the transaction format.", "status": "active", "statusNote": null, "sources": [ "https://github.com/kaspanet/rusty-kaspa/blob/master/consensus/core/src/tx.rs", "https://github.com/kaspanet/kips/blob/master/kip-0014.md", "https://github.com/kaspanet/rusty-kaspa/blob/master/cli/src/modules/send.rs" ], "checkedAt": "2026-09-19", "formats": [] }, { "network": "Kusama", "id": "kusama", "tickers": [ "KSM" ], "field": "None", "required": "never", "valueType": "none", "limits": null, "addressFormatsWithMemo": null, "ifMissing": "Not applicable: a balance transfer has no memo field; the receiving address identifies the recipient.", "notes": "Same balance transfer calls as Polkadot (destination and amount only). Existential deposit: sending less than it to an empty account means the account won't receive the funds; the official page lists 0.0000033333 KSM on Kusama Asset Hub (where balances moved on October 7, 2025) and 0.00033333333 KSM on the relay chain. No current official exchange-deposit guidance was found.", "status": "active", "statusNote": null, "sources": [ "https://paritytech.github.io/polkadot-sdk/master/pallet_balances/pallet/enum.Call.html", "https://wiki.polkadot.com/learn/how-to/existential-deposit/", "https://wiki.polkadot.com/learn/how-to/asset-hub-migration/" ], "checkedAt": "2026-09-19", "formats": [] }, { "network": "NEAR Protocol", "id": "near", "tickers": [ "NEAR" ], "field": "None", "required": "never", "valueType": "none", "limits": null, "addressFormatsWithMemo": null, "ifMissing": "Not applicable: a native NEAR transfer has no memo field; the receiving account itself identifies the recipient.", "notes": "The protocol's Transfer action carries only an amount (deposit); the transaction has no memo. Accounts are named (for example alice.near, 2 to 64 characters) or implicit (64 hex characters). NEP-141 fungible tokens are different: ft_transfer has an optional memo argument, with no length limit in the standard. docs.near.org removed its exchange-integration pages on 2026-03-19; the last version described implicit accounts as useful for exchanges.", "status": "active", "statusNote": null, "sources": [ "https://nomicon.io/RuntimeSpec/Actions", "https://nomicon.io/RuntimeSpec/Transactions", "https://github.com/near/nearcore/blob/master/core/primitives/src/action/mod.rs", "https://docs.near.org/protocol/accounts-contracts/account-id", "https://github.com/near/NEPs/blob/master/neps/nep-0141.md", "https://github.com/near/docs/blob/0b4162f8a02ad0805668e7b038be55ba800b12de/docs/integrations/implicit-accounts.md" ], "checkedAt": "2026-09-19", "formats": [] }, { "network": "Polkadot", "id": "polkadot", "tickers": [ "DOT" ], "field": "None", "required": "never", "valueType": "none", "limits": null, "addressFormatsWithMemo": null, "ifMissing": "Not applicable: a balance transfer has no memo field; the receiving address identifies the recipient.", "notes": "The balance transfer calls (transfer_allow_death, transfer_keep_alive) take only a destination and an amount. A separate system.remark call can store arbitrary bytes but is not part of a transfer. Existential deposit: sending less than it to an empty account means the account won't receive the funds; it is 0.01 DOT on Polkadot Asset Hub (where balances moved on November 4, 2025) and 1 DOT on the relay chain. No current official exchange-deposit guidance was found.", "status": "active", "statusNote": null, "sources": [ "https://paritytech.github.io/polkadot-sdk/master/pallet_balances/pallet/enum.Call.html", "https://paritytech.github.io/polkadot-sdk/master/frame_system/pallet/enum.Call.html", "https://wiki.polkadot.com/learn/learn-transaction-construction/", "https://wiki.polkadot.com/learn/how-to/existential-deposit/", "https://wiki.polkadot.com/learn/how-to/asset-hub-migration/" ], "checkedAt": "2026-09-19", "formats": [] }, { "network": "Solana", "id": "solana", "tickers": [ "SOL" ], "field": "None (optional Memo program)", "required": "never", "valueType": "none", "limits": "Optional Memo program (MemoSq4gqABAXKb96qnH8TysNcWxMyWCqXgDLGmfcHr): UTF-8 text, up to 566 bytes in an unsigned instruction (as of v1.5.1)", "addressFormatsWithMemo": null, "ifMissing": "Not applicable for native SOL: the receiving address identifies the recipient.", "notes": "The official exchange guide recommends a unique deposit account for each user. The Memo program is optional: it checks that the memo is valid UTF-8 and writes it to the transaction log. Exception: a Token-2022 token account can turn on 'required memo on transfer', and the guide says exchanges may then ask users to add a memo instruction when depositing such tokens. The guide also says every SOL deposit must be at least the rent-exempt minimum (0.00089088 SOL at the time of writing).", "status": "active", "statusNote": null, "sources": [ "https://solana.com/docs/defi/exchange", "https://www.solana-program.com/docs/memo", "https://solana.com/docs/core/transactions/transaction-structure" ], "checkedAt": "2026-09-19", "formats": [] }, { "network": "Theta", "id": "theta", "tickers": [ "THETA", "TFUEL" ], "field": "None", "required": "never", "valueType": "none", "limits": null, "addressFormatsWithMemo": null, "ifMissing": "Not applicable: a native send transaction has no memo field; the receiving address identifies the recipient.", "notes": "The native send transaction (SendTx) has only a fee, inputs and outputs (address plus coins), covering both THETA and TFUEL. No official source addresses exchange deposits either way; 'no memo' follows from the transaction format.", "status": "active", "statusNote": null, "sources": [ "https://github.com/thetatoken/theta-protocol-ledger/blob/master/ledger/types/tx.go", "https://github.com/thetatoken/theta-mainnet-integration-guide/blob/master/docs/api.md", "https://github.com/thetatoken/theta-mainnet-integration-guide/blob/master/docs/cmd.md" ], "checkedAt": "2026-09-19", "formats": [] }, { "network": "TRON", "id": "tron", "tickers": [ "TRX" ], "field": "Memo (raw_data.data)", "required": "never", "valueType": "bytes", "limits": "No size limit stated in the docs. A memo makes the transaction larger (more bandwidth) and, under TIP-387, burns a memo fee set by a network parameter.", "addressFormatsWithMemo": null, "ifMissing": "Not applicable for normal deposits: the official exchange integration docs credit deposits by the receiving address.", "notes": "raw_data.data is an optional memo (hex bytes); the create-transaction API calls it extra_data. The official API reference says production systems should not use the memo as the only business identifier. The official exchange integration guide derives deposit addresses (BIP-44) and checks that the recipient belongs to the platform.", "status": "active", "statusNote": null, "sources": [ "https://developers.tron.network/docs/tron-protocol-transaction", "https://developers.tron.network/reference/createtransaction", "https://developers.tron.network/docs/exchange-wallet-integration", "https://developers.tron.network/docs/track-1-exchange-and-custodial-wallet-integration", "https://github.com/tronprotocol/tips/blob/master/tip-387.md" ], "checkedAt": "2026-09-19", "formats": [] } ]