BandwidthSwap

A bandwidth market where the payment is the proof.

Check a proof · Oct 2026

Lab status

Check a proof

October 18, 2026 · the receipt is the proof, checked in your browser · nothing you paste leaves this page

Every hour the Mint signs a root over the windows it settled, and bwkit prove on the Mint prints the proof that each settlement is under that root. Paste one here. This page recomputes every leaf and the path up to the root, and checks the Mint's signature on the root, using none of the kit's code: it is a second reading of the same rules, written so that a proof has to satisfy two implementations, not one. It runs in your browser and sends nothing anywhere.

The Mint you expect

Filled with the lab Mint's NYM, read from bw-mint with bwkit nym on October 18, 2026. A proof signed by any other key then fails here, as it should when you meant this Mint. Empty the field to accept any Mint's signature; the page then says whose it is.

The live commitment

The Mint posts a summary of its ledger to the status feed every ten minutes and right after each hour's commitment, signed with its own key, and the summary carries its latest hourly commitment. This fetches the feed and checks the signature on that commitment, in your browser, against the Mint's NYM.

Since bwkit 0.3.0 the feed names its Mint on the commitment and carries the committed hour's proof; both are checked when present, and the Lab status section does the same on every load. If a feed carries neither, the signature is checked against the NYM printed on this page.

What this checks, and what it cannot

The commitment's signature
Ed25519 by the Mint's key over bandwidthswap/commitment/v1, a newline, and the JSON array [mint, window, root, count] in canonical form. The Mint's NYM is ed25519: followed by its 32-byte public key in base64url. A valid signature means that Mint said this root, over this many settlements, for this hour, and cannot later say otherwise.
Every settlement's place in the root
A leaf is SHA-256 over a zero byte and the settlement in canonical JSON, without its field t, the Mint's own clock. Canonical means keys sorted, no whitespace, every non-ASCII character escaped, numbers written as the kit writes them. An inner node is SHA-256 over a one byte and its two children; the tree splits at the largest power of two below the count, as in RFC 6962. The proof's path is the list of siblings from the leaf up; the page climbs it and must arrive at the root.
What it does not check
Whether the settlements are right. A settlement is the Mint's reading of two signed receipts, and those signatures are not in the proof, only their values; the kit's bwkit rebuild redoes the settling from the parties' own copies. Whether the Mint left a window out: that needs your receipt and the hour's commitment, and is what bwkit prove on your copy is for. Who the Mint is. A key is a key; the NYM above is the lab's because this page says so, not because anything proves it.

Getting a proof

On a Mint, for the hour starting at midnight local time on October 18, 2026 (the example above):

sudo -u bwkit bwkit prove 2026-10-18T00 > proof.json
bwkit verify-proof proof.json --mint "$(sudo -u bwkit bwkit nym)"

The second line is the kit's own check. This page is the other implementation: bsp.js, one ES module with no dependencies and nothing to fetch: SHA-256 and Ed25519 from the browser's WebCrypto where it has them, and otherwise its own SHA-256 and SHA-512 in plain JavaScript and an embedded copy of noble-ed25519 2.3.0, so a plain-http page with no WebCrypto at all, which is how a node's own page is opened on its network, checks the same bytes; the line under the result says which ran. In the site's repository, node tools/check-vectors.mjs runs the same module over real proofs from the lab's Mint and tampered copies of them, and over the kit's test vectors once those exist, so the two implementations are held to the same bytes.