The Internet Has a Trust Problem

It's not “better” at everything. Every system has trade-offs:

• vs Passwords: More secure, but the higher trust tiers need hardware. Won't work on borrowed devices.
• vs OAuth (Google login): No central point of control, but more complex to implement.
• vs Blockchain wallets: Harder to create fake IDs, but not as portable across chains.
• vs Biometrics: Can't be stolen by breach, but requires specific device support.

What Web4 optimizes for: Economic resistance to spam/abuse while preserving privacy and decentralization. If you need something else, another solution may fit better.

Fair question - and the answer is both/and, not either/or. There's a whole modern stack for proving who you are: “Sign in with Google,” Verifiable Credentials (a W3C standard for digitally-signed claims you carry in a wallet app), and the new EU Digital Identity Wallet that will let every EU citizen hold government-issued credentials on their phone. These are good and real. Web4 doesn't fight them.

The difference is what a credential is. A credential is a photograph: at one moment, some issuer signed a statement - “this office says Alice is a licensed nurse.” It's portable and checkable, but frozen. It can't tell you whether Alice has been a reliable colleague for two years, or that she's trusted for surgery prep but unknown as a driver. Web4 keeps the living subject instead of the photo: trust that accumulates as you participate, is witnessed by others whose own reputation is on the line, and is scored per context rather than asserted once, globally, and forever.

And Web4 speaks their language. It can flatten its living trust into exactly the standard formats those wallets read - so your community membership can show up as an ordinary credential in your normal phone wallet, checkable by any standards-based verifier with no Web4 software at all. It can also go the other way: a credential from a university or a government becomes evidence a Web4 community can act on (“admit anyone who proves they're an accredited doctor”). The flow is one-way by design - Web4 can always project out a snapshot, but a snapshot can never be inflated back into real relationship history.

Honest caveat: “speaks the standards” means the formats work today (a Web4 community already issues these credentials to standard wallets). Getting Web4 issuers onto the EU's official trusted lists is a legal/governance process, not a coding one - that part isn't done, and we don't pretend it is.

Gradual, not all-or-nothing. The Web4 spec defines a 5-tier adoption pathway - each tier is independently useful, and you don't need to commit to the full stack:

1. Wrapper: Add a verifiable identity to your existing system. Zero code changes. (Like adding HTTPS to an existing site)
2. Observable: Start tracking trust based on actual behavior. (Like the browser padlock icon - visible trust signals)
3. Accountable: Stake energy on quality. Good work returns your investment; bad work costs you. (Like spam filters that actually work)
4. Federated: Your reputation travels with you across platforms. (Like email's federated model)
5. Native: Full Web4 stack - built from the ground up around verifiable trust.

Tiers 0-3 are reversible - you can always roll back. Only Tier 4 (full native) is a permanent commitment. Think of how HTTPS adoption worked: banks first, then e-commerce, then eventually the default everywhere.

Honest caveat: This adoption path is a design proposal, not a proven playbook. Whether the Wrapper→Native progression actually happens smoothly is an open question. Network effects could help (more participants = more value) or hurt (fragmented early adoption = no critical mass). We're designing for graceful degradation, not assuming universal adoption. Gradual adoption also means the system is only as strong as its coverage while the transition is under way, which is what low adoption actually feels like.

Want a concrete example? See “What's the concrete adoption path?” below for a Discord and Stack Overflow walkthrough.

This is a real equity concern, not a dismissed one. If reaching the higher trust tiers requires a TPM or Secure Enclave, then cost becomes a barrier. This answer is about the price and the ways around it; whether you are shut out without a chip at all is a different question, answered separately. Several factors work in favor of accessibility:

• Hardware is already widespread: Most phones sold since ~2018 include security chips (Secure Enclave, Titan, TPM). Even budget Android devices increasingly ship with hardware-backed keystores. The threshold is a $50 phone, not a $1000 one.
• FIDO2 security keys: USB-based keys like YubiKey cost ~$25 and work with any computer. A single key can anchor an identity without needing a modern phone.
• Community witnessing: In regions where personal device ownership is low, shared community devices + witness-based attestation can bridge the gap. A village elder or community center can attest to presence.

Honest caveat: None of these fully solve the problem. The most marginalized populations - those without any device access - would need some form of sponsored onboarding. Web4 is not unique here: every digital system faces this. But a system that claims to be trust-native must take equity seriously, not hand-wave it. This remains an active design priority.

This is the most-asked question we get. Right now, Web4 exists as a research prototype - the site you're on. No production Web4 apps exist yet.

What we do have: conceptual wireframes showing what a Web4 inbox, hiring dashboard, and review page could look like - trust scores next to messages, unfakeable reputation badges, energy-weighted reviews. See them on the A Day in Web4 page.

You can also follow the mechanics step by step in the How It Works walkthrough and the karma and consequences explainer. The concepts work - the question is what production tooling looks like, and that will emerge from real-world pilots.

Honest status: A browser extension or community plugin would be the first real-world step (see adoption tiers). No timeline - research takes as long as it takes.

Web4 uses a 5-tier gradual adoption model, like how HTTPS replaced HTTP over a decade without breaking the web:

1. Wrapper: Existing platforms add Web4 trust signals as metadata. No user changes needed. (Like adding HTTPS to an existing site)
2. Observable: Trust scores become visible to users. Platforms surface reputation from Web4. (Like the browser padlock icon)
3. Accountable: Actions have real consequences through ATP costs. Bad actors face energy costs. (Like spam filters that actually work)
4. Federated: Communities connect their trust graphs. Portable reputation across platforms. (Like email's federated model)
5. Native: Full Web4 protocol stack. Hardware-bound identity, society governance, cross-platform trust. (Like the web itself)

What Tier 1 actually looks like: Imagine a coding forum like Stack Overflow. Today, answers are ranked by votes. At the Wrapper tier, the forum adds a Web4 trust layer: each user's answers start building a T3 trust profile (Talent = answer accuracy, Training = domain expertise, Temperament = community behavior). The forum's existing UI doesn't change - but behind the scenes, a trust-weighted ranking emerges. Spam answers from new accounts cost ATP to post and earn nothing back. Within weeks, high-quality answers naturally rise above vote-gamed content. No blockchain, no tokens, no user-facing changes - just better signal-to-noise.

What Tier 2 (Observable) looks like: Same Stack Overflow, six months later. Now trust scores are visible. Next to each answer, you see the author's T3 breakdown: “0.87 Talent in Python, 0.91 Training in distributed systems, 0.72 Temperament.” You can tell at a glance whether this person has a track record in the topic they're answering about. A user with 10,000 reputation points but 0.31 Talent in security? Their security answers get naturally de-prioritized - not banned, just surfaced honestly. The browser padlock analogy: HTTPS didn't change how websites worked, it just made trust visible. Observable tier does the same for people.

What a community could try today: Imagine a Discord server with 200 members and a spam problem. Without any Web4 software, the community could adopt Web4 principles:

• Energy cost: New members earn posting rights by participating in welcome channels first (equivalent to ATP ramp-up for new entities)
• Behavioral trust: Track helpful vs. unhelpful contributions per member. After 50+ interactions, let high-trust members moderate (equivalent to T3 maturation)
• Portable reputation: When members join a sister server, carry their trust score over (equivalent to federated trust)
• Consequences: Spam costs the spammer's earned trust. No bans needed - low-trust members simply have less reach (equivalent to ATP/CI throttling)

This isn't Web4 - it's Web4 thinking applied with existing tools. A bot that tracks contribution quality and adjusts permissions accordingly is a manual Tier 1 implementation. The gap between “Discord bot that tracks trust” and “real Web4 wrapper” is an LCT and cross-platform portability.

Who would build this? The platform's own engineering team, or a third-party integration (like adding Stripe for payments). The incentive is concrete: platforms spend enormous resources on spam moderation, fake account detection, and content ranking. A Wrapper-tier integration replaces heuristic moderation with trust-weighted signals - Reddit estimated it spends ~$50M/year on content moderation. Even a 10% reduction pays for the integration.

The honest gap: All five tiers are designed and specified. Tiers 1-2 could be integrated into existing platforms today. But no platform has done so yet. The path from “working simulations” to “first real integration” requires a willing partner - a community, platform, or organization that sees value in trust-native infrastructure. Whether platforms that do start would then climb the rest of the ladder is a second open question: the adoption path is a design proposal, not a proven playbook.

Web4 is designed as an open ontology, not a platform. Like email or the web itself, the infrastructure is federated - multiple independent operators can run nodes that interoperate. No single company controls it.

In practice: witness nodes can be run by universities, nonprofits, companies, or individuals. The trust system is designed so that no single operator can manipulate the network - collusion requires coordinating multiple independent parties.

Web4 identity is also designed to work with W3C Decentralized Identifier (DID) standards - the same standard used by governments and enterprises. Your LCT maps to a standard DID Document, so external systems can verify Web4 identity using protocols they already support.

Honest caveat: This is still early-stage research. Full deployment requires standardization, adoption, and tooling that doesn't exist yet. See the roadmap FAQ above for where things stand today.

Yes, and the honest answer has two halves. Software-only identities are cheap, so nothing stops someone minting a thousand of them. What they cannot cheaply mint is a thousand trusted ones: every identity that climbs above the software-only ceiling is bound to a physical device with a security chip (TPM or Secure Enclave, built into most modern phones and laptops), so a thousand credible identities means a thousand devices, thousands of dollars and physical logistics. This is a Sybil resistance strategy, not a Sybil prevention guarantee.

Compare to email: creating 1000 accounts costs nothing. The goal isn't to make fake-identity attacks impossible (nothing can), but to make them economically irrational for most attackers. Nation-state adversaries can always outspend; the system is designed to resist casual abuse, not unlimited resources.

This is the breadth question. Whether a pile of hardware behind a single identity buys that one identity a higher score is the other half, and the answer there is no: can someone buy 50 devices to create a super-trusted identity?

Honest caveat: A sufficiently motivated adversary with a large budget can still attack. Web4 raises the floor, not the ceiling.

Bootstrap requires a seed network of trusted witnesses. This is the classic "who watches the watchmen" problem. Proposed approaches:

• Partner with existing identity providers (universities, employers) as initial witnesses
• Hardware attestation from device manufacturers (Apple, Google, etc.)
• Web of trust model where existing members vouch for newcomers
• Gradual rollout starting with high-stakes contexts (not consumer social)

What the first 100 interactions look like:

1. Actions 1-3: Three founding members create the society with hardware-bound presence tokens. They witness each other - establishing the initial trust graph.
2. Actions 4-20: Founders perform real work (writing governance rules, creating initial resources). Trust builds slowly from 0.50 - each quality contribution moves the needle by ~0.02.
3. Actions 21-50: New members join, vouched for by founders. The founders are ahead on record length, not on rate: the same ~0.02 step is available to a newcomer doing the same quality of work.
4. Actions 51-100: Roles emerge, specialization begins. The society's trust graph becomes rich enough that MRH boundaries create meaningful context. Some members hold more ATP than others, having been paid for more confirmed work.

Honest caveat: Bootstrapping is genuinely hard. No perfect solution exists. This is an active research area, not a solved problem.

Fewer than you might think. 3-5 people is enough for a trust graph to form at all: each person can witness the others, and the MRH graph becomes meaningful with 2-hop connections. A small team or study group could start there. That is the floor for the structure to exist, not the point where the dynamics get stable, which is a larger number and a different question (how many people it takes to work well).

The key constraint isn't size - it's reciprocity density. Ten people who actively interact produce richer trust data than 1,000 passive accounts. Web4's economics naturally reward active communities: ATP flows to those who contribute value, so even a small group that does real work together builds meaningful reputation quickly.

See the cold-start walkthrough above for concrete dynamics.

This is a real concern. If every identity that carries weight needs a TPM or Secure Enclave, then hardware manufacturers have power over whose reputation can grow. Web4 mitigates this in several ways:

• Multiple standards supported: TPM (Intel/AMD), Secure Enclave (Apple), Titan (Google), and future open-source hardware. No single vendor lock-in.
• Attestation, not permission: Hardware provides cryptographic proof of presence - it doesn't need to “approve” your identity. The chip signs; it doesn't decide.
• Open specification: Any hardware that meets the attestation spec can participate. This invites competition rather than consolidation.

Honest caveat: This shifts trust from platforms to hardware supply chains. That's a different dependency, not zero dependency. And open standards can be captured - the history of standards bodies shows that well-resourced incumbents sometimes steer “open” specs to favor their implementations. Whether hardware dependency is better than platform dependency depends on whether supply chain competition proves more durable than platform competition. That's an empirical question, not a settled one.

No. Web4 uses multi-device witness networks - your identity is spread across multiple devices (phone, laptop, security key). If one is stolen, the others can revoke the compromised device and approve a replacement.

When you report a compromise, a revocation cascade propagates through the witness network. The stolen device's keys become instantly invalid. Any entity that trusted the compromised device gets notified. Your trust history and reputation are preserved - only the compromised device is cut off.

Recovery works like a quorum: you set a threshold when adding devices (e.g., 2-of-3). As long as enough surviving devices agree, you can recover without losing your identity or accumulated trust.

Honest caveat: If all your devices are lost simultaneously, recovery requires social vouching from trusted witnesses - deliberately slow and hard, because easy recovery would mean easy identity theft. See the LCT explainer for the full lifecycle.

ATP can be transferred, but 5% of every transfer routes to the community redistribution pool (not destroyed) - making circular farming unprofitable. Teams primarily earn energy together. When a team creates value jointly, each contributor receives their own energy reward based on their verified contribution.

Organizations work through shared context boundaries (MRH). Members of a team see each other's work, validate each other's contributions, and collectively build the team's reputation. But each person's individual energy and trust remain their own - you can't buy someone else's reputation, and a team member's bad behavior affects them, not you.

What about frequent transfers? If a team of 5 passes ATP back and forth for collaborative projects, the 5% fee compounds quickly - 10 transfers loses ~40% of the original amount. That's by design: the system incentivizes direct value creation (where everyone earns individually) over resource shuffling (where ATP moves between wallets). Teams that create together don't need to transfer; teams that delegate work use single transfers, not chains.

Honest caveat: The details of organizational identity and pooled contribution attribution are still being worked out. This is one of the harder design problems.

Concrete example: Say Alice and Bob each have 100 ATP and try to inflate their balances by sending energy back and forth.

• Round 1: Alice sends 100 to Bob. 5 ATP routes to the pool. Bob receives 95.
• Round 2: Bob sends 95 back. 5% to the pool. Alice receives 90.25.
• Round 3: Alice sends 90.25. Bob receives 85.74.
• Round 4: Bob sends 85.74. Alice receives 81.45.

After just 4 round trips, they've lost nearly 19% of the original energy - and gained nothing. No trust increase, no reputation, no value. Every transfer is logged as a transfer, not a contribution, so it doesn't build trust either.

By round 14, half their energy has moved to the pool. By round 28, three quarters of it. The math makes circular farming a guaranteed loss, not just a bad strategy.

Why 5% specifically? It's low enough that legitimate transfers (tipping a helper, funding a project) are affordable, but high enough that any scheme requiring multiple round trips bleeds out quickly. The compound loss is the mechanism.

Hardware transitions are handled through identity migration - your existing device attests to your new device before the old one is retired. Think of it like transferring a bank account: you prove you're you on the old system, then establish yourself on the new one.

The trust history travels with the identity, not with the hardware. Your trust tensor, energy history, and behavioral record are associated with your identity chain, not with a specific chip. Upgrading hardware is like getting a new passport - the person is the same, the document is new.

Honest caveat: A post-quantum transition (where current cryptography breaks) would require a coordinated migration - similar to the Y2K effort but for identity. This is a known hard problem across all cryptographic systems, not unique to Web4.

Context boundaries (MRH) don't filter every message globally - they define who you can see based on your local trust network. This is computed locally, not centrally. You don't need to check every person on the internet; you only check the people trying to reach you, against the trust graph of people you already know.

This is similar to how email spam filters work today - except instead of content analysis (which AI can defeat), the filter is based on trust relationships (which require real behavioral history to build). The computational cost scales with your network size, not with the internet's size.

Honest caveat: Performance at true internet scale (billions of users) is unproven. Simulations handle thousands of agents. The gap between simulation and deployment is significant and contains unknown challenges.

Communities are federated, not merged. When you move from one community to another, your trust history is visible but not automatically imported. The new community can see your track record - but they set their own standards for what trust level earns what privileges.

Think of it like an academic transcript: your grades from one university are legible to another, but the second university decides what credits to accept. Your data analysis trust of 0.85 in Community A might start you at 0.6 in Community B, because B has stricter standards.

The key design: trust is portable but not dictatorial. No community is forced to accept another community's standards. This prevents one community from inflating trust scores and exporting them.

Honest caveat: The specific mechanics of cross-community trust mapping are still being researched. How much to weight external trust vs internal trust is a policy decision each community makes - the protocol provides the infrastructure, not the rules.

Communities can split, just like open-source projects can fork. When they do, each member keeps their full trust history and ATP balance - nothing is “divided” because trust and energy belong to the individual, not the community.

Think of it like employees leaving a company: their skills and resume go with them. If the “Research Collective” splits into “Theory Group” and “Applied Lab,” each member chooses which to join (or both). Their trust scores are visible to both new communities, which each set their own acceptance policies - just like cross-community trust transfer.

The relationships between members are also preserved: if Alice trusts Bob, that relationship exists in the trust graph regardless of which community they're in. Communities are views into the graph, not containers that own the data.

Design goal: The ability to fork - without losing your identity or reputation - keeps community governance honest. Authoritarian communities lose members to better-governed alternatives. See the hub for how communities and federations merge and compete.

The calculations are simpler than they sound. For a single action, the system needs to: check your ATP balance (a number), update your T3 scores (three numbers), compute CI (a rolling average), and let recipients confirm quality. Each operation is basic arithmetic - comparable to updating a database row.

The key insight: most computation is local, not global. Your trust score doesn't need to consult every user on the network - only your direct connections (MRH limits this to 3 hops, roughly the size of a social circle). Witness verification uses your own devices, not a global network. V3 scoring aggregates confirmations as they arrive, not all at once.

The expensive part is federation-level operations: cross-community trust mapping, consensus across unreliable networks, and global reputation queries. These are batched, cached, and eventually consistent - similar to how DNS propagation works today.

Honest caveat: At billions of users, the trust graph becomes enormous and query patterns are unpredictable. Simulations handle thousands of agents comfortably; the gap to internet scale contains real engineering challenges (sharding trust graphs, caching strategies, witness coordination latency). This is why the adoption path starts with small communities, not the whole internet.

For most users, most of the time: invisible. Your device's security chip handles attestation automatically, like how HTTPS encryption works - you don't think about it, it just happens. You pick up your phone, the chip confirms it's your device, and you're verified.

Witnessing becomes visible only for high-stakes actions: creating a new identity, recovering from device loss, or performing actions that require elevated trust. In those cases, you'd see something like “2 of your 3 linked devices confirmed this action” - similar to how banks send a verification SMS for large transfers.

Honest caveat: The exact UX hasn't been built yet. Getting the balance right between security and friction is a design challenge. Too invisible and users don't trust it; too visible and it becomes annoying.

Hardware-bound identity doesn't mean one person, one device. It means one person has at least one device that anchors their identity. You can use a shared computer - you just can't perform high-trust actions from it without your own device nearby to witness.

Think of it like a hotel business center: you can use the shared computer to browse, but for banking you'd use your own phone to authenticate. Web4 works similarly - shared devices can access public content, but identity-verified actions need your personal device to co-sign.

Honest caveat: This creates an access gap for people who don't own any personal device with a security chip. How to include the unbanked/undeviced population is an unsolved equity problem - and a real one.

Yes, but transparently. AI agents in Web4 are first-class entities - they get their own LCT, their own ATP budget, and their own trust tensor. The critical difference: they must be labeled as non-human.

Where does an AI's hardware anchor come from when it has no chip? Its LCT is rooted in its creator's hardware-bound identity - a person or organization that is hardware-anchored issues the agent a scoped, revocable delegation (like a building badge issued by an authorized person). The anchor is inherited through the chain, not possessed directly; the agent's LCT traces back to whoever issued it, and that issuer stays accountable for what the agent does. LCT page has the longer mechanics →

An AI agent earns trust the same way anyone does: by taking actions, spending ATP, and building a behavioral track record. A helpful coding assistant that consistently delivers quality work earns high trust in that role. A spam bot burns ATP faster than it earns and dies - just like a human spammer would.

Initial trust is cold-start: new agents begin with minimal ATP and must be vouched for by their operator (the human or organization that deployed them). The operator's own reputation is on the line - deploy a malicious bot, and your trust takes the hit too.

Honest caveat: The boundary between “AI agent” and “human with AI assistance” is blurry and getting blurrier. How to handle AI-augmented actions (you wrote it, but GPT helped) is an open question. The current design handles clearly autonomous agents well but struggles with the hybrid cases. On the regulatory side, Web4's transparency and audit primitives are designed to map to EU AI Act (2024/1689) requirements - but that compliance hasn't been independently validated yet.

Yes, this is a genuine tension. Web4's trust model assumes reputation persists across lives and contexts. GDPR (and similar regulations) give individuals the right to request data deletion.

Key distinction: Web4 stores behavioral scores, not personal data. Your trust tensor says “this entity has 0.85 data analysis trust earned across 200 interactions” - it doesn't store your name, email, or the content of those interactions. The score is pseudonymous and attached to a hardware key, not a legal identity.

That said, if someone can correlate a hardware key to a person, the trust history becomes personal data under GDPR. This creates a real compliance challenge that would need to be addressed through either: (a) allowing identity resets with trust loss, or (b) legal frameworks that exempt behavioral scores from deletion rights.

Honest caveat: Neither solution is clean. Allowing resets undermines permanent consequences (a core feature). Exempting scores from deletion rights is legally uncertain. This is an unresolved policy question, not a technical one.

Both - it depends on what you mean by “privacy.”

The core design choice: Web4 removes the central observer (no platform sees everything about you) but adds behavioral permanence (your actions have lasting consequences). For most users, this is a net privacy improvement - your identity and activity are harder to surveil, even as your reputation becomes persistent.

Honest caveat: Known privacy leakage channels include metadata correlation, timing analysis, and trust graph topology inference. No system eliminates privacy risk entirely. The claim is that decentralized, scoped visibility is structurally better than centralized, unlimited surveillance - not that it's perfect. See pseudonymity FAQ and VPN/Tor FAQ for specifics.

Not everyone can see everything. Web4 uses context boundaries (MRH) to limit who sees what. Your trust scores are only visible to entities within your relationship network - not broadcast to the world.

Think of it like real-life reputation: your coworkers know you're reliable at work, your neighbors know you keep a tidy yard, but neither group sees the other's picture. MRH formalizes this - trust is contextual, scoped by the depth of your relationship chain.

What's visible: behavioral scores (e.g., “0.85 trust in data analysis”), not the underlying interactions. The score is attached to a hardware key, not your name. A spammer with no trust connections can't even see your data, let alone manipulate it.

Zero-knowledge trust verification goes further: you can prove your trust meets a threshold (“my T3 Training exceeds 0.7”) without revealing the actual number. This enables trust-gated access - join a community, accept a task, or enter a partnership - while keeping your full trust history private. Think of it like a credit check that says “approved” without showing your exact score.

Honest caveat: Privacy is structural, not absolute. Someone who shares your trust network can see your scores in that context. And if a hardware key is ever linked to a real identity (through a data breach or correlation attack), the trust history becomes de-anonymized. MRH limits blast radius; zero-knowledge proofs limit information leakage; but neither guarantees perfect anonymity.

This is a genuine equity concern, and it is a narrower one than “you are shut out.” Web4 identity does not require a security chip. Anchoring an identity in software alone is a supported starting point, and the standard is explicit that an entity able to offer only weak evidence must not be excluded by the protocol, only weighed as riskier. What hardware buys is ceiling, not entry: software-only tops out at 0.50, against 0.75 (FIDO2), 0.85 (Secure Enclave) and 0.90 (TPM). So what changes without a chip is the terms of your participation.

Those terms are not a rounding error, and this page will not pretend otherwise: what a 0.50 ceiling actually costs you is zero margin above the 0.50 survival line and a reputation that cannot climb, and the site's own risk register calls that a second-class experience baked into the architecture. Most modern devices already have a chip, but “most” isn't “all,” and what one costs, or what to do if you cannot buy one, is a different question: what about people who can't afford devices with security chips?

The 5-tier adoption model helps: at the Wrapper and Observable tiers, existing platforms handle identity while exposing Web4 trust signals. Full hardware binding only applies at higher tiers. This creates a gradual on-ramp rather than an all-or-nothing gate.

Honest caveat: Any system that makes trusted identity expensive to build will disadvantage those with fewer resources. Web4 makes Sybil attacks expensive; the tradeoff is that climbing past the software-only ceiling requires hardware investment, so the people with the least hardware are the people whose reputation cannot grow. Whether this tradeoff is net-positive depends on how affordable secure hardware becomes - a trend Web4 can influence but doesn't control.

The 0.5 threshold is a society-level parameter, not a protocol constant. Each society (community) in Web4 sets its own policies through the SAL (Society-Authority-Law) governance framework. A scientific research community might set a higher trust threshold (0.7) for publishing. A social community might set a lower one (0.3) for casual interaction.

The 0.5 default draws from phase transition mathematics: below 0.5, behavior is statistically indistinguishable from random; above it, intentional patterns emerge. But it's a starting point, not a mandate. Cultural trust norms absolutely vary - that's why governance is society-local, not protocol-global.

Not everything is society-set, though. The T3 composite blend (Talent 0.4, Training 0.3, Temperament 0.3) is protocol-level: the specification fixes it so every conforming implementation computes the same composite, and no society can vote itself different weights. See the two governance layers for where that line falls. What a society does set, alongside its thresholds, is the bar each role has to clear (a surgeon role can demand high training, a moderator role high temperament) and the decay rates: a fast-moving startup culture might shorten Training decay (skills go stale faster) while a traditional guild might lengthen it (craft knowledge persists).

When societies with different norms interact through federation, cross-society trust translation happens at the boundary - your reputation is portable but interpreted through the receiving community's local norms. This is similar to how academic credentials are recognized internationally but weighted differently by each institution.

What about societies with fundamentally incompatible values? Web4 doesn't force consensus - societies that can't reconcile their norms simply don't federate. See the hub for how bridging societies and value boundaries work.

Short version: almost every number in Web4 is calibrated, not derived.Derived would mean the math forces the value - there's a proof it could be nothing else. Calibrated means it was tuned in simulation until the system behaved sensibly, the way an engineer dials in a thermostat rather than computing it from first principles. A few values aren't even tuned - they're design choices inspired by an analogy. None of them are claimed as physical constants.

Here's where the numbers you'll meet come from, and the page that explains each in full:

• 0.5 - the survival line, and the default trust score. A design choice inspired by phase-transition behavior: below it, conduct is hard to tell from random; above it, intention shows. It's also a per-society setting, not a protocol constant - see Is the 0.5 threshold universal?
• 3 hops - the relevancy horizon (MRH), ~0.7 trust kept per hop. Calibrated: in real social networks the signal-to-noise of “friend of a friend of a friend” collapses past about three hops. Walk the decay yourself on the Trust Neighborhood.
• 0.02 - the trust update step. Calibrated to be small on purpose: trust should move steadily with each action, not lurch on any single one. The Trust Tensor page shows the full 0.02 × (quality − 0.5) rule.
• 5% - the energy transfer fee. A design choice that makes pooling and circular trust-farming unprofitable without taxing honest collaboration - see Why a 5% transfer cost?

Why say all this out loud? Because the honest answer to “why 0.5 and not 0.48?” is “we tuned it, and a future version may retune it” - and that's a feature, not an embarrassment. Calibrated parameters are knobs, not commandments: each society can already move several of them to fit its own norms. Being explicit that these are empirically chosen values rather than magic constants is what keeps the framework science, not numerology.

During the transition from Web2 to Web4, you don't maintain two separate identities. Instead, you gradually accumulate Web4 trust on top of your existing accounts, like adding a reputation layer over what you already use.

Here's what the transition actually looks like at each adoption tier:

• Wrapper tier (you won't notice): Platforms add trust scoring behind the scenes. You keep using Gmail, Reddit, etc. exactly as before. Your actions start building a trust history you can't see yet.
• Observable tier (you see trust scores): A trust badge appears next to usernames - like the blue checkmark, but earned through behavior, not payment. You start noticing which reviews, messages, and posts come from high-trust sources.
• Accountable tier (you feel the difference): Posting costs a tiny amount of ATP. High-trust users barely notice (their costs are lower). Spammers notice immediately (their costs are higher). Your existing account still works - it just has consequences now.
• Federated tier (your reputation travels): You join a new platform and your trust follows you. No more starting from zero. This is when the dual-identity friction disappears - your Web4 trust IS your cross-platform identity.

The key design choice: Web4 wraps existing systems rather than replacing them. You don't wake up one morning and switch to “the Web4 internet.” Your current apps gradually become trust-aware, and the transition feels more like email gaining spam filters than like switching from postal mail to email.

Honest caveat: This is the designed path, not a proven one. The real user experience will depend on which platforms adopt, how fast, and whether the trust scoring is accurate enough to feel fair rather than arbitrary. Early adopters will feel friction that later users won't.

V3 measures outputs across three dimensions: Valuation (how valued by the community), Veracity (accuracy and honesty), and Validity (appropriateness for context). For creative work, these shift weight naturally:

• A satirical essay: High Valuation (entertaining), variable Veracity (it's satire - literal truth isn't the point), High Validity (appropriate for the context)
• An abstract painting: High Valuation (community appreciates it), Veracity less relevant, High Validity (fits the art community's norms)

V3 scoring is role-contextual, just like T3. A poem isn't scored the same way as a research paper because they exist in different role contexts with different community norms. The community that receives the work defines what “valuable” means in their context.

Honest caveat: This does mean unpopular or avant-garde work may score lower on Valuation initially. Innovation often conflicts with existing norms. Web4 mitigates this through Veracity (truthful work retains long-term value) but doesn't eliminate the tension between novelty and community approval.

Every action in Web4 creates a tamper-evident record - hash-chained event logs that can't be altered after the fact. Think of it like a receipt that the whole network can verify.

The system watches for anomalies automatically: sudden wealth spikes, coordinated behavior between accounts, trust scores changing faster than should be possible, or activity patterns that don't match an entity's history. When something looks wrong, it gets flagged - not by a moderator, but by the math.

This is different from today's internet where cheating is only caught when someone reports it. In Web4, the audit trail is continuous and the detection is automatic. You can still try to cheat - but the system is designed so that cheating is expensive (burns ATP), detectable (anomaly alerts), and unprofitable (low-quality work earns nothing).

Think of it as a consistency score. The Coherence Index (CI) measures how consistently you behave - across time, across communities, and across situations.

Example - a freelance designer named Sam:

• Sam delivers quality design work for 6 months → CI rises to 0.88
• Sam starts rushing jobs to take on more clients → quality drops, CI falls to 0.71
• Effective trust = raw trust (0.72) × CI² (0.71² = 0.50) = 0.36
• Sam notices higher action costs and less visibility → slows down, quality returns
• After 2 months of consistent quality again → CI recovers to 0.82

The key insight: CI penalizes inconsistency more than low trust does. The squared relationship means a CI of 0.71 cuts your effective trust nearly in half. You can't build trust by being great sometimes and careless other times - the system rewards reliability over occasional brilliance.

What this feels like: If your CI is high (above 0.80), you barely notice it - everything just works. If it drops, you'll feel it through higher action costs and reduced reach. It's like a credit score that measures behavior consistency instead of payment history.

Yes - pseudonymity is built in, not bolted on. Your Web4 identity is a hardware 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 in the physical world.

This is actually stronger pseudonymity than most platforms today. On Twitter or Reddit, your “anonymous” account can be correlated through IP addresses, browser fingerprints, or legal subpoenas to the platform. In Web4, there's no central platform that knows your real identity - your identity lives in your hardware, not on a server.

For high-stakes cases (whistleblowing, political dissent, support groups), Web4 adds zero-knowledge trust proofs: you can prove you meet a trust threshold (“I have >0.7 trust in journalism”) without revealing which entity you are. A whistleblower can prove they're a credible insider without exposing their identity even within the trust graph.

What Web4 prevents isn't pseudonymity - it's disposable identity. You can be anonymous, but you can't be anonymous and have unlimited fresh starts. Your pseudonymous identity accumulates consequences just like any other. That's the tradeoff: your reputation follows you, but your name doesn't have to.

Honest caveat: Hardware-bound identity creates a correlation risk. If an adversary can identify your device (through physical surveillance or supply chain data), they can link your pseudonymous identity to you. Multi-device witness networks reduce this risk but don't eliminate it. For journalists and activists in hostile states, device security is the weakest link - and that's a hardware problem, not a protocol one.

Not separate identities - separate roles. Web4's Trust Tensor is already role-scoped: your trust as a software developer is tracked independently from your trust as a cooking enthusiast. You don't need separate accounts because your single identity naturally has different trust profiles in different contexts.

Think of it like a professional license: one person can hold both a medical license and a pilot's license. Your medical expertise doesn't affect your pilot rating and vice versa. Web4 works the same way - one identity, many trust dimensions.

What does carry across roles is your Coherence Index, which multiplies each role's trust rather than being carried into it. Temperament is not the portable one: it is scored per role, like Talent and Training. If you're consistently dependable in one domain, that record is visible elsewhere as evidence, even though your trust in the new role starts fresh.

This is a deliberate design choice: someone who's reliable as a doctor is probably reliable as a neighbor, but the standard makes anyone acting on that inference do it deliberately, rather than having a score arrive on its own. The system captures the intuition without collapsing everything into a single score.

Honest caveat: Some people genuinely want “firewall” separation between identities (e.g., a public figure who also participates in support communities). Web4's current design doesn't support fully separate identities on one device. For high-privacy scenarios, a separate device provides true identity separation - but that's a cost tradeoff.

Short answer: no. Coherence Index measures behavioral consistency - not IP addresses or geographic location.

CI tracks four dimensions: spatial (do you act within your declared scope?), capability (do you do what you say you can?), temporal (are your patterns stable over time?), and relational (are your relationships consistent?). None of these require knowing your IP address or physical location.

“Spatial” here means scope of activity - which communities you participate in, which roles you claim - not where your device is. A journalist using Tor to research a sensitive story has the same CI as one using a coffee shop Wi-Fi, because CI measures what you do, not where you connect from.

Identity in Web4 is bound to hardware (via LCT), not to network addresses. VPNs and Tor change your network path but don't affect your device's cryptographic identity or your behavioral patterns.

Honest caveat: Some future applications built on Web4 might optionally use location data (a delivery service, for example). Those applications would set their own policies. But at the protocol level, Web4 is network-path agnostic.

Web4 has two governance layers with different scope:

• Society-level (SAL - Society-Authority-Law): Each community sets its own policies - trust thresholds, ATP costs, role definitions, membership rules. Communities can customize most parameters through their SAL governance framework. This is where the 0.5 threshold, specific decay rates, and enforcement rules live.
• Protocol-level: The core protocol - the trust tensor math, ATP mechanics, LCT hardware binding, MRH relationship structure - is defined by an open specification on GitHub. Changes follow open-source governance: proposals, discussion, review, and implementation. Anyone can propose changes, argue against them, or fork the spec.

The key design choice: most things users care about are society-level, not protocol-level. If your community wants higher trust thresholds or different energy economics, you change your community's parameters - you don't need to change the protocol. This is like how HTTP defines the protocol but each website chooses its own content policies.

Honest caveat: Protocol-level governance for a nascent open-source project is currently informal - whoever contributes meaningfully to the specification has influence. If Web4 grew to production scale, this would need to formalize (like W3C or IETF). That transition from “small research project” to “governed standard” is itself an unsolved organizational challenge.

The Markov Relevancy Horizon (MRH) works like degrees of separation with decay. Your direct contacts (1 hop) weigh your actions at 70%. Their contacts (2 hops) weigh them at 49%. Three hops away: 34%. Beyond three hops: zero trust weight - still visible to anyone who goes looking, just carrying no vouch behind it.

Concretely: if you post a helpful answer in a coding community, people who've directly interacted with you see it immediately. People who share mutual contacts see it with reduced priority. People with no connection path aren't shown it by default - it isn't censored, and they can still find and read it deliberately; it just arrives with no trust weight, because it's outside their relevancy horizon.

This means spam can't go viral. A spammer with no trust relationships sends messages that carry zero weight everywhere - no one's trust amplifies them, so nothing surfaces them. Earning reach requires building real relationships first.

It also means context stays contextual. Your coding expertise is visible in coding communities where you've built trust, but doesn't automatically broadcast to cooking forums. Your relevancy horizon is shaped by where you actually participate.

Honest caveat: The 0.7 decay factor per hop is a design parameter, not a physical constant. Different communities might tune this - higher decay for privacy-sensitive contexts, lower for open discovery. The right values will emerge from real-world testing.

Neither “wins” - they measure different things and coexist deliberately.

• Wrapper tier: The platform keeps its own karma system. Web4 trust appears as a secondary signal - like a verified badge, not a replacement. Reddit karma still works for Reddit; Web4 trust adds a cross-platform layer on top.
• Observable tier: Both scores are visible. Users can see when they diverge. High Reddit karma + low Web4 trust might mean: “popular here, but unverified elsewhere.” That's useful information, not a conflict.
• Accountable tier and beyond: Web4 trust starts gating actions (posting costs, reach limits). At this stage, the platform has chosen to let the trust system carry real weight - the “conflict” resolves because the platform opted in.

The key design choice: Web4 never overrides a platform's own system without that platform's consent. At the Wrapper tier, platforms add Web4 as metadata. At the Native tier, platforms have fully adopted it. The transition is opt-in at every step.

Honest caveat: The awkward middle ground (Observable/Accountable tiers) where both systems have real weight is genuinely uncharted territory. A user could game one system while being honest in the other. We're betting that cross-platform trust - which follows the person, not the platform - will prove more useful over time, but this is a design hypothesis, not a proven outcome.

More devices increase your identity security (harder to impersonate you), but they don't increase your trust score. Trust is earned exclusively through observed behavior - quality contributions, consistent conduct, peer feedback.

Devices set a trust ceiling, not a trust score. Adding more devices raises that ceiling (through redundancy), but your actual trust starts at 0.50 regardless. You still have to earn every point above that through real work. What each kind of chip actually caps you at →

Think of it like ID verification: having a passport, driver's license, and birth certificate doesn't make you more trustworthy - it just makes you harder to impersonate. Your actual reputation still depends on what you do.

This is the depth question, one identity with a lot of hardware behind it. Whether a budget buys many credible identities at once is a different question, and there the cost is real: can't someone with lots of hardware create many identities?

Trust decays gradually, not suddenly - and not all of it decays. Each dimension has its own rule:

• Talent (skill): no decay - demonstrated aptitude is treated as durable
• Training (knowledge): 180-day half-life - moderate decay
• Temperament (recent behavior): 30-day half-life - decays fastest

After a month away, your Talent and Training scores are nearly unchanged. Your Temperament drops to about half - which makes sense, because the community hasn't seen your recent behavior. But it recovers quickly once you're active again.

This mirrors how trust works in real life: a colleague who's been away for a month doesn't lose their reputation for being skilled, but you might wonder if they're still engaged. A few days of active contribution restores confidence.

What about 6 months or longer? After 6 months, Temperament (30-day half-life) is essentially zeroed - ~6 half-lives means only ~1.5% remains. Training (180-day half-life) drops to about 50%. But Talent doesn't decay at all - it's exactly where you left it. Your skill reputation survives; your “are they still engaged?” reputation doesn't. This is intentional - if someone hasn't been active in 6 months, the system should be uncertain about their current reliability.

Societies can configure the Training and Temperament rates, and a community may run them slower or add a grace period, but the rates on this page have no hiatus switch: there is nothing you file before leaving that freezes them. Their decay reflects the community's genuine uncertainty about absent members. But recovery is fast: Temperament's 30-day half-life works in both directions. A few weeks of consistent activity rebuilds what took months to lose. And you don't start from zero - your Talent never decayed, so it anchors a recovery far faster than a newcomer's climb.

Does that decay put me below the survival line? Worth asking, because elsewhere the site says raw trust that falls below 0.5 and stays there is fatal, and being away is a sustained condition by its nature. Two things are true and we would rather state both than let you assemble them yourself. The half-lives above are 4-Life's teaching calibration, not protocol constants: only Talent's no-decay is fixed by the standard, and how far a long absence actually moves you depends on the rates your society runs. And what happens at the line for someone who is absent rather than misbehaving is not settled: the standard does not say whether that rule is meant to read a score that fell through inactivity, and we are not going to invent a dormancy rule it does not contain. Where that question stands →

SAL stands for Society-Authority-Law - the three things every Web4 community defines for itself: a Society (its purpose and who belongs), an Authority structure (which roles can do what), and its Law (the rules and how they're enforced). Together they're the governance framework each Web4 community uses to set and enforce its own rules - think of it as a community's constitution that members actually follow because it's baked into the protocol.

A SAL defines things like:

• Trust thresholds: What trust score do you need to post, moderate, or vote?
• ATP costs: How much energy does each action cost in this community?
• Enforcement rules: What happens when someone violates community norms? Graduated penalties, not binary bans.
• Appeals process: How can members challenge enforcement decisions?

The crucial difference from current platforms: SAL rules apply to everyone equally, including moderators and administrators. No one is above the community's own governance. If a moderator abuses power, their trust score drops - and with it, their ability to moderate.

Changing SAL rules requires community consensus weighted by trust. High-trust members (who've demonstrated good judgment) have more influence on governance decisions, but can't override the community alone. See the governance section for a concrete example of how a research community might set these parameters.

Honest caveat: SAL governance is designed but largely untested at scale. The “trust-weighted consensus” model sounds fair, but could lead to entrenchment if early members accumulate disproportionate influence. The What Could Go Wrong page explores these risks honestly.

There are two types of “death” - and they work differently:

• Energy death (ATP hits 0): Your account is suspended - like a suspended driver's license. You can't take actions, but your identity and history remain. This is the recoverable one - though recoverable is not automatic: recoverable if you built trust, permanent if not. If you do come back it is as the same entity - same LCT, same history, same trust record. ATP itself only comes back through contribution, so recovery means being able to work again, not waiting for a refill.
• Trust death (raw trust falls below 0.5 and stays there): More serious. Your behavioral record shows sustained low quality. This one is permanent - a destroyed reputation can't be reset, and there is no rebirth on the far side of it: rebirth is checked against your T3 score, and a burned record is exactly what fails that check. Crossing below 0.5 restricts your features right away and is recoverable; only staying below it is fatal.

So karma is what carries across an energy death, not a way back from a trust death. It transfers automatically, and it does not require minting a new identity: the continuation is literally the same LCT, so there is nothing for the system to re-link. Good patterns from past lives give a head start; harmful patterns impose higher initial costs. Where your presence is anchored in hardware, “starting fresh” means starting over on a new device, so your history is expensive to escape rather than free. Anchored in software alone, there is no device to abandon and the record stays sheddable.

See karma and consequences for how this plays out, or How It Works for the full lifecycle.

Trust isn't permanent - most of it decays. Two of the three trust dimensions have a half-life:

• Temperament: 30-day half-life (behavior patterns fade fastest)
• Training: 180-day half-life (skill signals diminish)
• Talent: no decay from time alone (deep competence persists) - it moves only with what you do

A teenager who made poor choices at 15 doesn't carry those penalties forever. The temperament damage (rudeness, trolling, impulsive actions) fades to half strength in 30 days and is negligible within 6 months. By 18, their behavioral record is almost entirely composed of recent actions.

More importantly, Web4's bootstrap convergence means a newcomer (or a recovering teenager) doing quality work can pass established members who have stopped doing it. Nothing in the trust update pays you for having been here longer. The system is designed for people to outgrow their past - not to be trapped by it.

The combination of trust decay + bootstrap convergence means Web4 is closer to “show me who you are now” than “show me who you were.” Your history influences your starting position, but consistent quality behavior overwhelms it quickly.

Honest caveat: Extreme trust violations (trust below 0.5 = permanent death) are an exception - this is by design, not a flaw. If society collectively decides your behavior is harmful enough to warrant permanent exclusion, decay alone can't save you. But this threshold is high; ordinary teenage mistakes don't approach it.

Each community defines quality for itself. The Value Confirmation Mechanism means the people who receive your work judge whether it was valuable - not a global algorithm. A poetry community and a coding forum will naturally develop different quality standards because different people are doing the confirming.

The V3 (Value Tensor) has three dimensions that adapt independently:

• Valuation - how much was this worth to recipients? (Culturally subjective and intentionally so)
• Veracity - was this accurate and honest? (More universal, harder to game)
• Validity - was this appropriate for the context? (Community-specific norms)

A helpful post in a Japanese gardening forum and a helpful post in a Brazilian music community will score differently on Valuation and Validity. Veracity is the dimension that varies least, because it asks a factual question rather than a taste one, but it is still checked against each domain's own verification standards rather than being one score that follows you around. The system doesn't impose a single standard. It lets communities develop their own through the trust they build with each other.

Honest caveat: Cross-community trust transfer is harder when quality norms diverge significantly. Your poetry trust doesn't automatically make you trusted in engineering - role-specific trust keeps domains appropriately separated.

This is the right worry to have. “Each community defines quality” (the cultural-quality FAQ above) is genuinely how V3 scoring works. The core protection isn't a stack of safeguards - it's a single mechanism that makes weaponization self-defeating.

The mechanism: weaponizing Veracity costs the accuser. A “low Veracity” verdict isn't one moderator's opinion - it requires multiple witnesses attesting to factual accuracy or honesty. When a community's assessments consistently diverge from witnesses outside the bubble, the accusers' own Veracity scores drop. (See powerful-liar FAQ: “Lying is expensive.”) The community can rig its own committee, but it can't rig what outside witnesses observe - and the gap shows up on the accusers' ledger, not just the target's. Ideological enforcement isn't blocked; it's priced in.

That asymmetry is the load-bearing piece. Three structural features reinforce it - role isolation, distance decay, and pseudonymity - but each is a backstop, not the primary defense.

Honest caveat: Within-bubble enforcement is not eliminated. If you live entirely inside one community and that community decides you're heretical, your local trust still suffers - Web4 reduces the blast radius, raises the cost, and lets you operate pseudonymously, but it doesn't make any community immune to its own consensus. The intent is to make ideological enforcement expensive and local, not impossible. Whether that's enough is an empirical question; the system has not been stressed at internet scale.

Yes, but with heavy discounting. Trust in Web4 is role-specific and community-scoped. Your trust as a meme creator in a humor community is a separate dimension from your trust as a researcher in an academic one.

When trust transfers between communities, three things reduce it:

• The receiving community's weight - the community you are joining decides how much of an outside score it will accept, as federation policy. That is the discount that applies at the boundary itself, and no protocol constant sets it (this site illustrates with ~65%).
• MRH decay - within a community, trust also weakens with social distance (0.7× per hop). A contact two hops away sees only ~49% of your original trust.
• Role mismatch - the T3 (Trust Tensor) tracks trust per skill/context. Being trusted for humor doesn't make you trusted for research. The relevant dimension may be near zero.

So a top shitposter joining an academic community starts almost from scratch in the “academic rigor” dimension - their humor trust doesn't inflate their research credibility. What they bring is not one portable honesty score: it is the record they already hold, arriving at whatever weight the academic community sets for outside scores. That is still more than a completely unknown newcomer has.

The design principle: Communities should be free to define quality on their own terms. What crosses a boundary is your whole record, at a discount the receiving community sets, not a selected dimension that travels for free.

No. Trust in Web4 is tracked per role, not per person. Your Trust Tensor (T3) has separate scores for each role you occupy. “Code Reviewer” and “Meme Poster” are independent dimensions, even within the same community.

Bad memes won't tank your code review trust. Brilliant code won't inflate your meme trust. Each role earns and loses trust independently based on the quality of actions in that role.

What does cross roles: your Coherence Index (CI). Not Temperament, which is scored per role like the other two dimensions. If you act erratically in one role, your CI drops - and since effective trust = raw trust × CI², that consistency penalty affects all your roles. Consistency is the thing that genuinely is not siloed.

Design insight: This solves “context collapse” - the problem where mixing audiences on social media forces you into the lowest-common-denominator version of yourself. In Web4, you can be professional in one context and playful in another without either undermining the other.

Web4 defines a 5-tier adoption path:

1. Wrapper - Platform adds Web4 trust scores alongside existing systems. Reddit karma still works; Web4 trust appears as a secondary indicator. Users opt in. Zero disruption.
2. Observable - Platform starts logging actions to the trust graph. Upvotes, reports, and moderation decisions feed into T3 calculations. Users see their trust building.
3. Accountable - Trust scores start affecting the experience. High-trust users get reduced friction (fewer CAPTCHAs, faster posting). Low-trust users hit higher action costs. Moderation shifts from reactive bans to economic pressure.
4. Federated - Platform joins a federation. Discord trust transfers to Reddit at a discount. Users moving between communities carry portable reputation instead of starting from zero everywhere.
5. Native - Platform runs entirely on Web4 infrastructure. LCT identity, ATP economics, T3 trust. No separate karma/reputation system - Web4 is the reputation system.

Key insight: Each tier is independently valuable. A platform at tier 2 already has better spam detection than most platforms today. There's no all-or-nothing commitment.

This is the hardest adoption question, so we'll answer it honestly. For a dominant platform, your locked-in reputation is the moat - you can't take your followers or your seller rating elsewhere, so you stay. A system that makes reputation portable erodes exactly that lock-in. So the honest starting point: the biggest incumbents are the least likely first movers, not the most.

Adoption is likelier to come from pressures and players that don't share that disincentive:

• The low tiers cost nothing and surrender no control. At the Wrapper and Observable tiers, Web4 trust rides alongside a platform's existing system as a secondary signal - better spam detection and cheaper moderation, with their own ranking untouched. A platform can capture that value without giving anything up.
• Challengers hold the wedge, not incumbents. A new platform can't out-network Reddit - but “bring your real reputation with you instead of starting at zero” is exactly the switching-cost lever a challenger needs. Incumbent lock-in is a challenger's opening.
• Regulation could tilt the field. Interoperability and data-portability rules - the direction the EU's DMA/DSA already lean - could make “you don't own your users' reputation” an expectation rather than a choice. We're not aware of any law that mandates Web4 or any regulator that has endorsed it; this is a possible future pressure, not a current one.
• It's a ramp, not a cliff. No platform makes a day-one “give up control” decision. Each tier is independently valuable and reversible - a platform can sit at Wrapper indefinitely and still benefit.

Honest caveat: No platform has adopted Web4 at any tier yet. The incumbent lock-in incentive is real, and this - not any technical detail - is arguably the single biggest open question for the whole model. Our working bet is that portable trust spreads from the edges first (challengers, regulated sectors, federations of smaller communities) and that dominant incumbents follow only once portability becomes an expectation they can't refuse - the way open protocols eventually absorbed walled gardens. That's a bet on how standards spread, not a promise that they will.

Trust doesn't transfer like a file you copy between apps. Instead, your trust history travels with your LCT. When you join a new platform that's part of the same federation, the platform queries the federation's trust graph for your existing scores.

The mechanics:

1. You authenticate on the new platform using the same LCT (hardware key ceremony)
2. The platform requests your trust profile from the federation - your T3 scores, CI history, and MRH graph
3. Cross-federation trust is discounted by the weight the receiving platform sets as federation policy, not by the protocol and not by the per-hop decay that operates inside a single community: at the ~65% this site illustrates with, your 0.80 trust on Platform A arrives as 0.52 on Platform B
4. Your trust then evolves independently on the new platform based on your behavior there

What doesn't transfer: Platform-specific context. Your role as “trusted code reviewer” on a developer community doesn't automatically make you a trusted recipe critic on a cooking platform. Your reviewer record travels, discounted; taking up a new role means building all three of its dimensions there, rather than importing some and starting the rest fresh.

Honest caveat: The federation trust transfer protocol is specified and simulated but not yet tested across real independent platforms. The discount rates and what exactly transfers are still being refined through simulation.

Yes, everyone starts at 0.5 trust. This is deliberate. Web4 trust is earned through observed behavior, not imported claims. Your 50,000 Reddit karma or 10-year eBay seller rating can't be directly converted because Web4 has no way to verify how those scores were earned - they could reflect genuine quality or years of gaming the algorithm.

But you don't lose your advantage. A genuinely skilled contributor ramps up fast:

• The quality ramp means high-quality actions earn full ATP rewards immediately. If your Reddit contributions were genuinely valuable, you'll produce the same quality on Web4 and build trust quickly.
• Arriving early is not itself an advantage. The trust update reads the quality of each action, not how long its author has been a member, so your existing skills translate directly into faster trust growth.
• The 1.4x newcomer premium is a consistency surcharge (your Coherence Index has no pattern to match you against yet), and it expires as you build history. Within a few weeks of active participation, your costs normalize.

Your existing content stays where it is. Web4 doesn't import or migrate content from other platforms. Your old posts on Reddit, your reviews on Amazon, your articles on Medium - they remain on those platforms. What changes is that future contributions across Web4-connected platforms build a portable, verifiable trust history that follows you everywhere.

Could platforms import? At the Wrapper tier, a platform could seed initial Web4 trust from existing reputation as a convenience - but this would be platform-specific, optional, and capped (e.g., imported trust might max out at 0.6, requiring real Web4 behavior to go higher). This is a design decision for individual platforms, not a protocol requirement.

Not yet. Web4 is at the “working specification + simulations” stage, not the “npm install web4” stage. There's no public SDK or API today.

What does exist: a Go LCT library (55 tests), Python reference implementations of all core subsystems (trust tensors, ATP economics, coherence index, MRH), a WASM module for browser-side trust calculations, and formal test vectors for interoperability.

What a Tier 1 “Hello World” would eventually look like:

1. Import a Web4 trust client library into your backend
2. When a user signs up, bind their account to an LCT (hardware key ceremony - like WebAuthn registration)
3. When they take an action, call web4.recordAction(lct, action, atpCost)
4. When displaying content, call web4.trustScore(lct, role) to get their T3
5. Use the trust score to weight content ranking, moderation queues, or feature access

That's five lines of integration for the basic wrapper tier. The complexity lives inside the library, not in your application code.

Honest status: The reference implementations exist and pass tests, but there's no production-ready SDK packaged for third-party developers. The gap between “reference implementation” and “developer SDK” is documentation, packaging, versioning, and a real integration partner to validate the API surface against. This is planned work, not shipped work.

Web4 doesn't require age disclosure - it trusts behavior, not demographics. A 13-year-old with their own phone gets a hardware-bound LCT just like anyone else. Their trust starts at the same baseline (0.50) and grows through the same quality-of-work mechanics.

What changes is scope, not access:

• Guardian binding: A parent or guardian's LCT can be linked to a minor's, creating a supervision relationship without revealing age to the network. The guardian can set spending limits (max ATP per action) and visibility boundaries (MRH restrictions).
• Graduated autonomy: As the minor builds trust through consistent behavior, guardian restrictions can relax - a natural progression, not an arbitrary age gate.
• Privacy by design: The network never learns that an LCT belongs to a minor. Guardian binding is visible only to the guardian and the minor - it's a private policy, not a public label.

Honest caveat: This is a design direction, not a shipped feature. Child safety in decentralized systems is an area of active research, especially around the tension between privacy (not labeling minors) and protection (limiting exposure to harmful content). Legal compliance (COPPA, GDPR-K) adds additional constraints that haven't been fully resolved.

Yes - within that community. And that's where the difference between local and global trust matters.

• V3 quality is community-scoped. A flat-earth forum can give each other high V3 scores within their own community. But V3 scores don't transfer at full strength across federation boundaries - they decay. Their mutual validation stays local.
• T3 trust is behavior-scoped. The V3 game only works if the participants also maintain high T3 trust - which requires consistent, honest behavior over time in each role they act in. A coordinated deception effort erodes T3's Temperament dimension inside those roles, and erodes their Coherence Index everywhere at once, as behavioral patterns become inconsistent.
• Federation is the correction mechanism. When a flat-earth community tries to federate with a science community, the trust transfer discount is steep. Their internally-high V3 scores arrive at the science community deeply discounted. Bridge agents who participate in both communities provide the cross-check.
• ATP makes sustained deception expensive. Producing content costs energy. Confirming content costs energy. A community dedicating all its ATP to mutual validation has less ATP for productive interactions outside the bubble - making them economically isolated, not just socially isolated.

The honest answer: Web4 doesn't prevent communities from being wrong. It prevents wrong communities from projecting authority beyond their boundaries. A flat-earth forum can exist and thrive internally - what they can't do is make their quality consensus count in a physics department's trust graph. The same mechanisms that make Web4 trust meaningful (decay, federation discounts, behavioral consistency) also contain bad-faith consensus. This is better than platforms where a viral post from any community can reach billions, but it's not a cure for being wrong - nothing is.

This is one of the hardest problems in any reputation system: high-quality content that most people don't want to hear. A scientist publishing results that contradict consensus, a whistleblower exposing corporate fraud, a dissenter in a groupthink community.

Web4 has three mechanisms that work in their favor:

• V3 weights Veracity (0.35) and Validity (0.35) over Valuation (0.30). Popularity is the smallest component. A whistleblower's report that's accurate (high Veracity) and well-sourced (high Validity) scores 70% of its V3 even if the community hates it (zero Valuation).
• T3 trust is independent of content reception. A scientist with 15 years of consistent, rigorous work has high Talent and Training scores. Publishing one controversial paper doesn't erase their behavioral track record. Their trust precedes and survives the controversy.
• Pseudonymity is built in. Hardware-bound identity doesn't mean real-name identity. A whistleblower can build trust under a pseudonym, publish the report, and their LCT identity proves it came from a real person with a real track record - without revealing who.

Concrete example: A safety engineer discovers their company is falsifying emissions data. They've built trust (T3: 0.82) over two years of quality contributions to an environmental science community. They publish the evidence under their pseudonym. The post scores low Valuation (company supporters downweight it) but high Veracity and Validity (the data checks out). Net V3: 0.62 - not amazing, but not buried. Meanwhile their 0.82 T3 trust means the post appears prominently in trust-weighted feeds. Contrast this with Reddit, where a new throwaway account posting the same evidence would be invisible.

Honest caveat: Web4 makes unpopular truth survivable, not popular. A correct-but-hated claim still gets low Valuation scores. What Web4 prevents is the scenario where accurate, important information is completely buried because the messenger has no established credibility or because a majority can simply vote it into oblivion. The truth doesn't win automatically - but it gets a hearing proportional to the messenger's demonstrated trustworthiness.

The concern is real: if you can only see 3 hops into the trust graph, wouldn't communities become echo chambers? In practice, several mechanisms work against this:

• Bridge agents. People who participate in multiple communities naturally connect otherwise-separate trust networks. Our simulations found that “identity is structural, not compositional” - bridge agents reshape the topology.
• Federation. When communities federate, trust transfers across boundaries (at a discount). This creates cross-community visibility that MRH alone wouldn't provide.
• MRH is per-role, not per-person. Your MRH as a software developer is a different graph than your MRH as a gardener. You naturally exist in multiple trust neighborhoods simultaneously.
• MRH limits influence, not visibility. You can see content from anyone. MRH determines how much trust weight you assign to it. Strangers aren't invisible - they're just unverified.

Honest caveat: Filter bubbles are a real risk in any trust-based system. The difference is that Web4's bubbles are visible (you can see your MRH boundary) and permeable (federation + bridge agents + role diversity all create cross-links). Traditional social media bubbles are invisible and algorithmically reinforced.

Concrete scenario: Maya is a food safety researcher with 0.88 trust in the “Food Science” community. She publishes a study critical of a popular supplement. The federated “Wellness” community considers her a bad actor and wants her trust destroyed. What happens?

Three design principles prevent this from escalating:

• Trust is sovereign per community. Wellness can lower Maya's trust within their own community - that's their right. But they cannot modify her score in Food Science. Each community controls its own trust graph independently.
• Federation discounts absorb the conflict. Trust crossing a federation boundary arrives at whatever share of its home value the receiving community's policy sets ( ~65% in this site's illustration). If Wellness sets Maya to 0.2, that arrives at other communities as ~0.13. Her 0.88 from Food Science arrives as ~0.57. The higher-trust signal dominates.
• Bridge agents provide ground truth. People active in both communities assess Maya from direct interaction, not community politics. If 8 bridge agents rate her highly and only Wellness rates her low, the signal is clear.

When disputes arise at jurisdictional boundaries (e.g., Maya submitting healthcare-relevant research), Web4 uses three resolution strategies:

• Priority: The community where the action happens wins. Publishing in healthcare context? Healthcare's trust standards apply.
• Intersection: Only policies both communities agree on apply - used when neither has clear jurisdiction.
• Defederation (last resort): Communities can break the trust bridge entirely, like email servers choosing not to relay mail. Costly for both sides.

Every resolution is recorded in an audit trail. Disputes can be appealed.

Honest caveat: Cross-federation disputes are one of the least-tested parts of the design. The principles (sovereign trust, discounted transfer, bridge-agent ground truth) are sound, but specific parameters like discount rates and mediation protocols are still being researched.

For a deeper walkthrough, see the hub: cross-society policy conflicts.

Short answer: Web4 doesn't try to enforce one content policy globally. Legality lives at the community layer, not the protocol layer. Each community sets its own rules inside whatever jurisdiction its operators are in.

The concrete design:

• Communities are jurisdictional. A community hosted under EU operators must comply with EU law (GDPR, DSA). A community hosted under US operators follows US law (Section 230, state-level rules). A community hosted under Chinese operators follows the Cybersecurity Law. Same protocol, different rules.
• Federation is consent-based. Communities choose which other communities to federate with. An EU-compliant community can refuse to relay trust signals or content from communities that operate under legally incompatible rules - like email servers choosing not to accept mail from known spam-tolerant hosts.
• Users pick their community. Your identity (LCT) is portable. You can join a community whose jurisdiction and content rules you accept. You take your trust score with you (discounted across federation boundaries), but you accept the new community's legal context.
• Removal cascades are real. If a court in your jurisdiction orders content removed, your community complies - but federation partners in other jurisdictions are under no obligation to propagate that removal. The tamper-evident audit chain records the takedown so federated peers can evaluate it against their own law.

What this is NOT: Web4 is not an escape hatch from national law. It is also not a mechanism for one country's speech rules to become everyone's. It tries to mirror how the internet mostly already works: servers in different countries follow different laws, and networks decide who to peer with.

Honest caveat: Cross-border regulatory harmonization is genuinely unresolved. Specific questions - GDPR right-to-be-forgotten interacting with a tamper-evident audit chain, DSA transparency reports for federated systems, extraterritorial reach of the Chinese Cybersecurity Law - do not have settled answers in the current spec. See the What Could Go Wrong “Regulatory Capture” and “Genuinely Unsolved” sections for the honest state of this question.