The problematic value is: 3264135159653872479015431810322683152639176555098724559580386778482198662677
So, this is a bytes32 argument written as the result of Crypto.sha256.
When I decode it - the hex value of that bytes32 is 7376f5e1bcf508a0e9f519f0ccc27250a6f1e1f83841b6b63c9791838274e15
Passing the hex value to a smart contract function that accepts bytes32 results in the following error:
**TypeError: First argument must be a string, Buffer, ArrayBuffer, Array, or array-like object.**
So, either the encoder is wrong (because in fact, 7376f5e1bcf508a0e9f519f0ccc27250a6f1e1f83841b6b63c9791838274e15` is 63 symbols)
or my conversion of 3264135159653872479015431810322683152639176555098724559580386778482198662677 to 7376f5e1bcf508a0e9f519f0ccc27250a6f1e1f83841b6b63c9791838274e15 is wrong
The description of Events explains this I think. It says: “The topics are (currently, this might change in the future) presented as 256-bit unsigned integers”
And indeed, if you interpret your 256-bit integer as a bytes(32) (i.e. using 32 bytes or 64 half-bytes) you get the expected answer:
The node endpoint don’t know what type the Topic “really” is and can only present something generic. At the moment that something is 256-bit unsigned (little-endian) integers. The SDK may do whatever it likes with this information, if it does know the correct type it should be able to do the right thing.