Skip to main content

​
General

There is no testnet deployment and no plans for one. We recommend testing on NEAR mainnet using separate dev/test NEAR accounts.

​
Deposits

The deposit process begins once the transfer transaction on the foreign network has been completed. When the balance of the user’s unique deposit address becomes positive, our indexer generates a deposit event and assigns it a PENDING status.The next step is collecting the current tokens in storage. The result of this process will be either a COMPLETED or FAILED status. Deposits with a FAILED status are currently handled manually and eventually updated to the COMPLETED status.On EVM networks, deposits can bypass the PENDING status due to faster processing and transfer completion times.BTC deposits: If you want to make a deposit to an account that hasn’t yet been connected to the application, this is possible but requires caution. You can request a deposit address by calling the bridge API (deposit_address) and specifying the account_id parameter. The account_id can be a NEAR account, an EVM address, or a SOL address to which you have access.
We recommend starting with a small amount for experimentation. After the deposit is completed, you can connect your wallet and check the tokens.
Only ft_transfer_call can be used to deposit NEP-141 tokens from NEAR to intents.near:
<TOKEN_ACCOUNT_ID>::ft_transfer_call({
  "receiver_id": "intents.near",
  "amount": "1234",
  "msg": "{\"receiver_id\": \"<ACCOUNT_ID>\"}"
})
Here is an example receipt.The msg parameter can also be empty, so that funds will be deposited to sender_id (i.e. the caller of ft_transfer_call). Here is an example of such a transaction.
For EVM chains, NEAR Intents does not impose limitations on how deposits are executed at the smart contract level. Our listeners track the chain for:
  • ERC-20 Transfer events
  • Regular or internal native transfers
to any of the supported deposit addresses.As long as the resulting transaction emits a valid Transfer event (or performs a native value transfer) to the deposit address, it will be detected—even if it originates from a custom contract method (for example, a custom withdraw() function instead of transfer / transferFrom).
This information is not available for Solana because the mechanism of deposit tracking works differently on that chain.
Very small amounts (e.g., 5,000 sats) are considered “dust” and there is special business logic to process such small amounts. This may cause delays in sweeping.

​
ETH Connector Migration

Because of the split of ETH-connector, the aurora contract now acts as a NEP-141 proxy to eth.bridge.near. This leads to some changes:
  1. All new deposits will be treated as eth.bridge.near, even if triggered from the aurora smart contract—even from inside Aurora Mainnet (example tx). All withdrawals of legacy aurora will be received on NEAR as new eth.bridge.near.
  2. Migration of already deposited ETH@NEAR (aurora) can be done permissionlessly by withdrawing from intents.near and depositing it back right away. This can be done in a single transaction thanks to this patch on the eth-connector side.
Users can migrate in two ways:Option 1: Via ft_withdraw() transactionExample transaction with the following params:
{
  "token": "aurora",
  "receiver_id": "intents.near",
  "amount": "1234",
  "memo": "Migrate ETH: aurora -> eth.bridge.near",
  "msg": "<USER_ACCOUNT_ID>"
}
Option 2: Via ft_withdraw intentUse the same parameters as above.
The front-end automatically detects legacy tokens on your balance and prompts you to sign a migration intent.