Router flow

No router commitment is required if the LayerAkira Router strategy used

Deposit

Routers must commit the Router Deposit in our Exchange to be able to route orders. This is a necessary requirement to prevent any malicious activity by Routers.

If the order routed by the Router is invalid, we will deduct the Router Penalty. This compels the Router to be diligent while providing router services.

Registration

Once a Router has the Router Deposit locked in our smart contract, they can register their address as the taker fee recipient and start earning fees. This is achieved by interacting with the smart contract method register_router. [Nikita - is there a step where they specify their routing fees?]

Bindings

Routers will define the signers responsible for signing orders on their behalf. This way, if a Router loses access to its private key, a Router can easily remove its bindings with the Router through a dedicated method in the smart contract called remove_binding. If the Router wants to add more signers, it can do it by interacting with the smart contract method add_binding.

Withdrawal

Routers are free to withdraw any earnings, however, an amount equal to the Router Deposit must be kept in our smart contract at all times in order to continue routing orders to our Exchange.

Deregister

Once a Router decides to stop providing services, it can invoke the deregister methods in slow mode, similar to how it works in withdrawals. This slowdown is required to prevent any malicious activities from the Routers (eg. where they stop providing services at the time of on-chain settlement).

Once a Router is deregistered, our Exchange will not push the Router's orders because it will force the transaction to fail. Where the Router has successfully deregistered, they will not be charged any penalty for failed transactions.

This logic will enable a transparent way for entities to provide Routing services. Any malicious activity performed by any parties would be unprofitable due to our design.

Example of Router Interactions:

• The Router maintains either our entire Router Book or the best bid/best offer.

• Users interact with the Router, making requests for quotes.

• The Router provides the current best rates that LayerAkira can offer.

• The Router provides calldata for the taker order that needs to be signed.

• The user signs the calldata and gives it to the Router.

• The Router validates that the user has the necessary permissions granted to the LayerAkira smart contract and has sufficient funds to execute the trade.

• The Router signs the order using one of the signer keys and sends the signed order to our endpoint.

• Our Exchange validates that the order can be executed:

  • For example, the user can:

    • specify strict slippage

    • make the order fill or kill ("FOK") or immediate or cancel ("IOC")

• Our exchange will immediately push the executed trades on-chain as both participants can reuse the results of trades as soon as possible (both maker and taker).

In this scenario, the users benefit from not incurring gas costs for failed transactions, unlike fully on-chain DEXs where their transactions might get reverted if someone has already filled a particular level or their trades fall out of slippage. Our approach ensures that users only pay gas for successful transactions, avoiding unnecessary costs associated with unsuccessful trades