Open Source vs Proprietary

Blockchain code can be classified as opensource or proprietary. SETL deliberately chooses to maintain a proprietary model with regard to its core code. However, this does not restrict in any way, the ability of users to independently verify and prove records on the SETL blockchain using standard cryptographic techniques – without reference to SETL or SETL’s software.

SETLs choice to remain proprietary is based upon the following:

  1. Opensource blockchains tend towards general solutions. SETL’s domain focus is a significant business advantage in financial services.

  2. SETL has significant investment in the unique IP that it has developed for financial services, and it is not in SETL’s interests to make it available to potential competitors.

  3. Other large scale collaborative software providers in financial services such as SWIFT and MarkitWire do not opensource their software. Both connect many banks and infrastructure providers together in collaborative ways but choose to keep their core software proprietary.

  4. There is no history of core financial infrastructure being opensource. For example, CREST, RTGS, T2S and Euroclear do not opensource. Even though T2S is a publicly funded and relative recent infrastructure it did not choose to opensource its code.

  5. A requirement of deploying software as infrastructure is being able to assert control over its development and being responsible for its maintenance. This is not compatible with putting code up on github for ad-hoc collaboration.

  6. Where competitors have opensourced their code, it has supported a different commercial model where they are actively promoting other revenue sources. IBM, for example, promote highly priced consulting services. Going toe-to-toe with IBM and others in technology consulting is unlikely to be to SETL’s commercial advantage.

  7. As an opensource project, SETL might lose control of the technology roadmap. This would mean that we could not quickly upgrade or change the core blockchain functionality in response to Client, Market or Regulatory requirements.

Differentiating Factors

The SETL Blockchain has been designed from the start with the needs of financial services in mind. There are many other uses for Blockchain, but we leave those opportunities to other providers, our focus is entirely upon financial services.

The attributes that we have focused upon, that financial markets value most, are:

  1. Speed: It is important that any single transaction be processed and made final very quickly. The SETL Blockchain aims to process all outstanding transactions within a 5 second window. SETLs blockchain has been benchmarked at 20,000 TPS.

  2. Capacity: The system must be able to cope with high transactional volumes. The SETL Blockchain aims to cope with huge numbers of accounts and Balances – currently 100 million.

  3. Identity: Financial regulation requires that all participants and transactions are identifiable. Identity has been a core consideration of the SETL Blockchain ecosystem.

  4. Real Assets: Assets are individually registered on the SETL Blockchain, they are not represented by ‘colouring’ a single crypto asset as with some other systems.

  5. Targeted functionality: The SETL Blockchain has functionality, transaction types and market integrations, that have been implemented with the sole purpose of making common financial market operations easier, faster and cheaper.

Attributes that we have specifically avoided, that would inhibit adoption in financial markets, are:

  1. Anonymous crypto currency. Many systems such as Ethereum, Ripple and Bitcoin rely upon a cryptocurrency to work. Typically, activity of any kind on these blockchains require the user to acquire and then pay some sort of token. The price of using these blockchains can vary dramatically on day to day basis. This is not a common business model in financial services and not scalable to any significant volume.

  2. Anonymity and Censorship resistance in general. Quite simply, not possible in regulated financial markets.

Competitor Comparison





SETL does not support anonymous value transfer

Public blockchains have at their core a permissionless ethos. This means that key functions such as validation can be undertaken by anonymous parties. Honesty is incentivized by the passing of a cryptocurrency between anonymous parties. This is true for Ethereum (ETH), Ripple (XRP) and Bitcoin (BTC).


SETL does not require ‘mining’ to work.

Mining is the process of anonymous parties competing for the right to propose the next block of transactions. Mining is designed to be expensive and cumbersome to engineer incentives for participants to act honestly. The bitcoin blockchain alone is estimated to use over 2.5GW of electricity – about the same as the electricity consumption of Ireland.


SET has bench-tested its blockchain at over 20k transactions per second. However, speed can be scaled infinitely by having multiple SETL blockchains which can interoperate.

Bitcoin currently processes around 5 transactions per second. Ethereum can process 15 transactions per second. Ripple claims 1500 transactions per second. Hyperledger Fabric 2500 transactions per second Corda 170 transactions per second

Financial Services

SETL has built financial services functionality into its core. This means that certain transaction rules are part of the core consensus algorithm – such as power-of-attorney arrangements.

Most competitor blockchains have been designed to be extremely general. Financial service functionality is built using add-on tools such as smart contracts. These run slowly and are typically of dubious quality and functionality. ERC20 is an add on smart contract for Ethereum that could result in holders of tokens permanently losing them.


Regulators require that financial services companies are able to identify users, monitor activity, report suspicious activity, implement sanctions if required and block malicious activity.

Blockchains such as Ethereum, Ripple and Bitcoin are designed to allow anonymous participation and advertise censorship resistance as a feature. Certain systems such as Quorum are built on Ethereum and try and roll back such feature with smart contract code – the equivalent of putting wheels on a horse to make a car.

Commercial Model

SETL presumes that the appropriate commercial model is determined by the use case and should be within the control of the participants.

Blockchains such as Bitcoin, Ripple and Ethereum build commercials into the protocol. Typically, they require users to bid for transaction processing or storage using limited supply tokens. This results in wildly variable transaction costs. The cost of a Bitcoin transactions has varied between $0.03 and $55.00 over the last three years.

Source code control

SETL maintains full control of its source code. This both ensures security and allows SETL to be responsive to needs as they arise. Regulators require infrastructure software to be in the control of a responsible party.

Opensource blockchains allow their code to be changed by anonymous contributors. Ethereum’s core code lists over 300 contributors- many identified only by handles such as b00ris and LLLeon.


SETL configures its privacy model around current trust relationships. Transactions and balances are only sent to and accessible by permissioned parties.

Blockchains such as Ripple, Ethereum and Bitcoin allow all participant to see everything. Privacy extensions of these blockchains (such a s Quorum) use complex cryptographic protocols to mask certain information from certain parties. Relying on encryption alone for privacy is risky as all protocols become less reliable as computers and crypto techniques evolve. Widely distributed encrypted information is likely to become public and open in the futureregardless of how smart the protocol seems today.

Security Model

SETL secures its information and business by conforming to industry standards such as ISO27001 and Cybsafe. All staff are security cleared and all developers undergo secure coding training. All code is externally reviewed by security specialists and security vulnerability scanning is completed on every code commitment.

Typically, blockchain code has been written by loosely affiliated teams with a reliance upon ‘opensource’ as a security strategy. The assumption is that because the code is available for review that someone will review it. This is not an approach which is likely to meet the requirements of financial service regulators.