Linked Context Token (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 on your own device, anchored in that device's security chip when the identity carries real weight, witnessed by your other devices (each one independently co-signs that it’s really you), and resistant to faking.
Why the name “Linked Context Token”?optional - tap to unpack the three words
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.
Token - the thing itself: a cryptographic key you hold and present, not a username a server looks up. It lives on your own device, in that device’s security chip where there is one, and signs each action, so “showing” your identity means proving you hold the key, not typing a name someone else could type too.
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 on your own devices, not in passwords or company databases. Where a device has a security chip, 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
How to read the numbers below: every trust score on this page runs on a 0-1 scale. 0.5 is the neutral midpoint (a coin-flip prior: with no track record yet, trust is neither earned nor lost), and it doubles as the survival line: you start at the neutral midpoint and, if your identity is hardware-anchored, earn your way above it. Where you start is not a promise about where you stay: what a long absence does to a score. (A software-only identity is capped at that same midpoint: what a 0.50 ceiling actually costs you ↓.) Crossing below 0.5 restricts your features right away and is recoverable; only staying below it is fatal. 0.75 is solid, and 0.90 is the hardware-bound ceiling. Every decimal you meet from here on sits on that scale.
Read on for the full picture, or jump to the interactive security audit ↓
You're starting a 5-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 witnesses verify (verifiable, revocable).
But what about pseudonymity? A device-anchored identity doesn't mean a 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
In plain English, an LCT identifier names just two things: which device it is anchored to, and which agent (the label) is using it. 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 (“device-anchored 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 - the core standard'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).
Which artifact, precisely: that is the core standard's reference implementation, tested against an Intel TPM 2.0. The hardbound enterprise tier is a separate Rust codebase whose on-device (Jetson) binding is not yet validated: its CI runs against mocks. When other pages say “hardware binding is not yet validated on-device”, that is the one they mean. See the status ledger →
To be precise about what that proves: the hardware layer - the chip-level identity binding - really is tested on silicon. The trust, witness, and economic dynamics built on top of it are real code that runs, but they run on their own, not on a deployed network. So “validated on real hardware” means the foundation is proven - not that you can join Web4 today.
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). How the two ceiling rules combine (in 4-Life's calibration): your chip class sets the hardware maximum (the tier table further down), and your device count sets how much of that maximum you can actually reach - your effective ceiling is the lower of the two. One TPM laptop alone → 0.75 (device count is the limit, despite the chip's 0.90 rating); the same laptop plus two more device witnesses → the full 0.90 (now chip class is the limit); a software-only setup stays at 0.50 however many devices it spans - which lands right on the 0.5 survival line, so it's fair to ask whether a chip-less identity is dead on arrival. It isn't - what a 0.50 ceiling actually costs you ↓. 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 a deployed system, your devices handle identity witnessing; external nodes (universities, employers, individuals) add network-level verification but aren't required.
Where each of those actually stands today: the two are not at the same stage, and the difference is the answer to “so who is witnessing me right now?” The witnessing that needs nobody else is the part that runs: on a single machine, the acts an agent takes under your policy gate are checked and recorded in a hash-linked witness chain, and your trust scores move with the outcomes (solo is not the mechanism switched off). Device co-witnessing is built rather than exercised: the code ships and the hub handshake carries it, but it has not yet been driven on a real second device. And nobody outside the lab that builds this runs a network witness node yet. The spec is written, the code is installable today, and there is no public network open to outside members yet. What is deployed, piece by piece →
What's the incentive to run a witness node? This part is design rather than observation, since there is not yet a node to observe. As specified: 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 are meant to parallel email servers: some organizations would run their own for control, most individuals would use shared infrastructure, and the network is designed to work 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. Known leakage channels include 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 - a key you hold, 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 on your own device - not a password you type and not an account a server looks up, but a presence your device proves and your other devices witness.
More formally, an LCT is Web4's foundational presence primitive: a verifiable digital presence certificate that binds an entity to its context through witnessed relationships. It establishes where you exist in a web of trust, not merely who you are. In short, a device-anchored, 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)
The LCT primitive is defined by the core standard; you obtain an LCT-based personal identity through hestia.
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 →
You already work this way
Your name doesn't make you unique - lots of people share it. What makes you you is the record around you that other people hold: a birth certificate a society issued and witnessed; degrees, licenses, and accreditations that other institutions conferred and can confirm; employers, memberships, references. A résumé is a claim - the reference check is what makes it count, because the university and the employer hold the other half of every link. An LCT is exactly that: an identity that lives in the witnessed links around it, not in a number.
And trust already scales with how complete that record is - and with what's being asked. A first name gets you a conversation, not a loan. A landlord wants references; a hospital wants the license; a bank wants the whole file. Nobody demands everything for everything - the more consequential the act, the more of the record it takes. A brand-new LCT is like a newborn with only a birth certificate: real, welcome, and correctly trusted with very little until it earns more. Identity theft gets caught the same way in both worlds - the impostor's life diverges from the real record, and the people holding the other half of the links notice.
One deliberate difference: there's no Social-Security-style number. That central number is the thing that gets stolen, because a copy of it carries your whole identity along. An LCT's identifier comes from a key only you hold, and the identity lives in the links - so there's nothing to steal that carries the person with it. How trust is scored →
▶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 survival line - crossing below 0.5 restricts your features right away and is recoverable; only staying below it is fatal, and an entity that stays below can no longer act at all (its posts, votes, and ATP transfers stop being accepted); 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.
“Can no longer act” is not erasure. Your LCT and its record survive, and standing is a society's own view of you rather than one universal number. Your history persists either way. How living and dying work, and how far a death reaches.
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 caps combine with the device-count rule above: chip class sets the maximum, device count sets how much of it you reach - the lower wins. A lone TPM laptop is capped at 0.75 by device count; it takes two more device witnesses to unlock the chip's full 0.90.
These are trust ceilings, not starting points. Everyone starts at neutral (0.5).Starting on the survival line isn't a knife-edge: trust moves in small steps (an honest mistake costs roughly a hundredth), a dip just below 0.5 is recoverable, and permanent trust death takes a sustained pattern of bad behavior, not one stumble. 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. It lets everyone participate while signaling what their identity is anchored to (see below for what the ceiling actually limits), but this is a policy choice, not a technical inevitability, and the choice is contestable.
“Software-only caps at 0.50 - and 0.5 is the survival line. Am I dead on arrival?” Trust death isn't a snapshot - it's falling below 0.5 and staying there, a sustained collapse. The number compared is raw trust, not effective trust (raw × CI²). A lower CI raises your costs and narrows your access; it does not push you toward trust death. What the software-only ceiling really costs you is margin: you start at the line with no buffer above it, so any dip restricts your features until you climb back, and your reputation can never carry more weight than the line itself. Zero margin is the tradeoff you accept by anchoring an identity in software alone. Climbing back is not a separate mechanism you have to be granted: a ceiling caps how high behavior can carry your trust, not whether behavior moves it. A dip leaves headroom below the cap, and the same witnessed conduct that moves anyone else's trust is what crosses it. Do not read this page's device-loss list (the dropped-phone one) into this one: “no second witness to vouch” there is about re-establishing an identity after a device is lost, not about what moves trust.
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 sets the ordering of the lower tiers - each step down is a concretely larger attack surface (the specific values are 4-Life's calibration of that logic, not constants mandated by the spec):
- Secure Enclave (0.85): strong dedicated hardware, but its attestation chain runs through a single vendor - less independently verifiable than the cross-vendor TPM certificate ecosystem.
- FIDO2 key (0.75): proves possession of the key, not the state of the platform using it - a compromised laptop can still misuse a legitimate key press.
- Software (0.50): no hardware root at all - keys live in OS memory, so anything that compromises the OS can extract them.
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. Low-trust actions cost more ATP and earn less back, so your ceiling also caps how far you can work your own costs down. This is a different lever from the quality ramp, which keys on the quality of the work you made (V3) rather than on your trust: the percentages on that ramp are quality scores, not trust values.
- 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 - ubiquitous and easy to stand up, with 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). At every tier you post, earn ATP, build karma, and join societies; what changes is the terms of your participation. Adding a second hardware 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.
If that one device has no security chip, two of those things work differently. A software-only setup sits at the bottom of the range above and stays there however many devices it spans, so a second device does not raise your ceiling; only a hardware-anchored one does. And there is no second witness to vouch for you, so if you lose that device, you start over from zero with a fresh identity, where a hardware-bound user who loses their only device still recovers through community vouching over 3-7 days. Those are the two things to weigh before settling for this tier, and neither one puts you out: what a 0.50 ceiling actually costs you ↑.
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.
And if there is no security chip? Software-only is the fallback the standard names for exactly this position, and the role it names for it is bootstrap. The key lives in an encrypted file on your machine rather than inside a chip, so what day zero establishes is that the signature is valid and current, not that it is bound to a particular device. That is enough to start. What it is not enough for is standing in as a witness later: the standard says a software anchor cannot be the sole anchor for a recovery quorum, which is why this page says, further down, that a software-only setup has no second witness to vouch for it. Either way the day-zero step begins the record rather than finishing it. From your first interaction onward, what witnesses you is the community you are acting in.
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.) NASCENT and ACTIVE are two of the four LCT lifecycle states - the full state machine, including what SUSPENDED and REVOKED mean, is in the lifecycle section below.
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 hardware 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.