Linked Context Tokens (LCT)
Imagine your phone becoming your driver’s license — but one that can’t be photocopied, faked from a stolen photo, or impersonated from a remote computer.
More precisely: a digital ID card that lives in your device's security chip — hardware-bound, witnessed by your other devices (each one independently co-signs that it’s really you), and resistant to faking.
Linked — every LCT links to its creator (lineage), to the devices that witness it, and to a tamper-evident creation record — meaning every entry is cryptographically chained to the one before it, so altering or back-dating any record breaks the chain and is immediately detectable. That linkage is what makes the token forge-resistant.
Context — the device, platform, and role this LCT operates in. Yes, that’s the same role-context that T3 weights — but the word here means runtime environment, not a chat thread.
Together: the token links your hardware identity to the context you’re acting in — your role, your device, what you’re doing right now — so trust is always evaluated in situation, not in the abstract.
Key Takeaways
- 1. Your identity lives in your devices' security chips — not in passwords or company databases. The chip's private key is generated inside the silicon and physically can't leave it: not even the operating system or malware can read it out, so it can't be copied or forged. (This is the reason hardware identity works.)
- 2. Multiple devices (phone, laptop, security key) witness each other, making faking exponentially harder. Heads-up: “witness” means two distinct things on this page — (a) your own devices co-signing each other, and (b) optional outside infrastructure nodes. Most of the page means sense (a). (both senses explained)
- 3. If you lose a device, your other devices can recover your identity — no "forgot password" needed (minutes to hours with multi-device; days if only one)
- 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, even swapped per community). Only the label is changeable; the cryptographic fingerprint above stays stable, so your trust history follows you across label changes.
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?tap to expand — cryptography terms defined
You don't need to memorize these to use Web4 — they're tamper-resistant security chips already in devices you probably own. Skip ahead if the high-level idea (“hardware-bound identity”) is enough; expand for the specifics.
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”?
The short answer: your laptop and phone are each a device co-witness — they vouch for each other, so the network sees both signatures together and no single device alone can claim to be you.
Heads up — Web4 uses the same word “witness” for two distinct jobs. To keep them apart, this page names them: a device co-witness (your own devices attest to each other — this section), and a network witness (optional infrastructure nodes verify the network — answered directly below). If you meet plain “witness” later, context tells you which.
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:
What about my first device — who witnesses it before I have any others?
Your phone's chip vouches for itself — and that’s a different job from the device co-witnesses above. The security chip inside (TPM on Android/PC, Secure Enclave on iPhone, FIDO2 on a USB key) ships with a manufacturer-burned key — a cryptographic identity baked in at the factory by the chip vendor (Apple, Qualcomm, Yubico, etc.). When you sign up, this factory attestation proves “I am a genuine, untampered piece of hardware from manufacturer X” without you doing anything. It vouches that the hardware is genuine; a device co-witness (above) vouches that you are present — related, but not the same act, which is why we give this founding step its own name instead of calling it a third kind of “witness.” No central notary, no government issuer, no self-attestation waiting period — the chip's own factory certificate is the proof.
A single device with this manufacturer attestation gets a trust ceiling of 0.50–0.75 (depending on chip class) — the same 50–75% as just above. Adding a second device later doesn't replace this factory attestation — it adds a device co-witness on top, raising the ceiling toward 0.90. Why a ceiling at all? →
Wondering what this looks like from your side? See the first 5 minutes of setup → (visual mockup — QR codes, device pairing, what you actually tap)
Who runs witness infrastructure?
Short answer: anyone can. Web4 is an open standard (like email), not a platform (like Gmail). Network 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?
Think of an LCT as a digital ID card that lives in your device's security chip — not a password you type and not a key file you store, but a presence your hardware proves and your other devices witness.
More formally, an LCT is Web4's foundational presence primitive: 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)
What does each word mean?
Linked — witnessed by your other devices and trust peers. Context — pinned to a specific role or scope. Token — a compact, verifiable credential.
The Context word is what makes role-contextual trust possible: one person can hold separate LCTs as doctor, parent, or moderator, each carrying its own trust history. A surgeon trusted as a surgeon ≠ trusted as a cook. See how T3 weights roles →
▶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
These two panels answer different questions. Presence Trust Score is how much trust your identity can reach (your ceiling, on the 0–1 scale — more independent devices raise it). Compromise Difficulty and its Anomaly Detection reading are about an attacker: how much harder a forgery gets, and how likely it is to be caught. One describes you; the other describes someone trying to impersonate you.
Presence Trust Score
Compromise Difficulty
Each independent hardware chip multiplies the attacker's cost — compromising one doesn't compromise the others, so the work to break in stacks rather than substitutes.
- 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.
Why the numbers rank that way: a TPM or Secure Enclave is a separate, tamper-resistant chip that generates private keys inside itself and never lets them out — you'd need physical attack on the chip to forge that witness. Software-only keys live on disk where any malware that runs on your device can copy them. The ceiling reflects how hard the witness is to fake, not how convenient the device is to use.
- Hardware-bound, multiple devices — your laptop and security key witness you're still you. A new phone enrolls in minutes; reputation is intact.
- Hardware-bound, one device — recovery is possible but slower. You re-establish through community vouching — trusted witnesses confirm you're you, typically over 3–7 days.
- Software only — no second witness to vouch. You start over from zero with a fresh identity.
The pattern that matters: a permanent reputation is not a permanent lockout. Lose every hardware device at once and you're still not erased — you drop into that same social-recovery path (trusted witnesses re-confirm you're you), deliberately slow at 3–7 days and deliberately hard — easy recovery would mean easy identity theft — but real, not forever. The lone exception is the software-only case above: with no hardware witness to vouch for you, there's nothing to recover to.
The numbers below measure that gap — how strong a witness your hardware is, and therefore how cleanly you can recover.
New to the scale? Trust runs from 0 (none) to 1.0 (the theoretical max). Roughly: 0.5 is the alive/dead line — fall below it and an entity can no longer act: its posts, votes, and ATP transfers stop being accepted (see Aliveness); 0.75 is solid; 0.85 is strong; above 0.85 is uncommon; 1.0 is the theoretical ceiling, not a number anyone actually reaches. The ceilings below are points on that scale.
Each number below is the maximum T3 trust score your hardware can vouch for — even with perfect behavior, software-only identity tops out at 0.50. What each cap unlocks (rewards, witness role, recovery path) is detailed below the grid.
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. One honest tradeoff: the software-only ceiling means people without newer hardware are capped lower — we treat that as a feature, not a bug, because it lets everyone participate while signaling what their identity is anchored to (see below for what the ceiling actually limits).
Why isn't the top tier 1.00?
No hardware is unbreakable. A TPM ceiling at 0.90 instead of 1.00 reflects three real attack surfaces that “perfect” would have to rule out and no chip on Earth does:
- Physical attack on the chip. Decapping, fault injection, electron-microscope key extraction — rare and expensive, but documented against TPM and Secure Enclave research samples. Possible in principle for a determined adversary.
- Supply-chain compromise. A weakened chip could ship from the factory with a known-to-the-attacker key, or a compromised firmware update could leak attestations. Vendor certificate chains catch most of this, but not all of it.
- Side channels. Power, timing, electromagnetic leakage have all been used to recover keys from secure elements that were “supposed” to be inviolate. Modern designs harden against this; none are immune.
A ceiling of 1.00 would mean “mathematically impossible to forge.” That standard is reserved for things like one-time pads, not for hardware that ships in a phone. 0.90 is shorthand for “trusted enough to anchor most decisions, not trusted enough to be the only check on something irreversible.” The remaining 0.10 is the gap reserved for independent corroboration — multiple devices, witness attestations, behavioral history.
The same logic explains the other tiers: each step down (0.85, 0.75, 0.50) reflects a concretely larger attack surface — weaker tamper resistance, fewer side-channel hardenings, or no hardware root at all.
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.
I just installed the app on my one phone — who witnessed my first device?
Crypto vocab below? Plain-English glosses are in the “For non-crypto readers” collapsible just below this box →
Short answer: the chip itself does. The security element in your phone (TPM, Secure Enclave, or FIDO2 key) ships with a manufacturer-burned key — the Endorsement Key (EK) — and a certificate chain back to the chip vendor (Apple, Intel, Google, Yubico, etc.). When the app creates your LCT, it bundles a hardware attestation signed by that key. The chip is the day-zero witness: the network doesn't need a peer device to confirm “this is real hardware, not a virtual machine pretending” — the vendor certificate chain settles that question on its own.
What hardware attestation doesn't prove: that this specific chip belongs to a unique person — vs. someone running a phone farm with 100 devices in a rack. That's the question peer device witnessing answers, and it's why your trust ceiling sits at 0.50–0.75 with one device. Adding a second device (or earning attestations from other community members through your behavior) is what graduates you toward the higher ceilings.
So what triggers NASCENT → ACTIVE for a solo-device user? For multi-device users, it's a peer device co-signing. For solo-device users, it's either (a) infrastructure witness nodes confirming the hardware attestation is well-formed and the vendor certificate chain checks out, or (b) the first attestation arriving from a community member you interact with. Both paths produce a valid ACTIVE token; the multi-device path just lets you reach a higher trust ceiling faster. (See who runs those infrastructure witness nodes for the network-side answer.)
The chicken-and-egg, resolved: hardware attestation is the bootstrap — you don't need a peer to start. You need a peer (or earned community attestations) to graduate to the higher trust ceiling. Day one solo: you're a verified-real device with no continuity guarantee yet, capped at the software-or-single-hardware tier. Day thirty with one hardware device and consistent behavior: you're still capped at the single-hardware ceiling but earning toward it. Add a second device any time: ceiling rises retroactively.
▶ For non-crypto readers: what those terms above actually mean
The bootstrap FAQ uses some cryptography vocabulary that may be unfamiliar. Plain-English glosses:
Why this matters for Web4: these primitives let the network distinguish “real hardware in a known state” from “a script in a virtual machine pretending” without you having to install anything special, run a chain node, or trust a third-party identity provider. The chip carries its own provenance.
▶ Why hardware binding lasts: identity vs. presence vs. location
Not all identity attributes are equal. Web4 distinguishes three tiers:
- TPM Endorsement Key (EK) — 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.