TimeChain Protocol Cheatsheet

The TimeChain Standard presents a family of cryptographic protocols for collaborative documentation that provide mathematical proof of document integrity, access patterns, and authorship without trusting the platform operator.

Protocol Comparison Matrix

Dimension	VEST	AEGIS	ForkNode-VEST	WEAVE	TNP
Full Name	Signed Evidence Audit Ledger	Authenticated Evidence Guard with Integrated Security	ForkNode + VEST Synthesis	Web-scale Edge-Aware Verifiable Exchange	Forking Latency-Unified eXchange
Primary Innovation	Cryptographic operation chains with non-repudiation	Zero-knowledge access control with selective disclosure	Homomorphic CRDTs with encrypted conflict resolution	Mesh-native topology with content addressing	Time-travel consensus with timeline divergence
Core Problem Solved	”Can we prove who edited what and when?"	"Can we audit access without revealing content?"	"Can we collaborate in real-time with E2E encryption?"	"Can we collaborate without server dependency?"	"Can we enable non-linear document history?”
Unique Selling Proposition	Court-admissible cryptographic proof of authorship	Server verifies permissions without learning document IDs	Server merges edits without decrypting content	Peer-to-peer operation chains with server acceleration	Infinite undo with branch/merge for documents

Technical Characteristics

Characteristic	VEST	AEGIS	ForkNode-VEST	WEAVE	TNP
Transport Layer	UDP + DTLS 1.3	UDP + DTLS 1.3	UDP + DTLS 1.3	UDP Mesh + DTLS	UDP + DTLS 1.3
Cryptographic Primitives	Ed25519, BLAKE3, Roughtime	Ed25519, zk-SNARKs (Groth16), Commitments	Ed25519, OPE, AES-256-GCM	Ed25519, BLAKE3, Content addressing	Ed25519, BLAKE3, Vector clocks
Data Structure	Merkle DAG (operation chain)	VEST chain + ZK proof forest	VEST chain + homomorphic CRDT state	Merkle DAG (content-addressed)	Merkle DAG with timeline branches
Consensus Mechanism	Distributed timestamps (Roughtime)	ZK proof verification + timestamps	OPE-based CRDT rules + timestamps	Gossip protocol + eventual consistency	Lamport clocks + causal ordering
Server Role	Witness + chain validator	ZK verifier + audit logger	Homomorphic merge engine + witness	Optional accelerator + discovery	Timeline coordinator + branch manager
Privacy Model	Server sees operation content	Server sees nothing (zero-knowledge)	Server sees encrypted operations + metadata	Server sees content-addressed hashes	Server sees operation structure, not content

Performance Characteristics

Metric	VEST	AEGIS	ForkNode-VEST	WEAVE	TNP
Client Overhead (P95)	+15ms	+250ms (proof gen)	+30ms	+10ms	+20ms
Server Overhead (P95)	+10ms	+8ms (verify)	+15ms	+5ms	+12ms
Target P95 Latency	<50ms	<300ms (first access)	<60ms	<40ms	<55ms
Throughput (ops/sec/node)	100K	50K (ZK bottleneck)	80K	150K (distributed)	90K
Proof Size	1-2KB per operation	300 bytes (ZK proof)	2-3KB per operation	500 bytes (content hash)	1.5KB per operation
Chain Verification (1M ops)	O(n) with Merkle proofs = O(log n)	O(n) but parallelizable	O(n) with OPE overhead	O(n) distributed	O(n) per timeline

Security Properties

Property	VEST	AEGIS	ForkNode-VEST	WEAVE	TNP
Non-repudiation	✅ Strong (user signatures)	✅ Strong (ZK commitments)	✅ Strong (dual signatures)	✅ Strong (content-addressed)	✅ Strong (causal signatures)
Tamper-evidence	✅ Hash chain + Merkle tree	✅ VEST chain + ZK proofs	✅ Encrypted chain integrity	✅ Content addressing	✅ Timeline DAG integrity
Forward Secrecy	✅ DTLS 1.3	✅ DTLS 1.3 + per-access keys	✅ DTLS 1.3 + document keys	✅ DTLS 1.3	✅ DTLS 1.3
Server Blindness	❌ Server sees content	✅ Server blind to access patterns	⚠️ Server sees positions (OPE)	✅ Server blind to content	⚠️ Server sees structure
Auditability	✅ Complete operation log	✅ Selective disclosure	✅ Encrypted operation log	✅ Content-addressed history	✅ Complete timeline history
Privacy Guarantees	Low (server sees all)	Very High (zero-knowledge)	Medium-High (OPE leakage)	High (content-addressed)	Medium (structure visible)

Market Positioning

Dimension	VEST	AEGIS	ForkNode-VEST	WEAVE	TNP
Target Customer	Legal, Healthcare, Finance (compliance)	Intelligence, High-security legal	All of the above (premium)	Distributed teams, offline scenarios	Git-style document workflows
Primary Use Case	Contract negotiations, audit trails	Classified documents, sensitive M&A	Real-time encrypted collaboration	Field operations, disaster recovery	Complex document versioning
Competitive Advantage	First cryptographic audit for docs	Unique zero-knowledge + audit	”Impossible trinity” achieved	Server-optional resilience	Git for documents
Pricing Strategy	3x base ($45/user/month)	10x base ($150/user/month)	Included in premium tier	2x base ($30/user/month)	2x base ($30/user/month)
Market Maturity	Ready (clear demand)	Emerging (ZK trending)	Speculative (validate first)	Niche (specific needs)	Niche (power users)

Implementation Complexity

Factor	VEST	AEGIS	ForkNode-VEST	WEAVE	TNP
Cryptography Difficulty	Medium	Very High (ZK-SNARKs)	High (OPE + homomorphic)	Medium	Medium
Integration Complexity	Low (extends Relay)	Medium (adds ZK verifier)	High (replaces CRDT)	Medium (mesh topology)	Medium (timeline management)
Development Timeline	9 months	12 months	18 months	12 months	10 months
Team Size Required	6-8 engineers	8-10 engineers	12-15 engineers	7-9 engineers	6-8 engineers
Required Expertise	Protocol design, Rust	Cryptography, ZK circuits	Homomorphic crypto, CRDTs	P2P networking, gossip	Version control systems
Maintenance Burden	Medium	High (crypto updates)	Very High	Medium	Medium

Packet Structure Comparison

VEST Packet (Simplified)

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|  Type | Flags         | Session ID                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length                | Document ID                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation Hash (32 bytes)                                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parent Hash(es) (variable)                                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lamport Clock                 | Timestamp (8 bytes)           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User Signature (64 bytes Ed25519)                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Server Signature (64 bytes Ed25519)                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Merkle Root (32 bytes)                                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp Proof (variable, Roughtime format)                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload (variable)                                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

AEGIS Packet (Simplified)

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|  Type | Flags         | Session ID                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User Commitment (32 bytes, hidden identity)                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Document Commitment (32 bytes, hidden document ID)            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp Commitment (32 bytes, hidden time)                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ZK Proof (Groth16, ~192 bytes)                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Public Inputs (variable)                                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VEST Chain Reference (32 bytes, links to audit chain)         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encrypted Audit Details (for auditor, variable)               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Consistency Proof (proves audit matches commitments)          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

ForkNode-VEST Packet (Simplified)

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|  Type | Flags         | Session ID                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VEST Header (as above)                                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encrypted Payload (AES-256-GCM)                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPE Position (8 bytes, order-preserving encrypted)            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fully Encrypted Position (for client decryption)              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation Type (visible: INSERT/DELETE/FORMAT)                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Causal Metadata (visible for CRDT merging)                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Document Key Fingerprint (32 bytes, not the key)              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Pseudo-Sequence Diagrams

VEST: Document Edit with Audit Trail

Client                     Relay                    Redis                Timestamp
  |                          |                        |                      |
  |--[1. Edit "Hello"]------>|                        |                      |
  |   Sign with user key     |                        |                      |
  |                          |                        |                      |
  |<-[2. Operation received]-|                        |                      |
  |                          |                        |                      |
  |                          |--[3. Verify signature]-|                      |
  |                          |   Check chain parent   |                      |
  |                          |                        |                      |
  |                          |--[4. Request timestamp]------------------>|
  |                          |                        |                      |
  |                          |<-[5. Timestamp proof]---------------------|
  |                          |   (Roughtime, 3 servers)                     |
  |                          |                        |                      |
  |                          |--[6. Add server signature]                   |
  |                          |   Compute operation hash                     |
  |                          |   Update Merkle tree                         |
  |                          |                        |                      |
  |                          |--[7. Persist to Redis]-|                      |
  |                          |                        |                      |
  |<-[8. Witnessed operation]|                        |                      |
  |   with proof chain       |                        |                      |
  |                          |                        |                      |
  |                          |--[9. Broadcast to other clients]             |
  |                          |                        |                      |

Result: Cryptographically verifiable audit trail stored

AEGIS: Zero-Knowledge Access Request

Client                     AEGIS                    Shield               Auditor
  |                          |                        |                      |
  |--[1. Request access]---->|                        |                      |
  |   Generate ZK proof:     |                        |                      |
  |   "I have permission"    |                        |                      |
  |   (hides document ID)    |                        |                      |
  |                          |                        |                      |
  |                          |--[2. Verify ZK proof]--|                      |
  |                          |   Server learns NOTHING|                      |
  |                          |   about document/user  |                      |
  |                          |                        |                      |
  |<-[3. Access granted]-----|                        |                      |
  |   Encrypted doc key      |                        |                      |
  |                          |                        |                      |
  |--[4. Decrypt locally]--->|                        |                      |
  |   Read document          |                        |                      |
  |                          |                        |                      |
  |                          |--[5. Log access event]-|                      |
  |                          |   Encrypted for auditor|                      |
  |                          |   Server can't decrypt |                      |
  |                          |                        |                      |
  |                          |                        |                      |
  [Later: Audit Request]     |                        |                      |
  |                          |                        |                      |
  |                          |<-[6. Request audit logs]-------------------|
  |                          |                        |                      |
  |                          |--[7. Export encrypted logs]---------------->|
  |                          |                        |                      |
  |                          |                        |   [8. Decrypt logs]  |
  |                          |                        |   Verify VEST chain  |
  |                          |                        |   Confirm access     |
  |                          |                        |                      |

Result: Access audited without server learning what was accessed

ForkNode-VEST: Encrypted Collaborative Edit

User1                    User2                    Server                Other Users
  |                        |                        |                        |
  |--[1. Type "Hello"]---->|                        |                        |
  |   Encrypt locally      |                        |                        |
  |   OPE position         |                        |                        |
  |                        |--[2. Type "World"]---->|                        |
  |                        |   Encrypt locally      |                        |
  |                        |   OPE position         |                        |
  |                        |                        |                        |
  |                        |                        |--[3. Compare OPE]--    |
  |                        |                        |   pos1 < pos2          |
  |                        |                        |   Merge WITHOUT decrypt|
  |                        |                        |                        |
  |                        |                        |--[4. Sign merged ops]- |
  |                        |                        |   VEST witness         |
  |                        |                        |                        |
  |<-[5. Broadcast encrypted merge]----------------|                        |
  |                        |                        |                        |
  |--[6. Decrypt locally]->|                        |                        |
  |   Result: "Hello World"|                        |                        |
  |                        |<-[7. Decrypt locally]--|                        |
  |                        |   Result: "Hello World"|                        |
  |                        |                        |                        |

Result: Real-time collaboration with E2E encryption maintained

Integration Requirements

VEST Integration with Materi

Existing: Browser → WebSocket → Relay → Redis → PostgreSQL
Modified: Browser → VEST Client → DTLS → Relay (VEST module) → Redis (chain) → PostgreSQL

Changes:
- Relay: Add VEST protocol handler (~2K LOC Rust)
- Client: Add signature generation (Ed25519, ~500 LOC TypeScript)
- Shield: Key management for user signing keys
- Redis: Store operation chains (existing Streams + new hash structure)
- Minimal: ~15ms added latency, 100K ops/sec maintained

AEGIS Integration with Materi

Existing: Browser → Shield (JWT auth) → API → PostgreSQL
Modified: Browser → ZK Proof Gen → Shield (ZK verifier) → AEGIS module → VEST chain

Changes:
- Shield: Add ZK proof verification endpoint (~3K LOC Python)
- Client: Add ZK proof generation (WASM, ~1K LOC TypeScript wrapper)
- New: AEGIS service for selective disclosure
- Redis: Store encrypted audit logs
- Moderate: +250ms first access (proof gen), +8ms verify

ForkNode-VEST Integration with Materi

Existing: Browser → Relay (CRDT) → Redis → PostgreSQL
Modified: Browser → Encrypt → ForkNode-VEST → Homomorphic CRDT → Redis (encrypted) → PostgreSQL

Changes:
- Relay: Replace CRDT engine with homomorphic version (~5K LOC Rust)
- Client: Add OPE encryption layer (~2K LOC TypeScript)
- Extensive: Complete CRDT rewrite for encrypted operations
- Significant: +30ms added latency, 80K ops/sec (reduced)

Risk Assessment Summary

Risk Type	VEST	AEGIS	ForkNode-VEST
Technical Feasibility	Low risk (proven crypto)	Medium risk (complex ZK)	High risk (novel combination)
Performance Impact	Low (+15ms)	Medium (+250ms first access)	Medium (+30ms sustained)
Market Validation	Strong (compliance demand)	Emerging (ZK trending)	Unvalidated (speculative)
Implementation Time	9 months	12 months	18 months
Team Expertise Gap	Low (protocol design)	High (ZK-SNARK expertise)	Very High (multiple domains)
Maintenance Burden	Medium	High (crypto updates)	Very High (complex crypto)
Competitive Response	2-3 years to replicate	3-5 years to replicate	5+ years to replicate

Recommended Build Order

Phase 1: Foundation (VEST)

Duration: 9 months
Investment: $1.3M
Risk: Low
Market: Validated
Outcome: Cryptographic audit trails, 2-3 year technical moat

Phase 2: Differentiation (AEGIS)

Duration: 12 months
Investment: $1.8M
Risk: Medium
Market: Emerging
Outcome: Unique zero-knowledge position, 3-5 year moat

Phase 3: Completion (ForkNode-VEST)

Duration: 18 months
Investment: $4.5M
Risk: High
Market: Unvalidated
Outcome: “Impossible trinity” achieved, but only if Phases 1-2 succeed

Decision Gate: After Phase 1, evaluate market response before committing to Phase 2. After Phase 2, evaluate before committing to Phase 3.

Standards Compliance

All protocols in the TimeChain standard family comply with:

RFC 8446: TLS 1.3 (via DTLS 1.3)
RFC 9000: QUIC (transport inspiration)
RFC 8032: Ed25519 signatures
FIPS 140-2: Cryptographic module standards
GDPR Article 32: Security of processing requirements
SOC 2 Type II: Trust service criteria
HIPAA § 164.312: Technical safeguards

Open Questions for Future Research

VEST: Can we reduce Merkle tree update overhead for documents with 10M+ operations?
AEGIS: Can we use lighter ZK systems (STARKs, Bulletproofs) to reduce proof generation time below 100ms?
ForkNode-VEST: Can we use fully homomorphic encryption (FHE) instead of OPE to eliminate position leakage?
WEAVE: Can we achieve Byzantine fault tolerance in mesh topology without consensus overhead?
TNP: Can we use persistent data structures to make timeline branching O(1) instead of O(n)?

Document Version: 1.0
Last Updated: November 27, 2025
Standard Name: TimeChain (Verifiable Evidence and Real-time Integrity Through Authenticated Streams)
Protocol Family: VEST, AEGIS, ForkNode-VEST, WEAVE, TNP
Status: Draft Specification

Getting Started

FNP Flashcards

Formal Verification

Guides

Architecture

TimeChain System

Protocol RFCs

Reports

Protocol Cheatsheet

TimeChain Protocol Cheatsheet

Protocol Comparison Matrix

Technical Characteristics

Performance Characteristics

Security Properties

Market Positioning

Implementation Complexity

Packet Structure Comparison

VEST Packet (Simplified)

AEGIS Packet (Simplified)

ForkNode-VEST Packet (Simplified)

Pseudo-Sequence Diagrams

VEST: Document Edit with Audit Trail

AEGIS: Zero-Knowledge Access Request

ForkNode-VEST: Encrypted Collaborative Edit

Integration Requirements

VEST Integration with Materi

AEGIS Integration with Materi

ForkNode-VEST Integration with Materi

Risk Assessment Summary

Recommended Build Order

Phase 1: Foundation (VEST)

Phase 2: Differentiation (AEGIS)

Phase 3: Completion (ForkNode-VEST)

Standards Compliance

Open Questions for Future Research

Getting Started

FNP Flashcards

Formal Verification

Guides

Architecture

TimeChain System

Protocol RFCs

Reports

​TimeChain Protocol Cheatsheet

​Protocol Comparison Matrix

​Technical Characteristics

​Performance Characteristics

​Security Properties

​Market Positioning

​Implementation Complexity

​Packet Structure Comparison

​VEST Packet (Simplified)

​AEGIS Packet (Simplified)

​ForkNode-VEST Packet (Simplified)

​Pseudo-Sequence Diagrams

​VEST: Document Edit with Audit Trail

​AEGIS: Zero-Knowledge Access Request

​ForkNode-VEST: Encrypted Collaborative Edit

​Integration Requirements

​VEST Integration with Materi

​AEGIS Integration with Materi

​ForkNode-VEST Integration with Materi

​Risk Assessment Summary

​Recommended Build Order

​Phase 1: Foundation (VEST)

​Phase 2: Differentiation (AEGIS)

​Phase 3: Completion (ForkNode-VEST)

​Standards Compliance

​Open Questions for Future Research

TimeChain Protocol Cheatsheet

Protocol Comparison Matrix

Technical Characteristics

Performance Characteristics

Security Properties

Market Positioning

Implementation Complexity

Packet Structure Comparison

VEST Packet (Simplified)

AEGIS Packet (Simplified)

ForkNode-VEST Packet (Simplified)

Pseudo-Sequence Diagrams

VEST: Document Edit with Audit Trail

AEGIS: Zero-Knowledge Access Request

ForkNode-VEST: Encrypted Collaborative Edit

Integration Requirements

VEST Integration with Materi

AEGIS Integration with Materi

ForkNode-VEST Integration with Materi

Risk Assessment Summary

Recommended Build Order

Phase 1: Foundation (VEST)

Phase 2: Differentiation (AEGIS)

Phase 3: Completion (ForkNode-VEST)

Standards Compliance

Open Questions for Future Research