7Block Labs
Decentralized Finance

ByAUJay

Developing Private “Dark Pool” DEXs using Fully Homomorphic Encryption (FHE)

In the realm of decentralized finance (DeFi), privacy is really starting to grab attention. A cool way to boost that privacy is by setting up private "dark pool" decentralized exchanges (DEXs) that take advantage of Fully Homomorphic Encryption (FHE). Let’s break down what this all means and how we can make it happen.

What Are Dark Pools?

Dark pools are like hidden trading spots where deals go down without anyone outside knowing the specifics. They're super useful for traders looking to handle large orders without making a splash in the market. Unlike the usual exchanges we’re all familiar with, dark pools focus on keeping things low-key, which is great for big-time investors who prefer to keep their game plan a secret.

Why Use FHE?

Fully Homomorphic Encryption makes it possible to perform calculations on encrypted data without needing to decrypt it first. This fantastic feature lets us work with information while keeping it secure and private. In the world of dark pool DEXs, FHE could play a significant role in preserving user privacy while still enabling trades to happen.

Benefits of FHE for DEXs:

  • Privacy: Your financial info, trades, and strategies are kept under wraps.
  • Security: If a hacker manages to break in, all they'd find is encrypted data.
  • Compliance: FHE helps tick off regulatory boxes by making sure your data stays private.

Building a Dark Pool DEX with FHE

Creating a dark pool DEX with FHE is a multi-step process that involves the following:

  1. Design the architecture: Figure out how the DEX will be set up, including the integration of FHE.
  2. Choose a blockchain: Select a blockchain that not only supports smart contracts but is also capable of handling FHE.
  3. Implement FHE: Work on developing the algorithms needed for processing data securely while it’s still encrypted.
  4. Create an interface: Build a user-friendly interface that lets traders easily navigate without worrying about the complexities of FHE behind the scenes.
  5. Test it out: Make sure to run thorough tests to confirm that everything functions as it should.

Challenges Ahead

While the concept of using FHE in dark pool DEXs sounds super promising, there are definitely some bumps in the road ahead. Here are a few challenges we might encounter:

  • Performance: FHE tends to be on the slower side, so it's super important to focus on optimizing its performance.
  • Complexity: The tech behind FHE isn’t exactly straightforward, which might make implementing it a bit of a challenge.
  • Adoption: Helping users warm up to new technology can require some time and a bit of education.

Conclusion

Building private dark pool DEXs using Fully Homomorphic Encryption (FHE) is an exciting idea that promises to boost privacy in the DeFi world. Sure, there are some challenges that we need to tackle, but the perks for users make it a really intriguing field to dive into. As we keep pushing the limits of technology, FHE could be a game-changer for the future of decentralized trading.

  • So, if you're looking to move sizes on-chain without setting off alarms in the mempool, here’s the scoop: ZK keeps your user states under wraps, but it doesn't really help when it comes to figuring out global prices. And those TEEs? They tend to create a single point of failure, which isn't ideal. On the flip side, MPC-only designs often hit a wall with throughput issues. Plus, we can't ignore L2s--they’ve made spam-based MEV way cheaper after Dencun, leading to latency races, reverts, and backruns that are really eating into block-size orders. (arxiv.org)
  • Since mid-2025, FHE has finally jumped over the “prototype” hurdle:

    • Zama’s public testnet has racked up over 1.2 million encrypted transactions and more than 19,000 confidential contracts. Their fhEVM Coprocessor is a game changer, letting any EVM chain handle encrypted computing effortlessly. And we can't overlook their Threshold KMS, which runs on 13 independent MPC nodes after a complete DKG ceremony. Check it out over at (zama.org).
    • Fhenix has made the leap from FHE rollups to a slick modular CoFHE coprocessor that can be accessed from Ethereum, Arbitrum, and Base. This move has seriously ramped up the performance and composability of encrypted execution. You can read more about it on (fhenix.io).
  • So, what's the scoop? We can now sync up encrypted limit/IOI flows, handle midpoint/auction clears, and only decrypt what's necessary for compliance--no more forking L1 or depending on just one enclave. (docs.zama.org)
  • Missed P&L: Open-intent venues really show how crucial private batching is. The CoW Protocol’s batch auctions do a great job of cutting down on frontrunning and ensuring users get a fair share of the surplus. Seriously, your block desk can't ignore slippage of 25-80 bps when there are sealed-bid and batch options out there. Take a look at cow-swap.com.
  • Execution integrity: With fast-finality L2s, it often feels like it’s a “first-spammed, first-served” game. We've noticed a surge of reverted arbitrage and a lot of congestion at the tops of blocks, which highlights some pretty wobbly fee-based ordering. That’s not exactly ideal, especially for institutional RFQ/TWAP. For a deeper dive, check out arxiv.org.
  • Regulatory timing:

    • The EU's DORA has officially kicked off as of January 17, 2025. This means we’re looking at some solid harmonization around ICT risk, oversight of third parties, and incident reporting. Just a quick reminder, vendor control evidence is set to be due from certain states starting this April. So, make sure your crypto operations are up to speed! You can find more details at eiopa.europa.eu.
    • The MiCA CASP frameworks started on December 30, 2024, and there’s a transitional “grandfathering” period that will wrap up by July 1, 2026, at the latest. If your plans for OTC or venue licenses fall behind schedule, you might be in a tough spot. For all the nitty-gritty, check out dotfile.com.
    • Over in the U.S., there’s some fresh SEC guidance that clears up how ATS and NSEs can offer both security and non-security crypto pairs, as long as they follow their requirements. If your firm is looking to trade tokenized securities privately, it’s time to get your Reg ATS/Form ATS-N and Reg SCI game plan ready. For more info, head over to sec.gov.
  • Program risk: We're seeing slippage from open books, some MEV leakage, and those annoying compliance redo cycles all stacking up into deadline risk--especially when budgets are really tight.

1) Market Structure Blueprint (What We Build)

  • Matching Model: We’re rolling with frequent batch auctions that feature encrypted orders (covering price, size, and side), plus an option for midpoint crossing if that's your jam.

    • Encrypted Pre-Trade: Picture this: all bids, asks, IOIs, and pegged orders are stored as TFHE ciphertexts. We use programmable bootstrapping LUTs to make comparisons, but only the batch-clearing price and the filled quantities get decrypted via a threshold policy. If you want to dig into the details, take a look here: docs.zama.org.
    • Fairness/MEV: To prevent those pesky gas-price races, we’ve implemented time-bucketed batches (like 250-1000 ms). Sealed bids keep things confidential until they're cleared. You can find out more about how Penumbra is integrating privacy and anti-front-run strategies into the EVM using FHE in our design notes on sealed-bid batch swaps right here: protocol.penumbra.zone.
  • Execution Venue: We’re excited to set up our execution venue on the EVM host chain. Think of it like an Ethereum L2--lower fees and better composability! We're also teaming it up with a network of FHE coprocessors, whether that’s the Zama fhEVM Coprocessor or Fhenix CoFHE.

    • Symbolic On-Chain Ops: These ops create references while the off-chain coprocessors take care of FHE tasks like adding, multiplying, comparing, and selecting. Once they’re done, they post commitments. For managing encryption, our KMS will handle threshold decryptions--whether they’re public or specific to a user. If you want to dive deeper, check out more details here: docs.zama.ai.
  • Decryption Policy: We're rolling with a threshold KMS that incorporates DKG and "N-of-M" shares. In the initial stages, we'll be using AWS Nitro Enclaves to ensure secure execution on our MPC nodes. Plus, we’re aiming for ZK-verifiable FHE evaluation in the future. To stay in the loop with our progress and insights, take a look at what we've been up to at zama.org.

2) Engineering Plan (How We're Going to Build It)

  • Circuit Design:

    • We're using euint64 to represent price and quantity. For our comparisons, we’ve set up a single programmable bootstrapping (PBS) for each one, relying on a lookup table (LUT). We’ve paired tfhe-fft with AVX-512 on the CPU, and for those really important paths, multithreaded PBS on the H100 is in play. When it comes to selection and branching, we’ve got an encrypted multiplexer handling that for us. If you want to dive deeper into the nitty-gritty, check out the Zama docs.
    • Our target for parameterization is a p_fail of (2^{-64}) specifically for price-time priority. For markets that demand tighter failure bounds, we’ll crank that up to (2^{-128}). More details can be found here.
  • Throughput Envelope You Can Model in a Spreadsheet:

    • The Zama fhEVM Coprocessor brings a reliable starting point with around 20 transactions per second (TPS) for each coprocessor. When we ramp up the hardware, we can soar to hundreds of TPS. Developers can easily code in Solidity using the euint types. For more info, check out the Zama site.
    • We’ve been keeping an eye on recent benchmarks for TFHE-rs GPU PBS on the H100, and they’re showing pretty solid latencies when we look at comparisons and KS-PBS under strong parameters. We tweak our worker pools based on these insights and shard order books by symbol. If you’re curious for more details, take a look at the documentation.
  • Key Management and Enclaves:

    • We’re in the process of establishing a threshold KMS with around 13 different parties. We usually go with a multiparty computation (MPC)-based distributed key generation (DKG). The cool part? We’ll securely store the shares in Nitro Enclaves, which come with KMS attestation conditions (RecipientAttestation keys). This means that a share can only be used within a verified enclave image. If you're curious to learn more, check out the details here.
  • The FIX/OMS Integration Your Traders are Looking For:

    • With our FIX 5.0 SP2 bridge, we’re ready to roll with D (NewOrderSingle), F (Cancel), and G (Cancel/Replace). We’ll make sure that all FIX tags go through some solid validation and normalization before getting encrypted on the client-side (SDK) right before submission. If you want to dive deeper into the specifics, take a look here.
  • DevX and Upgrade Path:

    • We're focusing on Solidity-first confidential contracts (swapping uint for euint) while using fhEVM libraries. We’re also making sure that our Rust microservices can easily work together with Concrete and TFHE-rs, and we’ll take advantage of GPUs where the PBS hotspots are. If you want to dive deeper into this, check out Zama's blog.

3) Security and Compliance by Design (Why Procurement Says Yes)

  • Data Minimization: We only decrypt what we absolutely need--like batch-clearing prices and per-fill receipts. Everything else? It stays encrypted, both when it’s sitting idle and while it’s being used. Our Key Management System (KMS) is designed to handle public and user-specific decrypt modes, all controlled by on-chain Access Control Lists (ACLs). For more info, take a look here.
  • DORA Mapping: We're on top of our game with ICT risk management! This means we’re keeping a solid inventory of assets like keys and coprocessors, putting in place incident reporting mechanisms, and managing vendors for both coprocessors and KMS operators. And don’t worry, enclave attestation is all laid out in our runbooks. You can dive deeper into it here.
  • U.S. Reg ATS Readiness: If any of our instruments are labeled as securities, we’re on top of aligning dark-pool activities with ATS controls. We prioritize protecting our subscribers' confidential info, making sure everyone has fair access, and keeping our technical setup strong and reliable. We're also checking out the SEC staff FAQs on mixed security and non-security pairs. If you want to dive deeper, you can find more details here.

4) Example: Encrypted Midpoint Cross (EVM + fhEVM types)

  • Flow:

    • It all starts with the Client SDK, which encrypts the order details--{side, limitPx, qty}--into an euint64. It also signs a zero-knowledge proof to make sure everything checks out (non-negative values and within the specified bounds).
    • Then, the contract adds the order to the current batch and sends out some symbolic “cmp/select” operations to the Coprocessor.
    • The Coprocessors spring into action next, using encrypted comparisons to identify the best crossing sets. The Key Management Service (KMS) takes care of a single public decryption to figure out the uniform clearing price, while user-specific decryptions provide the private fill details.
  • Pseudocode Sketch (just a quick example):

    euint64 pxMid = avg(bestBid, bestAsk); 
    ebool isFill = ( (side==BUY && limitPx>=pxMid) || (side==SELL && limitPx<=pxMid) );
    euint64 fillQty = select(isFill, min(qty, contraAvail), 0);
    • Once the settlement happens, only the clearing price and the fill quantity for each order are decrypted based on the policy.

5) Performance/Cost Planning (Feel free to share this with Finance)

  • Coprocessor Capacity Planning:

    • First up, we’re looking at 4× H100 workers. Our goal is to make sure these can handle multiple computations per batch for the top pairs. And remember, sharding symbols is key for that parallel processing! Try to keep those batch intervals between 250-1000 ms to hit the sweet spot between leakage and latency. You can check out more details here.
  • Fee Modeling from a Live FHE Protocol:

    • So, here’s the scoop on the Zama Protocol: their pricing is all about the bits you use. Both decryption and ZK-PoK are charged based on the number of bits, and they’ve even got some published ranges to guide you. For example, if you're working with a 64-bit amount and need three decrypts along with one proof, you’re looking at around ~$0.01-$1.3 per transaction these days. Plus, if you're diving into it with high volume, they offer some nice discounts for those busy venues. This bit of info could really help you plan your OPEX based on how many orders you expect. You can find all the details here.
  • Hardware Trajectory:

    • Great news! The GPU PBS on the H100 is now production-ready. On top of that, the research roadmaps--like heterogeneous FHE accelerators and near-memory designs--show that we have some breathing room to plan our budgets all the way into 2026. If you want more details, check it out here.

Best emerging practices we apply in 2026 builds

  • Keep comparisons inexpensive: When you're designing your matching logic, aim to minimize the PBS count. Try to stick to single-LUT comparisons and consider using encrypted mux beats rather than going the route of subtract-and-scan chains. Only reach for euint radix packing when it truly makes sense to save on PBS. (docs.zama.org)
  • Batch to kill MEV, not UX: Focus on those 250-1000 ms batches; they really strike a great balance. Sync up with the solver deadlines you've learned from batch-DEX practices and keep an eye on L2 timing too. (protocol.penumbra.zone)
  • Start Thresholding Early: Kick off your DKG before diving into UAT; this way, no single operator holds onto the entire key. And hey, remember to publish your attestation measurements and KMS key policies alongside your audit materials. Check it out here: (zama.org)
  • FIX-in, encrypted-out: Use FIX 5.0 SP2 (D/F/G) and convert it to encrypted intents on the client side. This way, you’ll avoid dealing with plaintext in your OMS->chain process. Check it out here: (fiximate.fixtrading.org)
  • Plan for verifiability: Utilize coprocessors that commit to their outputs and rely on a majority consensus. Also, stay tuned for developments in ZK‑FHE research, which could offer new ways to eliminate the need for trust in the majority by using proofs. (docs.zama.org)

GTM Metrics and Operating Targets You Can Count On

  • Technical SLAs (Phase 2 pilot, single venue, top 5 pairs):

    • Batch Cadence: We’re shooting for a target of 500 ms (P50), and we want the clearing price decryption to be under 120 ms (P95) using our 13-party KMS. For more details, take a look at zama.org.
    • Throughput: We’re aiming for at least 20 tx/s per coprocessor instance, and with a few extra H100 workers, we’re looking to ramp this up to about 200-400 tx/s. Check out the full scoop on zama.ai.
    • Confidentiality: The batch clearing price will be made public, but all per-fill receipts will be re-encrypted to the taker/maker keys for added security.
  • Execution Quality KPIs (compared to open-mempool baseline on the same pairs/time windows):

    • Our goal is to really cut down on observable pre-trade leakage events, wipe out sandwich and backrun signatures, and make sure surplus capture fits well with batch-auction venues. For more info, check out cow-swap.com.
  • Compliance Deliverables:

    • DORA Package: This bad boy includes an ICT asset register specifically for coprocessors/KMS, enclave attestations, incident runbooks, third-party risk due diligence, and a handy evidence binder for audits. If you want to dive deeper into this, check out eiopa.europa.eu.
    • U.S. ATS Readiness (if applicable): We’re putting some solid controls in place for confidential subscriber data, making sure everyone has fair access, and mapping tech resiliency to SCI. Plus, we've prepped a Staff FAQ for mixed pairs, so we’ve got you covered! Get more details at sec.gov.
  • Cost Model (for Procurement):

    • We’ll be using variable fees for each transaction, which will depend on Zama bit-pricing bands and the amortization of H100 clusters. Keep an eye out for a unit-economics worksheet coming your way in week 2 of Discovery. If you want to dive deeper, check out docs.zama.ai.

What 7Block Labs Offers (and How to Get Involved)

Architecture and Build:

  • Dark-pool matching with encrypted orderbooks on EVM chains is totally our jam! We pull this off with our awesome custom blockchain development services and blockchain integration teams. We’ve got Solidity down, featuring FHE types, batch-auction logic, and a super useful FIX bridge.
  • We also carry out security reviews for circuits and KMS flows as part of our security audit services. This means we get to validate those enclave/KMS policies and provide support for DKG ceremonies--pretty cool, right?
  • And don't forget, we’re all about cross-chain liquidity and encrypted settlement extensions, thanks to our rockstar cross-chain solutions and blockchain bridge development teams!

I’d love to team up and brainstorm how we can elevate your project!

  • Delivery plan (12-16 weeks to pilot):

    1. Weeks 1-2: We’ll kick things off with a workshop where we’ll dive into market structure and regulatory architecture. During this time, we'll nail down the KPIs and controls, map out the FIX dictionary, and sketch out the fee and capacity model.
    2. Weeks 3-6: Next on the agenda is creating a proof of concept for an encrypted order book on the testnet, featuring 2 symbols. We’ll also run a dry run for the KMS DKG and get the enclave attestation up and running.
    3. Weeks 7-10: In this phase, we’ll tackle batch auctions and midpoint crosses while fine-tuning performance on the PBS hotpaths (H100). Plus, we’ll conduct FIX-UAT with the OMS to make sure everything's running smoothly.
    4. Weeks 11-12: We’ll compile a compliance binder that covers DORA/ATS, whip up some runbooks, and run a red-team tabletop exercise to test our readiness. After that, we’ll make our go/no-go decision.
    5. Optional Weeks 13-16: If we’re feeling up for it, we can take things a step further by expanding our work to 10 symbols, bringing in liquidity providers, and looking into cross-chain encrypted settlement.
  • Target Audience (and the Keywords They Actually Use)

    • Heads of Digital Asset Trading / Market Structure at banks and broker-dealers: These pros are all about phrases like “midpoint crossing,” “sealed-bid batch auctions,” “Reg SCI readiness,” “Form ATS‑N,” “FIX 5.0 SP2 D/F/G,” “IOIs,” and “time‑weighted priority.”
    • Exchange/CASP Operators under EU Regimes: This group is on the hunt for terms like “DORA ICT asset register,” “MiCA CASP authorization,” “threshold KMS attestation,” and the “transitional period end July 1, 2026.” And let’s not forget “ACL‑governed decrypt”!
    • Quant/HFT Market Makers: They’re using lingo such as “encrypted orderflow,” “PBS budget per compare,” “GPU PBS on H100,” “LUT‑based cmp/mux,” and “batch interval tuning.”

Brief, in-depth details you can apply this quarter

  • Circuit checklist:

    • Don’t forget to stick with single-LUT comparisons when dealing with price and priority. It’s a good idea to set up bounded integer domains to minimize errors. For side data, encrypt it as bits and use select() for muxing to identify matches. And hey, make sure to compute pool-wise net flows under FHE, but only decrypt the batch clear. Check out the details here: (docs.zama.org)
  • Ops checklist:

    • Make sure to run KMS on Nitro Enclaves while adhering to the KMS RecipientAttestation conditions. Remember to rotate your enclave images every three months and include PCR/ImageSha384 in your due diligence pack. (docs.aws.amazon.com)
  • Reg checklist:

    • When it comes to the EU, make sure you pull together evidence for the ICT asset register, run some incident drills, and keep a close eye on your vendors. Don't forget to categorize KMS and coprocessor providers as “critical ICT third parties.” Over in the U.S., if you’re working with securities, get your ATS-N ready and establish some data confidentiality SOPs, along with a solid SCI change management plan. (eiopa.europa.eu)
  • Performance checklist:

    • Start your batches every 500 ms, make sure to shard your symbols, and don't forget to profile KS-PBS. Ramp up your H100 workers and double-check the cost envelope using Zama's per-bit pricing before you hit that go-live button. (docs.zama.org)

Hey! What's up?

If you’re the Head of Digital Asset Trading at a MiCA-compliant venue and you’re facing that CASP transition deadline coming up on July 1, 2026, we’ve got just what you need. If you're searching for a sealed-bid, midpoint-crossing DEX that supports FIX 5.0 SP2 and comes with a DORA-ready KMS attestation pack, drop us an email! We can set up a 45-minute architecture review for you this week.

We’ll be ready with a live PBS budget, a decryption-cost model that aligns perfectly with your symbol list, and a draft ATS/DORA evidence binder that you can hand over to Procurement on the spot. Want to know more? Check it out here: (fintecharbor.com). Can’t wait to chat!

References (selected)

  • Take a look at the Zama fhEVM Coprocessor! We've got some performance insights, stats from the protocol testnet, and all the documentation for TKMS/KMS. Plus, don’t miss out on the results from the DKG ceremony. (zama.ai)
  • Check out the Fhenix CoFHE Coprocessor architecture update from August 2025! It covers some really cool advancements. You can read more about it here: (fhenix.io)
  • For those on the hunt for benchmarks, the TFHE‑rs PBS CPU/GPU benchmarks dive into parameter options and offer solid performance insights for the H100. Check it out here: (docs.zama.org)
  • If you're looking for some design inspiration, take a peek at the Penumbra sealed‑bid/batch design for private swaps. You'll find some pretty neat ideas! (protocol.penumbra.zone)
  • Check out the intriguing insights on the MEV/latency race after Dencun, plus some cool stats on batch-auction MEV protection. It's definitely worth your time! (arxiv.org)
  • Keep an eye on the DORA application kicking off on January 17, 2025, and don’t forget to check the regulator guidance and MiCA deadlines, which run through July 1, 2026. (eiopa.europa.eu)
  • Lastly, the SEC staff FAQ about crypto pairs for ATS/NSE and the references for Reg ATS/SCI are super helpful. Make sure to take a look! (sec.gov)

Money-phrases to remember

  • “Encrypted order flow, only decrypted during the batch clear.”
  • “PBS-per-compare budget you can calculate before going live.”
  • “DORA-ready KMS featuring attested enclaves and N-of-M decryption.”

Like what you're reading? Let's build together.

Get a free 30-minute consultation with our engineering team.

Related Posts

Decentralized Finance

ByAUJay

Creating a Yield Aggregator for RWA Tokens: A Step-by-Step Guide

### Summary So, you’re looking to create a serious RWA yield aggregator in 2026? Well, things have definitely stepped up a notch technically! You'll need to manage a few crucial elements like ERC‑4626/7540 vault flows, permissioned token standards (ERC‑3643/1404), NAV and reserve oracles, and cross‑chain DvP. It’s going to be a challenging but exciting ride!

Decentralized Finance

ByAUJay

Building 'Policy-Based' DeFi Wallets for Corporate Treasuries When it comes to managing corporate funds, efficiency and security are top priorities. That's where 'policy-based' DeFi wallets come in. These wallets not only allow businesses to tap into decentralized finance but also ensure there's a robust framework in place to manage their assets according to specific guidelines. What exactly do we mean by 'policy-based'? Well, it's all about tailoring the wallet's functionality to fit the unique needs of a company's treasury operations. With these kinds of wallets, companies can set rules and policies that dictate how funds are accessed, spent, and invested. So, if you're worried about security or compliance, these wallets can be a big help. These wallets can be designed to handle everything from regular transactions to more complex financial maneuvers, like yield farming or liquidity provision. Plus, the ability to automate certain processes means that businesses can save time and reduce the risk of human error. In a nutshell, 'policy-based' DeFi wallets are game-changers for corporate treasuries. They provide a smart, efficient way to manage crypto assets while keeping everything in check with rules that align with the company's financial strategy. It's a win-win!

**Summary:** Hey there! Corporate treasuries now have a great opportunity to explore the world of DeFi with some robust controls. Thanks to EIP-7702 smart accounts, along with policy modules like ERC-7579 and ERC-6900, they can ensure everything runs smoothly. Plus, with features like MPC signing, on-chain sanctions checks, and Travel Rule workflows, security is top-notch. This guide is here to take you through how 7Bl can help make it all happen!

Decentralized Finance

ByAUJay

The 'Dual-Market' DeFi Setup: Merging Speed with Flexibility

**Summary:** A lot of DeFi stacks make you choose between super-fast execution and a whole bunch of features. But with a Dual‑Market architecture, you don’t have to pick one over the other anymore! It combines a low-latency “Fast Market” for quick trades with an intent-driven “Flexible Market” that offers versatility, bringing them together in a seamless way.

7BlockLabs

Full-stack blockchain product studio: DeFi, dApps, audits, integrations.

7Block Labs is a trading name of JAYANTH TECHNOLOGIES LIMITED.

Registered in England and Wales (Company No. 16589283).

Registered Office address: Office 13536, 182-184 High Street North, East Ham, London, E6 2JA.

© 2026 7BlockLabs. All rights reserved.