This guide is specific to SuperSwap routes (anything touching PulseChain,
toChain=369 or fromChain=369). LI.FI and Near Intents routes have their own recovery models β see the Error Handling guide for those.The Guarantee
For every SuperSwap transaction your user signs, one of three things happens:- The swap completes and the user receives their destination token. β
- The DEX leg fails after 3 automatic retries β bridged USDCh lands in the userβs wallet as a fallback. β οΈ
- The flow is abandoned by the user (step 1 signed, step 2 not signed) β funds wait in the InboundReceiver contract until the user or support completes the flow. π
The SuperSwap State Machine
PollGET /v1/status?provider=superswap&txHash=...&fromChain=...&toChain=369 to observe the state. Every swap moves through the following sequence:
| Status | Meaning | Terminal? | User action |
|---|---|---|---|
INITIATED | Deposit registered on InboundReceiver, waiting for bridge dispatch | no | Wait |
BRIDGING | Hyperlane message in flight from source chain | no | Wait (~2β3 min) |
BRIDGE_CONFIRMED | Message delivered on PulseChain, about to call DEX | no | Wait |
SWAPPING | Piteas DEX swap executing | no | Wait |
COMPLETED | Output token delivered to userβs wallet | yes β | Stop polling |
FALLBACK_SENT | DEX swap failed after 3 retries β USDCh sent to user | yes β οΈ | See Fallback Recovery |
FAILED | Unrecoverable failure (very rare) | yes β | Contact support |
COMPLETED is 3β5 minutes (Hyperlane delivery dominates).
Failure Modes and Recovery
1. Happy path β
Normal execution. Nothing to handle.Exception for
USDCh β USDC outbound: that specific route uses the direct Warp Route path which has no DEX step, no Hypermid fee, and therefore no fallback path β it either succeeds 1:1 or the source tx reverts before any funds leave the userβs wallet. If you ever do see a FALLBACK_SENT for this route, itβs a bug β please contact support with the tx hash.
- DEX swap fails after retries (
FALLBACK_SENT) β οΈ
What happened: The bridge delivered USDCh on PulseChain, but the Piteas DEX swap reverted 3 times in a row. This can happen when:
FALLBACK_SENT) β οΈ- The output token has very thin liquidity at this size
- Piteas is temporarily unavailable or returning stale quotes
- Slippage is too tight for current market conditions
sendFallback(claimId, reason) on the Receiver contract, which transfers the bridged USDCh directly to the userβs wallet. Status transitions to FALLBACK_SENT.
What the user sees: USDCh (0xa5B0D537CeBE97f087Dc5FE5732d70719caaEc1D) in their PulseChain wallet, instead of the requested token.
What the user / integrator does: Nothing required β funds are safely in their wallet. They can:
- Swap USDCh manually on piteas.io when liquidity recovers
- Use USDCh directly (itβs a working PulseChain stablecoin)
- Keep it as a stablecoin balance
FALLBACK_SENT in status, display a message like:
βYour bridge completed, but the PLS swap couldnβt execute at current rates. Youβve received USDCh (a PulseChain stablecoin) in your wallet instead. You can swap it to PLS later at piteas.io, or hold it as a dollar-pegged balance.β
- Multi-step flow abandoned by the user π
What happened: For non-USDC source tokens (e.g. ETH β PLS), the user signed step 1 (LiFi swap into the InboundReceiver) but never signed step 2 (the EIP-712 registration) β they closed the tab, denied the signature prompt, or lost connection.
What happens automatically: The USDC sits in the InboundReceiver contract on the source chain. A background scanner logs [InboundReceiver] Unregistered USDC deposit ... once per deposit (deduped) so support has a record.
What the user does to recover: Re-run the registration call with the original tx hash. They need to call POST /v1/inbound-receiver/register with the EIP-712 signature. If your integration lost state, this flow can be reconstructed:
The signature must be produced by the same wallet that sent the Step 1 transaction (
tx.from). The backend checks this and rejects mismatches with INVALID_SIGNATURE.4. Bridge message delivered but executor RPC flaky π
What happened: Hyperlane delivered USDCh to the Receiver contract, but the backendβs PulseChain RPC is returning stale data or 5xx errors. The executor canβt callexecuteSwap() yet.
What happens automatically: The executor retries on its standard interval, with automatic failover across 4+ PulseChain RPC endpoints (Pulse mainnet, g4mm4, publicnode, etc.). Status stays BRIDGE_CONFIRMED until the RPC recovers.
What the user does: Wait. In almost all cases this resolves within 1β2 minutes.
5. Hyperlane message fails to deliver (extremely rare)
What happened: The source-chain transaction emitted a valid Hyperlane dispatch but the message was never delivered on PulseChain. This is vanishingly rare; Hyperlane has its own redundant relayer infrastructure. What happens automatically: None at the protocol level. If you see status stuck inBRIDGING for more than 1 hour, contact support.
What support does: Hyperlane exposes manual delivery tools; support can nudge the message through if needed.
6. PLS gas sponsorship fails (non-PLS output)
What happened: Your user received WPLS or HEX, but the post-swap PLS airdrop (so they have gas to transact their new token) didnβt go through β typically because the executorβs own PLS balance is temporarily depleted. What happens automatically: The swap itself completes normally; only the gas sponsorship skipped. Status is stillCOMPLETED.
What the user does: Fund their PulseChain wallet with PLS from an exchange, or ask support for a small top-up.
7. User sent tokens to the wrong address
Out of protocol scope. If a user sends USDC to an address unrelated to the InboundReceiver, we canβt recover it β that tx never touched our infrastructure. Direct users to the original recipientβs owner.What Your Integration Should Do
When handling SuperSwap on the frontend:- Always poll
/v1/statusuntil a terminal state. Donβt assumeCOMPLETEDafter a fixed timeout. - Handle
FALLBACK_SENTas a success-with-caveat, not a failure. The user got their money; they just got USDCh instead of their requested token. Your error-handling UI shouldnβt scare them. - Retain the Step 1 tx hash for multi-step flows β store it in local storage or your DB so users can resume the registration if they drop off.
- Donβt let users retry Step 1 on a transient error. If registration fails, send them back to the signature prompt, not the swap prompt β the funds are already bridged, they just need to sign.
- Display the
afterStep1flow as 2 actions, not 1. Users who think theyβve already paid will bail on the EIP-712 prompt (βwhy am I signing again?β). Label it clearly: βAuthorize delivery on PulseChain β free, no gas.β
Support Recovery
ForFAILED statuses or edge cases not covered above, open a support ticket with:
- Source tx hash (the LiFi or direct swap tx on the source chain)
- Wallet address (the userβs address, same one that signed)
- Requested output token (e.g. WPLS address on PulseChain)
- Timestamp (approx)
- Status transitions observed (copy the
/v1/statusresponses)
sendFallback(), or nudge Hyperlane delivery β whichever the situation needs.
Contact: support@hypermid.io or status.hypermid.io for live incident visibility.
Key Contract Addresses
For direct on-chain recovery verification:| Contract | Chain | Address |
|---|---|---|
| InboundReceiver | Base | 0x4b2C166EF372aa7f7cf8fC476DE3D3E69926cf78 |
| HypermidSender (Base) | Base | 0x1F5aF4535230a5D14336b436080a05Cf61611608 |
| HypermidSender (ETH / Arb / OP / Polygon / Unichain) | Multi | 0x191741c8aAd6Cd33A5Bd5B4B8C2406d411716268 |
| HypermidReceiver | PulseChain | 0x191741c8aAd6Cd33A5Bd5B4B8C2406d411716268 |
| USDCh token | PulseChain | 0xa5B0D537CeBE97f087Dc5FE5732d70719caaEc1D |
| Piteas Router | PulseChain | 0x6BF228eb7F8ad948d37deD07E595EfddfaAF88A6 |
| Hyperlane Mailbox | PulseChain | 0x56176C7Fb66FdD70ef962Ae53a46A226c7F6a2Cc |