A **hash collision** occurs when multiple distinct inputs produce the same hash value or map to the same hash bucket. In adversarial contexts (on-chain tables, maps or hash tables), an attacker who can craft many colliding keys can concentrate operations on a single bucket, driving up compute/gas cost and causing insertion/lookup failures. This is a pure collision problem — not a logic bug in higher layers — where the attack surface is the mapping from input → bucket.

Remediation

• Use a collision-resistant hash for bucket assignment where adversarial inputs are possible (e.g., Keccak256 / SHA-256 / BLAKE2).
• Prevent attacker control of the hash seed/salt; derive any seed from contract-controlled, non-influenceable entropy.
• Limit per-bucket growth: enforce bucket size caps, per-caller insertion quotas, or per-tx insertion limits to bound worst-case cost.
• Design table operations to be incremental and gas-bounded (avoid single transactions that must traverse an unbounded bucket).
• Add on-chain detection and fail-safe behaviour: if a bucket exceeds thresholds, reject further inserts and surface an alertable event rather than attempting expensive processing.
• Apply economic friction for bulk inserts (fees, stake or collateral) so mass collision creation becomes costly.