What is Labyrinth: The Solution to Ensuring Privacy and Ending Blockchain Surveillance

Blockchain revolutionized money, making it flow globally as effortlessly as information does across the Internet. Yet, this breakthrough came with a stark price: Transparency. Every transaction and user activity is publicly visible to anyone.

Privacy has emerged as the ultimate frontier, the biggest barrier to reaching mass adoption. Imagine this: You’re strolling through the streets, popping into a café, and paying for your coffee with crypto—smooth, modern, and trendy. Big names like Base Chain are partnering with coffee shops around the world to make this a reality with the Accept USDC campaign, and companies like Gnosis Pay and MetaMask are rolling out crypto cards that promise the ease of a swipe. It feels like the future, doesn't it?

But here’s the twist in the tale: Every one of these transactions leaves a digital breadcrumb trail that anyone can follow. While you sip your espresso, your payments are logging your location, your spending, and your habits into a ledger that's open for the world to see. It's not just Base, Gnosis, or MetaMask either—giant protocols like Uniswap, Lido, and Aave are part of this too. Your on-chain transactions are transparent as glass.

This isn’t just about losing privacy; it's about how the tool designed to empower us could become the ultimate surveillance system. Attempts have been made in the past to provide privacy, but those solutions still need to achieve compliance in a decentralized manner.

This blog will guide you through the corridors of Labyrinth, showcasing how it uses cryptographic techniques, Zero-Knowledge proofs (ZK), and blinded(stealth) addresses to protect user’s transactions from prying eyes while playing by the rules.

Overview of labyrinth’s modular privacy framework 

Labyrinth provides a Shielded(private) account for EVM-based networks so that users can do on-chain activities with privacy in a compliant way. From here we will explain the complete transaction cycle within Labyrinth, showcasing how privacy, security, and compliance are seamlessly integrated at every step. Whether you're depositing funds, transferring assets, swapping through an external protocol, or withdrawing, Labyrinth ensures that your activities remain anonymous and secure.

Creating a shielded account With an existing wallet

A Shielded Account can be thought of as having a private crypto account parallel to regular Ethereum accounts. Unlike public ethereum accounts with their single public-private key pair, a shielded account comes with not one, but two key pairs - one to sign and one to view—along with a Root Address (which is essentially the user’s address). The Sign Key is your shielded account’s private key, and as the famous saying goes: "Not your keys, not your assets.".It’s what lets you access and spend your funds. The View Key, on the other hand, is like a read-only mode—good for peeking at transaction history or balances but completely powerless when it comes to spending.

For a smoother experience, the shielded account keys are derived from the user’s public Ethereum address. So, there’s no extra headache of managing a new set of keys or seed phrases—your existing wallet (whether it's MetaMask, Rainbow, Coinbase, Ledger, etc) gets the job done. This means users can easily create a shielded account using the wallets they’re already comfortable with.

The protocol uses the shielded address for all the transaction transactions in the labyrinth protocol. This would mean the sender has to know the recipient’s shielded address. which results in a UX nightmare. 

Labyrinth solves this by having users register their public wallet address which points to their shielded address. This mapping is stored as event data on-chain, so the sender only needs to know the recipient’s public address (or even their ENS name) as the public address can be resolved to a shielded address. Crucially, the public address is used to resolve the transaction off-chain at the SDK level. it is never exposed on-chain. This means that during any transaction, the user's public address remains hidden, preserving their privacy. Registration is done during the onboarding process before a user starts doing transactions. With ENS integration, users no longer need to remember any addresses, making the user experience seamless and far superior to most privacy applications out there.

Entering the Shielded pool with a deposit 

When a user first creates a shielded account and deposits their assets into Labyrinth, they place them into a private vault known as the Shielded Pool. It handles user’s funds with utmost confidentiality, ensuring that their activities remain private.

As user deposits their funds, Labyrinth generates an encrypted note memo that holds the details of the user’s asset—completely encrypted. The note contains information like the asset, asset value, address of the owner, and revoker. A user can have zero or more notes in their shielded account. The asset balance of a shielded account is simply the sum of the values of all notes of that asset. These notes are stored in the Merkle tree. It is a data structure that is used to store and verify the integrity of data. 

Labyrinth uses a UTXO-based architecture (Unspent Transaction Output) for notes, similar to Bitcoin. The transactions in this architecture simulate the spending of physical cash notes in a peer-to-peer transaction. The UTXO (UnSpent Transaction Output) can be considered as a digital Note. Each note represents a certain value of an asset, and as long as you hold the note, you have the authority to spend that value in a future transaction. 

Proving ownership with Zero Knowledge Proof 

We are making transactions Unlinkable and untraceable possible with the help of ZKPs, blinded(stealth) addresses, and bundlers. Let’s understand how. Now that the user’s funds are privately stored in a shielded pool, a user may want to transfer them. whether it’s doing a transfer, swap, staking, lending, or batch transactions for payroll token vesting, for every transaction users have to generate a zk proof of inclusion, for the note(s) they are spending and also verify their ownership over those notes. 

As described above, using encryption and ZKPs, users achieve confidentiality and undetectability. Encryption ensures that transaction details are kept private, while ZKPs verify transactions without revealing any private information about the user or the transaction itself.

To ensure that the user’s address is unlinkable with the transaction, we leverage a blinded(stealth) address. These addresses are essentially one-time-use addresses generated uniquely for each transaction, making it impossible to trace them back to your main wallet or your shielded account.

To ensure that a user's address is unlinkable with the transaction, blinded(stealth) addresses are leveraged. These addresses are essentially one-time-use addresses generated uniquely for each transaction, making it impossible to trace them back to the user's main wallet or shielded account.

However, ensuring transactions are untraceable requires an additional solution. Typically, when users make transactions like swaps, stakes, or simple asset transfers with the Labyrinth Pool using their wallet address to pay a gas fee, it would expose their address on block explorers, potentially linking it to their previous deposits and compromising their privacy. To prevent this, EIP-4337 bundlers are used to relay the transactions.

The bundler acts as an intermediary that submits transactions on behalf of the user. Instead of paying gas fees directly from their public wallet, which would reveal their address, the bundler covers these fees upfront. Users then reimburse the bundler from their shielded balance once the transaction is complete. This process ensures that their public wallet address remains hidden, and the transaction remains completely untraceable, preserving their privacy throughout the entire process.

Interacting with external smart contracts of protocols using Labyrinth’s Adaptor Handler

Labyrinth goes beyond private transfers by being fully interoperable with most protocols without requiring changes to those protocols. This allows users with shielded accounts to perform shielded operations like swaps, staking, and lending anonymously using external protocol integrations. The Labyrinth SDK and external adaptor handler contract simplify the integration by abstracting the complexities of zero-knowledge proofs (ZKPs) and compliance, enabling developers to create secure, private, and compliant dApps effortlessly. 

Developers don’t need in-depth knowledge of ZKPs. The core API of their protocol, which may be already deployed, remains the same. No change is required in the already deployed contracts. The only requirement is a standalone adaptor contract needs to be written that facilitates communication between Labyrinth and the external protocol. We call these contracts Protocol Adaptors. These contracts take input assets from the user's shielded account, convert those assets to some other (output) assets, and return these output assets back to the Labyrinth pool for the user to access. The interaction converts from one asset to another. Some examples:

• When WETH with USDC on Uniswap you're converting your WETH (input) to USDC (output).
• When staking WETH on Lido you convert your WETH (input) to wstETH (output).
• When lending USDT on Aave, you convert it to aUSDT.

When users interact with external protocols using the Labyrinth App, our Adaptor Handler comes into play. This component manages various transaction types, including swaps, stakes, and lending for the requests that are coming from the Labyrinth pool. 

Let's discuss when the user gets anonymity and confidentiality within the Labyrinth protocol. When a user performs operations like deposits, withdrawals, or transactions involving external protocol adapters (e.g., Uniswap, Aave, Lido, etc.), the user's anonymity is still protected by hiding the wallet address, but they lose confidentiality by exposing some metadata, such as the transaction ID and the value of the transaction. This exposure occurs because Labyrinth must interact with external liquidity pools that aren't shielded like Labyrinth’s shielded pool. In the case of internal transfers, where the user directly interacts with Labyrinth’s shielded pool, both anonymity and confidentiality are possible.

For more comprehensive details on how SDK works for protocol integration, how you can offer privacy to users, build new private applications, and more - check developer documentation. It’s ready and designed for various use cases like wallets, OTC desks, Lending & staking protocols, and payroll to test private payments.

User owned compliance 

Along with keeping privacy, decentralized compliance is a fundamental part of Labyrinth's transaction system, designed to prevent illicit activities and protect innocent users. Our Selective De-Anonymization (SeDe) network establishes regulatory standards, allowing privacy-preserving applications to trace illicit transactions without centralized control, ensuring adherence to regulations. Users have full control over their assets without any fear of innocent user’s assets getting frozen. In the upcoming blog series, we will talk about compliance methods that we are using but for an overview, you can refer to this documentation or check the compliance research paper. 

Recently, we made a strategic partnership with 0xbow to bring even stronger compliance and trust proof to Labyrinth to identify illicit actors while allowing you to prove your genuineness by submitting trust proof during transactions, ensuring a safer and more trustworthy environment for all users.

Conclusion: User-own the future of privacy 

V1 private testnet is now live with the Labyrinth application and SDK! Labyrinth application offers a user-friendly, private, secure, and compliant interface where users can deposit, and store their assets with privacy, and explore the decentralized compliance explorer and various applications within the Labyrinth ecosystem.
The app includes use cases such as Transfer, Swap, Staking, Yield Farming, Lending, Batch Transactions for Payroll, and Token Vesting. Check this document to explore more about the application and apply for early access here. We invite you to test it whether you are an individual, protocol, or institution and share your feedback.

If you're interested in integrating SDK to provide private payment solutions into your product, we’d love to hear from you.

Join our community on Discord to dive into conversations, ask any questions, or provide feedback. follow our updates on Twitter, or reach out via email for any queries.

Labyrinth Whitepaper
Labyrinth Compliance Paper