feat:added ledger

[vinaysingh8866]

Ledger Protocol 1.0

Summary

Adds the Ledger Protocol v1.0 — a DIDComm v2 protocol for peer-to-peer shared expense tracking and settlement between agents, like a decentralized Splitwise built on DIDComm.

• Two or more agents maintain a shared, tamper-evident expense ledger with hash-chained, dual-signed entries
• Flexible split types: equal, exact amounts, percentage, and ratio-based shares
• Net balance computed from confirmed entries — no central server needed
• Settlement triggers the Payments 1.0 protocol via pthid correlation, with cryptographic proof linking (session_id + tx_ref) back to the ledger
• Group settlement optimization minimizes the number of payment flows for 3+ participants
• Offline-tolerant sync with sequence-based reconciliation and hash chain verification
• Entry disputes, adjustments, and voiding with full audit trail

Protocol Details

PIURI: https://didcomm.org/ledger/1.0

Messages (11):

Message	Purpose
create	Propose a new shared ledger with rules, currency, and participants
accept	Accept a ledger proposal
entry	Add an expense (amount, split, description, category)
ack	Countersign an entry to confirm it
reject	Dispute an entry with a reason code
adjust	Void a previous entry and replace it with a corrected one
settle	Propose settling the outstanding balance (triggers Payments 1.0)
settle-confirm	Confirm settlement received with payment proof
sync-request	Request missing entries after being offline
sync-response	Return entries since a given sequence number
close	Propose closing the ledger

Key Design Decisions:

• Hash-chained entries — each entry includes prev_hash = SHA-256(previous_entry) regardless of status, creating a tamper-evident append-only log between peers
• Dual signatures — creator signs, all other participants countersign via ack. No single party can fabricate confirmed entries.
• Balance is computed, never stored — derived from confirmed entries, always independently verifiable by any participant
• Payments 1.0 integration — settlement uses pthid for thread correlation, terms.request_id references the settle message, and settle-confirm links back session_id + tx_ref as proof
• Group settlement optimization — minimum-transfers algorithm reduces pairwise settlements for 3+ participants
• Offline sync — sequence + hash based reconciliation; offline entries are treated as pending proposals resolved via normal ack/reject flow

Composition

Protocol	Integration
Payments 1.0	Core — settlement triggers full Payments handshake flow
Signing 1.0	Optional — entry signatures, complex approval flows
Vaults 1.0	Optional — encrypted ledger archival via ContentRef
Workflow 1.0	Optional — model recurring splits as workflow templates
Discover Features 2.0	Advertise split types, max participants, settlement support

Security

• Hash chain integrity prevents history tampering
• Dual signatures prevent entry fabrication
• Settlement entries reference Payments session_id + tx_ref — can't fake without real payment
• Sign-then-encrypt recommended for non-repudiation
• Entry TTL auto-voids stale pending entries
• DIDComm v2 encryption ensures only participants see ledger data