Quiver

The verifiable risk brain for autonomous agents. Twenty-two priced quantitative computations an agent calls over HTTP, pays for in-band with x402, and discovers through the ERC-8004 trustless-agent registry. No chat, no human in the loop. Every deterministic answer arrives with a proof you can re-derive yourself.

• Live endpoint: https://quiver-production-c3a8.up.railway.app — /build and /paper are free; the paper is also served as plain markdown in seven AI-readable parts at /paper/1 … /paper/7

• Free MCP: https://quiver-production-c3a8.up.railway.app/mcp — Streamable HTTP, the nine risk-brain tools, fair-use daily quota; on the official MCP registry as quiver-risk-brain

• On-chain identity: ERC-8004 agent #5152 on X Layer (eip155:196) · Build: q1-e1fa99d08887d6cc

• Payment (dual rail): x402 v2 exact — USD₮0 on X Layer (OKX facilitator) and USDC on Base (Coinbase CDP facilitator); 0.005–0.05 per call

• Availability, measured from outside: status page (JSON) — hosted deliberately off the service it watches, so the record survives an outage

• Use it in five minutes: QUICKSTART.md · framework snippets: INTEGRATIONS.md

• Launch thread, with the demo video: x.com/Quiverrrs/status/2080225222880526720

At a glance

Related MCP server: zarq-risk-intelligence

Since the deadline

The submission closed on 28 July 2026 and judging runs after it. OKX confirmed that during judging they cannot go back and forth resolving errors: if the service breaks while being scored it simply comes back empty. Our own redeploys were expected to take up to three minutes before the new container serves, so the original plan was to build everything without deploying at all.

That plan changed. Thirteen deploys have shipped since the deadline, and eleven of them have a recorded darkness figure. The table below is the file-backed part, from gates/deploy-log.tsv, which the watchdog writes and nothing edits by hand; the three that predate the file are reconstructed in docs/deploy-manifest.md, and the two that have no figure at all are named as such rather than left to look measured.

The three-minute estimate did not survive contact. Eight of the nine were measured and seven of those eight were 0 seconds — the service answered every poll straight through the container swap. The single 11-second window was the first deploy, before any of this was instrumented. Deploy 3 has no figure.

The log is why the later figures exist and the early ones partly do not. gates/deploy-log.tsv carries one row per completed deploy and is never backfilled, so its evidence begins at deploy 4; docs/deploy-manifest.md reconstructs the three before it from commit timestamps, and for deploy 3 that reconstruction yields no darkness figure at all. The watchdog also requires a marker only the new build can produce, and refuses to start if that marker is already true — otherwise the watch passes instantly and reports nothing.

Two of these deploys fixed things a reviewer would have hit directly. Deploy 6 and 7: every proof published snarkjs plonk verify <key> publicSignals proof — the verification key is published at /proof/vk/<circuit>. That endpoint returns the key wrapped, so a reviewer following the sentence verbatim got Cannot read properties of undefined (reading 'toUpperCase') on a proof that was perfectly good. Deploy 8: the 402 challenge told payers to build their EIP-712 signing domain from {"name":"USDT","version":"2"}, and the token's own domain is {"name":"USD₮0","version":"1"} — so every signature a buyer built from our own challenge was rejected by the token, on the rail the ERC-8004 identity lives on. Base was checked in the same run and was correct. Both were found by buying from the deployed service rather than by reading the code, and gates/preflight.mjs now rebuilds the signing domain from config and compares it to the chain, per rail, treating an unreadable token as a failure rather than a skip.

After deploy 8, all 22 services were bought with real funds on that rail to prove it end to end. The first settled on chain in under five seconds. Billing reconciles exactly at the published per-service prices, which are not flat; a rejected request is not billed, and a 200 carrying a refusal is not billed either. docs/deploy-manifest.md carries the evidence table.

The machine-readable paper stays at exactly seven parts, because the submitted entry hardcodes seven URLs. That has held through every change, and npm run gate:y now checks the section-to-part mapping rather than the part count, because a section can move between parts while the count stays at seven.

A second circuit: the Kelly sizing identity

The honest cap on this project has moved and the number is worth stating precisely rather than rounding in our favour. Seven of the eight deterministic services now emit a Plonk proof — perp-gate, size-gate, treasury-risk, exec-verify, event-vol, lp-risk, options-risk — measured against the deployed container, not against local code, because those two disagreed until deploy 5. The eighth, risk-attest, is answered rather than missing: its response publishes every leaf, so set-exactness is 2N-1 hashes and a circuit adds nothing. The other fourteen of the twenty-two are observation services, and no proof of arithmetic reaches what they are actually claiming — that a number came from a venue. Two can attest their inputs today, three more could because they read chain state and a block stateRoot already commits to it, and eight have no mechanism at all. That last group is a TEE or zkTLS problem, not a proving problem, and it is the honest end of this road.

An eighth circuit exists, is correct, and is not served. lpclosed certifies lp-risk's headline — EIL = exp(−v/8) − 1, where lpbracket certifies the breakeven beneath it. The identity is exact, 2√r/(1+r) − 1 being sech(ln r / 2) whose expectation under the martingale lognormal is exp(−v/8), and the circuit proves and verifies in 2.7 seconds on a development machine. On the deployed container the prover exits with a kill signal every time: a 16.6 MB proving key at Plonk domain 8,192 against the memory this host has, while lpbracket at 7.1 MB proves there without trouble. It is withdrawn from the served paths rather than left returning an error, because the prover worker is shared and a crash per request endangers the proofs that do work. The circuit, its artifacts and its gate are all in the repository, and docs/pending-deploys.md records what serving it would take. size-gate is the second, chosen because it is the smallest: the discrete Kelly criterion f* = (p(b+1) − 1)/b cross-multiplies to a single polynomial identity, where the liquidation identity needed a division cleared through three factors of SCALE.

Three gates, each able to fail:

node zk/scripts/gateB0-kelly.mjs        # proves, verifies, and refuses all 5 perturbed signals
node zk/scripts/gateB1-kelly-sweep.mjs  # 4,000 bets through the real engine; bound never violated
cd zk && npm install                    # solc + an in-process EVM, gate-only, never shipped
node scripts/gateB2-kelly-evm.mjs       # Solidity verifier in an EVM: accepts, then refuses 6 ways

The first two run against a fresh clone with no extra install. The third needs zk/package.json's dependencies, which are deliberately not in the service manifest: solc and an in-process EVM rehearse a verifier, they never answer a request, and the thing that serves traffic should not carry them.

That paragraph is a correction. An earlier version of this section said all three were "runnable from a clone", and none of them was. Every script under zk/scripts imported the engine as ../../hackathon/veritape/src/..., which is a path in the author's working tree and does not exist in this repository, so all five gates — including gate2 and gate3, cited elsewhere as re-runnable rehearsals of the on-chain registry — died with ERR_MODULE_NOT_FOUND for anyone who cloned it. The proving key and witness wasm were missing too: the repo shipped the verification key and the gate results, but not the artifacts needed to reproduce those results. Verifiability from a clone is the load-bearing claim of this whole project, and it was untested, so it drifted.

node zk/scripts/gate-clone-portability.mjs   # the check that was missing

It refuses two failure modes specifically: a local module that cannot be resolved, and a build artifact that is not in the checkout. It does not demand that every gate pass, because gate3 talks to a live chain and a network failure is not a portability failure. Proven able to fail by pointing one gate back at the old path: it goes red on three counts and names the offending file.

Gate B1 failed the first time it ran, and that is the point of it. 3,997 of 4,000 sampled bets blew the residual bound by a factor of about a thousand. The cause was not the circuit: sizeGate publishes fullKellyFraction: round(fullKelly, 6), so certifying the served number would have proved an identity about a bet up to 5×10⁻⁷ away from the one actually sized — five hundred grid steps, and exactly the factor of a thousand observed. This is the same defect class the liquidation circuit hit when the engine handed back round(M, 2) for margin. The witness now recomputes the fraction at full precision from the snapped inputs, with a guard that refuses to certify at all when the result drifts past the six decimals the answer is published at. After the fix: 0 violations in 4,000, tightest case using 0.9997 of the bound — tight rather than generous, which is what makes it worth proving.

Those two constraint counts are now read from the artifacts by zk/scripts/circuit-facts.mjs rather than written down. They used to be literals: the gate recorded plonkConstraints: 718 by hand, and this table said "357 R1CS", which is circom's non-linear count and not what the .r1cs file holds. The literal was right and the label was wrong, and neither was ever compared to the file it described, which is the only part that mattered.

Not yet shipped, stated plainly: the live size-gate service does not serve these proofs and no Kelly verifier is deployed on chain. Both need either a deploy or gas, and neither is worth the risk while reviewers are testing. This is exactly what the paper said about the liquidation circuit before it shipped: built, and verifiable from a clone.

Answering the wrong question correctly

Agent #5152 holds twelve on-chain reviews: ten at five stars and two at half a star. Both bad ones are from the same reviewer agent, and its own comments say what happened.

"Wrong endpoint: options-desk can't do Aave health checks. No deliverable." "Delivered crypto options/vol data, not the Aave health check that was requested"

It wanted a lending-protocol health check and called options-desk. Two other agents ran the same Aave task through protocol-pulse and scored it 5.0 and 4.8, so the capability was there and working. The reviewer picked the wrong service out of twenty-two, and Quiver had no way to say so. Read it yourself: onchainos agent feedback-list --agent-id 5152.

It failed twice, in two different ways:

The second is the dangerous one. A service that answers the wrong question correctly looks, from outside, exactly like a service that is wrong.

src/util/routing.js closes both. It scores the request against all twenty-two services on two signals kept deliberately apart: shape, meaning which required keys the body carries, which is a fact about the service; and words, meaning vocabulary overlap, which is a guess and is weighted as one. A refusal now names the service that fits and gives the exact call to retry. A success that looks mis-aimed carries a routingNotice beside result and proof — never inside either, so the content hash is untouched and every published proof still reproduces.

The case that took a second attempt to catch is call 2: the body satisfied options-desk completely and carried protocol, a key options-desk has never heard of and protocol-pulse requires. A foreign required key in an otherwise valid body is the signature of a mis-route, and the first version of the detector missed it entirely.

npm run gate:r   # replays both of MantaRay's calls and requires the signpost

Six checks. Two replay the reviews. The other four are the half that can fail: an ordinary options request must not be flagged, all twenty-two services must leave their own minimal valid requests alone, an empty body belongs to the validator rather than the signpost, and hard evidence must outrank weak evidence. Proven able to fail by a scripted revert: with the detector stubbed out, 2 of 6 go red.

Quiver never reroutes a paid call. You asked this endpoint and this endpoint answered. The signpost exists so a caller can tell a wrong shop from a wrong answer, which is precisely the distinction the two half-stars failed to make.

Portfolio proofs: the wide circuit was the wrong question

portfolio-gate reports the leg nearest liquidation, a minimum over legs. Proving a minimum inside one circuit forces every leg into one evaluation domain, and a leg is the liquidation circuit at 1,301 constraints, so the ceremony file on hand caps it at three. The obvious answer was to fetch a bigger file. Both halves of that turned out to be wrong.

The file is not big: 2^14 is 18.1 MB, not the "gigabytes" an earlier draft of the plan claimed. But zk/scripts/domain-scaling.mjs measures proving at domain^1.01, so twelve legs would take about 5.7 s and break the roadmap's own three-second abandon threshold. A bigger file moves the wall.

So zk/scripts/gateB6-portfolio-routes.mjs measured the alternative: prove each leg separately and let a contract take the minimum on chain. A Plonk proof is constant size and constant verification cost whatever the circuit behind it, which is the fact the whole comparison turns on.

Both gas figures are single samples: zk/scripts/probe-plonk-gas-variance.mjs measures a 1.26% spread across identical statements, and the 11-leg row moves by about 9,000 gas between runs. The wide figure is read from zk/build/gateB8-2-portfolio-evm.json rather than written down; an earlier draft of this table said ~273,118, which matched no artifact in the repository.

The 10.1× gas that looked like the deciding trade is worth about five hundredths of a millicent on this chain. One invalid leg reverts the whole call, because a minimum over whatever happened to verify is not a minimum.

And the minimum that call takes is over the liquidation PRICE, not over the distance to it. This table used to end "the contract picks the right leg", which was wrong and the gate's own check could not catch it — it compared the router against the router's own rule. On this eleven-leg book the price minimum is leg 3, 24.089% from liquidation; the leg portfolio-gate reports is leg 10 at 6.103%. liquidation.circom publishes no mark, so that router cannot be corrected in place. The gate now measures the aggregation shape and asserts its own limit — npm run gate:b6-revert in zk/ restores the old claim and the gate goes red. The portfolio minimum is proved instead by zk/scripts/gateB10-portfolio-perleg.mjs over zk/circuits/portfolioleg.circom, which publishes the adverse-distance numerator and the mark and ranks them by cross-multiplication on chain. Full write-up: docs/fix-gateb6-ranking.md.

Nothing is deployed; CertifiedPriceMin.sol exists only inside that test.

Three more circuits: treasury, LP divergence, execution

Tier 1 of the completion plan. The proof layer now covers five of the twenty-two services and five of the nine that have a deterministic path. Every size below is read from the artifact by node zk/scripts/circuit-facts.mjs, not written down.

Nine gates, three per circuit, all runnable from a clone (the EVM ones after cd zk && npm install):

node zk/scripts/gateB3-1-concentration-sweep.mjs   # 4,000 treasury books through the real engine
node zk/scripts/gateB4-1-divergence-sweep.mjs      # 4,000 price ratios, 1/100x to 100x
node zk/scripts/gateB5-1-constantproduct-sweep.mjs # 3,595 pools across seven orders of magnitude
node zk/scripts/gate-clone-portability.mjs         # and the check that all of the above still run for you

A square root is proven, not computed. lp-risk rests on IL = 2√r/(1+r) − 1, and circuits do not take roots. So s arrives as a witness, the circuit forces s² = r·S and pins it non-negative so the other root cannot be substituted, and the identity then cross-multiplies to L̂·(S + r̂) = 2·S·ŝ with no division left. The gate refuses a wrong root, and refuses the negative root offered as a field element, because that second one is the whole reason the bit decomposition is there.

Every bound is tight, because a loose bound is not evidence. The concentration circuit shipped with 2|R| ≤ 4S on a derivation that counted two rounding sources. The sweep put the worst of 4,000 real books at a quarter of it, and the derivation was simply wrong: Σŵ² is computed from the snapped weights, so weight rounding changes which book is described rather than how well the identity holds for it. The bound is now S, and the worst case uses 0.9986 of it — which upgrades the claim from "near the right index" to "the correctly rounded Herfindahl index of the published shares". Measured, then tightened, in that order.

What the three sweeps caught. All three failed at least once, which is the only reason their green results are worth anything:

• toScaled in the shared kit read BigInt(Math.round(snap(x) * 1e9)) — the exact scaled product its own comment warned against. Harmless for a probability; at an AMM reserve of 8.03e8 the double has a granularity of 128, so the encoder was off by up to sixty-four grid steps. Now assembled from the decimal string, exact at any magnitude.

• The constant-product encoder computed y − x·y/(x+in) where the engine computes (y·in)/(x+in). Algebraically identical, numerically not: the first cancels two large numbers to leave a small one. Third appearance of this defect class, after a display-rounded margin and a display-rounded Kelly fraction, and the same fix each time — use what the engine uses, arranged how the engine arranges it.

• The agreement guard refused 455 of 3,595 pools at a flat, suspiciously round 5.0 grid steps that did not move when the encoder changed twice. 5e-9 is exactly half of 1e-8, and honestOut is served as round(honestOut, 8). A constant gap that survives two encoder fixes is not the encoder.

Latency, against the 500 ms bar. Three circuits prove warm in 328 to 346 ms. constantproduct takes 697 ms and is over, because 1,293 Plonk constraints force a 2,048-point evaluation domain where the others fit 1,024. It came down from 1,553 by dropping two comparators that were implied by constraints already present and by narrowing the fee-residual window from 66 bits to 34. Getting under 1,024 would mean cutting another 270, and 55% of what remains is six 62-bit range decompositions that are load-bearing for soundness; narrowing them to fit would cap reserves at about 4.5M tokens, and the sweep already reports 405 of 4,000 pools outside the current 2^62 domain. So it stays at 697 ms and is reported rather than hidden. None of it is on the request path — the live service answers in 275 to 348 ms p50, measured, because a proof is built behind the response and not inside it (node zk/scripts/latency.mjs --live).

Not shipped: no endpoint serves any of these three, and no verifier for them is deployed. Both need a deploy, and deploys wait while judging runs.

The proof now outlives the process

Until this week the proof store was a Map. A redeploy cleared it, and a second replica would answer 404 for a proof the first replica had just built. The endpoint said so in its own 404 body, which was honest but was not a fix — and "held in memory" is not a property anything on chain should depend on.

A proof is immutable and is already named by its own content hash, so this is a lookup change, not a design change. src/util/proofStore.js writes a finished proof under its hash and reads it back on a memory miss. Three decisions are worth stating because they are the ones that could have been wrong:

• Only ready is persisted. A building record is a fact about a process, not about arithmetic. Persisting it would mean a crash mid-proof leaves a permanent "building" on disk that nobody is working on and every later reader polls forever. failed and unavailable are excluded for the same reason: a refusal is a judgement made by one build of the code, and a fixed prover should not keep serving the old refusal.

• Off unless configured. Neither QUIVER_PROOF_S3_BUCKET nor QUIVER_PROOF_DIR, no behaviour change of any kind. /build reports which of the three worlds a deploy is in, and the 404 body says the matching thing rather than the reassuring one.

• An object store, not a volume. The claim is that a proof survives a redeploy and a second replica. A Railway volume cannot carry the second half — Railway's own reference says "Replicas cannot be used with volumes", one volume per service, region-pinned — so a volume would have delivered half the claim while the endpoint advertised both. The store therefore has an S3 backend beside the filesystem one, chosen by environment. The filesystem backend was kept: it is the one anyone can exercise from a clone with no credentials, which is what keeps the gate runnable unattended. Details, and what is and is not proven without real AWS keys, in docs/PHASE_A_S3.md.

npm run gate:a          # builds a proof in one process, kills it, reads it from another — both backends
npm run gate:a-revert   # removes the feature five separate ways, proves the gate goes red each time

gate:a spawns a real child process, waits for it to exit, then reads the proof from a second, unrelated pid. It carries its own negative control: a third process with no store configured must not find the same proof, otherwise the gate would be measuring the prover instead of the store. A fourth process boots the whole service and is asked for /proof/<hash> over HTTP — because the store is asynchronous, and a route that reads it without awaiting would answer 200 with an empty body that reads exactly like a cache miss. Eleven cases, every one run against both backends.

gate:a-revert is the part that makes the green result mean something. It removes the feature five ways — writes become a no-op, the durable read is deleted, durability is claimed instead of probed, the endpoint's await is dropped, a failed write is swallowed — reruns the gate after each, and requires it to go red every time and to come back to 11 of 11 once all five are undone. A gate that is red in both states is broken, not strict, so both halves are checked.

Where this actually stands: the store code is deployed and switched OFF, which you can confirm yourself — curl .../build reports proofStorage: {"durable": false, "kind": "in-memory only", …}. Turning it on is a bucket and a role: no code change, no endpoint change, no re-review. These cases deliberately sit in gates/ rather than test/, and they are staying there: the paper is served live and states the size of the model-free suite, so moving that number in the repo while the live paper keeps the old one would create exactly the staleness this project keeps auditing for — and the only thing that could reconcile them is re-cutting the paper to describe a feature that is switched off.

Quiver bought from another agent

See the At a Glance row and on-chain verification. Settlement 0x51f44374…a1539 on X Layer, 0.01 USD₮0 to agent #4462, deliverable returned in 0.81 s. Zero deploys: a purchase is a transaction from our wallet, not a change to the service.

The listing was removed, and the stated reason was not the whole reason

On 1 August 2026 at 09:31 UTC this agent was delisted from OKX.AI. The listing card said Listing rejected and carried an empty reason field; the reason came by email, and it was that the service was not integrated with the official OKX Payment SDK, so their review could not complete verification.

Everything we could measure said the service was fine, and it was measured within half an hour of the rejection. All 22 services were still stored on chain with the right endpoints and fees. The endpoint answered / and /.well-known/agent-card.json with a 200 and every paid route with a well-formed 402, all in under half a second. OKX's own agent x402-check passed 22 of 22. validate-listing returned zero findings. The last deploy had gone live 27 hours earlier and every watchdog-recorded deploy measured zero seconds of darkness. A correct hand-rolled implementation of the protocol is simply not what the review verifies; it verifies the SDK.

Then the container's own logs said something none of those checks could. Every settlement on X Layer from 31 July 16:17 UTC to 1 August 09:12 UTC answered success=true with no transaction hash. The rule that reads that as unsettled has been in this service since July, so it refused to serve and returned a 402 each time: for at least seventeen hours every buyer was correctly charged nothing and correctly given nothing. The delisting landed nineteen minutes after the last failed attempt. An exhaustive scan of the X Layer transfer log across that entire window — blocks 66,744,564 to 66,807,564, full coverage, no gaps — found zero transfers arriving at the payment address, which confirms the money genuinely never moved and rules out the worse reading, that payments were landing while the service answered 402 anyway.

So the likeliest account is that a reviewer tried to buy something and could not, and the SDK was named as the remedy rather than as the symptom.

The migration fixed it, and that was verified with real money rather than by reading a receipt. The payment layer now runs on @okxweb3/x402-express and @okxweb3/x402-core, with the OKX facilitator client doing verify and settle. After the deploy, a 0.005 call to macro-sentry returned HTTP 200 with a real answer, its receipt carried transaction 0x271c9f64acee8052f6dd0f4b303986c9f225ccfb5b625b85e22c96a35c63a211, and the balances moved on chain by exactly that amount in each direction. The listing was resubmitted and reads active with 22 services again.

Four defects surfaced during the migration and every one of them was found by probing the running service rather than by reading code: a facilitator base URL passed with its path already attached, so the SDK appended its own and earned a 403 that read exactly like bad credentials; an initialize() that reported success while the primary rail had no supported payment kinds at all, because one facilitator answering counts as success; an empty accepts[] when the facilitator sync was disabled, which is a 402 nobody can pay; and an HTTP 500 on every paid route when the facilitator was unreachable, which breaks the one thing the protocol actually mandates. Initialisation is now retried with backoff behind a fallback that keeps answering a payable 402 and never serves the resource unpaid.

Two more were in the instruments, which is the part worth keeping. A new gate compared the challenge in the response header against the mirror in the body using JSON.stringify, and called a difference in key order a disagreement. The same gate fired sixty-six requests at a service that rate-limits at sixty a minute and then read the resulting 429 bodies as unpayable challenges. The empty-body challenge was caught at all only because two instruments looked at the same claim from different sides and disagreed.

The lesson is narrower and more useful than "test more". A green 402 says nothing about whether settlement lands. Every check this repository owns was passing while the paid rail was completely dead, and the only instrument that showed it was the container's log. After any change to a payment layer, put real money through it and check the chain, not the receipt.

The engine hash q1-e1fa99d08887d6cc did not move: the payment layer sits outside src/engine/, so every published proof still reproduces.

Documentation

The full technical documentation is one continuous document, served as /paper — typeset, with figures, mirrored at assets/whitepaper.html (PDF).

Reading it with an AI? That page is 400 kB of styled HTML and will not arrive whole in one fetch. The identical text is served as plain markdown in seven parts, each small enough to read in a single request. Nothing is abridged — the parts concatenate to the whole document, cut only at section boundaries, and a test asserts exactly that.

The split was measured, not guessed. Stripping the markup gave 237 kB of clean markdown, and a real fetch of that still stopped at about 40%, mid-sentence in §5.19, reporting the References and all three appendices as missing. The budget belongs to the reader, so the document had to arrive in pieces. Generated by tools/paper-to-text.mjs.

The same material is also split by topic below. Each file is short enough to read in one pass and points at the artifact that settles its claims.

Research artifacts — the crash study, its pre-registered queries, the beta calibration, the buyer audit and its raw ledger — are under research/.

The Risk Brain — deterministic, proof-carrying

Nine engines whose answers are pure functions of their inputs. Each ships the proof envelope, and each is reachable free over POST /mcp.

Options, safety, microstructure and market intelligence

How a call works

agent ──POST /api/perp-gate───────────────────────────▶ Quiver
      ◀─402 Payment Required {asset, amount, payTo, network}   (one entry per rail)
      ──POST + PAYMENT-SIGNATURE (EIP-3009, gasless)──▶
                                     verify + settle ─▶ facilitator
      ◀─200 {result, proof} + PAYMENT-RESPONSE receipt

Every paid route answers an unauthenticated request with the 402 challenge before any business logic runs. A request the engine refuses is never settled: the receipt reads not_charged and you keep your money.

Running it

npm ci
npm test      # 386 model-free tests — no network access required
npm start     # serves on the configured port

The core suite is self-contained, so the invariants can be verified offline.

License

MIT — see LICENSE.