working whitepaper

A trust layer for direct trade.

Middn is an AI-assisted, privacy-first, smart-contract powered P2P trading layer. This draft explains the product thesis, escrow flow, AI guidance, privacy direction, market design, and proposed MID token economics.

v0.2 / May 2026 Testnet product draft No custody by Middn
01

The thesis

The internet made it easy for two strangers to find each other. It did not make it easy for them to safely exchange value without handing custody to a centralized platform. Middn exists for that missing middle layer.

The product vision is simple: users keep wallet control, the smart contract holds escrow state, the AI agent explains what is happening, and privacy proofs reduce how much personal data needs to be exposed.

the basic Middn room Buyer payment proof Seller release ready smart escrow AI guide ZK / private proof * *
positioning note

Middn is not presented as a guarantee of safety, profit, or legal protection. It is product infrastructure designed to make trade state, evidence, and release decisions clearer.

02

Why the old way breaks

P2P trading often forces users into two bad options: give funds to a centralized exchange, or coordinate privately across chats, screenshots, wallets, bank apps, and trust signals that are hard to verify.

What Middn is designed to reduce

  • Custody risk from platforms that hold assets as part of the trade experience.
  • Off-platform confusion where critical proof lives in Telegram, WhatsApp, email, or screenshots.
  • Blind trust in unverifiable counterparties, fake reputations, or unclear payment instructions.
  • Dispute chaos when neither side has a clean timeline of what happened.
the difference scattered trade chat receipt? proof and terms drift apart Middn room terms escrow proof one state, one timer, one proof trail
03

The protected trade flow

The core product flow is deliberately simple. A user should be able to connect a wallet, open a room, agree terms, fund escrow, submit proof, and release or dispute without needing to understand smart contracts.

Room states

StateWhat happensUser sees
draftBuyer and seller review amount, asset, payment method, and requirements.Chat, terms, risk hints, countdown to accept.
acceptedBoth sides approve the room before funds move.Escrow can be generated.
fundedThe crypto side deposits into the smart contract.Contract address, lock state, timer.
proofThe payment side uploads evidence and follows instructions.AI proof check and seller confirmation.
releaseSeller confirms payment or dispute review resolves the room.Release, refund, or dispute outcome.
pre-escrow agreement room chat AI guidance timeout cancel dispute path
04

Smart contract escrow

Middn's escrow direction is non-custodial: the application coordinates the room, but the contract holds the funded asset and exposes clear state transitions. Middn should not be the account that receives user funds.

Simplified contract state

// simplified product sketch, not production code enum State { Draft, Accepted, Funded, ProofSubmitted, Released, Refunded, Disputed } struct EscrowRoom { address buyer; address seller; address asset; uint256 amount; bytes32 termsHash; State state; } function release(uint256 roomId) external onlySeller { require(rooms[roomId].state == State.ProofSubmitted, "proof required"); rooms[roomId].state = State.Released; // funds transfer from escrow to buyer or seller depending on market type }

Design principles

  • Explicit funding before any payment instruction is shown.
  • Terms hash so the room can prove which conditions were accepted.
  • Timeouts so inactive rooms do not trap attention forever.
  • Dispute branch where evidence is organized before any human review.
05

The AI trade agent

The AI agent is not a black-box judge and should not sign transactions for the user. Its role is to make the room easier to understand: explain steps, detect risk, compare proof against terms, and prepare neutral evidence summaries if a dispute appears.

assistant inside the room AI guide reads the room, not your wallet keys risk hints evidence summary

Agent tasks

  • Explain each stage in plain language before the user clicks.
  • Warn when someone tries to move the trade to WhatsApp, Telegram, or email.
  • Check payment proof for amount, date, sender name, reference, and method.
  • Summarize dispute evidence without deciding the outcome alone.
06

Privacy and ZK direction

Middn should not force every user into maximum disclosure. Some trades may need stronger verification, but the product direction is selective disclosure: prove only the attribute needed for that room.

SignalCan proveShould avoid exposing
walletUser controls the wallet address.Private key, seed phrase.
reputationLevel, success rate, completed trade count.Full trade history.
identityVerified person or business status when required.Full documents to every seller.
jurisdictionEligible or blocked status for a market rule.Unneeded personal address data.
KYC vs ZK

KYC and ZK are not automatically contradictory. The goal is not to remove all verification, but to avoid repeatedly exposing raw identity data when a reusable proof can express the needed trust signal.

07

Markets on Middn

The same escrow room model can support different markets. Each market changes the proof requirements, payment rules, and room language, but the user should always understand: who sends what, who receives what, what is locked, and what happens next.

P2P fiat rails OTC private rooms RWA milestones NFT swaps Digital services Cash in person research

Market-specific rules

MarketPrimary needMiddn layer
P2PPayment proof, deadlines, seller requirements.Escrow room + AI proof check.
OTCNegotiated terms, large tickets, private access.Pre-escrow agreement + staged approvals.
RWADocuments, invoices, milestones.Milestone escrow + evidence bundles.
NFTMetadata, wallet ownership, collection checks.NFT escrow + AI metadata warnings.
DigitalDelivery proof, revisions, service milestones.Freelance-style escrow room.
08

MID tokenomics draft

MID is planned as the coordination asset for incentives, reputation, fee design, and future governance. The numbers below are a draft allocation framework and should be treated as product planning, not an investment guarantee.

30%Ecosystem and rewards / 30M MID
20%Team and advisors / 20M MID
15%Seed and private sale / 15M MID
12%Treasury and reserve / 12M MID
10%Liquidity across CEX and DEX / 10M MID
10%Partnerships and marketing / 10M MID
3%Public sale, IDO, launchpad / 3M MID
ICO note

The public sale concept currently uses 0.50 USD per MID in the local testnet prototype. Final sale mechanics, compliance requirements, and chain deployment would need to be confirmed before any real launch.

09

Roadmap and open work

The next phase is about turning the prototype into a coherent beta: fewer screens, clearer room states, stronger wallet connection, testnet escrow contracts, and a focused onboarding story for beta testers.

PhaseFocusStatus
01Public landing, docs, whitepaper, app prototype visual system.in progress
02P2P deal room, pre-escrow agreement, chat, timers, seller requirements.prototype
03Testnet contracts, fake USDC, buyer/seller state simulation.planned
04AI proof reading, dispute summaries, scam warnings.planned
05Privacy proof layer and reusable reputation signals.research

Complete Middn Whitepaper

Download the full standalone whitepaper package.

Download full whitepaper

Important: this whitepaper is a product draft. It does not make financial, legal, security, or performance guarantees. Contract code, audits, token terms, and compliance flows must be finalized before any real-money deployment.