Frax Ferry

A slower, simpler, more secure method of bridging tokens.

Motivation

• Too many bridge hacks from bugs, team rugs, anon devs, etc.

• Risks of infinite mints.

• Some chains have slow bridges (Arbitrum, Optimism, etc).

Benefits

• Risk is capped by token amounts in bridge contracts. No risk of infinite mints.

• Slower transactions give more time for bad batches to be caught and stopped, assuming they are not cancelled automatically by bots.

• Crewmembers can pause contracts so any issues can be investigated.

Risks

• Captain is tricked into proposing a batch with a false hash AND all crewmembers bots are offline/censured/compromised AND no one disputes the proposal.

• Reorgs on the source chain. Avoided, by only returning the transactions on the source chain that are at least one hour old.

• Rollbacks of optimistic rollups. Avoided by running a node.

• Operators do not have enough time to pause the chain after a fake proposal. Avoided by requiring a minimal amount of time between sending and executing the proposal.

• Centralization

Process

1. User sends tokens to the contract. This transaction is stored in the contract. embark(), embarkWithRecipient(), or embarkWithSignature().

2. Captain queries the source chain for transactions to ship.

3. Captain sends batch (start, end, hash) to start the trip. depart()

4. Wait at least 24 hrs.

5. Crewmembers check the batch and can dispute it if it is invalid. disputeBatch() or do nothing.

6. Non disputed batches can be executed by the first officer by providing the transactions as calldata. User receives their tokens on the other chain. disembark()

7. Hash of the transactions must be equal to the hash in the batch.

8. In case there was a fraudulent transaction (a hacker for example), the owner can cancel a single transaction, such that it will not be executed. jettison(), jettisonGroup(), removeBatches().

9. The owner can manually manage the tokens in the contract and must make sure it has enough funds.