Skip to content

fix(keepkey): support ruji deposits and flag unsupported sends - #12604

Merged
kaladinlight merged 3 commits into
developfrom
fix/keepkey-ruji-tcy-send
Aug 19, 2026
Merged

fix(keepkey): support ruji deposits and flag unsupported sends#12604
kaladinlight merged 3 commits into
developfrom
fix/keepkey-ruji-tcy-send

Conversation

@kaladinlight

@kaladinlight kaladinlight commented Aug 19, 2026

Copy link
Copy Markdown
Member

Description

KeepKey firmware reconstructs the THORChain MsgSend it signs and hardcodes the rune denom, so it cannot sign transfers of native THORChain assets that aren't RUNE. That is why sending RUJI fails with "failed to sign transaction".

Deposits are unaffected, as those carry the asset through verbatim. So this PR:

  • Enables RUJI deposits in hdwallet-keepkey, alongside the RUNE and TCY already allowed (mirrors the earlier TCY fix in 6f08e44).
  • Surfaces the send limitation upfront rather than failing at signing time. Selecting RUJI or TCY to send on a KeepKey now shows an inline alert and disables the confirm button.

Sending RUJI/TCY on KeepKey is not fixed here, and can't be from the client - it needs a firmware change so MsgSend carries the asset's denom rather than hardcoding rune.

Issue (if applicable)

closes #12463

Linear: https://linear.app/shapeshift-dao/issue/SS-5707/unable-to-send-ruji-on-keepkey

Note the original acceptance criteria was "should be able to send Ruji on KK". That isn't achievable from the client - MsgSend hardcodes the rune denom in firmware - so there is nothing further for us to do here. Closing on the basis that deposits now work and the send limitation is communicated clearly rather than surfacing as a signing failure. If firmware later carries the denom through, lifting the guard is a one-line change in walletSupportsSendingAsset.

Risk

Low, but it does touch signing.

What protocols, transaction types, wallets or contract interactions might be affected by this PR?

  • KeepKey + THORChain only. The hdwallet-keepkey change widens an allowlist in the MsgDeposit path from THOR.RUNE/THOR.TCY to also accept THOR.RUJI. No signing logic changes; a previously rejected asset is now passed through the same code path TCY already used.
  • MsgSend is untouched and still throws for any non-rune denom.
  • walletSupportsSendingAsset returns true for every other wallet and asset, so the send modal is unchanged outside KeepKey + RUJI/TCY.

Testing

Engineering

  1. Pair a KeepKey (requires pnpm run hdwallet:build or a running dev server so the hdwallet-keepkey change is compiled into dist).
  2. Deposit: deposit RUJI on THORChain - the device should prompt and sign. Previously threw THORChain: Unsupported coin asset: THOR.RUJI.
  3. Send guard: open Send, pick RUJI (or TCY), and continue to the address step. Expect a warning alert reading "Sending RUJI is not supported by KeepKey." and a disabled button.
  4. Regression: sending RUNE on KeepKey, and sending RUJI/TCY on any other wallet, should be unaffected.

Operations

  • User-facing change, needs testing

On a KeepKey, choosing to send RUJI or TCY now shows an explanatory message and a disabled button instead of letting you proceed to a "failed to sign transaction" error. RUJI deposits work. No other wallet or asset should behave differently.

Summary by CodeRabbit

  • New Features

    • Added support for sending THOR.RUJI assets through compatible wallets.
    • Added a warning when the selected wallet does not support sending an asset.
    • Disabled the Next button for unsupported wallet and asset combinations.
  • Bug Fixes

    • Prevented unsupported KeepKey transfers for specific THORChain assets.
    • Added a clear error message identifying the asset and wallet involved.

KeepKey firmware reconstructs the THORChain MsgSend it signs and hardcodes
the `rune` denom, so it cannot sign transfers of native THORChain assets
that aren't RUNE. Deposits are unaffected, as those carry the asset through
verbatim - allow RUJI there alongside RUNE and TCY.

Sends remain firmware-blocked, so surface that in the send modal upfront
instead of failing at signing time with "failed to sign transaction".

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@kaladinlight
kaladinlight requested a review from a team as a code owner August 19, 2026 21:05
@coderabbitai

coderabbitai Bot commented Aug 19, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

Warning

Review limit reached

@kaladinlight, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 53 minutes

Limit details: You’ve used all 2 included reviews currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

Wait for the limit to reset, then comment @coderabbitai review or push new commits to the PR.

An organization admin can change what happens after included review limits in Billing.

How do review limits work?

CodeRabbit enforces per-developer PR review limits within each organization.

For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window.

Please refer docs for additional details.

Review details
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 8216aa8a-48da-4f73-9e41-e816de16e87b

📥 Commits

Reviewing files that changed from the base of the PR and between 514ab27 and 042ad56.

📒 Files selected for processing (2)
  • packages/hdwallet-keepkey/package.json
  • src/lib/utils/index.ts

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: fcad03b1-9562-4349-9622-01206f815d53

📥 Commits

Reviewing files that changed from the base of the PR and between 5be3c8f and 514ab27.

📒 Files selected for processing (4)
  • packages/hdwallet-keepkey/src/thorchain.ts
  • src/assets/translations/en/main.json
  • src/components/Modals/Send/views/Address.tsx
  • src/lib/utils/index.ts

Included review availability: Your plan provides up to 2 included reviews per hour; 1 remains after this review.


📝 Walkthrough

Walkthrough

The change adds RUJI to KeepKey THORChain deposit assets. It adds wallet asset support detection to the send form, displays a localized warning for unsupported assets, and disables the Next button when sending is unavailable.

Changes

Wallet asset support

Layer / File(s) Summary
KeepKey THORChain asset handling
packages/hdwallet-keepkey/src/thorchain.ts
THORChain deposit signing now accepts THOR.RUJI in addition to THOR.RUNE and THOR.TCY.
Wallet send-support policy
src/lib/utils/index.ts
walletSupportsSendingAsset rejects KeepKey transfers of TCY and RUJI and allows other wallet-asset combinations.
Send-form support validation
src/components/Modals/Send/views/Address.tsx, src/assets/translations/en/main.json
The send form shows a localized unsupported-asset warning and disables Next when the selected wallet does not support the selected asset.

Estimated code review effort: 2 (Simple) | ~10 minutes

Merge Risk: 🔵 Low · up to 514ab

The PR enables RUJI deposits and prevents unsupported KeepKey sends from reaching a signing failure; it is mergeable with owner awareness that the warning should always include a wallet name.

Suggested reviewers: 0xapotheosis

Poem

A rabbit checks the coins in line,
RUJI hops through signing time.
Unsupported assets raise a bell,
The Next button waits until all is well.
“Send with care!” the rabbit sings.

🚥 Pre-merge checks | ✅ 3 | ❌ 2

❌ Failed checks (2 warnings)

Check name Status Explanation Resolution
Linked Issues check ⚠️ Warning The PR does not meet issue #12463 because it prevents RUJI sends instead of enabling them on KeepKey. Add KeepKey firmware support for RUJI denomination handling, then enable RUJI signing and verify RUJI sends.
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly summarizes RUJI deposit support and unsupported KeepKey send warnings.
Out of Scope Changes check ✅ Passed The changes support the stated PR objectives and contain no unrelated code changes.
✨ Finishing Touches 💡 1
📝 Generate docstrings 💡
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch fix/keepkey-ruji-tcy-send

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

kaladinlight and others added 2 commits August 19, 2026 15:09
1.62.41 is already on npm, so the ruji deposit change needs a bump to ship.
publish-packages.yml publishes any packages/* whose version is not yet on the
registry, but the bump itself is manual.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@kaladinlight
kaladinlight enabled auto-merge (squash) August 19, 2026 21:12
@kaladinlight
kaladinlight merged commit fa1076a into develop Aug 19, 2026
6 checks passed
@kaladinlight
kaladinlight deleted the fix/keepkey-ruji-tcy-send branch August 19, 2026 21:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Unable to send RUJI on Keepkey

1 participant