The Qredo API and Partner API are being deprecated and will be replaced by a breaking change in Q4. To receive updates about the release, register here.
Qredo Logo

Signing Agent

Integration

TL;DR

To integrate your App with the Signing Agent and Partner API:

Overview

The Signing Agent is a standalone component of the Qredo ecosystem. To run a Signing Agent, first you need to register it on the Qredo network. A new Signing Agent is created via the Partner API. Each Signing Agent receives a unique identifier. This ID can be added to the 'members' group and included in the custody policy:custodygroup_withdraw and/or the custodygroup_tx for an entity.

The following diagram demonstrates the basic flow with regards to:

  • PartnerApp (i.e. your App)
  • Signing-Agent-Service (e.g. Signing Agent running on your infrastructure)
  • and QredoBE (backend).

Step 1: Initiate integration with Partner API

1. Have a Qredo account or a Sandbox account linked to the Qredo Web App.

Enable testnet assets

While not mandatory, Qredo strongly recommends you perform API tests using testnet assets. A Sandbox account is used for integration testing and only uses testnet assets.

2. Sign up to use the Partner API.

3. A Signing Agent is part of a custody policy. To create a custody policy, you must have the governing entity in place for the API you will use:

3. Generate the API keys.

Three major outcomes must be achieved:

4. Set up testnet assets (optional/recommended)

This is optional for the Production Web App and Production environment. Testnet assets must be activated for use in the Sandbox environment, https://sandbox.qredo.network/.

Return Here

Carry out the Steps above and return here to continue the flow.

Step 2: Set up environments

This is a technical integration targeted at developers, and it is important to be familiar with the following:

  • Docker
  • Open API 3+ integrations
  • Generating, using, and managing the lifecycle of API keys including encoding and timestamping such keys for authentication
  • Blockchain transactions including signing and transmitting txs

Step 3 Deploy Signing Agent

Next, you will work with the Docker image and Signing Agent configuration file to instigate a self-served Rest API service to register your Signing Agent with Partner API.

The self-served Rest API generates an agent ID which may be added alongside, or in place of, trusted parties in your custody policy.

Register a Signing Agent

Setting up your Docker image is covered in a dedicated page. Once you register a Signing Agent and hold the agentID, you are ready to implement that Signing Agent as part of your custodial policies. The final part of the flow, implement ensures you have the entities in place to support such policies.

Step 4: Implement your Signing Agent

Ensure you have the required entities

A Signing Agent becomes part of your custody group according to your policy requirements. This means that to implement Signing Agent, you must have the governing entity set up and determine which level you wish to apply custody policies to.

Partner APIQredo API v1
Entity NameCompanyOrganization
Supported policy levelCompanyOrganization
FundFund
WalletWallet

Registration flow

The following explanation summarizes the registration process, which involves the PartnerApp (i.e. your 3rd-party App), the signing-agent-service (e.g. Signing Agent running on your infrastructure), and QredoBE (e.g. our Qredo backend).

  1. The PartnerApp triggers the registration process by providing its client name, Partner API Key, and Base64-Private Key to the signing-agent-service.
  2. signing-agent-service generates BLS and EC keys.
  3. signing-agent-service stores BLS and EC keys.
  4. The signing-agent-service can now register itself to the Partner API on the QredoBE, by sending the client name, BLS, and EC public keys.
  5. The agentId and a feedURL is returned by the QredoBE to the signing-agent-service. This feed is used by the signing-agent-service to keep a communication channel open with the QredoBE.
  6. The agentId and a feedURL is also passed along to the PartnerApp so that the latter can monitor for new actions that need to be approved in that case that the service is not configured for auto-approval.

All the data above is currently stored on premises in a file by the signing-agent-service, and since some of it (ClientSecret, EC & BLS private keys) is quite sensitive it needs to be running in a secure environment.

Previous
Get started