Linked Context Tokens (LCT)
Web4's verified presence layer — hardware-bound, witnessed, and resistant to faking
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).
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 “witnesses”?
In Web4, a witness is another device or platform that independently confirms your presence is real. Think of it like co-signers on a 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 witnesses simultaneously to impersonate you — not just steal one password.
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 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 example)
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.
Security Comparison: Web2 vs Web3 vs Web4
Password Database Breach
Attacker hacks a company's server and steals the password database
What Happens When Things Go Wrong?
Hardware binding sounds great until your phone falls in a lake or your laptop gets stolen. If your identity lives in hardware, what happens when that hardware is gone?
Device Lost or Destroyed
This is why Web4 uses multi-device witness networks. If you have 3 devices and lose one, the remaining 2 can vouch for your identity on a replacement device. This works like a quorum: you set a threshold (e.g., 2-of-3) when you add devices to your constellation.
Device Stolen or Compromised
When you detect compromise (or suspect it), your other devices issue a revocation cascade. This invalidates the stolen device's keys and notifies every entity that trusted it.
All Devices Lost
Worst case. With no surviving devices, you need a social recovery — trusted witnesses who can vouch for your identity. Think of it like getting a new passport: you need people who know you to confirm you're you.
LCT Lifecycle: Birth → Active → Suspended → Revoked
Every LCT follows an explicit state machine:
Nascent: Birth certificate created, waiting for witness attestation. Active: Fully operational, can sign and participate. Suspended: Temporarily frozen (e.g., suspected compromise) — can be reactivated. Revoked: Permanently invalidated. Trust history preserved but no new actions allowed.
Expired LCTs can also exist — when a time-limited delegation reaches its end date.
Who Picks the Witnesses?
Natural follow-up question: if witnesses are so important, who chooses them? And what stops them from lying?
Selection is reputation-weighted, not random. Witnesses are drawn from a federation-wide pool, weighted by their track record of accurate attestations. Like jury selection, the goal is diverse, qualified, independent observers — not hand-picked allies.
Lying has consequences. Witnesses stake ATP when they attest. If their attestation is later proven false or biased (by cross-checking against other witnesses), they lose their stake — like validators in proof-of-stake systems. This economic penalty makes dishonest witnessing unprofitable.
Load balancing prevents exhaustion. No single witness can be overloaded. The system distributes attestation requests across the pool, tracks response times and availability, and penalizes witnesses who drop below service commitments.
Witness network coordination: 90 validated checks. Pool management, quorum selection, SLA tracking, and slashing protocols all formally specified.
What Would This Actually Feel Like?
The visitor's real question: “Do I need a special device, or does my existing phone work?” Short answer: your existing devices already have the hardware.
Open the app on your phone. It detects your device's security chip automatically — iPhones have Secure Enclave, most Android phones and laptops have TPM chips, or you can use a FIDO2 key (like YubiKey). You approve a one-time key generation. No passwords to create, no seed phrases to write down.
You request to join a Web4 society. Three existing members witness your presence — they confirm “yes, this device is real and this person is asking to join.” Think of it like three friends vouching for you at a members-only club. You start with 100 ATP and 0.5 trust.
Want stronger identity? Open the app on your laptop. Your phone and laptop cross-verify each other. Now compromising your identity requires stealing both devices — not just guessing a password. Each additional device makes your presence harder to fake.
After setup, hardware binding is invisible. Your device signs actions in the background — you just use the app normally. No 2FA codes, no password managers, no “prove you're not a robot.” Your phone's chip quietly proves it's really you.
This UX is aspirational — the current prototype uses stubbed hardware interfaces. The goal is zero-friction identity backed by real device attestation.
Why LCTs Enable Trust-Native Societies
1. Verifiable Presence
Because LCTs are hardware-bound and multi-witnessed, they resist forgery:
- Keys exist only in secure hardware (TPM, Secure Enclave, FIDO2), never exported
- Birth certificates prove when/where/by whom this LCT was created
- Multiple independent witnesses must attest (can't fool them all)
- Hardware attestation proves keys are in real chips, not software emulation
2. Behavioral Reputation
LCTs accumulate verifiable behavioral history:
- Every action is signed by your LCT, creating an audit trail
- Trust Tensors (T3) track multi-dimensional reputation
- Good behavior increases trust, bad behavior decreases it
- Can't escape reputation by creating new account (birth certificate shows lineage)
3. Precise Delegation
Task scoping enables limited authority:
- Create AI agents with specific capabilities (perception only, execution, delegation, etc.)
- Each task type has defined ATP budget and resource limits
- Compromised agent has limited damage radius
- Creator can revoke delegated authority instantly
4. Revocable Trust
Unlike stolen Web3 keys (permanent loss), LCTs can be revoked:
- Creator can instantly revoke compromised LCTs
- Stolen LCT becomes worthless immediately
- Recovery via device constellation (other devices witness revocation + new enrollment)
- Reputation preserved (history transfers to new LCT)
5. Accountability Chain
Lineage creates clear responsibility:
- Every LCT points to its creator's LCT
- Bad actor agents damage creator's reputation
- Organizations accountable for their AI agents
- Creates incentive for responsible delegation
Foundation for everything else: LCTs make ATP economics work (can't create fake accounts cheaply if presence requires hardware), Trust Tensors work (reputation bound to verifiable presence), Coherence Index work (behavioral consistency verifiable), and MRH work (context graphs rooted in verified presence).
What if I lose all my devices?
If you have multiple devices (phone + laptop + security key), losing one is manageable: your remaining devices revoke the lost one and you enroll a replacement. Your reputation transfers intact.
If you lose all devices at once (rare but possible), recovery depends on your witness network. Other entities that previously witnessed your identity can attest to who you are, similar to how banks verify identity through multiple documents. This is slower — think days, not minutes — and may require in-person verification for high-trust accounts.
This is an area of active research. Perfect recovery from total device loss without any central authority is one of the hardest open problems in decentralized identity.
Works With W3C Standards
Web4 identity isn't a walled garden. LCTs are designed to work with W3C Decentralized Identifiers (DIDs) — the same standard used by governments, enterprises, and other identity systems.
Identity Bridge
Every LCT maps to a standard DID Document. External systems (EU authorities, employers, apps) can verify Web4 identity using W3C protocols they already support.
Selective Disclosure
Prove “my trust score meets your threshold” without revealing the exact number. Like proving you passed a background check without disclosing medical records.
Verifiable Credentials
Your LCT can carry tamper-proof credentials: birth certificates, trust attestations, compliance certifications. Each independently verifiable by anyone.
Trust-Gated Messaging
Send messages that only entities above a trust threshold can receive. Spam can't reach you if senders must prove reputation first.
W3C DID/VC interoperability is implemented but not yet tested against external identity providers. The bridge maps LCT↔DID bidirectionally.
▶ Technical Details (For The Curious)
Full LCT Object Structure
{
"lct_id": "lct:web4:mb32...",
"subject": "did:web4:key:z6Mk...",
"binding": {
"entity_type": "human|ai|organization|device|...",
"public_key": "mb64:coseKey",
"hardware_anchor": "eat:mb64",
"created_at": "2025-09-11T15:00:00Z",
"binding_proof": "cose:Sig_structure"
},
"birth_certificate": {
"citizen_role": "lct:web4:role:citizen:...",
"context": "nation|platform|network",
"birth_timestamp": "2025-09-11T15:00:00Z",
"parent_entity": "lct:web4:...",
"birth_witnesses": ["lct:web4:...", ...]
},
"mrh": {
"bound": [...],
"paired": [...],
"witnessing": [...]
},
"attestations": [...],
"revocation": {"status": "active|revoked"}
}Supported Hardware Platforms
| Platform | Security Level | Max Trust | Ubiquity |
|---|---|---|---|
| Phone Secure Enclave | High | 0.75 | Very High |
| FIDO2 Security Key | Very High | 0.80 | Medium |
| TPM 2.0 (Laptop) | High | 0.75 | High |
| Multi-device (3+) | Very High | 0.95-0.98 | Medium |
| Software-only (fallback) | Low | 0.40 | Universal |