Fix Tron swap UX in the TRX/USDT flow

[pedromcunha]

Read Tron balances from TronGrid's fullnode endpoints instead of the solidity node, and confirm Tron transactions with getUnconfirmedTransactionInfo, so balances and approvals no longer wait on solidification.

Gate the same-chain completion shortcut on the step being atomic. Tron TRX/USDT, deposit-address routes and forced solver execution all report matching origin and destination chain ids while still requiring a solver fill, so keying on chain ids alone reported success before the fill landed and rendered the same-chain step sequence for them.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
relay-sdk-demo	Ready	Preview	Sep 8, 2026 7:27pm UTC

[github-actions]

Claude finished @pedromcunha's task in 1m 31s —— View job

---

📝 Docs Drift Check — Confidence: LOW (below configured floor: medium)

What changed: A Tron TRX/USDT swap-UX fix — balances now read from fullnode endpoints and transactions confirm via unconfirmed-receipt lookups, and the same-chain completion shortcut is gated so solver-filled same-chain routes (Tron, deposit-address, forced solver execution) wait for the fill. It also adds one new public SDK export, isSolverFilledStep, re-exported from @relayprotocol/relay-sdk.

Why I didn't draft: The behavior changes are captured by the changeset (which auto-publishes to the unified changelog), and the one new public export is a low-level helper with no obvious documented home — the SDK reference documents actions, createClient, and the /chain-utils subpath, but nothing lists standalone utility helpers, so whether it deserves a reference page is a judgment call rather than something the diff settles.

Pages likely affected:

• references/relay-kit/sdk/ — the new isSolverFilledStep export is now public API; a human may decide it warrants a short reference entry (closest structural sibling is chain-utils.mdx) or that it's an internal helper best left undocumented.
• references/relay-kit/sdk/adapters.mdx — the Tron adapter section could optionally note the improved transaction-confirmation timing, but that's implementation-level detail and likely doesn't need a prose change.

Suggested next step: manually open an issue or PR in relayprotocol/relay-docs if you want isSolverFilledStep documented. Do NOT use /publish-docs-pr — it will attempt to publish a low-confidence draft.

[github-actions]

Claude finished @pedromcunha's task in 1m 50s —— View job

---

Code Review — No issues found.

Reviewed 10 files, 245 additions / 24 deletions. Checked correctness, security, error handling, and repo guidelines.

What I verified

• solverFill.ts gating — isSameChainAtomic in transaction.ts:530 now only short-circuits confirmation for atomic (swap/send) same-chain steps, so deposit intents (Tron TRX/USDT, deposit-address, forced solver) correctly await confirmationPromise instead of reporting premature success. The Execute export chain (utils/solverFill.ts → utils/index.ts → src/index.ts export *) is intact, so @relayprotocol/relay-sdk resolves isSolverFilledStep for the UI import in steps.ts.
• UI step sequence — steps.ts:453 guards the same-chain branch on isSameChainId && !usesSolverFill, pushing solver-filled same-chain routes down the cross-chain path. The acknowledged hasDestinationTxHashes limitation (false when chain ids match) is compensated by the isInReceivingState (checkStatus === 'submitted') trigger for the receive step at steps.ts:637, so the receive state still activates.
• Tron balance/receipt reads — walletsolidity/* → wallet/* and getTransactionInfo → getUnconfirmedTransactionInfo are consistent with the stated goal (read pre-solidification state). Confirmation math (tip - blockNumber + 1) stays ≥ 1 for an included-but-unsolidified tx, and the reverted/OUT_OF_ENERGY path still throws. The 60s→90s timeout bump is a reasonable safety margin.
• Error handling — Balance fetch still surfaces both data.error and data.result trigger failures rather than returning a 0 balance. No secrets, no injection surface, all async paths awaited.
• Tests — New coverage exercises atomic same-chain (no fill wait), same-chain deposit (waits for fill), and the send atomic case, plus unit coverage of isSolverFilledStep.

One note rather than a finding: isSolverFilledStep keys solely on step.id === 'deposit', so correctness depends on the API always emitting deposit for intent-routed steps — the JSDoc documents this contract clearly, which is the right call.

[greptile-apps]

Confidence Score: 5/5

Safe to merge based on the verified same-chain execution behavior: solver-filled deposits wait for fulfillment and atomic sends retain immediate completion.

What we checked:

• Ran a deterministic Vitest harness through the SDK executeSteps flow with mocked intent statuses of pending, pending, then success.
• Observed the parent revision finished a same-chain deposit after a single status request, illustrating a premature completion relative to solver fulfillment.
• On the PR revision, the deposit completed after three status requests via solver fulfillment while an atomic same-chain send completed in one request, validating the updated logic that distinguishes solver-filled deposits from atomic transactions.
• Reviewed the code-paths that decide transaction completion and confirmed alignment with the observed outcomes through a targeted validation in the transaction decision logic and its solverFill classification.

Summary

• This change makes Tron balances and transaction receipts available before block solidification, and it prevents same-chain intent deposits from being reported complete before the solver finishes the fill.
• The same-chain completion behavior was exercised against both revisions. Before this change, a same-chain deposit completed after one status request despite pending solver status. With this change, the deposit waits through the pending responses until solver success, while an atomic same-chain send still completes from its origin transaction confirmation. This disproves the potential regression that the new solver-fill classification would delay atomic same-chain transactions.