How ShadowVault is built

The market is boring on purpose. Every decision below exists to keep one property true: an order either settles exactly as agreed, or the coin goes back. None of it depends on an admin being awake at 04:00, and none of it depends on you trusting a sentence on this page — the parts you can check are published on the canary page and signed with the desk key.

Stack

One public edge: a reverse proxy terminates TLS, serves the static files you are reading, and forwards dynamic requests to the application tier. Nothing else on the host is routable from outside. The proxy is the only component with a public listener, and it terminates connections rather than passing them through.

Behind it sits the application tier — Python, one worker per CPU, stateless. Session state, carts and counters all live in the store, so a worker can be killed mid-request without stranding anyone's order. The relational store holds listings, orders, escrow rows, the dispute docket and an append-only transition log. It is not exposed to the network; only the app tier and the settlement worker can reach it.

Settlement is a separate process. It owns the wallet handles, talks to the store over a private Unix socket, and has no HTTP surface at all. The app tier can request a transition; it cannot sign one. That split is the whole point — a bug in the request path can mis-file an order, but it cannot move coin without the worker agreeing to it.

Escrow flow

An order walks a fixed five-state path and never skips a step:

1. Buy. The buyer commits to a listing, a quantity and a shipping method. A price quote is frozen against the listing revision at that moment, so a vendor repricing afterwards does not change what you owe.
2. Lock. The settlement worker sweeps the exact amount into an escrow address derived per order. The order is not visible to the vendor until the sweep confirms at the required depth.
3. Ship. The vendor marks dispatch and attaches the shipping proof of their choice — tracking string, postmark photo hash, or a PGP-signed manifest line.
4. Confirm. The buyer confirms receipt, or the 48-hour window from the ship timestamp expires and the order auto-confirms.
5. Release. The worker pays the vendor, minus the buyer-side fee, and marks the escrow row spent. Release is one-shot; the row can never pay twice.

A dispute opened at any point before release freezes the row. Frozen rows keep their escrow address but the worker refuses to release from them until the docket closes. Every transition — including the freeze and every admin action taken on a frozen row — appends a line to the log with actor, timestamp and the state delta. The log is what a ruling is written from; if a transition is not in the log, it did not happen.

Reserves and the ledger

Treasury keys never touch a machine that is online. Signing happens on a Ledger device, held by two operators who each keep half of the recovery material, and the device is only connected when a sweep or a top-up is actually being signed. Between those events the treasury is a set of addresses nobody can spend from remotely.

The coverage ratio is cold reserve balance divided by open escrow liability. It is computed from the escrow table against cold balances and republished in the market feed whether or not it is flattering. Below 1.0 the market keeps selling but flags the shortfall on every listing; below 0.95 new orders are held at the cart. Audits are scheduled quarterly against the same published addresses, so an auditor can prove the balance without asking us for anything.

Cold balances go to exactly two published addresses — one BTC, one XMR — printed on canary.html under Settlement addresses, each with a copy button. If a deposit ever lands somewhere else, that is a signal, not a rounding error.

Mixer

The mixer runs on pooling, not on a fixed denomination table. Deposits are collected into a pool per asset, split into outputs of randomised size, and paid out after a randomised delay to addresses the caller supplies. Splitting and delay are drawn from the same distribution for every job, so a large job and a small job look alike on chain apart from their totals.

Each job is tracked by an ID that is returned at submit time and is the only handle you need. The mixer stores the job ID, the output addresses and the payout schedule — and deliberately nothing that ties the job back to a market account. Paying mixer fees from the same wallet as your purchases is what links them, not the mixer itself. Job state is queryable until the last output is paid; after that the row is pruned.

Hardening

Rate limits and lockouts sit in front of authentication, not behind it, so a bad password costs the attacker before it costs the hasher. Limits are per-IP token buckets with a per-account exponential lockout layered on top: five failures back off for a minute, then five minutes, then an hour. The counter resets on a successful login from a previously seen fingerprint.

Sessions are short — thirty minutes of idle, hard expiry at twelve hours, no silent extension. The cookie is host-only, HTTP-only and same-site strict, and rotating a password drops every other session on the account.

The public edge is deliberately thin: no admin UI on the market hostname, no directory listing, no framework debug page. The login form, the search endpoint and the order lookup are the only surfaces worth brute-forcing, and all three are throttled and answer in constant time whether or not the record exists.

Uptime

Health checks run continuously from three vantage points, one inside the hosting network and two outside it. Edge health, app-tier health, store replication lag and settlement-worker liveness are all checked separately, because "the site loads" and "orders can settle" are different facts and only the second one matters.

Degradation is graceful and explicit. If the settlement worker drops, the market stays up in read-only mode: listings, search and past orders keep serving, carts warn that checkout is paused, and a banner names the component. If the store goes, the edge serves a static page rather than a half-rendered one. Nothing in degraded mode can lose an order, because nothing in degraded mode accepts new escrow.