Closed pmespresso closed 5 years ago
Ok, so the QR is completely independent of that, that is up to the user and it not part of this at all. The way it works -
As an aside, the above description is wrong for extrinsic v3. (payload has genesisHash as well)
ahh okay, thank you for the super quick response
So there may very well be some tweaks required - however, the QR really doesn't care about the data passed, it can be anything. (If we try and build in tx logic here, we are setting ourselves up for failures - whatever it gets in must already be encoded, @polkadot/types
handles all that and really tracks the extrinsic formats)
However... there may be that we are missing an additional flag based on a type that the caller passes in and we don't have yet. (For those, PRs required, not close to passing the stuff yet, so cannot really comment if everything is 100%)
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query.
according to @maciejhirsz : https://github.com/maciejhirsz/uos#substrate-payload,
payload
MUST be the SCALE encoding of the tuple of transaction items (nonce, call, era_description, era_header).payload_hash
MUST be the Blake2s 32-byte hash of the SCALE encoding of the tuple of transaction items (nonce, call, era_description, era_header).immortal_payload
MUST be the SCALE encoding of the tuple of transaction items (nonce, call).Currently react-qr supports a setting a utf8 encoded
message
but not an actualpayload
per se.