feat: support TON destination bridging

[ted-palmer]

No description provided.

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
relay-sdk-demo	Ready	Preview, Comment	Jun 17, 2026 5:11pm

[github-actions]

Claude finished @ted-palmer's task in 1m 24s —— View job

---

Code Review

• Gather context (diff, commits, sibling utils, ChainVM type)
• Review correctness, security, error handling, repo guidelines

Code Review — 1 issue found

1. NOTE Correctness: extraneous prefix char in friendly-address regex
   packages/ui/src/utils/ton.ts:9 — the character class [EUkq0] includes q, but the comment directly above only documents EQ/UQ (mainnet) and kQ/0Q (testnet). No valid TON tag byte encodes to a leading q, so this allows an invalid prefix like qQ... to pass. Harmless in practice (it only over-accepts, never rejects a valid address), but it looks like a typo and diverges from the comment. Suggested fix: /^[EUk0]Q[A-Za-z0-9_-]{46}$/. Fix this →

Other observations (not blocking):

• The friendly-address regex requires the 2nd char to be Q, which holds for basechain (workchain 0) addresses — i.e. effectively all user wallets. Masterchain (workchain -1) friendly addresses encode a different 2nd char, but those aren't user destination addresses, so this is fine for the use case.
• tonvm is correctly part of the SDK ChainVM union (packages/sdk/src/types/RelayChain.ts:16), so the new branch in isValidAddress type-checks.
• The new file matches the sibling convention (tron.ts, lighter.ts) exactly — exported { id } const plus an isXAddress regex helper. The raw-address regex ^-?\d+:[a-fA-F0-9]{64}$ correctly models <workchain>:<32-byte hex>.

No correctness, security, or error-handling problems found. Reviewed 2 files, 19 lines changed.

[github-actions]

Claude finished @ted-palmer's task in 1m 11s —— View job

---

📝 Docs Drift Check — No docs impact

This PR does not touch surfaces that require a relayprotocol/relay-docs update.

The changes are confined to internal UI utilities — a tonvm branch added to the isValidAddress helper and a new TON address-validation util. No public SDK export, hook, widget prop, provider API, or wallet-adapter interface changed, and no TON adapter ships here (so the adapter reference's vmType list is unaffected).

[alexanderattar]

Seems like claude found a real issue above? I think it's not major, but should still probably be fixed

[github-actions]

Claude finished @ted-palmer's task in 32s —— View job

---

Code Review — No issues found.

The previously flagged issue is resolved — tonFriendlyAddressRegex no longer contains the extraneous q and now reads /^[EUk0]Q[A-Za-z0-9_-]{46}$/, matching the documented EQ/UQ/kQ/0Q prefixes in the comment above it.

Verified:

• ton.ts matches the sibling convention (tron.ts, lighter.ts) exactly — exported { id } const plus an isXAddress regex helper.
• The raw-address regex ^-?\d+:[a-fA-F0-9]{64}$ correctly models <workchain>:<32-byte hex>.
• The new tonvm branch in isValidAddress type-checks against the SDK ChainVM union.

Reviewed 2 files, 19 lines changed. Checked for correctness, security, error handling, and repo guidelines compliance.

[github-actions]

Claude finished @ted-palmer's task in 39s —— View job

---

TON Destination Bridging — Review Follow-up

• Gather context (diff, commits, ton.ts, address.ts)
• Verify the regex issue flagged in the earlier review
• Confirm current state

Result

The issue flagged in the earlier review (extraneous q in the friendly-address character class) has already been fixed in commit 20cb6c6f (fix: claude feedback).

packages/ui/src/utils/ton.ts:9 now reads:

const tonFriendlyAddressRegex = /^[EUk0]Q[A-Za-z0-9_-]{46}$/

The character class is now [EUk0], which matches exactly the four documented prefixes — EQ/UQ (mainnet bounceable/non-bounceable) and kQ/0Q (testnet) — and no longer over-accepts an invalid leading q. The regex is consistent with the comment directly above it.

No further changes are needed. The rest of the PR looks good:

• tonvm is correctly part of the SDK ChainVM union, so the new branch in isValidAddress (packages/ui/src/utils/address.ts:94) type-checks.
• The raw-address regex ^-?\d+:[a-fA-F0-9]{64}$ correctly models <workchain>:<32-byte hex>.
• The new file matches the sibling convention (tron.ts, lighter.ts).

[github-actions]

Claude finished @ted-palmer's task in 41s —— View job

---

Code Review

• Gather context (diff, commits, ton.ts, address.ts, sibling utils)
• Review correctness, security, error handling, repo guidelines

Code Review — No issues found.

Verified:

• tonFriendlyAddressRegex (packages/ui/src/utils/ton.ts:9) reads /^[EUk0]Q[A-Za-z0-9_-]{46}$/ — the character class [EUk0] matches exactly the four documented prefixes EQ/UQ (mainnet) and kQ/0Q (testnet), 48 chars total. The earlier-flagged extraneous q is gone.
• tonRawAddressRegex ^-?\d+:[a-fA-F0-9]{64}$ correctly models <workchain>:<32-byte hex>, including the optional negative masterchain workchain.
• The new file matches the sibling convention (tron.ts, lighter.ts) exactly — exported { id } const plus an isXAddress regex helper. (Siblings don't use // ABOUTME: headers, so the new file matching their style is correct.)
• The new tonvm branch in isValidAddress (packages/ui/src/utils/address.ts:94) type-checks against the SDK ChainVM union and follows the existing per-VM dispatch pattern.
• Changeset is a correctly-scoped patch to @relayprotocol/relay-kit-ui.

Reviewed 3 files, 24 lines changed. Checked for correctness, security, error handling, and repo guidelines compliance.
• ted/ton-destination-address-support

[github-actions]

Claude finished @ted-palmer's task in 1m 12s —— View job

---

📝 Docs Drift Check — No docs impact

This PR does not touch surfaces that require a relayprotocol/relay-docs update.

The changes are confined to internal UI utilities — a tonvm branch added to the isValidAddress helper and a new TON address-validation util. No public SDK export, hook, widget prop, provider API, or wallet-adapter interface changed. No TON wallet adapter ships here, so the adapter reference's supported-vmType list (evm/svm/bvm/tvm/lvm) is unaffected — TON is supported only as a bridging destination, not as a source-signing adapter. The latest commit only adds a changeset file, which is not a doc-relevant surface.