feat: add blog post about architecture of NEAR Intents

blog/2026-01-24.md

@@ -0,0 +1,177 @@
+---
+title: "Deep Dive into NEAR Intents"
+authors: [denbite]
+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 the PoA Bridge work together to enable secure and efficient asset transfers across blockchains.
+
+<!-- truncate -->
+
+---
+
+## 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.
+
+<!--
+
+Particularly, we will focus on two components:
+
+1. NEAR Intents, a relatively new product which enables intent-based swaps
+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. -->
+
+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
+
+<!-- At a high level, cross-chain swap usually combines two things: bridging assets from one blockchain to another, and exchanging them along the way.
+
+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 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](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:
+
+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**](/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. 
+
+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**](/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.
+
+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](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
+
+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.
+
+
+:::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).
+:::
+
+### 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`](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`.
+
+:::tip 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.
+
+<!-- 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. -->
+
+#### 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](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 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](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.
+
+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.

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