Trading fees pay for AI. The AI writes maths proofs. A machine checks every one. You choose what it works on.
People trade the tokenEvery trade pays a 2% fee. After the Meteora fee, 90% goes to the pot for Compute Power (API, servers, checkers), 10% to operations + team. The split is fixed on-chain.
Holders voteEach round, holders choose the next problem with the Vote button.
The AI swarm gets to workModels from different labs divide the problem into pieces and work on many at once.
Machines check every proofLean, a computer proof-checker, checks the maths. Comparator confirms it proves exactly the stated problem. No person, AI or vote can overrule them.
Everything is publicEvery proof, every vote, who proved what. Re-check any of it yourself.
The machine is simple to use and strict underneath.
Under the hood, it's anything but simple: many AI models from different labs, two independent checks on every proof, on-chain votes anyone can recount and a money check every hour all have to line up before a single result counts. Here is every step in between.
01
When a proof becomes certain
A proof counts only after two independent checks inside a sealed box. Lean checks the mathematical reasoning; Comparator confirms it proves exactly the published statement. When both agree, the result is certain: no contributor, model or vote can change those rules or overrule the maths. Contributors may make the checker faster, never different.
Inside the sealed box: no internet, no keys, fixed versions.0 checked · 0 proven
A result is proven when all four hold
The Lean kernel accepts the proof. The kernel is Lean's core proof checker. Where it is switched on, a second independent checker, nanoda, runs too. If nanoda gives no verdict, we say so, and the result rests on Lean's kernel.
Comparator confirms the proof proves exactly the published statement. It also checks that nothing the statement relies on has changed. Solvers fill in the proof only; they never edit the statement or the rest of the file.
Only the three standard axioms are used, as reported by #print axioms: propext, Quot.sound and Classical.choice. Anything containing sorry, admit, a new axiom or implemented_by is rejected.
The check runs sandboxed: a fresh, isolated container with no network, no keys, and fixed versions of the toolchain and library.
What you see on each result
Proven
All four rules hold: Lean and Comparator both passed. For results from other labs, reviewers from other labs also judged the statement faithful to the paper.
Partly proven
Some pieces are proven; work continues on the rest, or the run has stopped. For other labs' results, the formal statement is weaker than the paper's headline result.
Proves a different statement
The proof is correct, but reviewers found that the Lean statement checks almost nothing about the paper's main result.
Not yet
The result has not reached the proven standard. That is not evidence it is wrong.
Labels while a check is in progressWhat the live feed shows piece by piece
Lean ✓ accepted
The kernel accepted the proof. It is called proven only after Comparator agrees.
Comparator pending
The kernel accepted the proof; Comparator has not returned a verdict yet. This is never shown as a failure.
Every run starts by checking a known-good proof, called a canary. If a checker gets it wrong, the run stops trusting that checker.
Upgrading Lean or MathlibWhy old results never silently change
Versions change through an upgrade gate: we build the new version alongside the old one and re-run every existing check. The switch happens only if nothing breaks. Published results never change after the fact, and every result records the versions used to check it.
How our checker comparesMost systems only report that a proof compiles
Our checker is among the strictest published. The only other published setup we found using Comparator is OpenAI's (openai/math, October 2026). DeepMind's AlphaProof Nexus (May 2026), Axiom (Putnam 2025) and Mistral's Leanstral (July 2026) use a similar community tool, SafeVerify. Most other systems report only that the proof compiles.
Why the whole file matters. A proof can compile without proving the intended statement. If checking covers only the final theorem, a model can pass by changing what surrounds it. In March 2026, the LongCat-Flash-Prover team reported a 97.6% pass rate when grading checked only whether the target theorem matched. Under a stricter whole-file check, that fell to 27.9% (arXiv 2603.21065).
We check the step before the proof too. A machine verifies the statement as written; whether that statement captures the paper's plain-English meaning needs review. In 2025–26, Erdős problems #124 and #480 (Harmonic's Aristotle) and #125 and #741 (AlphaProof Nexus) were each reported as "proved" in a form that did not express the real problem. We review statements before they reach a ballot, as the next section explains.
Lean settles whether a proof establishes the Lean statement. We also check the earlier step: whether that statement says what the paper says. Models from other labs review it, with their names on every result and their conclusions labelled as AI judgement.
That review found three formal statements in OpenAI's published maths that are weaker than their papers' headline results. Four AI reviews from three labs agree on that: Claude, then Grok 4.7, Gemini 3.1 Pro and a fresh Claude. They differ on how clearly OpenAI's notes say so. One of the three is labelled "Proves a different statement", because its formal statement checks almost nothing about the paper's main result.
Proving: any model may try. The kernel decides whether a proof is correct, whichever lab's model wrote it.
Reviewing: never your own lab's work. A model family never reviews its own lab's statements. Non-OpenAI models, Google's Gemini and xAI's Grok, review OpenAI's statements, and a second family re-checks every issue raised. For neutral problems, we use whichever models measure best.
Writing new statements. For a paper without a Lean statement, one model writes it, models from two other labs review it blind against the paper, and Lean type-checks it. 43 statements from new papers have been prepared this way for the ballot.
Human review is always open. Anyone can compare a statement with its paper and send us their findings.
Lean checks that a conclusion follows from its premises. Facts about the world sit outside it, so work outside formal proof is labelled "re-run / measured", never "proven".
03
How the machine is built
Six parts, each with one job. The chain holds the money and the votes. The checker holds no keys. The public site cannot start work or move money.
Hover a part to see its job and the limits of its access.—
Fee path (on-chain). The token trades on Meteora, a third-party Solana program. The pool's fee setting splits the fees 90/10 between the pot and operations.
Votes (on-chain). Holders vote by burning tokens in a transaction carrying the round's ballot tag and one option code. A public counter builds the tally from chain data, and the tally's fingerprint is posted on-chain.
Dispatcher. Turns the winning option into proof tasks. It starts work only from a tally whose fingerprint is posted on-chain and refuses any other.
Swarm. Sends tasks to models through commercial AI providers. Every call is booked against the run before it is made. The money in the pot sets how much work runs each hour.
Checker. Separate servers run every check in a fresh, sealed container with no network and no keys. The checker returns a verdict and never edits a statement. Servers are added automatically ahead of demand, five at least and ten at most. live
Site. A read-only page shows the vote, the live work, each result's label and its exact proof file. It holds no keys. A backup copy on a second host shows the last state if the main site is down.
04
Many models, every piece checked
The swarm divides a hard problem into smaller pieces, or lemmas. Several agents from different labs work on each open piece at once. The first proof the checker accepts wins that piece, and work continues only while Lean confirms progress.
The proof map (as on the live page): the final result in the middle, its pieces around it, lines showing which pieces depend on others.0 / 0 pieces
The models
Claude Sonnet 5.5, Claude Opus 5.5, GPT-6 Astra and Claude Fable 5.1 each run at a fixed thinking level. Sonnet, Opus and Fable run on both of our AI providers; GPT-6 Astra runs on one.
We chose them through a small measured test on six hard lemmas, with every proof checked by Lean. Six lemmas give a first signal; live results tell us more. The kernel judges the proof, not the model that wrote it. Every result names its model.
The proving rules, step by stepHow work proceeds, and when the machine stops
Free checks first. Before any model is paid, Lean checks that each statement compiles. A screen for statements that may be false is coming after launch. planned
A quick first pass on every piece.
Several agents per piece, different models. In maximum-agents mode, each open piece gets several agents at once, three by default, each from a different model family or using a different hint; with the mode off, each task gets one agent. The first proof the checker accepts wins, and the other agents on that piece are cancelled. After a failed attempt, the checker's error message feeds into the next one. live
Continue while the checker confirms progress. Progress means new pieces accepted by Lean. A model saying it is close does not count. Accepted pieces are kept for later attempts, and retries receive the outline, the accepted pieces and a log of approaches already tried. Six attempts without progress mark a task as stuck.
A warm-up for each new topic. Work does not slow down until the topic's first proven piece, or until 90 minutes have passed.
Computing power for fresh ideas. About a fifth of each task's computing power goes to new approaches even without visible progress, so a problem that needs a new idea isn't cut off by the progress rule.
A ceiling per task. A ceiling, not a target. A solved task stops at once: agents already running finish, and no new agent starts.
"Unsolved by this setup." A task that reaches its ceiling or stops making progress receives this internal label; the public list shows "Not yet". Fixed rules derive a suspected reason from the attempt record, such as signs the statement may be false or a missing library result; "cause unknown" is also allowed. A model saying "this is false" counts only as a clue. A result proven suspiciously easily has its statement re-checked against the paper.
No automatic reopening. A task recorded as "Not yet" runs again only if a vote picks it.
Long thinking where it helps. Calls can run for up to about 15 minutes, with answers streamed as they arrive.
When a model refuses a pieceContent filters, and how the run carries on
An AI provider's content filter sometimes blocks a request and returns an empty reply. That model skips the piece while the others carry on. The block itself passes or fails nothing. live
Every question sheet gets a block test before it is locked. Last test: 82 pieces × 4 models, 0 blocked.
What every run recordsThe same format for every attempt
Each attempt records the model, thinking level, approach, time, tokens, verdict, kind of checker error and accepted pieces. Each problem records its outcome, time, attempts and suspected reason. Every run also has a short summary. Before repeating a run, we write down its success criterion and repeat limit; neither changes after we see the results.
Why OpenAI's model is on the ladderLab neutrality
GPT-6 Astra is an OpenAI model. Models on the ladder write proofs, and Lean judges those proofs, so any lab's model can take part. GPT-6 Astra never reviews OpenAI's own statements.
05
How voting works
Use the Vote button to burn tokens for weight, or vote free with what you hold. Every vote is on-chain, anyone can recount a round, and credit you don't use stays yours.
One round, start to finish.voting open
Held for9 days · 1×
Vote only with the Vote button. It burns the tokens you choose, or none for a free vote, in a transaction carrying one current-round code and the round's ballot tag. The tag is a fixed address nobody owns, published with each round. The counter reads only tagged transactions, so it finds every vote however busy trading gets. A burn without the tag is not a vote and earns no credit.
Weight. Burn credit equals tokens burned × the 30-minute average price at the burn's block time. Free holding votes count 1× at first, 2× after 14 days held and 3× after 30 days. Burning keeps your holding clock; selling restarts it. Votes are shown in dollars.
Per-wallet cap. Each wallet can add a limited amount to an option each round. The limit is published with the round settings and can only go up. Credit above the cap carries over.
Carry-over. Backers of the winning option use up their credit. Everyone else keeps 100% of theirs, with no expiry. In each new round, you can put all your credit on any option.
Every round starts fresh. Your holdings and credit count only when you vote in that round. One "this is my vote" transaction uses both your free holding votes and your saved credit. A 0-token burn costs only the network fee.
Change your vote. Vote again for a different option. Your last counted burn decides.
Last 90 seconds. The button turns grey and counts down 90 seconds before the close, giving burns time to land. The countdown follows our server's clock. A burn sent directly to the chain still counts if its block time is before the close.
Every option is runnable. Each option has a public title, a line explaining what it means and the maths behind it, linked to a written work plan. A ballot opens only when every option has a plan. An option that loses 3 rounds in a row comes off the ballot.
Burns that miss, multisigs and smart walletsNothing you burn is silently lost
A burn arriving after the close, between rounds, or with another round's code, no code or two codes does not count as a vote. Its value, worked out like a vote's, is saved in the round it lands in (or the next round, if it lands between rounds) and becomes usable one round later. For example, a burn meant for round 5 that lands after round 5 closes is saved in round 6 and usable from round 7.
A burn made before round 1 opens is saved in round 1 and usable from round 2, valued at the price when it was burned. Before the token's first trade there is no price, so such a burn saves no credit. A burn through a multisig or smart wallet (inside another program's call) saves credit for the address the tokens came from, but never counts as a vote. Failed transactions and burns of the wrong token are not counted.
Where free holding votes come fromWhich of your accounts are counted
For wallets voting in a round, free holding votes come from their own token accounts: the usual account for the token, any account they have voted from, and any other account for that token found in those accounts' transactions. Moving tokens between your own accounts links them. To include an account with no such link, vote from it once or move a token between it and your usual account.
If a wallet's history does not add up on either of our two data providers because a transaction is missing, its free holding votes count as 0 for that round. Its burns still count, the round goes ahead, and the team is told at once. The round file lists the wallet so every recount follows the same rule.
How prices are measuredEvery price can be re-derived from the chain
The count takes prices from the token's own pools and one on-chain SOL/USDC pool, one point per minute per pool. For the token, it uses the last clean swap of each minute: a real swap of at least 0.01 SOL made by the pool itself. For SOL/USD, it uses a hash-ordered median of the minute's first clean swaps. The 30-minute averages run over these points.
Anyone can re-derive a round's points through any Solana connection. Each round file names its pricing pools, and those pools are checked on-chain before use.
Junk floods. To find a minute's last clean swap, the recorder checks up to 5,000 of that minute's newest transactions. If none is a clean swap, it carries the last real price for at most 3 minutes in a row, marked "carried" in the record and round file so recounts agree. A 4th flooded minute in a row stops the price record: rounds wait to be counted, and the team is told at once. Voting itself never stops.
How a round is countedOne fixed point, two providers, one fingerprint
One position per close. A round's chain position is fixed when it closes and reused on every retry, so a delayed count still reads the same point in the chain. Two independent data providers supply the count; if they disagree, nothing is posted, and the alert names the provider missing data.
The fingerprint (tally hash). A SHA-256 fingerprint of the full tally: every counted burn, every saved non-vote burn and every wallet's credit. It includes the previous round's fingerprint, linking the rounds into a chain, and is posted on-chain as a memo containing only the hash. "Verify this round" under the ballot links to that memo and to the file you need to recount.
Measured: two independent recounts matched the live count in all 3 rounds of a local test. The devnet recount produced the same fingerprint, posted and read back. Practice run 2: recounts matched in 14 of 14 rounds.
06
Rounds, Focus and Stop
Each round chooses the machine's next problem. A voted winner is never skipped. The team has two controls: Focus keeps work on a problem that is close; Stop ends the current problem early.
Rounds run on a clock, shown in the top bar. The round length was set on launch day; by default, each problem gets about a day of work.
A winner is never skipped. If work is still running when the next winner is counted, the queue waits. No voted winner is dropped. At most 3 counted rounds can wait in line.
A round with no votes keeps the machine working on the last winner.
Focus. The team can keep the whole machine on the current problem. Voting stays open, the round runs longer, and the site says "Round extended: the machine is finishing …". No vote is lost; when Focus ends, the round closes 3 minutes later, so anyone mid-vote still lands in it. Focus ends when the team turns it off, the problem is solved, or nothing is left to try.
Stop. The current problem stops, what it proved is published, and the next winner takes over. Round numbers and past rounds never change.
Automatic Focus. The machine deciding Focus on its own exists only as a separate test copy, and comes after launch. planned
07
Where the money goes
Every trade pays a 2% fee. After the Meteora fee, 90% goes to the pot and 10% to operations + team, fixed on-chain. The pot buys computing power, and the machine's pace follows the money available.
The split is on-chain. On our mainnet test token, it measured exactly 90/10, before and after graduation.
The split. The Meteora fee is 20% of each fee, measured. Of the rest, 90% goes to the pot and 10% to operations, and each side can claim only its own part. The 10% pays for operations + team.
Two money wallets: the pot and the team. The pot wallet is the pool's fee claimer, so only the pot can claim its share; no server key can. Every payment out is visible on-chain. The server holds two working keys: the graduation mover, which can only move our own pool, and the tally publisher, which posts round fingerprints. Neither can move pot or team money.
Graduation. When the token moves to its full trading pool, the 90/10 split continues, and the one-off leftover from the launch curve also goes to the pot. The mover handles the pool move automatically. live
Pot → compute. Claimed fees are converted to USDC and used to pre-pay AI compute. AI accounts are topped up by hand, and the pot's key never sits on a server. Money that isn't spent stays in the pot.
Money ready for computecovers next hour
Speed follows the potThe hourly money check
By default, agents run at full capacity: as many as the AI providers allow, the checker servers can handle and the open work needs. Every hour at minute :58, the machine checks whether the money ready for compute covers the next hour at full capacity. That is the pot plus the balance in our AI accounts, shown on the site as COMPUTE POWER.
If it covers the hour, work runs at full speed. If not, the machine runs only as many agents as that money pays for, and scales back up at the next check once money comes in. It commits only to an hour it can already pay for. Each decision is recorded internally; those records hold cost figures, so they stay private. live
Unreadable numbers never trigger a scale-up. An AI balance that can't be read counts as zero, and a SOL price older than 60 minutes makes the pot's SOL count as zero. If the money can't be read at all, the machine uses only what remains from the last hour, for at most one missed check. After that, no new agents start.
Controlled warm-up. On top of that, an hourly spending limit starts low and doubles each hour while everything is healthy: few AI calls turned away, checker waits under a minute, and work still left. If the team sets a maximum, the limit never goes above it.
Pause and StopEffective within about 5 seconds, no redeploy
Pause starts nothing new: no vote counts, fingerprint posts or work. Work already running finishes. Stop also ends the work that is running. Money that isn't spent stays in the pot, and removing the pause resumes the machine.
08
When something breaks
An outage delays a result. It never passes or fails one. Work pauses, the money stays in the pot, and everything picks up where it left off.
proofs flow straight to the checker
Checker down. The proof is held, not failed, and no new model calls are made to replace it. When the checker is back, it checks the held proof.
Comparator unavailable. The result stays "Comparator pending".
AI provider busy or refusing. Work moves to our second AI provider. If both are limited, work pauses and the money stays in the pot.
Vote data incomplete. The round's result is held ("counting paused"), never guessed. Votes live on Solana, so our outages cannot lose them. Paused rounds are counted in order once the data is back.
Main site down. A backup copy on a second host takes over and shows the last published state, its time and a "voting paused" notice. live The live page supports up to 10,000 live connections, then falls back to refreshing.
Pauses and resumes are automatic.
09
What an attacker can't do
Assume every part could be attacked. These are the limits on each attacker, and the risk that remains when every rule holds.
10
What it's built on
The machine stands on open, public tools and on-chain records. Here is what each one provides, and how you can check it yourself.
Built on
How you can check it
Lean and Comparator, the checkers
Both are open source. Where switched on, a second independent checker, nanoda, also runs.
Mathlib, the shared maths library
Public and reviewed by its maintainers. We pin the exact version, and each problem's own definitions are published with it.
Statements that match their papers
AI models from other labs review them and are named on every result. Anyone can review them too.
AI providers serving the model they name
The same lemmas run through two providers showed no sign of a swap. A different model could change who receives credit, never whether a proof is correct.
The pot paying only for compute
One dedicated wallet, with every payment out on-chain. Its address is published.
Meteora and Solana
Public on-chain code. The program, the pool and who can upgrade them are published.
The files on the site
Every proof file is named by its SHA-256 fingerprint. Re-hash the file to know it is the real one.
11
Check it yourself
Four checks anyone can run, without asking us or taking our word for it.
Rebuild the checker
The image's build recipe and fingerprint are published. Build it and compare. It pins Lean 4.34.1 and the exact Mathlib revision. live
Re-run a result
Download the proof file, named by its SHA-256. Run Lean and Comparator on it. #print axioms should list only the three standard axioms.
Recount a vote
Take the round file, settings, price points and close position, plus chain data from any Solana connection. Run the counter and compare your fingerprint with the one on-chain.
Follow the money
Read the pool's on-chain fee setting. Follow the claims into the pot and every payment out of it.
12
How we handle sensitive findings
Any finding that could expose people or systems to harm goes privately to the people who can fix it first. That covers stolen money, leaked personal data, exposed passwords or API keys, and ways to break or take over a service. Once it's fixed, it is published with credit.
What counts as sensitive. Anything that could harm people or others if it got out before a fix: money at risk, private or personal data, secrets such as passwords, keys and API tokens, or a way to break, take over or shut down a system people depend on.
Private first. Details are encrypted with restricted access and never appear on the site, in logs or in any repository. We contact maintainers privately. If money is at risk right now, we also contact SEAL 911 privately.
The deadline is 90 days, or shorter if someone is already exploiting the issue. If there is no response by then, we escalate to CERT/CC and publish only what people need to protect themselves, never a ready-to-use attack.
After the fix, once people have had time to update, we publish the finding with credit. Publication is decided case by case, never automatic.
Gaps in a maths paper harm no one. The authors get a heads-up first, then it can be published.
Contributors can stay anonymous. Voting needs only a wallet. Names are opt-in, through a .sol name or a signed nickname, and pseudonyms are welcome.
What AI providers see. Prompts for public work go to commercial AI providers, who can read them. Each ballot option states what it exposes.
13
Open for everyone
All code is Apache 2.0. All results and proofs are CC BY 4.0. Our name and logo are not included.
All of our code is open source under Apache 2.0: the whole supercomputer, the control panel, the vote recount tool and the proof-check scripts. Read it, run it, change it or build on it for any purpose, without asking. There is no waiting period.
Results, findings and proofs are free to use under CC BY 4.0, including the paper-to-Lean statements and the round records. Credit us when you use them. These rights do not expire.
Other people's work keeps its own licence. OpenAI's maths library and Mathlib are Apache 2.0. We keep their notices.
Our name and logo are not covered. Anyone may run a copy, but not under our name or logo, and not presented as the official project.
14
What we've proved already
The record below separates machine-checked proofs, measured runs and AI judgement, and names who produced each. Recorded results are never rewritten; corrections appear as new dated entries.
Recorded result
How it's known
189 of 189 of OpenAI's formalized main results re-checked twice, the second time built entirely from source. Every proof is valid. Nanoda independently accepted 182; it reached a resource limit on the other 7 and gave no verdict, and Lean's kernel accepted all 7. No statement or library file changed.
kernel + Comparator
13 of 13 further OpenAI proofs, covering cryptography-related challenges and π, proven. Independent re-checks of existing maths.
kernel + Comparator, nanoda on
72 of 79 lemmas re-proved by the swarm in 3.2 minutes. These fresh proofs were independently re-checked; all 72 passed both kernels and Comparator.
kernel + Comparator
16 of 16 lemmas proven in a full live run: tally → swarm → Lean → Comparator → site files.
kernel + Comparator
Live test run: all 6 of 6 written success criteria met.
measured
Practice run 2: 14 of 20 pieces proven; the vote recount matched 14 of 14.
kernel + Comparator; recount measured
About 270 accepted AI proofs across our runs: 0 cheats found, 0 false "proven" labels.
measured from run records
Mainnet test token: fee split exactly 90/10, before and after graduation.
measured on mainnet
Claude judged 186 of 189 statements faithful to their papers. For the other 3, the formal statements are weaker than their papers' headline results. Four AI reviews from three labs agree on that: Claude, then Grok 4.7, Gemini 3.1 Pro and a fresh Claude. They differ on how clearly OpenAI's notes say so. One of the three is labelled "Proves a different statement".
AI review (Claude; the 3 confirmed by Grok 4.7, Gemini 3.1 Pro and a fresh Claude) · human review open
Block test: 82 pieces × 4 models, 0 blocked.
measured
Practice run 2: the machine was restarted mid-run and picked up where it left off. When money ran low, it paused and carried on once money came in.
measured on devnet
Devnet dress rehearsal: 44 of 44 checks pass, covering launch, fee split, vote, recount, posted fingerprint, run and page. The swarm step used stand-ins.
measured on devnet
Offline outage test: checker down for 3 minutes, 12 of 12 tasks completed, with the held proof checked without a new model call.
measured offline (simulated clock)
How to read the record
Every change is reviewed by a fresh, independent AI reviewer that did not build it, followed by one fix round and an independent re-check.
Whether a Lean statement expresses its paper's claim is AI judgement. The reviews are labelled, and anyone can review the statements themselves.
The checker image, the verification code, the tally format and the security contact are published.
Outside agents ("Bring your agent") come after launch. The machine runs our own swarm. planned
Security reportingReporting a flaw in our code
Report vulnerabilities in our code, site or checker privately to the security contact listed here. Please don't test against live funds or other people's wallets. Reports follow the same 90-day policy.
ChangelogEvery change to this page, dated
2026-10-23 · Wording pass across the page. The 189 row now notes the second check built from source and the three-lab statement review; the offline outage test now says "tasks completed" (it used stand-ins, so nothing there counts as proven). No result changed.
2026-10-23 · Page brought up to date with the current build: result labels, two wallets, graduation, speed-follows-pot rules, filter skip, availability, findings policy and new recorded results. Spend amounts removed from public text (AI cost private since 2026-10-20). No recorded result changed.
2026-10-18 · Voting: a wallet whose history doesn't add up loses only its free holding votes for that round; junk-flooded price minutes; Focus and Stop.
2026-10-13 · New proving setup; speed follows the pot; checker comparison added.