Wrong Recipient address sending SOL Model T

Suite issues Wallet issues
, ,
1

Hey, I have a problem with my Model T:
I want to send 1 JUP token (on the Solana blockchain) from my Model T to my Phantom wallet. But my Trezor shows me a completely different sender and recipient address on the device than the one I want to send my money to. This is really strange.
Sending funds works quite well with SOL, but with JUP there is always the wrong address.

And the device also shows some strange things:
1/3 COMPUTE BUDGET PROGRAM: SET COMPUTE UNIT LIMIT
UNITS
200000

(after confirming)
2/3 COMPUTE BUDGET PROGRAM: SET COMPUTE UNIT PRICE
Compute unit price
100000

(after confirming)
3/3 TOKEN PROGRAM: TRANSFER CHECKED
Token
JUPyiwrYJFskUPiHa7hkeR8VUtAeFoSYbKedZNsDvCN

(after confirming)
3/3 TOKEN PROGRAM: TRANSFER CHECKED
Recipient
[and now follows a complete random address, starting with DTE1r6 … GcJA7o]

(after confirming)
3/3 TOKEN PROGRAM: TRANSFER CHECKED
Amount
1

(after confirming)
3/3 TOKEN PROGRAM: TRANSFER CHECKED
From
[now follows a completely wrong address from a wallet that is not mine, starting with 3j81 … 35Fa]

(after confirming)
SUMMARY
Expected fee:
0.000025 SOL
[now there should follow the final confirmation to send, wich I don’t want to press]

I feel uncomfortable sending the funds. On the screen in the Trezor Suite is the correct data shown, but not on the device.

Can someone help me? What is the issue here?

I use the latest latest firmware update 2.7.0 and Trezor Suite 24.3.3

Thanks!

1 Like
2

umm not sure what to say on all that… leave that for the experts on here.

But just to tell you I have sent and received SOL tokens (USDC, WEN, BONK) using the nufi web wallet (not the extension) with trezor T and it works very well.
As always, send a test amount first to see what happens, but nufi has been a life saver and I use it as my preferred wallet for SOL.

3

My advice is to create a support ticket here: https://trezor.io/support in the bottom right corner click on the chat button and create a support ticket.

Also, when you bought the Trezor device, did you verified it? Checked if it hasn’t been tampered with?
Also, it’s normal to regenerate a new receive address every time, but you always need to verify this with your device.

And I have no idea if those messages are supposed to be there because I don’t use Solana, so maybe someone else here or support can help you out.

2 Likes
4

I’m having the exact same problem. I sent a small amount of SOL and Bonk to my Trezor, which worked. Now I’m trying to send it back to my hot wallet and both the sender and recipient addresses that appear on the Trezor device are random and not addresses that are mine. The token address of the coin I’m trying to send is correct, just not the sender or recipient addresses.

I get all the same weird steps you’ve outlined here, asking me to confirm compute units etc. In my case the amounts were very small so I went ahead with confirming even the addresses on the Trezor did not match what was on the screen in Trezor Suite.

The first few attempts the transaction fails with the error about incorrect block hash. But this last time I just tried again and it worked, and the amounts appeared in my other hot wallet. So the transaction worked, but both the sender and recipient addresses were WRONG on the Trezor device.

Not sure wtf is happening but obviously this should not happen. This is very concerning.

5

Also worth mentioning that when I look in the transaction log in Trezor Suite, it shows the incorrect address there too. It shows a recipient address that is NOT mine, and NOT the hot wallet where the funds actually arrived at. So it’s not just a display issue on the Trezor device, there’s something much more wrong happening.

6

Hi, this is expected.

When someone send you a token or you send it, they/you will get your address, and deterministically send it to your dedicated token sub account.

Sol accounts sort of work like an xpub. Each token has it’s own token account

Associated Token Account Program | Solana Program Library Docs

1 Like
7

Hey forgi, thanks for answering.
But I don’t get the point. What does “this is expected” means?
Is it safe to send my funds? It feels really wrong to do so, bc you guys always tell your customers to double check if the address on the device and on the screen match. Now nothing is matching…
Why isn’t the device just showing the correct receiving and sending address? It worked perfectly before the firmware/suite update.

1 Like
8

It means that it behaves as it should, yes it is safe.

This is how SOL works, but I see your point and the product team already got the feedback on this.

1 Like
9

I am having the exact same issue and this does not give me any confidence in sending a transaction. Not sure about your point this is how SOL works. It didn’t work like this in old Suite and Firmware so it’s definitely something new that has been introduced.

Can you post something officially clarifying everything and why it’s safe to do so when you yourself have been banging on about making sure the address displayed on the device is correct recipient address.

1 Like
10

I have never heard from any source that it’s “expected and safe” to confirm an address on the hardware wallet that doesn’t match both the screen and the intended wallet addresses.

This makes zero sense and you’ve provided no real information to explain why on earth this would be either expected, or safe.

11

You can read the provided documentation:

You can always try to send a small amount to see that it will arrive to your destination address correctly.

please refer to my previous post above.

12

You’ve just cemented my choice to buy a ledger. Thanks.

2 Likes
13

As mentioned previously, the product team will try to address this feedback, so the actual UI will be more clear on this, however, this is how Sol tokens work as such.

14

totally wrong it wasn’t like this in the old suite version only started happening after updating the suite.

If our funds are lost cuz of what you saying would you take full responsibility for it?

15

I believe there is logic in place that converts between the “token address” and “main address” on Trezor, precisely so that this problem is not actually happening.*

that, however, must be correctly executed from Suite side. and it’s also possible that the update to fee code broke the functionality, so both Suite and firmware need an update.

if you are worried about it – and it’s fully correct to be worried – then I’m afraid you’ll need to wait until this is fixed. hopefully next month, fingers crossed :crossed_fingers:

*) as I was mentioning elsewhere, the design decisions leading to this problem in the first place were, shall we say, not Solana’s brightest moments. they have some amazing tech in there, but very little thought was put into how the hell are users supposed to trust the thing

1 Like
16

Compute budget appears in FW when priority fees are used, which is new in suite do to the recent hotfix.

It also depends on the address to which users are sending the tokens. Some addresses have the associated tokens account already, which then shortens the signing process since there is no need to create a new one.

17

So, let me summarize this:
Last month I was unable to send my JUP to another address bc there were no priority fees.
This month I’m unable to send my JUP bc the wrong address scares the shit out of me and it’ll take at least another month to fix this.
This is incredibly unsatisfactory.

18

There is no issue with sending, you can send your tokens. I understand your worries but, as was explained in the posts above, this is how SOL works.

19

You have no idea what Ledger does in the background. Ledger is a blackbox. Open source hardware wallets like Trezor and OneKey lets you check out the source code and whatnot. If you really want to know the pro and cons of every wallet I would recommend https://walletscrutiny.com

They actually check the code of all kinds of wallets be it software or hardware wallet and even try to build the code and compare it with the device or software.

If you switch let it be an informed decision rather than a hasty one.