From a7860556fc42814b9b79798b81a0fa933d9e9570 Mon Sep 17 00:00:00 2001 From: denbite Date: Tue, 3 Feb 2026 21:07:58 +0100 Subject: [PATCH 1/4] feat: add blog post about architecture of NEAR Intents --- blog/2026-01-24.md | 120 +++++++++++++++++++++++++++++++++++++++++++++ blog/authors.yml | 8 +++ 2 files changed, 128 insertions(+) create mode 100644 blog/2026-01-24.md diff --git a/blog/2026-01-24.md b/blog/2026-01-24.md new file mode 100644 index 00000000000..274d0216b63 --- /dev/null +++ b/blog/2026-01-24.md @@ -0,0 +1,120 @@ +--- +title: "NEAR Intents: Inside the Architecture of Cross-Chain Swaps" +authors: [denbite] +slug: near-intents-2026 +tags: [articles] +--- + +Cross-chain swaps aren't a new idea. They have existed in the blockchain ecosystem for several years already. By definition, a cross-chain swap usually combines two things: bridging assets from one blockchain to another, and exchanging them along the way. + +Today, I want to talk about how this kind of technology is built on the NEAR Protocol. More specifically, I want to walk through the combination of two components: a relatively new product called NEAR Intents, which enables intent-based swaps, and the trustless Omni Bridge, which handles cross-chain asset transfers. + +The focus of this article is not the user-facing experience, but the technical foundations behind it. We will look at which features of NEAR Protocol make this architecture possible, and why they allow it to be built in a robust and secure way. We will go a bit deeper technically and break down how the system is structured, and what exactly made this design feasible in the first place. + +Bridges are an essential part of any cross-chain swap, but at the same time they are also its weakest point. Let's take a simple example: you want to swap 100 USDT on Ethereum for some amount of SOL on Solana. + +At a high level, there are two common ways to approach this. + +1. The first one is straightforward: you bridge 100 USDT from Ethereum to Solana, and then perform the swap directly on Solana. The obvious issue here is the bridge itself. Bridging assets between chains is complex, slow, and historically has been the source of many security incidents. + +2. The second approach avoids bridging altogether. Instead, you rely on counterparties who already have liquidity on Solana. They receive your 100 USDT on Ethereum and, in return, send you SOL on Solana. 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. + +This is where NEAR introduces an approach that effectively combines both models while avoiding their main drawbacks. Instead of bridging directly from Ethereum to Solana or relying on trust-based counterparties, assets first move into a neutral execution environment on NEAR Protocol. + +In practice, a swap from 100 USDT on Ethereum to SOL on Solana would work like this - the USDT is first deposited from Ethereum to NEAR using trustless Omni Bridge, once the assets are on NEAR, NEAR Intents handles the swap itself, and after the swap is completed and the target asset is obtained, it can then be withdrawn out from NEAR to Solana, again using trustless Omni Bridge. + +## The primitives this design relies on + +Before diving into the swap flow itself, it helps to understand the technical environment that makes this design possible. + +At first glance, none of the individual building blocks used here look impossible to imagine elsewhere. For example, [Chain Signatures](/chain-abstraction/chain-signatures) on their own are "just" multi-party computation, a group of participants collectively generates a signature without any single party ever owning the full private key. This is a powerful primitive, and in theory, MPC could exist on many blockchains. + +The question is not whether MPC is possible, but whether it can be used naturally as part of on-chain execution. + +Signature generation is not instantaneous, it's an interactive process that unfolds over time. On NEAR, this fits cleanly into the execution model, because the [protocol is asynchronous by design](/protocol/architecture). Contract execution can be split into multiple steps across blocks, without blocking the system or forcing everything to finish inside a single transaction. The chain can move forward while the signature is being assembled, and resume once it is ready. + +But even with asynchronous execution, another problem appears quickly - cost. Multi-step execution across blocks still consumes gas, and without special care, long-lived flows become expensive. This is where NEAR's [yield and resume](/smart-contracts/anatomy/yield-resume) mechanism becomes critical. It allows contract execution to pause and continue later without repeatedly paying for the same work. As a result, waiting for MPC signatures becomes economically viable, not just technically possible. + +Once signing across chains becomes reliable and affordable, token flows themselves need to support multi-step logic. This is where the design of a [NEP-141](https://github.com/near/NEPs/blob/master/neps/nep-0141.md) matters (analogue of ERC-20 on Ethereum), the Fungible Token standard is built around callback-based transfers. Using `ft_transfer_call`, a token transfer can hand off control to another contract, wait for a result, and then either finalize the transfer or revert it automatically. This makes it possible to build flows where assets either move all the way through the system or not at all. + +Finally, NEAR Intents builds on [NEP-245](https://github.com/near/NEPs/blob/master/neps/nep-0245.md) (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 + +With this context in mind, we can now walk through the swap itself. + +### Step 1: Deposit funds from Ethereum to NEAR + +Chain Signatures allow NEAR to deterministically derive public keys that can sign arbitrary payloads. Because Ethereum uses ECDSA keys, the same derivation can be used to produce a valid Ethereum public key, and from it - a regular Ethereum address. This address becomes a deposit address, deterministic and unique for each NEAR account. + +From the user's point of view, the action is simple - they send their tokens (in our case, USDT) to this Ethereum address. Once the transaction is included and finalized on Ethereum, it is detected and a cryptographic proof is generated that confirms the transfer really happened. + +This proof is then processed on NEAR Protocol by the Omni Bridge smart contract `omft.near`. Once verification succeeds, it makes a cross-contract call to the child smart contract that represents a bridged token (USDT, in our case, and the address will be `eth-0xdac17f958d2ee523a2206206994597c13d831ec7.omft.near`) to mint the same amount that was deposited on Ethereum. These newly minted tokens are then transferred directly to the NEAR Intents contract at `intents.near`. + +The NEAR Intents contract plays two important roles. First, it will later act as the verifier for intents, which we will cover in the next step. Second, it implements both the NEP-141 Fungible Token and the NEP-245 Multi-Token standards. The last one allows a single contract to manage balances of many different assets, which is exactly what NEAR Intents needs. + +As a result, the bridged tokens end up held by the `intents.near` contract, but its internal state records that they belong to your NEAR account. + +:::info +One natural question here is what happens to the funds sent to all those unique deposit addresses on Ethereum. They do not remain scattered forever. Because these addresses are controlled via Chain Signatures, NEAR Intents can generate valid transactions to move funds out of them. After a 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. + +#### What NEAR Intents contract does? + +The contract performs three core functions. + +1. First, it validates the format of intents. Each intent must follow a strict structure, otherwise the transaction is rejected immediately. + +2. Second, it verifies cryptographic signatures. Every intent is signed by a public key specified inside the intent itself - the contract checks that the signature is valid for the given payload. + +3. Third, it verifies key ownership. A valid signature alone is not enough, the public key used to sign the intent must have been previously registered in the contract's state. This guarantees that the user explicitly declared, ahead of time, which keys are allowed to sign intents on their behalf. + +Only if all three checks pass does the contract move forward. + +#### `TokenDiff` intents and balance matching + +The most important intent type for swaps is the `TokenDiff` intent. Conceptually, it expresses a simple idea - "I am willing to give up X of token A and receive Y of token B". + +For a swap to be valid, the contract must ensure that the sum of all token changes balances out. In practice, this means that if one intent declares “−X, +Y”, there must be one or more matching intents that declare “+X, −Y”. + +These matching intents typically come from solvers. A solver may fully satisfy a single intent, partially fill it, or participate as part of a longer chain where multiple intents and solvers connect different assets. As long as the net balance across all involved tokens sums to zero, the swap is considered valid and can be executed atomically. + +#### How this looks in practice + +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](https://docs.near-intents.org/near-intents/market-makers/bus/solver-relay). + +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 `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. Conceptually, this looks very similar to the deposit flow, just in the opposite direction, and it is still 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](https://docs.near-intents.org/near-intents/integration/distribution-channels/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 Omni 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](https://near-intents.org/) 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](https://github.com/near-examples/near-intents-examples) 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](https://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. diff --git a/blog/authors.yml b/blog/authors.yml index 2efbec14ca3..320e4fa85c9 100644 --- a/blog/authors.yml +++ b/blog/authors.yml @@ -67,3 +67,11 @@ matiasbenary: image_url: https://github.com/matiasbenary.png socials: github: matiasbenary + +denbite: + name: denbite + title: DevRel + url: https://github.com/denbite + image_url: https://github.com/denbite.png + socials: + github: denbite From 89d1505b52af34b5e5bf8b3a4d4bf29764f96e1b Mon Sep 17 00:00:00 2001 From: Guillermo Alejandro Gallardo Diez Date: Mon, 9 Feb 2026 17:08:32 +0100 Subject: [PATCH 2/4] fix: reviewed the blogpost --- blog/2026-01-24.md | 145 ++++++++++++++++++++++++++++++++------------- 1 file changed, 103 insertions(+), 42 deletions(-) diff --git a/blog/2026-01-24.md b/blog/2026-01-24.md index 274d0216b63..b8fdc9178bf 100644 --- a/blog/2026-01-24.md +++ b/blog/2026-01-24.md @@ -1,89 +1,150 @@ --- -title: "NEAR Intents: Inside the Architecture of Cross-Chain Swaps" +title: "Deep Dive into NEAR Intents" authors: [denbite] slug: near-intents-2026 tags: [articles] --- -Cross-chain swaps aren't a new idea. They have existed in the blockchain ecosystem for several years already. By definition, a cross-chain swap usually combines two things: bridging assets from one blockchain to another, and exchanging them along the way. +Let's take a deep dive into the architecture of cross-chain swaps on NEAR Protocol, exploring how NEAR Intents and Omni Bridge work together to enable secure and efficient asset transfers across blockchains. -Today, I want to talk about how this kind of technology is built on the NEAR Protocol. More specifically, I want to walk through the combination of two components: a relatively new product called NEAR Intents, which enables intent-based swaps, and the trustless Omni Bridge, which handles cross-chain asset transfers. + -The focus of this article is not the user-facing experience, but the technical foundations behind it. We will look at which features of NEAR Protocol make this architecture possible, and why they allow it to be built in a robust and secure way. We will go a bit deeper technically and break down how the system is structured, and what exactly made this design feasible in the first place. +--- + +## 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. Briefly, these services + +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. + +Furthermore, when using bridges you usually receive a wrapped version of the asset rather than the token itself, which means it might be difficult to swap the bridged asset for the native one if the bridge does not have enough liquidity on the target chain. + +#### 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. -Bridges are an essential part of any cross-chain swap, but at the same time they are also its weakest point. Let's take a simple example: you want to swap 100 USDT on Ethereum for some amount of SOL on Solana. +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`. -At a high level, there are two common ways to approach this. +Achieving atomicity across multiple blockchains is **extremely difficult** because each chain has its own execution model, timing, and finality. -1. The first one is straightforward: you bridge 100 USDT from Ethereum to Solana, and then perform the swap directly on Solana. The obvious issue here is the bridge itself. Bridging assets between chains is complex, slow, and historically has been the source of many security incidents. +--- + +## 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 Omni Bridge: a **trustless bridge** that securely moves assets from and to NEAR +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. + +--- -2. The second approach avoids bridging altogether. Instead, you rely on counterparties who already have liquidity on Solana. They receive your 100 USDT on Ethereum and, in return, send you SOL on Solana. 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. +## Technical Foundations -This is where NEAR introduces an approach that effectively combines both models while avoiding their main drawbacks. Instead of bridging directly from Ethereum to Solana or relying on trust-based counterparties, assets first move into a neutral execution environment on NEAR Protocol. +The core technical foundation that makes all of this possible is the combination of **on-chain 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**. -In practice, a swap from 100 USDT on Ethereum to SOL on Solana would work like this - the USDT is first deposited from Ethereum to NEAR using trustless Omni Bridge, once the assets are on NEAR, NEAR Intents handles the swap itself, and after the swap is completed and the target asset is obtained, it can then be withdrawn out from NEAR to Solana, again using trustless Omni Bridge. +### Chain Signatures +[Chain Signatures](/chain-abstraction/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. -## The primitives this design relies on +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. -Before diving into the swap flow itself, it helps to understand the technical environment that makes this design possible. +### Yield and Resume -At first glance, none of the individual building blocks used here look impossible to imagine elsewhere. For example, [Chain Signatures](/chain-abstraction/chain-signatures) on their own are "just" multi-party computation, a group of participants collectively generates a signature without any single party ever owning the full private key. This is a powerful primitive, and in theory, MPC could exist on many blockchains. +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**](/blog/yield-resume). 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. -The question is not whether MPC is possible, but whether it can be used naturally as part of on-chain execution. +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. -Signature generation is not instantaneous, it's an interactive process that unfolds over time. On NEAR, this fits cleanly into the execution model, because the [protocol is asynchronous by design](/protocol/architecture). Contract execution can be split into multiple steps across blocks, without blocking the system or forcing everything to finish inside a single transaction. The chain can move forward while the signature is being assembled, and resume once it is ready. +### Asynchronous Execution -But even with asynchronous execution, another problem appears quickly - cost. Multi-step execution across blocks still consumes gas, and without special care, long-lived flows become expensive. This is where NEAR's [yield and resume](/smart-contracts/anatomy/yield-resume) mechanism becomes critical. It allows contract execution to pause and continue later without repeatedly paying for the same work. As a result, waiting for MPC signatures becomes economically viable, not just technically possible. +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. -Once signing across chains becomes reliable and affordable, token flows themselves need to support multi-step logic. This is where the design of a [NEP-141](https://github.com/near/NEPs/blob/master/neps/nep-0141.md) matters (analogue of ERC-20 on Ethereum), the Fungible Token standard is built around callback-based transfers. Using `ft_transfer_call`, a token transfer can hand off control to another contract, wait for a result, and then either finalize the transfer or revert it automatically. This makes it possible to build flows where assets either move all the way through the system or not at all. +### Mature Token Standards +Once signing transactions for foreign chain becomes reliable and affordable, token flows themselves need to support complex swaps logic. -Finally, NEAR Intents builds on [NEP-245](https://github.com/near/NEPs/blob/master/neps/nep-0245.md) (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. +NEAR Intents builds on [NEP-245](https://github.com/near/NEPs/blob/master/neps/nep-0245.md) (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 -With this context in mind, we can now walk through the swap itself. +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. -### Step 1: Deposit funds from Ethereum to NEAR -Chain Signatures allow NEAR to deterministically derive public keys that can sign arbitrary payloads. Because Ethereum uses ECDSA keys, the same derivation can be used to produce a valid Ethereum public key, and from it - a regular Ethereum address. This address becomes a deposit address, deterministic and unique for each NEAR account. +:::tip 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](https://docs.near-intents.org/near-intents/integration/distribution-channels/1click-api). +::: -From the user's point of view, the action is simple - they send their tokens (in our case, USDT) to this Ethereum address. Once the transaction is included and finalized on Ethereum, it is detected and a cryptographic proof is generated that confirms the transfer really happened. +### Step 1: Deposit funds from Ethereum to NEAR -This proof is then processed on NEAR Protocol by the Omni Bridge smart contract `omft.near`. Once verification succeeds, it makes a cross-contract call to the child smart contract that represents a bridged token (USDT, in our case, and the address will be `eth-0xdac17f958d2ee523a2206206994597c13d831ec7.omft.near`) to mint the same amount that was deposited on Ethereum. These newly minted tokens are then transferred directly to the NEAR Intents contract at `intents.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`](https://docs.near-intents.org/near-intents/market-makers/passive-deposit-withdrawal-service) endpoint in the NEAR Intents API, which will return a native `Ethereum` address into which the user can send their `USDT`. -The NEAR Intents contract plays two important roles. First, it will later act as the verifier for intents, which we will cover in the next step. Second, it implements both the NEP-141 Fungible Token and the NEP-245 Multi-Token standards. The last one allows a single contract to manage balances of many different assets, which is exactly what NEAR Intents needs. +:::tip Where does this deposit address come from? -As a result, the bridged tokens end up held by the `intents.near` contract, but its internal state records that they belong to your NEAR account. +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. -:::info -One natural question here is what happens to the funds sent to all those unique deposit addresses on Ethereum. They do not remain scattered forever. Because these addresses are controlled via Chain Signatures, NEAR Intents can generate valid transactions to move funds out of them. After a 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. -#### What NEAR Intents contract does? +#### Starting the Swap -The contract performs three core functions. +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`, it is automatically detected by external indexers and a cryptographic proof is generated that confirms the transfer really happened. -1. First, it validates the format of intents. Each intent must follow a strict structure, otherwise the transaction is rejected immediately. +This proof is then processed on NEAR Protocol by the NEAR Intents smart contract, which then forwards it to the Omni Bridge smart contract `omft.near`. Once the Omni Bridge contract verifies the proof, it makes a cross-contract call to the child smart contract that represents a bridged token (for `USDT` the address is `eth-0xdac17f958d2ee523a2206206994597c13d831ec7.omft.near`) to mint the same amount that was deposited on Ethereum. -2. Second, it verifies cryptographic signatures. Every intent is signed by a public key specified inside the intent itself - the contract checks that the signature is valid for the given payload. +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. -3. Third, it verifies key ownership. A valid signature alone is not enough, the public key used to sign the intent must have been previously registered in the contract's state. This guarantees that the user explicitly declared, ahead of time, which keys are allowed to sign intents on their behalf. + -#### `TokenDiff` intents and balance matching +#### What happens to the funds sent to the deposit address? -The most important intent type for swaps is the `TokenDiff` intent. Conceptually, it expresses a simple idea - "I am willing to give up X of token A and receive Y of token B". +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. -For a swap to be valid, the contract must ensure that the sum of all token changes balances out. In practice, this means that if one intent declares “−X, +Y”, there must be one or more matching intents that declare “+X, −Y”. +There is one treasury per supported chain, and all deposits are consolidated there. -These matching intents typically come from solvers. A solver may fully satisfy a single intent, partially fill it, or participate as part of a longer chain where multiple intents and solvers connect different assets. As long as the net balance across all involved tokens sums to zero, the swap is considered valid and can be executed atomically. +### Step 2: Executing the swap inside NEAR Intents -#### How this looks in practice +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](https://docs.near-intents.org/near-intents/market-makers/bus/solver-relay). @@ -95,13 +156,13 @@ The first step is requesting a quote. The user calls the Solver Bus API and spec - 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 `TokenDiff` intent and send it to the Solver Bus for execution along with the solver's quote hash(es) using `publish_intent` method. +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. Conceptually, this looks very similar to the deposit flow, just in the opposite direction, and it is still driven by intents. +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). From 19fa218447f96dd0e57a3d996298e3781e07c623 Mon Sep 17 00:00:00 2001 From: Guillermo Alejandro Gallardo Diez Date: Mon, 16 Feb 2026 11:35:29 +0100 Subject: [PATCH 3/4] fix: addressed most comments --- blog/2026-01-24.md | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/blog/2026-01-24.md b/blog/2026-01-24.md index b8fdc9178bf..d825fd2e192 100644 --- a/blog/2026-01-24.md +++ b/blog/2026-01-24.md @@ -15,7 +15,7 @@ Let's take a deep dive into the architecture of cross-chain swaps on NEAR Protoc 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. Briefly, these services +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. @@ -45,8 +45,6 @@ You send `100 USDT` from your `Ethereum` account to a `Solana` wallet that you c 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. -Furthermore, when using bridges you usually receive a wrapped version of the asset rather than the token itself, which means it might be difficult to swap the bridged asset for the native one if the bridge does not have enough liquidity on the target chain. - #### 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. @@ -78,7 +76,7 @@ Behind this simple user experience, there is a complex architecture that makes i ## Technical Foundations -The core technical foundation that makes all of this possible is the combination of **on-chain 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**. +The core technical foundation that makes all of this possible is the combination of [**chain signatures**](/chain-abstraction/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](/chain-abstraction/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. @@ -96,8 +94,6 @@ Another advantage of yielding and resuming is that contracts do not pay gas whil 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 -Once signing transactions for foreign chain becomes reliable and affordable, token flows themselves need to support complex swaps logic. - NEAR Intents builds on [NEP-245](https://github.com/near/NEPs/blob/master/neps/nep-0245.md) (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. --- From adfd83a64f5f1147b5ad20bf8b7fa606d54de6d5 Mon Sep 17 00:00:00 2001 From: denbite Date: Wed, 18 Feb 2026 01:02:18 +0100 Subject: [PATCH 4/4] fix: update bridge to PoA instead of Omni Bridge, as it's the one explaiened in the blog post --- blog/2026-01-24.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/blog/2026-01-24.md b/blog/2026-01-24.md index d825fd2e192..456db7b7295 100644 --- a/blog/2026-01-24.md +++ b/blog/2026-01-24.md @@ -5,7 +5,7 @@ slug: near-intents-2026 tags: [articles] --- -Let's take a deep dive into the architecture of cross-chain swaps on NEAR Protocol, exploring how NEAR Intents and Omni Bridge work together to enable secure and efficient asset transfers across blockchains. +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. @@ -24,7 +24,7 @@ Today, I want to take a deep dive into the technical foundations on how cross-ch Particularly, we will focus on two components: 1. NEAR Intents, a relatively new product which enables intent-based swaps -2. The trustless Omni Bridge, which handles cross-chain asset transfers +2. The PoA Bridge, which handles cross-chain asset transfers Particularly, I want to focus on the technical foundations behind them. For that, we will look at which features of NEAR Protocol make this architecture possible, and why they allow it to be built in a robust and secure way. We will go a bit deeper technically and break down how the system is structured, and what exactly made this design feasible in the first place. --> @@ -58,9 +58,9 @@ Achieving atomicity across multiple blockchains is **extremely difficult** becau 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: +For this, NEAR relies on two key components: -1. The Omni Bridge: a **trustless bridge** that securely moves assets from and to NEAR +1. The PoA Bridge, a bridge built by [Defuse Labs](https://defuse.org/) (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: @@ -122,9 +122,9 @@ Chain Signatures allow NEAR to deterministically derive ECDSA keys (and EDDSA) t #### 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`, it is automatically detected by external indexers and a cryptographic proof is generated that confirms the transfer really happened. +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. -This proof is then processed on NEAR Protocol by the NEAR Intents smart contract, which then forwards it to the Omni Bridge smart contract `omft.near`. Once the Omni Bridge contract verifies the proof, it makes a cross-contract call to the child smart contract that represents a bridged token (for `USDT` the address is `eth-0xdac17f958d2ee523a2206206994597c13d831ec7.omft.near`) to mint the same amount that was deposited on Ethereum. +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. @@ -168,7 +168,7 @@ This burn event is automatically detected by the NEAR Intents infrastructure. A ## Further Exploration -If you're interested in integrating cross-chain swaps into your own service, the recommended entry point is the [1Click API](https://docs.near-intents.org/near-intents/integration/distribution-channels/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 Omni Bridge and removes the need to manually orchestrate each step. +If you're interested in integrating cross-chain swaps into your own service, the recommended entry point is the [1Click API](https://docs.near-intents.org/near-intents/integration/distribution-channels/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](https://near-intents.org/) 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.