Deployments

General framework

Three nodejs files connected to one another through multi-threading are in charge of listening for a specific event coming from the Emitter contract deployed to Ethereum. These files will review all transactions sent to a particular Account in case one hasn't been automatically redeemed as part of Arbitrum's auto-redeem of retryable tickets. In case it finds one, it manually redeems it.

Structure

Internal subnetwork of Akash deployments

Each group of files is containerized and submitted as one deployment to the Akash network. There are N amount of Akash deployments in case one provider fails, since the network doesn't support load balancing at the moment.

• event-listener listens for new transactions coming from Emitter. Once it gets one, it filters out the Account that was involved in the transaction, adds it to the back of the queue of Accounts to check (if it hasn't been added already), and forwards the queue to while-fork.

• while-fork grabs the Account at the beginning of the queue and waits 60 seconds before sending it to redeem-fork. These seconds are needed to give Gelato's subgraph enough spare time to index the new L1 transaction that just occurred.

• redeem-fork gets the Account from while-fork, and start checking each new transaction that hasn't been checked before for one that wasn't manually redeemed. If it finds one, the EOA associated to these deployments redeems it.

Considerations

• It needs to be an EOA who does the redeems since the redeem function from Arbitrum can't be called by a contract.

• All of the actions within the three files happen at the same time.

Assumptions and internal logging

It's worth noting that the most probable, but still unlikely, cause of auto-redeem failure is insufficiency of L2 gas price submitted when creating the retryable ticket.

If a transaction is manually redeemed, it gets stored in the RedeemedHashes contract, in Arbitrum, for future queries.