Some CLI Changes in Testnet 2.2

Hey everyone, we’ve recently been working on some updates to the coda command-line interface to try to make it a little more consistent and easy to use. As a result, a CLI change is coming down the line (in Testnet 2.2) which will let the daemon manage your keys for you a little better.

We read through a lot of your great CLI FYI feedback and did our best to integrate some of it into the design. Obviously there’s a lot left to do, but we wanted you to know how much we appreciated your ideas. Specifically, these changes were inspired in part by, but also works towards enabling further work on ideas like and

You’ll be able to make a new account:

$ coda accounts create
Password for new private key file: 
Again to confirm: 

😄 Added new account!
Public key: 8QnLXcjiXHe4jsEx2stzSs9j4J5jXPuGTzCD7P2wtAk1AkNFT6SfgsHzJYAxWsDW8z

List your accounts:

$ coda accounts list
Wallet #1:
  Public key: 8QnLXcjiXHe4jsEx2stzSs9j4J5jXPuGTzCD7P2wtAk1AkNFT6SfgsHzJYAxWsDW8z
  Balance: 0
  Locked: false

As well as importing and exporting accounts from/to the format you’re used to. Let me know what you think!


Commands that used to take a -privkey-path will soon just take a -public-key argument of a public key corresponding to one of your tracked accounts. For now, we want to give people a chance to try out the new stuff and update their scripts without too much breakage, so we’ve exposed these commands under a (temporary!) coda client2 subcommand. If everything goes smoothly, we expect to swap the commands in coda client for these new versions next testnet. If you have any thoughts or issues, feel free to comment here.

We hope to be able to build some kind of aliasing system on top of this soon so that you don’t have to remember those big strings. In the meantime, you can always use the trick of defining environment variables containing your public keys.

export CODA_PK=<public-key>
coda client2 get-balance -public-key $CODA_PK


When you create a new account, you’ll be asked for a password (as usual). When the account is created, it will be in the “unlocked” state, which means you can use its public key to send payments etc. You can lock it again with coda accounts lock -public-key $CODA_PK, which will prevent you or anyone else with access to your terminal from accidentally sending your funds.

When the daemon is started, all existing tracked accounts start locked and you’ll have to unlock the ones you want to use before you perform any operations that require your secret key (sending transactions, staking etc).


Another cool thing about this change is that it integrates the CLI experience better with our GraphQL API. The new CLI commands now communicate with the daemon via GraphQL, rather than the RPC system that was being used previously. Hopefully this leads to more consistency in behaviour between those systems and less work on everyone’s part to maintain both!

One clear benefit is that you’ll no longer need to use the coda daemon -unsafe-track-propose-key or coda advanced unsafe-import to use your keys with the GraphQL API. All your tracked account keys will show up the same, whether it’s through the API or in the command line.

Going forward

  • There’s some naming inconsistency between the GraphQL API and the CLI, for instance, the API uses the term “wallet” instead of “account”. This will be changed to be “account” in the API sometime in the future along with some other changes.
  • As mentioned in the post, it might be easier to specify keys using aliases. One unresolved question there would be whether it’s alright to only have aliases for owned/tracked accounts (the ones you have the secret key for) and not other peoples’ accounts (say, the recipient of a transaction you’re sending).
  • More flexibility with signing keys — we know you might not want the daemon to directly hold onto your keys, and we’ll need to investigate how best to support the ability to sign txns/etc from a remote machine.
  • There were lots of good ideas in CLI FYI about extra information that could be exposed by coda client status. Didn’t get a chance to tackle those as part of this change but hopefully someone can add them soon!