wingman

// The Challenge // Fusion orders aim to get users the best price. Normal sandwiches and backruns are not possible because Resolvers execute the tx for the user.

However, Fusion orders are public and this exposes them to the risk of being taken advantage of.

One important vulnerability of public orders on-chain are: Multi-order sandwiches. This type of MEV is not widely known so we'll go into a detailed example:

1. User submits: A user submits a Fusion order for a big buy. So big it will move the market by 5%.
2. Bot frontruns: A bot reads that order and immediately submits his own buy, moving the market up 10%.
3. Order Fails: The Fusion order will time out and fail, since no Resolver can fill in the accepted range anymore.
4. User resubmits: The user still wants to buy. Grudgingly he submits a second order, now for a 10% higher price.
5. Bot backruns: The bot waits for the user order to execute and backruns it with a sell of the same amount. Netting a profit of 5% (the user price impact) minus fees.

// FAQ //

• Won't off-chain prices rebalance after the bots buy order: Not if the token is primarily traded on-chain. And not if the bot splits his trade between off- and on-chain.
• This is not guaranteed, the user might not resubmit: Yes, he might not. The bot can use amount and price impact to judge exactly what kind of slippage the user will likely tolerate. The bot plays a probabilistic game, and wins big every time it works, and loses little if it doesn't. However, the user always loses.

// This is a Big Problem //

No MEV protection protects against this sandwich: It doesn't matter which chain the user is on, whether with a centralized sequencer or not – the bot can always read the user's intent from the public Fusion order book.

Damage is practically unlimited: The damage to the user is only limited by his urgency to make the trade, and how careful he is checking prices. The bot can push the price 1, 5, 10, 20% and the user might still buy - the price jump can even make him fomo more. A single such sandwich can wreck a user considerably.

Other problems of lack of privacy: Sandwichers, while very damaging, are not the only ones that can abuse a Fusion order. Copy traders, simple frontrunners, signal traders (cross-chain traders) can all use the information to their benefit. And anyone can make a Fusion order fail with intentional price impact (e.g. to hurt a competitor).

// Other Problems // There are other problems with a of lack of privacy of orders:

• Orders can be effectively censored by anyone (by frontrunning them)
• Orders can be interpreted by competition (e.g. Iceberg orders can be read and frontrun)
• Orders can be copied, or plainly frontrun by a signal trader.

// Solution //

To protect the user we hide their tx from being publically readable. This way sandwiching bots and other actors wanting to use your order don't know about the order and can't you. Only Resolvers can still decrypt these transactions - letting them settle the orders like any other Fusion order.

We effectively created a FusionPool - a private pool of protected orders that only Resolvers can read. Here is how it works

1. Encryption: We encrypt the user transaction in the frontend, store the tx on IPFS and send the key to Threshold network.
2. Decryption: Resolvers can get new orders from IPFS, sign a message with their private key and request a re-encryption of the tx from Threshold network. Threshold checks if they are a resolver against a smart contract, and if they are, sends the tx back to the Resolver re-encrypted with the resolvers public key.

This gives the users full privacy until their order is mined on-chain. And fully protects them from multi-order sandwiches and all other risks of having their order public before it's mined.

// Outlook // We can easily extend the Condition-Based decryption to check for any arbitrary condition that can be verified on-chain. Such as

• Orders that execute only after a certain block
• Orders that only execute after a certain price (making Stop-Limit Fusion orders possible!)
• Orders that can execute after any other Oracle condition is satisfied (which with long-tail Oracles allows you to access almost any datapoint).

// Technologies // Wingman relies on

• 1inch Fusion SDK: 1inch Fusion orders give users the best price, and protect against sandwiches and backruns. Made possible by Resolvers that compete and submit transactions optimally. We use the 1Inch Fusion SDK to query market prices, construct Fusion orders and solve Fusion orders as a Resolver.
• Polygon: We deployed Wingman on Polygon. The Fusion Resolver registry smart contract is deployed on Polygon. User transactions and Resolver transactions are also mined on Polygon.
• Threshold.Network: We use threshold networks Condition-Based Decryption (CBD), to verify Resolvers decryption requests and return re-encrypted orders.
• Metamask: We use Metamask to sign the 1inch Fusion order. We also use Metamask to sign the Resolver signed message that requests a re-encryption from Threshold.
• IPFS: We store the encrypted transaction on IPFS.
• Foundry: We are use Foundry Forge, Cast and Anvil.
• Solidity: Smart contracts are written in Solidity.
• Frontend: We wrote the frontend in React and Typescript (UI and encryption).

// How it works //

1. *User creates a tx: On the Wingman UI users can select the standard swap parameters: token_in, token_out, and in_amount.

2. 1inch Fusion Quote: The UI uses the 1inch Fusion SDK to query a price quote (getQuote). We then use the SDK to create a Fusion order.

3. Encryption: The frontend creates a unique private key for the users transaction and uses it to encrypt the transaction. The private key is then split and saved on distributed nodes in Threshold encryption's condition-based encryption network.

4. Fusion Dark Pool: Instead of the Fusion API (placeOrder) we send the order to be stored on IPFS.

5. Resolvers read new ecrypted txs: Resolvers check the IPFS directory for new order IDs, and request any new orders that they have not seen before.

6. Resolvers query re-encryption: Resolvers then sign a message with their private key and ask Threshold CBS for re-encryption of the order with the resolvers public key.

7. On-chain check of resolver: Threshold nodes verify the Resolvers's signed message with the Resolvers public key. They then verify against the on-chain resolver registry whether this public key is currently registered as a resolver.

8. Re-encrpytion by Threshold: If the public key of they querying resolver is currently registered in the resolver registry then the threshold nodes together decrypt the user order and re-encrypt it with the Resolvers public key. Then send it back to the Resolver.

9. Decryption and Settlement: The Fusion Resolver can then decrypt the order using his private key and treat the order from then on like a normal fusion order. Once he can fill it he settles the order, submits it privately (to a builder) and the tx gets mined.

10. Protected settlement: The tx has been mined without being visible by anyone other than the resolvers, builders and lock proposers. The user transaction has been fully protected.