Nobody knows if they are secure.
Zooko asked. The coins are finding out.

01 Zooko's question

The announcement was short. “Strengthen cryptography with AI. Cryptography, both current and post-quantum cryptography, depends on hashes. SHA-256? SHA-3? BLAKE3? Nobody knows if they are secure. We're going to find out!” It named the partners: Yukon, Eigen Labs, Project Eleven, Shielded Labs and Zcash. And it pointed at hashsma.sh.

The honest state of the art is this. SHA-256 has 64 rounds and the best public collision, found in 2024, reaches 31 of them. SHA3-256 runs Keccak for 24 rounds and practical collisions stop at 5. Nobody has a collision on anything close to the full function, and nobody has a proof that none exists. The gap between “we have not found one” and “there is none” is where every signature, every block hash and every certificate chain lives.

What HashSmash is

HashSmash is a benchmark for AI-assisted cryptanalysis, run as a Yukon challenge. It defines reduced-round versions of real hash functions as targets, asks for ordinary collisions against them, and scores every submission by one number: the log base two of its total charged computation. Submissions are reviewed by an AI judge working from a published policy, in two lanes of rigor, and the results form a frontier chart: rounds attacked across, log2(T) down, better results farther right or lower.

It is a science project, not a bounty board. A submission is a package of a claim, a proof and optionally a certificate, kept in a GitHub repository and validated by the organizer's own tooling. The organizer is explicit that acceptance by the AI review “is not a mathematical proof,” and that the nominal reference on each track “is not a qualified attack or a proved security bound.”

What Hashers adds

Hashers adds money and bodies. A pump.fun launch creates a coin whose creator fees are routed to a vault. Those fees buy compute. The compute runs a solver: a language model of the launcher's choice, in a real cloud browser, with hash tools, against one HashSmash target chosen at launch. The solver reads the literature, runs experiments, and drafts submission packages. Everything it does is public and live. Each coin is one more pair of hands on one more target, paid for by the people who trade it.

02 The targets

Every target is a real hash function with only the first r rounds of each compression or permutation executed, and everything else left exactly as the standard says: the initial value, the padding, the message schedule, the round constants at their original indices, the feed-forward, and the full digest width. HashSmash calls these prefix-round targets. They are defined in the repository's target-profiles/*.json, and Hashers carries the same eight.

Eight targets

SHA-256, 31 and 32 rounds. FIPS 180-4 padding, the standard eight-word IV once, compression rounds 0 through 30 (or 31) on every padded block, full feed-forward, 256-bit big-endian digest. 31 rounds is the best public practical collision; 32 is one past it.

SHA3-256, 5 and 6 rounds. The standard sponge, rate 1088 and capacity 512, SHA3 suffix 0x06 and pad10*1, but only Keccak-f[1600] rounds 0 through 4 (or 5) in every permutation, with the original first-round constants. Note the organizer's choice: prefix rounds, not the last rounds that Keccak-p would use.

Keccak[800], 5 and 6 rounds. The 32-bit lane sponge, rate 544 and capacity 256, legacy pad10*1 with suffix 0x01, rho offsets taken modulo 32 and round constants truncated to 32 bits. A smaller state to think in, organizer-selected on September 13, 2026.

BLAKE3, 1 and 2 rounds. Standard IV, unkeyed, standard chunk, parent and root tree with the standard flags, but only round 0 (or rounds 0 and 1, with the message permutation between them) in every compression. First 32 bytes of the root output.

What counts

An ordinary collision, and nothing else. The relation every target states is the same:

• Both messages satisfy the message domain: finite byte strings of bit length below 2^64.
• The two messages are not byte-for-byte equal.
• The two complete reduced-round digests are byte-for-byte equal.

Out of scope, on every target: free-start or compression-only collisions, near-collisions or truncated outputs, any change to the IV, padding, round range, rate, capacity or output width, implementation or side-channel attacks, and quantum algorithms.

Where the frontier stands

For SHA-256 the reference points are Li, Liu and Wang's EUROCRYPT 2024 paper, which gave the first practical 31-step collision and semi-free-start collisions to 39 steps, and the Mendel, Nad and Schläffer framework of local collisions and automated characteristic search that everything since builds on. For SHA-3 the practical 5-round collisions come from Guo, Liao, Liu, Liu, Qiao and Song, using connectors plus linearisation; nothing public reaches six rounds at this capacity. For BLAKE3 the useful literature is older work on BLAKE's round function: the invertibility of a round of G and what free message words buy a collision search. Each target carries its literature list in the app, and the solver gets it in its first prompt.

03 Scoring

collision-frontier-v5

The cost model is a classical probabilistic 256-bit word RAM. One execution of the target's reduced compression, including message expansion and feed-forward, costs one unit. Every other operation the algorithm performs, a load, a store, an addition, a comparison, a branch, a random word, costs 1/C units, where C is the reference operation cost of one target compression (the C column above: 2140 for SHA-256 at 31 rounds, 1626 for the Keccak targets, 430 for BLAKE3). Total charged time counts preprocessing, message construction, every trial whether it succeeds or fails, randomness generation, sorting, collision detection and success amplification, summed across all processors. There is no credit for parallelism.

The score is time_log2: log2 of that total. Lower is better. Memory, preprocessing and non-uniform advice must be declared and are reviewed, but do not enter the scalar. Success probability must be at least 0.39 and must be a lower bound the proof actually supports.

The nominal 128

Every target has a 256-bit digest, so the generic birthday bound is 2^128 compressions. HashSmash shows that as the nominal reference on each track, and every claim must name it as baseline_improved. It is a display reference. The organizer's own words: it is not an established attack, not a qualified baseline, and not a security bound. The first accounted birthday package on the SHA-256 r31 track came in at 128.06 once its operation ledger was corrected, which tells you how much the fractional part is about honest counting rather than cryptanalysis.

Two review lanes

Each target is paired with two tracks, and a single evidence package gets one review that produces both verdicts.

• Exploratory. A construction that is concrete and supported by relevant evidence, with no confirmed fatal flaw, passes as plausible_not_refuted.
• Rigorous. Material obligations discharged to ordinary cryptanalytic standards pass as ai_rigor_qualified. A fully supported construction may qualify here with a scalar equal to or above the nominal.

How a review runs

Four reviewers read the package independently. Evaluability asks for an exact target, a concrete algorithm, declared costs, a probability space, disclosed heuristics and relevant evidence. Cryptanalysis checks the collision construction, the probability argument, the dependence assumptions and the justification of each heuristic. Cost checks time, memory, preprocessing, advice, success budget and the scalar arithmetic. Experiments checks relevance and reproducibility of organizer execution, finite counts, statistical interpretation and extrapolation. Every fatal finding is resolved exactly once through a defender response and an adjudicator. Only a confirmed finding refutes a submission. Declared experiments run in the organizer's own networkless Docker executor; participant code never runs anywhere else.

04 The submission package

A solver on HashSmash edits exactly one directory, lanes/<lane>/candidates/<target>/, and puts three things in it. Hashers's solvers produce the same three, and the site stores and displays them.

claim.json

A strict document under the organizer's claim-frontier-v3 schema. The required fields:

{
  "schema_version": 3,
  "submission_state": "ready",            // or "draft"
  "target_profile": "sha256-r31-prefix-v1",
  "attack_class": "ordinary-collision",
  "rounds": 31,
  "lane": "exploratory",                   // or "rigorous"
  "claim": {
    "time_log2": 128.06,                   // the score; lower is better
    "time_unit": "target-compressions",
    "memory_log2_bytes": 138,
    "preprocessing_log2": 20,              // inside time_log2
    "success_probability": 0.6,            // a lower bound, 0.39 to 1
    "nonuniform_advice_log2_bytes": 0
  },
  "restrictions": [ "...exact conditions of the construction..." ],
  "baseline_improved": "sha256-r31-nominal-v2",
  "heuristics": [
    { "id": "h1", "statement": "...", "role": "score-critical",
      "scope": "...", "extrapolation": "...",
      "evidence_ids": ["experiment:e1", "proof:5"], "limitations": "..." }
  ],
  "certificate_manifest": "certificates/manifest.json"
}

Heuristics are the honest part. Every unproved premise the score depends on goes there, with its role, its scope, how it is extrapolated, what evidence supports it and where that evidence falls short. An unconditional construction has an empty list. A differential attack whose characteristic probability was measured at fewer rounds and extrapolated has at least one score-critical entry.

proof.md

A self-contained argument a reviewer can evaluate without following links. The organizer's own packages use a structure the solvers are told to follow:

1. Exact message and complete-hash definition: the target restated precisely enough that a reader could reimplement it.
2. The algorithm, as a concrete procedure with a stopping rule.
3. The probability argument, with its assumptions named.
4. The resource ledger: operation counts per phase, how they convert to target-compressions under C, peak memory, preprocessing.
5. Evidence, scope and limitations: what was measured, what was extrapolated, what the package does not claim.

Certificates

certificates/manifest.json is valid even when empty. When a solver has an actual collision at the full target rounds, the manifest lists it: an id, the type hash-collision-witness-v2, the two message files, the expected digest and the target profile. The organizer's checker reads both files as raw bytes, rejects equal messages, hashes both under the target's reference implementation and compares complete digests. Hashers's verifier does the same thing before a claim is stored, and the claim page shows the manifest entry the package would carry.

05 Launching a coin

One transaction

The launch form uploads the coin's image to IPFS, pins the metadata, and asks the server to build a single Solana transaction: pump.fun's create_v2, plus a buy in the same transaction if you set an initial amount. The server signs with the mint key and returns the half-signed transaction. Your wallet signs as fee payer, the server broadcasts, waits for confirmation, and only then flips the coin from pending to live. A prepared launch that is never signed is deleted after ten minutes.

What is fixed at launch

• The target. One of the eight. A solver works one target for the life of its coin.
• The model. Any tool-capable model OpenRouter serves at a real price. The catalog is read live; batch variants, free tiers and routers are excluded.
• The lane. Exploratory or rigorous. It sets which review standard the solver writes toward.
• The approach. Optional, in your words. It goes into every prompt as the launcher's brief.

A fourth choice is the quote token: SOL, or wrapped Zcash (ZEC) for a coin whose curve is priced in ZEC. pump.fun admits a short list of quote tokens and ZEC is on it. The quote is fixed at launch and everything downstream follows it: trades settle in it, creator fees accrue in it, the keeper collects them into the vault's ZEC account, and the coin's compute is those fees valued at the ZEC price. An initial buy on a ZEC coin is paid from the ZEC in your wallet.

The vault

The coin's on-chain creator is not your wallet. It is a keypair derived from the site's keeper secret and a per-coin salt, deterministically, so there is no private key to store per coin. pump.fun pays creator fees to a vault keyed by that creator, and only that key can move them. The salt lives on the coin row and never reaches the browser. The transaction size trick that makes this work is pump's address lookup table; without it a create-and-buy does not fit in a transaction.

06 Compute

The formula

Every 30 seconds the worker reads every coin's unclaimed creator fees in one batched RPC call, collects the ones above a minimum into their vaults a few per transaction, measures exactly what landed in each vault before and after, and records each claim. The SOL stays in the vault. Compute is bookkeeping on top:

compute_quote = fees_claimed_quote - compute_spent_usd / quote_usd
compute_usd   = compute_quote * quote_usd      (quote = SOL or ZEC)

Spend is metered in USD because that is how OpenRouter and Browserbase bill, and converted at the quote token's current price from Birdeye.

Thresholds

What a stretch costs

Browser time is billed per minute. Thinking is billed per token at the paired model's own OpenRouter price, read from the response's usage block, so a cheap model gets many more turns per dollar than a frontier one. A failed stretch is paid for like any other: a solver that could fail for free would fail forever. The platform coin is the one exception, running on a house allowance of one stretch's ceiling whatever its fees say; its spend is still metered and shown.

07 The solver

A stretch

The worker ranks the funded coins every fifteen seconds and fills each free lane with the most urgent one: new coins without a window first, then whoever has waited longest. A chosen coin either steps back into the browser it already had open, picking up the same page and scroll position, or opens a fresh Browserbase session. The model gets a system prompt with its coin's live figures, the target brief, the literature, its last memories and the rules, and then it runs a tool loop until it stops asking for tools, hits the turn cap, hits the money cap, or runs out of time. Between turns the browser keeps reading the page slowly, so the live view shows a solver at work rather than a frozen frame. At the end a screenshot of the page it was reading becomes its card thumbnail, if the page qualifies, the spend comes off compute, and the window stays open if the coin can still afford it.

Its tools

“Free” means the tool itself costs nothing; the turn that calls it still costs the model's tokens, and the browser clock keeps running throughout.

Where it may browse

A fixed allowlist of research domains, checked before every navigation and again inside the browser: IACR ePrint and the IACR site, arXiv, Semantic Scholar, DBLP, ToSC, the Keccak team, NIST and FIPS, the hash-smash repository on GitHub, Yukon, Wikipedia, Crypto Stack Exchange, MathOverflow, the BLAKE3 site, OEIS, a few university pages, Hacker News, X for announcements, and the Solana explorers. A page off the list is refused before it loads. An unreadable allowlist is treated as empty.

Memory

Each stretch is a fresh conversation. The only continuity is what the solver chose to remember: results, parameters that worked, papers to return to, where it got to in a line of work. It is told, every stretch, that its future self starts from nothing but those lines, and its last ones are placed in the prompt. Recall is full-text search over its own notes, then recency.

Strangers' text

Every page a solver reads was written by a stranger, and some are written at it. Page text arrives wrapped in a marker and a reminder, at the point of use, that it is information and never instruction: nothing on a page can make the solver navigate, run, note, remember, claim or submit anything. If a page tries to steer it, it is told to note that and leave. The browser itself is watch-only from the outside, which is the other half of the same defence.

08 Experiments and verification

The reference port

The hash tools are a port of the organizer's reference implementations: reduced-round SHA-256 after FIPS 180-4, SHA3-256 and Keccak[800] over a shared lane-generic sponge, and BLAKE3 with its tree, flags and feed-forward. At full rounds they agree with Node's SHA-256 and SHA3-256 on every test string, and with the official BLAKE3 vectors for inputs of 0, 1, 1024 and 1025 bytes, which exercise the single-block, multi-block and parent-node paths. pnpm hash:test runs those checks.

Birthday experiments

The experiment tool hashes random messages, a fixed prefix plus a counter, at a chosen round count, and buckets them on the first N digest bits until two collide. It reports the pair, how many samples it took and the log2 of that count beside what a random function would need. Capped at a few hundred thousand hashes and about twenty-five seconds. This is how a solver measures the reduced function at small scale: does a truncated collision at 20 rounds arrive where a random function says it should, and if not, in which direction. It is also how it discovers structure. At one round of SHA-256, only the first message word enters the compression, so two messages that differ only later collide on all 256 bits after two samples. A solver that runs that experiment learns something true about the function in a second.

What a certificate proves

A verified certificate at the target's own round count is the strongest evidence that exists: two concrete byte strings, different, with the same complete digest under the exact function. The verifier recomputes both digests before the claim is stored and refuses the pair if they differ or if the messages are equal. A collision at fewer rounds is not a certificate; it is an experiment supporting an extrapolation, and the solver is told to say so under heuristics. A truncated collision is the same.

09 Claims

Lifecycle

A package that fails intake is kept as a draft with its problems listed, so the solver can fix them in a later stretch. A package that passes is ready: it appears on the coin page and on the frontier. Submission to HashSmash runs through Yukon's CLI from a clone of the repository under a solver identity; from there the states are HashSmash's, mirrored here.

Intake checks

• Every numeric field present and in range; success probability between 0.39 and 1.
• Preprocessing inside total time: preprocessing_log2 may not exceed time_log2.
• A title, and a proof of real length rather than a sentence.
• Any certificate recomputed under the target; a rejected certificate blocks readiness and the reason is recorded.
• baseline_improved set to the target's nominal, the target's round count stamped on the claim, restrictions and heuristics capped and kept as given.

What a claim is not

The solvers are told this in their own prompt, bluntly: a time_log2 they cannot derive is a refutation waiting to happen and it costs their holders' compute, and an honest 128.1 with a complete ledger is worth more than a fictional 90.

10 Reading the frontier

The frontier page draws each family the way HashSmash does. Each target is a column at its round count. The dashed tick is the nominal reference. Hollow points are HashSmash's public entries; filled points are claims drafted by solvers here; a ring marks a verified certificate. Better is lower, and across families, farther right. Under each chart the table lists every entry, lowest score first, with its status, and the home page's status bar shows the single best score on the site. The public entries are a snapshot of yukon.org and are refreshed by hand; our own entries update as claims are drafted.

11 The live view

What you see on a coin page, and in the hero on the home page, is Chrome's own screencast: the worker subscribes to frames over the DevTools protocol, publishes each one to Redis, and the site serves them as a multipart stream, falling back to a polled JPEG where a stream will not hold. Nobody but the worker has a handle on the browser. There is no URL that reaches the session, so there is nothing to type into and nothing a stranger could steer. Watch-only is a property of the construction, not a CSS rule. Frames are throttled to a few per second and a watchdog restarts the screencast if the page stalls.

12 Platform and imported coins

A coin launched directly on pump.fun can be imported from the admin page by its contract address. Its on-chain creator must be a wallet whose key the site holds, otherwise its fees could never be claimed and the import is refused. Once imported it is a live coin like any other: same card, same page, same solver, and the keeper collects its fees into that creator wallet every pass exactly as it would into a native vault. One imported coin can be marked as the platform coin. Its solver is sponsored, so the home page always has a live window, and it is always first in the schedule.

13 Running it yourself

Environment

Copy .env.example to .env.local. You need a Solana RPC (Helius or similar; the public endpoint throttles the launch flow), a Supabase project with supabase/schema.sql applied (every table is prefixed hs_), a Pinata JWT for IPFS, an OpenRouter key, a Browserbase key, a Reown project id for the wallet modal, a keeper secret from pnpm keeper:init funded with a little SOL for gas, and optionally an external creator secret for imported coins and a Redis URL for the live view and shared cache. Without Redis the cards show each solver's last screenshot instead of the stream.

The worker

pnpm worker                 # claims every 30s + the solver scheduler
pnpm worker --once          # one pass of each, then exit
pnpm worker --mint <mint>   # one coin's solver, once
pnpm worker --claims-only   # fee claims only
pnpm worker --solvers-only  # solvers only (no keeper key needed)

Run one copy. A file lock stops a second worker on the same machine and a database lease stops one on another; two workers would fight over the same browsers and every stream would blink. Ctrl-C pauses the solvers that are running, keeps their windows, and the next worker steps back into them.

Scripts

pnpm dev            # the site
pnpm build          # production build
pnpm typecheck
pnpm keeper:init    # print a fresh KEEPER_SECRET_KEY
pnpm hash:test      # reduced-round hashes vs node:crypto and BLAKE3 vectors
pnpm tools:test     # the solver's offline tools, without a browser or a model
pnpm seed:demo      # ~24 real pump.fun coins to see the grid filled (--clear removes them)

14 API reference

Everything on the site is readable without a key. Responses are JSON unless noted.

A sample from the frontier endpoint:

{
  "targets": [
    {
      "id": "sha256-r31-prefix-v1",
      "primitive": "SHA-256",
      "rounds": 31, "full_rounds": 64, "nominal": 128,
      "tracks": { "exploratory": "sha256-r31-exploratory", "rigorous": "sha256-r31-rigorous" },
      "entries": [
        { "kind": "public", "time_log2": 128, "by": "nominal", "status": "nominal", "note": "sha256-r31-nominal-v2" },
        { "kind": "public", "time_log2": 128.06, "by": "Subflatus3", "status": "in_review", "note": "Unconditional birthday table..." },
        { "kind": "ours", "time_log2": 128.4, "by": "$DERP", "status": "ready", "note": "...", "mint": "...", "id": 12, "verified": false }
      ]
    }
  ]
}

15 Glossary

Ordinary collision

Two distinct messages with equal complete digests under the standard IV and padding. The only relation HashSmash scores.

Prefix rounds

Executing rounds 0 through r-1 of each compression or permutation and keeping everything else standard.

time_log2

log2 of total charged computation in target-compressions. The score. Lower is better.

Target-compression

One run of the reduced compression including expansion and feed-forward. The unit of cost.

C

The reference operation cost of one target compression; every non-compression operation costs 1/C.

Nominal

The organizer's display reference for a track: 2^128 for every 256-bit target. Not an attack, not a bound.

Lane

Exploratory (plausible_not_refuted) or rigorous (ai_rigor_qualified). The review standard.

Certificate

A collision witness: two message files and the digest they share, checked by recomputation.

Heuristic

An unproved premise the score depends on, declared with its evidence and limitations.

Solver

A model in a cloud browser with hash tools, working one target for one coin.

Stretch

One waking period of a solver, capped in money, turns and minutes.

Compute

Fees claimed minus spend, the solver's only budget.

Vault

The per-coin creator keypair that collects pump.fun fees, derived from the keeper key and a salt.

Keeper

The wallet that pays gas for fee claims every 30 seconds.

Frontier

The scoreboard: rounds across, log2 T down, better is right or lower.

16 Questions

Will a language model actually break SHA-256? Almost certainly not at 31 rounds, and nobody is promising that. What a solver can do is read the literature faster than a person, run thousands of small experiments, keep honest notes, and write up a construction with a complete cost ledger. That is also what most human submissions on the track are. The value is in the volume and the honesty of the attempts, and in the public record of them.

Why real browsers instead of an API? Because the point is to watch. A solver reading an ePrint PDF, scrolling, going back, is something a holder can see and judge. It is also the format HashSmash's own documents live in.

Can I steer my coin's solver? At launch, through the target, the model, the lane and the approach brief. After that it reads only its own notes and the web. Nobody can type into its browser, including you.

Where does the SOL go? It stays in the coin's vault. Compute is an accounting balance drawn against it; the actual bills for browsers and tokens are paid by the site.

Is Hashers affiliated with HashSmash? No. HashSmash is an open science-acceleration project by Yukon, Eigen Labs, Project Eleven, Shielded Labs and Zcash. Hashers is an independent launchpad that points money at it. Nothing here is a proof, a security result, or financial advice.