Skip to content
Daemon for hardware wallet communication
Branch: master
Clone or download
Latest commit 30c7780 Apr 25, 2019
Type Name Latest commit message Commit time
Failed to load latest commit information.
.github setup github templates Apr 8, 2019
ci-scripts fix button auto press Apr 12, 2019
cmd/daemon Add integration tests and csrf Mar 29, 2019
.golangci.yml fix integration tests Apr 7, 2019
.travis.yml add test-race command Apr 14, 2019
Gopkg.lock 34-replace-connected-with-available Apr 25, 2019
Gopkg.toml 34-replace-connected-with-available Apr 25, 2019
Makefile add test-race command Apr 14, 2019 add flag to set daemon mode Apr 10, 2019 update readme Apr 8, 2019
swagger.yml 34-replace-connected-with-available Apr 25, 2019

daemon logo

Hardware Wallet Daemon

Build Status GoDoc Go Report Card

The hardware walllet daemon provides an HTTP API to interface with the wallets supported by skycoin. It uses the go bindings provided by the hardware wallet go library.

Table of contents


Hardware Daemon supports go1.10+.

Go 1.10+ Installation and Setup

Golang 1.10+ Installation/Setup

Run Daemon from the command line


The API has two modes:

  1. USB: Communicate with the hardware wallet.
  2. EMULATOR: Communicate with the emulator.

You can use the -daemon-mode flag to enable the required mode or use the make commands.

Example(USB Mode):

$ cd $GOPATH/src/
$ make run-usb

Example(Emulator Mode):

$ cd $GOPATH/src/
$ make run-emulator

Show Daemon options

$ cd $GOPATH/src/
$ make run-help

API Documentation



Development guidelines

Code added in this repository should comply to development guidelines documented in Skycoin wiki.

The project has two branches: master and develop.

  • develop is the default branch and will always have the latest code.
  • master will always be equal to the current stable release on the website, and should correspond with the latest release tag.

Client libraries

Hardware wallet daemon uses swagger for the API specification. It follows OpenAPI 2.0.

The go client has been automatically generated using go-swagger and the swagger specification.

Note: The go client uses a slightly modified response template.

The swagger specification can be used to generate more libraries in the required language.

Running tests

Library test suite can be run by running the following command

$ make test

Running Integration Tests

There are integration tests for the HTTP API interfaces. They have two run modes, "wallet" and "emulator".

The emulator integration tests are run only when an emulator is running.

The wallet integration tests are run only when a physical skycoin hardware wallet is connected.

Emulator Integration Tests

$ make integration-test-emulator


$ ./ci-scripts/ -m emulator -v

The -m emulator option, runs emulator integration tests.

The -v option, shows verbose logs.

Wallet Integration Tests

$ make integration-test-wallet


$ ./ci-scripts/ -m wallet -v

The -m wallet option, runs wallet integration tests.

The -v option, shows verbose logs.

Debugging Integration Tests

Run specific test case:

It's annoying and a waste of time to run all tests to see if the test we real care is working correctly. There's an option: -r, which can be used to run specific test case. For example: if we only want to test TestEmulatorFeatures and see the result, we can run:

$ ./ci-scripts/ -m emulator -v -r TestEmulatorFeatures

Update golden files in integration testdata

Golden files are expected data responses from the HTTP API saved to disk. When some of the tests are run, their output is compared to the golden files.

To update golden files, use the provided make command:

$ make update-golden-files

We can also update a specific test case's golden file with the -r option. For example:

$ ./ci-scripts/ -m emulator -v -u -r TestEmulatorFeatures

Test coverage

Coverage is automatically generated for make test and integration tests run against a stable node. This includes integration test coverage. The coverage output files are placed in coverage/.

To merge coverage from all tests into a single HTML file for viewing:

$ make check
$ make merge-coverage

Then open coverage/all-coverage.html in the browser.


All .go source files should be formatted goimports. You can do this with:

$ make format

Code Linting

Install prerequisites:

$ make install-linters

Run linters:

$ make lint


A full CPU profile of the program from start to finish can be obtained by running the node with the -profile-cpu flag. Once the node terminates, a profile file is written to -profile-cpu-file (defaults to This profile can be analyzed with

go tool pprof

The HTTP interface for obtaining more profiling data or obtaining data while running can be enabled with -http-prof. The HTTP profiling interface can be controlled with -http-prof-host and listens on localhost:6060 by default.

See for guidance on using the HTTP profiler.

Some useful examples include:

go tool pprof http://localhost:6060/debug/pprof/profile?seconds=10
go tool pprof http://localhost:6060/debug/pprof/heap

A web page interface is provided by http/pprof at http://localhost:6060/debug/pprof/.

Dependency Management

Dependencies are managed with dep.

To install dep for development:

go get -u

dep vendors all dependencies into the repo.

If you change the dependencies, you should update them as needed with dep ensure.

Use dep help for instructions on vendoring a specific version of a dependency, or updating them.

When updating or initializing, dep will find the latest version of a dependency that will compile.


Initialize all dependencies:

dep init

Update all dependencies:

dep ensure -update -v

Add a single dependency (latest version):

dep ensure

Add a single dependency (more specific version), or downgrade an existing dependency:

dep ensure


Update the version

  1. If the master branch has commits that are not in develop (e.g. due to a hotfix applied to master), merge master into develop (and fix any build or test failures)
  2. Switch to a new release branch named release-X.Y.Z for preparing the release.
  3. Run make build to make sure that the code base is up to date
  4. Update move the "unreleased" changes to the version and add the date.
  5. Follow the steps in pre-release testing
  6. Make a PR merging the release branch into master
  7. Review the PR and merge it
  8. Tag the master branch with the version number. Version tags start with v, e.g. v0.20.0. Sign the tag. If you have your GPG key in github, creating a release on the Github website will automatically tag the release. It can be tagged from the command line with git tag -as v0.20.0 $COMMIT_ID, but Github will not recognize it as a "release".
  9. Tag the changeset of the protob submodule checkout with the same version number as above.
  10. Release builds are created and uploaded by travis. To do it manually, checkout the master branch and follow the create release builds instructions.
  11. Checkout develop branch and bump tiny-firmware/VERSION and tiny-firmware/bootloader/VERSION to next dev version number.

Pre-release testing

Performs these actions before releasing:

  • make lint
  • make check (make sure that all the integration tests are passing)

Responsible Disclosure

Security flaws in the source of any software provided by skycoin or infrastructure can be sent to Bounties are available for accepted critical bug reports.

PGP Key for signing:



Key ID: 0x5801631BD27C7874

The fingerprint for this key is:

pub   ed25519 2017-09-01 [SC] [expires: 2023-03-18]
      10A7 22B7 6F2F FE7B D238  0222 5801 631B D27C 7874
uid                      GZ-C SKYCOIN <>
sub   cv25519 2017-09-01 [E] [expires: 2023-03-18] account:

You can’t perform that action at this time.