How this works
The market data is real: every price, book, trade print and candle on this site is read from a public venue feed. The money is simulated — and it really moves, through a double-entry ledger built as though it were not simulated at all. This page draws the line between those two halves, describes the machinery on both sides of it, and ends with four things you can go and check without taking any of it on faith.
Nothing of value is custodied
Every balance here is still paper money the system issues to itself: no bank, no payment rail, no counterparty, and no asset anyone could lose. What has changed is the machinery underneath. A real settlement rail now exists — a watcher that credits confirmed on-chain deposits, and a payout worker that can carry a withdrawal from approval to a signed broadcast — and it is confined by configuration to test networks, whose tokens carry no monetary value. It refuses every mainnet outright, and the payout side additionally ships switched off. The rail is real; the money still is not.
Real money would require what has deliberately not happened: a mainnet enabled on purpose in a production deployment, custody with keys held outside this system, regulatory authorisation and production transaction screening — none of which exists. This build deliberately has no KYC or identity-verification flow. It also means the usual proof does not apply. An exchange this size would publish a reserve attestation here; a fabricated one is strictly worse than none, so what sits in that slot instead is a live health reading you can check yourself.
Check the feed right nowWhere the numbers come from
Two processes, and a cache is the only seam between them. A websocket has to outlive a request and a request handler is gone the moment it responds, so the venue connections cannot live in the web app — that is the entire reason a second process exists. The worker only writes; the site only reads; neither knows anything about the other beyond what passes through the cache.
- The venue publishesBinance streams public spot and perpetual market data over websockets, and serves the same data over REST. Nothing on this path is invented, smoothed or delayed on purpose.
- One worker holds the sockets openSpot and perpetuals run as independent pipelines that share no state, so an outage on one cannot stall the other. Each keeps a ticker connection for the whole streamed set and a separate detail connection for the symbols terminals are actually open on — sharing one would mean a resubscribe storm interrupting prices for every pair on the board.
- It writes into the cache, and only writesA batched channel per venue for ticker updates, a channel per symbol for book, trade and candle frames, and snapshot keys so a cold page load renders before the first tick arrives. Ticker updates are coalesced before publishing: within one window only the newest price for a symbol matters, and a queue of superseded prices would only make the browser render stale frames on its way to the current one.
- The web app subscribes and streams it onServer-sent events, not websockets — one direction, self-reconnecting, no protocol of its own. Server-rendered pages read the snapshots directly. The only thing the web app ever writes back is which symbols are being watched, never a price, which is what makes “the worker is the only thing that can be wrong about a price” a true sentence.
- Your browser holds one stream per surfaceThe ticker store subscribes per symbol, so a batch that moves twelve prices re-renders twelve rows rather than the whole board. An open terminal registers its interest with an expiry of 90 seconds — whoever is still watching renews it, and everyone else ages out, so the worker never streams a symbol for a tab that closed.
The cache is a cache, never a dependency
This is the dashed line in the figure. Every server-side read tries the worker’s snapshot first and falls back to the venue’s REST API when it is missing, so the site runs with no worker and no cache at all — slower, polled rather than streamed, never blank. A trade tape holds 60 prints per symbol when the cache is warm, and comes from the venue when it is not. There is no code path anywhere that renders an empty panel because a cache lookup missed.
Three feeds, and nothing else
Every external number on this site comes from one of three public sources. There is no aggregator in between, no data broker, no private feed, and nothing bought from anyone.
Binance public market data
Prices, order books, trade prints, candles, funding rates, mark price, open interest, and the instrument rules every order is validated against.
Public endpoints only — the same ones anyone can read without an account. No order of ours has ever been sent to them.
CoinGecko asset data
Market capitalisation, circulating supply, rank, and the descriptions and project links on an asset page.
Facts a trading venue's own feed does not carry. Cached hard against a shared free tier, and omitted rather than guessed when a read fails.
European Central Bank reference rates
Daily fiat reference rates, for the currencies in the cross-rates tool that no crypto venue quotes.
Published once per working day, so a cross rate routed through one is a reference level rather than a live market — and the tool says so on the cells that use it.
What never reaches your browser
The venue’s full instrument catalogue
It is roughly 17 MB on spot. The worker fetches it, reduces it to the few fields an order needs — tick size, lot size, minimum notional, trading status — and caches that. Shipping the raw document to a phone to answer “how many decimals does this pair accept” would be absurd, and it is the kind of absurdity that ships when nobody looks at the response size.
Any figure that is money
The account stream carries a poke: a reason that something changed, never an amount. The client then refetches from the ledger. A dropped message therefore costs one refresh interval of staleness rather than a wrong number rendered as a balance, and there is no path by which a stale broadcast becomes the figure on your screen.
When it breaks, and what that looks like
This is the longest section on the page, and that is the point. Every claim above describes a system working; the ones below describe it failing, which is the part a reader cannot verify from a screenshot and the part most pages like this leave out. Each row names the component that handles the failure and, last, what you are actually looking at while it happens.
The feed goes quiet
A market-data socket does not fail loudly — it fails by going silent, and a frozen number looks exactly like a stable one. Most of the engineering here is about detecting silence rather than handling errors.
A venue socket stays open and goes quiet
the socket watchdog
A TCP connection can stay open long after the peer stops sending, so readyState === OPEN is not evidence of anything — a recent message is. A watchdog checks every 10 seconds and, after 60 seconds of silence, terminates the socket itself. terminate() rather than close(): a half-open connection never completes a closing handshake, so a graceful close would wait forever for a peer that is gone.
You see — A gap of a few seconds in the tape, then it resumes. Nothing freezes at its last value.
A socket is connected and delivers nothing
the ticker ingest and the catalogue sweep
Measured against the live venue rather than assumed: the perpetuals endpoint accepts a subscription to the ticker stream, reports it active under a subscription listing, and then sends nothing — while the trade stream on the same connection runs normally. So the ingest tracks its own last delivery, marks the feed starved after 45 seconds without one, and the catalogue sweep tightens from a 60-second backup poll to a 15-second one. Perpetual prices are rebuilt from the trade tape for the same reason, with the 24-hour figures carried from the sweep.
You see — Prices keep moving on a poll instead of a stream. The worker heartbeat names which venue is polling.
Nothing is subscribed yet on the detail socket
the watchdog’s idle exemption
The connection that carries books, trades and candles has nothing subscribed until someone opens a terminal, so silence on it is correct rather than suspicious. It reports itself idle and the watchdog leaves it alone. Without that exemption the watchdog kills a healthy socket every 60 seconds, and each kill wipes the venue-side subscription set — which is how a working candle stream ends up delivering nothing to every terminal that opens next.
You see — Nothing, which is the point. A terminal opened after a quiet spell still streams immediately.
The venue drops the connection, or a whole region reconnects at once
the reconnect backoff
Reconnection is exponential, capped at 30 seconds, with full jitter — a uniform draw from zero to the current ceiling rather than a fixed delay, so a fleet coming back after a venue incident spreads out instead of arriving together and becoming the second half of the outage. The venue also cuts connections at 24 hours; each socket recycles itself before that on its own schedule, so the drop is planned rather than a surprise at an unpredictable moment.
You see — At worst a few seconds of gap. Reconnects are logged by the worker, never surfaced as an error to you.
A frame arrives that cannot be decoded
the frame decoder
One malformed message is caught where it is parsed and logged, and the connection carries on. The alternative — letting a decode error propagate — takes down ingest for every other symbol sharing that socket because one of them sent something unexpected.
You see — Nothing. One frame’s worth of one symbol is missing, and the next frame replaces it.
The cache, or the worker, is gone
The worker and the cache are an accelerator, not a dependency. Everything below is the site running without one or both of them, which is the ordinary state during a restart.
The cache is cold, or not running at all
every server-side market read
Each read tries the worker’s snapshot and falls back to the venue’s REST API when it is missing, so the site runs with no worker and no cache at all. The live stream routes do the same rather than dropping: if the subscriber cannot connect they poll the venue directly — the board re-reads tickers every four seconds, a terminal its book and tape every three. The stream stays open and the events keep arriving; only their spacing changes.
You see — Slower pages and polled rather than streamed prices. No blank panel, no spinner that never ends.
The worker dies while the cache keeps running
the snapshot expiries
This is the dangerous one, because a stale cache entry looks exactly like a fresh one. Every key the worker writes carries an expiry: the heartbeat 30 seconds, a book snapshot 60, the ticker hash 120, the trade tape 300, funding 600, the instrument catalogue two hours. Data from a dead worker expires rather than freezing, and the reads fall back to the venue on their own without anyone deciding to. A key written without an expiry would leave the whole site serving the last prices it ever saw, indefinitely, and looking healthy.
You see — System status flips to Degraded, and the health endpoint answers 503 instead of 200 and names what is carrying the site.
The cached order book is stale or hollow
the order-book read
A book older than five seconds is refused and refetched from the venue, and so is a book with no levels in it — an empty snapshot is absence wearing a timestamp, and serving it would starve order placement of liquidity the venue actually has. The worker will not persist a hollow book in the first place. Order placement fetches its own book server-side at execution time regardless, fifty levels deep.
You see — An order never prices against a level that has already gone.
The venue geo-blocks the host
pipeline bootstrap
The venue answers some regions with 451. That pipeline logs the refusal and does not start, while the other one carries on serving — spot and perpetuals are independent pipelines that share no state, and every cache key either side touches is namespaced by kind. If neither can bootstrap, the worker exits non-zero rather than running empty and reporting itself healthy.
You see — One board or the other is unavailable and says why. Nothing renders an invented price in the gap.
The asset-data provider is unavailable or rate limited
the asset profile read
Market capitalisation, supply and rank come from CoinGecko rather than a trading venue, on a free tier whose budget is shared across everyone using this deployment. Every call is cached hard — rankings for five minutes, descriptions and project links for an hour — and when a read fails the section is omitted entirely rather than filled with a placeholder. Degrade by absence, never by invention.
You see — An asset page without its About block or its market-cap figure. Prices, book and tape are untouched — they come from somewhere else.
Something that moves money is down
The ledger has one write path and it is transactional, so the interesting question is never “what half-wrote” — it is what the system declines to do while a dependency is missing.
A mark price or funding rate goes missing
the positions sweep
Liquidation and funding read the venue’s published mark, never a last trade — a single-print wick is precisely what a mark price exists to ignore. A mark older than 60 seconds, or absent, skips its symbol for that pass: positions there are not funded and not liquidation-checked, and the symbol is named in the worker’s heartbeat under degraded. A silent skip would be indistinguishable from a pass with nothing to do.
You see — Funding and liquidation resume on the next pass that has a price. The gap is reported, not smoothed over.
A stop has no recent print to check against
the resting-order sweep
No trigger that pass. A stop fires on the venue’s record that the market actually traded at a price, and when the tape returns nothing the honest answer is to wait for the next sweep rather than to infer a trade from the book. The same reasoning refuses a stop at placement whose trigger the tape has already passed.
You see — A stop triggers a few seconds later than it might have. It never triggers on a price nobody traded at.
The exchange database is unreachable
the worker sweeps, and every account action
Market data is unaffected — it never touches the database — so prices, books and candles keep streaming while accounts are unavailable. The resting-order and positions sweeps fail their pass quietly and the next tick retries; one bad symbol inside a pass logs and the pass continues for the rest. Account actions are single transactions, so there is no partial state to reconcile: a sign-up that cannot reach the database created no user, no wallets and no opening balance, and says exactly that rather than hedging.
You see — The market side of the site keeps working. Anything involving your balance says plainly that nothing was written.
None of this is a promise that the site is up. System status reports the ingest worker rather than the web server, because a health check that stays green while every price is an hour stale is worse than no health check at all.
What actually happens when you place an order
Eleven stages, in order, from the ticket to the notification. The money is paper and every constraint on it is real: the same validator the engine uses runs in the form, the fill price is walked over the live book, and the transfer that settles it cannot be written unless its legs sum to zero.
The ticket checks the market’s own rules
the shared order validator
Tick size, lot size, minimum notional, and whether the instrument is trading at all. The form and the engine call this one function, so the ticket cannot accept an order the engine would then refuse — two copies of these rules drift, and the result is a form that said yes and an order that vanished. Every rule here belongs to the instrument, not to you: it holds identically whether or not anyone is signed in, which is why the ticket can enforce it before there is an account to check. A malformed draft never becomes an order row at all, because recording every typo as a rejected order would fill a history with things that were never orders.
Refused before anything is written
- market_halted
- price_required
- price_not_positive
- price_precision
- trigger_price_required
- trigger_not_positive
- trigger_precision
- trigger_immediate
- quantity_not_positive
- quantity_precision
- below_min_notional
The book is fetched on the server, not taken from your browser
the placement action
Fifty levels, read at execution time — deeper than the twenty the terminal shows, because a market order can legitimately walk past the visible book. A browser’s copy is however old its last frame was, and a client that could post its own book could choose its own fill price. The market definition is read server-side for the same reason: precision and minimum notional are the constraints being enforced, so they cannot arrive from the thing being constrained.
One transaction opens, and nothing happens outside it
the order engine
The trading account is resolved first, because the replay check is scoped to it. The idempotency key is client-supplied and built from public values, so an unscoped lookup would hand another account’s order to whoever collided with its key. Then the spendable balance is locked before it is read, so two placements arriving together cannot both pass their own check against the same funds. A second submit of the same key returns the order it already placed — including the fills, so the replayed copy carries the same average price rather than a null that would read as “never filled”.
The plan walks the live book
the matching engine
Best price first, taking no more than each level actually holds — taking more would be inventing liquidity. Quantities round down, because rounding one up spends money the account does not have. A limit order stops at the first level on the wrong side of its price; the book is sorted, so nothing past it could be acceptable either. The average is volume-weighted over the planned fills, and it is null rather than zero when nothing filled — a zero renders as a real-looking price someone could act on.
A stop does not walk anything yet
the order engine
Its condition has not fired, so filling it here would fill it at prices its own trigger says it is not ready to accept. It goes straight to
untriggeredwith an empty plan and a reservation as real as a resting limit order’s — off the book, but the funds are just as spoken for. A stop already through its trigger is refused at the ticket rather than placed: an order that fires on the next print is a limit order with an extra step.A stop must also be good-till-cancelled
- stop_requires_gtc
Funds are checked once, against everything the order needs
the order engine
What the immediate fills spend, plus what a resting remainder will lock, against what is available right now — one check covering both, because two separate ones each pass while their sum does not. Short of that, the order is refused and nothing is written. A fill-or-kill that cannot fill in full is recorded as expired having moved no money at all, and a market order with nothing to fill against is refused rather than parked.
Refused here
- insufficient_funds
- no_liquidity
The match becomes balanced ledger legs
settlement
Five of them for a spot buy — the figure below is exactly this step. The fee is charged in the asset received and rounded up; a fee rounded down means the house absorbs the remainder on every trade, and each shortfall looks like a rounding error in every report. The other side of every leg is the internal
externalaccount, the same contra account a deposit uses, because this exchange holds no inventory to trade out of.The ledger refuses to be wrong
the ledger’s single write path
There is exactly one write path to the entry table and it sums the legs per asset, in decimal, before a row is inserted. An unbalanced transfer is not a validation failure to report to a user — it is a bug in the caller, and it throws. Summing as floats would let a transfer that is out by 1e-18 pass the very check that exists to catch it. A transfer with fewer than two legs is refused on the same grounds: one leg is not a movement, it is an assertion.
The order, its fills and its first event are written
the order engine
In the same transaction as the money. There is no state in which an order exists but its funds have not moved, or funds have moved and no order records why. A resting remainder moves from available to locked, stored as the exact amount locked rather than recomputed later from a price that has since changed. The fee sits on the first fill rather than being spread across fills it did not price, because it was charged once against the whole batch.
Statuses an order can hold
- untriggered
- new
- partially_filled
- filled
- expired
- cancelled
The worker sweeps while nobody is looking at a page
the resting-order sweep
Every five seconds, driven off the open orders themselves rather than off every streamed symbol — almost always no rows, and when there are, a handful. Stops go first and are checked against the latest trade print, the tape rather than the book, because a print is the venue’s record that the market actually traded there. A stop that triggers becomes a plain resting limit order that the same pass then fills, with no special case. This is work no request handler can do: it is gone the moment it responds, and a limit order placed and abandoned still has to fill when the market reaches it.
You are told what happened to your money
the account stream and your order history
The fill appears in your order history and your balances, and a notification names what moved. The account stream carries a poke — a reason, never an amount — and the client refetches from the ledger, so a dropped message costs one refresh interval of staleness instead of a wrong number rendered as money. The sweep sends at most one poke per account per pass, however many of your orders it touched.
And if you cancel
A cancel and the sweep can want the same resting order in the same instant — you pressing the button while the market reaches your price. The whole of the concurrency control is a single statement that claims the row only if nobody else holds it: it either returns the order or it returns nothing, and nothing means someone else got there first. Reading the order and then deciding would let both proceed and release the same reservation twice.
What comes back is exactly what was locked, taken from the amount recorded at placement rather than recomputed from a price that has since moved. A cancelled order keeps whatever it filled before it was pulled, so its average price still comes from its fills — an order that filled half and was then cancelled is not an order that filled nothing.
The spot taker rate is 0.10%, charged in the asset you receive. Fees documents every charge in the product, each one imported from the engine that levies it, with the ledger account it lands in named beside it.
The ledger, which is the part built as though the money were real
This is the section that justifies the phrase “and it really moves”. A simulator can hold a number in a column and add to it. What is underneath this product instead is double-entry bookkeeping with one write path, a balance that is derived rather than stored, and a constraint that throws rather than posts — the same machinery you would build if the balances were owed to someone, because if they ever are, none of it changes.
A balance is not stored anywhere
There is no balance column to update, because a column can disagree with its own history and when it does there is no way to tell which one is lying. Every number this product shows you is a sum over ledger entries, computed when you ask for it. That is slower than a cached figure, and it is the entire point: your balance cannot drift from the list of things that happened to it, because it is that list.
Every entry the trading engine writes lands in one of four buckets. Two are yours and two belong to the system, and every simulated transfer is some combination of them. The schema declares three more for on-chain settlement, and two now have a writer: a test-network chain deposit credits settlement — assets actually held on a chain — mirrored by customer_funds, the record of what those holdings owe to users. Only gas remains a name no code writes, because gas accounting is deliberately unbuilt.
availableyours- Spendable right now. This is the number an order ticket checks against and the one every wallet screen leads with.
lockedyours- Yours, and already spoken for by a resting order or an open position’s margin. Still your money; not money you can spend twice.
externalsystem- The outside world, as one account. Everything you have ever been credited came from here and everything you have ever spent went to here, so it runs permanently negative — its balance is the running total of what this system has issued itself.
feessystem- Where every fee lands. It has no owner, it is a real account rather than a reporting category, and it is the one place the exchange’s own take accumulates.
The simplest transfer in the system
A credited on-chain deposit is four legs, one asset: the tokens this exchange now holds enter settlement, and the same amount becomes spendable in your spot wallet. Signup no longer types a balance — a new account is empty until a deposit confirms.
| externalsystem | −10,000.00 |
|---|---|
| settlementsystem | +10,000.00 |
| customer_fundssystem | −10,000.00 |
| Your spot walletavailable | +10,000.00 |
| Sums to | 0 |
Nothing arrived from anywhere. The credit is balanced by a debit to external, which is why that account is permanently negative and why the books stay square while nothing of value is custodied. The settlement rail did not repurpose this leg when it arrived: a chain deposit posts its own kind against its own accounts, so this credit keeps meaning exactly what it says — the system issuing paper to itself.
One market buy, as five ledger entries
Buy 1 BTC at market. The book fills it across two levels — 0.4 at 64,000.10 and 0.6 at 64,001.00 — for an average of 64,000.64, and the 0.10% fee comes out of the BTC that arrives rather than the USDT that left.
| Your spot walletavailable | −64,000.64 |
|---|---|
| externalsystem | +64,000.64 |
| Sums to | 0 |
| externalsystem | −1.00000000 |
|---|---|
| Your spot walletavailable | +0.99900000 |
| feessystem | +0.00100000 |
| Sums to | 0 |
Both totals are zero because the ledger refuses to write anything else: the legs are summed with decimal arithmetic before a row is inserted, and an unbalanced transfer throws rather than posting. The transfer carries the key <order id>:settle — derived from the order, never from the client — so a retried submit settles once and a key that legitimately repeats across two accounts cannot collide into one.
A sell is the same five legs mirrored: base leaves, quote arrives, and the fee comes out of the quote instead. Charging in the asset received rather than the asset spent is what lets a buy reserve exactly what the order costs — reserving fee-inclusive amounts is where “insufficient funds” on a perfectly funded account comes from.
The fill prices above are illustrative. Every number derived from them — the volume-weighted average, the fee, the credited amount, the five legs — is the arithmetic the engine performs, not a rounded retelling of it.
Everything the ledger knows how to do
Every kind of movement below has code that writes it, and together they are every way value moves in this product. It is a tighter description of the surface area than any feature list, because a capability with no transfer kind cannot move money by definition. The newest group belongs to the settlement rail and moves only test-network tokens; the last group below is the corollary: names the schema declares that nothing calls.
Money entering and moving inside an account
- deposit
- A credit this system issues to itself, against external.
- wallet_transfer
- Between your own spot, futures and funding wallets.
- convert
- One asset to another, priced through the live tickers.
Spot orders
- order_reserve
- Available to locked, when an order rests.
- order_release
- Locked back to available, when it is cancelled.
- trade_settle
- A fill: assets swap and the fee is taken.
Perpetual positions
- margin_reserve
- Margin locked when a position opens or grows.
- margin_release
- Margin returned when it closes or shrinks.
- pnl_settle
- Realised profit or loss, at the moment it is realised.
- funding_fee
- The eight-hourly payment between long and short.
- liquidation
- A position closed by the engine rather than by you.
On-chain settlement — test networks only
- chain_deposit
- A confirmed test-network deposit, credited after its confirmation depth and a reorg check.
- withdrawal_reserve
- Available to locked, the moment a payout is requested.
- withdrawal_settle
- The payout confirmed on chain, leaving the books for good.
- withdrawal_release
- The reservation returned when a payout fails or is refused.
And the names with no code behind them
- withdrawal
- gas_cost
Both are names the schema declares and nothing calls. withdrawal is the original simulated-payout kind, left alone rather than repurposed when the chain-backed lifecycle took three new names of its own — a kind that changes meaning makes every historical row ambiguous. gas_cost waits on gas accounting, which is deliberately unbuilt. This list held six names before the settlement rail gave the other four writers, and the argument it used to carry — a vocabulary is not a capability — no longer covers them: the capability exists now, confined to test networks where nothing it moves is worth anything, which is exactly what the custody statement at the top of this page says.
Why decimal strings, everywhere
Anything a user could be owed is a decimal string and never a floating-point number, stored in a column type that round-trips exactly. It matters most at the one place it is least visible: the balance check that sums a transfer’s legs. Summed as floats, a transfer out by one part in a quintillion passes the very check that exists to catch it. Floats are still fine for charts — the line is drawn between numbers you look at and numbers you are owed.
What runs while you are not looking
A resting order has to fill when the market reaches it, and a position has to be liquidated before it goes past its collateral, whether or not anyone has the page open. Neither is work a request handler can do — it is gone the moment it responds — so both live in the same long-lived process that holds the venue sockets. Two sweeps, each every five seconds.
Resting orders and stops
Driven off the open orders themselves rather than off every streamed symbol — almost always no rows, and when there are, a handful. Fetching two hundred books on a timer to serve three resting orders is the expensive way round. Stops are checked first, against the latest trade print; a stop that fires becomes a plain limit order that the same pass then fills.
Funding, every eight hours
Charged at each crossing, from the same fresh mark-and-rate pair, and taken from available balance first — only the remainder comes out of the position’s own margin. It is not a fee this exchange collects: its ledger legs touch the external account and never the fee account, because funding is a payment between the long and the short side.
Liquidation
Checked against the venue’s published mark price and never a last trade, because a single-print wick is exactly what a mark price exists to ignore. Maintenance margin is a flat 0.5%. The scan only nominates; the engine re-checks everything from the locked row, and the account’s open orders on that symbol are cancelled after the close has committed rather than inside it.
The parts that clean up after a crash
Reduce-only orders whose position no longer exists are reaped. Take-profit and stop-loss legs owed by a fill that committed just before a restart are placed on a later pass, replayed rather than duplicated because their keys are derived from the fill they belong to. A crash in the wrong millisecond costs latency, never protection.
Each pass publishes at most one notification per account, however many of your orders or positions it touched — a reason, never an amount, with the figures refetched from the ledger.
What this does not simulate
Filling against a real book is honest about slippage and dishonest about everything that happens between traders. These are the differences that would change a result, listed rather than glossed — a simulator that hides its own edges teaches the wrong lessons most confidently.
Market impact
Your fills consume levels inside the plan and nowhere else. The venue’s book is unchanged, nobody else’s screen moves, and a size that would genuinely shift a real market here costs only what the visible depth costs.
Queue position
Your order never rests on the venue’s book, so it never waits behind anyone and never earns a maker rebate. Every fill is a taker fill, which is why there is no maker rate and no rebate tier.
Latency, and losing a race
The book is fetched server-side at the moment of execution. There is no round trip in which someone faster takes the level you were aiming at, and no queue of other people’s orders ahead of yours.
Instant resting fills
A resting order fills on a sweep that runs every five seconds, not the instant the price prints. On a fast move that is the difference between a fill and a better fill.
Depth past the fetched book
Fifty levels are read for execution. An order larger than that leaves a remainder, which expires for a market order and rests for a good-till-cancelled limit, rather than filling at a price nobody quoted.
Venue-side risk checks
Self-trade prevention, position limits, order-rate limits and the other rejections a real exchange applies to a real account are not modelled. The rules enforced here are the instrument’s, not the venue’s opinion of you.
A counterparty with a balance sheet
The other side of every fill is an internal contra account, not a trader and not a market maker with inventory. Nobody is ever on the losing end of your win, and no auto-deleveraging or insurance fund exists because there is no pool that could be short.
Anything that happens off the tape
Auctions, halts declared by an issuer, delistings mid-position, funding-rate changes announced rather than published — this product knows what the public feed says and nothing that arrives any other way.
Real, simulated, absent
The same boundary as a list, so it can be checked one row at a time rather than argued. Four states, because “real or fake” is not enough vocabulary for a product whose fill price is real, whose balance is paper, and whose settlement machinery is genuine — and confined to networks where tokens are worth nothing.
| What | What makes it that |
|---|---|
| RealRead from a public feed, or executed by code that would not change if the money were real. | |
| Last price, 24h change, high, low and volume | Binance’s spot ticker stream. Perpetual prices are rebuilt from the trade tape plus the venue’s 24-hour snapshot, because the futures ticker stream accepts a subscription and then sends nothing. |
| The order book | Twenty levels, republished every 100 milliseconds while a terminal is open. Order placement fetches its own fifty levels server-side at execution time. |
| The trade tape | The venue’s own prints, newest first, 60 retained per symbol. The aggressor side is what colours each row, and it is read from the field that means the opposite of what its name suggests. |
| Candles | History from the venue’s REST API. The forming one-minute bar is folded from the same trade prints the venue folds its own from — not an approximation of a candle, but the definition of one applied to the same input. |
| Funding rates, mark price, open interest | The venue’s published figures. Funding is swept every five minutes and filtered against the live contract list; open interest is read on demand and memoised for 30 seconds. |
| Tick size, lot size, minimum notional, trading status | The venue’s instrument catalogue, refreshed hourly. The order ticket and the engine call the same validator, so the form cannot accept an order the engine will refuse. |
| Which pairs exist at all | Filtered against the live catalogue rather than the ticker endpoint, which returns every symbol ever listed — including delisted pairs frozen at their final price. |
| Market capitalisation, supply and rank | CoinGecko, for the facts a trading venue’s own feed does not carry. Cached hard against a shared free tier, and omitted entirely rather than placeholdered when a read fails. |
| The price your order fills at | Walked over the live book, level by level, best price first. An order large enough to clear three levels gets a worse average than one that clears a single level, because that is what would happen. |
| The numbers the AI commentary reasons about | The model is handed the same ticker and candles the charts render and told to ground every claim in them rather than recall a price. The prose is a model’s and can still be wrong; the market it is describing is the one that exists right now. Commentary runs only where the deployment carries a server-side model key: without one the desk writes nothing at all and says so on its own page, rather than offering an ask it cannot answer. |
| The ledger, and its constraint | Double-entry, with one write path, which throws rather than writes when a transfer’s legs do not sum to zero in every asset they touch. Amounts are decimal strings stored as Postgres numeric — never floats. |
| Simulated, and really movesPaper money, moved by machinery built as though it were not paper. | |
| Your balances | The sum of every entry ever written against your account, computed at read time rather than stored in a column that gets overwritten — so a balance cannot silently disagree with its own history. |
| Deposits | A credit this system issues to itself. One leg credits you; the other debits an internal account representing the outside world, which therefore runs permanently negative by design. Nothing arrives from anywhere. |
| Orders, fills and their statuses | Real rows with real state transitions, reserved funds and idempotency keys. They never reach the venue and never join the book they fill against. |
| Resting orders and stops | Held off the venue’s book and filled by a sweep that runs every five seconds while nobody is looking at a page. A stop is checked against the latest trade print and becomes a plain limit order the moment it fires. |
| Fees | 0.10% on a spot fill, taken from the asset received and rounded up, accruing to an internal fee account. Quantities round down. Both directions are chosen, not incidental. |
| Perpetual positions | USDT-margined linear perpetuals, one-way, isolated margin. Margin, funding, unrealised PnL and liquidation are computed by the same functions that price the preview before you commit. Leverage is an integer 1 to 75, fixed at open; maintenance margin is a flat 0.5%. |
| Liquidation | Checked every five seconds against the venue’s published mark price and never against a last trade — a single-print wick is exactly what a mark price exists to ignore. The engine re-checks everything from the locked row, so the scan only nominates. |
| Wallet transfers and swaps | Movements between your own spot, futures and funding wallets, and conversions priced per leg through USDT off the live tickers — re-derived server-side on every attempt rather than trusted from the browser. An unpriced leg returns nothing rather than a zero rate. |
| Your order history and activity | Read back from the same rows the engine wrote, in the same transaction as the money. There is no separate activity log that could tell a different story from your balance. |
| The lending simulation | Supply and withdrawal use dedicated customer ledger buckets. USDT may be borrowed against BTC or ETH under server-enforced LTV, utilization-rate, repayment and mark-price liquidation rules. Supplier membership is term-locked while a loan is open; there is no custody, real yield, background risk worker or order-book sale. What it moves is the same spendable paper balance the rest of this group moves — which is why it sits here rather than below. |
| Fee rebates, referrals and campaigns | Settled-fill rebates debit recorded house fees once, referral attribution is fixed in the registration transaction, and campaigns reserve their complete winner cap before activation. Every credit is simulated ledger money, never a token or cash claim — and it lands in a spot wallet you can immediately trade with. |
| Built, and moving nothing of valueReal state machines confined by configuration to networks whose tokens carry no monetary value. Unlike the group above they move no balance you can spend — they are the two rails that would carry value if a mainnet were ever enabled, and neither is. | |
| An on-chain deposit rail | A watcher observes transfers to deposit addresses, waits out a confirmation depth, re-checks the block hash so a chain reorganisation cannot leave a credit standing on a vanished transaction, and only then writes the ledger — under its own transfer kind, not the simulated one. It refuses every mainnet outright; the deposit page exposes only a configured test-network address and reports an unavailable state rather than inventing one. |
| The withdrawal lifecycle | Request, reservation, human approval, then a custody check that refuses to pay out more of an asset than actually arrived on that chain, and a signed broadcast — recorded before it is sent, because sending is the one irreversible act. The withdrawal page shows history and permits request or cancellation only when the deployment passes every gate. It otherwise names the exact refusal; defaults ship off, reject the faucet conflict and contain no signing key. |
| Does not existAbsent, and the product says so where you would look for it — nothing greyed out, nothing “coming soon”. | |
| A real-value withdrawal control | None. The conditional withdrawal form above is confined to worthless test tokens, refuses mainnet and becomes a specific refusal surface when its signer, custody proof or deployment gates are absent. It creates no cash or external claim. |
| Any way to put real money in | No card, no bank transfer, no payment processor — and the deposit rail above refuses every mainnet, so no address exists anywhere that could receive value on this product’s behalf. The one control that adds funds writes a balanced pair of ledger entries and says so on the page it lives on. |
| Custody of anything worth having | No bank, no payment rail, no counterparty — and the only chains this system will speak to are test networks, whose tokens carry no monetary value. Nothing held here is worth anything, so nothing held here is at risk. |
| An order that reaches the venue | Nothing placed here is sent anywhere. Your order reads the venue’s book and never joins it, which is also why it can never move the market it prices against. |
| Staking | Specified, not built. Its page explains validator rewards, slashing and unbonding but offers no control or APY, because no network delegation or reward source exists here. |
| A maker side, and its rebate | Your order never rests on the venue’s book, so it never provides liquidity anyone can trade against. A maker rebate would pay you for something that did not happen. |
| Proof of reserves | There are no reserves, so any ratio would attest to nothing. System status is the checkable artefact instead: it reports the ingest worker, and its endpoint answers 503 when the data path is dead. |
| A support desk, an app listing | Where a real exchange would put either of those, this site puts nothing rather than a plausible-looking substitute. |
Four things you can check right now
Everything above is a claim. These four are the ones that can be tested from where you are sitting, in about a minute each — the first three without an account at all.
Put a price side by side with the venue
Open any pair on markets and the same pair on Binance in another tab. The last price, the 24-hour high and low and the volume should agree, moving together, because they are the same numbers read from the same public feed. A pair that is quiet here is quiet there.
Read the health endpoint, not the marketing
/api/health answers 200 while the ingest worker is writing and 503 when it is not, and in the failing case it names what is carrying the site instead. It reports the data path rather than the web server, which is the only version of that check worth having. System status renders the same reading with the symbol counts beside it.
Watch the ticket refuse you before you sign in
Open a terminal and type an amount with too many decimals, or one worth less than the venue’s minimum. The error you get is the instrument’s own rule, produced by the same function the engine runs — and the button still says “Sign in to buy” rather than looking armed.
Try to take money out
Open Withdraw in the account rail. The page reads the same configuration the payout worker starts from: a closed deployment gives a concrete refusal instead of a dead button, while an open one offers a form, quotes the fee, and holds every request for one human approve-or-reject decision. Any eligible spot balance can be requested regardless of whether it came from a deposit, trade, faucet or admin adjustment. The rail remains confined to valueless test-network tokens. And the page that adds funds still says exactly what it is writing to the ledger.
What you cannot check from outside
Two claims resist checking. That the ledger balances: you can see your own balance and your own history and confirm they agree with each other, but the constraint that makes that true lives in code you are being asked to take on trust. And that the settlement rail is confined to test networks: the configuration that refuses every mainnet is just as invisible from a browser, so it is stated plainly rather than dressed up as a fifth check. Test-network requests and history can exercise the lifecycle, but they cannot prove custody of an asset with monetary value. There is no honest way around either from where you sit, and an attestation would be exactly the move this page exists to refuse. What is offered instead is that the rules are stated, the failures are loud rather than silent, and every rate quoted on this site is read from the code that charges it rather than typed into a page.
The same claims, in the running product
Two captures of this site rendering the live feed, with the evidence pointed at. Everything numbered below is a mechanism described further up this page.
- 1The headline price is the venue’sLast price and the 24-hour high, low and volume beside it, from the spot ticker stream. The one figure on this page rendered above 24px, which is the only size the display-tier market colours are legal at.
- 2Twenty levels of real depthRepublished every 100 milliseconds while this terminal is open. An order placed here fills by walking this book — deeper, at fifty levels, fetched server-side at the moment it executes.
- 3The venue’s own trade tapeNot a simulation of trading activity — these are the prints the exchange published, newest first, and the aggressor side is what colours each row.
- 4A control that does not pretendThe ticket validates tick size, lot size and minimum notional against the live instrument, and still says “Sign in to buy”. It never looks armed when it cannot act.
Captured from this product against the live venue. Any figure inside a screenshot is a moment rather than a claim about now — open the terminal and watch the same panels move.
- 1Pairs listed, counted honestlyFiltered against the venue’s live catalogue rather than its ticker endpoint, which returns every symbol ever listed. Unfiltered, this figure overstates the product roughly threefold and the table fills with delisted pairs frozen at their final price.
- 2The feed says when it is degradedA frozen number looks exactly like a stable one, so the board carries its own status rather than leaving you to guess whether the market is quiet or the socket is dead.
- 3Three numbers from one frameThe range track places the last price between the 24-hour low and high. All three arrive in the same ticker update, so the marker cannot disagree with the two figures printed beside it — which is what happens when a chart and its labels are fetched separately.
The pair count in this capture is whatever the venue was listing that day. System status renders the current one on every load.
Where to go next
Five ways in, in increasing order of scepticism.
- Learn the machinery8 lessons on the book, order types, candles, perpetuals and sizing — written to be tried immediately on a live tape.
- Every charge, with its arithmeticTwo flat taker rates, the ledger account each fee lands in, which way every amount rounds, and a worked fill computed by the engine itself.
- The API behind the pagesThe read endpoints this site is built on, documented from the route code, including all three event streams and the health check.
- System statusWhether the ingest worker is writing right now, how many symbols are on socket, and what carries the site when it is not.
- Just go and lookEvery pair the venue actually trades, priced live. Cross-check any of them against the venue in another tab.
What is stored about you
An email address, a password stored only as a hash, and whatever account activity you generate — balances, orders, fills, positions. No payment details, because nothing here takes payment, and no identity documents, because there is nothing to verify you for. Privacy covers it in full, and Terms states the same boundary in the language that binds.