Traditional atomic DEXes operate isolated, without any information but the on-chain liquidity of tokens traded. This is particularly bad in a multi-chain context with fragmented liquidity.

Intents and cross-chain intents are great solutions for this problem. Still, the asynchronicity doesn't fit well for many use cases: liquidations, vaults, interoperability, fee collection, or just hurried-up users.

In Bang, we tackle this problem by providing atomic one-side swaps based on Oracle prices for listed tokens.

The protocol efficiently manages shared cross-chain liquidity in USDC to acquire these tokens in low liquidity chains (secondary chains). Then the tokens are sold asynchronously using bridges, cross-chain intents, or different strategies.

This effectively connects the demand for atomic swaps with asynchronous and cross-chain solutions, efficiently managing liquidity and risk.

On the other hand, the acquired tokens should be sold at a better price than the acquisition cost. There's a risk in the operation, so we apply discounts to the oracle price and swap capacity limits, and the discounts increase with the utilization of the capacity.

Two key aspects drive the design of the solution:

1. Liquidity efficiency

Since our intention is to develop a multi-chain protocol that exists in many small chains, then it's critical to efficiently allocate the available USDC liquidity across them.

The design of the protocol is such that the secondary chains communicate the trades to the main chain, as fast as possible (using a fast bridge) and the main chain refills their USDC capacity also as fast as possible, without waiting for the liquidation of the acquired tokens.

This way we don't need to allocate big amounts of idle liquidity on each small chain.

1. Risk Management

Buying tokens based on oracle prices, that will be sold minutes after transferring them to a chain with more liquidity, is a risky business.

The protocol was designed to allow a granular parametrization of the markets, defining capacity per market and token, discount ranges, and fixed costs per trade.

These parameters operate on time-windows, with explicit renewals for each period.

The different liquidation strategies operate in a trade-off between finding the best price and selling as soon as possible.

In the future, we might off-load the risk, by transferring it to an insurance protocol like NexusMutual or Ensuro.

Presentation here: https://docs.google.com/presentation/d/1EzMW1LkIZHdbroOg6wGrCZZy1VeiuxmxggemsROKDVY/edit?usp=sharing

The architecture of the solution is the following:

DEX contract

It's a contract that will be deployed on each chain where we accept trades (price-follower chains).

This contract implements a price curve that's based on the oracle price, applying a discount that increases as more capacity for a given token has been used, in a given timeslot.

Supporting this contract, we have two contracts:

• IBridge: this contract transfers USDC to the main chain and sends messages to it. It was implemented using Hyperlane for remote calls and CCIP (with underlying CCTP) for transfer of USDC.
• IPriceOracle: this contract provides the prices of the listed tokens. It was implemented using Pyth Oracle, a solution that gives us flexibility to on-board a great variety of tokens.

Liquidators

These contracts are the ones responsible for receiving the acquired tokens, selling them, and sending the resulting USDC to the main chain.

The protocol supports different liquidators for each token on each chain. This gives us the flexibility to implement the most suitable strategy for each particular case.

Some of the liquidators implement the bridge-and-swap strategy. This means they transfer the tokens to the main chain, which generally has a lot of liquidity and competitive swap markets. Once the tokens arrive, they are sold and the result is transferred to the Risk Hub (see below).

For bridging the tokens, we implemented CCIP, Hyperlane, and LayerZero (OFTs). The idea is to use the canonical bridge, when available.

Another strategy is selling the tokens using intents, either on the same chain (using Cow Protocol and then bridging the USDC to the main chain) or with cross-chain protocols like 1inch Fusion+. We couldn't yet implement either 1inch or Cow Protocol, using intents signed by smart contracts, but is part of our plans.

Other strategies can be implemented in the future, like selling the tokens in several small trades, to avoid slippage.

Risk Hub

This contract is deployed once, in the "main chain". This chain should have a lot of liquidity in most of the tokens, it could be Arbitrum or Base.

The responsibility of this contract is to refund the DEXes for the trades made. This contract also receives the results of the liquidations.

This way, this contract is the one that effectively faces the risk and the profits. If on average the acquired tokens are sold and a higher price than the acquisition cost, it will have profits. Otherwise, it will have losses.

To stabilize the returns of the protocol, in future versions, we might off-load the risk to an on-chain insurance protocol, like Ensuro or NexusMutual.

This contract also uses a CCIP Bridge and Hyperlane for the transfer of USDC and communication with the DEXes.