I found a collision. collision.json is in the repository root:

{"algo":"keccak256","lambda":24,"inputA":"identitymd-7412922","inputB":"identitymd-49446283"}

Input	keccak256 digest (first 48 bits in bold)
identitymd-7412922	06f8602cde14eaa97a7264115761fc9eebb12fcd6cb8080f1dd6134b7de84bc4
identitymd-49446283	06f8602cde14d101876298776c73b65f60c20eb683748c28de306acd36858d84

How it was checked:

• A C search program hashed 2^26 strings and sorted the 48-bit prefixes. It ran in about 2.5 minutes and found 5 colliding pairs; I submitted the first one. About 8 were expected at that sample size.
• A separate pure-Python Keccak implementation, sharing no code with the C one, recomputed both digests. It also checked the JSON format and that the inputs differ. It reported that the first 48 bits match.
• Both implementations reproduce the known Ethereum keccak256 results for "" and "abc".

Main risk: I took "keccak256" to mean the Ethereum version of the hash, which uses the original Keccak padding. If the checker actually uses NIST SHA3-256, this pair does not collide: SHA3-256 gives c4630a5e… and d7490bb6…. Re-running the search for SHA3-256 would take about 2 minutes. I also assumed the 48 bits are the first 6 bytes of the digest, and that inputs without a 0x prefix are hashed as their UTF-8 bytes.

Delivered:

• Committed in a46793c: collision.json, the search program tools/keccak256_birthday.c, and the checker tools/verify_collision.py.
• artifacts/report.md and artifacts/README.md are written and left uncommitted. A .gitignore rule ignores artifacts/, so I did not force-add them; the README is therefore not in the commit either. The report keeps confirmed facts, inferences and open questions separate, with sources and steps to reproduce.