Proposal 130093 to enable ckUSDC on the NNS dapp just went live, please consider voting 
Change Log
This proposal aims to enable basic ckUSDC functionality in the NNS Dapp. It does this without changing the canister wasm, only by changing the canister arguments.
Wasm Verification
Since this proposal doesn’t change the wasm, verification is different than usual and does not involve building the wasm module. Instead you can verify that the module hash of the proposal matches the module hash currently deployed on mainnet.
Run the following commands from the root of the nns-dapp repo:
git fetch # to ensure you have the latest changes.
git checkout "87df24860d5946de9117139c0b5515c77c754a12"
dfx canister info nns-dapp --network=mainnet # Should match `wasm_module` argument in the proposal.
To verify the canister arguments we’ll start with the configuration of the previous proposal, apply the feature flag change and generate the arguments to compare them to the proposal arguments.
jq '.defaults.network.config.FEATURE_FLAGS.ENABLE_CKUSDC = true' dfx.json | sponge dfx.json
DFX_NETWORK=mainnet ./config.sh
cat nns-dapp-arg-mainnet.did
didc encode "$(cat nns-dapp-arg-mainnet.did)"
6 Likes
When will we be able to receive assets from ETH network in the NNS
1 Like
@chepreghy we get a different hash as can be seen in the screenshot, any ideas ? Thanks
@ZackDS can you clarify what it is you didn’t expect to see?
Sure, the hash in the payload is not the same as the one we got
according to the description should be the same.
It looks the same to me.
Are you referring to the “0x” that dfx puts in front of the hash?
Exactly that, is that just so the following string represents a hexadecimal ? And the payload is then correct ?
I’m not sure why dfx decided to prefix the hash with “0x”. I’ve only seen it used before to indicate a hexadecimal number and I wouldn’t consider a hash a number. But “x” is not a possible hexadecimal digit so it’s not part of the hash. It also wouldn’t really be possible for the hashes to match except for 2 characters.
If you prefer, you could also compare to the previous NNS dapp proposal and notice that the hash is the same.
Or look at any other proposal, such as this one for internet identity, and notice that the hash also matches if you ignore the “0x” prefix:
$ dfx canister info rdmx6-jaaaa-aaaaa-aaadq-cai --network mainnet
Controllers: r7inp-6aaaa-aaaaa-aaabq-cai
Module hash: 0x20103f72d31f20fb08e1fa3c50778c25c7a2dc115c92981f4bb54e61cd9f4538
1 Like
Thank you for clarifying and for the quick response.
From a mathematical point of view a hash is indead a number and it is convention to format hashes as hexadecimals. So, at least for me it’s not unlogical that dfx decided to prefix it with 0x
But this prefix doesn’t appear in every instance of Wasm hashes being provided. It’s the inconsistency that was confusing here.
I agree it would be good to handle it consistently.
