Use Cases
Last updated
Last updated
Please, note that this part explains the use case from a simplified point of view in order to understand how basics work.
The following part provides for 3 use cases for your reference:
Swap between Users (Mirror Swap) - swap when different users want to execute opposite transactions, allowing them to be inter-executed.
Swap closed by the Resolver - order closed by a sole resolver.
Complex Swap - swap featuring mirror swap and resolver closings.
Mega-Layer - order from a third-party intent-based protocol closed by a resolver from other third-party intent-based protocol via Quotex Mega-Layer.
User A wants to exchange 3,000 USDT on Source Chain (for example, ERC-20) for 1 ETH on Destination Chain (for example, BNB). He goes to Quotex and signs a respective order. The order appears in the Order Pool of the Unified Order Network, a dynamic database accessible to market participants.
Matching Engine first looks for opposite (mirror) orders in the Order Pool. It finds that User B has signed an order to swap 1 ETH on BSC to 3,000 USDT on ERC-20 at the same time.
After the contract ensures that both orders of User A and User B are still valid and unexecuted, and have enough slippage set to cover the gas fees, it immediately inter-executes their orders.
User A wants to exchange 3,000 USDT on Source Chain for 1 ETH on Destination Chain. He goes to Quotex and states the required sum in relevant windows, as well as chooses how he wants his trade to be performed - via a Dutch Auction (an auction type where the price starts high and decreases until it reaches the limit of the [Sum - Slippage]) or a Limit Order (an order to buy or sell a cryptocurrency at a specific price or better) method.
The order appears on the Unified Order Network, a dynamic database accessible to market participants. Matching Engine looks for mirror orders first, however, there is no mirror order in the Order Pool.
The Matching Engine proposes the order execution to the relevant resolver, who then competes for it. There are two variations of the competition model, depending on the user’s choice of trade type: limit order or Dutch auction. Let's assume that regardless of the trade type User A chooses, Market Maker B wins the bid and decides to fulfill the order.
After User B decided to fulfill the order of User A - 3,000 USDT of User A are blocked on the Source Chain. Market Maker B sends 1 ETH to User A on the Destination Chain. The contract verifies that User A received the 1 ETH. Upon successful verification, the contract releases the 3,000 USDT blocked on the Source Chain and sends it to Market Maker B. This ensures that both parties securely receive their respective assets. The exchange is completed with User A receiving 1 ETH on the Destination Chain and Market Maker B receiving 3,000 USDT on the Source Chain.
User A wants to swap 1,000,000 USDT on the Source Chain (for example, ERC-20) for USDC on the Destination Chain (for instance, BSC). He signs the respective order on Quotex.
The order appears on the Unified Order Network, a dynamic database accessible to market participants. Matching Engine finds a mirror order from User B, that can partly inter-execute the order of User A. User’s B order is to swap 900,000 USDC on Chain Y to USDT on Chain X.
After the contract ensures that both orders of User A and User B are still valid and unexecuted, it immediately inter-executes their orders.
User's Order is partly executed - he received 900,000 USDC on the Destination Chain (Y) for 900,000 USDT on the Source Chain (X). There are no more mirror orders available. User A still has to trade 100,000 USDT on the Source Chain (X) for the 100,000 USDC on the Destination Chain (Y).
Matching Engine proposes to relevant resolvers to compete for the rest of order execution. 2 variations of the competition model which are dependent on the user's choice of the trade type - limit order or dutch auction. Let’s assume, no matter which trade type User A has chosen - a Market Maker B wins the bid and decides to fulfill the order for 99,000 USDC.
After Market Maker B decided to fulfill the rest of the order of User A. 100,000 USDT of User A are blocked on the Source Chain (X). Market Maker B sends 99,980 USDC to User A on the Destination Chain (Y). The contract verifies that User A received the 99,980 USDC. Upon successful verification, the contract releases the 100,000 USDT blocked on the Source Chain (X) and sends it to Market Maker B. This ensures that both parties securely receive their respective assets. The exchange is completed with User A receiving 99,800 USDC on the Destination Chain (Y) and Market Maker B receiving 100,000 USDT on the Source Chain (X).
Intent-Based Protocol Y has integrated its orders within the Order Pool of Unified Order Network, as it wants to provide its users with faster and efficient execution of their intent-based orders, due to the lack of resolvers in their Protocol.
Intent-Based Protocol X has far more resolvers than orders, thus it wants to give their resolver access to an additional pool of order, and therefore it has decided to integrate its resolvers to the Resolver Pool of Unified Order Network.
User Y filled an order within Intent-Based Protocol Y and it respectively duplicated in Quotex Order Pool. Resolver Pool from Intent-Based Protocol X is integrated within Quotex Resolver Pool, and therefore Resolver X has an access to the Quotex Order Pool to compete for orders there, including order of User Y. Resolver X wins the competition for execution of User Y Order, and executes it via Quotex. At the same time, User Y does not leave the interface of the Intent-Based Protocol Y, and his order is executed. Resolver X from his side does not leave the interface of Intent-Based Protocol X and executes more orders.
