Docs — Middn

01 ↘

Introduction & motivation

This document specifies Middn, a peer-to-peer trading protocol designed around four invariants: non-custody, privacy by default, atomic settlement, and verifiable correctness. We describe its architecture, smart contracts, zero-knowledge proof system, marketplace layer, and threat model.

The problem

Modern crypto trading splits between two unsatisfying poles. Centralized exchanges offer good UX but require users to surrender custody and disclose KYC data to a single party. History (Mt. Gox, FTX, Celsius, Voyager) shows this trust assumption is structurally unsafe. Decentralized exchanges preserve self-custody but only solve the on-chain part of the trade — anything involving off-chain conditions, fiat ramps, NFT-for-token swaps with conditions, or bilateral OTC deals between two specific parties remains unsupported. Existing P2P escrow solutions either reintroduce a custodial intermediary or expose all trade details on-chain.

What Middn does

Middn enables two parties to:

Discover counterparties through a privacy-preserving marketplace without revealing trade size or terms
Negotiate a deal with arbitrary conditions (price, asset, off-chain proof, timeout)
Lock assets in a non-custodial escrow contract with cryptographic conditions
Verify conditions via zero-knowledge proofs without disclosing the underlying data
Settle atomically — both legs of the trade clear in the same transaction, or neither does

Design principles

Four hard constraints govern every protocol decision:

i.Non-custody is absolute. No Middn-controlled key can move user funds at any point. Contracts have no admin functions over balances.
ii.Privacy is default. All trade metadata is encrypted client-side; ZK proofs verify conditions without revealing them.
iii.Atomicity is required. Partial states are impossible. A trade either clears entirely or refunds entirely.
iv.Verifiability is public. All contract code, circuits, and audit reports are open-source and reproducible.

Document structure

Chapter 2 describes the high-level architecture and trade lifecycle. Chapter 3 specifies the marketplace layer used for counterparty discovery. Chapters 4–7 cover the cryptographic primitives: smart contracts, zero-knowledge circuits, end-to-end encryption, and the non-custodial design. Chapter 8 details multi-chain support. Chapters 9–10 enumerate the threat model and current audit results. Chapter 11 outlines the roadmap and references.

Status & versioning

This document specifies Middn v0.1.4, currently deployed on Ethereum, Base, Arbitrum, Optimism, Polygon, and Solana. All numerical results (gas costs, proof sizes, throughput) reflect measurements from this version.

02 ↘

Architecture overview

Middn is a P2P trading protocol built on three pillars: smart contracts that hold the funds, zero-knowledge proofs that verify conditions privately, and an AI agent that guides users through the flow. Every component is non-custodial and verifiable on-chain.

The flow at 10,000 feet

A Middn trade goes through 4 phases — each enforced by code, not by a backend service. There is no Middn server holding state in between.

→ how a trade flows

↳ what makes it different

Unlike a CEX, Middn has no order book, no matching engine, no custody layer. It's a protocol, not an exchange — closer to how Uniswap relates to Coinbase.

03 ↘

The marketplace

The marketplace is Middn's counterparty discovery layer. It lets users post and find trade opportunities without revealing trade-identifying information until both parties commit. Discovery is privacy-preserving by design — listings disclose only the minimum required for matching.

What the marketplace is

A persistent, queryable feed of open trade intents. Each listing is published by a wallet that has staked a small refundable bond, and contains four public fields plus an encrypted blob:

Asset class (ERC-20, ERC-721, ERC-1155, native, or a custom asset tag)
Direction (offering or seeking)
Size bucket — coarsened to one of 7 ranges to prevent fingerprinting
Region tag (optional, used for fiat off-ramp deals)
Encrypted detail blob — full terms accessible only after handshake

Sensitive parameters — exact price, exact size, off-chain conditions, contact channel — never appear in cleartext on-chain. They are encrypted with a fresh ephemeral key included in the listing.

Listing lifecycle

A listing moves through five states:

State	Description	Funds locked?
`POSTED`	Listing visible. Maker has staked bond.	Bond only
`HANDSHAKE`	A taker requested terms. Maker has revealed full blob to one party.	Bond only
`COMMITTED`	Both parties signed an escrow contract instance.	Full deal locked
`SETTLED`	Atomic settlement executed.	Released to both
`EXPIRED`	Timeout passed without commit. Bond returned.	None

Anti-spam: the maker bond

To post a listing, a maker locks 0.05% of the declared size bucket midpoint in a refundable bond. The bond is returned automatically when the listing reaches SETTLED or EXPIRED. If a maker abandons a HANDSHAKE state (refuses to commit after revealing terms), the bond is slashed to the taker as compensation for wasted effort. This makes ghosting expensive.

Reputation without identity

Each wallet accumulates a per-asset-class reputation score based on past settlements. Reputation is stored on-chain as a counter of successful settlements and a counter of slashed bonds — nothing else is tracked. There is no identity, no KYC, no global wallet score. A wallet active in stablecoin OTC is independent from the same wallet's NFT history.

Reputation surfaces to counterparties only after handshake, never on the public listing. This prevents discrimination based on wallet history during discovery while still rewarding good actors during negotiation.

Matching: who finds whom

Matching is client-side. The full set of POSTED listings is queryable through Middn's open subgraph. Wallets filter locally on asset, direction, size bucket, and region. Once a candidate is found, the taker initiates a HANDSHAKE by sending an encrypted reveal request to the maker. No central matching engine exists; the protocol exposes only the data needed to match, and clients decide.

Privacy properties

The marketplace preserves three privacy properties:

Pre-handshake unlinkability. Listings disclose only public fields; the exact terms, identity, and chain history of the maker stay encrypted.
Selective reveal. The maker reveals full terms to one specific taker per handshake. Other observers see only that a handshake occurred, not its content.
Post-settlement minimal disclosure. Once settled, only the asset transfer is visible on-chain. The pre-trade conditions, price, and handshake content remain encrypted forever.

Fee structure

The protocol charges a flat 0.15% fee on settled trade value, split between maker and taker. Fees accumulate in a public treasury contract governed by the same non-custody constraints as escrow — no admin can withdraw to an external address. Treasury usage (audits, bounties, infra) is voted via on-chain governance with token-less voting weighted by lifetime settlement volume.

End-to-end deal flow

The complete flow from listing post to settlement, with the chapters that detail each step:

Step	Action	Where it happens	Reference
1	Maker posts listing, stakes 0.05% bond.	On-chain (marketplace contract)	This chapter
2	Taker filters listings client-side, finds match.	Off-chain (client + subgraph)	§ Matching
3	Taker initiates HANDSHAKE.	Encrypted P2P channel	Ch. 06
4	Maker reveals exact terms (encrypted blob).	Encrypted P2P channel	Ch. 06
5	Taker accepts; both compute CREATE2 escrow address.	Client-side	Ch. 04
6	EscrowFactory.create() called; instance deployed.	On-chain	Ch. 04
7	Both legs deposited to instance.	On-chain	Ch. 04
8	Party with off-chain condition fulfilled generates ZK proof client-side.	Local prover (~1.4s)	Ch. 05
9	Proof submitted to settle(); both legs transfer atomically.	On-chain	Ch. 04
10	Bond released, reputation counters incremented, fee routed to treasury.	On-chain	This chapter

Total wall-clock time for a simple stablecoin OTC trade on Base: typically under 90 seconds end to end, with on-chain finality dominating. Cross-chain trades (Ch. 08) add the asymmetric deadline window.

Marketplace contract surface

The marketplace itself is implemented as a small set of contracts independent from the escrow:

ListingRegistry — receives postListing(asset, direction, sizeBucket, regionTag, encryptedBlobHash) calls with the bond attached. Emits Listed event consumable by the subgraph.
BondVault — holds maker bonds. Releases on SETTLED/EXPIRED, slashes to taker on handshakeAbandoned() (callable by the taker with a signed timeout claim).
ReputationTracker — append-only counter, one per (wallet, asset-class) pair. No score formula — clients interpret the raw counts however they wish.
Treasury — receives the 0.15% fee. Can only disburse via a governance proposal that has reached quorum on settled-volume voting.

All four contracts are deployed once per chain, are immutable, and share the same audit and bug-bounty surface as the escrow.

04 ↘

Smart contracts

The core of Middn is a set of atomic swap contracts built on HTLC (Hash Time-Locked Contract) primitives. Each trade deploys a new escrow instance through a singleton factory pattern, returning a deterministic CREATE2 address. Once deployed, the instance is immutable — neither the Middn team nor anyone else can modify, pause, or invoke a privileged action on it.

Factory + instance pattern

Middn uses a two-layer architecture:

EscrowFactory — a singleton, deployed once per chain. Holds no funds. Its only responsibility is to deploy fresh MiddnEscrow instances via CREATE2 and emit an indexable event for subgraph discovery.
MiddnEscrow (instance) — a fresh contract per trade. Holds the deposited funds. Contains only the logic to release on a valid proof or refund after timeout. Has no admin, no proxy, no fallback function.

Deploying a new instance per trade isolates blast radius: a bug in a deployed instance cannot drain other trades. The factory's bytecode is verified against the published source on Etherscan; instances inherit the factory's deployed code identically.

The escrow contract

A simplified version of the core escrow logic (Solidity):

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

contract MiddnEscrow {
    address public immutable buyer;
    address public immutable seller;
    address public immutable tokenA;     // what buyer locked
    address public immutable tokenB;     // what seller locked
    uint256 public immutable amountA;
    uint256 public immutable amountB;
    bytes32 public immutable conditionHash;
    uint64  public immutable deadline;

    bool public settled;
    bool public refunded;

    function settle(bytes calldata zkProof) external {
        require(!settled && !refunded, "finalized");
        require(block.timestamp <= deadline, "expired");
        require(Verifier.verify(zkProof, conditionHash), "invalid proof");

        settled = true;
        // atomic — both legs release in the same tx
        IERC20(tokenA).transfer(seller, amountA);
        IERC20(tokenB).transfer(buyer,  amountB);
        emit Settled(buyer, seller, amountA, amountB);
    }

    function refund() external {
        require(!settled && !refunded, "finalized");
        require(block.timestamp > deadline, "too early");

        refunded = true;
        IERC20(tokenA).transfer(buyer,  amountA);
        IERC20(tokenB).transfer(seller, amountB);
        emit Refunded(buyer, seller);
    }
}

State machine

Every escrow instance moves through one of four terminal states, irreversibly:

State	Trigger	Outcome
`DEPLOYED`	Factory.create()	Awaiting both deposits.
`FUNDED`	Both tokens locked	Awaiting proof or deadline.
`SETTLED`	Valid ZK proof submitted before deadline	Both legs transfer atomically.
`REFUNDED`	Deadline passed without proof	Both deposits returned to original owners.

The contract has no other transitions. There is no admin pause, no migration, no manual override. Once SETTLED or REFUNDED is set, the instance is inert; any further call reverts.

Atomicity guarantee

The atomicity of settle() is enforced by the EVM itself: both transfer calls happen within the same transaction. If either reverts (e.g., token contract failure, insufficient balance — which should be impossible if FUNDED is correctly enforced), the entire transaction reverts and the contract state is unchanged. There is no partial-settlement state.

For cross-chain trades, atomicity is achieved via conditional HTLC chaining: each chain's instance has a hashlock derived from a common preimage, and the first reveal on chain A unlocks chain B within a bounded delay. See Chapter 08 for the full protocol.

Gas profile

Operation	Mainnet gas	L2 gas (Base)
Factory.create()	~148k	~52k
deposit (per leg)	~62k	~21k
settle() with ZK proof	~310k	~104k
refund()	~74k	~26k

The settle() cost is dominated by proof verification (~280k of the 310k). Meta-transaction support in v0.2 will route gas through a paymaster, allowing wallets to settle without holding native gas tokens.

Key properties

Immutable — no admin keys, no proxy, no upgrade path. The deployed bytecode is the entire trust surface.
Atomic — settlement is all-or-nothing within a single EVM transaction.
Refundable — if the deadline passes without a valid proof, both sides recover their deposits unconditionally.
Self-contained — no oracle dependency for settlement; the ZK proof is the sole authority.
Indexable — Settled and Refunded events are emitted with deterministic schemas for subgraph consumption.

05 ↘

Zero-knowledge proofs

Middn uses Groth16 zk-SNARKs to let users prove trade conditions are valid without revealing the underlying data. Amounts, identities, balances, conditions — everything stays private. The chain only sees a 192-byte proof.

→ zk verification flow

Circuits we use

Middn ships three production circuits, each with a publicly verifiable trusted setup transcript:

conditionCheck — proves all declared trade conditions are satisfied (price within range, asset-class match, signature validity, deadline not yet expired) without revealing the underlying values.
balanceProof — proves a wallet holds at least minAmount of a given asset at a recent block, without exposing the exact balance. Uses Merkle inclusion against a state root.
complianceProof — optional. Proves jurisdictional eligibility (e.g., "issued by a recognized KYC provider") without revealing identity documents or the provider's response payload.

conditionCheck — circuit sketch

The conditionCheck circuit (in circom pseudocode) takes private inputs and emits a single public commitment:

// conditionCheck.circom — simplified
template ConditionCheck() {
    // PRIVATE: full trade parameters known only to the parties
    signal input price;
    signal input amount;
    signal input nonce;
    signal input partySignature[2];
    signal input deadline;

    // PUBLIC: commitment hash that the contract checks
    signal input conditionHash;

    // 1. price within negotiated bounds (private bounds)
    signal input minPrice;
    signal input maxPrice;
    component priceCheck = InRange(64);
    priceCheck.in <== price;
    priceCheck.lo <== minPrice;
    priceCheck.hi <== maxPrice;

    // 2. signature valid from each party over (price, amount, nonce)
    component sigA = EdDSAVerifier();
    sigA.msg <== Poseidon([price, amount, nonce]);
    sigA.sig <== partySignature[0];

    // 3. deadline still in the future at proof time
    signal input currentBlockTime;
    component timeCheck = LessThan(64);
    timeCheck.a <== currentBlockTime;
    timeCheck.b <== deadline;
    timeCheck.out === 1;

    // 4. recompute the commitment and bind it as public output
    component poseidon = Poseidon(5);
    poseidon.inputs[0] <== price;
    poseidon.inputs[1] <== amount;
    poseidon.inputs[2] <== nonce;
    poseidon.inputs[3] <== partySignature[0];
    poseidon.inputs[4] <== deadline;
    poseidon.out === conditionHash;
}

The contract only ever sees conditionHash (public) and the 192-byte Groth16 proof. The actual price, amount, signatures, and bounds remain in the prover's local memory.

Performance benchmarks

Circuit	Constraints	Proving time	Verifying gas
conditionCheck	~28k	~1.4s on M1 laptop	~282k
balanceProof	~12k (depth 32 Merkle)	~0.8s	~282k
complianceProof	~9k	~0.6s	~282k

All proving happens client-side in WebAssembly. We provide a Node.js prover for headless environments. Verifying gas is constant for Groth16 regardless of circuit size; the 282k figure includes the pairing precompile call and dispatch overhead.

Trusted setup

Each circuit underwent a two-phase Powers of Tau ceremony:

Phase 1: 28-million-constraint universal setup, contributed to by 142 participants across 19 organizations (Apr 2025–Aug 2025). Final transcript hash and contribution log are published on IPFS.
Phase 2: circuit-specific contribution. 89 participants for conditionCheck, 64 for balanceProof, 51 for complianceProof.

The security assumption is honest-majority of at least one participant in each ceremony — i.e., if any one contributor discarded their toxic waste, the setup is sound. Transcripts are independently auditable.

↳ why Groth16

We chose Groth16 over PLONK/Halo2 for verification cost (~282k gas vs ~600k+) and proof size (192 bytes constant vs ~1KB+). The price is a per-circuit trusted setup — acceptable given our circuits change infrequently and the setup is transparent and reproducible.

06 ↘

End-to-end encryption

Trade invitations, marketplace blob contents, counterparty messages, and off-chain settlement metadata are all encrypted client-side. Middn's backend never sees plaintext. Even if our servers were compromised, attackers would only find ciphertext bound to keys held exclusively by the two parties.

The cryptography stack

Component	Algorithm	Purpose
symmetric	AES-256-GCM	Payload encryption + authentication
key exchange	X25519 ECDH	Per-deal shared secret derivation
signing	Ed25519	Message authentication, deal commitments
kdf	HKDF-SHA256	Key separation, channel binding
hashing (off-circuit)	BLAKE3	Content addressing, integrity
hashing (in-circuit)	Poseidon	ZK-friendly commitments

Handshake protocol

When a taker discovers a marketplace listing and wants the full terms, the two clients run a three-message handshake to establish a per-deal encrypted channel:

// Handshake — taker T initiates with maker M's listing

// 1. T → M: HANDSHAKE_REQUEST
{
  listingId:    bytes32,
  takerPubKey:  X25519 public key (ephemeral, fresh per request),
  takerSig:     Ed25519 sign(BLAKE3(listingId || takerPubKey)),
  takerWalletAddr: address
}

// 2. M → T: HANDSHAKE_RESPONSE
{
  listingId:    bytes32,
  makerPubKey:  X25519 public key (ephemeral, fresh per request),
  encryptedBlob: AES-256-GCM(
                   key  = HKDF(X25519(makerPriv, takerPub), "middn-v1-blob"),
                   data = { exactPrice, exactAmount, settlementWindow, contactChannel, ... }
                 ),
  makerSig:     Ed25519 sign(BLAKE3(listingId || makerPubKey || encryptedBlob))
}

// 3. T → M (only if T accepts the terms): COMMIT
{
  listingId:    bytes32,
  escrowAddr:   address (CREATE2-derived from terms),
  takerSig:     Ed25519 sign(BLAKE3(listingId || escrowAddr || acceptedTermsHash))
}

Critical properties:

Per-deal ephemeral keys. X25519 key pairs are generated fresh at every handshake. They are never reused across deals, and they are discarded once the deal is settled or refunded.
Forward secrecy. If a wallet's long-term key is later compromised, the attacker still cannot decrypt past handshakes — the ephemeral keys are gone.
Channel binding. HKDF derives the AES key with a domain-separator string ("middn-v1-blob") so blob keys, signing keys, and other derived material cannot be confused.
No metadata leak to Middn. The encrypted blob is broadcast through a public relay (or directly via libp2p), but it is opaque to anything except the holder of takerPriv.

Key lifecycle

Each user holds two long-term key pairs derived from their wallet seed (via BIP-32-style hardened derivation):

An Ed25519 identity key used to sign handshake messages and deal commitments. Stable across deals.
An X25519 announce key published on-chain (or via a public registry) so counterparties can initiate a handshake. Rotated voluntarily.

Per-deal ephemeral X25519 keys are derived deterministically from (walletSeed, dealNonce) so they can be regenerated for proof verification but are stateless to the user.

Settlement metadata

For trades involving an off-chain delivery (e.g., fiat ramp via bank transfer), the settlement metadata — bank reference numbers, IBAN hashes, transfer timestamps — is exchanged through the same encrypted channel and committed inside the ZK proof. The on-chain proof attests "a signed bank statement matching the agreed reference was presented" without exposing the reference itself.

07 ↘

Non-custodial by design

The most important property of Middn is what we don't do: we never hold user funds. Not for a millisecond. Not in a hot wallet. Not in cold storage. Never.

How it's enforced

No admin functions on contracts. No "pause" button, no "rescue" function, no upgrade proxy.
No multi-sig holding fees — protocol fees are routed to a separate immutable contract.
No backend custody — our servers never receive private keys or signed transactions.
Verifiable on-chain — every escrow address is publicly visible. You can watch your own.

↳ self-verifiable

Don't trust us — verify. Every contract address and source code is published on Etherscan with matching bytecode hashes. Run our circuits locally and you'll get the same proofs.

08 ↘

Multi-chain deployment

Middn contracts are deployed on EVM-compatible chains and Solana. The escrow logic is bytecode-identical across EVM deployments — only the verifier precompile address differs on chains without standard pairing support. Cross-chain trades are supported via atomic HTLC bridging — funds never leave the source chain prematurely and never depend on an external bridge custodian.

Supported chains

Ethereum

Base

Arbitrum

Optimism

Polygon

Solana

Additional chains are added based on community demand and verifiable security. New deployments go through the same audit pipeline and re-verification of the proof system on the target chain's precompile or equivalent.

Same-chain trade lifecycle

For two parties on the same chain:

Discovery — taker finds maker's listing in the marketplace, completes the handshake (Ch. 6), receives full terms.
Factory.create() — taker calls the EscrowFactory with the agreed parameters, deploying a fresh instance.
Deposits — both parties send their token leg to the instance address. Order is irrelevant; the contract enforces both must arrive.
Proof submission — either party (typically the one with the off-chain condition fulfilled) submits the ZK proof to settle().
Atomic settlement — both legs transfer in the same transaction.

Cross-chain trade lifecycle (HTLC bridging)

For trades where token A is on chain X and token B is on chain Y, Middn uses a hashlock-coupled escrow pair:

The buyer chooses a secret s and computes H = SHA-256(s).
An escrow instance is deployed on chain X locking token A. It releases to the seller upon presentation of any s' such that SHA-256(s') == H. Deadline: t + Δ.
An escrow instance is deployed on chain Y locking token B. It releases to the buyer upon presentation of the same s. Deadline: t. (Note: shorter deadline on Y by Δ to prevent free-option attacks.)
The buyer reveals s on chain Y to claim token B. The transaction broadcasts s publicly.
The seller observes s on chain Y, then submits it on chain X to claim token A.
If the buyer never reveals s by deadline t, both instances refund.

The asymmetric deadlines (Δ typically 30 minutes) protect the seller: the buyer must claim on chain Y first, exposing s early enough for the seller to claim on chain X before chain X's deadline elapses. This is the standard atomic-swap construction with no trusted intermediary.

Chain-specific notes

Ethereum mainnet. Reference deployment. Highest cost, highest security. Used for high-value OTC and NFT trades.
L2s (Base, Arbitrum, Optimism). Same contract bytecode. ~3x cheaper settlement. Sequencer trust assumption applies, but escrow funds remain non-custodial regardless of sequencer behavior.
Polygon. Same bytecode, faster finality. Bridging back to mainnet for high-value trades is the user's choice.
Solana. The Solana program is functionally equivalent but written in Rust against the SVM. Cross-chain trades with EVM use the same HTLC hashlock construction (SHA-256 is supported on both sides).

Subgraph + indexing

Each chain has a dedicated subgraph (TheGraph for EVM, custom indexer for Solana) that exposes the marketplace listings and settlement history. Subgraphs are open-source, self-hostable, and verifiable against on-chain events. Middn runs reference indexers as a public good, but the protocol does not depend on them — clients can index from a local node directly.

09 ↘

Threat model

This chapter enumerates the attack surfaces we consider in-scope and the assumptions we explicitly do not protect against. A protocol is only as safe as the precision of its threat model.

What we defend against

Middn's design hardens the following adversarial scenarios:

Threat	Mitigation
Smart contract exploit	Two external audits, formal verification on critical paths, fuzzing & symbolic execution, $250k bounty.
Counterparty defaults mid-deal	Atomic settlement — funds release together or refund. No partial state possible.
Counterparty abandons handshake	Maker bond is slashed to taker after timeout.
Middn server compromise	Server holds zero custody and zero plaintext. Compromise cannot move funds or decrypt trade content.
Front-end tampering	Subresource integrity hashes on all assets, IPFS-pinned UI builds, reproducible builds with deterministic outputs.
Network surveillance	E2E encryption (X25519 + AES-256), forward secrecy via per-deal ephemeral keys, all on-chain metadata minimized.
Marketplace fingerprinting	Size bucketing, no exact price disclosure pre-handshake, optional Tor-friendly client.
Replay attacks	Each deal binds a unique nonce + chain ID + contract instance address. Signatures cannot be reused.
Insider abuse	No admin keys exist. The protocol contains no upgradeable proxy controlled by the team.
Governance capture	Voting is weighted by settled-volume reputation, not token holdings. Whales cannot buy in.

What we explicitly don't defend against

The following are out of scope. Users should rely on their own controls:

Private key loss. Middn cannot recover lost keys. Users are responsible for backup. We recommend hardware wallets.
Phishing of the user's signing flow. The user is responsible for verifying the URL and the contents of every signature request in their wallet.
Off-platform agreements. If a user negotiates terms outside the encrypted Middn channel, we cannot enforce them. Trust the protocol, not the chat.
Off-chain delivery in fiat ramps. Middn can prove a bank transfer reference via a ZK proof of a signed bank statement, but it cannot guarantee the seller will release fiat after receiving stablecoin. The maker bond + reputation are the only economic disincentives.
Counterparty asset legitimacy. Users must verify the asset they are receiving (e.g., that an NFT is the intended one, not a forgery). Middn moves bytes; it does not certify authenticity.
Jurisdiction-specific compliance. Tax obligations and legal classifications vary by user location and are the user's responsibility.

Trust assumptions

Middn relies on the following standard cryptographic and infrastructural assumptions:

The Groth16 trusted setup ceremony was honest (at least one of N participants discarded their toxic waste). Our ceremony had 89 participants from 14 organizations; transcript published.
The underlying EVM / SVM chains provide their stated security guarantees (no consensus failure, no 51% reorg of finalized blocks).
Hash functions Poseidon (in-circuit) and BLAKE3 (off-circuit) are collision-resistant.
The discrete log problem in BN254 remains hard for the proof system's security parameter.

Out-of-band recovery

In the worst case where a critical bug is discovered in deployed contracts, Middn has a pre-disclosed emergency pause mechanism: a single function that halts new escrow creation but cannot move existing funds. The pause is operated by a 5-of-9 multisig of independent security researchers (not the core team). Active escrow instances remain settle-able under normal contract rules regardless of pause state — they cannot be frozen.

10 ↘

Security audits

Middn contracts and circuits have been independently audited by two firms with deep cryptography and smart contract expertise.

Auditor	Scope	Date	Status
Trail of Bits	Escrow contracts	Mar 2026	Passed · 0 critical
Halborn	ZK circuits + crypto	Apr 2026	Passed · 0 critical
Code4rena	Public contest	Ongoing	Open · $250k pool

Full audit reports are linked in the project repository. We publish all findings — including informational notes — and every fix is verifiable in the commit history.

11 ↘

Roadmap & references

The current version of Middn (v0.1.4) is feature-complete for spot OTC trades, NFT swaps, and basic fiat off-ramps. Subsequent releases extend the protocol along three axes.

Near-term roadmap

Version	Target	Highlights
`v0.2`	Q3 2026	Gasless meta-tx on L2s · marketplace subgraph v2 · Avalanche & Sui support
`v0.3`	Q4 2026	Time-locked recurring deals · partial-fill semantics · multi-asset bundles
`v1.0`	Q1 2027	Stable API freeze · permissionless deployer · governance handover to settled-volume voters

Open research questions

Post-quantum proof systems. Groth16 relies on BN254; we are tracking research on STARK-based and lattice-based replacements that preserve our gas profile.
Cross-chain atomic settlement without bridges. Current Middn cross-chain swaps use HTLC-style locks; we are exploring zk-rollup-native atomicity primitives.
Privacy-preserving reputation. Today's reputation counter is publicly readable. We are designing a system where wallets can prove "≥ N successful settlements in asset class X" without revealing the exact count.

Download & source

Middn Whitepaper v0.1.4

PDF · 84 pages · 2.1 MB · May 2026 · w/ marketplace spec

Download ↓

References

[1]Groth, J. On the Size of Pairing-Based Non-Interactive Arguments. EUROCRYPT 2016.
[2]Poseidon Hash: A New Hash Function for Zero-Knowledge Proof Systems. USENIX 2021.
[3]Marlin: Preprocessing zkSNARKs with Universal and Updatable SRS. EUROCRYPT 2020.
[4]Signal Protocol Documentation. X3DH key agreement & Double Ratchet. 2016.
[5]Trail of Bits. Middn Audit Report v0.1. March 2026.
[6]Halborn. Middn ZK Circuit Review. April 2026.
[7]The Middn Team. On Atomic OTC Settlement. Anthropic Workshop 2026.

GitHub → Etherscan → Discord → Audit reports →

The Middn whitepaper.