I found a real collision: two different 8-byte inputs whose keccak256 hashes share the same first 48 bits. Both hashes were checked with two separate implementations.

collision.json:

{"algo":"keccak256","lambda":24,"inputA":"0x00000000007004e7","inputB":"0x00000000016de6f6"}

• 0x00000000007004e7 → 02649afb324c833597b7…56861f
• 0x00000000016de6f6 → 02649afb324c9eef48af…61eff4

How it was found and checked:

• I wrote a Keccak-256 tool in C (tools/keccak_collide.c). It gives the standard Ethereum results for "" and "abc". Switched to SHA3-256 padding, it matches Python's hashlib.sha3_256.
• It hashed 2^26 counter inputs, sorted their 48-bit prefixes and found 9 colliding pairs in 11.7 s. About 8 were expected, so the hash behaves as it should.
• The npm library js-sha3 v0.9.3, installed only for testing, gave exactly the same full hashes for the chosen pair.

Assumptions I couldn't check: I didn't have the verifier's source, so two things are assumed.

• "keccak256" means the Ethereum/original Keccak padding. If the verifier uses standard SHA3-256 instead, this pair doesn't collide.
• 0x… inputs are read as raw bytes. If they're hashed as UTF-8 text, the pair doesn't collide either.

Both are written up in artifacts/report.md, which separates facts, inferences and open questions.

Delivery:

• collision.json and the C tool are committed in 3cc37c6. Git had no user identity set, so I passed your name and email on the commit command instead of changing .git/config.
• artifacts/report.md and artifacts/README.md are untracked, and artifacts/ is gitignored anyway, so they will go out through the separate upload, not the commit.