## Fraxtal LayerZero Liquidity AMO
### Concept
Provide bridging liquidity so that users who bridge to Fraxtal via LayerZero can exit into the Fraxtal-native respective asset. We willu refer to Fraxtal-native FRAX as nFRAX and LayerZero FRAX as lzFRAX.

For this solution, a standalone contract is required which supports the LayerZero compose [interface](https://docs.layerzero.network/v2/developers/evm/protocol-gas-settings/options#lzcompose-option). The execution that follows is:
1. User initiates bridge on Blast to Fraxtal by burning lzFRAX with additional data in `tx 1`.
1. lzFRAX is minted to the standalone contract on Fraxtal in `tx 2`.
1. LZ executor calls the standalone contract with the data given in tx 1 in `tx 3`.
- lzFRAX is swapped for nFRAX
1. User receives nFRAX

## Solution: Curve pool with AMO

### Initial State
Fund a Curve nFRAX/lzFRAX pool with 250k each managed by an AMO.

### Bridge operation
- User provides slippage tolerance and recipient. Upon `tx 3`, standalone contract swaps with Curve and sends the output to the recipient.

### Rebalance Conditions
If the pool become imbalanced, do some operation to equally-weight the pool.

#### Scenario A: Curve pool has too much nFRAX
##### Solution 1: Arbitrage liquidity
1. Swap lzFRAX for nFRAX

Duration: 1 block

##### Solution 2: Manage liquidity
1. Withdraw nFRAX from Curve
2. Use Frax Ferry to bridge nFRAX to Ethereum
3. Use LZ bridge to bridge back lzFRAX to Fraxtal
4. Deposit lzFRAX to Curve

Duration: (2) 12 hours + (3) 5 minutes

#### Scenario B: Curve pool has too much lzFRAX
##### Solution 1: Arbitrage liquidity
1. Swap nFRAX for lzFRAX

Duration: 1 block

##### Solution 2: Manage liquidity
1. Withdraw lzFRAX from Curve
2. Use LZ bridge to bridge lzFRAX to Ethereum
3. Use Fraxtal native bridge to bridge back nFRAX to Fraxtal
4. Deposit nFRAX to Curve

Duration: (2) 5 minutes + (3) 15 minutes

### Challenges
#### Imbalanced Curve pool
##### Problem
The curve pool can be imbalanced from:
a. Bridges in one direction
b. Swaps in one direction
It's important to distinguish the two as the pool is permissionless. Meaning, anyone has the ability to imbalance the pool and trigger a rebalance. This is a DoS risk as if the pool is constantly rebalancing, there may not be sufficient liquidity to execute a bridge tx.
##### Potential Solutions
1. Arbitrage by team or bots
- Pros
- Team / bots earn arb profits
- Cons
- Additional assets must be held by team / bots to pay for swap
2. Rebalance pool
- Pros
- Does not require additional assets held
- Cons
- Additional mainnet gas cost
- Time spent in bridge processing

#### Swap amount out too high
##### Problem
A user may request more output token than what is allowed by the pool. This may happen if:
1. Pool is already imbalanced
1. Pool balance changes
a. A user requests an amount out in `tx 1` that is acceptable.
b. The pool changes balance before `tx 3`
c. `tx 3` attempts to execute and reverts because the pool now returns less output token
##### Potential Solutions
1. Allow users to pass in 0 `amountOut`
- Pros
- `tx 3` always executes
- Cons
- Puts user at risk of slippage loss
2. Give user lzFRAX instead of nFRAX (don't swap)
- Pros
- `tx 3` always executes
- Cons
- Requires user to either:
a. Manually swap on curve
b. Bridge lzFRAX to other chain
3. Create swap queue in standalone contract to execute by bot upon sufficient liquidity
- Pros
- User receives nFRAX
- Cons
- User does not receive funds at the time they expect
- Assumes pool will reach balanced state
#### Bridge amount limited by liquidity available
##### Problem
A whale who wants to bridge 500k lzFRAX is unable to receive 500k nFRAX in one tx as there is not sufficient liquidity in the Curve pool.
##### Potential Solutions
1. Whale receives 500k lzFRAX on Fraxtal and is responsible for swapping with curve.
- Pros
- TBD
- Cons
- Requires multiple Fraxtal txs
3. Require whale to bridge in multiple txs for nFRAX.
- Pros
- Whale receives all desired nFRAX
- Cons
- Requires multiple source txs
4. Team provides liquidity directly to whale
- Pros
- Only 1 tx for whale
- Cons
- Time/effort required by Frax team
#### Native frxETH is not a token
##### Problem
Native frxETH is the gas token and not an ERC20. Meanwhile, lzFrxETH is an ERC20.
##### Potential Solutions
1. Create a Curve pool with wrapped frxETH / lzFrxETH and unwrap the token in the standalone contract
- Pros
- Gives user the gas token upon receipt
- Cons
- Requires wrapping the gas token in the pool
#### Protocol changes gas token
##### Problem
The Fraxtal protocol upgrades gas token, changing the wrap-ability of frxETH and FRAX / FXS
##### Potential Solutions
1. Make the standalone contract upgradeable
- Pros
- Allows support of all Frax assets out-of-box
- Flexibility to support upgrade by modifying logic
- Cons
- Trust assumptions of upgradeability
2. Deploy only Frax assets that have and will not be used as gas tokens
- Pros
- Contract is immutable
- Cons
- Only partial support of LZ assets

## Proposed Solution
### Liquidity
- `nFRAX/lzFRAX`: $250k each
- `nsFRAX/lzsFRAX`: $250k each
- `nfrxETH/lzfrxETH`: $250k each
- `nsfrxETH/lzsfrxETH`: $250k each
- `nFXS/lzFXS`: $150k each
- `nFPI/lzFPI`: $100k each

Total ask: $2.5M

### Strategy
- LZ team provides initial Curve pool liquidity.
- Frax team manages imbalanced liquidity with PoRL (Proof of Rebalancing Liquidity) through swaps of the pool.
- If Frax PoRL is depleted in one direction (ie. many swaps from lzFRAX into nFRAX), Frax AMO will bridge the extra PoRL assets to Ethereum mainnet and return with the depleted asset.
- User provides their desired native asset `amountOut` as viewable from the pool. They can provide 0 `amountOut` if desired to receive `nFRAX` while assuming slippage risks.
- If the swap fails, user receives `lzAsset`.
- The standalone contract will be upgradeable, providing support for all LZ assets at the start.