How to read the result of sign/send just as we do with call

Hey all,

I would like to understand how to read the result of a sign/send in a cold storage setup. As an example let’s take the get_full_neuron call to the governance canister. This would work if it’s done from a networked computer where the owner of the neuron is the active user and provides the neuron id as the argument of the script.

NETWORK="" # Mainnet
CANISTER="rrkah-fqaaa-aaaaa-aaaaq-cai" # Governance canister
echo $ARGS
RESULT="$(dfx canister --no-wallet --network=$NETWORK call $CANISTER get_full_neuron $ARGS --output=raw)"
didc decode -t "(Result_1)" -d ./nns-ifaces-0.8.1/governance.did $RESULT

But … my question is how can I achieve the same with a cold storage setup, where the private key is in another non-networked system. It signs the message there and then we send the corresponding message.json from a networked system.

What I tried after some advice from the telegram channel is:

  1. Sign the get_full_neuron request in the cold computer
  2. Move the message.json in the networked one and send it. Get a request_id
  3. Use request-status to query the request id with a script like this:

NETWORK="" # Mainnet
CANISTER="rrkah-fqaaa-aaaaa-aaaaq-cai" # Governance canister

./dfx canister --network=$NETWORK request-status $REQUEST_ID $CANISTER

The problem with this is that I always seem to get an html 404 error.

Creating a wallet canister on the https___ic0_app network.
The replica returned an HTTP Error: Http Error: status 404 Not Found, content type "text/html", content: <html>
<head><title>404 Not Found</title></head>
<center><h1>404 Not Found</h1></center>

So how can I get around this and make it work?


This can’t proxy through the wallet in the current sdk, so you’ll have to use --no-wallet in the request-status call too, so

dfx canister --network=$NETWORK --no-wallet request-status $REQUEST_ID $CANISTER

Apologies it can be a bit tricky to debug things in telegram!

Note you can use this sign/send combination for any calls to canisters. So you can explore signing and sending from a single dfx setup on some non critical canister calls to get comfortable with the process, before doing it for real with your cold storage.

1 Like

Hello @Ori thank you for your response. Doing what you suggested no longer returns 404 but still does not work as it returns a 403:

The replica returned an HTTP Error: Http Error: status 403 Forbidden, content type "", content: Request IDs must be for requests signed by the caller.

Which makes no sense since the whole point of this is to be able to sign in an airgapped machine, send it from a networked one and then on the same networked one check the result.

1 Like

This is a bit of a catch-22 isn’t it. I think this might be falling through the cracks a little somewhere, re what the current version of dfx is capable of…

@nomeata @stanley.jones ??

I would really appreciate a way to be able to make this work. Please let me know what I can try.

@Ori respectfully second this request (no pun intended). We have the AG working for sign/send on transfer, but now would be great to fully see the request-status. Thank you!!


I would also highly appreciate this. I am currently failing to disburse with AG, and this would at least help me understand what the problem is. At the moment I just have a request_id and no error.

1 Like

An update on this:

1 Like