CosmicLedger MVP

Overview
- A minimal, offline-first verifiable ledger designed for partitioned networks (e.g., interplanetary missions).
- Local append-only ledger with cryptographic signatures, Merkle-DAG proofs, and delta-based reconciliation.
- A simple Data Contracts Registry to define and version mission data schemas (Telemetry, SensorData, Event, Command, Hazard).
- Delta export/import to synchronize logs between nodes with compact proofs.
- Optional cloud-ground anchoring concept (not implemented in this MVP).

What you can run here
- A tiny Python package that provides: LocalLedger, DeltaLog, DataContractRegistry, and a tiny Signer using HMAC.
- test.sh script to build and run a basic cross-node delta replication scenario with two ledgers using the same signer key.

How to use (high level)
- Create a LocalLedger with a node-specific signer key.
- Register data contracts (Telemetry, SensorData, Event, Command, Hazard).
- Append entries to the local ledger.
- Export a delta since a given index and apply it on another ledger to reconcile.
- Compute Merkle roots to verify log integrity.

Notes
- This is an MVP; cryptographic signing uses HMAC for simplicity in this prototype. In a production setting, you'd replace with Ed25519 or ECDSA and proper key management.
- No external network code is included; delta exchange is simulated via in-process data structures for MVP validation.

Contributing
- See AGENTS.md for architectural rules and testing protocol.

License: MIT

Improvements (Post-MVP Goals)
- Cloud anchoring: Optional anchoring of log roots to a trusted ground anchor for long-term verifiability across partitions.
- Governance ledger: Lightweight event-sourced log for data-access decisions, policy changes, and contract amendments.
- Delta proofs: Plan to extend delta exports to include compact Merkle proofs for selective entry verification.
- Interoperability bridges: Start mapping core primitives to canonical data schemas for ecosystem interoperability.
- Observability: Instrumentation for proof sizes, reconciliation latency, and data-integrity guarantees.

READY_TO_PUBLISH marker is created when this MVP is deemed production-ready in a real SWARM build.