Skip to main content

Deep Dive into NEAR Intents

· 13 min read
denbite
denbite
DevRel

Let's take a deep dive into the architecture of cross-chain swaps on NEAR Protocol, exploring how NEAR Intents and the PoA Bridge work together to enable secure and efficient asset transfers across blockchains.

Introduction​

Given the bast amount of chains and assets that have surged, it is now common for users to need to swap assets across chains (e.g. swap USDT on Ethereum for SOL on Solana).

Since each blockchain is a separate and isolated system - indeed, blockchains do not have any inherent way to communicate with each other - different off-chain services emerged to enable cross-chain swaps.

Today, I want to take a deep dive into the technical foundations on how cross-chain swaps work on NEAR Protocol, and understand which features of the protocol enabled it to be robust and secure.

But before, let's briefly review how cross-chain swaps have traditionally worked, and what challenged they faced, to better understand why NEAR's approach is unique and powerful.

The problem with cross-chain swaps​

Let's take a simple example: you want to swap 100 USDT on Ethereum for some amount of native Solana tokens. There are two main approaches to achieve this:

1. Bridge, then swap​

You send 100 USDT from your Ethereum account to a Solana wallet that you control using a multi-chain bridge. Once the funds arrive, you go to any swap in Solana to convert your USDT into SOL.

The main point of trust here is in the bridge itself. You need to trust that the bridged assets will arrive in the target chain, and that the bridge is secure enough to prevent theft or loss of funds.

2. Use a Counterparty​

Instead of bridging the tokens, you find a counterparty who already has SOL and wants USDT on Ethereum. You agree on a swap rate, send them your 100 USDT on Ethereum, and they send you SOL tokens to your Solana wallet in return.

From a user's perspective this can feel faster, but it immediately raises a security question: how do you make this operation atomic? You do not want to send your USDT and never receive SOL, and the counterparty does not want to send SOL without a guarantee that they will receive your USDT.

Achieving atomicity across multiple blockchains is extremely difficult because each chain has its own execution model, timing, and finality.

The best of both worlds​

NEAR combines both bridge and counterpart approaches into a single, seamless experience that leverages the strengths of each while mitigating their weaknesses.

For this, NEAR relies on two key components:

  1. The PoA Bridge, a bridge built by Defuse Labs (the team behind NEAR Intents) that moves assets from and to NEAR via a treasury-based model
  2. NEAR Intents, that finds a counterparty and executes the swap atomically on NEAR

For the user, the experience is simple and intuitive:

  1. Tell NEAR Intents that you want to swap 100 USDT from Ethereum and receive SOL on a specific Solana address (that you control)
  2. NEAR Intents finds a counterparty who is willing to take the opposite side of the swap, and gives you a quote
  3. If you agree to the quote, NEAR Intents provides you with an address on Ethereum where to send your 100 USDT
  4. Once you send the funds on Ethereum, you get the SOL tokens on Solana

Behind this simple user experience, there is a complex architecture that makes it all possible. The key to understanding it is to look at the technical foundations that NEAR Protocol provides, and how they enable this design in a way that is secure, efficient, and user-friendly.

Technical Foundations​

The core technical foundation that makes all of this possible is the combination of chain signatures (multi-party computation), the protocol's ability to handle true asynchronous execution, the yield and resume mechanism of smart contracts to handle long-lived flows without excessive costs, and callback-based token standards.

Chain Signatures​

Chain Signatures allows smart contracts to sign transactions for NEAR and other chains in a secure and deterministic way. It is based on multi-party computation (MPC), where a group of participants collectively generates a signature without any single party ever owning the full private key.

While MCP is a powerful primitive that exists on other chains, in NEAR it is naturally integrated into the on-chain execution thanks to the fact that smart contracts can yield and resume computation.

Yield and Resume​

Signature generation is not instantaneous, it is an interactive process that takes time and unfolds over multiple blocks. On NEAR, this is not an issue, because smart contracts can yield and resume computation. This is, they can pause their execution, wait for an external event (like a signature being ready), and then continue from where they left off once the event occurs.

Another advantage of yielding and resuming is that contracts do not pay gas while they are waiting, which makes it economically viable to wait for signatures that can take maybe seconds to be generated, without worrying about the cost of keeping the contract alive during that time.

Asynchronous Execution​

It is important to remark that, contracts can yield and resume computation without blocking the blockchain or even themselves! Indeed, thanks to the asynchronous nature of NEAR, contracts can have multiple flows in flight at the same time, each waiting for different signatures or events, and the chain can process them all in parallel without any bottlenecks.

Mature Token Standards​

NEAR Intents builds on NEP-245 (analogue of ERC-1155 on Ethereum). This Multi-Token standard allows a single contract to manage balances for many different tokens, instead of deploying a separate contract per asset. This significantly simplifies intent execution - swaps can involve multiple assets, partial fills can be aggregated, and state can be tracked in one place without unnecessary cross-contract calls.

Overview of the swap flow​

Now that we have covered the technical foundations, let's see how they come together in practice to enable a cross-chain swap. We will use the example of swapping 100 USDT from Ethereum for some amount of SOL on Solana, but the same principles apply to any other asset and chain supported by NEAR Intents.

1-Click API

In this post, we will explain in detail the manual process of using intents, for production apps the 1-Click API abstracts away all the complexity and allows you to execute the entire flow with a single API call. You can read more about it in the docs.

Step 1: Deposit funds from Ethereum to NEAR​

Since we want to make a cross-chain swap, the first step that we need to perform is deposit the funds in NEAR Intents. For this, the user can call the get_address endpoint in the NEAR Intents API, which will return a native Ethereum address into which the user can send their USDT.

Where does this deposit address come from?

Chain Signatures allow NEAR to deterministically derive ECDSA keys (and EDDSA) that can sign arbitrary payloads. Ethereum uses ECDSA keys, for which NEAR Intents can get a unique key and derive a valid Ethereum address from it.

Starting the Swap​

From the user's point of view, the action is simple - they send their USDT to this Ethereum address. Once the transaction is included and finalized on Ethereum, the deposit is automatically detected by the PoA Bridge.

The PoA Bridge then instructs the corresponding token contract on NEAR to mint the bridged tokens. For USDT, this is the eth-0xdac17f958d2ee523a2206206994597c13d831ec7.omft.near contract, which mints the same amount that was deposited on Ethereum.

These newly minted tokens are then transferred directly to the NEAR Intents contract at intents.near. As a result, the bridged tokens end up in the intents.near contract.

What happens to the funds sent to the deposit address?​

Since the address was controlled via Chain Signatures, NEAR Intents can generate valid transactions to move funds out of them. After the deposit is finalized, the funds are automatically transferred into a shared treasury address for that chain.

There is one treasury per supported chain, and all deposits are consolidated there.

Step 2: Executing the swap inside NEAR Intents​

Once the funds are available on NEAR, the actual exchange happens inside the NEAR Intents contract. At a high level, this contract exists for one reason - to make intent-based operations verifiable and atomic. Every intent-based swap ultimately goes through this contract, and nothing is executed unless it passes all of its checks.

Before any swap can happen, the user must register a public key with the intents.near contract. This key will later be used to sign intents and is stored on-chain so the contract can verify that future intents are authorized. It can be registered either by calling the contract directly, or by submitting a dedicated add_public_key intent via the Solver Bus API.

Once the key is registered, the swap flow becomes straightforward. In our case, the user now holds bridged USDT on NEAR eth-0xdac17f958d2ee523a2206206994597c13d831ec7.omft.near, which represents USDT originally deposited from Ethereum. The user wants to swap this USDT for SOL, represented on NEAR as sol.omft.near, which is the bridged representation of native SOL.

The first step is requesting a quote. The user calls the Solver Bus API and specifies either:

  • Exact amount in: "I am willing to spend 100 USDT, how much SOL can I get?", or

  • Exact amount out: "I want to receive 1 SOL, how much USDT do I need to spend?"

The Solver Bus queries active solvers and within a few seconds returns one or more quotes, each quote represents a solver's willingness to take the opposite side of the trade. If the user is satisfied with the offer provided by the solver, they can sign a token swap intent (i.e. a TokenDiff intent) and send it to the Solver Bus for execution along with the solver's quote hash(es) using publish_intent method.

From there, user's signed intent is being aggregated with others to form a single execution batch, and then it's relayed to the Intents contract for execution. As a result, the API returns a hash that can be used to track the execution status.

Step 3: Withdrawing funds from NEAR to Solana​

The final step is moving the result of the swap out of NEAR and into Solana, which - just as the swap - is driven by intents.

To start the withdrawal, a user creates the FtWithdraw intent, that is signed with the same registered public key and includes a memo field that specifies the destination account. Because in our case the token being withdrawn is sol.omft.near, it's clear that the destination address must be a Solana address (since sol.omft.near represents bridged SOL tokens).

The signed intent is submitted to the Solver Bus API and then is relayed to intents.near contract for execution. Its execution triggers a cross-contract call to the token contract itself, in this case, sol.omft.near. Concretely, the intents.near contract makes a cross-contract call to ft_transfer method on sol.omft.near, transferring the tokens to the token contract itself. For this contract, such a transfer is interpreted as a burn operation. As a result, the specified amount of tokens is burned, and a corresponding on-chain event is emitted.

This burn event is automatically detected by the NEAR Intents infrastructure. A cryptographic proof is generated that confirms the tokens were indeed burned on NEAR. Once this proof is available, using Chain Signatures, NEAR Intents constructs and signs a transaction that transfers the real assets from the Solana-side treasury directly to the destination address specified in the intent. The transfer is executed on Solana, completing the withdrawal.

Further Exploration​

If you're interested in integrating cross-chain swaps into your own service, the recommended entry point is the 1Click API. It provides a single, high-level interface that executes the entire flow described above — deposit, swap, and withdrawal — with one request. In practice, this acts as a thin abstraction over NEAR Intents and the PoA Bridge and removes the need to manually orchestrate each step.

To see the flow end to end from a user perspective, the main NEAR Intents UI is a good place to start. It walks through the same stages described in this article, but through an interactive interface, which helps build intuition.

If you want to understand how NEAR Intents works in a concrete implementation, there is example repository that demonstrate how the system is wired together in practice. It's useful when you want to trace real requests, intent construction, and execution paths.

Finally, the full technical documentation lives at docs.near-intents.org. It covers the protocol concepts, APIs, intent types, solver interaction, and integration details in depth, and is the best reference when you want to go deeper or build something on top of NEAR Intents.