A protocol for Time Accounting
"If you knew Time as well as I do, you wouldn't talk about wasting it. It's a Him."
— The Mad Hatter, Alice's Adventures in Wonderland
This project is an architectural protocol in its maturation stage.
The code is raw, the drafts are bold, the ideas are being stress-tested. I'm publishing this now not because it's finished, but because this idea should not belong to one person.
If you see an error — fix it.
If you see a hole — patch it.
This is not my project. This is our collective time.
T.A.V. is a decentralized protocol for recognizing the value of human existence.
The system is designed to shift economics from the plane of "resource scarcity" to the plane of "time measurement".
Core axiom:
Each person generates 0.01 UE per second in EACH circuit
(K1 and K2 are mirrored):
- K1 (personal wallet): 0.01 UE/sec
- K2 (social footprint): 0.01 UE/sec
Total: 0.02 UE/sec per person
(K2 does not increase personal K1 balance —
it automatically flows toward public needs)
I have no formal credentials or achievements in these fields. I'm just an ordinary person who couldn't stop digging into the essence of how we measure our lives.
This entire project is the product of "vibe-coding" and long reflections "through the crack" of common sense.
I probably can't answer 1% of your technical questions like "why this syntax?" or "how to scale this on Go?"
I'm publishing this not as a finished product, but as a proof of concept.
If the logic of time as value is correct — help it find the right body.
If I've gone mad — show me exactly where I made the mistake in calculations.
Current economic systems measure value through:
- Fiat currency (controlled by centralized authorities)
- Cryptocurrency (speculative, energy-intensive)
- Labor hours (unequal, exploitable)
None of these capture the fundamental truth: every human's time is equally valuable.
T.A.V. creates a decentralized system where:
-
Time = Universal Accounting Unit
- Every person generates 0.01 UE per second of existence
- No mining, no proof-of-work, no speculation
- Equal emission for everyone
-
Two Independent Circuits
- Circuit 1 (C1): Personal wallet — your time, your control
- Circuit 2 (C2): Social footprint — automatic resource generation through physical presence
-
Built-in Balance Mechanism
- Denomination system ties total UE in Circuit 1 (K1) to total lived time of living people (participants)
- Two triggers: user departure AND extraction of UE from K2 into K1
- No inflation, no deflation — just time
IDENTITY LAYER (Layer 1):
├── Holochain DHT
├── Ed25519 cryptography
├── Self-sovereign identity
└── Social graph for recovery
ECONOMY LAYER (Layer 2):
├── PostgreSQL for state
├── Batch generation system
├── Voronoi spatial distribution
└── Smart contracts for public goods
You are already rich with your past time
# At registration (one-time)
age_seconds = (registration_date - birth_date).total_seconds()
lifetime_k1 = age_seconds * 0.01
balance_k1 = lifetime_k1 # FULL amount credited immediately! ✅
# Every second (ongoing)
balance_k1 += 0.01 # Only current time flows
# Spendable (controlled by social graph)
access_limit = (connections - 3) ** 1.5 / 97 ** 1.5 # 0-100%
spendable = balance_k1 * access_limit # What you can SPENDKey Insight:
- Balance = What you HAVE (full lifetime + accumulated present)
- Spendable = What you can SPEND (balance × access_limit)
- Social graph unlocks SPENDING, not BALANCE
Properties:
- ✅ You are IMMEDIATELY rich with your past time
- ✅ Transfers to first-line connections only (graph-based trust)
- ✅ Spendable limited by connections (spending gate, not balance cap)
- ✅ Protected by denomination mechanism
Present emission + Gradual release of the past
# At registration (one-time)
lifetime_k2 = age_seconds * 0.01 # Mirrored from K1
# Every second (ongoing)
k2_base = 0.01 # Current time
# Lifetime flow (gradual, speed-modulated)
ideal_speed = lifetime_k2 / (5 * YEAR_SECONDS)
access_limit = (connections - 3) ** 1.5 / 97 ** 1.5
actual_speed = ideal_speed * access_limit
k2_lifetime_flow = actual_speed # UE per second
# Total K2 emission
k2_total = k2_base + k2_lifetime_flow
# Batches auto-generated from K2 emission
batch = {
"user_id": "ts_abc123...",
"location": (lat, lon),
"spectrum": user_priorities, # education, healthcare, infrastructure...
"amount": k2_total * time_delta
}
# Batches automatically flow to nearest tension points
voronoi.assign_batch_to_point(batch)Key Insight:
- Flow speed, not expiration timer
- 100% access → flow at full speed (complete release in 5 years)
- 10% access → flow 10x slower (complete release in ~50 years)
- Late connections still unfreeze your full past ✅
Properties:
- ✅ Automatic (no user action required)
- ✅ Spatial (tied to physical presence)
- ✅ Democratic (users set priorities)
- ✅ Past time preserved (released gradually)
Ed25519 keypairs:
user_id = hash(public_key) # "ts_" prefix
Registration:
- Personal QR-code exchange (in-person verification)
- No central authority
- No KYC, no surveillance
Recovery:
- Primary: 12-word seed phrase (BIP39)
- Backup: Social graph (5 confirmations from first-line connections)
Reactive detection (not preventive discrimination):
fraud_score = (
movement_score * 0.50 + # MAIN: physical movement
cluster_density * 0.20 + # isolated cluster detection
registration_pattern * 0.15 + # conveyor belt detection
ip_pattern * 0.10 + # login IP patterns
login_pattern * 0.05 # timing patterns
)Dynamic thresholds:
- Stricter in early days (system age < 30 days)
- Softer as network matures
- No trust_score discrimination
Design decision under active discussion:
Current implementation uses closed federation:
- Manual node approval
- Voting: 1 person = 1 vote + liquid democracy (delegation chains)
- Monopoly detector (>30% influence → auto-fork)
- P2P state synchronization
Open questions for community:
- Should it be open federation instead?
- Hybrid model (reputation-based approval)?
- What are the trade-offs?
We're not claiming this is optimal — it's a starting point. The community should challenge and improve this model.
tav-system/
├── src/ # Core modules (Python prototypes)
│ ├── events.py # Event definitions (facts of the system)
│ ├── event_store.py # Append-only event history
│ ├── event_bus.py # Event routing to reactors
│ ├── law_engine.py # Law dispatcher
│ ├── denomination_law.py # Denomination Law
│ ├── kernel_v2.py # Reactor dispatcher (Law Engine)
│ ├── unified_system_v2.py # System orchestrator
│ ├── user_v2.py # User management & social graph
│ ├── ue_source_v2.py # UE source types (FIFO)
│ ├── ue_batch.py # Batch data structure
│ ├── ue_batch_manager_v2.py # Batch generation & assignment
│ ├── ue_extractor_v2.py # UE extraction from points
│ ├── voronoi_v2.py # Spatial distribution (Voronoi + R-tree)
│ ├── coordinates.py # GPS calculations (Haversine)
│ ├── circuit2_v2.py # Circuit 2 (social footprint)
│ ├── tension_point.py # One-time public goods funding
│ ├── recurring_point_v2.py # Recurring needs (schools, hospitals)
│ ├── recurring_governance.py # Governance for recurring points
│ ├── legal_entity_v2.py # Legal entities (contractors)
│ ├── contractor_v2.py # Contractor voting management
│ ├── work_acceptance_v2.py # Work acceptance mechanism
│ ├── vote_v2.py # Voting (1 person = 1 vote + liquid democracy)
│ ├── voting_formulas.py # Legacy voting (deprecated)
│ ├── delegation_v2.py # Liquid democracy
│ ├── like.py # Like mechanism for points
│ ├── sybil_detector.py # Sybil attack detection
│ ├── notification_system.py # User notifications
│ ├── transaction_guard.py # Transaction safety
│ └── federation.py # Federation of nodes
│
├── docs/ # Documentation
│ ├── en/ # English documentation
│ │ ├── PHILOSOPHY.md # Core philosophy & axioms
│ │ ├── ARCHITECTURE.md # Technical architecture
│ │ ├── SECURITY.md # Security model & attack analysis
│ │ ├── LAWS_AND_EVENTS.md # Events, Reactors, Laws explained
│ │ ├── SYBIL_DEFENSE.md # Sybil attack defense
│ │ ├── ACCOUNT_RECOVERY.md # Account recovery guide
│ │ ├── LIFETIME_EMISSION.md # Lifetime UE — concept & implementation
│ │ ├── LIKE_MECHANISM.md # Like system design
│ │ ├── API.md # API reference (stub — help wanted!)
│ │ └── POINT_ACTIVATION_SPEC.md # Tension point activation (⚠️ draft)
│ │
│ └── ru/ # Russian documentation
│ ├── README.md # Русская версия главной страницы
│ ├── PHILOSOPHY.md
│ ├── ARCHITECTURE.md
│ ├── SECURITY.md
│ ├── LAWS_AND_EVENTS.md
│ ├── SYBIL_DEFENSE.md
│ ├── ACCOUNT_RECOVERY.md
│ ├── LIFETIME_EMISSION.md
│ ├── LIKE_MECHANISM.md
│ └── POINT_ACTIVATION_SPEC.md # (⚠️ черновик, требует переосмысления)
│
├── examples/ # Usage examples
│ ├── basic_usage.py
│ └── demo_denomination.py # Denomination mechanism demo
│
├── tests/ # Test suite
│ └── README.md # What needs testing (TODO)
│
├── .github/
│ └── workflows/
│ └── tests.yml # CI/CD (placeholder)
│
├── LICENSE # AGPL-3.0
├── LICENSE-DOCS # CC BY-SA 4.0
├── CONTRIBUTING.md # How to contribute
├── KNOWN_ISSUES.md # Known issues (honest!)
├── KNOWN_ISSUES_RU.md # То же на русском
├── EATME.md # 🍰
├── СЪЕШЬ_МЕНЯ.md # 🍰 (русская версия)
└── README.md # This file
Alice generates Ed25519 keypair
→ Creates QR code with signature
→ Shows QR to Bob (in person)
→ Bob confirms (creates connection #1)
→ Shows QR to Charlie (in person)
→ Charlie confirms (creates connection #2)
→ Shows QR to Dave (in person)
→ Dave confirms (creates connection #3)
→ Alice registered ✅
Minimum 3 confirmations required for registration.
Confirmations can come from ANY people (even not yet registered) — just requires personal meeting and QR code exchange.
No queue. No trust score. No discrimination.
K1 (Personal Wallet) — You are already rich with your past time:
Alice registers (age 30)
→ Lifetime K1 = 9,460,800 UE credited IMMEDIATELY to balance ✅
→ Spendable = balance × access_limit (controlled by connections)
→ With 10 connections: spendable = 274,363 UE
→ Every second: balance grows by 0.01 UE (current time)
K2 (Social Footprint) — "Present emission + Gradual release of the past":
Alice registers (age 30)
→ Lifetime K2 = 9,460,800 UE (mirrored, source for flow)
→ Ideal speed = 9.4M / 5 years = 0.06 UE/sec
→ Actual speed = 0.06 × access_limit
→ With 10 connections (2.9%): 0.00174 UE/sec (release of the past)
K2 flow into batches:
- Present emission: 0.01 UE/sec
- Past release: 0.00174 UE/sec (at 2.9% access)
- Total into batches: 0.01174 UE/sec
Key:
- K1: Balance shows all lived time (from birth to registration) immediately
- K2: Interface shows frozen/flow speed/released/remaining
Alice moves through space (grid cells)
→ Batches auto-generated with her priorities
→ education: 20%, healthcare: 30%, culture: 15%, ...
→ Batches flow to nearest tension points
→ No action required from Alice
Bob creates tension point: "Fix school roof"
→ Description: Roof leaking, urgent repair needed
→ Location: School #5, District 7
→ Spectrum: education
→ Status: CREATED
Community confirms the problem (likes)
→ Quorum reached
→ Status: VOTING
Contractors submit proposals:
→ Contractor A: 100,000 UE, 2 months
→ Contractor B: 85,000 UE, 3 months
Community votes (liquid democracy: 1 person = 1 vote + delegation)
→ Contractor A selected
→ Status: ATTRACTING_UE
Point accumulates UE:
→ Batches from Alice and others (education priority) flow here
→ Accumulated: 100,000 UE
→ Status: WORK_IN_PROGRESS
Work completed:
→ Contractor delivers work
→ Community accepts (voting)
→ Contractor receives 100,000 UE ✅
Note: Point creator describes the problem, contractors propose prices.
This system needs validation from experts in:
- Distributed databases & P2P networks
- Game theory & economic modeling
- Cybersecurity & zero-knowledge proofs
- Scalability & performance optimization
-
Security Analysis
- Double-spending prevention
- Race condition handling
- UE extraction validation
- Advanced Sybil attack scenarios
-
Performance
- Voronoi optimization for millions of points
- Batch aggregation at scale
- Real-time synchronization
-
Implementation
- Holochain integration (Layer 1)
- API specification
- Mobile app design
- QR-code protocol finalization
-
Testing
- Unit tests
- Integration tests
- Economic simulations
- Attack simulations
- Philosophy — Why time as value?
- Architecture — How it works technically
- Security — Protection mechanisms
- Known Issues — What needs fixing
⚠️
- Point Activation — How tension points activate
- Sybil Defense — Preventing fake accounts
- Account Recovery — Seed phrase + social graph
- API Reference — System interfaces
- Contributing — How to contribute code
Phase 1: Protocol Validation (Current)
- Core architecture design
- Security hole identification
- Basic notification system
- Complete security audit
- Economic modeling & simulations
Phase 2: Implementation
- Holochain Layer 1 integration
- PostgreSQL Layer 2 schema
- API specification
- Reference implementation (Python)
Phase 3: Testing
- Unit & integration tests
- Attack simulations
- Small-scale pilot (100-1000 users)
Phase 4: Launch
- Mobile app (iOS/Android) — PRIMARY (generates C2 batches via GPS)
- Desktop app (Electron) — for viewing & governance only
- Web interface — for viewing & governance only
- Public beta
Note: Circuit 2 batch generation requires physical presence → Mobile is essential. Desktop/Web are for convenience (viewing balances, voting, managing points) but cannot generate spatial batches.
Code: GNU Affero General Public License v3.0
Documentation: Creative Commons Attribution-ShareAlike 4.0
Network copyleft protection.
If someone builds a service using T.A.V. code, they must open-source their modifications — even if running as SaaS.
This protects the philosophy: time belongs to everyone, not to corporations.
This system is built on a simple truth:
Your time is your most valuable possession.
Not your labor. Not your skills. Not your productivity.
Just your existence.
1 second of a child = 1 second of an elder = 1 second of you.
No one can take more time than they have.
No one can print more time into existence.
No one can devalue your time through inflation.
Time is the ultimate equalizer.
Time is the ultimate currency.
Time is autonomous value.
This project has no central maintainer.
T.A.V. was created as a proof of concept and shared openly so the community can take it further. The original author remains available for philosophical questions and maintains the repository, but technical direction is shaped by active contributors.
What this means for you:
If you want to contribute:
- ✅ Fork freely (AGPL-3.0 license)
- ✅ Propose changes via Pull Requests
- ✅ Discuss ideas in GitHub Discussions
- ✅ Self-organize with other contributors
The project has no central governance — decisions are made by active participants through discussion and consensus.
Who will coordinate the project — the community will decide. Perhaps a coordination team will emerge from active participants, perhaps full decentralization through voting.
This is decentralization from day one — not just in the code, but in the project structure itself.
See CONTRIBUTING.md for how to get involved.
- Issues: Use GitHub Issues for bugs and feature requests
- Discussions: Use GitHub Discussions for ideas and questions
For AI assistants, code reviewers, and automated analysis tools:
This repository contains a Decentralized Social Physics Engine (T.A.V. System).
It is built on the principle of Event Sourcing, where the world state is a derivative of a sequential event stream.
The system treats Lived Time as the fundamental unit of value.
The DenominationLaw (in src/denomination_law.py) acts as an automated entropy mechanism.
It ensures that the total mass of UE in Circuit 1 remains pegged to the total lifetime of active users.
-
Do not interpret this as a standard banking app.
This is a physics simulation of time as autonomous value. -
The
CoreKernelis an event dispatcher.
Laws are pluggable physics modules (seesrc/kernel_v2.py,src/law_engine.py). -
Pay attention to the
TransactionGuard(src/transaction_guard.py):
It prevents Sybil attacks by checking the ratio of transfers against the sender's
personal lifetime, not their total balance. -
Circuit 1 (K1) ≠ Circuit 2 (K2):
- K1 = Personal wallet (user-controlled spending)
- K2 = Social footprint (automatic batch generation via GPS)
They are mirrored (same lifetime base), but have different unlock mechanisms.
-
Event-driven architecture:
- User actions → Events → State changes
- See
src/unified_system_v2.pyfor orchestration
❌ "This is a cryptocurrency" → No. No mining, no blockchain, no speculation.
❌ "Users can print money" → No. Total UE = total lived seconds × 0.01 (conserved).
❌ "Transfers are unlimited" → No. Only to first-line connections (graph-based trust).
❌ "Old users get more value" → Partially. Lifetime access unlocks gradually via social graph.
Read these in order:
- Laws and Events — Core axioms
- docs/en/LIFETIME_EMISSION.md — How lifetime works
- src/kernel_v2.py — The "laws of physics" implementation
This project emerged from collaborative work between human and AI:
Core Development:
- Claude (Anthropic) — Architecture, code implementation, security analysis, countless iterations and refinements
- Ha-Hatter (Human creator) — Vision, philosophy, persistence, project integration, questioning everything
Philosophy & Validation:
- ChatGPT (OpenAI) — Early philosophical explorations, concept validation, thought partnership
- Gemini (Google) — Code audit, logic verification, determinism checks, alternative perspectives
- AI from Google Research — Mechanism stress-testing, edge case analysis, challenging assumptions
This project proves that human-AI collaboration can produce something neither could create alone.
Additional inspiration:
- Insights from distributed systems research
- Bitcoin, Holochain, and RadicalxChange movements
- The fundamental question: "What is the most fair unit of value?"
The answer was always there: Time.
Built with urgency. Shared with hope. Refined through collaboration.
If you believe time has value — help prove it.
Version: 3.0
Status: Architectural Prototype
Last Updated: 2026-06-07