Honest Assessment

What Could Go Wrong

Every system has failure modes. Hiding them doesn't make them go away — it just means you discover them at the worst time. Here are the real risks, honest assessments, and what's genuinely unsolved.

This page is for users and builders who want to know what they're getting into. For technical security analysis (attack surfaces, formal threat modeling), see the Threat Model.

What concerns you most? Jump to that risk:

The Big Risks

1.

Nobody adopts it

Adoption & Network Effects

The risk: Web4 only works if enough people and platforms use it. If only 5% of the internet adopts hardware-bound identity, the other 95% is still a spam-filled free-for-all. Attackers just avoid the Web4 part.

Why it's real: Every new protocol faces the chicken-and-egg problem. Email, HTTPS, and IPv6 all took decades to reach critical mass. Many promising protocols (XMPP, WebRTC for social) never did.

What mitigates it: Web4 is designed to provide value even in small communities. A single organization could run a Web4 trust network internally — spam-free collaboration, verifiable contributions, earned reputation. The value starts local and grows outward.

Honest assessment: This is the #1 existential risk. The technology could be perfect and still fail if adoption doesn't reach critical mass. No amount of good engineering solves a coordination problem.

2.

Hardware vendors become the new gatekeepers

Centralization Risk

The risk: Web4 identity requires hardware with security chips (TPM, Secure Enclave). These chips are made by a handful of companies — Intel, Apple, Google, Qualcomm. If identity depends on their hardware, haven't we just replaced platform gatekeepers with hardware gatekeepers?

Why it's real: Hardware supply chains are concentrated. If a manufacturer decides to revoke attestation keys, block certain firmware, or charge licensing fees for security chip access, they could effectively control who gets a Web4 identity.

What mitigates it: Web4 is designed to work with any hardware attestation standard, not just one vendor's. The specification supports multiple attestation methods so no single manufacturer is a chokepoint. Open-source hardware (RISC-V with open security modules) could provide vendor-independent alternatives.

Honest assessment: This is a real concern with partial mitigation. Multi-vendor support helps but doesn't eliminate the risk. The entire smartphone ecosystem runs on a duopoly (Apple/Google) and Web4 inherits that concentration. Even “open” standards can be captured — USB, Bluetooth, and Wi-Fi are all open specifications controlled by industry consortia with corporate membership fees. Web4's attestation layer faces the same dynamic.

3.

The trust threshold punishes the wrong people

Fairness & False Positives

The risk: Web4 uses a 0.5 trust threshold as the minimum bar for continued participation. Fall below it and you're out — your agent “dies” and must be reborn with reduced resources. But what if the scoring is wrong? What if legitimate users get flagged?

Why it's real: Every automated system produces false positives. Credit scores, content moderation, spam filters — they all incorrectly flag legitimate people. A system that can “kill” your digital identity based on behavioral scoring could ruin someone's online life for an algorithmic mistake.

What mitigates it: Trust scores are multi-dimensional (Talent, Training, Temperament) and role-specific, so a bad score in one context doesn't affect others. The coherence index checks behavioral consistency across four dimensions, making false positives less likely than single-score systems. And rebirth means you get another chance — you're not permanently banned, just set back.

Honest assessment: An appeals mechanism has been designed (SAL-level multi-tier process with witness panels, evidence phases, and escalation to federation), but it hasn't been tested with real humans. The simulations assume perfect scoring; reality won't be so clean. See the Aliveness page for how appeals work.

4.

Rich actors game the system anyway

Economic Attack Surface

The risk: ATP transfers cost 5%, so buying reputation at scale is expensive but not impossible. A well-funded organization could buy thousands of hardware devices, create thousands of identities, and slowly build legitimate-looking trust across all of them — a long-game Sybil attack.

Why it's real: Nation-state actors and large corporations routinely invest millions in influence operations. If each fake identity costs $500 in hardware plus months of “reputation farming,” that's still pocket change for a well-funded adversary with strategic goals.

What mitigates it: Coherence scoring detects behavioral patterns that are hard to fake at scale — genuine users develop organic interaction patterns that differ from coordinated bot farms. The economic cost is real: $500K for 1,000 identities, each needing months of activity. It's not impossible, but it's orders of magnitude harder than creating 1,000 email accounts.

The numbers: Web4 simulations show that honest strategies yield ROI of ~0.93 while Sybil strategies yield ~0.90. The margin is small — but it's consistently in favor of honest behavior. More importantly, circular energy transfers (the simplest farming tactic) lose money: 30 circular transfers destroy ~150 ATP (energy budget) through the 5% transfer fee. It's cheaper to just do good work.

Why coordinated attacks fail: Detection probability follows P = 1 − (1−p)N where N = conspirators. With 3 witnesses per interaction (60% base detection), a solo attacker has a 40% chance of going undetected. Two conspirators? Only 16% undetected. Three or more? Under 7%. Meanwhile, the gain per conspirator shrinks as N grows (split the spoils). The math: coalitions become unprofitable at 2–3 members at current stake levels.

Honest assessment: Web4 raises the floor, not the ceiling. Casual abuse becomes uneconomical. Sophisticated, well-funded attacks remain possible. This is a design trade-off, not a flaw — but users should know the limit.

5.

Your hardware breaks and you lose everything

Device Loss & Recovery

The risk: Your identity is bound to physical hardware. Phone stolen? Laptop destroyed in a fire? If you can't prove you're you without the device, you lose your accumulated trust, reputation, and access.

Why it's real: People lose devices constantly. Phones break, get stolen, or fall in water. Hardware security chips can't be cloned (that's the point), so backup is harder than copying a password.

What mitigates it: Web4 supports identity constellations — multiple devices linked to the same identity. Lose one device and your other devices can still attest. Witnesses (trusted contacts who can vouch for you) provide an additional recovery path. The design explicitly plans for device loss.

Honest assessment: Recovery from total device loss (all devices destroyed, no witnesses available) is an unsolved problem. The system makes this scenario unlikely through redundancy, but it can't make it impossible. This is an active area of research. See the LCT Explainer for the full device loss FAQ.

6.

The witness network gets captured or corrupted

Governance & Trust Infrastructure

The risk: Witnesses validate identities and actions. If a majority of witnesses in a community collude or are compromised, they could approve fake identities, deny legitimate ones, or selectively punish users they don't like.

Why it's real: Small networks are vulnerable to capture. A Web4 community with 50 members could be manipulated by 10 colluding witnesses. Governments could compel witness nodes in their jurisdiction to censor identities. Corporate witnesses could prioritize their own interests.

What mitigates it: Federation means no single witness network has monopoly power. Users can participate in multiple communities with independent witness sets. Cross-community trust verification makes it harder to maintain a corrupt local network when external validators can flag inconsistencies.

Game theory check: Web4's adversarial simulations tested four attacker profiles — from low-skill opportunists (200 ATP budget) to nation-state actors (5,000 ATP, 5 coordinated agents). Key finding: when the stake for misbehavior exceeds 2× the expected gain, cooperation becomes the Nash-dominant strategy. At current parameters (200 ATP stakes + 3 witnesses), rational, self-interested actors will cooperate rather than attack. Irrational actors (ideological saboteurs) can still attack but face consistent losses.

Honest assessment: Witness governance is one of the hardest unsolved problems. “Who watches the watchmen?” doesn't have a clean answer. Federation reduces the damage of any single compromised network, but doesn't prevent local corruption. A governance engine now exists in the spec (SAL framework with law oracles, graduated enforcement, and multi-tier appeals), but it operates on a key principle: alignment without compliance is acceptable; compliance without alignment never is. Whether this philosophy holds at scale is untested.

7.

It works in simulations but not at real scale

Scalability & Performance

The risk: The simulations on this site run with 12–50 agents. The real internet has billions of users. Trust-filtered message delivery, coherence scoring across four dimensions, and real-time witness verification all have computational costs that might not scale.

Why it's real: Many systems that work beautifully at small scale collapse under real-world load. Blockchain demonstrated this painfully — Bitcoin processes ~7 transactions per second while Visa handles ~65,000. Web4's per-action trust computation could hit similar walls.

What mitigates it: MRH (context boundaries) limits the trust computation to local neighborhoods — you don't need to verify trust against every user on the internet, just the ones in your current context. This is similar to how DNS scales: local resolution handles most queries without touching root servers.

Honest assessment: Scalability is unproven. The architectural approach (local trust computation within bounded contexts) is sound in theory, but has never been tested at internet scale. The simulations prove the mechanics work, not the engineering.

The Uncomfortable Questions

These aren't failure modes — they're design tensions that don't have clean answers.

If ATP transfers cost 5%, how does collaboration work?+

When two people co-create something valuable, who gets the ATP reward? If Alice and Bob co-author a post, does each get the full reward? Half? Some other split?

Current design: each participant earns ATP based on their individual contribution. But measuring individual contribution in collaborative work is a hard problem that Web4 inherits from every other attribution system (academic citations, open-source credit, etc.).

Status: Partially designed. The specification supports contribution attestation but the details of fair attribution in group work are an open research question.

Doesn't behavioral scoring enable surveillance?+

Web4 tracks actions, measures consistency, and assigns trust scores. That sounds a lot like a social credit system. What stops it from becoming one?

The key difference: Web4 scores are context-bound and decentralized. Your trust in a coding community is separate from your trust in a cooking forum. No single entity sees your complete behavioral profile. MRH (context boundaries) prevents trust information from leaking across contexts without your consent.

But the concern is legitimate. Any behavioral scoring system can be misused. The architecture resists centralized surveillance by design, but a sufficiently powerful actor who compromises multiple contexts could correlate identities across boundaries.

Status: The privacy architecture is designed but the tension between “enough information to compute trust” and “not enough to enable surveillance” is fundamental and unresolved.

Do newcomers always start at a disadvantage?+

You start with 100 ATP and 0.5 trust. Established members have higher trust, more ATP reserves, and richer histories. Does Web4 create an entrenched elite that's impossible for newcomers to challenge?

The design actively prevents entrenchment. Formal bootstrap convergence proofs show:

  • First-mover advantage has a ~30-action half-life — early adopters can't coast. Their head start decays exponentially.
  • After ~50 quality actions, newcomers can surpass founders — stochastic dominance breaks. Quality beats seniority.
  • Trust distribution converges to Gini ~0.25 — moderate inequality (like a healthy economy), not extreme concentration.
  • Catch-up time scales as O(log n) — joining a larger network is logarithmically, not linearly, harder.

Trust dimensions also decay at different rates — Temperament has a 30-day half-life, meaning recent behavior matters far more than historical reputation. Established members who stop contributing lose their advantages measurably fast.

But newcomer friction is real. In every reputation system, being new means being untrusted. The difference: Web4's math shows the path from “new and untrusted” to “established and trusted” is provably finite and fair — unlike today's internet where the path is often “impossible without connections.”

Status: Bootstrap convergence is formally proven with simulation validation. Whether the ~50-action threshold feels fast enough for real humans is a question real-world testing would need to answer.

What happens when hardware standards change?+

TPM 2.0 will eventually become TPM 3.0. Quantum computing may break current cryptographic assumptions. When the underlying hardware standard changes, does everyone's identity need to migrate?

Yes, eventually. The specification is designed to be attestation-method-agnostic — a new hardware standard can be added alongside existing ones. During transitions, both old and new attestation methods would be accepted. Identity migration would use the existing multi-device recovery flow: attest your new device while your old device is still valid.

Status: The architecture supports graceful migration in theory. In practice, coordinating a hardware transition across millions of users while maintaining trust continuity has never been tested.

What do a community's first 100 interactions look like?+

Every Web4 community starts from zero. Here's what the bootstrap actually looks like:

Actions 1–10: Genesis. A founder creates the society with a hardware-bound root LCT. They invite 2–3 trusted contacts who witness each other's presence. Everyone starts at 0.5 trust, 100 ATP. The founder assigns initial roles (treasury, governance, auditing). These first actions are cheap because the society has no history to validate against.

Actions 11–30: Exploration. Members start contributing — posting, reviewing, organizing. Trust scores begin diverging: active contributors climb toward 0.6, while passive members stay at 0.5. ATP flows establish patterns. Quality assessment is rough because there's no baseline yet — the V3 value tensor is calibrating.

Actions 31–50: Differentiation. Roles become meaningful. Members who consistently deliver quality earn trust in specific dimensions — Talent for skilled work, Training for follow-through. First-mover advantage peaks around action 30 and begins decaying. New members who join now can see established trust patterns to learn from.

Actions 51–100: Stabilization. Trust distribution settles toward Gini ~0.25 (moderate, healthy inequality). Quality newcomers start surpassing coasting founders. ATP circulation creates a functioning economy. The society has enough history for MRH context to be meaningful — members can make trust-informed decisions about unfamiliar entities.

Status: This trajectory is validated through simulation. Whether real human communities follow the same curve depends on factors simulations can't model — social dynamics, motivation, and the specific purpose of the community.

What about communities with fundamentally different values?+

Federation handles economic coordination — dynamic pricing, resource allocation, circuit breakers. But what happens when one society considers something ethical that another considers harmful?

Web4's answer is deliberate non-resolution. Unlike platforms that enforce a single content policy, Web4 societies set their own rules. A society that values free expression and one that values content moderation don't need to agree — they just need to decide whether to federate.

Federation is opt-in. Societies choose who to federate with based on shared values, compatible trust thresholds, and historical behavior. No central authority forces incompatible societies together.

MRH creates natural boundaries. Your Markov Relevancy Horizon means you only see entities within your trust graph. A society you don't federate with is invisible to you — not censored, just outside your context.

Cross-society policies handle conflicts. When federated societies have different rules, the society closer to the action (MRH-weighted priority) takes precedence. Circuit breakers automatically isolate partners whose behavior diverges too far.

This doesn't solve the philosophical problem — it sidesteps it. Web4 doesn't claim to know which values are correct. It gives each community sovereignty over its own rules and lets federation economics handle the rest. Communities with compatible values naturally cluster; incompatible ones naturally separate.

Limitation: This approach works when societies can cleanly separate. It struggles with shared-resource conflicts (e.g., environmental policy) where one society's actions affect another's world. Cross-society externalities are an unsolved coordination problem.

What's Genuinely Unsolved

These are open research problems. We're not hiding them — we're working on them.

Witness Bootstrapping

How does the first witness network form? A composite model has been formalized (escrow + sponsor + graduated capabilities create a 3-factor barrier), but no single approach suffices. The trade-off between accessibility and Sybil resistance at genesis is an active research area.

Appeals & Dispute Resolution

When the system scores you unfairly, how do you contest it? A multi-tier appeals mechanism has been designed (file → review → evidence → hearing → verdict), but it hasn't been tested with real humans. The hard question: can the anti-gaming protections prevent people from abusing appeals to escape legitimate consequences?

Governance at Scale

Who decides the rules? A Society-Authority-Law (SAL) framework has been designed with law oracles, graduated enforcement (critical → high → medium severity), emergency bypass with post-hoc audit, and panel-based appeals. The framework distinguishes alignment from compliance — societies can tolerate rule-breaking if the spirit is right. But decentralized governance at internet scale — where communities disagree on fundamental values — remains a challenge no system has fully solved. The simulation engine validates mechanics; human behavior is the unknown.

Real-World Validation

Simulations prove the mechanics work in principle. Whether they work with real humans, real incentives, and real adversaries is an empirical question that requires deployment to answer. A 5-tier incremental adoption pathway (wrapper → observable → accountable → federated → native) has been designed so teams can adopt gradually and validate at each step — but no one has walked the full path yet.

Regulatory Compliance

Laws like the EU AI Act (Articles 9–15) impose requirements on AI systems: risk management, data governance, transparency, human oversight. A compliance mapping exists (7 articles → 16 Web4 requirements) with drift detection and remediation advisors, but regulatory interpretation is ambiguous and evolving. Web4's decentralized model doesn't fit neatly into frameworks designed for centralized AI providers.

Foundation models face additional GPAI obligations (Art. 51–56): model cards, systemic risk classification for models above 1025 FLOP, adversarial testing, and 15-day incident reporting. Web4's T3/V3 + LCT audit trail maps to these requirements, but real regulatory audits haven't been attempted yet.

Why publish your own failure analysis?

Because a project about trust that hides its weaknesses is undermining its own thesis. If trust comes from verifiable honesty, then we should be honest about what we don't know and what could fail.

The Why Web4 page makes the case for this approach. This page makes the case against it. Read both and decide for yourself.

← Why Web4 (The Case For)Technical Threat Model →
Try It Hands-On
All concept-tool bridges →
CollusionAdversarialPlayground
Terms glossary