As part of the build week of Threshold Cryptography Bootcamp, I and Leny collaborated to build an optimal solution for one of the most defining issues in the blockchain ecosystem via ᴄᴏᴍʙɪɴɪɴɢ ᴛʜᴇ ᴄʀʏᴘᴛᴏɢʀᴀᴘʜɪᴄ ᴘᴏᴡᴇʀs ᴏғ ʙʟᴏᴄᴋʟᴏᴄᴋ-ᴇɴᴄʀʏᴘᴛɪᴏɴ ᴀɴᴅ ᴠᴇʀɪғɪᴀʙʟᴇ ʀᴀɴᴅᴏᴍɴᴇss—ᴘʀᴇsᴇɴᴛɪɴɢ ʏᴏᴜ: GHOSTLOCK: MEV REAPER.

Lets have a walk through of what we built, why we built it, and how the pieces tie together — from the front-end UX to the Solidity contracts and the off-chain services that glue everything into a working privacy-preserving batch settlement system.

Why this matters?

MEV(maximal extractable value) is a systemic problem that leaks value from ordinary traders into searchers and miners/validators. The web3 community has responded with many partial mitigations; hence, we came up with GhostLock that aims to combine time-locked encryption (to hide intents), verifiable randomness (to avoid biased sequencing), and batch auctions (to remove discriminatory pricing) into a single coherent architecture.

Architecture overview:

Frontend: React + TypeScript
Backend: Node.js + Express, using ethers.js to interact with the contracts.
Smart contracts: GhostLockIntents (handles encrypted intents and the Blocklock callback), BatchSettlement (handles uniform-price batch auctions), EpochRNG (verifiable randomness provider).

High-level flow (user to settlement)

User constructs a trading intent in the frontend (side, amount, limitPrice, marketId, decryptionTime).
The intent is encrypted off-chain using Blocklock (time-lock encryption with a block-based unlock condition).
The ciphertext is submitted on-chain to our GhostLockIntents contract and stored as a CipherIntent record.
When the block-lock condition is reached, the Blocklock network / threshold signer calls back into GhostLockIntents with a decryption key.
The contract verifies unlock conditions, decrypts (in PoC) or signals that the intent is ready, and the intent becomes available for the batch settlement.
The Auction BatchSettlement process (off-chain coordinator + on-chain settlement contract) collects ready intents, orders them using verifiable randomness from EpochRNG, then runs a uniform-price batch auction and executes settled trades.

Understanding Artifacts and Smart Contracts

Deployed contract addresses on BaseSepolia:
- GHOSTLOCK_INTENTS_ADDRESS
  - BATCH_SETTLEMENT_ADDRESS
  - EPOCH_RNG_ADDRESS

GhostLockIntents.sol

- This contract inherits AbstractBlocklockReceiver from the Blocklock Solidity library. The contract stores "CipherIntent" objects:
  
  * CipherIntent struct contains requestedBy, encryptedAt (timestamp), unlockBlock, a TypesLib.Ciphertext ct, a ready flag, and an optional decrypted bytes field for PoC.
  - The on-blocklock callback is implemented as:
    - function _onBlocklockReceived(uint256 requestId, bytes calldata decryptionKey) internal override { ... }
    - It checks that the request exists, verifies block.number >= unlockBlock, and then calls _decrypt(it.ct, decryptionKey) to obtain plaintext.
    - For the proof-of-concept, the contract stores the cleartext bytes and sets ready = true, then emits IntentReady(requestId).
  - Important note in the contract: decrypting on-chain and storing plaintext is only for the PoC. In production, we would emit a decryption key event and let off-chain indexing/settlement services parse sensitive payloads (minimizing on-chain plaintext exposure).
  - Why this is important: by wiring the Blocklock callback directly into the contract, we create a deterministic, auditable point at which an encrypted intent becomes available for settlement — and the unlockBlock condition enforces a minimum privacy window.

blocklock-service.ts

- This module provides the BlocklockService class that does the heavy lifting for encryption.
  - encryptIntent(payload, unlockBlock) builds the ABI-encoded payload using ethers utilities (parseUnits for amount & price using the token decimals) and then calls blocklock.encrypt(ethers.getBytes(encodedPayload), BigInt(unlockBlock)).
  - The code shows the encoding flow (we create a tuple of fields, ABI-encode it, then encrypt). In practice, that means the client produces a TypesLib.Ciphertext-like structure that can be passed to the Intents contract for storage.

Core design choices and tradeoffs

Time-based conditional encryption via the Blocklock Encryption

- Benefit: Mempool searchers and frontrunners cannot read encrypted intents prior to the unlock event, removing a major attack vector for sandwiching and frontrunning.
  - Implementation detail: In the PoC, we both store ciphertext on-chain and allow the Blocklock network to call back a decryption key. The contract then either persists plaintext (PoC) or emits the key for off-chain actors (production).
  - Tradeoff: If you decrypt on-chain you increase transparency (auditable) but risk exposing sensitive data on-chain; off-chain decryption preserves privacy but requires a trustworthy off-chain processor or carefully designed key emission.(🙂)

Verifiable randomness for ordering (EpochRNG)

- Purpose: eliminate biased or replayed ordering by introducing unbiased randomness into the sequencing.
  - In practice: the Auction BatchSettlement process uses a VRF-derived random seed to shuffle or sort ready intents deterministically in a way that can be independently verified.

Batch uniform-price auctions

- Purpose: a single clearing price metric reduces incentives for value-extracting ordering and makes arbitrary sandwiching unprofitable.
  - Implementation: BatchSettlement contract aggregates intents for an epoch, computes clearing price and settles all trades at that price. This approach is a proven MEV mitigation technique because it removes per-transaction priority value.

Path Ahead: Operational and security considerations

Liveness: the plan ahead is strengthening our platform via bonds/slashing and fallback revealers — we need these to ensure a permission-less system can't be bricked by missing threshold signatures.
Metadata leakage: even ciphertexts leak metadata (size, timing). The roadmap ahead is padding, dummy intents and batch-only publication to reduce leakage — these are important next steps.
Audits & testing: Foundry fuzzing, audits, and invariant checks — a must before production use.

Practical MEV context (high level and conservative): MEV extraction has been a multi-hundred-million-dollar problem across multiple chains historically; mitigation strategies that remove ordering advantage (uniform price, encryption + delayed release, VRF ordering) meaningfully reduce the exploitable surface.

GhostLock's design combines those widely-discussed mitigations into a single pipeline.

TL;DR ;))

This project is a clear PoC that intentionally demonstrates the pattern:
encrypt off-chain with time-lock conditions,
store ciphertext on-chain,
and use a trusted threshold signer / Blocklock network to release decryption when the window arrives.

With a committed deadline, purpose and aim, we were able to combine a few powerful ideas into GhostLock: blocklock time-locked encryption to hide intents, verifiable randomness for unbiased ordering, and batch uniform-price settlement to remove per-transaction priority value. With our roadmap ahead, we will be endeavoring to achieve them for a utility-driven solution.

GhostLock neatly demonstrates how cryptography and protocol design can materially improve trader protections in decentralized systems.

Happy Building :))😊

https://docs.dcipher.network/quickstart/blocklock/

https://github.com/randa-mu/blocklock-solidity

https://drand.love/

https://github.com/randa-mu/randomness-solidity