LiveAgents Production Architecture

01How to read this

Every figure in this document carries where it came from. Nothing here is estimated from a diagram or recalled from a README.

Measured

MRead from the Cloudflare API, the GraphQL analytics endpoint, a D1 query against the production database, or an HTTP probe of the live endpoint. Reproducible today.

Derived

DArithmetic on measured values, or a constant read directly out of the deployed source. The inputs are always named.

Assumed

AA modelling assumption for the 100k projection. Stated explicitly, never mixed into a measured table.

The capture window matters for the traffic numbers. Cloudflare's Workers analytics were read for 2026‑09‑04 through 2026‑09‑07 13:00 UTC, and 09‑07 is a partial day (traffic to 12:50 UTC only). Latency probes are three sequential samples from a Sydney client, so the first sample of a cacheable endpoint includes the cache fill and the following two do not. That difference is itself informative and has been left in.

Two things this document deliberately does not do. It does not report a throughput number for the LiveChain consensus, because the chain reports medianCommitMs: null and has never measured one. And it does not assign a dollar figure to the Cloudflare bill, because the account carries thirty-eight other Workers and eleven other R2 buckets, and no per-project cost attribution exists.

02Deployed inventory

Six Workers carry the system. Five belong to LiveAgents proper; the sixth, agent-terminal, is a sibling product on the same zone that the exchange calls into to deploy an agent, so it is in scope for connectivity but not for the data model.

Workers

Static hosting

The React single-page app is deployed twice from the same build. Cloudflare Pages project liveagents serves liveagents.org and liveagents.pages.dev from production branch main (latest deployment 2026‑09‑07 12:47:07 UTC, commit ab4b9312). The liveagents-code Worker serves the identical bundle through a Workers Assets binding with not_found_handling: single-page-application and run_worker_first: ["/api/*"]. The exchange terminal is a third, separate bundle served from the dex Worker's own assets directory.

Container fleets

Durable Object namespaces

Durable stores

03Logical architecture

Five tiers, and only one of them holds state that matters. Workers are stateless routers and policy gates; every durable fact lives in a Durable Object, in D1, or in R2.

What each Worker is responsible for

liveagents-code is the console's API and the AI desk's scheduler. It serves the SPA from a Workers Assets binding, handles /api/* itself, mints and verifies HS256 sessions, seals user credentials with AES-256-GCM under MASTER_KEY, and owns five Durable Object classes. Its five-minute cron does no work itself — it re-arms things that a deploy can silently destroy: researcher.ensure(), scanIfDue(), sitIfDue() and runOutlets(). Every one of those was originally a Durable Object alarm, and a class replacement during deploy drops the alarm with no error anywhere.

liveagents-dex is a cache, a policy gate and a SQL relay wrapped around one container. It answers the public read endpoints from caches.default with per-endpoint TTLs chosen from how fast each value actually moves, answers the agents pages from its own D1 binding without touching the container at all, and forwards everything else. It also hosts three control paths that are not part of the public API: /__sql, /__roll and /__treasury, all behind the same SQL_TOKEN.

liveagents-chain holds no keys and no state. It routes: submissions are sticky by sender (the sender address is hashed to a validator, so one account's strictly-sequential nonces cannot be split across nodes in a round), and reads are spread across validators by a hash of the key being read so repeated polls see a monotonic answer instead of flickering between nodes at different heights.

liveagents-hedge has no route at all. Its every-minute cron pulls the zkLighter venue registry on multiples of five, lists new markets on the local book, and runs a hedging cycle in shadow mode. It writes to the exchange's D1 database.

liveagents-treasury has workers_dev = false and no route. The only way in is the dex Worker's service binding, and only for a request the exchange container signed with a shared HMAC over timestamp.body within a 300-second window. It holds the Privy application secret, the wallet authorization key and the Solana RPC URL, and it enforces its own per-request and per-day payout caps independently of whatever the exchange believes it owes.

04Physical production topology

There is no origin server, no VPS, no load balancer and no nginx. What replaces them is a distinction worth drawing precisely: which code runs in every colo the user might arrive at, and which code runs in exactly one place on earth.

The deploy-time trap this topology creates

A container instance runs the image it started with, for its whole life. The dex container is kept awake by a two-minute cron precisely so it never stops quoting — which means it also never restarts, and therefore never picks up a newly pushed image. ./cf/deploy.sh dex handles this by calling POST /__roll with the SQL token after the push; without that step a deploy builds and uploads an image that nothing ever runs. The only proof the new image is live is uptimeSec resetting at /api/health.

05Connectivity map

Sixteen edges carry everything. The diagram shows which component talks to which; the table beneath it carries the protocol, the credential and the cadence for each numbered edge, because those would be illegible written on the arrows.

06Data flows

Two flows carry the system's actual claims: an agent's order can only reach the exchange through a mandate check it cannot route around, and every fill becomes one signed transaction on a chain that does not trust the exchange.

Flow A — an autonomous order, from strategy code to the book

Flow B — a fill becomes a transaction on LiveChain

Flow C — the AI research desk

Three producers write into liveagents-code D1 and the console reads them back. The Researcher singleton walks every listed market on a Durable Object alarm, one Claude Code turn per asset in the platform's own sandbox container, 45 seconds between assets and 86,400 seconds between sweeps. The Opportunity Finder scans on the cron rather than an alarm, because a scan runs for minutes and a deploy resets a Durable Object mid-scan. The Investment Committee sits once a day: three analysts with deliberately conflicting mandates each take a turn in their own container, and a chair reconciles them into a ranked slate.

Research cost / pass

$0.09M 21 passes, $2.03 spent

Research sweep

86,400 s12 markets, 45 s apart ≈ $1.10/day

Committee sitting

$1.684 turns, 177 s wall clock, daily

Prior cadence cost

$77/daysame loop at a 90 s interval

The cost dial is RESEARCH_SWEEP_S, and the difference between its current value and its original one is a factor of seventy in the monthly Anthropic bill. That is the single most consequential tunable in the deployment, and it lives in a Worker var.

07Data stores — contents and growth

Every row count below was read from the production databases during the capture window. Together they say something the architecture diagram cannot: the write load today is almost entirely market data, not user activity.

liveagents-dex — the exchange ledger

Where the candles come from

liveagents-code — the console and the desk

liveagents-chain — the explorer mirror

chain_txs 3,450 · chain_events 1,549 · chain_rounds 1,526 · chain_trade_records 1,406 · faucet_claims 11 · chain_minutes 0. M This database is a searchable mirror, not the chain: the chain itself lives in the seven validator Durable Objects' SQLite storage. Losing this database would cost the explorer's search box, not the ledger. Note that chain_minutes has never been populated, so the per-minute throughput rollup the explorer expects does not exist.

The three constraints the D1 transport imposes on the exchange

08Measured performance baseline

Four days of Workers analytics and a set of timed probes. This is the number to compare against after any change in section 10.

Request volume, per Worker per day

Latency and error quantiles, 09-06 00:00 to 09-07 13:00 UTC

Endpoint response times, three sequential samples from Sydney

D1 workload, per database per day

09Bottlenecks and scale ceilings

Ranked by how soon each one stops growth, not by how hard it is to fix. Every one carries the measurement that identifies it.

B1 — the exchange is one container and cannot be given a second

The book is in memory, so max_instances: 1 is correct rather than conservative: a second instance would be a second exchange. That one process, on 1 vCPU, terminates every WebSocket, runs the matcher, quotes the market maker, accrues funding and checks liquidations. Measured uncached round trip is 450–506 ms steady-state, and the Worker's wallTimeP99 against it is 9.99 s.

The contention is already documented in the code's own tuning comments: quoting thirty markets a tick made the exchange answer in eleven seconds instead of milliseconds, because the matcher was queued behind the market maker. MM_PER_TICK is set to 6 and MM_REFRESH_MS to 6,000 to keep that product bounded. Those knobs bound the maker; nothing bounds concurrent user traffic.

B2 — every container query is a public-internet round trip

D1 cannot be dialled from a container, so the exchange posts SQL to its own public hostname. At capture, an endpoint with zero queries measured 76 ms and an endpoint with exactly one query measured 482 ms. M The database's own p50 is 0.22 ms, so roughly 400 ms per uncached endpoint is pure transport. This is far better than the 10–20 s it was before the IPv6 connect-timeout fix, and it is still the dominant term.

B3 — D1 read replication is off on all three databases

read_replication: {"mode": "disabled"} and no primary_location_hint on any of them. M Every read from every colo crosses to one region.

B4 — market-data writes dominate — historical, already resolved

3,974,773 rows written on 2026-09-05 M against 34 users and 1,274 lifetime trades, with the candles table holding 106,901 rows across 228 markets and nine intervals.

B5 — the chain fans out to seven objects on every status read

77,198 chain requests produced 225,210 subrequests, a 2.9× amplification. D /api/status and /api/nodes both call all seven validator Durable Objects and wait for the slowest, which is why both measure 385–430 ms while the single-node /api/supply measures 227 ms. Chain wallTimeP99 is 15.0 s, the worst in the fleet.

B6 — the consensus committee is not agreeing on state

At capture: validators: 7, online: 7, atHead: 7, behind: 0 but agreeing: 2 and inAgreement: false, with round: 2204 against lastCommittedRound: 2201. M Inspecting the nodes individually, their logRoot and logSize are identical (173460d5…, 3,453) while their stateRoot and emitted values differ. Two explanations fit: either token emission is time-derived and each node was sampled a few milliseconds apart, which is benign; or state execution genuinely diverges, which is a fork. The available evidence does not distinguish them, and medianCommitMs is null on every node, so the chain has never measured its own commit latency. Establishing that number is prerequisite to any claim about chain throughput.

B7 — the hedge Worker loses a decision cycle whenever the venue rate-limits it

68 of 2,156 invocations threw M — a 3.2% exception rate. The cause is in the exchange's own registry_syncs table: 112 of 718 syncs failed on HTTP 429 from zkLighter, 74 on /api/v1/orderBooks and 38 on /api/v1/exchangeStats. M Because the scheduled handler awaits sync(env) before runCycle(...), a 429 also skips that tick's hedging decision. All 1,518 hedge plans are mode = shadow, executed = 0, and the most recent one is dated 2026-09-06 07:12 — more than a day before capture, with the cron running every minute throughout.

B8 — forty concurrent workspaces, one shared AI credential

The sandbox fleet caps at 40 instances (7 live at capture) at 1 vCPU and 6 GiB each. M Every builder gets one container addressed by their user id, and every platform agent — researcher, finder, three committee analysts, chair — also consumes one. At 100,000 registered users even a 0.5% concurrency rate needs 500 containers.

B9 — the front-end ships nine megabytes — withdrawn

What is true: the same bundle is deployed twice, to Pages and to Workers Assets, from one build.

B10 — a deploy destroys in-flight work, silently

Replacing a Durable Object class resets the object, killing any Claude Code turn in progress and dropping any alarm it held. This has silently stopped the research feed and the committee twice. The mitigation in place is the cron re-arm pattern — sitIfDue and scanIfDue ask the database "has a session produced a result in the last day?" rather than trusting an alarm. It is a correct mitigation and it does not remove the cost: a scan or a sitting in progress at deploy time is lost, and the only signal is an empty feed.

10Scaling to 100,000 users

The load model first, stated as assumptions so it can be argued with. Then the derived demand, then the six changes that meet it, in the order they unblock each other.

The model

What the model demands

Peak REST

833 /sD 2,500 × 20 ÷ 60

Served at the colo

708 /s85% cache hit, no origin tier touched

Reaching the exchange

125 /sthe number that must not hit one container

In-flight at 450 ms

56concurrent requests against 1 vCPU today

Concurrent WebSockets

2,500on the same process that matches orders

Orders / day

34,8002,000 × 17.4

Fills / day

18,800→ 0.22 chain tx/s sustained

Ledger rows / year

42.6 M≈ 4.3 GB against D1's 10 GB ceiling

Three of those numbers are decisive. 125 uncached requests per second against a single 1-vCPU process is roughly fifty times what the measured round trip supports. 2,500 WebSockets on the matching engine is not a tuning problem, it is the wrong process. And 42.6 million ledger rows a year puts a single D1 database within eighteen months of its hard 10 GB limit, before candles are counted.

The target shape

The work, in dependency order

Changes that are cheap and should not wait for the above

• Cache the chain's aggregate reads. /api/status and /api/nodes fan out to seven objects on every call and produced 225,210 subrequests. A 2-second edge TTL on both would remove most of that with no loss of accuracy, since the underlying rounds advance no faster.
• Split the front-end bundle by route. The 1.46 MB entry chunk and the 977 KB Privy signer should be lazy imports; the 1.75 MB PDF should not be in dist at all.
• Catch the venue 429 in the hedge Worker so runCycle still runs, and back off rather than retrying on the next minute.
• Measure the chain. medianCommitMs is null on all seven nodes. Until that number exists, 0.22 fills/second is an untested claim.
• Turn on traces and Logpush (observability.traces.enabled is false on all five Workers, logpush is false) and alert on: research feed idle > 25 h, committee idle > 25 h, chain inAgreement: false, dex pendingWrites > 0, and registry sync failure rate.

11Security

Twelve findings against the deployed configuration and the deployed source. Two are critical, four are high. Key material is described by its structure below, never quoted.

The security model that is working

Worth stating first, because the findings below should not obscure it. A user's strategy runs in their own container and is handed no exchange credential and no route to the exchange; POST /strategy/tick returns intents, and the Worker prices them, checks them against the mandate and only then places an order. The treasury holds the signing credentials and the exchange does not, so a compromise of the exchange container can queue payout requests the treasury refuses and can read no key. The container disk is discarded on every sleep and the workspace lives in R2, which is what makes it safe to give a language model a shell inside. Session tokens are never accepted from a query parameter. Passwords are PBKDF2-SHA256 and user credentials are AES-256-GCM sealed under a Worker secret. All of that is real and verified in the deployed code.

Findings

12Operations

Deploying

./cf/deploy.sh              # everything
./cf/deploy.sh web          # the SPA, to Pages
./cf/deploy.sh code         # code.liveagents.org
SQL_TOKEN=$(tr -d '\n' < ~/.config/liveagents/dex.sql_token) ./cf/deploy.sh dex

The dex line is not optional decoration. Pushing a dex image does not restart the container, and the two-minute cron means it never restarts on its own, so without the roll a deploy uploads an image that nothing runs. The roll is POST /__roll with x-sql-token. The only proof the new image is live is uptimeSec resetting at /api/health.

Verifying a deploy

curl -s https://code.liveagents.org/api/health   | jq   # claudeAuth, icp mode
curl -s https://dex.liveagents.org/api/health    | jq   # uptimeSec, pendingWrites
curl -s https://dex.liveagents.org/api/chain/status | jq # backlog must be 0
curl -s https://chain.liveagents.org/api/status  | jq   # inAgreement, round vs committed
curl -s https://code.liveagents.org/api/research/status | jq
curl -s https://code.liveagents.org/api/committee/status | jq
node cf/bin/verify-fill-records.mjs                     # third-party fill check

Traps that have already cost time, and the rule each one produced

Open defects at capture

• Treasury non-functional — TREASURY_HMA versus TREASURY_HMAC. Finding S3.
• Hedger has produced no plan since 2026-09-06 07:12, with the cron firing every minute since. All 1,518 plans are shadow-mode and unexecuted; open interest is currently zero across all 226 positions, which is a plausible benign cause but is unconfirmed.
• 112 of 718 registry syncs failed on HTTP 429 from zkLighter, and each failure also skips that tick's hedge cycle.
• Chain reports inAgreement: false with 7 of 7 at head and only 2 sharing a state root. Log roots are identical across nodes, so this may be time-derived emission sampled at different instants rather than a fork — unresolved, and medianCommitMs is null so there is no latency data to reason with.
• Four SPA pages call a dead origin. Finding S9.
• chain_minutes has never been written, so the explorer's per-minute throughput rollup does not exist.
• PRIVY_APP_ID is stored as a secret on the dex Worker and as a plaintext var on the code and treasury Workers. It is public by design; the inconsistency is harmless but it inverts exactly the classification that matters in S1.

13Remediation

Applied and deployed on 2026-09-08. Every line below was verified against the running system, not against the diff.

Security

Correctness — the chain was not converging, and now it cannot diverge further

Section 9 left B6 unresolved between two explanations. Arithmetic settles it. Every difference in emitted between the seven validators is an exact whole multiple of one emission payment of 6,341,958,392 — the nodes sat 0, 1, 2, 3, 4, 18 and 20 payments apart while six of the seven agreed on an identical logRoot. M

The cause is in the commit path: payEmission ran once per execution of a commit rather than once per round. A validator that was evicted and caught up re-executed rounds it had already paid for, and paid again. That makes the ledger a function of how often a node happened to run the commit path instead of a function of the log, so the state root can never converge.

Emission is now guarded by the round: re-executing pays nothing, and a node that skipped rounds pays for each of them, so the total depends only on how far the chain has committed. Three fresh rounds were driven through the committee after deploying, and the spread stayed at exactly 20 payments where it would previously have grown. All eight offline suites pass.

Performance

Also changed

• D1 read replication is on (mode: auto) for all three databases, and the code paths that can tolerate a moment's lag now read through a session. The exchange's SQL relay carries a bookmark in both directions, so its reads may be answered by a replica while a read issued after a write still cannot see less than that write — a ledger cannot be eventually consistent with itself. No latency improvement is measurable from Sydney yet; replicas are provisioned over time, and the change is correct either way.
• The hedge Worker no longer loses a cycle to somebody else's throttle. The venue pull is wrapped so a 429 cannot skip the hedging decision that followed it, and a refusal is remembered for one cron period instead of being walked into again. This addressed 112 of 718 failed syncs and the 3.2% Worker exception rate.
• An authenticated request is no longer a D1 write. Adopting a user named by an external token was an unconditional upsert on every call, which priced every authenticated request at a write to the primary region to insert nothing. It reads first now.
• Nothing that carries a credential is cached, as a guard that does not depend on the endpoint list staying correct.

Left for the operator, as of the first pass

1. Rotate the Privy wallet authorization keypair. The private half sat in a readable configuration field and must be assumed disclosed. Removing it from the variable does not undo that, and the rotation happens in Privy, not here.
2. Decide how the chain converges. Reset and lose the fill records, or reconcile state from a quorum. Doing nothing leaves seven validators permanently disagreeing on a state root while agreeing on every transaction.
3. Finish or retire the four legacy pages. Marketplace, Channels, BuildAgent and the trading-brain panel now point at the console Worker, which does not implement their endpoints. They report "not available" instead of a gateway error, which is honest but is not the same as working.
4. Delete the api.liveagents.org record. Nothing ships a reference to it any more, but the hostname still resolves and still answers 502, and this deployment's token has no DNS write scope.
5. Move the shared JWT secret to asymmetric signing if the console and the main API are to keep one identity. Shortening the token life and adding revocation reduced the blast radius; it did not remove the shared secret.

Second pass — 2026‑09‑09

Every one of the twelve findings was re-run against the deployed system rather than against the note above. Nine were confirmed still fixed. Three had been left short, and are closed below. One is prepared and deliberately not taken.

Where the twelve stand now

S12 — the work factor could not go up, so the hashes went away instead

Workers cap PBKDF2 at 100,000 iterations. That is a platform ceiling, not a setting, and it is well under what OWASP asks of the primitive. An offline attack needs two things though, the hashes and the work, and only one of them was fixed.

The password is now HMAC'd under a Worker secret before it reaches the KDF. A stolen users table is no longer enough to guess against: the attacker also needs a value that is never in the database, never in the repository and never in a query result. It costs one HMAC per sign-in. Two schemes exist and both verify, so nothing was invalidated: a legacy record is rewritten under the pepper the next time that password is used successfully, which is the only moment the plaintext is in hand. With no pepper set the behaviour is exactly what it was, so a missed secret degrades rather than locking every account out.

The trade is stated rather than hidden. Losing the pepper invalidates every peppered password, and they can only be reset, not recovered.

a synthetic pre-pepper record: login 200, stored scheme pbkdf2$ → pbkdf2p$, login again 200 wrong password on a peppered record: 401

S4 and S10 — the relay signs now, and the token stays home

The exchange authenticated to /__sql with a static bearer token, over the public edge, on every query. That made the credential carrying full read and write on the ledger the single most transmitted secret in the system, and it is why S10's unrestricted egress mattered: the shell that could read a token was the shell that could reach the control plane.

It signs now. HMAC‑SHA256 over timestamp.body under the same token, verified inside a five-minute window, compared in constant time. The key never leaves either end. This is the construction the treasury already demanded of the exchange, so there is one idea in the system rather than two. The token was rotated before the change, so the value that spent months on the wire is already dead.

The window bounds a replay to five minutes rather than for ever, and does not prevent one inside it. That residue is deliberate: a nonce store would put a write on the hot path of every query the matcher runs, to defend against a request an attacker must already be positioned to capture and can only repeat, not alter.

bearer token /__sql 403 /__treasury 403 /__roll 403 good signature /__sql 200 → {"results":[[{"ok":1}]]} bad signature 403 · 10-minute-old timestamp 403 · body swapped after signing 403 the exchange, which signs: health, markets, live, buybacks, chain/status all 200 in 0.46-0.53 s

S11 — something looks now

S11 was never that the system lacks logs. It was that nobody reads them, and three failures ran for an unknown length of time in plain sight because of it. So this is not a logging pipeline. It is five checks that assert the things whose failure has actually gone unnoticed here, on the clock the platform already has, with the answer written down.

Three rules it follows. A check that cannot run is recorded as failing, because "I could not tell" and "it is fine" are the same silence that hid S3. Each row carries the time its verdict last changed, so the endpoint answers for how long rather than only now — which is the question S3 could not answer. And it runs unconditionally, with no admin switch, because a monitor that can be paused from inside the thing it monitors is not a monitor.

The dex Worker also grew /__treasury/health, an unauthenticated boolean saying whether the money path is configured at all. S3 stayed dead partly because the only way to ask required the container's own credential. This forwards an unsigned probe and reports which refusal came back: the treasury turning down an unsigned caller is healthy, and the treasury refusing on its own configuration is the failure. No secret goes in and nothing but a boolean comes out.

What the exchange taught, the expensive way

Left for the operator, revised

1. Rotate the Privy wallet authorization keypair. Still the most important item, and still not done: the public half in the configuration is byte-identical to the one committed when the private half was moved out of it, so the disclosed key is the live key. It is also cheaper than it looks. Privy fixes a wallet's owner at creation, so replacing the key means replacing the wallet, and that only costs something if the wallet holds something. It does not: checked today, the treasury address holds 0 SOL and has no token accounts. cf/treasury/rotate-auth-key.mjs generates the replacement pair in the two encodings the two sides want, asserts their DER shapes, and prints the rest of the runbook. It needs the Privy app secret, which is write-only in Cloudflare and therefore yours.
2. Decide how the chain converges. Unchanged. Reset and lose the fill records, or reconcile state from a quorum. The watchdog now reports the disagreement every five minutes instead of nobody noticing, which is not the same as fixing it.
3. Give the watchdog somewhere to shout. It records every verdict and would post a change to ALERT_WEBHOOK; no destination is set, so a failure is written down and not delivered. One secret closes this.
4. Delete the api.liveagents.org record. Unchanged, and confirmed today: still resolves, still answers 502, still a dangling-origin takeover candidate. This deployment's credential carries zone:read and no dns_records:write, so the record cannot be read or removed from here.
5. Finish or retire the four legacy pages. Unchanged.
6. The shared JWT secret has largely lapsed rather than been fixed. The second holder was the Fastify API on the decommissioned VPS, which no longer runs. The repository still carries that service and still configures it with the same secret, so the finding is dormant rather than closed: it comes back the day anyone starts it.

First captured 2026-09-07 between 12:45 and 13:05 UTC against Cloudflare account 051b311d9fa20814264dea2f40b27608, the three production D1 databases, and the deployed source at commit ab4b931; remediated and re-measured 2026-09-08 between 23:00 and 00:40 UTC. Latency probes originate from Sydney and will differ from another vantage point. Every table states its own provenance; nothing in this document was estimated from a diagram, and three findings were withdrawn or corrected when closer measurement contradicted them.

14LiveChain in one page

A settlement ledger for one venue, not a general-purpose computer. There is no virtual machine and no bytecode. A fill, an order, a cancel and an attestation are native transaction types with named fields, which is why the explorer can show a trade and a light client can prove one.

Chain id

4444LiveChain, ticker LIVE, nine decimals

Committee

750,000,000 LIVE staked each, 350M total

Quorum

2f+1233,333,333.333333334 LIVE of stake

Finality

3 roundsthe chain's own claim: typically under half a second

Supply

10,000,000,000LIVE, fixed at genesis, nothing minted after

Base fee

0.0002LIVE floor, burned rather than paid out

Three design choices carry most of the weight, and each one is a direct answer to something a trading venue needs that a general chain does not.

References are votes. Every validator proposes one block per round that names a quorum of the previous round's blocks as parents. Those parent references are the entire voting protocol. There are no separate vote messages and no certificates on the wire, so a validator's bandwidth goes almost entirely to transactions instead of consensus chatter. Adding a validator adds throughput rather than subtracting it.

The mempool is sealed. A trader submits an order encrypted to a future consensus slot. The DAG orders the ciphertext without being able to read it, and only once the position is fixed does the committee release the key that opens it. Sequencing cannot depend on content, so the sandwich attack has nothing to stand on. Section 16 covers the scheme, and section 19 records that this path has not yet been exercised in production.

State is provable, not merely stored. Every committed transaction is appended to a Merkle Mountain Range and every account lives in a sparse Merkle tree, and both roots go into the block header. A counterparty holding nothing but a header can check a balance or a fill against a short proof. For a venue that is the difference between a receipt and a database assurance.

15The DAG and the Helix commit rule

Helix sends no messages. The DAG already contains every vote that will ever be cast, and Helix is the function that reads a total order out of it. That is the whole reason the design scales with committee size.

Equivocation is evidence, not an error

Two blocks by the same author in the same round are both validly signed, so a node cannot simply reject one. The DAG keeps the first it saw and retains the second as proof: a pair of conflicting signed headers is checkable by any third party, and it is what the slashing path spends. From that moment the author is excluded from quorum counting, so the rest of the committee converges even though two honest validators may have seen different halves of the equivocation first. The live chain reports equivocations: 0 on every node.

Why the header and the body travel separately

Peers exchange headers, notice a parent they do not hold, and fetch only that body. The header commits to the body through txRoot, so a peer cannot answer a body request with different transactions than the ones the author signed. On a DAG where each block references a quorum of the last round, header-only gossip is most of the traffic.

Consensus parameters

16Cryptography

Six primitives, each chosen for one property the protocol depends on. Nothing here is a default picked for familiarity, and the reasoning is written into the source files rather than left implicit.

The three details that stop a subtle break

Rogue key defence. Aggregating BLS signatures over the same message is unsafe on its own, because an attacker who chooses their key as the group generator minus the sum of the honest keys can forge an aggregate nobody signed. Every validator registers a proof of possession, a signature over its own key under a separate domain, and aggregate verification refuses to run against keys that have not been checked.

One encoding per structure. A signature is over bytes, so two encoders that can produce two encodings of the same block let two honest validators disagree about whether a signature is valid. JSON cannot promise a single encoding: key order, number formatting and whitespace are all free. Everything hashed or signed goes through a deterministic codec with fixed-width little-endian integers, shortest-form varints and length-prefixed byte strings. The decoder is strict, and a redundant continuation byte or a trailing byte is an error rather than something to shrug at.

Addresses hash the key. An address is BLAKE3 of the public key with a scheme tag, rendered as bech32m under the prefix live, so a mistyped address fails its checksum instead of sending LIVE into a hole. Hashing rather than using the key directly means an account can rotate to a different signature scheme later, post-quantum included, without changing its address, and the public key is not on chain until the account first spends.

Unpredictable leaders

The leader schedule is drawn from an epoch randomness beacon, which is a threshold BLS signature over the previous epoch's commit root. That matters for a trading chain specifically. If leaders were predictable, an adversary could aim a denial of service at the validator about to sequence the market's busiest second. Nobody knows more than one epoch ahead, and the beacon cannot be biased by a minority, because any 2f+1 produce the same value and fewer than that produce none.

17Transactions, state and fees

Nine transaction kinds, all native. A fill is roughly 120 bytes with named fields, validated by the protocol, indexed by the node and provable to a light client, rather than an opaque blob that a virtual machine on the hot path would have to interpret.

Two fields that do more than they look

validUntil is the last round at which a transaction may be included, and the protocol enforces it on every kind. An order that misses its window dies rather than lingering in a mempool and executing later at a price its author never agreed to. nonce is strictly sequential per sender, which makes a replay arithmetically impossible rather than merely unlikely, and it is the reason the gateway routes submissions sticky by sender: one account's nonces cannot be split across two validators in the same round.

Execution is a receipt, even when it fails

The state transition function has no clock, no randomness, no input and output, and no floating point. The round number and the block author arrive as arguments precisely so nothing has to reach for an ambient value. A rejected transaction is not an exception, it is a receipt with a reason, and the sender still pays, because a transaction that was gossiped, ordered and executed consumed the same resources whether or not it did what its author hoped. That is what stops a free denial of service through deliberately failing transactions.

Balances are bigint in nano LIVE throughout. Ten billion LIVE at nine decimals is 10²⁸ nano, about ten million times past the point where a double silently rounds.

The fee market and the emission schedule

The base fee is burned rather than paid to validators. If validators received it they would have a reason to manufacture congestion, and on a chain whose users are trading algorithms that would show up as a spread. What a validator receives is the tip the sender sets, plus its share of the emission. The burn also gives LIVE a sink proportional to how much the chain is used, which at the time of capture amounted to 0.4796 LIVE destroyed across 4,302 committed transactions.

18How the chain runs on Cloudflare

Seven Durable Objects, one Worker in front of them, and one D1 database that holds nothing the chain needs. The awkward parts of this deployment are all consequences of a Durable Object being evictable and a location hint being honoured only once.

Geography is fixed at genesis

Each validator is env.NODE.idFromName("validator-k") fetched with a location hint, and the hint is honoured only when the object is first created. That is exactly right here: it fixes the committee's geography once and leaves the seven nodes spread across enam, wnam, weur, eeur, apac, sam and oc, seven regions on three continents. A DAG protocol takes its latency from the 2f+1 quantile of the round-trip matrix, so spreading the committee is the difference between a network that survives one region going dark and one that does not. It also means the placement cannot be changed later without recreating the objects, which would recreate the chain.

Three routing rules in the gateway

• Submissions are sticky by sender. The sender address is hashed to one validator, so an account's strictly sequential nonces cannot be split across nodes in a round.
• Reads are spread by key. Sending every read to one node makes that node the busiest in the committee while it is also trying to take part in consensus, and it was the first thing to fall over under load. The node is chosen from a hash of the key being read, so repeated polls for the same transaction see a monotonic answer rather than flickering between nodes at different heights.
• A miss widens, a hit does not. A validator that was evicted comes back behind, and if that node answers a read then a transaction the rest of the committee committed a second ago looks pending, which to a caller polling for their own trade is indistinguishable from the chain being stuck. So a lookup that would return "not yet" asks one other node, chosen by hash rather than fanning out to all six.

The chain's own D1 schema

19Measured chain state, and one divergence still open

Probed from Sydney on 2026‑09‑09. All seven validators are online, all seven are at the head, and all seven agree on the committed transaction log. No two of them agree on the state root.

Round

2,499last committed 2,496

Committed txs

4,319log size 4,302 leaves

Accounts

27allocations, validators, and users

Online

7 / 7at head 7, behind 0

Base fee

200,000nano LIVE, sitting on the floor

LIVE price

0.045115USDT, sourced from LiveAgents

Gateway latency, three sequential samples from Sydney

The state root divergence

Reading /api/nodes gives one row per validator. The committed log is identical everywhere: the same logRoot, the same 4,302 leaves, the same total burned. The state root is different on all seven, and the differences track emitted exactly.

Both findings are reproducible right now against chain.liveagents.org/api/nodes, which is why they are recorded here rather than in the remediation log above. Nothing in this section changes the standing of Part I: the platform findings of 2026‑09‑08 were fixed and verified, and these two are chain-level and still open.

20Scaling to 10 million, and what it costs

The 100k model in section 10 contains an arithmetic error that inflates every downstream number. Corrected, ten million registered users need roughly twelve thousand concurrent sockets, not a quarter of a million, and the bill lands near four figures a month. The thing that breaks first is not throughput and not cost. It is storage, and only if the ledger stays in one database.

Concurrency, derived rather than assumed

Concurrency is not a percentage you pick. It falls out of how many people show up and how long they stay, which is Little's Law: average concurrent sessions equal daily active users multiplied by average session length, divided by the length of the day.

Ten million registered users produce about 12,500 concurrent sockets. The websocket hub was measured on 2026‑09‑09 at 20,000 connected clients, where one fan-out flush costs 1.1 µs and one account update 0.3 µs. The steady state at ten million users is already inside what one indexed hub handles, before any sharding.

What ten million users actually demand

425 GB a year is the only number here that is fatal to the current shape. D1's ceiling is 10 GB per database, so a single ledger database is exhausted in nine days at this rate. Split across per-user Durable Objects it is 42.5 KB per account per year against a 10 GB per-object limit, which is four orders of magnitude of headroom. Sharding the ledger by user is not an optimisation at this scale. It is the only thing that makes the scale reachable at all.

The bill

Cloudflare meters this workload on six lines. Rows written dominate, at $1.00 per million, which is why the market maker writing nothing is worth more than it sounds.

A Command-log entries are batched at 50 commands per row and queue messages at 100 fills per message, both of which the migration plan requires; unbatched, the command log alone would add roughly $100 a month. Duration assumes WebSocket Hibernation, so a fan-out object holding idle sockets is not billed for wall-clock time. If the terminal kept polling at 20 calls a minute instead of taking live data over its socket, Worker requests rise from $108 to about $1,080 and the total roughly doubles.

What actually breaks, in order

21Security re-review — 2026‑09‑10

The twelve findings of section 11 were re-checked against the deployed configuration today. Eleven are closed and verified. One is still open and still critical, for a reason worth stating precisely: it was relocated, not rotated. Three further findings are added, one of them a market-integrity defect in the matching engine that the golden tests turned up.

Verified closed today

What the ten-million shape changes about the threat model

Two things get better and one gets worse. Per-user AccountDOs mean a user's balances live in storage that no other user's request can address, which is a stronger boundary than a shared table behind a shared credential. Retiring /__sql removes the single credential that today opens the whole ledger to anyone who captures a signed request inside the replay window.

What gets worse is the blast radius of the matcher. One Durable Object per market owns that market's book with no second instance to disagree with it, so a defect in the ported engine is a defect in the only copy. That is the argument for the golden sequences being the gate on the port rather than a test written afterwards, and for N1 above being fixed in the port rather than carried into it.