Helm charts for booting an operational and/or validator node for the Agreements Network (AN).

Getting Started

This repository contains four primary charts to help bootstrap your network. Before proceeding, please make sure both Kubernetes and Helm are installed for your cluster (whether that’s in Minikube, AWS, GCP or elsewhere). We have highlighted some appropriate configurations you may wish to --set, but for the sake of brevity we have excluded many other values so please explore all options within each chart.


The simplest way to join the network is with burrow-connect:

This will create a new helm release titled an which automatically applies our burrow-connect deployment (pulling the latest instance of hyperledger burrow) to the current Kubernetes namespace. Another chart under ./src/burrow has been included to enable further customization outwith the AN.


Parameter Description Default
image.repository Image Repository hyperledger/burrow
image.tag Latest Stable Release 0.22.0
chain.infoURL Peers
chain.numberOfNodes # Pods 1


To support the high-level use of our smart contracting ecosystem, Blackstone will enable your organisation to easily interface with the main chain. First build the required dependencies and then install the API with a new node:

helm dependency build ./src/blackstone
helm install --name api ./src/blackstone --set=anNodes.enabled=true --set=chainInfoURL=${RUNTIME_INFO} --set=manualChain.signingAddress=${VALIDATOR}

A necessary dependency known as Vent is actually packaged with the chart to synchronize EVM events with the back-end database. In this case we use PostgreSQL, but the chart can also be configured to interface with the Google managed service. The last dependency is Hoard which also has a stand alone chart listed below.


Parameter Description Default
image.repository Image Repository
image.tag Latest Stable Release v0.5.0
an-nodes.enabled Burrow-Connect false
postgresql.enabled DB true
postgresql.postgresDatabase DB blackstone_development
postgresql.postgresUser DB blackstone_development
postgresql.postgresPassword DB blackstone_development
gcloudproxy.enabled DB false
gcloudproxy.existingSecret DB cloudsql-instance-credentials
gcloudproxy.existingSecretKey DB credentials.json
gcloudproxy.userCredentialsSecretName DB cloudsql-db-credentials
gcloudproxy.postgresDatabase DB ""
replicaCount # Pods 1
service.port Port 3080


Many of the objects referenced by the API need to be retrievable (or shared) at a later date, which is the sole purpose of Hoard. It is a lightweight content-addressed object store which can use the local filesystem, memory or even cloud-hosted buckets to host deterministically encrypted data in plain-sight.

By default, this will start the Hoard daemon in a single pod which can be port-forwarded to the localhost;

We can then communicate with the instance;

$ ref=$(echo bar | hoarctl put)
$ echo $ref | hoarctl get
~ bar


Parameter Description Default
replicaCount # Pods 1
image.repository Image Repository
image.tag Latest Stable Release 1.1.3
s3.enabled Store false
s3.region Store ""
s3.bucket Store ""
s3.prefix Store hoard
s3.envCreds Store true
s3.credentialsSecret Store ""