Linked Context Tokens (LCT)
Web4's verified presence layer — hardware-bound, witnessed, and resistant to faking
Key Takeaways
- 1. Your identity lives in your devices' security chips — not in passwords or company databases
- 2. Multiple devices (phone, laptop, security key) witness each other, making faking exponentially harder (who runs this?)
- 3. If you lose a device, your other devices can recover your identity — no "forgot password" needed
- 4. This is pseudonymous — your reputation follows you, but your real name doesn't have to
- 5. Every trust change is logged in a tamper-evident transparency log — you can audit your own trust history
Read on for the full picture, or jump to the interactive security audit ↓
You're starting a 6-concept journey. Each builds on the last:
Identity Evolution: Web2 → Web3 → Web4
Web2: Passwords
Web3: Wallet Keys
Web4: LCTs
Key insight: Web2 trusts what you memorize (forgettable, shareable). Web3 trusts what you store (copyable, stealable). Web4 trusts what hardware proves and witnesses verify (verifiable, revocable).
But what about pseudonymity? Hardware-bound identity doesn't mean real-name identity. Your LCT is a cryptographic key, not your name. Nobody sees “Jane Smith” — they see an entity with a trust history. You can participate, earn trust, and contribute value without ever revealing who you are. What Web4 prevents isn't anonymity — it's disposable identity. Your reputation follows you, but your name doesn't have to. See the full FAQ →
Worked example
Suppose you pick the handle alice.assistant1. Your LCT looks like this:
lct:web4:0x4c8f…a3f2#alice.assistant1The 0x4c8f…a3f2 part is a cryptographic fingerprint tied to your device's security chip — it never leaves the hardware, and it's the same every time you sign in. The #alice.assistant1 part is a label you chose; it could be anything — pseudonymous, role-scoped, or even rotated per community.
Two sessions, same entity: Monday you answer a question; Friday you post again. Both messages are signed by the same LCT, so the community sees one continuous reputation — the trust you earned Monday applies Friday. No one had to check an ID, email, or phone number to know it's you.
Visible to others
- Your LCT fingerprint (stable across sessions)
- Your trust history (T3 scores, past behavior)
- Your handle, if you chose one
Not visible
- Your legal name
- Your email or phone number
- Any data broker profile
What are TPM, Secure Enclave, and FIDO2?
These are tamper-resistant security chips already built into devices you probably own:
- Secure Enclave — Apple's security chip in every iPhone, iPad, and Mac. It handles Face ID, Touch ID, and encryption keys.
- TPM (Trusted Platform Module) — A security chip in most modern laptops and PCs. Windows uses it for BitLocker encryption and secure boot.
- FIDO2 / WebAuthn — Security keys you can buy (like YubiKey) or built-in biometrics (fingerprint readers). Used for passwordless login on many websites already.
The key property: these chips generate cryptographic keys internally and never let them leave the hardware. Even if someone copies your entire hard drive, they can't extract the keys.
This isn't theoretical — Web4's TPM2 binding has been validated on real hardware (Intel TPM 2.0: key creation, signing, verification, attestation quotes, EK certificate chain verified through 2049).
What are “device witnesses”?
Witnessing happens at two layers: (1) your own devices attest to each other, and (2) optional infrastructure nodes verify the network. This section covers layer 1 — layer 2 (“who runs the network?”) is answered directly below.
Why device witnesses? Passwords can be stolen. A single device can be hacked. But compromising three independent devices at the same time? That's orders of magnitude harder. A device witness is any device or platform that independently confirms your presence is real — like co-signers on a legal document. Your phone, laptop, and security key each independently vouch that “yes, this is really Alice.” An attacker would need to compromise all of your device witnesses simultaneously to impersonate you.
Example: Logging in from a new city
You log in from Tokyo. Your phone's GPS confirms you're in Tokyo. Your laptop's TPM chip signs the same session. Your smartwatch confirms your biometrics match. Three independent devices, three independent confirmations — that's witnessing. If someone steals just your laptop password, they still can't fake your phone's GPS or your watch's heartbeat pattern.
What happens under the hood:
Who runs witness infrastructure?
Short answer: anyone can. Web4 is an open standard (like email), not a platform (like Gmail). Witness nodes can be run by universities, companies, nonprofits, or individuals — the same way anyone can run an email server.
Two kinds of witnessing: (1) your own devices witness each other — your phone witnesses your laptop, and vice versa — proving you are real. (2) Infrastructure witness nodes validate the network — confirming attestations are properly formed and consistent. In the current prototype, both are simulated. In a deployed system, your devices handle identity witnessing; external nodes (universities, employers, individuals) add network-level verification but aren't required.
What's the incentive to run a witness node? Witnesses earn ATP for validation work — each attestation they process earns a small fee from the network's redistribution pool (not from the user being witnessed). For institutions like universities or employers, the incentive is also reputational: being a trusted witness builds their own T3 scores, making their attestations more valuable. Individual witness nodes earn less per attestation but face lower operating costs. The economics parallel email servers: some organizations run their own for control, most individuals use shared infrastructure, and the network works regardless of the mix.
Collusion requires coordinating multiple independent parties simultaneously, which is both economically costly and mathematically detectable.
What about metadata and surveillance? If devices are constantly attesting to each other, couldn't the attestation patterns themselves reveal sensitive information? Yes — this is a real concern. Web4 identifies 7 privacy leakage channels, including graph structure (who talks to whom) and timing correlation. Mitigations include pseudonymous attestation, proof batching, timing jitter, and dummy edges — but complete prevention is impossible. The design goal is raising the cost of inference above the value of the leaked information.
How does this compare to today's web?
| What's exposed | Today (Web2) | Web4 |
|---|---|---|
| Your identity | Real name, email, phone sold to data brokers | Pseudonymous — hardware-bound, no personal info required |
| Your content | Platforms read, analyze, and monetize everything | Only recipients see content — protocol moves attestations, not data |
| Your browsing | Tracking cookies follow you across sites | No cross-context tracking — each role is a separate LCT |
| Your social graph | Full contact lists harvested and shared | Partial — who attests to whom is visible within 3 hops |
| Your activity timing | Platforms log every click, scroll, and hover | Attestation timing visible — mitigated by jitter and batching |
| Breach exposure | Centralized databases leaked (billions of records yearly) | No central database to breach — identity is on your devices |
The honest framing: Web4 trades centralized data collection for decentralized attestation patterns. Two channels (social graph and timing) leak some metadata — but your identity, content, browsing, and breach risk all improve substantially. Net result: narrower leakage, built into the protocol rather than bolted on as afterthoughts.
What Is a Linked Context Token?
An LCT is Web4's foundational presence primitive. Unlike a password (knowledge) or wallet address (cryptographic key), an LCT is a hardware-bound, witnessed, contextual proof of presence that verifies:
- Where you are: Which physical device/platform (via hardware attestation)
- Who created you: Your lineage chain (accountability)
- What you can do: Your task scope (limited delegation)
- Who witnesses you: Which devices/platforms attest to your existence
- How you behave: Your reputation history (trust earned, not claimed)
▶Technical: What an LCT looks like (format breakdown)
| lct: | Scheme — marks this as an LCT (like https: marks a URL) |
| web4: | Namespace — the Web4 trust fabric |
| agent: | Entity type — agent, human, device, role, or society |
| alice.assistant1 | Lineage — created by Alice, who vouches for it |
| @Thor | Context — runs on the “Thor” device (Jetson AGX with TPM attestation) |
| #perception | Task scope — read-only, cannot execute code or delegate |
The format is human-readable on purpose. If any segment is missing or unverifiable, the LCT is rejected — so a glance tells you who/where/what/scope.
Try It: Click Components & Attack Scenarios
Explore how each LCT component works, then test it against real attack vectors. Your Security Audit unlocks as you explore.
Interactive: How Device Witnesses Strengthen Presence
Presence Trust Score
Compromise Difficulty
- Secure Enclave (iPhone/Android)
Each witness adds 15% detection probability (capped at 95%)
Why this matters: With 1 device, an attacker must physically steal AND biometrically unlock your device. Adding a second device (like a security key) would raise detection from 30% to 45% and make compromise 6.3x harder.
Not All Hardware Is Equal
Your device's security hardware determines how high your trust can go. Stronger hardware means a stronger identity witness — like the difference between a handwritten note and a notarized document.
These are trust ceilings, not starting points. Everyone starts at neutral (0.5). With software-only hardware, 0.5 is both where you start and the highest you can reach. Stronger hardware lets you build higher — but you still have to earn it through behavior.
The ceiling caps how high your T3 trust can climb through behavior. At every tier you can post, earn ATP, build karma, and join societies — what changes is the terms of your participation:
- Cost & reward economics. Higher trust pays less per action and earns more back. The quality ramp rewards a 0.85-trust account roughly 7× more per quality action than a 0.30-trust account — so a higher ceiling means your good behavior compounds faster.
- Witness role. Hardware-bound devices (TPM / Secure Enclave / FIDO2) can serve as witnesses for other people's sessions and attestations. Software-only identities can be witnessed but generally don't witness others — the cryptographic root isn't strong enough to anchor someone else's claim.
- Recovery path. A higher ceiling means you have more hardware witnesses, which means a faster recovery if a device is lost or stolen (multi-device quorum vs. starting over). One device can recover via a second; software-only has no quorum to fall back on.
- Headroom for high-stakes participation. Many actions in Web4 carry a trust threshold (e.g., coherence checks gate large transfers and trust-weighted votes count proportionally to T3). A 0.50 ceiling caps how much weight your participation can carry in those settings; a 0.90 ceiling lets earned trust translate into proportionally larger influence.
Plain framing: software-only at 0.50 is comparable to email today — full access, but a low ceiling on what your reputation can carry. Hardware-bound at 0.90 is the difference between “I’m here” and “the network can verifiably stake reputation on me.”
Only have one device? You're still in.
Single-device users aren't excluded — they just have a lower trust ceiling (typically 0.50–0.75 depending on hardware). You can fully participate, post, earn ATP, and build karma. Adding a second device later raises your ceiling retroactively. This matters especially in developing countries where many people access the internet from a single smartphone — Web4 is designed to include them, not penalize them.
Why a ceiling at all? A lone device has no second device to corroborate its continuity — if it's lost, stolen, or quietly compromised, there's no independent witness to notice. Adding a witness turns a single trust root into a quorum: compromising multiple hardware roots at once is materially harder than compromising one, so the ceiling rises with corroboration, not with how long you've been around.
▶ Why hardware binding lasts: identity vs. presence vs. location
Not all identity attributes are equal. Web4 distinguishes three tiers:
- TPM Endorsement Key (burned at manufacture)
- CPU serial number
- Secure Enclave key (Apple platforms)
- MAC address (per network adapter)
- Hostname (admin-changeable)
- GPU UUID
- IP address (DHCP, VPN, roaming)
- Port, session state
Key insight: An IP address is a presence attribute, not an identity attribute. A machine that gets a new IP is still the same machine if its immutable anchor (TPM EK) matches. Web4 anchors identity at the immutable tier — making LCTs durable across reboots, network changes, and even OS reinstalls.