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 intents, 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 intent, the listener captures the intent 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 intent 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 intent on behalf of the MM. After fulfillment, the database is updated to reflect the intent's completion.

The second workflow is triggered when a fulfillment is made on the Payment Registry contract. The listener detects the FulfillmentReceipt event and updates the database to indicate that the intent has been fulfilled. This is also where the automatic withdrawal system could be activated to start the proving and withdrawing process as soon as fulfillments are made via mostFulfillOrders (single or batched). 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 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 intents it wishes to prove and withdraw to improve its liquidity position.

The service will then gather the necessary intent 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 intent 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 intents. 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 intents when gas prices are low or to withdraw one large intent when gas prices are high but you are low on liquidity on the destination chain.