Endgame L2 Tokens Bridging and Farming

Requirements:

  • Deploying NST, NGT, SNST and SDAO tokens on Arbitrum and Base.
  • Better security guarantees than simple multisig based bridges such as Wormhole.
  • SDAO and NGT farming with NST on the destination chain.
  • Build the bridge in a way it can later be upgraded to a general L1 to L1 bridge with multisigs.

Plan:

1. Bridging the tokens:

See https://github.com/makerdao/arbitrum-token-bridge/blob/dev/README.md

A similar bridge should be built on top of the Optimism stack to support Base.

2. Fast withdrawals:

Rely on rate-limited Subdaos solutions. For example:

  • Spark CCTP based liquidtiy network
  • Quant subdao to maintain Stargate liquidity (note that Arbitrum and Optimism are already supported on Stargate).

If these solutions are hard or non-attractive for a Subdaos to maintain, the current Teleport solution can be used up to a certain debt ceiling (enforcing a max throughput rate of the debt ceiling over 7 days).

Multisig Based Solutions

In case the main bridging solution or the fast withdrawals solution are not satisfactory in terms of the withdrawal period (for the main bridge) or the throughout (for fast withdrawals), a multisig and delay can be used to enhance/replace either.

3. L2 Farms:

  • As per the L1 farms, L2 farms will be deployed implementing the StakingRewards contract.
  • A new L1FarmProxy contract will be the target of VestedRewardsDistribution's token transfer on L1. It will then transfer the tokens through the bridge to L2FarmProxy.
  • The L2FarmProxy contract will wrap the L2 StakingRewards contract. Keepers and incentivised users will transfer the reward tokens from it to the L2 farm.

image
(https://excalidraw.com/#json=vfAubuKr9dj4bIavbTVqL,YXzuhSMPd1IBSbwq_BvdgQ)

4. Saving Rate:

  • Despite the original requirements of implementing a native L2 SSR, it might make sense to instead just bridge SNST to Arbitrum through the mechainsm decided on in (1), and rely on market forces (or a Subdao if needed) to supply liquidity for swapping with NST.
  • Apart from moving the complexity of the conversion to third parties, it allows to have the same conversion ratio as in L1 and it doesn't clash with Spark multichain plans.
  • As previously proposed by Phoenix Labs, a DSR oracle can be deployed to reduce the slippage in DEXs like Balancer.
Select a repo