killcord
A censorship-resistant dead man's switch that automatically publishes encrypted secrets to IPFS via Ethereum smart contracts.
What is killcord?
Killcord is an archived prototype of a censorship-resistant dead man's switch system that automatically releases a decryption key for a publicly accessible encrypted payload if the owner fails to check in within a predefined time window. It leverages Ethereum smart contracts for trustless state management and IPFS for decentralized storage of the encrypted data. The system is designed to enable posthumous or emergency data release without relying on centralized authorities.
Developers and researchers interested in experimenting with decentralized technologies like Ethereum and IPFS for building trustless, automated data release mechanisms. It is suited for those exploring concepts of digital legacy, censorship resistance, or secure dead man's switches in a prototype context.
Developers might choose Killcord for its unique integration of Ethereum smart contracts as a trustless source of truth and IPFS for immutable, decentralized storage, creating a fully automated and censorship-resistant system. Unlike simple timer-based solutions, it provides a programmable, blockchain-backed mechanism where publication rules are enforced by smart contracts, reducing reliance on third-party trust.
Overview
a censorship resistant deadman's switch
Use Cases
Best For
- Experimenting with dead man's switch implementations using Ethereum and IPFS for academic or personal projects.
- Building prototypes for posthumous data release systems where automatic key publication is required upon owner disappearance.
- Creating censorship-resistant data storage and release mechanisms that leverage decentralized networks.
- Developing trustless systems where state management and publication logic are enforced by smart contracts.
- Exploring the integration of IPFS for immutable payload storage with blockchain-based trigger conditions.
- Researching decentralized autonomous agents (like the publisher) that monitor smart contracts and execute actions based on time-based rules.
Not Ideal For
- Production systems requiring reliable, maintained software for critical or life-dependent data release.
- Teams lacking expertise in Ethereum smart contract deployment, IPFS node management, and cryptographic key handling.
- Applications needing simple, server-based dead man's switches without the complexity of blockchain transactions and decentralized storage.
- Projects where data privacy is paramount and payloads must never risk public exposure, as IPFS storage is treated as eventually public.
Pros & Cons
Pros
Leverages Ethereum smart contracts as a censorship-resistant source of truth and IPFS for immutable payload storage, eliminating reliance on centralized authorities. The README highlights this as core to ensuring trustless operation and data persistence.
Includes a publisher component that automatically monitors smart contracts and publishes decryption keys based on configurable time thresholds (e.g., 48 hours default). This enables hands-off operation for posthumous data release without manual intervention.
Provides a command-line interface with commands for initialization, encryption, check-ins, and status checks, simplifying project management. The README details steps like 'killcord init' and 'killcord checkin' for owner control.
Designed as a prototype for experimenting with decentralized technologies, offering insights into dead man's switch implementations. The README positions it as a toy project for exploring claims made by IPFS and Ethereum, suitable for learning and research.
Cons
The project is explicitly marked as archived with no future updates or support, making it risky for any ongoing or production use. The README's opening note states it's left up for historical reasons only, with no maintenance planned.
In early alpha with undiscovered bugs that could compromise system integrity, as warned in the README. It has not undergone proper peer-review, and flaws in implementation or encryption might lead to premature data exposure.
Setting up the publisher requires manual configuration and scheduling using tools like cron or custom AWS Lambda setups, described as the 'least mature part' in the README. This adds operational overhead compared to turnkey solutions.
Payloads stored on IPFS are treated as eventually public, with no recourse if decrypted early due to bugs, key compromise, or funding issues. The README emphasizes this as a critical consideration, warning that data should be intended for public release.
Frequently Asked Questions
Related Projects
IPFS DesktopAn unobtrusive and user-friendly desktop application for IPFS on Windows, Mac and Linux.
PeergosA p2p, secure file storage, social network and application protocol
PlanetBuild and host decentralized blogs and websites on your Mac
archiveweb.pageA High-Fidelity Web Archiving Extension for Chrome and Chromium based browsers!
Found a gem we're missing?
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.