ledger-app-vet

VeChain wallet application framework for Ledger Nano S/SP/X and Stax

Quick start guide

Follow the steps of Quick start guide of app-boilerplate reported below just for the sake of completeness.

With VSCode

You can quickly setup a convenient environment to build and test your application by using Ledger's VSCode developer tools extension which leverages the ledger-app-dev-tools docker image.

It will allow you, whether you are developing on macOS, Windows or Linux to quickly build your apps, test them on Speculos and load them on any supported device.

• Install and run Docker.
• Make sure you have an X11 server running :
  • On Ubuntu Linux, it should be running by default.
  • On macOS, install and launch XQuartz (make sure to go to XQuartz > Preferences > Security and check "Allow client connections").
  • On Windows, install and launch VcXsrv (make sure to configure it to disable access control).
• Install VScode and add Ledger's extension.
• Open a terminal and clone app-boilerplate with git clone git@github.com:LedgerHQ/app-boilerplate.git.
• Open the app-boilerplate folder with VSCode.
• Use Ledger extension's sidebar menu or open the tasks menu with ctrl + shift + b (command + shift + b on a Mac) to conveniently execute actions :
  • Build the app for the device model of your choice with Build.
  • Test your binary on Speculos with Run with Speculos.
  • You can also run functional tests, load the app on a physical device, and more.

:information_source: The terminal tab of VSCode will show you what commands the extension runs behind the scene.

With a terminal

The ledger-app-dev-tools docker image contains all the required tools and libraries to build, test and load an application.

You can download it from the ghcr.io docker repository:

sudo docker pull ghcr.io/ledgerhq/ledger-app-builder/ledger-app-dev-tools:latest

You can then enter this development environment by executing the following command from the directory of the application git repository:

Linux (Ubuntu)

sudo docker run --rm -ti --user "$(id -u):$(id -g)" --privileged -v "/dev/bus/usb:/dev/bus/usb" -v "$(realpath .):/app" ghcr.io/ledgerhq/ledger-app-builder/ledger-app-dev-tools:latest

macOS

sudo docker run  --rm -ti --user "$(id -u):$(id -g)" --privileged -v "$(pwd -P):/app" ghcr.io/ledgerhq/ledger-app-builder/ledger-app-dev-tools:latest

Windows (with PowerShell)

docker run --rm -ti --privileged -v "$(Get-Location):/app" ghcr.io/ledgerhq/ledger-app-builder/ledger-app-dev-tools:latest

The application's code will be available from inside the docker container, you can proceed to the following compilation steps to build your app.

Building and testing the application

With VsCode

Supposing you have followed the steps of the previous section with VSCode, you can now build and test the application with ease thanks to the Ledger extension. The steps should be:

1. Docker Container > Update container
2. Select target for the desired target.
3. Build > Build to build the application and app.elf file (used by Speculos).
4. Functional Tests > Run tests to test the application

With Speculos

Manually run with Speculos. Once you have the Speculos installed, you can run the application with the following command:

• Run the server specifying the port, the model, and the app

  /speculos$ ./speculos.py --api-port 5000 --model nanos --display headless <app-vechain-location>/build/nanos/bin/app.elf 

• Visit local website to test and send apdu codes.

It's possible to generate the transaction and the APDU codes for the transaction by running tests/generatetx.py script with desired args or directly changing the body of the transaction there.

If you encounter any issue with APDU codes generated by tests/generatetx.py try by extracting APDU codes from the test suite.

1. Get the hex of transaction.
2. To generate the APDU codes, you can change the transaction in the test tests/test_sign_tx_long_cmd.py and run the test.
3. The test should fail for a wrong signature. This is normal because different transaction should have different blake2 message hash and consequentially different signature.
4. Given that the test failed, you can extract the APDU codes from the logs of the failed test.