Javascript sign transaction request() problems #118
-
SummaryHi! I am developing a Solana SDK for godot. I am unable to create correct signatures from phantom in javascript. I would really like some details on exactly what phantom does to its input and what it expects as input to sign properly. ExampleNo response Steps to ReproduceWhen trying to sign transactions from javascript. I am limited to using the request method. I read in the example at https://docs.phantom.app/solana/sending-a-transaction that phantom expects First output is the serialized message and second is bs58 encoded message. So I try to add the signatures too. Now I get a popup and can sign something. But the signature is just not the one I expect. Again here the first output is the serialized transaction and the second is its base 58 encoded string. I get the signature with the following code: It is not a signature of the transaction and I cannot verify it and I cannot send it. Phantom Version23.15.0 chrome extension Is there an existing discussion for this?
|
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 3 replies
-
Hey @Virus-Axel thank you for writing in! And cool project! Do you have some code available that I could take a look at? |
Beta Was this translation helpful? Give feedback.
-
I found the reason for this here: https://solana.stackexchange.com/questions/6623/how-to-disable-priority-fees-in-phantom/6632#6632. The solution would be to add ComputeUnitBudget instruction and a ComputeUnitLimit to the transaction. That is what wallets sign anyways (some conditions to it). It was also possible to partially sign to get around this phenomenon. I tried partially signing but seems not possible when there is only one signer. I am glad this is resolved, and thank you for your time :) |
Beta Was this translation helpful? Give feedback.
I found the reason for this here: https://solana.stackexchange.com/questions/6623/how-to-disable-priority-fees-in-phantom/6632#6632. The solution would be to add ComputeUnitBudget instruction and a ComputeUnitLimit to the transaction. That is what wallets sign anyways (some conditions to it). It was also possible to partially sign to get around this phenomenon. I tried partially signing but seems not possible when there is only one signer.
I am glad this is resolved, and thank you for your time :)