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’.
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.
Nocturne allows users to
Send / receive any token (ERC20/721/1155) to / from existing EOAs and on-chain applications (protocols such as Uniswap etc.) anonymously
Confidential payments to other stealth addresses (hidden sender, recipient and amount)
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.
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:
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.
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.
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.
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.
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.
User initiates deposit by specifying stealth address to deposit to
Funds are escrowed in Deposit Manager
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
Once the user’s deposit has been completed, this is the steps that lead to storage of funds within Nocturne.
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.
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
Here is the flow that occurs when a user wishes to carry out an operation with funds in Nocturne.
User puts in an order to swap 0.1 ETH for 200 DAI
This operation will be collected by the bundler and relayed to Teller, together with the proof
Teller verifies proofs
User’s 0.1 ETH will be sent to the Handler (operation executor)
Handler executes the operation by swapping the 0.1 ETH for 200 DAI on a DEX
Once the swap is complete, handler tracks this change by adding a note commitment for 200 DAI
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.
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.
This concept of stealth addresses holds the key to private transactions.
A stealth addresses comprises of two keys:
Viewing Key: Allows viewing of transaction, but spending is not allowed
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?
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:
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.
Per-Address Rate Limits
There is a default rate limit for the amount each address can deposit everyday.
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.
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.
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’.
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.
Nocturne allows users to
Send / receive any token (ERC20/721/1155) to / from existing EOAs and on-chain applications (protocols such as Uniswap etc.) anonymously
Confidential payments to other stealth addresses (hidden sender, recipient and amount)
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.
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:
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.
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.
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.
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.
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.
User initiates deposit by specifying stealth address to deposit to
Funds are escrowed in Deposit Manager
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
Once the user’s deposit has been completed, this is the steps that lead to storage of funds within Nocturne.
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.
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
Here is the flow that occurs when a user wishes to carry out an operation with funds in Nocturne.
User puts in an order to swap 0.1 ETH for 200 DAI
This operation will be collected by the bundler and relayed to Teller, together with the proof
Teller verifies proofs
User’s 0.1 ETH will be sent to the Handler (operation executor)
Handler executes the operation by swapping the 0.1 ETH for 200 DAI on a DEX
Once the swap is complete, handler tracks this change by adding a note commitment for 200 DAI
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.
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.
This concept of stealth addresses holds the key to private transactions.
A stealth addresses comprises of two keys:
Viewing Key: Allows viewing of transaction, but spending is not allowed
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?
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:
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.
Per-Address Rate Limits
There is a default rate limit for the amount each address can deposit everyday.
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.
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.
Subscribe to Cookies Research
Subscribe to Cookies Research
Cookies ResearchCoW Swap: Intents, MEV, and Batch Auctions
Low Fees and MEV-Resistant Trades: Made possible through intent-based architectureSpecial thanks to Anna and Alex for feedback and input on CoW Swap and its novel design mechanismsKey TakeawaysCoW Swap is an intent-based application that allows users to leverage signed messages to express their intent to trade (e.g. swap token A to token B)A batch auction mechanism is utilized, in which a network of solvers compete amongst each other to maximize user orders surplus, via Coincidence of Wants (...
Cookies Research1inch Fusion: Cost-Efficient, MEV-resistant Swaps
Key Takeaways1inch Fusion offers users the most favourable swap rates while being MEV-resistantA dutch auction model is utilized, where the swap rate is decreased over timeOrders are filled by resolvers, which are professional market makers, to give the best ratesUsers get to swap gas-free, as gas is paid by the resolversWhat is 1inch?1inch is a decentralized exchange (DEX) aggregator that aggregates liquidity across the various DEXs. This contributes to deep liquidity on 1inch, offering user...
Cookies ResearchMonad: Highly Performant, Parallelized, EVM Compatible L1
Summary thread available here.Key TakeawaysHigh Performance | Solid stats 10,000 TPS. 1 second block time. 1 second finality.EVM Compatible | Building is a piece of cake Full EVM Bytecode Compatibility: Applications built for Ethereum can be deployed on Monad with no code changes Full Ethereum RPC Compatibility: User-facing infrastructure (e.g. MetaMask) can be used seamlesslyUnique Architecture | The core to high performance 2 main fundamental architecture employed by Monad to allow for high...
Cookies ResearchCoW Swap: Intents, MEV, and Batch Auctions
Low Fees and MEV-Resistant Trades: Made possible through intent-based architectureSpecial thanks to Anna and Alex for feedback and input on CoW Swap and its novel design mechanismsKey TakeawaysCoW Swap is an intent-based application that allows users to leverage signed messages to express their intent to trade (e.g. swap token A to token B)A batch auction mechanism is utilized, in which a network of solvers compete amongst each other to maximize user orders surplus, via Coincidence of Wants (...
Cookies Research1inch Fusion: Cost-Efficient, MEV-resistant Swaps
Key Takeaways1inch Fusion offers users the most favourable swap rates while being MEV-resistantA dutch auction model is utilized, where the swap rate is decreased over timeOrders are filled by resolvers, which are professional market makers, to give the best ratesUsers get to swap gas-free, as gas is paid by the resolversWhat is 1inch?1inch is a decentralized exchange (DEX) aggregator that aggregates liquidity across the various DEXs. This contributes to deep liquidity on 1inch, offering user...
Cookies ResearchMonad: Highly Performant, Parallelized, EVM Compatible L1
Summary thread available here.Key TakeawaysHigh Performance | Solid stats 10,000 TPS. 1 second block time. 1 second finality.EVM Compatible | Building is a piece of cake Full EVM Bytecode Compatibility: Applications built for Ethereum can be deployed on Monad with no code changes Full Ethereum RPC Compatibility: User-facing infrastructure (e.g. MetaMask) can be used seamlesslyUnique Architecture | The core to high performance 2 main fundamental architecture employed by Monad to allow for high...
Share Dialog
Share Dialog
<100 subscribers
<100 subscribers
No comments yet