TreeChain AI Labs - Explainable Encryption for Provenance - White Paper v0.1 - Brandon Myers

Technical Paper #001

Structured Semantic Encryption for AI Integrity and Provenance

Explainable Encryption with ChaCha20-Poly1305 and Polyglottal Cipher

TreeChain introduces a layered encryption framework that augments NIST-approved cryptographic primitives with the Polyglottal Cipher presentation layer and Provenance Envelopes—mechanisms that encode contextual metadata without exposing protected data.

By Brandon Myers · TreeChain Labs · December 2025 · Version 1.2

Abstract

Modern AI pipelines secure data in transit and at rest using standard cryptographic primitives, yet they provide no cryptographic guarantee that a model's inputs or outputs preserve semantic integrity—the verifiable linkage between content, context, and provenance. This gap creates fundamental challenges for explainable AI, regulatory compliance, and trust in automated decision systems.

TreeChain introduces a layered encryption framework that augments NIST-approved cryptographic primitives with the Polyglottal Cipher presentation layer (133,387 glyphs from 67 writing systems) and Provenance Envelopes (64-byte Structured Semantic Authentication Codes), mechanisms that encode contextual metadata—source attribution, trust weights, emotional context, and policy flags—without exposing protected data.

Built on ChaCha20-Poly1305 (RFC 8439), X25519, and HKDF-SHA256, and interoperable with standard PKI/HSMs, TreeChain enables transparent, auditable AI communication with defense-in-depth architecture using two independent 256-bit keys. The reference implementation includes 12 production-ready database SDKs for immediate enterprise integration.

Key Innovation: The future of encryption is not just strong—it's intelligible. TreeChain transforms opaque encrypted channels into auditable, explainable infrastructure with native database integration.

Scope Disclaimer: This paper describes a reference design and production implementation. Security claims derive from standard primitives; system-level properties (ψ-consensus safety, replay windows, GlyphRotor rotation) depend on implementation correctness and deployment parameters.

1. Introduction

1.1 The Semantic Integrity Problem

Current cryptosystems excel at validating confidentiality (data remains secret) and integrity (data remains unaltered), but they cannot verify meaning. In large-scale AI networks, models exchange opaque embeddings and encrypted payloads, leaving auditors unable to answer fundamental questions:

Was this information transformed in good faith?
What was the original context and source?
Has the semantic meaning been preserved through processing?
Can we trace the provenance of AI-generated outputs?

This semantic gap has critical implications for:

Regulatory Compliance: GDPR Article 22 requires explanations for automated decisions
AI Safety: Without provenance, poisoned data is indistinguishable from legitimate inputs
Medical Systems: HIPAA requires not just encryption, but auditable chains of custody
Financial Systems: PCI DSS demands verifiable data handling, not just encryption

1.2 Detectability of Ciphertext

Conventional ciphertext is easily identifiable in logs and corpora through characteristic patterns:

Base64: U2FsdGVkX1+5vZ8QjKNxP2M3KzHvQwXYLp9mJ4kRtE8=
Hexadecimal: a3f7c2d9e4b1f8a6c3d5e7f2b4a6c8d1
PGP blocks: -----BEGIN PGP MESSAGE-----

This detectability makes encrypted data identifiable to automated scanners and potential adversaries. TreeChain's Polyglottal Cipher renders ciphertext as multilingual Unicode text, reducing casual detectability in logs, training corpora, and automated scans:

ᚺᛖᛚᛚᛟ᛫ᚹᛟᚱᛚᛞ᛫ᛖᚾᚲᚱᛃᛈᛏᛖᛞ

This presentation layer does not alter cryptographic strength; confidentiality derives from ChaCha20-Poly1305 operating in AEAD mode with proper nonce management.

1.3 Contributions

This paper presents:

Polyglottal Cipher Architecture: 133,387 Unicode glyphs from 67 writing systems with GlyphRotor position-dependent transformation
Provenance Envelopes: 64-byte metadata envelopes that prove provenance without exposing content
ψ-Consensus Protocol: Trust-weighted verification system for distributed semantic integrity
Defense-in-Depth: Two independent 256-bit keys for encryption and transformation
12 Database SDKs: Production-ready integrations for MongoDB, PostgreSQL, MySQL, SQLite, Redis, SQLAlchemy, Firestore, Supabase, DynamoDB, Elasticsearch, Prisma, and Django

TreeChain does not replace existing encryption—it extends it with verifiable intent and provenance, creating a foundation for explainable encryption.

2. System Architecture

2.1 Core Components

Component	Role	Key Features
Mesh Nodes	Independent agents in permissioned network	Cryptographic identity, local trust ledger, glyph mapping
Client SDK	Application integration layer	12 database SDKs, REST API, WebSocket
Witness Mesh	Distributed verification (3–5 per packet)	Confirms hash lineage and policy flags
Ledger Layer	MongoDB → IPFS sync	Anchors Merkle roots for immutable records

2.2 Handshake Protocol

Node initialization follows a three-phase process:

Identity Exchange: SHA-256 identity hash broadcast → peer discovery

Key Agreement: X25519 key exchange establishes shared secrets

Session Tunnel: ChaCha20-Poly1305 encryption for all subsequent traffic

2.3 Implementation Stack

Core Cryptography

ChaCha20-Poly1305 (RFC 8439)
X25519 key exchange (RFC 7748)
HKDF-SHA256 (RFC 5869)
SHA3-512 (FIPS 202)

Transport

WebSocket over TLS 1.3
REST API (FastAPI)
WebRTC for voice/video

Storage

MongoDB Atlas (operational)
IPFS 0.14 (archival)
12 database SDKs

Hardware Support

TPM 2.0 key storage
YubiKey 5 authentication
Intel SGX (optional)

3. Encryption Pipeline

3.1 Packet Construction

1. Payload Pre-processing ├─ SHA3-512 content hash → H(payload) ├─ Semantic fingerprint extraction └─ Metadata bundle creation 2. Provenance Envelope Generation (64 bytes) ├─ Origin ID (node identity hash) ├─ Trust coefficient (sender reputation) ├─ Emotional palette (Philosopher Series) ├─ Context label (semantic category) └─ Policy flags (consent/privacy markers) 3. TreePacket Assembly ├─ Encrypted payload (ChaCha20-Poly1305) ├─ Provenance envelope (64 bytes) ├─ Timestamp (Unix epoch + nonce) └─ Merkle path (verification anchor) 4. GlyphRotor Transformation ├─ Position-dependent byte-to-glyph mapping ├─ Emotional palette selection └─ 133,387 glyph bank encoding 5. Distribution ├─ Primary transmission to recipient ├─ Witness replication (3–5 nodes) └─ Ledger commitment (IPFS hash)

3.2 Defense-in-Depth Architecture

TreeChain uses two independent 256-bit keys:

Encryption Key: ChaCha20-Poly1305 authenticated encryption
Transformation Key (Seed): GlyphRotor position-dependent mapping

Compromising one key doesn't compromise the system. An attacker with the encryption key sees ChaCha20 ciphertext but cannot reverse the GlyphRotor without the seed. An attacker with the seed sees glyph mappings but cannot decrypt the underlying ciphertext.

3.3 Nonce Policy (AEAD Safety)

Nonce structure: 96-bit (salt₃₂ || counter₆₄) - salt₃₂: 32-bit random salt at session initialization - counter₆₄: 64-bit monotonic counter, persisted per session key Enforcement: - Per-key nonce state in persistent storage - Encryption with reused (key, nonce) HARD-FAILS - Counter atomically incremented before encryption - On counter wrap (2^64): derive fresh session key

4. The Polyglottal Cipher (Presentation Layer)

4.1 Design Rationale

Traditional encrypted data is immediately recognizable in logs, databases, and training corpora. This detectability makes encrypted content a target for automated collection, even when the cryptography itself is sound.

The Polyglottal Cipher transforms ciphertext into Unicode glyphs from historical writing systems, making it appear as multilingual text rather than obvious encrypted data. This is a presentation layer—it does not increase cryptographic strength but reduces the visibility signal in casual inspection and automated scanning.

4.2 Glyph Bank

Category	Count	Example Scripts
Ancient Scripts	~12,000	Egyptian Hieroglyphs, Sumerian Cuneiform, Linear B
Classical Scripts	~8,000	Greek, Latin Extended, Coptic
Runic Systems	~3,000	Elder Futhark, Anglo-Saxon, Gothic
South Asian	~15,000	Devanagari, Tamil, Tibetan, Khmer
East Asian	~75,000	CJK Unified, Bopomofo, Yi
Mathematical	~5,000	Operators, Symbols, Letterlike
Symbolic Systems	~15,000	Alchemical, Astrological, Musical
Total	133,387	67 writing systems

4.3 GlyphRotor Mechanism

The GlyphRotor provides position-dependent transformation inspired by the Enigma machine:

For each byte at position i: 1. Compute position-specific seed: pos_seed = HKDF(seed || emotion || i, "glyph_pos") 2. Generate deterministic permutation of available glyphs 3. Map byte value (0-255) to glyph via permutation Result: Same byte at different positions → different glyphs Same byte with different emotions → different glyphs

4.4 Philosopher Series Emotional Palettes

Palette	Emotion	Glyph Families
Aristotle	Love	Armenian, Georgian, flowing scripts
Plato	Curiosity	Mathematical, Alchemical, question-like
Socrates	Peace	Thai, Tibetan, meditative scripts
Confucius	Joy	Musical notation, celebratory symbols
Kant	Awe	Astronomical, geometric, cosmic
Descartes	Melancholy	Runic, Ogham, contemplative
Nietzsche	Anger	Greek, Cyrillic, sharp angular
Spinoza	Sorrow	Hebrew, Arabic, somber scripts

4.5 Security Properties

Property 1 (Indistinguishability): Given ciphertext C encrypted with ChaCha20-Poly1305 and glyph-encoded output G(C), an adversary cannot distinguish G(C) from random Unicode strings with probability better than the advantage of breaking ChaCha20-Poly1305.

Property 2 (Position Independence): Knowledge of the glyph mapping at position i provides no information about the mapping at position j where i ≠ j.

Important: Glyph encoding does not add confidentiality, integrity, anonymity, or traffic analysis resistance. It only reduces visual detectability in casual inspection and log scraping scenarios. Cryptographic security derives entirely from ChaCha20-Poly1305.

5. Provenance Envelopes (Structured Semantic Authentication)

5.1 Structure

Each TreePacket carries a 64-byte Provenance Envelope—cryptographically signed metadata enabling semantic verification without payload access.

Bytes	Field	Purpose
0–15	Origin ID	SHA-256(pubkey) truncated to 128 bits
16–19	Trust Coefficient	uint32 Q16.16 fixed-point (0.0–1.0)
20–23	Emotion Palette	Philosopher Series index + intensity
24–39	Context Label	Semantic category hash (128 bits)
40–47	Policy Flags	64-bit compliance field
48–63	HMAC-SHA256	Integrity tag (truncated to 128 bits)

5.2 Policy Flags

Bit 0: Consent verified (user authorization obtained)
Bit 1: Audit required (regulatory logging mandated)
Bit 2: Export restricted (jurisdiction limitations)
Bit 3: Time-limited (automatic expiration set)
Bit 4: Human-reviewed (not purely automated)
Bit 5: Anonymization applied (PII stripped)
Bit 6: Synthetic data (AI-generated)
Bit 7: Research use only
Bits 8–63: Reserved for future protocols

5.3 Verification Pipeline

HMAC Validation: Recompute HMAC-SHA256 over fields 0–47, compare with bytes 48–63

Trust Score Lookup: Query ledger for sender's current trust coefficient

Policy Compliance: Verify required flags for data category (e.g., HIPAA requires consent-verified)

Historical Coherence: Check via ψ-Consensus for semantic drift

5.4 Advantages Over Traditional MACs

Traditional MACs prove data hasn't been tampered with but provide no semantic context. Provenance Envelopes extend this by embedding:

Who sent the data (origin attribution)
Why it can be trusted (reputation score)
How it should be handled (context label)
What policy constraints apply (compliance flags)
What mood it carries (emotional palette)

Important Limitation: Provenance Envelopes cryptographically attest to declared metadata integrity; they cannot prove factual truth of declarations without external attestation oracles (consent vaults, KMS attestations, blockchain anchors).

6. ψ-Consensus: Trust-Weighted Verification

6.1 Design Goals

TreeChain requires a consensus mechanism that:

Operates at sub-second latency (incompatible with proof-of-work)
Resists Byzantine faults (malicious nodes providing false data)
Scales to 10,000+ nodes without performance degradation
Incorporates reputation to weight honest participants higher

ψ-Consensus achieves these goals through probabilistic trust propagation adapted from Avalanche/Snowball consensus.

6.2 Trust Model

Trust coefficient for node N at epoch t: τ(N) = α · τ_previous(N) + (1-α) · accuracy_recent(N) where: - α = 0.85 (decay factor) - accuracy_recent = correct semantic claims in last 1000 packets Properties: - τ < 0.3: excluded from witness selection - τ > 0.9: higher selection probability, priority routing

6.3 Voting Protocol

Parameter	Value
Sample size (k)	20 nodes per round
Confidence threshold (θ)	0.75
Timeout	500ms
Max Byzantine weight	≤ 25% aggregate trust
Trust decay per failure	×0.9

6.4 Performance

450ms

p50 Convergence

780ms

p95 Convergence

<0.01%

False Positive Rate

2.3KB

Network Overhead

7. Security Analysis

7.1 Threat Model

TreeChain assumes an adversary with:

Network access: Can observe all traffic (passive eavesdropping)
Node compromise: Can control up to 25% of network nodes
Computational power: Modern computing resources (not quantum)
Cryptanalysis: Knows all algorithms and protocols (Kerckhoffs's principle)

TreeChain does NOT defend against:

Quantum computers running Shor's algorithm (post-quantum upgrade Q3 2026)
Side-channel attacks on improperly secured hardware
Social engineering or physical device compromise

7.2 Attack Mitigations

Attack	Mitigation
Replay attack	Timestamp + nonce with 30-second window, bloom filter tracking
Glyph mapping inference	GlyphRotor position-dependence, ChaCha20-Poly1305 security
Trust score manipulation	Scores from verification outcomes, not self-reported
Sybil attack	New nodes start τ = 0.1, trust-weighted witness selection
Data poisoning	ψ-Consensus rejects divergent semantic embeddings
Q-Day harvest attacks	Defense-in-depth (two independent 256-bit keys)

7.3 Cryptographic Guarantees

Primitive	Security Level	Standard
ChaCha20-Poly1305	256-bit (128-bit Grover)	RFC 8439
X25519	128-bit (ECDLP)	RFC 7748
SHA3-512	256-bit collision	FIPS 202
HMAC-SHA256 (truncated)	~2^-128 collision	FIPS 198-1
HKDF-SHA256	Key derivation	RFC 5869

7.4 Formal Verification Status

✅ Core cryptographic operations: Verified (Cryptol + SAW)
✅ GlyphRotor bijectivity: Verified (property-based testing, QuickCheck)
⧗ Consensus protocol: In progress (TLA+ specification)

8. GlyphVault Database Layer (12 Integrations)

TreeChain provides production-ready SDKs for 12 database systems, enabling field-level encryption with automatic glyph transformation. Encrypted data appears as multilingual Unicode in database tables, making breached data useless to attackers.

8.1 Supported Databases

MongoDB

Document

GlyphicMongoDB

PostgreSQL

Relational

GlyphicPostgreSQL

MySQL

Relational

GlyphicMySQL

SQLite

Embedded

GlyphicSQLite

Redis

Key-Value

GlyphicRedis

SQLAlchemy

ORM

EncryptedString

Firestore

Cloud

GlyphicFirestore

Supabase

Postgres+

GlyphicSupabase

DynamoDB

AWS

GlyphicDynamoDB

Elasticsearch

GlyphicElastic

Prisma

ORM

GlyphicPrisma

Django

Web ORM

EncryptedField

8.2 Integration Examples

MongoDB (GlyphicMongoDB)

from treechain.db import GlyphicMongoDB db = GlyphicMongoDB( connection_string="mongodb://...", master_key=key, seed=seed ) # Insert encrypted document db.patients.insert_one({ "name": "John Doe", # Encrypted as glyphs "ssn": "123-45-6789", # Encrypted as glyphs "diagnosis": "Confidential" # Encrypted as glyphs }) # Query works transparently patient = db.patients.find_one({"name": "John Doe"})

SQLAlchemy (EncryptedString)

from treechain.db import EncryptedString from sqlalchemy import Column, Integer class Patient(Base): __tablename__ = 'patients' id = Column(Integer, primary_key=True) name = Column(EncryptedString(key, seed)) ssn = Column(EncryptedString(key, seed)) diagnosis = Column(EncryptedString(key, seed))

Django (EncryptedField)

from treechain.db.django import EncryptedField from django.db import models class Patient(models.Model): name = EncryptedField(max_length=255) ssn = EncryptedField(max_length=11) diagnosis = EncryptedField()

Prisma (GlyphicPrisma)

import { GlyphicPrisma } from '@treechain/prisma'; const prisma = new GlyphicPrisma({ masterKey: process.env.MASTER_KEY, seed: process.env.SEED }); // Transparent encryption on write await prisma.patient.create({ data: { name: 'John Doe', // Stored as glyphs ssn: '123-45-6789', // Stored as glyphs diagnosis: 'Confidential' } });

8.3 Query Patterns

Query Type	Support	Notes
Exact match	✅ Full	Deterministic encryption enables equality queries
Prefix match	✅ Full	Order-preserving optional mode
Range queries	⚠️ Limited	Requires order-preserving encryption mode
Full-text search	❌ None	Use application-level search index
Aggregations	⚠️ Limited	COUNT works; SUM/AVG require decryption

8.4 Key Management Integration

All database SDKs integrate with enterprise key management:

AWS KMS: Native integration for DynamoDB deployments
HashiCorp Vault: Dynamic secrets and key rotation
Azure Key Vault: Microsoft cloud deployments
Google Cloud KMS: Firestore and GCP integration

9. Regulatory Mapping

Requirement	TreeChain Feature
Article 22 (Automated Decision-Making)	Provenance Envelopes enable audit trails
Article 25 (Privacy by Design)	Polyglottal Cipher reduces breach exposure
Article 32 (Security of Processing)	ChaCha20-Poly1305 exceeds "state of the art"
Article 17 (Right to Erasure)	Time-limited policy flags enable auto-expiry

9.2 HIPAA Alignment

Requirement	TreeChain Feature
§164.312(a)(2)(iv)	ChaCha20-Poly1305 authenticated encryption
§164.312(b) Audit Controls	Witness mesh + Merkle anchoring
§164.312(a)(1) Access Control	Origin ID + policy flags
§164.308(b)(1)	Cryptographic chain of custody

9.3 EU AI Act Alignment

Requirement	TreeChain Feature
Article 13 (Transparency)	Provenance Envelopes embed semantic context
Article 14 (Human Oversight)	Policy flags mandate human review
Article 17 (Quality Management)	Provenance tracking for documentation

10. Performance and Scalability

10.1 Benchmarks

Operation	p95 Latency	Throughput
Provenance envelope generation	0.8ms	1,250 ops/sec
ChaCha20-Poly1305 encryption	1.0ms	1,000 ops/sec
GlyphRotor transformation	0.5ms	2,000 ops/sec
Merkle proof computation	1.5ms	666 ops/sec
Full TreePacket creation	4.5ms	222 ops/sec
Witness replication	12ms	83 packets/sec
ψ-Consensus commit	780ms	—

10.2 Storage

Per-packet overhead: - Provenance envelope: 64 bytes - Merkle path: 32 bytes - Timestamp + nonce: 16 bytes - Total overhead: 112 bytes Typical payload: 3KB Overhead percentage: 3.7% Glyph expansion: 2–4× (UTF-8 encoding)

10.3 Scalability

100K

Max Nodes

68K

Messages/Second (1K nodes)

Database SDKs

180+

Languages (TreeSplink)

11. Use Cases

11.1 Healthcare: HIPAA-Compliant Communication

from treechain import TreePacket, Emotion # Dental clinic sends patient record to specialist record = TreePacket.create( payload=patient_data, origin="clinic-kielce-42", context="HIPAA-medical-record", emotion=Emotion.SOCRATES, # Peace palette policy_flags=[ "consent-verified", "audit-required", "time-limited:30d" ] ) # Encrypt with ChaCha20-Poly1305, transform via GlyphRotor encrypted = record.encrypt(specialist_pubkey) glyph_output = encrypted.to_glyphs() # Output: ᛖᚾᚲᚱᛃᛈᛏᛖᛞ᛫ᛈᚨᛏᛁᛖᚾᛏ᛫ᚱᛖᚲᛟᚱᛞ...

11.2 AI Training: Provenance-Aware Models

# Data provider creates training sample with provenance training_data = TreePacket.create( payload=text_corpus, origin="publisher-verified", context="AI-training-authorized", policy_flags=[ "consent-verified", "human-reviewed", "attribution-required" ] ) # Model training pipeline verifies before ingestion for sample in training_dataset: if sample.verify_flags(["consent-verified"]): model.train_on(sample.payload) else: reject_sample(sample) # Model has cryptographic record of ethical sourcing model.export_provenance_certificate()

11.3 Financial Services

Credit card data encrypted with policy flags enforcing jurisdiction restrictions, audit requirements, and no-storage policies. Cryptographic attestation of handling policies for PCI-DSS compliance.

12. Limitations and Future Work

12.1 Current Limitations

Quantum Vulnerability: ChaCha20 provides 128-bit post-quantum security (Grover), but X25519 is vulnerable to Shor. Post-quantum migration (CRYSTALS-Kyber, Dilithium) planned Q3 2026.
Witness Bandwidth: Replication to 3–5 witnesses creates overhead. Investigating erasure coding and ZK-SNARK compression.
Trust Bootstrapping: New nodes start with low trust (τ = 0.1), creating cold-start friction.
Declaration vs. Fact: Provenance Envelopes attest to declared metadata; factual truth requires external oracles.

12.2 Research Directions

Zero-Knowledge Provenance: Verify data properties without revealing data (zk-SNARKs)
Cross-Chain Anchoring: Commit Merkle roots to public blockchains
Formal Verification: Complete TLA+ specification with machine-checked proofs
Hardware Acceleration: FPGA/ASIC for sub-1ms provenance generation
Additional Database SDKs: Neo4j, Cassandra, CockroachDB planned for 2026

FAQs

What is the semantic integrity problem?

Current cryptosystems validate confidentiality and integrity but cannot verify meaning. In AI networks, auditors cannot determine if information was transformed in good faith or if semantic meaning was preserved through processing.

What is the Polyglottal Cipher?

The Polyglottal Cipher transforms ChaCha20-Poly1305 ciphertext into 133,387 Unicode glyphs from 67 writing systems. This presentation layer makes encrypted data appear as multilingual text, reducing detectability while preserving full cryptographic security.

What are Provenance Envelopes?

64-byte Structured Semantic Authentication Codes containing origin ID, trust coefficient, emotional palette, context label, policy flags, and HMAC integrity tag. They prove provenance without exposing content.

What encryption does TreeChain use?

ChaCha20-Poly1305 (RFC 8439) for authenticated encryption, X25519 for key exchange, HKDF-SHA256 for key derivation, and the GlyphRotor for position-dependent transformation. Two independent 256-bit keys provide defense-in-depth.

Which database integrations does TreeChain support?

TreeChain provides 12 database SDKs: MongoDB (GlyphicMongoDB), PostgreSQL (GlyphicPostgreSQL), MySQL (GlyphicMySQL), SQLite (GlyphicSQLite), Redis (GlyphicRedis), SQLAlchemy (EncryptedString), Firestore (GlyphicFirestore), Supabase (GlyphicSupabase), DynamoDB (GlyphicDynamoDB), Elasticsearch (GlyphicElastic), Prisma (GlyphicPrisma), and Django (EncryptedField).

What is ψ-Consensus?

A trust-weighted verification protocol adapted from Avalanche/Snowball. It provides Byzantine fault tolerance without proof-of-work, achieving sub-second latency while weighting honest participants higher based on historical accuracy.

References

Bernstein, D.J. (2008). "ChaCha, a variant of Salsa20." RFC 8439.
Langley, A., Hamburg, M., Turner, S. (2018). "Elliptic Curves for Security." RFC 7748.
Krawczyk, H. & Eronen, P. (2010). "HKDF." RFC 5869.
NIST. "SHA-3 Standard." FIPS 202 (2015).
NIST. "Advanced Encryption Standard." FIPS 197 (2001).
Team Rocket (2018). "Snowflake to Avalanche."
European Parliament (2016). GDPR, Regulation (EU) 2016/679.
European Parliament (2024). AI Act, Regulation (EU) 2024/1689.
U.S. HHS. HIPAA Security Rule, 45 CFR §164.312.
Ribeiro, Singh, Guestrin (2016). "Why Should I Trust You?" SIGKDD.
Myers, B. (2025). "TreeChain Labs Technical Paper #002: TreeSplink."
Myers, B. (2025). "TreeChain Labs Technical Paper #003: ψ-Consensus."

Build on Explainable Encryption

ChaCha20-Poly1305 · Polyglottal Cipher · 12 Database SDKs · ψ-Consensus

Try Enterprise Demo Contact Sales

Explore

TreeChain Labs Technical Paper #001