feat: enhance messaging unwire scripts

[clauBv23]

Summary

• Adds direction-aware messaging unwire behavior for from, to, and both.
• Keeps one-way unwires narrow: from/to only set the relevant send-side DVN to the local DeadDVN, while both performs the full unwind with send/receive DeadDVN, executor zeroing, and peer removal.
• Moves messaging unwire input into chainsConfig/<chain>.yml under unwire.token_messaging and unwire.credit_messaging, selected with UNWIRE_CHAIN=<chain> / --unwire-chain.
• Skips status: DEPRECATED chains from normal wire/configure graphs while still allowing unwire to resolve them.
• Removes the old stage-level messaging.unwire.yml flow and updates chain templates.
• Adds/updates the unwiring runbook for asset unwire, pool chain full messaging unwire, Hydra two-phase messaging unwire, checker usage, and cleanup rules.

Operator Flow

Use the combined messaging target when TokenMessaging and CreditMessaging should be processed together:

STAGE=mainnet make unwire-chain-mainnet UNWIRE_CHAIN=<chain> CONFIGURE_ARGS_COMMON=--dry-run
STAGE=mainnet make unwire-chain-mainnet UNWIRE_CHAIN=<chain> CONFIGURE_ARGS_COMMON=--onesig

Use the split targets only when reviewing or proposing TokenMessaging and CreditMessaging separately:

STAGE=mainnet make unwire-token-messaging-mainnet UNWIRE_CHAIN=<chain> CONFIGURE_ARGS_COMMON=--dry-run
STAGE=mainnet make unwire-credit-messaging-mainnet UNWIRE_CHAIN=<chain> CONFIGURE_ARGS_COMMON=--dry-run

Pool chain deprecations use direction: both for both OApps after pool funds and credits are fully drained.

Hydra chain deprecations use two phases:

1. Phase 1 keeps TokenMessaging outgoing paths active for user exits by using token_messaging.direction: to, while CreditMessaging can use direction: both after credits are drained.
2. Phase 2 switches TokenMessaging to direction: both once the remaining exit path is no longer needed.

Validation

• git diff --check
• make -n unwire-chain-mainnet UNWIRE_CHAIN=glue-mainnet CONFIGURE_ARGS_COMMON=--dry-run
• make -n unwire-chain-mainnet UNWIRE_CHAIN=glue-mainnet CONFIGURE_ARGS_COMMON=--onesig

[changeset-bot]

⚠️ No Changeset found

Latest commit: 1584c55

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[Copilot]

Pull request overview

Updates the messaging “unwire” graph builder so that disabling an edge can be applied directionally (one-way vs two-way), avoiding unnecessary DeadDVN changes when only one direction is being unwired.

Changes:

• Replace the disallowed-edge Set with a Map that tracks the UnwireDirection per directed edge.
• Apply disableMessagingEdge conditionally per edge and omit receiveConfig for one-way unwires.
• Update disableMessagingEdge to accept an UnwireDirection and only set receiveConfig when direction is 'both'.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 12 out of 12 changed files in this pull request and generated 2 comments.

[Copilot]

Pull request overview

Copilot reviewed 12 out of 12 changed files in this pull request and generated 2 comments.

[tinom9]

This flow assumes no inflight messages between steps, which may be ok for most unwired chains, but I believe we should be more strict.

We don't want to be put in a position where we need to re-wire to deliver inflight messages.

Should we do the following?

1. Disallow sending funds to and from the chain. Only send-side to keep inflights deliverable.
2. After inflights have landed, unwire all token messaging.
3. Synchronize credits with local LP and local token balance so that users can withdraw?
4. We control credit messaging, so no need to worry about credit messaging inflights, we can unwire all at once.

[clauBv23]

After inflights have landed, unwire all token messaging.

Does this mean unwiring receive on the chains being deprecated?

If so, I avoided doing that in step 1 to prevent inflight messages from getting stuck. My thinking was that this could be handled in step 2 as part of the full wind down. In the meantime, no new messages should be received anyway, so it seems safe to keep the receive libs until the final step.

I'd prefer not to add a separate step just for this, since that would make the Hydra unwind a 3-step process. I'd like to keep it as simple as possible while still keeping it functional and safe.

The question is: Is there any vulnerability or edge case with keeping the receive libs until the final step?
If not, I'd prefer to keep this as a 2-step process rather than adding a third one.

[clauBv23]

Synchronize credits with local LP and local token balance so that users can withdraw?

I'm not sure I get what you mean here.

It is Hydra, there will be no local pool or balance. And as mentioned, users will get the funds out via ofts paths, will remove all credits before starting this part

[clauBv23]

Updated the pool-chain unwire flow in the runbook.

The key change is that pool deprecation should not full-unwire TokenMessaging in one step by default. Even after pool funds and credits are drained, there can still be in-flight outbound messages from the deprecated chain. If we remove destination peers immediately, those messages may get stuck and would require rewiring to deliver.

Recommended pool flow is now:

1. First run TokenMessaging with direction: from to stop new outbound messages from the deprecated chain.
2. In the same step, run CreditMessaging with direction: both, since credits should already be drained.
3. After confirming there are no in-flight messages, run TokenMessaging with direction: both to fully disconnect the mesh.

For very low-activity chains, a single full direction: both unwire may still be acceptable, but the two-step TokenMessaging flow is the safer default.

[Copilot]

Pull request overview

Copilot reviewed 14 out of 14 changed files in this pull request and generated 3 comments.