Weaknesses

#1: Bridging from L1 to L2

Due to the asynchronous behavior of bridging and the fact that it's not possible to get -onchain- the updated gasPrice of L2 (unless one would request it from an oracle which would increase the cost of using the protocol), a lot of methods are placed in order to be able to respond to the multiple scenarios that may arise from partial or complete bridging collapse.

These scenarios cause the involvement of third parties that increase the risk of failure for using the protocol, risk that could be completely suppressed if there was no bridging, and ETH transfers to Accounts would happen in L2 directly.

Hard-coded gasPrice for L2

The most severe implication of this weakness is the hard-coded gasPrice mentioned above. If at any point this value is not enough for the L2 execution (due to a high flow of transactions in Arbitrum, for example), the auto-redeem feature wouldn't be possible, so an Akash deployment would have to manually redeem the transaction, making the involvement of this separate network a very important element of the system.

EOAs for manual redeems

Each Akash deployment is uploaded to the network through a containerized file which contains the private key of the EOA in charge of redeeming each L1 transaction that could have failed when being automatically redeemed.

This means that technically speaking, the owner of each provider of each deployment have access to this raw private key and could steal the funds at any point, halting the manual-redeem mechanism. Only audited providers are being used in the deployments (to avoid any wrong doing), but this situation still presents a trust assumption which goes against the trustless philosophy that this protocol is trying to achieve.

Cost of usage

By removing the bridging mechanism, the cost of using the protocol would be reduced considerably since all the computation in L1 would disappear.

#2: Centralization vectors

These are:

• The ownership of the proxy contracts that control the system. Although, the end goal is to completely remove it and make the protocol immutable, and only allow the addition or removal of implementations/facets through minimized DAO governance.

• Since an EOA is who manually redeems L1 bridging transactions that weren't auto redeemed, it means that there has to be an entity monitoring and manually funding these EOAs of each deployment in case funds run low.

• One front-end is hosted in IPFS through ENS and EthDNS using Fleek, which in the end centralizes the hosting to the Fleek account holder. For a complete decentralization of the front-end, an IPFS cluster would be necessary.

#3: Possible MEV attacks

In order to avoid malicious MEV being done to your swaps, such as sandwich attacks, it is always advisable to do offchain the calculation of the minimum amount of tokens you'd expect to receive after the swap.

All calculations in this protocol are onchain, so technically speaking, that would leave the door open for anyone to maliciously attack the protocol.

The good thing (until this moment) is that L2 swaps occur in Arbitrum which only uses one sequencer for block production which is controlled by Offchain Labs (aka them), so this type of negative MEV is not actually possible.

Once they decentralize their Sequencer for a network of permissionless Sequencers, it needs to be seen if the algorithm they’ll use will allow negative MEV to happen. The reason of this mention is that there are conversations that stipulate that Arbitrum might be designing an algorithm that would forbid the application of negative MEV.

If this turns out to be true, no change would need to be done in how the protocol performs its swaps. But if it’s not, then a modification for how minOut is calculated would need to take place.