Introduction

For the sake of this document, NEAR Intents (documentation) is a cross-chain swapping protocol (in fact it’s much more than that). The protocol is in active development, so many things are changing rapidly. This protocol is integrated into multiple front-ends (with the list growing).

The protocol is designed to be very similar to CEXes. The user needs to deposit assets into the protocol, then he’s able to trade them (fast and cheap) and at the point when he wants to move the assets to another place, he needs to withdraw.

Currently, it uses so-called PoA bridge service for deposits and withdrawals. It is fast, but it’s trusted. An alternative solution for deposits and withdrawals is called Omnibridge. Omnibridge provides enhanced trust assumptions compared to PoA bridge, but generally is slower. For the networks supported by Omnibridge, Intents will switch the deposit and withdrawal logic from PoA to Omnibridge over time. The slow deposits over Omnibridge can be offset by the fast deposit service.

The current implementation of Omnibridge is named v1. It has custom integrations of networks (Bitcoin and Ethereum have light clients on NEAR; Arbitrum, Base and Solana integrations are using Wormhole for message passing). Every new network integration is complicated to develop in Omnibridge v1 architecture (it requires some form of message passing or light clients and development of smart contracts on target blockchain). Maintenance of Omnibridge v1 is also complicated.

There’s a concept of Omnibridge v2. It will use the mix of TEE, RPC reads and MPC (from Chain Signatures) technologies. Omnibridge v2 makes it much simpler to maintain Omnibridge, while also simple to add new networks. Both Omnibridge v1 and v2 would not be fully decentralized, since the contracts must be upgradable to allow for changes of blockchain protocols. However, the decentralisation level of Omnibridge is maximum possible without breaking UX.

Similarly to CEXes, NEAR Intents does not include an Automated Market Maker (AMM) software. Instead, Market Makers (MM / Solvers) should integrate with Intents to create markets for specific pairs of the tokens (say, ETH.ethereum <> SOL.Solana). However, contrary to CEXes, the protocol provides a convenient way to trade any <> any token through routing service: (say, NEAR can be traded to MOG through this path: NEAR <> USDC.near <> USDC.base <> MOG).

There is an open-source MM software that is integrated with NEAR Intents. It works similarly to Uniswap v2 pool. A party that wants to create a market needs to supply liquidity from both sides (we recommend TOKEN <> USDC.ethereum to make sure the routing works well) and run this AMM Solver. There’re other MM softwares where NEAR Intents will be integrated over time (example).

There’s a ‘Solver of Last Resort’ integrated with NEAR Intents run by Solver inc. This MM is a temporary solution for major markets, because bigger MMs will eventually integrate with the protocol. The Solver of Last Resort implements neutral strategies and uses integration with CEXes and DEXes to counter-trade. The major difference between Solver inc. and AMM Solver is that the latter creates a new market for an asset, while the former is aggregating existing markets.

Decision process for token listing

To communicate with the party that wants the token to be listed you need to follow this algorithm:

1. Get information about the token:
   1. Which chains this token exists. And which chains do you want this token to be available for deposits and withdrawals.
   2. On which on-chain markets (DEXes) this token is traded and what’s the algorithm behind it (Univ2/Univ3/Univ4/Raydium/etc.)
   3. Which CEXes this token is traded.
2. Communicate that:
   1. We cannot guarantee whether the token will be discoverable on all the FEs; only https://near-intents.org/
   2. There’s a separate deposits/withdrawals listing
   3. Somebody needs to MM the token (create a market for it) for every chain.
3. If the token exists on the chain that is currently not supported by the PoA bridge, it won’t be listed for this chain at all.
4. If the token is available (or you want it to be listed) on a single chain, then:
   1. If this token is traded on markets, currently supported by Solver Inc., then Solver Inc. would be able to MM this token for you. Solver Inc. would need liquidity from you to do this (in a form of a loan). If you want the trades of $X size to be usually able to be executed, then you need to provide $4X+ of the one-sided liquidity (only the token). Increasing the amount of the tokens will increase the size of the swaps possible.
   2. If this token is not traded on the markets supported by Solver Inc., then you either need to run AMM solver or wait until Solver Inc. would support the markets for your token.
5. If the token is available on multiple chains supported by PoA bridge and you want it to be listed on all of these chains, then:
   1. If this token is traded on at least a single market currently supported by Solver Inc., then Solver Inc. will be able to MM this token for you. Solver Inc. would need liquidity from you to do this (in a form of a loan). If you want the trades of $X size to be usually able to be executed, then you need to provide ((n+1)4$X)+ of the one-sided liquidity (only the token), where n is the number of chains supported. Increasing the amount of the tokens will increase the size of the swaps possible.
   2. If this token is not traded on the markets supported by Solver Inc., then you either need to run AMM solver or wait until Solver Inc. would support the markets for your token. Note that you would need to run multiple AMM solvers to allow for cross-chain routing.

Trust assumptions

1. Intents protocol: works as a smart contract; contract is pausable and upgradeable (security council)
2. PoA bridge: trust to a 3rd party to custody assets