If you are here to learn more about Nocturne, please skip to the ‘Introduction’ section below to prevent being bored out by my little ramble about privacy.

Privacy is a necessity. There’s a reason why we set a passcode for our phones. There’s a reason why our bank account details are not easily accessed by others. But privacy, is a double-edged sword. This duality is rather apparent in the web3 space, with the most prominent example being the Tornado Cash sanction in 2022, which left the industry separated into two camps. On one side we have got the supporters of this ‘removal / limitation of privacy’ movement, with the argument that ‘privacy leads to problems such as money laundering’. Not wrong, right?. On the other side we have a group of dissatisfied individuals with the argument of ‘it is my rights to have my data stay private and known only to me’. Once again, seems right.

With the current landscape, I believe we can agree that crypto is way too transparent. By transferring some ETH from my account to another, the recipient is able to figure out that I hold no $PEPE in my wallet and missed out on generational wealth. That would be analogous to me buying a matcha latte at Starbucks and the cashier now knows that I don’t have enough for a latte the next day (because no $PEPE…). For crypto to achieve a money-like state, where peer-to-peer crypto transactions are a norm, privacy is a necessity. Some examples Nocturne brought up include the ability to:

• Receive payroll on-chain without revealing salaries

• Make purchases without divulging spending habits

• Store assets on-chain without disclosing net worth

Within the privacy sector we have seen efforts from multiple players, including Zcash, Monero and Mina Protocol. But it seems that the level of adoption has been rather stagnant. As to why, you can check out this article by @luffistotle from zeeprime.capital on why privacy has failed.

Nonetheless, we still see efforts being put in to achieve a balancing point that could potentially make the industry nod their head and say ‘yes to privacy! i mean, yes to regulated privacy!’. This is where Nocturne steps in with their solution, aiming to address the unmet needs of the privacy-conscious and integrate privacy into existing applications for the average user.

The main aim of this article is to have a better understanding of Nocturne’s architecture, to which I break down aspects of the documentation and provide analogies.

Disclaimer: The article is rather technical. I had to eat chocolate while reading the documentation to stay calm when I didn’t understand parts of it initially. If you don’t want your brain to hurt from reading, scroll to the bottom and read the ‘Conclusion’.

Introduction of Nocturne

Main innovation Nocturne brings to users: Private accounts.

Nocturne allows users to send or receive assets from Externally-Owned Accounts (EOAs) and contracts to private, stealth addresses. This keeps the user’s identity and asset balance a secret. It is possible for users to prove that they own these assets (which are hidden) without having to reveal any private information.

Benefits of Nocturne

Nocturne allows users to

1. Send / receive any token (ERC20/721/1155) to / from existing EOAs and on-chain applications (protocols such as Uniswap etc.) anonymously

2. Confidential payments to other stealth addresses (hidden sender, recipient and amount)

3. Prove asset ownership (solvency) and transaction history (compliance)

Point 2 taps into the earlier mentioned use case of receiving payroll on-chain without having to reveal the salary, net worth or spending habits. This makes absolute sense to a user. In the web2 world, me receiving a salary from my employer does not allow them to identify that I willing pay a million for a picture of a rock.

Particularly on point 3, the possibility of an user to prove their account solvency and compliance status (with no prior suspicious transactions) can open up a whole new set of opportunities for on-chain borrowing and lending. On the borrowers’ end, they will be able to receive a loan without having to disclose private information and on the lenders’ side, they will be able to accurately affirm the credibility of the borrower and offer a suitable level of interest rate. This builds into the increased level of capital efficiency given to users.

Something I would like to bring up here, but not delve deep into, would be the possibility of receiving loans based on income. This could be made possible by the combination of point 2 and point 3 mentioned above. Looking at the bigger picture, this opens up doors to much more robust on-chain protocols, just as how our salary can be used to qualify for mortgages, credit cards etc.

User Interaction with Nocturne

The team at Nocturne is forward looking, building the protocol out with a high level of flexibility that allows its user experience (UX) to take several forms. The following are some potential use cases that the team has highlighted:

1. Private Asset Vault

This is the first user product that will be built on Nocturne. As simple as it is, this vault allows users to privately store their assets over a period of time, while earning yield on the deposited assets. Should users wish to utilize these assets for activities like trading, they can withdraw them to burner wallets.

2. Backend for Private Payments

Instead of sending funds directly to a recipient’s EOA, a user can send the funds into Nocturne, and assign the stealth address to receive funds. By going through Nocturne, the transaction is kept private and secure.

One use case highlighted by the team is the setting up of a private payroll system. Looking at crypto companies these days, this is an aspect that they lack. With Nocturne, it is possible for employees’ salaries to be kept private.

Should users require an even higher level of confidentiality to their transactions, perhaps on an institutional level, they can opt in for confidential payments.

3. Privacy-Preserving Smart Contract Wallet

Here comes the exciting portion. Existing crypto users are reliant on numerous pieces of core infrastructure. The one that’s non-arguably the most important for users, would be the hot wallet, i.e. MetaMask etc. Hence, with any novel infrastructure that aims to impact the user experience (UX), it is critical for it to be compatible with wallets.

Nocturne checks off this box, with an off-chain SDK which can be integrated into existing wallet clients. This integration will allow users to continue using their wallets, but with the added benefit of built-in asset privacy.

Nocturne’s Architecture

The figure below depicts a high level overview of Nocturne’s architecture:

There are a few steps to Nocturne’s system. Let’s go through them one by one.

Deposit of Funds

Deposits into Nocturne have to undergo a screening process to minimize the inflow of illicit funds (more on this in the ‘Compliance’ section below). This is achieved by having a permissioned off-chain actor inspect all deposits, who will then decide whether to approve or reject the deposits.

To this point, I would like to express concerns over the permissioned off-chain actor due to two reasons. Firstly, what are the chances of this actor being exploited? Given that it is permissioned, what will this permissioned process look like? Secondly, given that it is off-chain, would it be difficult to track the approval / rejections that have been issued by the actor?* *

Here’s the step by step flow of how deposits into Nocturne are carried out.

1. User initiates deposit by specifying stealth address to deposit to

2. Funds are escrowed in Deposit Manager

3. Deposit Screener sees the deposit request and screens through wallet

   a. If approved → Deposit Screener signs the deposit hash → Deposit completed

   b. If rejected → User can retrieve escrowed funds

Storage of Funds | Upon Deposit Completion

Once the user’s deposit has been completed, this is the steps that lead to storage of funds within Nocturne.

1. Deposit Manager sends funds to Teller

   Do keep in mind that the escrow of funds in Deposit Manager only lasts for the period between initiation of deposit and approval / rejection of deposit.

2. Teller calls Handler to track note commitment of the funds

   The deposit is inserted as a note commitment in Nocturne’s Merkle commitment tree. This tracks all of the transactions that are occurring.

Let’s understand a little bit more about what notes are.

A note can be considered to be a ‘dollar bill’ that has a owner. There are 3 key characteristics to a note:

• Owner: An anonymous stealth address for the note’s owner

• Asset: Indicates the kind of token the note represents. Could be ERC20/721/1155

• Value: Indicate how much the note is worth

An example to help with understanding. Cookies has a ERC20 token that is worth $1, let’s look at the characteristics this note will have:

• Owner: This will be Cookie’s stealth address

• Asset: The note represents an ERC20 token

• Value: $1

Operation | Usage of Funds

Here is the flow that occurs when a user wishes to carry out an operation with funds in Nocturne.

1. User puts in an order to swap 0.1 ETH for 200 DAI

2. This operation will be collected by the bundler and relayed to Teller, together with the proof

3. Teller verifies proofs

4. User’s 0.1 ETH will be sent to the Handler (operation executor)

5. Handler executes the operation by swapping the 0.1 ETH for 200 DAI on a DEX

6. Once the swap is complete, handler tracks this change by adding a note commitment for 200 DAI

7. 200 DAI is sent back to Teller (storage)

One might be curious as to why the Teller and Handler are separate. The Teller serves as a storage for all of the user’s funds, while Handler only has access to the funds that users wish to transact. Should the Handler have access to all of user’s funds, a single exploit could potentially cause bulk of the funds to be lost. Thus, this segregation of roles helps to increase the robustness of Nocturne’s security.

Privacy Achieved Through Stealth Addresses

The above explains how user transactions are carried out in Nocturne. In this section, let’s take a look at the key innovation that allows for private transactions.

Keys & Stealth Addresses

This concept of stealth addresses holds the key to private transactions.

A stealth addresses comprises of two keys:

1. Viewing Key: Allows viewing of transaction, but spending is not allowed

2. Spending Key: Allows for both viewing and spending

Essentially, a user’s account details can always be kept private regardless of the kind of transactions performed with stealth addresses. With this, when I carry out a peer-to-peer transaction, the recipient will not be able to look into my account history to find out that I bought BTC at $69,000.

I have some questions regarding the differentiation of canonical and stealth addresses. It seems rather redundant for other users to have access to my canonical address, if the main aim is to spin out a stealth address for others. Wouldn’t it be sufficient for other users to have access to a stealth address that I spin out for them, and that can be the address used to pass on to others?

Compliance | Say ‘No’ to Regulatory Clampdowns

Over the past year, we have seen the SEC crack down on the crypto industry, with multiple parties being on the receiving end: stablecoins, centralized exchanges, protocol / company leaders. Privacy protocols, in particular, would intuitively be subjected to a higher level of scrutiny, given the inherent lack of transparency it results in. To steer clear of such regulatory issues, there are compliance features to Nocturne:

1. Deposit Filtering

   High-risk deposits are filtered out using public on-chain metadata and known address blacklists. This by-passes the need for users to share any additional information beyond what is available on-chain.

2. Per-Address Rate Limits

   There is a default rate limit for the amount each address can deposit everyday.

3. Global Rate Limits

   Deposits across all address are limited by the global rate limit.

With the above mentioned features acting as barriers to entry, Nocturne is able to effectively keep malicious funds out of the protocol. Not only does this play a part in keeping it compliant, it also ensures that users of Nocturne are safe-guarded against protocol hackers.

Conclusion

If somehow you are here at the conclusion but didn’t manage to read through the above parts (no worries I honestly wanted to flipped the table a few times when I couldn’t understand Nocturne’s architecture and had to drink some milk to calm myself down), you can read this introductory article by the team themself, and for more details, you can visit the documentation here.

To summarize, Nocturne is looking to enable private transactions through the usage of stealth addresses. With the industry seeking for mass adoption, privacy in crypto is a necessary pillar that has to be strengthened. Through the materials, it is apparent that Nocturne is looking to contribute to this pillar in a manner that does not result in UX tradeoffs, while offering increased level of flexibility and security.