Indigo Architecture


Chainscript is an open JSON Standard for Proof of Process. By extension, digital records of cryptographic audit trails are referred to as chainscripts. Chainscript describes how each step of a process should be formatted so that:

  • It is unique
  • It is immutable
  • It has only one parent
  • It can have multiple children
  • It can reference other steps


The agent runs multiple processes. Each process is responsible for transforming data into Chainscript. It knows how to initiate a new map, how to add a step to an existing map, how to notarize and save steps, how to find and filter existing steps.

A process can be configured by declaring the different transitions that may happen to each steps and by implementing in JavaScript the mutations that these transitions imply. These transitions are called actions.

The agent exposes an HTTP API that provides read and write access to the underlying processes.

Agent Clients

An Agent client wraps the HTTP API so that it’s easy to use in your language of choice.

Implementations currently exist in JavaScript and Ruby.

Agent UI

The Agent UI provides a simple generic graphical user interface that allows anyone to get information about agents and to read and write new steps in a process.

Agent UI

It leverages the JavaScript Agent Client and the Map Explorer.

Map Explorer(s)

This generic component can be used to display a specific map in a process.

Map Explorer

It is configurable and extensible.

It is available for different frameworks (React, Angular, Angular2, Ember, Rails).

Store and fossilizer

Once a new step (called segment in Chainscript) has been created by the Agent, it needs to be stored and (eventually) fossilized.

It can be stored in a regular (centralized) database. In that case, to reduce the trust put in the database owner/administrator, the segment needs to be timestamped. We can use any timestamping service but a public blockchain such as Bitcoin provides a secured, decentralized, powerful, cheap and fast timestamping service.

This fossilization, as we call it, provides a strong proof of existence.

This architecture is already pretty solid but:

  • The Agent is centralized. It cannot be trusted (with private data for instance).
  • There is no warranty a piece of data won’t ever be removed.
  • The Agent/owner of the database has to be trusted to enforce business rules.
  • It is dependent on a public blockchain on which the user has no control.

To address these issues, segments can be stored in a permissioned blockchain.

With this kind of architecture:

  • Each stakeholder can have his own agent that can be trusted with private data. It can encrypt data, sign data, generate zero-knowledge proofs, etc.
  • Fossilization becomes optional. The blockchain already provides a timeline and a proof of existence.
  • Business rules can be agreed on, and enforced at the storage level. Consensus can be reached on a single version of the truth (this kind of feature is not yet available and currently being researched and developed at Stratumn).