Matchmakers
Matchmakers are bots that continously scan open orders on the MuesliSwap orderbook protocol. If they find two orders that can be used to fill each other, they issue a match: Use the locked funds of either order to fill the other order.
This process is coordinated by two factors: The matchmaking incentive and game theory. The matchmaking incentive is a small amount of ADA that is attached to each order and incentivices matchmakers to process orders. The matchmakers are additionally incentiviced by the margin on two orders, which they can keep as a reward.
Game theory coordinates the contention around matching orders. While Matchmakers may try to batch as many orders as possible or wait strategically until they match certain orders, game theory forbids this behavior. The matchmakers need to be aware of other matchmakers interacting with the protocol. Since others could process orders before any strategic behavior is applied, the main incentive is to fill orders as fast as possible - just as users would wish for.
The MuesliSwap protocol doesn't rely on trusted individuals with special privileges. This is in contrast to other decentralized protocols, where a dev team has the power to select "validators". As a rule, these validators make money by arbitrage and reordering transactions in a way profitable for them. Such a protocol is not really decentralized! In MuesliSwap, no such thing exists - everyone can be a matchmaker.
Interacting with orders
Users place orders on the Cardano Blockchain by locking funds in the MuesliSwap Orderbook contract. The contract may only release tokens if the conditions specified by the user are met - this is the case if the amount of tokens returned to the user fits the amount of tokens ordered. Alternatively, a ratio of the tokens may be attached to a new order placed to the contract belonging to the same user.
Parsing user orders
How do the matchmakers know the amount of tokens ordered by the user? When placing an order at the MuesliSwap orderbook contract, we attach metadata and tokens to the transaction. The amount of token offered is exactly the amount of token attached to the utxo, except for 1.7 ADA that are always attached to meet the minimum UTxO amount. The following metadata provides the remaining information necessary to reconstruct what a user ordered:
| Metadata label | Value | Example |
|---|---|---|
1000 | Shelley address of user (hex) |
|
1002 | Ordered token Policy ID |
|
1003 | Ordered token Name (hex) |
|
1004 | Ordered token Amount | 1000 |
1008 | Offered token Policy ID |
|
1009 | Offered token Name (hex) |
|
Constructing a match
When constructing a match transaction between two user inputs, the matchmaker needs to supply the contract with additional information. Once, it needs to supply the datum that the user attached to its order in the contract. This datum is reconstructed according to the metadata fields above.
In addition, the matchmaker needs to supply a special datum, called redeemer, that tells the contract the purpose of spending the user funds. When matching two orders completely, the format for the redeemer does not change. In case of a partial match, the matchmaker has to provide the match ratio r in the redeemer.
Note: With the launch of our new orderbook protocol, we introduce so called "Matching licenses". These are necessary in order to interact with the orderbook as matching entity. The licenses are in place to secure user funds and guarantee a safe match making progress. As our protocol progresses, we will give licenses out in a more and more liberal fashion such that ultimately everyone can participate as a registered matchmaker. Licenses are now available for testnet via our testnet faucet! See the feature preview page.
The redeemer now has an additional field which specifies the index of the incoming UTxO to the transaction that contains a valid matching license. It is important that the matching license is valid until before the end of validity of a transaction.
Last updated