The problem Eternal Ledger solves

Eternal Ledger

Decentralized Birth-to-Death Identity and Verification Registry

1. Project Overview

Eternal Ledger is an identity lifecycle platform that records key events from birth to death using decentralized blockchain technology. Each person receives a unique, portable digital identity at birth, maintained with verifiable attestations by trusted organizations (hospitals, registrars, NGOs, funeral homes). At verified death, the system mints an immutable Soulbound Death Token (SDT) to signal closure, streamlining automated processes for service providers, benefits systems, and estate executors.

Key Objectives:

• Provide tamper-evident civil registration, accessible across borders and institutions

• Enable standardized, privacy-preserving proof of life events (especially “death status”)

• Automate downstream workflows (pension cessation, subscription cancellation, estate execution)

• Support compliance, auditability, global reach, and privacy by design

2. Architecture

2.1 Components

• Smart Contracts: Core registry contracts deployed on Polygon (zkEVM) handle identity issuance, event attestation, and SDT minting.

• Identity Wallets: Each individual is assigned a blockchain wallet—initially under guardian control, transferred to self-custody at adulthood.

• Verifier Registry: DAO-curated list of trusted entities authorized to attest life events, each with keys for signing transactions.

• Off-Chain Storage: Encrypted documents (e.g., certificates, medical records) stored via IPFS or Arweave; only hashes of proof anchors stored on-chain.

• Oracles & APIs: Bridges for automated data relay between Eternal Ledger and external systems (banks, pensions, courts, etc.).

• Governance DAO: Oversees verifier onboarding, schema standards, policy thresholds, and dispute resolution.

2.2 Tech Stack

• Polygon zkEVM: Full Ethereum compatibility, zero-knowledge security, streamlined smart contract deployment.

• Chain Development Kit (CDK) & Avail: Modular Layer 2 toolkit for data availability, privacy choices (zk-rollup/Validium), and custom sequencer logic.

• Decentralized Identifiers (DIDs): For flexible, interoperable identity mapping; optional ENS integration for human-readable lookups.

• Encryption: Public-key cryptography ensures document privacy; credentialed access via DAO workflows.

• Oracles: Automated feeds to trigger post-mortem workflows in integrated external systems.

3. Core Features

3.1 Decentralized Birth Identity Creation

• Process: At birth, an authorized entity (hospital/registrar) submits a signed birth attestation.

• Birth ID: On-chain issuance of a globally unique identifier bound to the new wallet.

• Custody: Guardian manages wallet until transition at majority age; emergency handover procedures available.

• Metadata: Minimal public data; sensitive details stored off-chain and encrypted.

3.2 Life Event Attestations

• Verifiers: Checked into registry by DAO; may include hospitals, registrars, NGOs, funeral homes.

• Events: Standardized types (birth, name change, marriage, death).

• Submission: Signed hash of event + encrypted document reference pushed on-chain.

• Schema: Event templates (birth, death, updates) managed by DAO for interoperability.

3.3 Soulbound Death Token (SDT)

• Trigger: Upon verified death, quorum of trusted verifiers submits confirmations.

• Issuance: Non-transferable SDT minted to the individual identity wallet.

• Signal: Canonical “deceased” status forever tied to the wallet.

• Integration: SDT status queryable via APIs, feeds, oracles.

3.4 Automated Post-Mortem Actions

• Subscribers: Service providers (pension, banks, insurers, courts) subscribe to SDT feeds.

• Workflows: Automatic cessation of payments/services, notification to executors, activation of pre-registered mandates.

• Policy Packs: Jurisdictional templates for regulatory requirements (waiting periods, notifications, etc.).

• Consent Delegation: Users and guardians can pre-authorize post-mortem actions or beneficiaries.

3.5 Privacy and Security

• Data Minimization: Only hashes and essential event proofs on-chain; no plaintext PII.

• Off-Chain Encryption: Sensitive documents decrypted only by credentialed parties, via DAO-controlled access.

• Governance: Transparency via audit logs, slashing for verifier misconduct, rotating cryptographic keys.

• Dispute Resolution: DAO-driven processes for contestation; evidence can be submitted for review/reversal.

3.6 Compliance & Child Safeguards

• Regional Compliance: GDPR-aligned data minimization, retention, and lawful disclosure modules.

• Guardian Control: Secure management for child identities, with progressive handover and emergency recovery options.

4. Integration Guide

Challenges we ran into

Challenges Encountered

One of the biggest challenges was integrating multiple components into a cohesive dApp—our smart contracts, IPFS storage, The Graph indexing, and a role-based frontend each came from separate codebases. This caused compatibility issues, mismatched dependencies, and deployment conflicts across environments.

Another major hurdle was handling on-chain + off-chain data synchronization. The smart contract stored minimal identifiers (like NRIC hashes and CIDs), while detailed metadata lived on IPFS. We needed a way to fetch, index, and display this data instantly. The solution was The Graph—we wrote a subgraph to listen for events such as RecordDeath and automatically index both blockchain and IPFS metadata, making it queryable in the frontend.

We also faced access control and user role management challenges. Without an existing permission system, hospitals and normal users shared the same interface, leading to security concerns. We solved this by implementing a role-based login flow, mock KYC for identity binding, and conditional UI rendering to separate hospital tools (registration, CID viewing) from normal user tools (record search, subscription list).

Finally, dependency conflicts—especially with npm and yarn—slowed early progress. We standardized our setup on yarn for frontend + The Graph, and Hardhat for smart contracts, resolving version mismatches and preventing build errors.

Through these challenges, we learned the importance of modular architecture, clear data flow design, and consistent tooling—critical for scaling a decentralized identity and vital records registry.