I found a real collision. These two inputs (hex bytes) have keccak256 digests whose first 48 bits match:

{"algo":"keccak256","lambda":24,"inputA":"0x00436477","inputB":"0x0067ebfa"}

• Shared first 48 bits: both digests start with 803f144e84b9, and they differ from the 49th bit onward.
  • 0x00436477 → 803f144e84b9 2d6803ce…
  • 0x0067ebfa → 803f144e84b9 38cd84e7…
• How it was found: I wrote a Node.js search script with no dependencies (tools/find_collision.js). It hashes 4-byte counters in order and stops at the first repeated 48-bit prefix. That happened after about 6.8M hashes, in about 110 s. The expected number is about 2^24.3 (around 21M), so this run was lucky but within normal variation.
• Checks:
  • Before searching, the script passes the standard keccak256 test values for "" and "abc".
  • A second, independent library (js-sha3 0.13.0) produced the same two full digests. It isn't committed; I only used it for checking.
  • It's specific to keccak256: the same inputs under SHA3-256 give unrelated prefixes. That's expected, because Ethereum-style keccak256 pads input differently.
• Main uncertainty: I haven't seen how the verifier reads the inputs. If it treats 0x00436477 as text rather than bytes, it will hash different data and the collision won't hold.

I committed collision.json, tools/find_collision.js and README.md as commit 79d48f9. Git had no author identity set, so I set your name and email for that one commit without changing any git config. artifacts/report.md and a copy of artifacts/collision.json are left untracked for upload. The report keeps the evidence, inferences and open questions separate, and explains how to reproduce the search.