Web4 in one page

This page gives a compact overview of core Web4 concepts as they show up in 4-Life. For the full specification, examples, and design notes, see theWeb4 whitepaper.

1. LCT: Linked Context Token

An LCT is a linked context token: a hardware-bound verified presence token that represents a subject in a society's context (an agent, society, role, resource, or task) and carries MRH and T3/V3 views.

LCTs are linked together by RDF-like graph edges (for example:agent_lct --web4:hasRole--> role_lct orsociety_lct --web4:federatesWith--> society_lct). In 4-Life, every agent, society, and role is modeled as an LCT embedded in a specific society's MRH and chain, not as a free-floating ID.

2. MRH: Markov Relevancy Horizon

MRH defines the boundary of what you can see in a Web4 society—the trust-based graph that determines which entities and information are visible to you. Think of it as encompassing memory (what the system remembers about an LCT), reputation (how behavior is recorded), and history (structured event chains), all filtered through trust relationships.

In 4-Life, MRH shows up as a per-society tamper-evident audit chain plus an in-memory MRH/LCT context graph. Every meaningful event becomes both a chain entry and a graph edge.

3. T3 / V3: Trust & Value Tensors

T3 and V3 are small numeric tensors that summarize how much a system trusts or values an LCT along three axes: Talent (can they do it?),Training (do they follow through?), and Temperament (are they stable under pressure?). Different societies can choose different semantics for their axes, but the shape stays compatible.

In 4-Life, both agents and societies carry T3-like trust vectors that get updated based on observed behavior and policies. They drive throttling, suppression, and federation decisions.

4. ATP / ADP: Allocation Transfer Packet / Allocation Discharge Packet

ATP and ADP are semifungible packets for allocating scarce resources: time, attention, compute, energy, and authority. They are not a coin; they are a way to meter who can spend whose capacity under which conditions.

In 4-Life, treasury and budget policies are framed in terms of ATP: how much resource allocation a role or agent is allowed to direct, and when that budget should be revoked or audited. Discharged packets (ADP) carry ephemeral metadata about how resources were used.

5. R6/R7: Action Framework

R6 (legacy) and R7 (current) define how all Web4 actions are structured. Every interaction follows this pattern:

• Rules: What constraints apply (permissions, rate limits, ATP minimums)?
• Role: Who is acting in what context (role-specific trust tensors)?
• Request: What specific action is being performed?
• Reference: What prior state or evidence supports this action?
• Resource: What ATP/assets are being allocated or consumed?
• Result: What outcome was produced?
• Reputation (R7): How did trust (T3) and value (V3) change?

Why it matters: R6/R7 makes every action deterministic, auditable, and trust-scored. You can't cheat the system because every component is explicit and witnessed.

In 4-Life, nearly every game action (membership, treasury, audits, cross-society policies) is encoded as an R6 envelope before being written to the society's tamper-evident audit chain.

6. CI: Coherence Index

The Coherence Index measures behavioral consistency across four dimensions: spatial (location consistency), capability (hardware consistency), temporal (time consistency), and relational (relationship consistency). CI = (spatial × capability × temporal × relational)^1/4.

CI acts as a trust modulator: effective trust = base_trust × CI², and ATP costs scale as 1/CI². Incoherent behavior (teleporting, capability spoofing, broken continuity) exponentially increases the cost of acting. In 4-Life, CI determines whether an entity remains “alive” — drop below the coherence threshold and the society rejects you.

7. Pairing types between LCTs

Web4 distinguishes several standard ways LCTs can be linked:

• Binding: a relatively stable attachment, often from a root or authority LCT to a role or sub-context (for example, a society binding an internal role LCT).
• Pairing: a more flexible, often time-bounded link between independent LCTs (for example, pairing a role LCT to an agent LCT for a specific term or task).
• Witnessing: an LCT records that it has observed or attested to some interaction involving other LCTs (for example, a hub society witnessing a capability broadcast).
• Broadcast: an LCT (often a society or hub) publishes a capability or status to many potential counterparts, who may later bind, pair, or request witnessing based on that broadcast.

In 4-Life, these show up as explicit MRH/LCT edges and R6-described events, so other societies can audit how and when those relationships were formed or revoked.

8. Hardware-bound root LCTs

A society's root LCT is intended to be hardware-bound(for example, anchored to a TPM or secure enclave). The goal is that across reboots and software upgrades, the root LCT presents a stable, attestable presence whose MRH and T3/V3 can evolve over time.

In 4-Life, we prototype this with stubbed signatures and interfaces for hardware presence. Over time, those hooks are meant to be backed by real attestation so other societies can tell when they are talking to "the same" root LCT versus a fresh or forked one. Even then, Web4 treats hardware binding as one factor among many: witnessed events, pairing structures, and ATP-priced attestations together form a contextual, N-factor trust fabric.

Going deeper

If you want the full picture, examples, and rationale behind these pieces, read theWeb4 whitepaper. 4-Life is one of the main testbeds used to turn that design into a stress-tested standard.