Operator Service

MM-UI and MM-Service Repositories are currently closed source

To complete the bridging process and enable data transmission between smart contracts, the Operator service is essential. Previously known as "eventWatch," the Operator's primary role is to listen for on-chain events.

While the core functionality is handled by the smart contracts, the Operator service is crucial for a fully operational bridge. Although it can be run locally, in a production environment, it's currently deployed on a server as an API service that the front-end can interact with. The Operator service also integrates a database to store all the orders, their statuses, and other relevant information. Inside the repository, there are several listeners that wait for events from the smart contracts, and upon receiving an event, they initiate the corresponding workflow.

Workflows

The first workflow is triggered when a user places an order, the listener captures the order details and logs them in the database, which the front-end queries to display the information for the MM to fulfill. The function checks if the order already exists in the database, and if not, it adds it. Next, it verifies if the MM has enabled auto-transfers. If enabled, it calls executeSendTransfer, which automatically fulfills the order on behalf of the MM. After fulfillment, the database is updated to reflect the order's completion.

The second workflow is triggered when a transfer is made on the Payment Registry contract. The listener detects the event and updates the database to indicate that the order has been fulfilled. This is also where the automatic withdrawal system, could be activated in order to start the proving and withdrawing system as soon as the transfer is made. However, in the current SMM setup, the MM has the flexibility to withdraw the funds at a more convenient time, either manually or through an automated system. This system can monitor the MM's liquidity on the destination chain, the amount owed on the source chain, and the current gas prices to optimize the withdrawal process.

To start the proof process, when done automatically, the process begins with calculating if a rebalancing of funds is required. Meaning is the market maker owed more on the source chain than on the the amount of funds they have on the destination chain. If a rebalance is needed, and gas prices are lower, the MM can choose how many orders it wishes to prove and withdraw to improve it's liquidity position.

The service will then gather the necessary order information that is used for proving, and send it over to the Escrow contract that will begin the proof generation process by validating the passed data, sending it to our custom HDP module, and then receiving an answer if said order has been fulfilled.

The calculation of storage slots used to be performed by the Operator service, however has since been offloaded to the HDP module, for a more secure and robust system, as once deployed via cairo, there is no way to change how the system will work, ensuring it's soundness.

This completes the core function of the Operator service. There are some differences depending on how the bridge is used, such as MMM versus SMM scenarios, as well as the option for auto-filling orders. Additionally, the Market Maker situation evaluator and executor monitors your outstanding debts on the destination chain. Depending on your liquidity and current gas fees, it will decide whether to start withdrawing smaller orders when gas prices are low or to withdraw one large order when gas prices are high but you are low on liquidity on the destination chain.