Here is the receipt. Check it yourself.

The breakthrough: 8080.AI dynamic dense attention (O(n))

Transparent form · receipt format v1 · checked in your browser · nothing leaves your machine

Abstract

8080.AI dynamic dense attention (O(n)) reads a bounded set of tokens for every new word, keeps the exact attention formula, and still reaches every token: flat cost at any context length, on the models the world already has, with no retraining. This page is its zero-knowledge proof. We seal a run, you pick rows with a number only you know, we open just those rows, and your browser checks them. You never learn how the tokens were chosen.

1Verify zk proof: seal, open, check, then the growth run from 512 to 1,048,576 tokens, ending at your downloadable receipt and the standalone checker.

Measured points on Fig. 0
Context lengthReads per new tokenCertified bandSealed in
No measured points yet.

lines: arithmetic · points: no measurement yet — press Verify zk proof

Fig. 0 | Reads per new token against context length, on a plain reads axis (context lengths double along the bottom). The blue line is arithmetic: standard attention re-reads every earlier token, (n+1)/2 on average. The amber line is the limit written into the sealed statement, 288. Points are measurements from sealed runs and appear after you run the checks; whiskers are the certified band.

Latest receipt

verified · 1,048,576 tokens · 100 rows opened · 3/3 checks · sealed on our server ·

Box 1 · The breakthrough, in one minute

Picture a 4,096-page book. To write each new word, standard AI re-reads every earlier page, so the further into the book it gets, the slower and dearer each word becomes: double the pages, four times the reading. That is the quadratic tax. 8080.AI dynamic dense attention (O(n)) reads at most 288 pages that matter for the word at hand, and can still reach any page in the book. Cheap, exact, nothing dropped.

This page lets you check that on a sealed run, the way an auditor checks a sealed ledger: we seal, you pick random rows with a number only you know, we open only those, and your browser checks them.

  • Cheap. Every token reads at most 288 earlier tokens, however long the text.
  • Exact. The output is the ordinary attention formula over exactly those tokens. Nothing approximated.
  • Nothing dropped. Every token is still read by something later, and far-back tokens stay reachable.
Why can't we cheat?

The run is sealed before your number exists. Your number then picks which rows must be opened, and the seal cannot be changed afterwards. If we had broken the limit on one row in twenty, opening 100 random rows would catch us with 99.4 % probability. Rows that cannot be shown count against us, never as skips. Rows you did not open are not checked; that is what random sampling buys, and what it does not.

What is a zk proof? ↗

  1. 01Sealidle
  2. 02Challengeidle
  3. 03Verifyidle
§ 1

§ 1 · Seal · Step 1 of 3

We seal a run

Our server runs one pass of 8080.AI dynamic dense attention (O(n)) over 2,048 tokens and seals what every token read. Your browser receives only the fingerprints. Once sealed, nothing can be changed.

1234tokens →layer?fingerprint
Fig. 1 | Every row is one token at one layer: what it read, and the numbers in and out. All rows are hashed into one fingerprint. Rows can be opened later, never changed.
Settings

2Synthetic run: the text is generated, not a real prompt. The attention arithmetic and the sealing are real.

§ 2

§ 2 · Challenge · Step 2 of 3

You pick what to open

Seal a run first. The pick is derived from the seal plus your number, so it cannot exist before the seal does.

your number · 84c3477f1234tokens →layer?seal
Fig. 2 | Your number, mixed with the fingerprint, picks which rows get opened. Change one character and different rows light up.
§ 3

§ 3 · Verify · Step 3 of 3

Your browser checks the receipt

Nothing to check yet. Seal a run and open some rows.

your number · 84c3477f1234tokens →layer?seal
Fig. 3 | Each opened row is checked against the fingerprint and its attention output is recomputed. One mismatch anywhere fails the run.
§ 5

§ 5 · Zero knowledge

Why this is a zero-knowledge proof

A zero-knowledge proof convinces you that a claim is true without telling you the secret behind it. Here the secret is how 8080.AI dynamic dense attention (O(n)) decides what each token reads. The receipt carries only a fingerprint of that rule, and none of the seven checks needs the rule to run. So you end up certain of the claim, and no wiser about the mechanism.

  • You learn: the limit (288), that the math is the ordinary formula, how far reads reach, how many tokens are read later, how many pairs connect, and that the weights are the base model's.
  • You never learn: the rule that picks the tokens, or anything that would let you rebuild it.
  • Two forms. On this page the picked rows are opened in the clear so your browser can recompute them (the transparent form). The production form wraps each opened row in a compact cryptographic proof, so even the rows stay hidden and a checker learns only pass or fail. Same seal, same checks, same number.
§ 6

§ 6 · Growth

Does it stay cheap as the context grows?

One sealed run per context length, same checks, same rule for picking rows. Every size was sealed once on our server; sizes up to 4,096 tokens carry the full seal (inputs and outputs too, so all seven checks run), sizes up to 1,048,576 tokens carry the reading lists. Each is opened with your number and your browser does all the checking, so the server is never trusted. Starting a run clears the previous results, and each size appears below as soon as it has been checked.

05121k2k4k8k33k131k524k1.0MCONTEXT LENGTH · TOKENSREADS PER LAYER

ring: sealed on our server, opened with your numberchecked in your browser

  • 8080.AI dynamic dense attention (O(n)), amber solid line: certified upper bound on total reads per layer
  • standard attention, blue dashed line: total reads per layer
Fig. 7 | Total reads per layer as the context grows (linear reads axis). Slope 1 means the reading grows in step with the text; slope 2 means it grows with its square. A least-squares fit over the sealed sizes: it measures these runs, not all contexts.
§ 7

§ 7 · Limits

What this proves, and what it doesn't

It proves

  • On this run, every row your number picked read at most 288 tokens, was ordinary attention over exactly those tokens, and reached at least halfway back.
  • Every token your number picked was read by a later token.
  • The two pair fractions are lower bounds at 95 % confidence, with missing chains counted against us.
  • The weights are the published base model's. No retraining, no fine-tuning.

It does not prove

  • That every row behaves this way. Only the rows you opened were checked; cheating on a meaningful fraction would be caught, cheating on one row in ten thousand probably would not.
  • That a deployed model does this. These are synthetic runs: generated text, real attention arithmetic. Binding these checks to a model serving real traffic needs an auditor who runs the prover or a hardware enclave that signs the receipt.
  • That the answers are good. Accuracy is measured on public text and reported separately; no check here says anything about quality.
  • Anything about how the tokens were chosen. The rule is our trade secret; the receipt carries only a fingerprint of it. Auditing the rule itself is done under confidentiality.
§ 8

§ 8 · Artifacts

Take the receipt with you

The receipt holds the statement, the fingerprints, your number and the opened rows, nothing else. The checker is a separate module with no network access; it re-derives which rows to open from your number and recomputes every check itself. Change any byte of an opened row and the fingerprints stop matching.

Check it on your own computer

The checker is open source, a single file, with no dependencies and no network access. Download a receipt above, then run either script next to it. Both re-derive the picked rows from your number and recompute every check offline; exit code 0 means every measured check passed.

python3 verify.py receipt.json
node verify.mjs receipt.json
App. A

Appendix A · Table A1

Run ledger

Every run that was sealed, opened with a visitor's number and checked is recorded here and verified a second time on our server with the same checker you can download. Receipts sealed in a browser are kept for the main run; the growth rounds keep only their verdict.

#WhenSealedTokensRows openedReads / tokenChecksStatusReceiptNumber
4fb54048our server growth1,048,5761002053/3verified↓ JSON · 254 KB7790cebf
501a2843our server growth524,2881002573/3verified↓ JSON · 261 KB7790cebf
bd5dcb1four server growth131,0721002393/3verified↓ JSON · 240 KB7790cebf
8312f5adour server growth32,7681001863/3verified↓ JSON · 215 KB7790cebf
514fdf09our server growth8,1921001293/3verified↓ JSON · 198 KB7790cebf
d796760eour server growth4,0961002317/7verifiedverdict only7790cebf
46bb6fb0our server growth2,0481001477/7verifiedverdict only7790cebf
81692dcdour server growth1,0241001477/7verifiedverdict only7790cebf
5963ce23our server growth5121001177/7verifiedverdict only7790cebf
27663bdbour server growth131,0721002383/3verified↓ JSON · 235 KB7aa4c555
Runs 1–10 of 20