cryptoBeliever
cryptoBeliever
## Current Behaviour SDK user has to specify fields manually: - `levySize` - `messageEnvelopeSize` ## Expected Behaviour Fields `levySize` and `messageEnvelopeSize` can be calculated based on other values in the...
When a mosaic array is not ordered by mosaic_id when constructing a transaction we get the error: "array passed to write array is not sorted". SDK should handle sorting and...
## Current Behaviour Old SDKs message specification defined four types of messages: - Plain Message (prefix 0) - Encrypted Message (prefix 1) - Persistent Delegated Message transaction (prefix 254) -...
When a mosaic array is not ordered by mosaic_id when constructing a transaction we get the error: "array passed to write array is not sorted". SDK should handle sorting and...
## Current Behaviour Old SDKs message specification defined four types of messages: - Plain Message (prefix 0) - Encrypted Message (prefix 1) - Persistent Delegated Message transaction (prefix 254) -...
## Steps to reproduce - open mainnet explorer - try searching for namespace `yukki-` (https://symbol.fyi/namespaces/C70B3AA4D2D8DCFC) ## Current result: The namespace is not found. ## Expected result: Redirect to namespace view...
## Current behavior Currently, metadata entries on the address view have column Target Id. It can be either depending on metadata type: - N/A - for account metadata - mosaic...
**Current behavior** Currently, in the explorer table components show pagination also when it's not necessary (when there is only one page). This unnecessarily distracts users. **Expected behavior** We should hide...
Related to wallet issue: https://github.com/nemgrouplimited/symbol-desktop-wallet/issues/856 Explorer should present amount transferred for aggregate transactions same as for single tx. Currently, it's not presented on list due Rest API limitation:  This...
## What's the issue? Desktop wallet calculates incorrect deadlines for offline transactions. This causes `Failure_Core_Past_Deadline` when announcing. Example signed transaction: ``` B000000000000000692DE12C9BD80C5F00ECADCED4190C80FE18777F52C3279335B9FEF097F25E79B8933A7E1EE50993FD2646AE9C2E00F06E2A99D7FF3F6370BE135FBB7CF37F061E7D10805F25609A8E3A866F3ED05C5D9B307CD0DE220325B8DD1D6D9108DAB80000000001685441C0440000000000003E5A70550300000068805C51DF7DB65E75F23FA110B3C6A5F14AAB67DB6535050000010000000000F82302A23F91ED6B0000000000000000 ``` ``` ( signature: 692DE12C9BD80C5F00ECADCED4190C80FE18777F52C3279335B9FEF097F25E79B8933A7E1EE50993FD2646AE9C2E00F06E2A99D7FF3F6370BE135FBB7CF37F06, signerPublicKey: 1E7D10805F25609A8E3A866F3ED05C5D9B307CD0DE220325B8DD1D6D9108DAB8, version:...