// Debug RPC provider health issues for a chain. Use when alerts mention RPC failures, high latency, stale blocks, or provider errors. Diagnoses the issue and recommends fixes.
Check token balances for each leg of a warp route. Shows collateral locked (for collateral/native legs) and total circulating supply (for synthetic legs). Use when you want to inspect the current state of a warp route's liquidity.
First step of deploying a new warp route (steps 1–9). Reads a Linear ticket to extract token details and chain configuration, looks up mailbox addresses from the local registry, generates the deploy.yaml, runs the deploy, and optionally runs a send test. Follow up with /warp-deploy-update-owners.
Post-deployment ownership transfer and registry PR for a warp route. Transfers ownership from the temporary deployer address to real owners, adds CoinGecko ID, commits, and opens a registry PR. Run after warp-deploy-init completes deployment.
Debug validator checkpoint inconsistencies where some validators are behind others. Use when alerts mention "checkpoint inconsistency", "validators behind", or "inconsistent latest checkpoints", or when asked to debug validator sets, investigate validator delays, or troubleshoot metadata fetch failures for a chain. Defaults to default_ism app context if not specified.
Apply RPC URL changes for a chain. Use after /debug-rpc-provider has diagnosed the issue and recommended new URLs. The user invoking this skill is the confirmation gate.
Encode and decode raw Hyperlane messages to/from packed hex bytes using the CLI. Use when you need to construct a message for testing, inspect a raw message from logs or a transaction, or decode a warp transfer body.
| name | debug-rpc-provider |
| description | Debug RPC provider health issues for a chain. Use when alerts mention RPC failures, high latency, stale blocks, or provider errors. Diagnoses the issue and recommends fixes. |
Diagnose RPC provider health issues for a Hyperlane chain and recommend fixes.
/debug-rpc-provider <chain> [environment=mainnet3]
| Parameter | Required | Default | Description |
|---|---|---|---|
chain | Yes | - | Chain name (e.g., ethereum) |
environment | No | mainnet3 | mainnet3 or testnet4 |
MONOREPO_ROOT=$(git rev-parse --show-toplevel)
pnpm --dir "$MONOREPO_ROOT/typescript/infra" exec tsx scripts/secret-rpc-urls/debug-rpc-url-health.ts \
-e <environment> -c <chain>
Examine the output table and classify each RPC URL:
| Condition | Classification |
|---|---|
| Health = ✅, Latency < 500ms | Healthy |
| Health = ✅, Latency >= 500ms | Slow |
| Health = ⚠️ | Stale (block age 30-120s) |
| Health = ❌, has error | Dead |
| Health = ❌, chainId mismatch | Misconfigured |
Output the following structured information:
Summary: One-line description of the issue (e.g., "2 of 3 private RPCs are dead on ethereum")
Current URL status table: For each private RPC URL, show status (healthy/slow/stale/dead) and key metrics
Proposed new URL list: A concrete JSON array of the recommended new private RPC URLs. This should:
Format:
Proposed new RPC URLs for <chain> (<environment>):
["https://full-url-1", "https://full-url-2"]
Suggested action: Either:
/fix-rpc-urls to apply the proposed URL changes" if URLs need updatingIf you recommended URL changes in Step 4, end your response with the confirmation convention so the user gets an approve/reject button:
[CONFIRM: Fix RPC URLs for <chain>]
This MUST be the very last thing in your message. Do NOT run /fix-rpc-urls yourself — wait for user approval.
Note:
[CONFIRM: ...]is a Haggis-specific harness primitive — Haggis renders it as an inline approve/reject button. In other Claude Code contexts it is just text, so this skill is intended to be invoked from Haggis.
If all URLs are healthy and no changes are needed, skip this step.