UX Recommendations
Intents Deposit addresses should not be presented as generic blockchain deposit addresses.
A deposit address can technically receive multiple different assets on a given network. However, Intents may support only a specific subset of those assets. This creates an important UX risk: if users see only an address and a QR code, they may reasonably assume that any asset supported by that network can be sent to that address.
If a user sends an unsupported asset, the deposit may not be processed, and the funds may be difficult or impossible to recover.
The integration should therefore make it very clear what can be deposited before the user sends anything.
Recommended UX
When displaying an Intents Deposit address, show the transfer requirements directly alongside it.
At minimum, users should be able to immediately understand:
which network they should send from;
which asset or assets are supported;
whether there is a minimum deposit amount;
whether there are any other transfer restrictions;
what can happen if they send something unsupported.
The deposit address should never appear without this context.
A good flow is:
The user selects or sees the source network.
The UI clearly shows how many assets are supported.
The user selects the asset they want to deposit.
The deposit address and QR code are shown.
Transfer requirements and warning are displayed directly next to, or immediately below, the address.
For example:
Transfer requirements Send only BTC from the Bitcoin network. Sending another asset or using another network may result in loss of funds.
If there are additional conditions, they should be included in the same area:
Transfer requirements Send only BTC from the Bitcoin network. Minimum deposit: $1. Do not send from an exchange if exchange deposits are not supported.
Make supported assets visible
One of the most important parts of the UX is making it clear that the deposit address may not support every asset on the selected network.
For example, showing:
1 asset supported
is useful because it immediately tells the user that the address has restrictions.
If multiple assets are supported, the UI can show:
4 assets supported
and allow the user to view or select from the supported assets.
This is preferable to showing only a generic address because it changes the user's mental model from:
"This is my address on this network."
to:
"This is a deposit address with specific supported assets."
That distinction is important.
Tie the address to the selected network and asset
The address should visually belong to the selected deposit configuration.
For example:
Sending from chain Bitcoin
Supported asset BTC
Permanent deposit address
bc1q...
The network and supported asset should remain visible while the address and QR code are displayed.
Avoid flows where the user selects an asset on one screen and then lands on a separate screen that shows only:
Deposit address
bc1q...
Once the asset and network disappear from the UI, the address becomes ambiguous again.
Show the warning where the user needs it
Warnings should be placed close to the deposit address and QR code.
Do not hide this information inside:
documentation;
tooltips;
FAQ pages;
support articles;
secondary screens.
The user needs this information at the moment they are about to copy or scan the address.
A dedicated Transfer requirements section works well because it is visible without interrupting the flow.
For example:
Transfer requirements Send only the selected asset from the selected network. Unsupported deposits may not be recoverable.
For higher-risk cases, stronger wording may be appropriate:
Transfer requirements Send only USDC from Ethereum. Sending any other token or using another network may result in permanent loss of funds.
Avoid generic deposit copy
Avoid language that implies broad compatibility.
For example, avoid:
Send funds to this address.
or:
Deposit to this address.
Prefer:
Send only BTC from the Bitcoin network to this address.
or:
This address supports deposits of BTC from Bitcoin only.
The wording should reinforce that the deposit address has specific requirements.
QR codes need the same context
A QR code should not be shown by itself.
Users often scan a QR code and complete the transaction in another wallet, where the original interface is no longer visible. The deposit screen should therefore make the supported network and asset obvious before the user scans.
A good structure is:
Bitcoin
BTC supported
bc1q...
[QR code]
Transfer requirements Send only BTC from the Bitcoin network.
The same rules should apply whether the user copies the address or scans the QR code.
If multiple assets are supported
If an address supports several assets, make those assets discoverable.
For example:
3 assets supported USDC, USDT, ETH
or allow the user to open an asset selector.
If the list is large, showing the number of supported assets and providing a dedicated selection screen is better than displaying a long list next to the address.
The important part is that users should never interpret the address as supporting every asset available on the network.
Example of a good integration
A good deposit experience combines the relevant information in one place:
source network is clearly visible;
supported assets are explicitly indicated;
the user selects the asset they expect to receive;
the deposit address and QR code are shown;
fees and estimated deposit time are visible;
transfer requirements appear directly below the address;
minimum deposit and other restrictions are clearly stated.
This provides enough information for the user to understand how to make a valid deposit without overwhelming them with technical details.
The goal is not to add more warnings. The goal is to remove ambiguity.
Core principle
Users should never have to infer what can be sent to an Intents Deposit address.
An Intents Deposit address should always be presented along with its supported network, supported asset (s), and any relevant transfer requirements.
If sending an unsupported asset can result in loss of funds, that risk should be communicated before the user copies or scans the deposit address.
Last updated