Trovebook Overview
Trovebook is the memory layer of Tythe — an encrypted, verifiable ledger that stores the complete credibility history of every TRIS identity.
It captures verified actions, validations, and proofs as structured receipts, forming an immutable record of how trust is built, earned, and enforced over time.
Each entry in Trovebook is bound to a TRIS ID and classified by metric (Finance, Governance, Security, Compliance, or Sustainability).
This allows Tythe to compute the DISC Score and Metric Health Factors without exposing private data, using zero-knowledge proofs for selective disclosure and off-chain computation.
Core Principles
Verifiable
Each entry carries a proof reference or hash that can be independently verified against DISCRegistry anchors.
Immutable
Once validated, entries become read-only — they cannot be edited or deleted, only superseded through new proofs.
Encrypted
All Trovebook data is encrypted at rest; only selective disclosure proofs expose specific entries when authorized.
Contextual
Every entry includes metadata that defines its origin, validation context, and metric tag for accurate attribution.
Privacy-Preserving
ZK-proofs allow credibility validation without revealing underlying data, ensuring user sovereignty and confidentiality.
Entry Lifecycle
1. Submission
Actor submits a new record — either manually (off-chain) or automatically (on-chain action or system integration).
2. Validation
Validator confirms authenticity of the proof (for off-chain data) or Tythe auto-verifies on-chain transactions.
3. Anchoring
Once validated, the entry’s hash is queued for inclusion in the next Trovebook Merkle batch anchored via DISCRegistry.
4. Computation
DISC Engine ingests validated entries, adjusting TCT and recalculating DISC Scores and Metric Health Factors.
5. Disclosure
Authorized viewers or systems may request ZK-proofs or selective attestations to confirm specific historical data.
Pending Submissions: Enteries pending validation. Can be edited or deleted. Qurantined Submission: Rejected entries awaiting deletion, edit, or re-submission for validation.
Entry Classification
On-chain
Auto-verified via smart contracts
Staking, repayment, validator uptime, DeFi actions
Off-chain (attested)
Verified by 3rd party validator organizations.
Educational certifications, research output, compliance records
On-chain (validated)
Verified by VP active organizations.
Platform defined Validation Policy (VP) triggers for meaningful contributions.
Access & Control
Individuals
Submit, edit pending entries, disclose selectively
Build and manage personal credibility ledger
Developers
Sync data from linked entities, manage app-level trust records
Integrate multi-identity memory across projects
Organizations
Verify, attest, and audit credibility proofs
Serve as validators and compliance verifiers
AI Agents
Maintain behavioral trace memory, linked to Registrant TRIS
Enable transparent, registrant-bound accountability
Data Anchoring
Validated Trovebook entries are batched into daily Merkle roots and published through the DISCRegistry.
This ensures every proof or action logged in Tythe’s memory layer is verifiable, timestamped, and tamper-evident — without requiring full data exposure on-chain.
Selective Disclosure
Actors retain full ownership of their Trovebook data.
Disclosure occurs only when:
A DISC Report is generated.
A DISC Policy check requires proof.
A third-party verifier requests ZK-validated confirmation.
Every disclosure is granular, revocable, and tracked with a proof receipt — guaranteeing both transparency and control.
Last updated
Was this helpful?