You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, we have some RPCs that return AccountIds. Substrate encodes them by default with the generic SS58-prefix 42. This is transformed into the node-specific SS58-address format by the client side, e.g., polkadot-js/api usually.
In our dart api, we don't have such a logic. Hence, this leads to inconsistency in the address format, when compared to the values returned by the polkadot-js api.
#568 hardcodes the prefixes to 42 for all networks, to fix inconsistencies with the js-api, which would use the network-specific prefix. This fix might be acceptable if we assume that the users will never use their account with polkadot-js/apps or with subscan. But is this a valid assumption?
We might want to internally the prefix 42 always, but we show the network specific one to the user.
The text was updated successfully, but these errors were encountered:
Currently, we have some RPCs that return
AccountId
s. Substrate encodes them by default with the generic SS58-prefix 42. This is transformed into the node-specific SS58-address format by the client side, e.g., polkadot-js/api usually.In our dart api, we don't have such a logic. Hence, this leads to inconsistency in the address format, when compared to the values returned by the polkadot-js api.
#568 hardcodes the prefixes to 42 for all networks, to fix inconsistencies with the js-api, which would use the network-specific prefix. This fix might be acceptable if we assume that the users will never use their account with polkadot-js/apps or with subscan. But is this a valid assumption?
We might want to internally the prefix 42 always, but we show the network specific one to the user.
The text was updated successfully, but these errors were encountered: