Frax Finance ¤
English 🇰🇾
English 🇰🇾
  • Frax Ecosystem Overview
  • FXS & veFXS
    • Frax Shares (FXS)
    • veFXS
    • Gauges
    • FXS Distribution
    • FXS Smart Contract & Addresses
  • GOVERNANCE
    • Frax Governance Overview
    • How It Works
    • Advanced Concepts
    • Fraxtal Snapshot Voting
  • FRAX V1 - ORIGINAL
    • Original Design
    • Staking Contracts
    • FRAX ABI & Token Addresses
    • Frax V1 Pool ABI & Addresses
    • Core Frax Multisigs
  • FRAX V2 - Algorithmic Market Operations (AMO)
    • AMO Overview
    • AMO Minter
    • Collateral Investor
    • Curve
    • Uniswap v3
    • FRAX Lending
    • Decentralization Ratio (DR)
  • FRAX V3 - 100% CR AND MORE
    • Overview
    • Fraxtal
    • AMOs
    • RWAs
    • sFRAX
    • FXBs
    • sFRAX Token Addresses
    • sFRAX & FXB Multisigs
  • Bridging
    • Fraxferry
    • LayerZero x Stargate
    • Fraxtal Bridge
  • Frax Price Index
    • Overview (CPI Peg & Mechanics)
    • Frax Price Index Share (FPIS)
    • FPIS Distribution
    • CPI Tracker Oracle
    • FPI Controller Pool
    • veFPIS
    • FPIS Conversion / FPIS Locker
    • FPI and FPIS Token Addresses
    • FPI Multisigs
  • Fraxswap
    • Overview
    • Technical Specifications
    • Fraxswap Contract Addresses
  • Fraxlend
    • Fraxlend Overview
    • Key Concepts
    • Lending
    • Borrowing
    • Advanced Concepts
      • Position Health & Liquidations
      • Interest Rates
      • Vault Account
    • ABI & Code
    • Fraxlend Multisigs
  • Frax Ether
    • Overview
    • frxETH and sfrxETH
    • Technical Specifications
    • Redemption
    • frxETH V2
    • frxETH V2 Technical Details
    • frxETH Code & V2 Addresses
    • frxETH and sfrxETH Token Addresses
    • frxETH Multisigs
  • BAMM
    • Overview
  • Frax Oracle
    • Frax Oracle Overview
    • How It Works
    • Advanced Concepts
    • Fraxtal Merkle Proof Oracles
  • Guides & FAQ
    • FAQ
    • Staking
    • Uniswap Migration / Uniswap V3
    • Fraxswap / FPI
  • Miscellany
    • All Contract Addresses
    • Bug Bounty
    • Miscellaneous & Bot Addresses
    • API
  • Other
    • Audits
    • Media Kit / Logos
Powered by GitBook
On this page
  • Summary
  • Motivation
  • Benefits
  • Risks
  • Process

Was this helpful?

Export as PDF
  1. Bridging

Fraxferry

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

PrevioussFRAX & FXB MultisigsNextLayerZero x Stargate

Last updated 7 months ago

Was this helpful?

Summary

A 24-48hr token bridging solution designed and implemented by the Frax team.

Motivation

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

  • Risks of infinite mints.

  • Some chains have slow bridges, especially on return trip back to Ethereum (e.g. 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 crewmember 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.

Fraxferry