Closed dovigod closed 11 months ago
In cosmos there are two types of message encoding, amino and protobuf, being Amino legacy but still maintained because is what ledger use to sign. Depending on what encoding you choose to prepare your tx, you will need to use one structure or another. For Amino encoding StdSignDoc is used and for Direct it is SignDoc. Thats why we differentiate between signAmino and signDirect, because these methods prepare the right encoding in CosmJS to be signed by the signer.
Method sign is just an intermediary method that check if the signer support direct or amino in case of support direct it always select direct. You can check OfflineSigner interface.
@j0nl1 Thanks for reply!! So, to be sure, 'SigningStargateClient.sign' , will result exactly same with 'Direct256h1Wallet.signDirect' if I'm not using ledger right?
If you are providing a direct signer when instantiate SigningStargateClient
then it will call signDirect yes. Assuming you are providing Direct256h1Wallet then yes it will call signDirect method.
I've experienced different behaviour than what you describe above @j0nl1. Even though I use proto msgs and keplr wallet, it seems to switch to Amino signing for some reason.
The case of sending a single message MsgDelegate
there is no problem and it seems like the signer is using signDirect. (as it works without the aminoConverters added to the signing client, however, with 2 messages it behaves differently:
I create 2 messages: One is MsgDelegate
and one is MsgGrant
, where the message grant contains a staking authorization. As you can see from the imports below, the types that i use are all proto based types, not amino. However, when i sign using a CosmwasmSigningClient that has the proper registry setup, The sending the signAndBroadcast
will fail before confirming with the following error: Type URL '/cosmos.authz.v1beta1.MsgGrant' does not exist in the Amino message type register. If you...
Is there a reason why the signing client asks for amino types instead of just accepting the prototypes?
import { MsgGrant } from 'cosmjs-types/cosmos/authz/v1beta1/tx'
import { Coin } from 'cosmjs-types/cosmos/base/v1beta1/coin'
import { AuthorizationType, StakeAuthorization } from 'cosmjs-types/cosmos/staking/v1beta1/authz'
import { GenericAuthorization } from 'cosmjs-types/cosmos/authz/v1beta1/authz'
import { getUnixTime, parse } from 'date-fns'
import { EncodeObject } from '@cosmjs/proto-signing'
...
value: MsgGrant.fromPartial(value), // using from partial for creation of the messages
...
In case there is no clear explanation and you'd like to see more of the implementation im using, ive added a thinned version of the code down here ⬇️
@MbBrainz I think this issue is not related with CosmJS. Keplr internally have their own registry they may not have support for that protobuf, I can't say. They decode the message in order to show the message in the UI.
Direct256h1Wallet
should be compatible with your code, I can't see the whole code but I would say is what I mention above.
@j0nl1 The error is not specific to keplr, with leap wallet i experience the exact same problem. It happens only to the transaction mentioned above, not to any other type. I tried to remove all the dependencies on other libraries, so that I would be sure its related to comsjs. The code block shows all the imports and constructions.
FYI: You can see the whole code by clicking on the ▶︎ Complete code blocks
dropdown
Hi, I’m currently developing with cosmjs sdk.
what Im doing is trying to map ethers method with cosmos methods.
While trying to map” ethers.signMessage” I found that there are two similar methods, which is
since, I couldnt found definetions of above two methods, I tried to inspect codes of them in this repository, but couldn’t solve my questions.
I’ll be thankful for answers.