Feat/share ccip bridge

[crispymangoes]

PR Scope Details

Core Contracts

1. DestinationMinter.sol (DM)
2. DestinationMinterFactory.sol (DMF)
3. SourceLocker.sol (SL)
4. SourceLockerFactory.sol (SLF)

Sequence of Main Operations for Contracts

1. Factory Contract Deployments:
   • SLF on source network && DMF on destination network.
2. Setup:
   • setDestinationMinterFactory() such that they are properly connected.
3. Create new pairs of SL & DM for a specified ERC20 shareToken via call: SourceLockerFactory.deploy()
   • High-Level: sends a series of msgs via CCIP to DMF and back (callback) to deploy a new SL && DM pair.
     • 1st msg (SLF -> DMF): deploys new DM w/ specs from msg from SF.
     • 2nd msg (DMF -> SLF): callback where SourceLocker.setTargetDestination() is finally called that finishes the setup of the DM & SL pair for said ERC20 shareToken param specified in initial deploy() call
4. SL locks up shares to bridge a mint request to DM, where the representation of the Source Network Shares is minted on Destination Network.
   - Likely setup to start:
   • A-Tier Cross-Chain-Locker-Minter (CCLM) Pair:
     • Arbitrum SLF && Mainnet DMF (Mainnet representation of Arbitrum yields)
   • B-Tier CCLM Pairs:
     • Alt-Networks SLFs && Arbitrum DMFs (Aggregation of alt-networks share token representations on Arbitrum, all distilled into the A-Tier CCLM Pair

[0xEinCodes]

Just some small changes. This is an exciting PR man, awesome work! We discussed some bigger picture aspects such as:

1. If there is any risk with the destinationShares being used in a destination chain protocolwith liquidation. This is a teaser to the possible areas that cross-chain shares could be used in to help "aggregate" yields and whatnot across the networks. We are leaving it to figure out later though and is outside of the scope of this PR so all good.
2. Another "Future" thing to consider that we chatted about is how destination chain protocols who provide liquidity mining or some type of reward setup would work with cross-chain shares such that they could get all yield (from the shares as well) on the destination chain itself. This is not in scope for this PR though, and could be handled via arbitrage as you had pointed out in our chat.

[0xEinCodes]

Same for this error, did we want to outline the amount of fees that was erroneous? Or is it just self-explanatory since they are user input params again?

[crispymangoes]

So this error only bubbles up if the user specified maxLinkToPay is less than the fees it would cost to send the bridge TX. So we could probably add in 2 args, the user specified max, and the actual fees being charged. However I dont think etherscan knows how to process custom errors, so this would only help people interacting with our contracts via some dev env that tells them.

[0xEinCodes]

Interesting that Etherscan is limited in that sense. So how would this pop up on etherscan if it were to revert because of this? If nothing can be done about it so it helps users, then that is fine to leave this unchanged.

[0xEinCodes]

Caller will have to approve LINK to be sent to this DestinationMinter, add note in the natspec?

[0xEinCodes]

On that note, do we want to have a revokeApprovals at the end of this function for LINK?

[crispymangoes]

Hmmm that is a good question. The router address is verified to be safe, and these contracts will not be holding any customer funds that are LINK. So it would probably only help us if for some reason the router did not transfer the link it said it would, and the LINK contract had ERC20 breaking logic like USDT where we revert when going from non zero allowance to non zero allowance.

[0xEinCodes]

True, but since we know that is not the case with the LINK contract, are you saying that we do not need to have a revokeApprovals applied here?

[0xEinCodes]

I've looked through the changes, and discussed any lingering ones with you async. Any that are lingering will be added to the fix branch once the audit report is received from Macro.