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 Systrem) 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?¶
User logs in to system
User generates a transaction
Transaction is validated within the network
Transaction is built into a Block along with other transactions
Block is added to the blockchain
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.