MuTC

TECHNICAL WHITEPAPER

Settlement you can verify, not trust.

The architecture of MuTC's escrow-enforced OTC settlement: one isolated contract per trade, venue-signed authorization, and a Bitcoin settlement path that never takes a counterparty's word for anything.

Version 1.0 · August 2026 · source & verification · github.com/MuTC-tech/mutc-contracts

Design principles

Three rules shape every component described in this paper.

Isolation over pooling. No shared vault ever holds more than one trade's assets. The blast radius of any single failure is one trade.
Verification over assurance. Every claim the venue makes — the deployed bytecode, a Bitcoin payout, a maker's balance — is checkable by anyone against public chain data, in the browser, without MuTC's cooperation.
Custody stays with the user. Keys are generated and used on the user's device. Deposits go to addresses the user's own seed controls; withdrawals are signed locally.

One vault per trade

MuTC does not operate a single escrow contract holding everyone's funds. Every trade deploys its own dedicated escrow contract — a vault — created by a factory at the moment the trade is opened:

MuTCEscrowFactory.createTrade(...)
    └─ new MuTCTradeEscrow(feeBps, feeRecipient,
         partyA, partyB, tokenA, amountA, tokenB, amountB, deadline)
       → a fresh contract address that exists for this trade alone

The trade's terms — who the parties are, what each side owes, the deadline — are fixed in the vault's constructor as immutable state. Nothing can amend them afterwards: not the counterparty, not the venue, not the contract owner, because the vault has no owner and no admin functions. There is no upgrade path, no pause switch, and no function that moves funds anywhere except to the two parties named at creation (and the flat fee to the fee recipient).

Why per-trade isolation matters

Property	Single shared contract	Per-trade vault (MuTC)
Worst-case loss from one bug	Everything the contract holds, across all users	One trade's two legs
State interference	All trades share storage; accounting bugs cross trades	Impossible — each vault's storage holds one trade
Auditability of a trade	Reconstructed from event logs among thousands	The vault address is the trade — its full history is its own
Approval scope	Users approve a contract that also serves strangers	Users approve a contract that serves exactly their trade

The factory keeps a registry mapping trade IDs to vault addresses and aggregates read-only views for the interface, but holds no funds itself and has no power over any vault after deployment.

Trade lifecycle

1 · CREATED

Vault deployed

Terms locked in the constructor. Both legs unfunded.

2 · FUNDING

Deposits arrive

Each party deposits exactly their leg. Wrong amounts revert.

3 · SETTLED

Atomic swap

The second deposit triggers payout of both legs in the same transaction.

✕ · UNWOUND

Refund paths

Timeout or mutual cancel returns every deposit to its owner.

Settlement is atomic: the transaction that completes funding is the same transaction that pays both sides. There is no state in which one party has been paid and the other has not.

Two unwind paths cover every other outcome:

Timeout. After the deadline, a funded party calls claimTimeout() and reclaims their deposit in full. No permission, signature, or cooperation is required — the deadline is enforced by the chain's clock.
Mutual cancellation. Both parties consent on-chain; when the second consent lands, all deposits return. Either side withdraws consent freely before the other has agreed.

Funds are never stranded. From any reachable state, each depositor has a path to either the swap or a full refund that requires no cooperation from MuTC.

Venue authorization

Creating a trade requires a signature from the venue's broker key over the exact terms:

termsHash = keccak256(factory, chainId, partyA, partyB,
                      tokenA, amountA, tokenB, amountB, deadline, nonce)
createTrade(...) requires ecrecover(termsHash, sig) == broker

This closes an attack class that pure permissionless escrow suffers from: reputation forgery. Without authorization, anyone can name an arbitrary address as counterparty in a trade the victim never agreed to, let it time out, and manufacture a public "no-show" against them — or collude between two of their own wallets to fabricate a flawless history. Both attacks were implemented and demonstrated against an unauthorized build of the contracts during internal review; the broker requirement eliminates them.

Each authorization carries a single-use nonce — a signed set of terms cannot be replayed into a second vault.
Signatures are checked with an s-value malleability guard; a tweaked encoding of a valid signature does not verify.
The broker signs terms only — it holds no power over funds, cannot spend from vaults, and cannot block a refund path.

Payment engine

Fees

The fee is 0.40% (40 bps), taken once, on execution, split from each leg at payout. Cancelled and timed-out trades pay nothing, because nothing executed.

Token safety

Non-standard ERC-20s settle correctly. Transfers are made with low-level calls that accept both tokens returning a bool and tokens — like mainnet Tether — that return nothing.
Addresses without code are rejected at creation. A phantom "token" at an empty address silently succeeds on every call; the factory refuses such legs outright.
State before interaction. Funding flags are set before external token calls (checks-effects-interactions), and re-entrant deposits are rejected by a guard.

Griefing-proof payouts

A counterparty whose address refuses incoming ETH cannot hold the swap hostage. If an ETH payout reverts, the vault credits it internally (owedEth) and completes the swap; the recipient withdraws the credit whenever they can accept it. Settlement of one leg is never blocked by the behavior of the other side's receiver.

Bitcoin settlement

Bitcoin has no smart contracts, so BTC legs settle through operator-mediated per-trade addresses under rules that mirror the vault model:

One deposit address per trade (native segwit), with its key generated for that trade alone — the Bitcoin counterpart of a dedicated vault.
Value-scaled confirmation depth. A deposit counts only once buried: 2 confirmations under 0.1 BTC, 3 to 1 BTC, 6 above. A reorged deposit cannot trigger a release.
Two independent data sources. Deposit status is cross-checked against a second block explorer backend. If the sources disagree, settlement halts as disputed; if the second source is merely unreachable, it does not gain a veto.
Overpayment returns to the sender. A release pays exactly the trade amount; any surplus in the deposit address goes back to the depositor, not to the venue.

Self-custodied wallet

The built-in wallet is a standard hierarchical-deterministic wallet, not an exchange account. A 12-word BIP-39 seed is generated in the browser; Ethereum addresses derive from it directly and the Bitcoin address by BIP-84 (m/84'/0'/0'/0/0). Because the derivation is standard, the same 12 words open the same balances in any compliant wallet — the user's access to funds does not depend on MuTC existing.

Balances are chain state, not ledger entries. The interface reads ETH, USDT and BTC balances from public nodes against the user's own addresses.
Withdrawals are signed on the device. Ethereum transactions sign locally via the user's key. Bitcoin withdrawals are built in the browser — coin selection, BIP-143 sighash, RFC-6979 signatures — and broadcast directly to the public network. The signing engine's output is verified byte-for-byte against an independent reference implementation in the automated test suite.
Fees are quoted before sending. The interface prices every withdrawal from live network data (gas estimation on Ethereum, sat/vB fee rates and real UTXO selection on Bitcoin) and shows the exact deduction before the user commits.

Verifiability

Every settlement claim is independently checkable:

Claim	How anyone verifies it
The deployed contract is the published source	The verification page compiles nothing and trusts nothing: the visitor's own browser fetches live bytecode from a public RPC and compares it against the published build, immutables masked.
A Bitcoin settlement paid what it claims	The same page decodes any settlement transaction directly from public Bitcoin explorers — amounts, addresses, fee — with no MuTC server in the path.
The source history is real	Contracts, tests and CI run publicly at MuTC-tech/mutc-contracts; the audit workflow re-runs the full suite weekly and on every push.
A maker's funds exist	Proof-of-funds badges on the board re-verify against mainnet balances every minute, and lapse when funds move away.

Trust model

Precision about what is trustless and what is not:

Component	Trust required
EVM vault settlement	None. Atomicity, refunds and deadlines are enforced by contract code with no admin surface.
Vault refund paths	None. Timeout reclaim needs no signature from MuTC or the counterparty.
Trade admission	The broker key signs which trades open. It gates entry, never funds — a malicious broker could refuse service, not steal.
Bitcoin legs	Operator-mediated within the published rules (per-trade keys, depth policy, dual-source checks). This is the trust cost of an unscriptable chain, stated plainly.
Wallet custody	None. Keys derive and sign on the user's device under standard BIPs.

The table above is the complete trust surface — two named concentrations, stated plainly, and nothing else. MuTC's key policy binds both: any key that can touch real-asset settlement operates from hardware-backed custody with co-signing. Everything outside those two rows settles without trusting MuTC at all.

Security process

The contracts have been through an adversarial internal review in which each vulnerability class was implemented as a working attack before being fixed and regression-tested: reputation forgery, signature replay and malleability, re-entrancy, ETH-refusal griefing, phantom tokens, non-standard ERC-20s, Bitcoin reorg acceptance, single-oracle trust, and operator surplus capture. The full findings table, with severity and status for every item, is published on the contracts page.

51 automated adversarial tests: 27 across the vault and factory and 12 against the Bitcoin settlement module run in public CI weekly and on every push; 12 more verify the browser wallet's Bitcoin signer byte-for-byte against an independent implementation in the platform's suite.
Deployment verification re-checks the live factory against the published build on every CI run.
A third-party audit precedes open trading. Internal review sets the floor, not the ceiling; the venue opens real-asset settlement behind an external report.