DEV Community: Den

Choosing The Right Deployment Strategy for Smart Contracts on Near

Den — Sun, 20 Jul 2025 13:46:00 +0000

A new version of nearcore has recently been released on Near Protocol Mainnet. Among other changes, it introduces support for Global Contracts. This update solves a long-standing problem with contract deployment patterns and opens a new set of tools for developers. Now, we have multiple fundamentally different options for deploying the same contract logic. The best choice depends entirely on your app’s architecture and user experience goals.
This article will walk you through those options, and by the end, you’ll know which questions to ask yourself to choose the most suitable strategy for your project.

The Classic Way

This is the default and most familiar pattern. You deploy a smart contract to a Near account by sending a transaction with the DeployContract action, which includes the compiled WebAssembly code. The contract is deployed to the same account from which the transaction was sent. For example, deploying to contract.testnet means the code now lives and runs under that exact account.

A few key points to remember:

The contract code is stored directly in the account's state.
The account is charged for using the storage at the rate of 1 NEAR per 100 KB, so a 500 KB contract will lock 5 NEAR on that account.
This locked amount is not spent — it can be recovered by deleting or replacing the contract with a smaller one.

This is important because if you deploy the same 500 KB contract to three accounts, each pays 5 NEAR for the storage — a total of 15 NEAR is locked just to hold the identical code. This redundancy is what Global Contracts aim to eliminate.

Global Contracts

Global Contracts are reusable, globally-accessible smart contracts. Instead of every user or app deploying its own copy, a Global Contract is deployed once and then referenced by many accounts.

There are two types of Global Contracts:

a. By Hash - An immutable contract is deployed globally and identified by its code hash.

b. By Account ID - An upgradable contract is published globally under a specific account ID.

Global Contracts work through two new transaction actions: DeployGlobalContract and UseGlobalContract. First, a developer deploys a smart contract by sending a transaction with the DeployGlobalContract action, which contains the compiled WebAssembly code and makes it available either by its code hash or by a specific account ID. This is a one-time, global publication — the contract doesn’t run under the sender’s account, but instead becomes available for others to reference.

To use that contract, another user or application sends a transaction with the UseGlobalContract action, referencing the Global Contract either by code hash, or account ID.

The contract code is distributed across all shards in the Near Protocol network, not stored inside any specific account’s storage.
The account is charged 10x more for deploying a Global Contract, at the rate 10 NEAR per 100KB.
This amount is entirely burnt and cannot be recovered later, unlike regular deployments where Near is simply locked.
It costs almost nothing for a user to UseGlobalContract as there're only a few bytes for the reference that are stored in the account's storage, the total fee is typically under 0.001 NEAR.

You Can Use Both on One Account

There’s nothing stopping you from deploying both a regular contract and a Global Contract by Account ID on the same Near account. Let's say Contract A is deployed as a Global Contract, and Contract B is a traditional contract on the same account. They coexist independently. The order of deployment also doesn’t matter.

How to Choose the Right Strategy

Ask yourself the following essential questions before deciding how to deploy your contracts:

Are you working in a local environment?
If you're just testing or building a prototype, regular deployments are simpler and more flexible. There's no need to burn tokens or register global references — just deploy and iterate.
Is the contract supposed to be deployed on many accounts?
If the same contract will be reused across many independent accounts — say, 10 or more — Global Contracts can significantly reduce overall cost and complexity. But if only a few accounts are involved, regular deployment remains the more economical choice.
Are these accounts managed by your team?
If all target accounts are under your infrastructure, you may prefer regular deployments for flexibility and cost recovery.
3.1 Are there more than 10 accounts?
Global Contracts become financially efficient when reused at scale. If you're deploying the same contract to more than 10 accounts, it's likely worth considering.
3.2 Do you need to upgrade the contract across many accounts in one step, even if it requires burning tokens?
If you want to be able to push updates to all deployed instances at once, then go with Global Contracts by Account ID, but keep in mind that the deployment cost is non-refundable.
Does your use case require the contract to be permanently immutable?
If the contract must never change, for example, due to security, compliance, or user trust, then using a Global Contract by Code Hash ensures immutability at the protocol level.

Real-World Examples

To make this concrete, let’s look at several practical scenarios and how each maps to the right deployment strategy.

— Guestbook App

A minimal app that lets users leave public messages.
It uses just one contract deployed under the app’s own account, with no need for reuse, upgrades, or external deployments. Since this is an internal deployment in a local environment, regular deployment is the simplest and most appropriate option.

— DeFi Protocol with On-Chain Oracles

An infrastructure-heavy application with multiple smart contracts handling liquidity, pricing, and execution.
All contracts are deployed and maintained by the core team, and only used within the project’s ecosystem. Since the number of deployments is limited, upgradability is needed, and storage costs should be recoverable, the best fit is regular deployment.
However, if the protocol deploys a large number of identical oracle contracts and wants the ability to upgrade them all centrally, it may be more efficient to use a Global Contract with reference by Account ID.

— DAO Factory

A tool that allows any user to deploy their own DAO governance instance.
The same contract is deployed many times by end users across different accounts. This clearly meets the threshold where Global Contracts become financially efficient. Since upgradeability may be useful down the line (e.g. to patch bugs or extend functionality), the right choice is Global Contract by Account ID.

— NFT Collection Factory

A service that lets users create their own NFT contracts with fixed metadata and royalty.
Each user deploys the same contract, but once deployed, it should never be changed — security and immutability are critical here. This makes Global Contract by Hash the best match.

Thanks for reading. I hope this helped clarify when and why to use Global Contracts on Near. If it did — share it, comment, and let others in the ecosystem know.

Everything You Should Know about Accounts on Near

Den — Sun, 29 Jun 2025 16:39:00 +0000

I’ve gathered all the key information about Near accounts in one place, so you don’t have to spend time digging through scattered resources to understand how they work.

In this article, we’re going to break down how accounts on Near work. We’ll cover:

The different types of accounts
What makes up a Near account under the hood
Unique features like sub-accounts, account deletion, and Ethereum compatibility

By the end, you’ll have a clear, complete picture of Near's account model and how to confidently use it in your projects

What Makes Up a Near Account

Here’s what you need to know first.

Every Near account has a total balance, which consists of two parts:

Available Balance: This is the balance you can use freely at any time to pay transaction fees, transfer tokens, stake, or perform other operations.
Locked Balance: These are tokens that are currently staked to a validator, whether you’re staking to your own validator or someone else’s. Locked funds don’t unlock instantly - it takes a little time, typically 4 epochs (20 hours).

Contracts

A smart contract is a WebAssembly (WASM) program that can be deployed to an account. When you first create an account, it doesn’t have a contract by default. What makes NEAR flexible is that you can deploy, update, and even remove contracts from an account later. This means you can fully upgrade the code over time, something that’s not always possible on other blockchains. Once deployed, your contract can be called by anyone, and it has access to the account’s storage.

Storage

Every NEAR account has its own persistent storage, built as a key-value store. It can only be read and modified by the contract deployed on that same account, other contracts can’t directly access your storage, neither for read nor for write.

The data stored on your account is publicly visible. Anyone can read it through RPC calls — just something to keep in mind.

Storage on Near isn’t free. There’s a storage staking rule - you must hold 1 NEAR per 100 KB of storage used. This covers the account itself, contract code, stored data, and access keys.

The cool thing is, when you delete data from your storage, the NEAR tokens tied to that storage are automatically released back to your available balance. So you’re not permanently spending tokens, you’re simply locking them as long as you use the storage.

Access Keys

This is one of Near's most unique features. Unlike many blockchains where each account is tied to a single key, Near accounts can have multiple keys at the same time, each with its own permissions.

There are two types of access keys:

Full Access: Gives complete control over the account.
Function Call: Can only be used to call specific contract methods, usually with limited permissions. This key can only call non-payable methods—methods that don’t require a deposit. If you try to use it for a payable method, the transaction will simply fail.

Accounts can have as many keys as you like, you can add/remove them anytime. You can even remove all keys from an account, which effectively locks it. Once locked, the account can’t perform any actions anymore, unless the smart contract deployed on it was specifically designed to handle interactions without relying on access keys (you’ll see an example of this later in the article when we talk about the Wallet Contract).

Types of Accounts

On Near, not all accounts are the same — there are a few distinct types, each with its own purpose and behavior. But before we dive into the details, let’s quickly look at the general rules that apply to all accounts.

Every account, no matter the type, follows a simple set of naming rules:

Length: Account names must be at least 2 characters long and can go up to 64 characters.
Allowed characters: You can use lowercase letters (a-z), digits (0-9), and separators, including dots (.), dashes (-) and underscores (_).
Separator Rules
- An account name can’t start or end with a separator - no _alice. or .bob.near-.
- Separators can’t follow each other - no .., --, __, or mixed combinations like .- or _..

john.doe.near, root, or user_123.near are valid account names.

Named Accounts

As the name suggests, named accounts come with a human-readable name, which makes life on Near a lot easier, especially when it comes to branding and user experience. You don’t have to memorize long, random strings of characters anymore.

Creating a named account is simple, but not entirely free. You need to send a transaction to register the account on the blockchain. If you choose, you can also send some NEAR tokens along with the transaction to pre-fund the account. Like any transaction on Near, you need to cover the network fee. The good news is, fees on Near are low, especially compared to other blockchains. In fact, some wallets or applications might even cover this fee for you using a relayer (a service that pays the transaction fee on your behalf). That said, not every wallet offers this, so in many cases, you’ll still need to pay this small fee yourself.

Sub-Accounts

You’ve probably noticed examples like child.user.near and might be wondering - can anyone create that account? Actually, no. Near uses a hierarchical account structure and accounts are separated by dots to indicate their level. For example, only user.near can create child.user.near, and if you try to create child.user.near directly, your transaction will simply fail. The account user.near must send the transaction to itself to create child.user.near. No one else can do it.

Here's an important nuance - once a sub-account is created, it's fully independent. It has its own access keys, assets, etc. It doesn't belong to the parent account in any operational sense. The only thing the parent controls is the ability to create the sub-account in the first place. After that, the two accounts are completely separate.

If only user.near can create child.user.near, who created user.near?

If you said near, that’s exactly right. This brings us to the next section.

Top-Level Accounts

The near part isn’t just a label, it’s actually an account itself. In fact, it’s a special type of account called a top-level Account.

Top-level accounts on Near are, in many ways, just like the named accounts we’ve already discussed. The key difference is that you can’t create a top-level account yourself.

These accounts are predefined at the protocol level. They usually don’t have any Full Access keys attached, which means they can’t be deleted, and they technically belong to no one. They simply exist.

What makes top-level accounts so useful is that they can also have a smart contract deployed on them, and in most cases, they do. For example, the near account has a contract deployed on it that exposes the create_account method. Anyone can call it to create sub-accounts under the top-level account, which are the regular named accounts like user.near. It’s as simple as that.

You can check out the smart contract source code right here. Though, this contract does more than just create accounts, it’s actually a broader tool with additional functionality called Linkdrop. But we won’t dive into those details in this article.

It’s also worth noting that near isn’t the only top-level account. For example, the tg top-level account was introduced at the beginning of 2024 to support the HERE Wallet on Telegram. They needed a dedicated top-level account because their use case required a custom smart contract deployed specifically to handle batch account creation and other custom features.

I don’t know the exact requirements for getting a custom top-level account, but I guess that if your use case ever grows to the point where supporting millions of users would truly benefit from having a dedicated top-level account, there’s a chance you could request one.

Implicit Accounts

Implicit accounts on Near work a little differently from the named accounts we’ve talked about so far. You won’t find a human-readable name here. Instead, the account ID is simply the hexadecimal representation of a public key.

The public key generated from Ed25519 is exactly 32 bytes long, and when you convert it to a hexadecimal string, you get a 64-character account ID.

You don’t need to send any transaction or pay any deposit to create an implicit account. You can generate it completely off-chain by simply creating a key pair and calculating the hex representation of the public key. That’s it. You can start using the address right away.

When you first generate an implicit account, Near Protocol knows nothing about it yet. It officially comes into existence the moment someone sends NEAR. At that moment, the blockchain registers the account with the exact public key you originally generated. This makes implicit accounts perfect for lightweight onboarding. You can start using the blockchain right away — no need to sign any transactions, no need to pay upfront fees. You simply generate a key pair and you’re good to go. If possible, you’re recommended to upgrade to a named account later.

Also, it’s important to note that implicit accounts can’t have sub-accounts. Their account ID is already 64 characters long (the maximum allowed on Near), so there’s simply no room to add anything else.

Simple Example

Imagine someone wants to send you USDT on Near, but you don’t have an account yet.
With a named account, you’d first need to register it by sending a transaction, which costs a small fee. If you skip this step and give them a name like user.near that hasn’t been created yet, you’re putting the funds at risk.
Why? Because anyone can create a named account that doesn’t exist yet. If you delay, someone else could create that same account before you and take the funds.

But with implicit accounts, it’s different.
When you generate an implicit account, the account address is derived from your public key.
The only way someone else could take over that account is by generating the exact same key pair, which is practically impossible.

Ethereum Accounts

Ethereum accounts on Near use the same familiar address format you’ll see in native EVM networks - a 20-byte hexadecimal string. If you’ve worked with Ethereum before, this format will feel instantly familiar.

These accounts were introduced to support smooth integration with Ethereum tools, especially wallets. The goal is to let users sign transactions using their Ethereum keys and execute them directly on Near.

When you create an Ethereum account on Near, a special Wallet Contract is automatically deployed on it. One of its core methods is rlp_execute(target: AccountId, tx_bytes_b64: Vec<u8>). This function takes an Ethereum transaction, verifies the signature using your Ethereum key, checks the nonce to ensure the transaction is in the correct order, and then executes it directly on Near.

It’s worth noting that Ethereum accounts on Near have limited capabilities, you can transfer NEAR tokens, call functions on other smart contracts, and add or delete FunctionCall keys, but you cannot add Full Access keys or delete the account.

Deleting Accounts

We’ve talked about how accounts can be created, but here’s something that makes Near stand out compared to many other blockchains - accounts on Near can also be fully deleted, and even recreated later, as many times as you need. This is not something you usually see on other chains, where account addresses are typically permanent.

Account deletion is done via a special transaction, and when you delete an account, its remaining available Near balance is automatically transferred to a beneficiary account of your choice. The account itself is completely removed from the blockchain’s state.

This feature gives you flexibility, but it also comes with a real risk of losing assets if you don’t handle the process carefully. When you delete an account, only the native NEAR tokens are automatically transferred. Any other assets like FTs, or NFTs, won't be transferred automatically. If you forget to move those assets before deletion, you will lose them permanently.

If you spot anything incorrect or notice something important I missed, please feel free to correct me or add your thoughts in the comments. I’d appreciate it!

Otherwise, I hope this article helped you build a clear, practical understanding of Near accounts and gave you the confidence to work with them without second-guessing.
Thanks for reading and have a great day!

The Smoothest Cross-Chain Integration I’ve Ever Built

Den — Sun, 22 Jun 2025 15:54:00 +0000

I used to think cross-chain swaps were one of the most complicated things in crypto.

Every time I looked into them, I’d feel that familiar hesitation — too many moving parts, too many edge cases, and way too much waiting around.

I believe that integrating them was always a pain in the ass. From juggling wallets and gas on multiple chains to writing spaghetti code to handle every possible failure, it felt like duct-taping over a fragmented system.

Then, about a year ago, I came across an idea that completely changed how I looked at cross-chain swaps.

What if the swap didn’t have to leave the chain?
What if you could make it happen from one place, atomically and as easily as updating a field in a smart contract?

And recently, I finally found a system that makes it real. It’s called NEAR Intents — and on top of that, they’ve just released something called the 1Click API, which blew me away.

What are Near Intents?

NEAR Intents is a multi-chain transaction protocol designed for peer-to-peer exchanges of any kind of resource, whether that’s tokens, NFTs, or even access rights to services or data. In other words, it enables people to trade whatever holds value to them.

The protocol is made up of three main components:

Solvers (or Market Makers)
These are automated agents that participate in the exchange process. Their job is to fulfill user requests by offering the resources the user wants, in return for whatever the user is offering. Solvers compete with one another to provide the best terms. If one solver offers a worse deal, another one can step in with a better one, effectively outbidding them. This competition ensures users always get the most favorable rate. Solvers earn a small fee from each successful trade, which motivates them to stay competitive and keep the system running efficiently.
Verifier Smart Contract
This contract runs on the NEAR Protocol and plays a key role in the system. It ensures that each trade is executed atomically, meaning it either happens in full or not at all, and it verifies the integrity of the transaction. We’ll dig into how exactly this verification works a bit later when we walk through an example.
Applications (or Distribution Channels)
These are the frontends or interfaces that users interact with (wallets, dApps, exchanges, or any other service that connects to the protocol). While technically optional, since it's peer-to-peer and users could interact with the protocol directly, in practice, most people use apps or wallets to make the experience smoother and more intuitive.

How does the Cross-Chain part work?

Right now, the main use case for Near Intents is peer-to-peer money transfers, swapping tokens across different networks. But how does Near make cross-chain swaps possible?

That’s where Omni Bridge comes in. It’s a core service within the Near ecosystem that allows assets to move between blockchains. Here’s how it works: when a user wants to bridge tokens to Near, they burn the tokens on the source chain and generate a proof of that burn. This proof is then submitted to Near, where it’s verified by the Near Light Client. And once the proof checks out, the Near side mints the equivalent amount of corresponding tokens (NEP‑141) and credits them to the user’s account.

Walkthrough with Alice

Let’s walk through how someone, say, Alice, would use Near Intents to swap 100 USDT on Ethereum for BTC on the Bitcoin network.

You can find another TypeScript example here.

Step 1: Deposit to Near

As described earlier, Alice starts by burning her USDT tokens on Ethereum. She then sends the proof of that burn to Near. Once the proof is verified, she receives a bridged version of USDT, minted directly to her address on the Near Protocol.

Step 2: Get a Quote

Alice queries a JSON RPC endpoint for swap quotes, specifying that she wants to swap 100 USDT and receive BTC in return.

Under the hood, this triggers a short bidding window, about 1 second, where all available solvers receive Alice’s request. Each solver checks if they can fulfill the trade and, if so, responds with a quote. These responses include how much BTC they can offer and until what time.

Here’s what the request body for querying a quote looks like:

{
    "id": "dontcare",
    "jsonrpc": "2.0",
    "method": "quote",
    "params": [
        {
            "defuse_asset_identifier_in": "nep141:eth-0xdac17f958d2ee523a2206206994597c13d831ec7.omft.near", // bridged USDT
            "defuse_asset_identifier_out": "nep141:btc.omft.near", // bridged BTC
            "exact_amount_in": "100000000" // 100 USDT
        }
    ]
}

And below is an example of the response you’ll get back:

{
    "jsonrpc": "2.0",
    "id": "dontcare",
    "result": [
        {
            "defuse_asset_identifier_in": "nep141:eth-0xdac17f958d2ee523a2206206994597c13d831ec7.omft.near",
            "defuse_asset_identifier_out": "nep141:btc.omft.near",
            "amount_in": "100000000", // 100 USDT
            "amount_out": "99999", // 0.00099999 BTC
            "expiration_time": "2025-06-15T09:42:42.294Z",
            "quote_hash": "2EKjNj2fYe73tbRJegHoeetNCc2oAb2kiFPpVs6VK54P"
        },
        {
            "defuse_asset_identifier_in": "nep141:eth-0xdac17f958d2ee523a2206206994597c13d831ec7.omft.near",
            "defuse_asset_identifier_out": "nep141:btc.omft.near",
            "amount_in": "100000000", // 100 USDT
            "amount_out": "100000", // 0.001 BTC
            "expiration_time": "2025-06-15T09:42:42.424Z",
            "quote_hash": "JAvGrCio97STdSX5P52Xo1WpBur3S8LKmoDRzQtJijEw"
        }
    ]
}

From the list of available quotes, she picks the one she likes best.

Step 3: Create and Sign an Intent

Now that Alice is happy with the quote, she creates an intent - a message saying, "I’m willing to give 100 USDT to receive 0.001 BTC".

Here’s what the intent message looks like:

const message = {
    signer_id: "alice.near",
    deadline: "2025-06-15T09:42:42.424Z",
    intents: [
        {
            intent: "token_diff",
            diff: {
                "nep141:eth-0xdac17f958d2ee523a2206206994597c13d831ec7.omft.near": "-100000000",
                "nep141:btc.omft.near": "1000000",
            },
        },
    ],
};

Notice that the USDT amount is negative, which indicates the amount being sent in the swap.

After the intent is created, we also need to generate a random 32-byte nonce, serialize all the data, and produce an ED25519 signature. It's worth noting here that the intent must be signed with a key that has already been registered on the Verifier Smart Contract. This allows the contract to verify both the validity of the signature and that the key belongs to your account.

Step 4: Submit the Intent

Alice submits the signed intent back to the RPC server. Solvers also sign their part, confirming that they’ll deliver the requested asset.

The request should follow this specific format:

{
    "jsonrpc": "2.0",
    "id": "dontcare",
    "method": "publish_intent",
    "params": [
        {
            "quote_hashes": ["JAvGrCio97STdSX5P52Xo1WpBur3S8LKmoDRzQtJijEw"],
            "signed_data": {
                "standard": "nep413",
                "payload": {
                    "message": "{\"deadline\":\"2025-06-15T09:42:42.424Z\",\"intents\":[{\"intent\":\"token_diff\",\"diff\":{\"nep141:eth-0xdac17f958d2ee523a2206206994597c13d831ec7.omft.near\":\"-100000000\",\"nep141:btc.omft.near\":\"1000000\"},\"signer_id\":\"alice.near\"}", // serialized intent message
                    "nonce": "D4DFuiyOSjNmYcmu/Rqkx/Q624mBnzk9WhnYdqUz0ek=", // random 32 bytes represented as base64 string
                    "recipient": "intents.near" // verifier smart contract
                },
                "signature": "ed25519:24nL3P37o27uCdsfyFqtCBEPuEgiu90AfaJSJSPpEE8vCAyYZTtgbBEyF7nkZ69nJwqReimDaU4n33zrSwziXiG1",
                "public_key": "ed25519:33fZjXn7DmM2XrAxZWK5XE6EnZugAusMtkKM9Zbb3P4J"
            }
        }
    ]
}

In response, we’ll receive a JSON object that includes an intent_hash, which can later be used to check the status of the execution.

{
    "jsonrpc": "2.0",
    "id": "dontcare",
    "result": {
        "status": "OK",
        "intent_hash": "9TBktE2kKuN0XHueyHwsJNQWY4EW73KMDkx9FizWJcsB"
    }
}

Once an intent is published to the RPC, the system builds a composite object that includes all the intents involved in the deal (it doesn't necessarily have to be just two parties, any number of participants are supported in a single agreement).

After all intents are signed by their respective participants, they’re bundled and sent to the Verifier Smart Contract. That’s where the magic happens. The Verifier runs a method called execute_intent, which does:

It checks that each intent is signed with a public key that matches the one declared in the intent itself and that it's already registered with the Verifier contract (this ensures the intent was genuinely signed by the account it claims to come from)
Next, it verifies that the net asset flow across all intents equals zero.
For example, if Alice offers 100 USDT, then the combined intents of the other participants must result in someone receiving exactly 100 USDT. Same with BTC: if someone gives up 0.001 BTC, someone else must receive exactly that amount.
Once all checks pass, it simply updates token balances. Alice’s USDT balance decreases by 100, but she gains 0.001 BTC. Her counterparty’s balances shift in the opposite direction.

Step 5: Withdraw

Finally, Alice burns her bridged BTC tokens on Near and submits the proof. Just like during the deposit flow, once verified, she receives native BTC on the Bitcoin network.

Making It Seamless with 1Click API

Now, let’s be real. That was a lot of steps. Even if Near Intents is cleaner than most cross-chain protocols, it still requires a solid grasp of knowledge about bridges, contracts, and signatures.

This is exactly why 1Click API exists.

What is 1Click API?

1Click API wraps everything, from quoting to execution, into a single API call. You just tell it what you want to send, what you want to receive, and where it should go. Done.

The magic of 1Click lies in how little you have to do to make this happen. You simply have to make a POST request to the /quote endpoint. In that request, you describe what asset they are sending and of what amount, what asset they want to receive, and where it should go and how refunds should be handled if anything fails.

Walkthrough with Alice again

To show how seamless this is, let’s go back to the example we explored earlier, of Alice swapping 100 USDT on Ethereum for BTC on Bitcoin, and walk through how it works using the 1Click API.

You can find more TypeScript examples for various 1Click API use cases here.

Step 1: Get a Quote

Alice makes a POST /quote request with the details.

Let’s walk through each important field to understand what it means and why we’re using those specific values.

The complete and latest 1Click API spec is available here.

depositType is set to ORIGIN_CHAIN, because the funds originate outside of NEAR, we’re telling the API to expect the deposit on the origin chain
originAsset is set to nep141:eth-0xdac17f958d2ee523a2206206994597c13d831ec7.omft.near, which is the address of the NEAR-bridged token that mirrors USDT on Ethereum
destinationAsset is set to nep141:btc.omft.near, same logic as above
amount is the number of USDT tokens Alice wants to send. It's passed over as units, for USDT with 6 decimals, it equals 100000000
recipientType is set to ORIGIN_CHAIN and recipient is Alice's Bitcoin wallet address
refundType is set to ORIGIN_CHAIN and refundTo is Alice's Ethereum wallet address. These parameters define where the funds should go if something goes wrong. It’s important to provide an address you own. If the refund address is incorrect, Alice could permanently lose access to the funds.

Here’s what the request would look like:

{
    "dry": false,
    "swapType": "EXACT_INPUT",
    "slippageTolerance": 10, // 0.1%
    "depositType": "ORIGIN_CHAIN", // expects a deposit on Ethereum
    "originAsset": "nep141:eth-0xdac17f958d2ee523a2206206994597c13d831ec7.omft.near", // bridged USDT
    "destinationAsset": "nep141:btc.omft.near", // bridged BTC
    "amount": "100000000", // 100 USDT
    "recipient": "bc1q3pqz07f0t48lrxunyqqx4yk3f9gr65nfxncc0r", // your Bitcoin wallet
    "recipientType": "ORIGIN_CHAIN", // withdraws on Bitcoin
    "refundTo": "0x427F9620Be0fe8Db2d840E2b6145D1CF2975bcaD",
    "refundType": "ORIGIN_CHAIN",
    "deadline": "2025-06-15T17:21:37.194Z"
}

Step 2: Make the Deposit

Now that we have the deposit address, Alice can send her 100 USDT to it on Ethereum. This transaction is what actually kicks off the swap.

Let’s use viem to send USDT:

import { erc20Abi } from "viem";
import { createWalletClient, http } from "viem";
import { mainnet } from "viem/chains";

const walletClient = createWalletClient({
    chain: mainnet,
    transport: http(), // use injected transport in a browser wallet
});

const depositAddress = response.quote.depositAddress;

const txHash = await walletClient.writeContract({
    account: "0x427F9620Be0fe8Db2d840E2b6145D1CF2975bcaD", // your address
    address: "0xdAC17F958D2ee523a2206206994597C13D831ec7", // USDT token address
    abi: erc20Abi,
    functionName: "transfer",
    args: [
        depositAddress,
        100000000, // 100 USDT
    ],
});

After that, the 1Click begins monitoring for the transaction’s finalization.

And that’s it! Once the transaction is fully finalized on the Bitcoin network, Alice will see her updated BTC balance in her wallet.

Was that simple enough? Feel free to share your thoughts in the comments. And if you have any technical questions about the process, don’t hesitate to ask — I’ll be happy to help.

Thanks for reading and have a great day!