[evm]: cross-chain partial fills for IntentGatewayV2#980
Draft
seunlanlege wants to merge 1 commit into
Draft
Conversation
Member
Author
|
Would be cool to add simplex, sdk & indexer support to this PR as well |
5 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds partial fills for cross-chain orders to
IntentGatewayV2. Previously cross-chain fills were all-or-nothing; this lets multiple solvers each fill a slice of a cross-chain order, mirroring the existing same-chain partial-fill behaviour.Design
The core invariant: every escrow movement uses a single monotonic
_cumulativeReleased(escrowTotal, filled, totalRequired)function, so across any split — and regardless of cross-chain message arrival order — the redeemed slices plus any cancel refund sum to exactly the escrowed amount, with rounding dust deterministically landing in the completing fill._fillCrossChain— partial-aware: accumulates_partialFills, pays the beneficiary pro-rata, clears_filledon partial / keeps it on completion, and dispatchesRedeemEscrowPartial(non-finalizing) orRedeemEscrow(finalizing). Output-calldata orders still require single-fill completion (PartialFillNotAllowed).onAccept— newRedeemEscrowPartialkind releases a proportional slice without finalizing (escrow stays open, fee pot left for the completing redeem). The completingRedeemEscrowfinalizes and forwards the fee pot (completing-solver-takes-all)._cancelFromSource/onGetResponse— proves each output's_partialFillson the destination via a GET request and refunds only the proven-unredeemed fraction, never the raw remaining escrow, so in-flight redeems stay covered. The deadline gate makes the post-deadline proof a final snapshot._cancelFromDest— reads_partialFillslocally and refunds the unredeemed fraction (no proof needed; freeze + snapshot are atomic).Escrow proofs match values to inputs by storage key (GET responses come back sorted by key, not request order).
EscrowReleasednow fires for every source-side release (including partial redeems) and carries the solver.placeOrdernow enforcesinputs.length == outputs.lengthand rejects zero-amount outputs (both would otherwise strand escrow).Testing
forge test --match-contract IntentGatewayV2and the reentrancy suite — 125 tests pass. New tests cover: proportional release + two-solver completion, non-finalizing source redeem, cancel refunding the unredeemed fraction, in-flight-redeem-after-cancel consistency, the fully-filled-cancel race (refund 0, fee pot withheld for the completing solver), multi-token value-by-key matching, double-cancel idempotency, the calldata guard, the placeOrder validations, and a_partialFillsstorage-slot guard.Follow-ups (out of scope)
RedeemEscrowPartial+ cross-chainPartialFill, construct partial cross-chain fills.intents-coprocessorpartial support.