feat: universal bridge adapter

[mrice32]

This modifies the SpokePool to support incentives to move tokens to other chains. This is done by establishing a defined ordering of deposits and fills on each chain and rewarding depositors and relayers for moving the tokens towards the right running balance.

Specific changes:

• To avoid frontrunning and allow depositors and relayers to lock in their reward, a running count of the aggregate amount of funds is tracked for both deposits and fills. Depositors and relayers can then pass in a maxCount to cap the amount of capital coming in ahead of them that they did not anticipate.
• Both LP fees and relayer fees can now be negative.
• The slow fill process/struct includes a new value, called payoutAdjustment. This enables the fees/rewards that would typically be passed on to a relayer to be passed on to the end-user in the case of a slow fill.
• When relayers take refunds on other chains, their impact is not considered on this chain or the other chain. This means that the dataworker will need to "deprioritize" their ordering and give them the least favored positioning within the bundle.

[socket-security]

Socket Security Pull Request Report

👍 No new dependency issues detected in pull request

Pull request report summary

Issue	Status
Install scripts	✅ 0 issues
Native code	✅ 0 issues
Bin script confusion	✅ 0 issues
Bin script shell injection	✅ 0 issues
Unresolved require	✅ 0 issues
Invalid package.json	✅ 0 issues
HTTP dependency	✅ 0 issues
Git dependency	✅ 0 issues
Potential typo squat	✅ 0 issues
Known Malware	✅ 0 issues
Telemetry	✅ 0 issues
Protestware/Troll package	✅ 0 issues

Bot Commands

To ignore an alert, reply with a comment starting with @SocketSecurity ignore followed by a space separated list of package-name@version specifiers. e.g. @SocketSecurity ignore foo@1.0.0 bar@2.4.2

Powered by socket.dev

[nicholaspai]

meta level comment: I think it'd be useful to draft the UMIP changes that would lead to this implementation change. I recall when writing the original UMIP that we wish we had made changes to the contract to make the UMIP easier to write

[nicholaspai]

Does _fillRelay have any new divide by zero or underflow/overflow checks we need to add now that the fees can be negative?

[mrice32]

I can't think of any -- can you? The total fees cannot be 100% or -100%. They are capped at +-50%, so I think the remaining amount is guaranteed to always be >0.

[nicholaspai]

Did a first pass review, haven't reviewed tests yet only solidity files

[nicholaspai]

just curious, why fillAmountPreFees here?

[mrice32]

Because the method is responsible for removing the LP fee from that to compute the "liabilities" that this chain will have to pay out as a refund. Does that make sense?

[nicholaspai]

This LGTM but can you explain the following new params:

• local repayment: can repayment chain still be set to any chain? When is this true vs false? What's the purpose?
• payoutAdjustment: How will this be used by dataworker?

[mrice32]

This LGTM but can you explain the following new params:

• local repayment: can repayment chain still be set to any chain? When is this true vs false? What's the purpose?
• payoutAdjustment: How will this be used by dataworker?

I added explanations in the description. Will also look into adding more comments about this in a follow up!

[pxrl]

Maybe this is premature, but is there a gas optimisation by making these two if statements mutually exclusive? For example:

        if (startingFillAmount == 0) {
            if (totalFillAmount - endingFillAmount > 0) {
                fillCounter[token] += _computeAmountPostFees(totalFillAmount - endingFillAmount, realizedLPFeePct);
            }
        } else {
        // If this is not the first fill, remove the partial fill that was previously assumed (startingFillAmount > 0).