Designing a Security Token Blockchain (3): Privacy
By Dusk Network

May 28, 2019


This is the third article in a multi-part series where we deep-dive into the design choices behind the Dusk Network. In this article we explain why we are designing for privacy.

Series outline

The first article in the series talked about our choice for a public and permissionless blockchain. The second article talked about our choice for direct settlement finality, fork resistance and pool resistance. These decisions allow anyone to take part in the consensus, prescribes how nodes check and audit transactional data before storing it, provide for real-time and direct settlement of transactions, preventing of forks and disincentivizing monopolistic power structures.

Today we discuss what we colloquially call the privacy of the ‘transaction layer’ which describes the level of privacy granted to transactors of the network. The decision to design for privacy relates to regulatory directives and legal requirements, and has far reaching technical consequences.

Defining Privacy, Pseudonymity


In the context of blockchain technology, privacy is about the inability of the public to identify transactors.


We talk of pseudonymity if the user can be (re-)identified through transactional data. Transactional data could be information related to the asset in a wallet, the number of assets traded or held, or the IP-addresses of the transactors.

How Dusk Network addresses privacy

Privacy is often misconstrued as a bad thing, while privacy is foremost about trust and context. In our relationships with banks, or government entities, we trust them to respect our privacy. Details of customer’s financials should remain confidential and not shared. Breaches of that confidentiality are breaches of trust. Of course, privacy isn’t limited to financial institutions. Every single company in the world is in some capacity involved with privacy. Data protection legislation applies throughout the entire world and underscores the need for privacy. The most noteworthy examples are Europe’s General Data Protection Regulation (GDPR), and SECs regulation s-p which mandates registered broker-dealers, investment companies, and investment advisers to address administrative, technical, and physical safeguards for the protection of customer records and information.

Dusk Network is used to register, issue and trade digital securities. Thereby the Dusk Network needs to serve as a financial market infrastructure (FMI) and cater to the many demands of the highly-regulated securities market. Issuers and investors alike must be protected and the ability to comply with regulatory requirements needs to come naturally.

Without privacy, traders on the network can be identified through secondary data (e.g. timing of transactions and transaction size, or even IP-addresses). Their actions, for example moving assets to an exchange or trading asset at a certain price, could cause a reaction in the market. If transactions on a blockchain can have an effect on the market, then the infrastructure is not market neutral. This means that transactional transparency, as opposed to transactional privacy, leads to inefficient markets and possibly market manipulation.

Furthermore, without privacy it is impossible to adhere to confidentiality agreements that underpin most of the transactions made by institutional parties. Think of a large player accumulating shares in stealth so to not get unfair/higher priced shares in subsequent deals. Without privacy such confidentiality agreements can simply not be kept, deterring these players from using the blockchain as an FMI for securities.

In short we need privacy so that we can:

  • Facilitate a market neutral infrastructure;
  • Prevent market manipulation;
  • Be compliant with well-established regulations, and;
  • Cater to the needs of institutional players.
So what does designing for privacy look like technically?

First, we need to unlink someone’s identity from a transaction. Dusk does this by using stealth addresses, a procedure through which a new keypair is created for every single transaction, whereby identities of the transaction’s originator remain anonymous as the newly generated keys are indistinguishable from keys used in other transactions. Secondly, by using ring signatures, which uses decoy transactions (inputs), the transactions are further concealed. Thus, for any transaction the asset-type and the amount transferred (obfuscated through Pedersen Commitments) cannot be linked to one identity.

Finally, we require the ability for issuers of XSC-based securities to program restrictions and requirements into their securities. This is called programmability. To achieve programmability without disclosing details the aforementioned techniques are coupled with proofs created in zero-knowledge. Dusk has advanced and expanded the toolkit to create zero-knowledge proofs. This enables transactors to prove, whilst preserving their privacy, that they are part of a whitelist and to prove that prerequisite conditions are met without disclosing who they are to the public. The proofs are verified — checking that they are legitimate — and the smart contract completes the transaction upon seeing these proofs are correct and fulfill the prerequisite requirements to let the transaction go through.


During the inception of the Dusk Network, it’s been our priority to create an ecosystem that is accessible by anyone, truly lowering the barrier to enter the financial industry, and replace intermediaries effectively with technology. We are creating a blockchain that will become the backbone of a fairer financial industry. By designing for privacy we give (institutional) investors the tools they need to safely enter the marketing for digital securities / security tokens.

In our next series, we touch on our programmable XSC securities (smart) contracts and why a controllable standard is required.

Dusk — Technology for Securities

Dusk streamlines the issuance of digital securities and automates trading compliance with the world’s first programmable and confidential securities.

Share this post

Subscribe to our newsletter

Dusk on GitHub Download Whitepaper