UMIP-179: refund deposits to abandoned (orphaned/disabled) destinations

[droplet-rl]

Problem

A Deposit whose destinationChainId is not an active protocol chain — either never onboarded (e.g. a typo/unsupported chain id) or currently in DISABLED_CHAINS (e.g. Scroll) — is accepted on-chain (SpokePool._depositV3 does not validate destinationChainId) and then silently dropped from bundle consideration: expired-deposit refunds are defined against the destination chain's clock, which doesn't exist for these deposits. The input funds sit on the origin SpokePool indefinitely.

This was hit in production (a Base→Scroll deposit routed via a third-party integrator, ~$300 stranded). Recovering it today requires a manual admin action.

Change

Adds §Finding Abandoned-Destination Deposits: such a deposit is refunded to the depositor on the origin SpokePool once its fillDeadline elapses within the origin Bundle Block Range (origin clock — no destination reads). Plus one clause in §Identifying Bundle Block Ranges: a re-enabled chain resumes its bundle range from the re-enablement block.

Safety (no double-pay)

The refund is issued without a destination FillStatus check (the destination is unresolvable), so the spec must guarantee no repayable Fill can exist:

• Orphan (∉ CHAIN_ID_INDICES at the fillDeadline HubPool block): CHAIN_ID_INDICES is append-only, so absence at the fillDeadline ⇒ absence for the whole [deposit … fillDeadline] window ⇒ no SpokePool ever existed ⇒ no fill.
• Disabled (∈ DISABLED_CHAINS at both the deposit block.timestamp and the fillDeadline): the destination was disabled for the whole window; any Fill in a disabled interval is never bundled (the new re-enablement range clause), so a depositor refund can never be double-paid.
• Membership is resolved from on-chain event timestamps (deposit block / fillDeadline), never quoteTimestamp — so the rule is independent of depositQuoteTimeBuffer (which may be raised).
• Forward-only: gated behind an AcrossConfigStore VERSION bump; deposits whose fillDeadline already elapsed are not retroactively swept.

Notes

• Companion dataworker implementation (@across-protocol/sdk BundleDataClient) in a separate PR.
• Related to the in-flight [WIP] UMIP-179: Updates #602 (UMIP-179 updates) — happy to fold this in there instead if preferred; opened standalone for a focused review of this specific rule.
• Design thread: internal Slack (teleswap chain-101 discussion + the Scroll incident).

🤖 Generated with Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 875ebaa455

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Require a continuous disabled interval before refunding

When a destination is disabled at the deposit timestamp and again at fillDeadline but is re-enabled in between, this endpoint-only test marks the deposit abandoned even though fills during the enabled interval can be included in a Bundle Block Range and repaid. Since DISABLED_CHAINS is not append-only (the new re-enable clause explicitly allows removal), the spec needs to verify that the chain stayed continuously disabled for the whole deposit-to-deadline window; otherwise a depositor refund can double-pay a valid relayer fill.

Useful? React with 👍 / 👎.

[droplet-rl]

Good catch — fixed in f56614b. You're right that the two endpoint checks did not deliver the "disabled for the entire interval" property the parenthetical claimed. Because DISABLED_CHAINS is not append-only (unlike CHAIN_ID_INDICES, chains can be re-enabled), a disable → re-enable → disable sequence satisfies membership at both the deposit block and the fillDeadline block while exposing a middle window in which a Fill lands on an active destination, gets included in a Bundle Block Range, and is repaid — so an origin refund issued on the endpoint test could double-pay.

Condition 2 now requires continuous membership across the whole [deposit block, fillDeadline block] HubPool interval: present at both endpoints and not removed by any DISABLED_CHAINS update in between (i.e. every DISABLED_CHAINS value effective during the interval contains the destinationChainId). This is what the "disabled across the whole window" intent always required; the spec text just under-specified the verification.

[chatgpt-codex-connector]

Add abandoned refunds to the bundle accounting

Although this new section says abandoned-destination deposits are refunded via the relayer refund procedure, the actual accounting rules still only add deposit refunds for deposits that “expired or were deemed unfillable” and the procedure list above likewise only names expired/unfillable deposits. In bundles where an abandoned-destination deposit expires, a proposer following the spec can identify it here but never add its inputAmount/inputToken to the origin-chain relayer refund root, so the intended refund is omitted unless the relayer-refund/running-balance rules are updated to include abandoned-destination deposits explicitly.

Useful? React with 👍 / 👎.

[droplet-rl]

Fixed in f56614b. You're right that the section declared abandoned-destination deposits are refunded "identically to expired-deposit refunds" but the accounting rules only named expired/unfillable deposits, so a proposer following the letter of §Computing Running Balances would never add the inputAmount/inputToken. Wired them in explicitly:

• §Computing Relayer Repayments & Depositor Refunds procedure list — added Finding Abandoned-Destination Deposits.
• §Computing Deposit Refunds — abandoned-destination deposits refund inputAmount units of inputToken on the origin chain, identically to an expired deposit.
• §Computing Running Balances & Net Send Amounts, step 3 (Add deposit refunds) — the sum now includes deposits "deemed abandoned-destination refundable," with a note that these are evaluated against the origin Bundle Block Range (their fillDeadline is resolved on the origin clock), matching the reference-clock rule in the new section. In all other respects they are accounted for identically to an expired deposit — consistent with the SDK implementation, which reuses the existing updateExpiredDepositsV3 path (no new leaf type).

[chatgpt-codex-connector]

Cover active deposits that expire while the destination is disabled

If a deposit is made while the destination is still active and the chain is then disabled before a bundle covers its fillDeadline, this skip makes the re-enabled destination range start after the disabled gap, so the deadline is never processed by the normal expired-deposit rule. The new abandoned-destination rule also excludes it because DISABLED_CHAINS was not set at the deposit timestamp, leaving the origin funds stranded for exactly the class of deposits that become unprocessable during a later disablement.

Useful? React with 👍 / 👎.

[droplet-rl]

You've correctly identified a real class, but declining to auto-refund it here is deliberate rather than an oversight — and I've added an explicit scope note in f56614b so the boundary is stated rather than silent.

The class you describe is: destination active at deposit, added to DISABLED_CHAINS later, fillDeadline elapses inside the disablement gap. The reason it can't be folded into this rule is the same reason the disabled arm is anchored at deposit time in the first place: a deposit made while the destination was active may already have been validly filled and repaid before the chain was disabled (that pre-disable Fill lands in an active window and is bundled normally). Refunding such a deposit on the origin clock without a destination FillStatus check would double-pay against that repaid Fill. And a FillStatus check is exactly what this rule cannot rely on — the whole premise is that a disabled/orphaned destination's SpokePool may be unresolvable (dead RPC, or never existed). So this class is provably unsafe to handle under the "zero destination reads" constraint that makes the rest of the rule sound; it is not merely unhandled.

Note also this is narrower than "origin funds stranded whenever a destination is later disabled": deposits whose fillDeadline is still in the future when the chain is re-enabled settle normally on the live destination. Only deposits whose deadline falls inside the gap are affected, and only when the chain is disabled (not re-enabled) across that deadline.

Those deposits remain recoverable via a discretionary admin refund, exactly as today — this PR's goal is to prevent recurrence of the deposit-into-an-already-disabled-destination shape (the Scroll/ZeroWay incident), not to auto-recover every stranding path. Extending coverage to the active-at-deposit class would need a separate, destination-reading mechanism and is out of scope here.

[droplet-rl]

@codex thanks for the review — all three findings triaged, two fixed and one addressed with a scope clarification. Pushed as f56614b.

P1 — continuous disabled interval (correct, fixed). The disabled arm previously checked DISABLED_CHAINS membership only at the deposit block and the fillDeadline block. Since DISABLED_CHAINS is not append-only, a disable → re-enable → disable sequence passes both endpoints while exposing a bundleable-fill window in the middle → double-pay. Condition 2 now requires continuous membership across the whole [deposit block, fillDeadline block] HubPool interval (no re-enablement in between).

P2 — abandoned refunds in bundle accounting (correct, fixed). Added Finding Abandoned-Destination Deposits to the procedure list, extended Computing Deposit Refunds to abandoned deposits, and updated the running-balance deposit-refund step to include them — evaluated against the origin Bundle Block Range. This matches the SDK impl, which reuses the existing updateExpiredDepositsV3 path.

P1 — active-at-deposit deposits that expire during a later disablement (intentionally out of scope). Declined the auto-refund but added an explicit scope note. Such a deposit may have been validly filled and repaid before the destination was disabled; refunding it on the origin clock without a destination FillStatus check would double-pay, and this rule's entire premise is that a disabled/orphaned destination is unresolvable. It's provably unsafe under the zero-destination-reads constraint, not merely unhandled — these stay covered by discretionary admin refund, as today. Details on each inline thread.

[chatgpt-codex-connector]

To use Codex here, create an environment for this repo.

[droplet-rl]

🔎 View trace

[droplet-rl]

Noted — this is the automated notice that Codex can't run a re-review here until a Codex cloud environment is configured for the repo (a maintainer action via the linked settings). No code changes are warranted for this message.

Nothing is pending on my side: the substantive review feedback was already addressed in f56614b — the continuous-disablement fix (P1), the abandoned-refund accounting wiring (P2), and a scope note on the intentionally-excluded active-at-deposit class (P1). The updated diff is ready for re-review either by a maintainer directly or by Codex once the environment is set up.

[droplet-rl]

🔎 View trace