Conversation
Funding was documented only under third-party payouts, which understated it: the same partner wallet is the ForwardRequest sender for on-ramp bridge-out as well as off-ramp escrow funding. It now has its own page that both flows can point at. The old wording also said a transfer on another chain "cannot fund an order and is not recoverable". That is true of the XAI wallet address and false of the per-chain deposit addresses we monitor and bridge from, so it read as a denial of a service we actually offer. It is now scoped to the address it applies to, alongside the deposit-address path. Document the accepted tokens per chain. They are not uniform — Solana is USDC-only, Tron and TON are USDT-only — and a mismatched send is unrecoverable, so the list ships next to the addresses rather than being left for a partner to infer. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WGpoBHdy1H255cVJdS9oTi
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7436717c7a
ℹ️ 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".
|
|
||
| ## The wallet lives on XAI | ||
|
|
||
| `GET /deposit-addresses` returns the wallet address as `funding_wallet_address`. |
There was a problem hiding this comment.
The newly advertised /api/v1/partner/deposit-addresses operation is not added to openapi/swagger.yaml; a repository-wide search finds it only in this page and the changelog. Because the public raw specification and interactive API reference are generated from that file, consumers cannot discover the operation's authentication or response schema, and generated clients will omit it. Add the operation to the OpenAPI source alongside this documentation.
Useful? React with 👍 / 👎.
| The practical consequence: **an empty balance stops every order**, not just the | ||
| next one. Keep the wallet funded ahead of demand. You can read the balance at any | ||
| time with `GET /wallet/funding-balance`. |
There was a problem hiding this comment.
This warning is incorrect for the on-ramp flow that the page explicitly includes: openapi/swagger.yaml:2599-2604 documents send-out as an optional action after the order is already completed and the purchased crypto has landed in the wallet, so an initially empty balance does not stop the core on-ramp order. Telling partners to keep the wallet pre-funded for every order may make them transfer funds unnecessarily; scope this requirement to off-ramp and third-party payouts, while explaining that on-ramp send-out uses the newly purchased balance.
Useful? React with 👍 / 👎.
1 participant
Important
Do not merge until
Unigox/account#606is merged AND deployed to prod. This documentsGET /api/v1/partner/deposit-addresses, which does not exist yet. Merging tomainauto-publishes to developers.unigox.com, so landing this early advertises an endpoint that 404s.prod-accounthas nodeploy_on_push— merging #606 is not enough on its own.Why
A partner asked whether we provision Solana/EVM deposit addresses tied to their partner wallet, or whether getting USDC onto XAI was their step. The docs answered the second — and answered it wrongly.
Funding was documented only under third-party payouts. That understated it: the same partner wallet is the ForwardRequest sender for on-ramp bridge-out (
partner_onramp.go) as well as off-ramp escrow funding (partner_offramp.go:2024). It now has its own page both flows point at.The old wording also said a transfer on another chain "cannot fund an order and is not recoverable". That is true of the XAI wallet address and false of the per-chain deposit addresses we monitor and bridge from — 356 Solana→XAI deposits have completed in production. As written it read as a denial of a service we actually offer, so it is now scoped to the address it applies to.
What changed
api-reference/funding-your-wallet.md— states up front that it covers off-ramp, third-party payouts and on-ramp alike, names thesender_addressendpoint for each, then the XAI wallet, then the deposit-address path.third-party-payouts.mdkeeps a short funding paragraph and links out, so the flow still reads standalone.The token table is the load-bearing half
The chain list alone would be dangerous. The rules are not uniform and each mismatch is unrecoverable:
Linea is deliberately absent. Its USDC
chain_tokensrow is active, but itschainsrow isactive = falseand it is streams-only, so a Linea deposit is never monitored — exactly the unrecoverable case. (Worth noting separately:trades/internal/consts/chains.gostill listslineainSupportedBridgeOutChains. One outbound Xai→Linea intent, ever, 2025-04-25. Likely stale there too.)NEAR is absent because it is not a fundable chain-type — relay-quote lists it in
DEFERRED_CHAIN_TYPES, and the stored value is a NEAR Intents account id, not a sendable address.Verification
Matrix checked against relay prod (
chains.activeANDchain_tokens.active— both halves, which is what excludes Linea). No real allocated deposit addresses appear anywhere in the diff.🤖 Generated with Claude Code