NeighborSwap

Inspiration

Earlier blockchains like ETH, and Polygon have a reverting mechanism that makes it possible for creative ideas like flash loans and slippage bounds to be realized, all of which were impossible in traditional finance. However, the limitation of these chains was that it is too slow to make finality. This limitation brought about the advent of parallel computing layer 1 solutions using sharding such as Near, Aptos, and Sui.

Whereas Aptos and Sui leveraged block-STM to support the reverting mechanism at the expense of the speed, Near didn’t support the reverting mechanism but rather used multi-machines where the transaction is executed in an asynchronous manner with nearly deterministic finality. Thanks to this asynchronous characteristic of transactions, there’s no need to worry about MEV attacks in the Near chain.

Builders in the Near ecosystem should handle callback functions when an unexpected situation occurs. However callback functions from many DAPPs are arranged in a way that it is difficult to revert the transaction. Furthermore, the heavy dependence of these callback functions on those of other DAPPs is another hurdle for the Near ecosystem. In short, it is hard to integrate cross-contract calls across DEXs. Therefore a DEX aggregator with slippage tolerance bound seldom exists.

We hope to solve the current routing issues in a single DEX of Near chain, Ref-Finance. In Ref-Finance, the maximum number of hops of each swap is limited to 2. Also each multi-hop swap of parallel swaps is bounded to its respective minimum amount weighted by its split amount. To this end, we propose our DEX aggregator, NeighborSwap, with the increased number of hops and the querying procedure. Querying procedure validates the slippage of whole transactions of DEX aggregator by quoting the full swap paths before executions. We expect that our DEX aggregator minimizes the price impact and slippage, so that users become more willing to trade on the Near chain.

What it does

NeighborSwap first examines price data fetched from DEXs on Near and finds optimal swap routes via efficient path-finding algorithm on the off-chain. Note, the efficient path-finding algorithm of NeighborSwap allows multiple hops (>2). Then, NeighborSwap quotes the computed optimal swap route on the on-chain and prevent unexpected large price impact. If the output calculated based on the price information of on-chain is smaller than the estimated output of the optimal swap route, the whole swap transactions are called off. Otherwise, whole swap transactions are executed. This querying procedure serves as a safeguard for the price impact, which makes NeighborSwap the first DEX aggregator to provide full path quote bounds.

How we built it

We fetched pool information in each of a few blocks from DEX pools directly and formatted it to provide inputs to search optimal paths. We investigated AMMs of all DEXs and made an optimal engine using rust. We executed transactions by deploying contracts with near-sdk. For user UI/UX, we used typescript and next-js to interact with the server(go) and web app(nest-js). We accumulated time-series data using Redis and monitored data using grafana to provide a robust price oracle(time-weighted / liquidity-weighted pricing) with an optimal engine. We deployed a web app using the vercel, and a server using ArgoCD & amazon service in the Near main net environment. We used all that node & BlockDaemon API for executing transactions and fetching the blockchain data.

Challenges we ran into

We tried to aggregate all of the DEXs including AMM-based DEXs like Jumbo Exchange, and Ref-Finance, and Orderbook-based DEXs like Spin, and Tonic. We had to be concerned about the cross-contract call-based loss as there’s no DEX that refunds assets when one of the batch transactions has errors or doesn’t meet the condition due to the absence of reverting system. So we minimized the problems to make the live demo in a single DEX(Ref-Finance) liquidity aggregation by using our own pathfinding engine. There was a time attack as we expected the time spent for the DEX Aggregator integration in any other EVM-compatible main nets(Polygon, BNB) but the Near has a lot of differences with other EVM-compatible main nets. Although we made Aurora DEXs integrations for Trisolaris, Rose finance, Curve, Nearpad, WannaSwap, AuroraSwap, and Saddle Finance, we couldn’t integrate into the transaction triggered from the Near in time. So we set the roadmaps that we couldn’t achieve during the hackathon period to deploy more sophisticated solutions in the Near trading services.

Accomplishments that we're proud of

Our main accomplishment is that we overcame two limitations of Ref-Finance, currently a DEX with the largest trade volume.

First is the double hop limitation. Swaps in Ref-Finance as of now go through at most 2 hops, which is a strong limitation for effectively reducing the price impact. By advancing the path-finding algorithm, NeighborSwap extended this to multiple hops, yielding a much more elaborate path of the swap, thereby cutting down the price impact and maximizing user experience.

Second is that Ref-Finance could potentially fail to swap the input assets in full amount, which was overcome by our router smart contract’s querying step. Since Ref-Finance splits the input assets into several fractions and carries out swaps for each fraction, if one of these swaps is reverted then the input asset ends up being swapped only partially. In contrast, NeighborSwap queries the total amount of the output asset of each fraction on the chain immediately before the swap and if that total amount exceeds the estimation then carries out the swap. Hence NeighborSwap is not subject to the kind of failure that Ref-Finance experiences.

In summary, by building NeighborSwap that provides up to 5 hops with linear splitting routes and that has a querying procedure, we could minimize users’ price impact and break through the big hurdle of low swap willingness in the Near ecosystem.

What we learned

We learned the mechanism of the Near main net and the pros & cons of the asynchronous transaction.

Pros are fast, stable, and unavailable-MEV network, and Cons are difficulties for integrity with cross-contract calls and inadaptable functions(Flashloan, Zap, etc) in other main nets.

We investigated NEP-141(fungible token standard specs) which doesn’t need an approval function and went through interfaces of pools and AMM modeling. We integrated SimplePool, StablePool, RatedPool, and Aurora layer(UniV2, Balancer, CurveV1 models) and it would be expanded to order book matching(for Spin, Tonic) and any other AMMs such as CurveV2(CSMM+CPMM with general coin pairs), UniV3(Concentrated Liquidity).

What's next for NeighborSwap

Our roadmap for NeighborSwap is as follows. In this hackathon, NeighborSwap provides Near’s safety check AMM-based DEX Aggregator. Afterward, we will integrate cross-contract AMM-based DEX Aggregator including order book-based DEXs, and Aurora DEXs.

We have the experience to deploy contracts in EVM-compatible main net and execute transactions in previous works. It would be easy to integrate the Aurora transaction from the Near main net.

After that, we will enable order book trade matching solutions in multichain and CEX integration. Eventually, we will expand our product to a multichain cross-swapping function, aggregating both Rust-based and Solidity-based main nets. This will contribute to decreasing the price impact and slippage and maximizing DeFi traders’ experience.