liqu1tent

liqu1tent allows users to create orders (with specified sellAmount [using a token on the origin chain] and buyAmount [using a token on the destination chain]) on an origin chain and sign them to allow a set of solvers (professional swap operators that execute swaps on users behalf) to execute them on a different destination chain.

For EVMs e.g. it uses eth-sign to sign a hash of an order which is then broadcast to the solvers. Once a solver decides to fill the order, they first lock the sellAmount on the origin chain by triggering the initiate-function on the origin-settlement contract.

They then can directly fill the order on the destination chain by triggering the settle function on the destination-settlement contract.

The contract will then

1. Transfer the buyAmount from solver to user-defined recipient
2. Broadcast a message (consisting of orderHash, fill status and solver-defined receiver) to the origin chain
3. Once the message on the origin chain is received, the sellAmount is transferred from origin-settlement contract to the solver-defined receiver.

The process makes the swaps nearly instant since a cross-chain messaging service (in our case Layer Zero) is only used after the user receives their buy amount on the destination chain.

Risks such as block-building latency or finality are to be evaluated by solvers which can compete (e.g. fill quick to get a good quote and accept possible risks of block finality) and impact the end user experience only minimally.

We deploy Settlement contracts (https://github.com/1delta-DAO/liqu1tent/blob/main/contracts/evm/contracts/Settlement.sol) on multiple chains.

We deployed the following ones as a demo on the given networks: [ChainId.MANTLE]: '0x1d051eeD29Df13E1A1d1546329E54036A57AEb77' [ChainId.POLYGON]: '0x1280Bdbe692fA1ae7b69B9356daD6Cc211cbEA41'

The Settlement contracts loosely follow the ERC-7683 standard that was introduced by Uniswap Labs.

As an example, we have a user (0x2D449a74a043e03fAF5C50171Eee640254B99e44) and a solver (0x45a000c10ae9ACd6dA466F650a2D80Cb38620117).

The user signed an order for a swap of 2 wMNT on Mantle against 1.5 wMATIC on Polygon that was picked up and validated (via ecrecover) at txn https://mantlescan.xyz/tx/0xa33d34c3f2b6c8f9b002bdb4ecbb91da70f212e3d0ff7b9a093e96f703123db6

The solver filled the order on the destination chain at txn https://polygonscan.com/tx/0x343d8efc36aec85df2242291c0c24d3a016e66d6bbc935b392dff6755b351aa8

This in return triggered the messaging service LayerZero V2 to broadcast the order-hash and fill status from Polygon to Mantle at https://layerzeroscan.com/tx/0x343d8efc36aec85df2242291c0c24d3a016e66d6bbc935b392dff6755b351aa8

The message triggered the lzReceive function on the Settlement contract on Mantle and unlocked the 2 wMNT to be received by the solver at txn https://explorer.mantle.xyz/tx/0x7e2f5a0a0b3fbcbdc3a4a4d7999e41504229c57d092e84b221c5e6ca76bb5bf7

We derived a few conclusions about ERC-7683:

• The standard uses address to refer to EOAs an tokens. Given that messaging services like layer zero support non EVMs like Solana, a generalization from address to bytes32 would extend the compatibility to a larger set of chains (including Cosmos & Solana)
• This also raises questions about how to potentially be more efficient with identifying chains (e.g. a compact bytesXX type would allow to include chains without numbered chainIds)

We also provided an example for an order database and solver in /backend.