ChainCustody

Inspiration

Security incident evidence is only as trustworthy as the system storing it. If an attacker gets admin access, or an insider wants to hide their tracks, logs can be quietly altered — this is a documented technique (MITRE ATT&CK T1070, Indicator Removal). Existing tamper-evident logging tools (e.g. Azure SQL Ledger) are still controlled by a single admin, so a compromised admin defeats the whole point. We wanted to know: could evidence integrity be verified by multiple independent parties, so no single compromised account could rewrite history undetected?

What it does

ChainCustody is designed to ingest security events, compute a cryptographic hash of each one, and anchor that hash on-chain via a smart contract that only finalizes once a 2-of-3 signature threshold (SOC analyst, compliance officer, external auditor) is met. Raw evidence stays off-chain for privacy; only hashes, signer identities, and timestamps are ever written to the ledger. Full technical detail is in our attached Phase 1 proposal.

How we built it

This project is currently at the Phase 1 concept-proposal stage. No code has been written yet, per competition rules — development begins during the Phase 2 24-hour build (October 10–11, 2026). This section will be completed with real implementation details after that build.

Challenges we ran into

To be completed after Phase 2.

Accomplishments that we're proud of

To be completed after Phase 2.

What we learned

To be completed after Phase 2.

What's next for ChainCustody

Real multi-party verifier nodes (SOC, compliance, external auditor) run by genuinely separate organizations, not simulated locally
Integration with existing SIEM/log pipelines
Formal evaluation against NIST SP 800-86 / ISO/IEC 27037 forensic standards