Nautilus Wallet Documentation

Welcome to the documentation for the Nautilus Wallet project. This document provides an overview of the Nautilus Wallet and its features, along with useful links for further information.

Nautilus Wallet logo

Nautilus Wallet Overview

The Nautilus Wallet is a cryptographic wallet hosted on a Trusted Execution Environment (TEE). It offers non-custodial services and is accessible to users who do not own a smartphone or device. The project also includes services for managing and governing assets in the context of Central Bank Digital Currency (CBDC).

The project also includes services for managing and governing assets in a [CBDC] context.

  • Trusted Execution Environment (TEE): https://en.wikipedia.org/wiki/Trusted_execution_environment
  • Intel SGX: https://www.intel.com/content/www/us/en/architecture-and-technology/software-guard-extensions.html
  • CBDC: https://en.wikipedia.org/wiki/Central_bank_digital_currency

Nautilus Wallet Features

  • Send and receive funds in XRP: Users can send and receive funds using XRP, Ripple's Native Digital Currency.

  • Basic Know Your Customer (KYC) Integration: New users can complete KYC processes with the support of Onfido.

  • Payment Connector: Users can act as connectors, charging a fee for transactions executed on their devices. The fee is displayed to users before completing a transaction.

  • Two-factor authentication: Users can verify their phone numbers and enable optional two-factor authentication via SMS. This adds an extra layer of security for authorizing transactions.

  • PIN Reset: Users can reset their PIN if they answer security questions correctly.

  • Bookmarking recipients: Users can bookmark preferred recipients for easier transactions.

  • Pull payments: Pull payments can be initiated by the receiving party and authorized by the sending party. This is especially useful for vendor transactions.

  • Recurring payments: Users can set up recurring payments to the same recipient when their wallet balance allows.

See also

Overview

The Nautilus Wallet system consists of the following high systems:

  1. An underlying ledger platform and its asset(s)
  2. The Wallet itself:
    • The Wallet TEE (server) hosts and provides access to the Wallet SGX enclave
    • The Wallet Connector app (client) securely connects wallet owners with their wallets
  3. Asset services, which help manage and govern the asset:
    • The KYC service
    • User verification service
  4. Backend services, which manages communication between the Wallet Connector app and third party services.

System Landscape diagram

System Landscape diagram

Figure: System Landscape diagram of Nautilus Wallet and the systems it interacts with.

Ledger platform

Nautilus Wallet's design supports interfacing with a choice of underlying ledger platform(s).

The system currently supports the following ledgers and asset types:

Algorand

The Algorand ledger supports transacting using Algorand Standard Assets (ASAs).

The Wallet TEE uses an SGX port of the algonaut SDK to implement key generation and transaction signing.

The Wallet Connector uses js-algorand-sdk to communicate with the Algorand network.

XRPL

The XRP Ledger supports transacting using Issued Currencies.

The Wallet TEE uses SGX ports of ripple-keypairs-rust and ripple-address-codec-rust to implement key generation and transaction signing.

The Wallet Connector uses xrpl.js to communicate with the XRP network.

Wallet

This provides the functionality of a non-custodial wallet to end-users who don't own a smartphone themselves, accessible through a smartphone-based connector app that requires only limited trust from the transacting user.

Container diagram

Container diagram: Wallet

Figure: Container diagram of the Wallet TEE and Connector app.

Wallet TEE

The Wallet TEE consists of a trusted SGX enclave, alongside an untrusted host service.

SGX enclave

The Wallet SGX enclave contains the system's [Trusted Computing Base (TCB)][TCB], and is responsible for all security-sensitive wallet operations:

  • Generating and managing account keypairs
  • Performing privileged operations such as transaction signing

Once generated, secret keys and other sensitive data never leaves the enclave unencrypted. All persistent storage is cryptographically sealed and authenticated, and all trusted communication with the enclave occurs over cryptographically attested and mutually-authenticated channels.

To learn more about Trusted Computing Base, click on the following link.

Host service

The SGX enclave is embedded in an untrusted host service, which facilitates communication between the enclave and the outside world.

  • Remote attestation, which allows the Connector app to remotely verify the identity and integrity of the enclave, and exchange keys to set up a trusted communication channel
  • Sealed message exchange, which allows the Connector app to request wallet operations, and receive results

Source Code

You can access the source code for the Wallet TEE server on GitHub:

Wallet Connector App Documentation

Welcome to the documentation for the Wallet Connector app. This document provides an overview of the app's functionality and its technology stack.

Wallet Connector App Overview

The Wallet Connector app is designed to run on web and smartphone devices (Android and iOS). It serves as a tool for transacting users to manage wallets and authorize transactions using a combination of QR codes and PIN-based authentication.

The primary purpose of the Connector app is to facilitate transactions for users other than the device owner, such as customers, friends, or family members. Each session established by the Connector app with the Wallet Trusted Execution Environment (TEE) is designed to be interactive, private, and short-lived. No session state is retained between sessions, and device owners and different transacting users have no access to each other's wallets or accounts.

Source Code

You can access the source code for the Wallet Connector app on GitHub:

Asset services

Container diagram

Container diagram: Asset services

Figure: Container diagram of the Nautilus asset services.

Source code

KYC Service

The KYC service currently integrates with Onfido to verify customer documents.

The KYC service is responsible for confirming the results of the KYC process using the Onfido integration on the app. The application saves the user's KYC check, allowing the app to enforce limits depening on the deployment configuration.

Configuration

The following configuration related to KYC is available in the app environment configuration.

App wide configuration

  • requireOnfidoCheckBeforeSendPayment: If set to true this option will prevent the user from sending payments using the app if they have not completed the KYC process.

Asset configuration

  • transactionLimitWithoutOnfidoCheck: Transaction limit that limits the amount of an asset a user can transact before they completed the KYC process.

Backend services Documentation

This documentation provides an overview of the backend services used in our project. These services are essential for handling various functionalities and integrating with third-party libraries.

Backend Service Overview

The backend service is implemented in Python and is built using the FastAPI framework. It serves as the core component responsible for handling various tasks and interacting with external libraries.

Third-Party Library Integration

Our backend services seamlessly integrate with the following third-party libraries to enhance functionality:

  • Twilio Auth API: This library enables Two-Factor Authentication for transactions above a certain limit or to specific recipient addresses. It enhances security in our application.

  • ODMantic: ODMantic serves as an Object Document Mapper for MongoDB, allowing us to work with MongoDB databases using standard Python type hints. It simplifies database interactions and data modeling.

  • XRPL Python Library: This library facilitates the autofund functionality in our application, making it easier to handle transactions on the XRP Ledger.

Source code

You can find the source code for our backend services on GitHub: Backend Services Repository

Building

Web Client

Requirements

  • Node 16

Steps

  1. Install the dependencies:

    npm install
    
  2. Ensure the prod environment file at web-client/src/environments/environment.prod.ts is correct for the build.

  3. Build the bundle:

    npm build:prod
    

The build output is in the www directory.

Web Server

Requirements

  • Docker with buildkit enabled
  • docker-compose

Steps

Note: docker images build in HW mode can only function on SGX capable hardware with the DCAP drivers installed

  1. Building docker image

    • for HW mode:

      docker-compose build server-hw
      
    • for SW mode:

      docker-compose build server-sw
      

Asset Services

Requirements

  • Docker with buildkit enabled
  • docker-compose

Steps

  1. Building optimised binaries:

    docker-compose build --build-arg CARGO_BUILD_FLAGS="--release" --build-arg CARGO_OUTPUT_PROFILE="release"
    

Deployment

For build instructions see: building

Web Client

To deploy, serve the contents of the www bundle after building the application.

Web Server

Requirements

  • Docker
  • docker-compose

To run the web server in HW mode:

  • SGX capable machine with DCAP support

Steps

To run in HW mode: docker-compose up server-hw

To run in SW mode: docker-compose up server-sw

By default the web server is bound to 0.0.0.0:8080

Asset Services

Requirements

  • Docker
  • docker-compose

Steps

  1. After building the docker images make sure the environment configuration is correct. Environment variables to set:

    • ONFIDO_API_TOKEN
    • TWILIO_ACCOUNT_SID
    • TWILIO_AUTH_TOKEN
    • TWILIO_VERIFY_SERVICE_SID
    • TWILIO_MESSAGING_SERVICE_SID
  2. To run the image, do docker-compose up in the asset services directory.

By default the asset services are bound to 0.0.0.0:8081