Ethereum, the world permissionless computer, is becoming popular among users who want to regain control over their finance and digital data. Nowadays every interaction with Ethereum is public and anybody can monitor what other users are doing. Privacy is a crucial component for building a trustless computer used worldwide and not a global panopticon that would enable total surveillance.
At the PSE team we worked in different aspects of on-chain privacy. My most recent role involved evaluating and benchmarking private transfers protocols (you can see a dashboard here). In my opinion private transfers are the atomic operation required to bring privacy on-chain but I was wondering what would be the next steps after users are able to successfully perform private transfers.
My crypto experience started with learning about decentralized ledgers (Bitcoin, Ethereum, Polygon, etc.), investing into multiple assets (BTC, ETH, etc.) and later on learning cool stuff that I could do with those assets. One of the most revolutionary one was permissionless lending.
In a nutshell, a lending protocol allows a user to deposit collateral (e.g. ETH) and borrow any asset (e.g. USDT). This is called a lending position. The collateral value (ETH) would have to always be greater than the borrowed amount in order to protect the lenders assets (USDT). The user would be able to use USDT in anything he wants. The happy path would be the collateral increasing in value, because the user would still need to return only the borrowed amount and nothing more. The worst case path would be the collateral decreasing in value, because the protocol would sell the collateral in order to cover the borrowed amount. This action is called liquidation.
Now the question is how would a private lending position work? It would depend on the private transfer protocol and its tradeoffs. Let me expand with the most popular and production ready private transfers categories:
Notes-based private transfers use UTXOs (Unspent Transaction Output) like Bitcoin. Every time a user receives a private value, a note is assigned to him. In order to spend it he generates a ZK proof showing note ownership and also a nullifier that invalidates the note from being used again (prevent double spending). On the on-chain layer, these protocols keep funds in a shielded pool smart contract. Every transaction sends ZK proofs to the contract and the private state is updated.
To integrate notes-based private transfers protocols with a standard lending protocol (e.g. Aave or Morpho), the protocol needs to publicly deposit collateral funds and borrow assets. If multiple users want to use the lending protocol, the shielded pool contract will have different positions to its name. One contract will be the owner of several positions with different collaterals and different borrowed assets. This would create a huge liquidation risk that could affect conservative and risky users.
Another approach to do this would be to deploy one contract per position. The user would send a request to interact with the lending protocol and the notes-based protocol will deploy a single smart contract that would control the position. The risk will be isolate to each smart contract so users will not be affected by the decisions of other users. The tradeoff here is that the position itself will be public and visible. Nobody will know the position owner but everybody will be able to check the data and conclude the position strategy. In some cases the metadata (position amount, chosen assets, timing, etc.) could leak the owner identity.
Homomorphic-encryption (HE) based private transfers usually involve confidential transactions where the amount and balances are hidden but the sender and recipient are visible on-chain. These protocols could use simple HE schemes (e.g. Tongo Cash) or co-processors (e.g. Zama and Fhenix) to perform operations that sends tokens from one account into another.
To integrate HE-based private transfers protocols with a standard lending protocol, the former will need to be updated in order to understand and execute HE operations. For example a user would deposit a confidential wrapped token (cUSD) and borrow any available public asset. The position collateral amount will be private and the liquidation mechanisms would need to perform HE comparison operations (e.g. lessThan) in order to execute a liquidation if required.
There is progress on modifying and adapting lending protocols to use confidential tokens but it is not as straight forward as the other categories because the lending protocol is required to be adapted. In my opinion, private lending using HE will be the cleaner way to hide your position and strategies from on-chain observers.
Stealth addresses are single-use addresses that recipients will generate so senders can send assets to those unlinkable addresses. The recipient will later on be able to deploy smart accounts into those addresses and move the received assets around.
An integration of stealth addresses protocols with standard lending protocols would be straight forward. The smart accounts deployed on the stealth addresses are normal smart contracts that can interact with DeFi protocols like lending ones. If one of these smart accounts interact with the lending protocol, the unlinkability property will be intact but the position data will be public. This is the same tradeoff as notes-based protocols.
As you can see, there are multiple challenges and tradeoffs in implementing private lending protocols for end users that would like to have their position private from the on-chain observers. There are multiple teams and organizations tackling these challenges and the only comment I can be sure of saying is: Privacy is coming.
If you liked this article please follow me in X (former Twitter): https://x.com/NicoSerranoP . I am planning on writing more about Ethereum and the privacy layer. Thank you very much for reaching the end, I apologize in advance for not describing other interesting private transfers categories but in future writeups I will highlight them.
Cover photo by Nihar Bhagat on Unsplash

