OpenCSD Overview

This document provides an overview of SETL’s Core product, known as OpenCSD, which comprises:

  • The Frontend – a user interface that gives access to the system

  • The Application Services – proprietary software to provide functionality:

  • Wallet Node to verify users and transactions and give access to other functions such as user administration, report production, creation and settlement of transactions, messaging, etc.

  • Validation Node to validate and collect transactions, agree consensus and add Blocks to the chain

  • Boss (Big Object Storage System) to provide blockchain storage and retrieval and database management

  • The Blockchain Ledger – the immutable record of the transactions that make up the State of the system

What is the system for?

The system is called OpenCSD, and a CSD (Central Securities Deposit) is a very specific financial mechanism. However, the principles underlying OpenCSD hold true for practically any financial system - to securely, swiftly and reliably execute transactions and then to safely store the transaction details. SETL’s system is suitable for:

  • Sales - financial transactions that transfer property or services in return for money or credit and include providing the goods or services, issuing invoices, and collecting payments.

  • Purchases - financial transactions that include receiving goods and services, recording the transaction as accounts payable, and paying the supplier.

  • Payroll - transactions that include calculating and recording gross pay, deducting and paying taxes, paying net pay, paying for insurances, etc.

  • Financing - transactions that include receipt of money from debt instruments, periodic interest payments and debt repayments, dividend payments, and the like.

  • Document Management – the technical integrity is immutably managed by the blockchain for any documents stored in the SETL system (and some external networks).

How does it work?


  1. User logs in to system

  2. User generates a transaction

  3. Transaction is validated within the network

  4. Transaction is built into a Block along with other transactions

  5. Block is added to the blockchain

  6. Transaction is completed

Obviously, the specifics will depend on the type of financial system – but generally, the user will have been previously verified and is logging in and using an account, connected to a Wallet. The transaction will normally be one half of a two-way contract – payment for asset, transfer of funds etc. The validation will depend on a number of requirements – contract exists, user has authority, user’s Wallet has necessary assets, transaction is correctly detailed etc. Assuming valid, the transaction is offered for consensus, and when agreed is built into a new Block. Blocks are regularly added to the blockchain and the transactions are then fixed, finalised and immutable – this marks the completion of the transaction from the user’s perspective. The whole process should be completed in a maximum of 5 seconds.

What makes this different?

The fundamental differences between this blockchain-based solution and traditional mainframe-based financial systems are:

  • Performance: using standard technological equipment, this solution is capable of delivering 30,000 TPS (transactions per second) – to put this into perspective, VISA currently is capable of 1,700 TPS.

  • Scale and capacity: no theoretical limit to the number of accounts, and 100 million States.

  • Identity: Fully permissioned and comprehensive KYC and KYP capabilities built in

  • Interoperability: Interfacing into global market structure (ISO, SWIFT etc)

  • Security: High level cryptographic techniques provide immutable record keeping and the duplication of States provides protection against corruption

  • Environmental: The speed and efficiency of the software reduces power consumption compared to legacy products

  • Resilience: The distributed nature of the solution reduces reliance on single end points and essentially means that there is no need for backups

  • Availability: With multiple points of contact for the UI, the loss of one or more Nodes will not impact the availability of the system. Automatic rebuilding of States on restarted machines means hot swapping can be performed.