Labyrinth
WhitepaperResearchGet Private Access
  • 🔭Labyrinth Overview
    • Introduction
    • Why Labyrinth?
    • Who can use Labyrinth?
    • Reward and Fee in Labyrinth
    • Compliance
  • ⭐Use Labyrinth web App
    • How to use the Labyrinth app?
  • 📦Labyrinth SDK
    • ❓What is Labyrinth SDK?
    • ⚒️Quickstart
      • Setup Environment
      • Initialization
      • Private Transactions
      • Balance And Transaction History
      • Protocol Integration
    • 1️⃣Getting Started
    • 🔐Shielded Account
    • 📈Transaction
    • ▶️Initializing SDK
    • 💰Balances And History
    • 📤Sending Transaction
    • 🔌Integrating with DeFi Protocols
    • Labyrinth fee structure
  • Compliance Solution
    • Overview of Compliance
    • How Compliance Works
  • 💻CLI
    • ▶️Running SeDe CLI
  • Technical Implementation
    • Cryptographic Primitives
    • Shielded Account
    • Shielded Address
    • Account Abstraction
    • 🔵Core Architecture
      • 💵Note
      • 🌲Merkle Tree
      • 🔀JoinSplits
      • 🛡️Shielded Transaction
    • 🔄Protocol Interoperability
  • Resource and support
    • Roadmap
    • FAQs
    • Whitepaper
    • Selective De-Anonymization Compliance Paper
  • Contact and socials
    • Labyrinth Website
    • Twitter
    • Discord
    • Contact Us
Powered by GitBook
On this page
  1. Technical Implementation

Protocol Interoperability

PreviousShielded TransactionNextRoadmap

Last updated 10 months ago

Labyrinth protocol is designed to be interoperable with most of the protocols without requiring any changes in the protocol integrating Labyrinth. This means users with shielded accounts will be able to perform shielded operations like swaps, staking, lending, etc. anonymously.

Interoperability with a protocol is achieved via a simple contract that we call Adaptor. Adaptor contracts are simple state-less contracts that live on-chain to act as a proxy for interacting with a target protocol. This contract must implement a standard interface that exposes a handleAssets function. In Solidity, it can be implemented by inheriting the interface IAdaptor.

contract IAdaptor {
    function handleAssets(
        uint24[] calldata inAssetIds,
        uint256[] calldata inValues,
        bytes calldata payload
    ) external payable virtual returns (uint24[] memory outAssetIds, uint256[] memory outValues);
}

This reflects the fact that, in general, most asset operations e.g. swapping, lending, staking, can be thought of as a process of converting from one asset called input asset to another asset called output asset. Here are a few examples:

  • When swapping ETH for USDC on Uniswap, ETH (input asset) is converted to USDC (output asset).

  • When supplying DAI on the AAVE market to earn interest, DAI (input asset) is essentially being converted to aDAI (output asset) the interest-bearing tokens given back in return.

  • Staking ETH (input asset) on Lido results in conversion to stETH (output asset) holding which represents your stake plus rewards.

The handleAssets function of a Adaptor contract is called via delegatecall with all the required input tokens/assets already in balance. The implementation of the handleAssets is left to the developer of the integrating protocol, allowing full flexibility. The converted assets or outputs are then returned in the same function.

The developers are not required to have any specific knowledge about ZKPs. The core API of their protocol, which may be already deployed, remains the same. No change is required in the already deployed contracts. Only a standalone adaptor contract, acting as a logic layer of communication between Labyrinth and their protocol, needs to be written.

Refer example to see this in action and add a layer of compliant privacy to your protocol!

🔄
Integrating with DeFi protocols