How I would run an APAC shift on Relay's queue for end users and integrators, and a working desk that finds any request from a hash, link or wallet and writes the reply and the engineering handoff.
End users ask where their funds are, why a transfer was refunded and why they received less. Integrators paste API errors, SDK timeouts and 429s. Impersonators target both.
Find the request, read both legs, answer in plain words, and hand engineering a case they can act on without a question back. Then turn the repeats into docs, macros and self-serve tools.
A support console on Relay's public API. It opens a case queue from the live request stream (failures, refunds, slow fills) with priorities and first-reply timers. Any request id, hash or wallet gives the three legs, the diagnosis, a reply in three languages and the handoff note. It also triages tickets, reads chain health and decodes errors.
| Takeaway | Why it matters |
|---|---|
| Most "not received" tickets are completed transfers | The help centre says it directly: success with no visible funds is usually the wrong network, a token not imported or a different account. The destination hash ends most of these in one reply. |
| Refunds are the second big queue | In a sample of 50 recent Base-origin refunds, SLIPPAGE was 26, DOUBLE_SPEND 10, EXECUTION_REVERTED 9. Each needs a different explanation and a different retry advice. |
| Integrators are a growing share | The JD says the integrator base doubled in six months. Their tickets need endpoint, body, response and SDK version up front, and an answer at engineer level. |
| Two changes this quarter will create tickets | Router 3.2 and a new approval proxy cut over on 26 Oct 2026 (old approvals, pinned addresses). /requests/v2 retires on 24 Nov 2026 and /requests/v3 needs an API key. Macros and an integrator notice should go out before each date. |
A cross-chain payments protocol by Uneven Labs (founded 2021, Series B led by Archetype and USV in February 2026). Users deposit on one chain and a solver fills on the other from its own capital, usually within seconds, then settles on Relay Chain. Relay Vaults were retired on 9 Oct 2026, with site withdrawals open to 31 Dec 2026.
| Surface | What it does | What support needs to know |
|---|---|---|
| relay.link app | Bridge and swap across chains, plus self-recovery at relay.link/withdraw | Every case has a transaction page; the full link is the one thing to ask for |
| Relay API and SDK | Quotes, execution, status, requests, webhooks; relay-kit for TypeScript | API keys from dashboard.relay.link; default limit 50 quotes per minute per key |
| Integrators | Wallets, marketplaces and aggregators route through Relay and can add app fees | The referrer field names the app; the user often does not know Relay was involved |
| Deposit addresses | Send-to-address flow with no wallet connection, open or strict mode | Wrong token, wrong chain and over or under payment each have their own rule |
| Chains | Live config lists 60 chains: 51 EVM plus Solana, Eclipse, Bitcoin, Hyperliquid, Tron, TON, XRP and Lighter | Chain health flags (disabled, deposits off, lagging, partial limits) come from /chains |
Fees users ask about: a $0.02 flat execution fee plus destination gas, swap cost, a platform fee from 0% (plain bridging) to 0.15% (minor swaps), and any app fee the integrator sets. Fees ↗
Three legs and seven statuses. Knowing which leg exists is most of the diagnosis.
| Status | What happened | What I tell the user |
|---|---|---|
| waiting | Quote created, no deposit indexed | Send the origin hash; do not resend. For a deposit-address order, check by the address: a regenerated address fills under a new request id while the old one keeps saying waiting. |
| depositing, pending | Deposit in, fill being prepared | Expected time and the request link. Bitcoin waits for confirmations. |
| submitted | Destination transaction broadcast | Here is the destination hash. |
| success | Delivered | Proof of delivery, then the checks: network, token import, receiving wallet. |
| refund | Returned on the origin chain, minus refund gas | The refund hash and the reason; it can arrive in the origin-swap token. |
| failure | Fill failed | Re-check first: a failure can still move to refund. With no refund leg, relay.link/withdraw or escalate. |
| unknown | Id never seen | Ask for the full transaction link. |
The desk ↗ draws these three legs for any request and writes the reply for the status it finds.
From the help centre's own articles, the execution-errors reference, and 50 real refunds and 20 real failures pulled from the public API on 19 October 2026.
| Ticket | Usual cause | Check first |
|---|---|---|
| "Bridged, nothing arrived" | Completed on a network the wallet is not showing, or to a different recipient | Status and destination hash; recipient vs sender |
| "Refunded, I wanted the token" | SLIPPAGE on a thin token | Slippage tolerance and size; suggest smaller size or slightly higher slippage |
| "I sent more and got it back" | DOUBLE_SPEND: a second deposit to an order already filled, or an app resubmitting | Sibling request ids in the same second; deposit-address mode |
| "Refund is less than I sent" | Refund gas, or the refund came back in the origin-swap token | Refund transaction token and amount |
| "Token never arrived" with a refund | DESTINATION_TOKEN_TRANSFER_REJECTED: the token's own transfer rules | Token contract; nothing Relay can override |
| NFT purchase refunded | ORDER_ALREADY_FILLED or ORDER_IS_CANCELLED via a marketplace | Referrer; someone else bought first |
| "Failed, where are my funds" | TRANSACTION_REVERTED with no refund leg, often the user's own origin transaction | failedTxHash on the explorer before escalating |
| Wrong token or chain to a deposit address | Outside the quote; only solver currencies are recoverable | relay.link/withdraw with the sending wallet; exchange-sent funds take another route |
| Integrator "timed out" | relay-kit stops polling after 2.5 minutes | Look up the request id: the fill may have landed later |
| Integrator 429 | Per-key rate limits, quoting on every keystroke | Debounce, webhooks or websocket, elevated limits via the dashboard |
| Approval or "contract changed" questions after 26 Oct | Router 3.2 and new approval proxy cut-over | Changelog; prepared macro for re-approval |
| "Relay support DMed me" | Impersonation; lookalike domains | Official channels are the chat on relay.link and support@relay.link only |
Each row is a sample in the desk's triage tab ↗.
Comparisons show up in integrator calls and in "why was it cheaper elsewhere" tickets. Aggregators also route to Relay, so some competitors are partners too.
| Alternative | Model | Where Relay differs |
|---|---|---|
| Across | Intent bridge: relayers front funds, an optimistic oracle settles | Same intent family; Relay leans on breadth of chains and same-flow swaps, including non-EVM chains |
| deBridge (DLN) | Intent orders filled by takers, strong on Solana | Close peer; Relay's single API covers bridge, swap and deposit addresses |
| Mayan | Solana-first swaps over Wormhole and its own auction | Relay covers more chains in one integration |
| Stargate (LayerZero) | Liquidity pools per asset and chain | Pool model vs solver capital; solver fills are usually faster for small transfers |
| Circle CCTP | Native USDC burn and mint | USDC only, with attestation wait; Relay fills instantly and swaps on either side |
| LI.FI / Jumper, Bungee, Squid, Rango | Aggregators that route across bridges | They can route through Relay: a user may file a ticket with the aggregator, the integrator, or Relay |
Read on 19 October 2026 across docs.relay.link, the live OpenAPI spec and support.relay.link. Each is a small docs fix of the kind the JD lists under self-serve.
| Observation | Detail | Fix |
|---|---|---|
| Status list | The v3 Get Status docs table still lists delayed; the v3 spec enum and the requests-v3 migration guide drop it. Unknown ids return {"status":"unknown"}, which no enum lists. | One status table, shared by docs and spec |
| Is failure terminal? | The rate-limit guide says to stop polling at success, failure or refund. relay-kit treats failure as non-terminal because a refund can follow. | Say "failure can still become refund" in the guide |
| refundTo default | The Refunds page says automatic refund is disabled without refundTo; the spec's /price parameter says it defaults to the recipient or user. | Align the two sentences |
| Undocumented codes | The spec has DEPOSIT_ADDRESS_MISMATCH, POOL_CAP_EXCEEDED, REFUND_RECIPIENT_IS_BLOCKED and MANUAL_REFUND_REQUIRED; the Execution Errors page does not describe them. | Add four rows |
| Blocked exchange error | The Unsupported Exchanges page names BLOCKED_WALLET_ADDRESS; the quote-errors table does not list it. | Add one row |
| Chain count | Docs pages say 85+, 80+ and 69+ chains; the live /chains config lists 60 and the status page 63. The higher numbers likely count chains supported in the past. | One count, with a link to the live list |
| Audit links | The two Zellic report links in the docs security table return 404. The files are in the same GitHub folder as Zellic-Relay-Settlement.pdf and Zellic-Relay-Protocol-Oracle.pdf. | Update two links |
These matter to support because integrators build their error handling from the tables, and support answers from the same pages.
| JD duty | My plan |
|---|---|
| Own front-line support in APAC hours (Sat to Wed) | Cover the queue while the existing team is offline; a written handover at the end of each shift: open cases, what is waiting on engineering, anything route-wide. |
| Respond with clarity and care, resolve what I can | Look up before replying; answer first, reason second, next step third; one ask at a time (the transaction link, never a seed phrase). |
| Investigate with backend logs, records, explorers | Request record first, then each leg on its explorer, then logs for the gap; check the status page and chain flags before calling it a bug. |
| Build fluency on on-chain flows for users and integrators | Run the main flows myself with small amounts: bridge, swap, deposit address, a refund (the docs offer a debug-force-refund referrer for testing), an SDK integration. |
| Escalate with enough context | The handoff format in §06: every id, both legs, timings, what I checked, the exact ask, what the customer was told. |
| Take a growing share of volume | Macros and the triage rules in the desk cut handle time on the repeat cases, leaving time for the hard ones. |
| Turn recurring issues into improvements | Tag every ticket by cause; a weekly note with counts, examples and one proposed fix per top cause (§07). |
| Communicate at the right level | Plain words for users; endpoint, body and response for integrators; a decision-ready summary for product. |
| Automation, docs, developer-portal tooling | Start with the docs findings above, an integrator ticket form, and a public status lookup modelled on the desk. |
An engineer should be able to act on the note without asking anything back. The desk writes this note for every request it opens.
[P2] Failed: Base → Solana, $9.90 Request: 0x1792…f7d3 · relay.link/transaction/0x1792…f7d3 Status: refund · failReason SLIPPAGE User: 0x2e93…bf2e · recipient 9rKQ…Szbh · Integrator: none In: 9.905006 USDC on Base · basescan tx Out: refund on Base, 2 s after deposit What I checked: slippage 3.00%, token liquidity thin, status page clear Ask: none, FYI pattern (SLIPPAGE share up this week) Customer told: refund link and retry advice
| Priority | When | Customer update |
|---|---|---|
| P1 | Funds not delivered and not refunded over $1,000, a refund that failed, or any security case | Within 4 hours |
| P2 | Late fill well past the quoted time, unindexed deposit, integrator production errors | Within 24 hours |
| P3 | Refund explained, user-side revert, quote errors | Same reply |
| P4 | Completed transfer the user cannot see, fees questions | Same reply |
The thresholds are my starting proposal; I would adopt the team's existing levels on day one.
"Every ticket is a signal" in practice: cluster by cause, fix the cause, measure the drop.
| Cause | Fix | Measure |
|---|---|---|
| Completed but not visible | A public status lookup that shows the three legs and the checks, linked from the chat widget's first message | Share of these tickets already success at first touch |
| Refund reasons | Plain-words reason and retry advice on the transaction page for the top five failReasons | Refund tickets per 1,000 refunds |
| Deposit-address mistakes | Accepted chain and token shown clearly before deposit; a recovery runbook | Time to resolution |
| Integrator errors | A ticket form asking for endpoint, body, response, SDK version; rate-limit usage per key in the dashboard | Time from first reply to reproduction |
| Impersonation | A pinned "official channels" note on X and in every macro footer | Reports per week |
The desk's last tab ↗ runs this clustering on a pasted week of tickets.
| Metric | Why |
|---|---|
| First reply time in APAC hours | The reason the role exists: overlap coverage. Split by end user and integrator. |
| Resolution without escalation | Rises as macros and lookups improve; a falling rate flags a new issue. |
| Escalations returned for more info | The quality check on handoffs. Target zero. |
| Tickets per 1,000 requests, by cause | Normalises for growth; shows whether a fix removed tickets. |
| Reopen rate | Catches replies that closed a ticket without solving it. |
| CSAT by cause | Low scores on refunds point to explanation, low scores on delays point to product. |
| When | What |
|---|---|
| Days 1 to 30 | Shadow the team; learn the backend logs, tools and escalation path; own my APAC hours on the queue; run every main flow with small amounts; keep a cause tag on every ticket. |
| Days 31 to 60 | Take a growing share of tickets end to end; ship macros for the top causes; fix the docs findings with the docs owner; first weekly signal note to product. |
| Days 61 to 90 | One self-serve or automation project with ticket counts behind it (status lookup or integrator intake form); a Chinese-language macro set for APAC users if the volume supports it. |