# IOTA Web Guardian — Strategy & Roadmap 2026
- **Document version:** 1.0
- **Date:** 2026-04-28
- **Authors:** Niccolò, Paolo
- **Audience:** IOTA Foundation team, mentors, investor advisors
```{=openxml}
```
## 1. Executive Summary
After feedback from the IOTA Foundation call, the direction for IOTA Web Guardian from now to December 2026 is clear:
- **No new features.** From April to December we polish, harden, and validate what we already have. The product as it stands today is considered ready in scope; what is missing is robustness, Web2 accessibility, and proof in the wild.
- **Bridge to Web2.** The system must become usable by publishers who do not understand Web3. Wallets, DIDs, and on-chain payments must disappear behind a "60-second onboarding" experience.
- **Detection-first hardening.** The economic model only works if the system reliably distinguishes AI scrapers from human browsers. This is the foundation everything else stands on.
- **Distribution and proof.** By December we want measured numbers from real publishers, not slides.
This document defines our medium-to-long term goals and roadmap from May to December 2026, organized in quarterly OKRs and four parallel tracks.
```{=openxml}
```
## 2. Strategic Tracks (April – December 2026)
The work is organized in four parallel tracks. Each runs across all quarters with different emphasis.
| Track | Focus | Owner (proposed) |
|---|---|---|
| **A. Hardening & Measurement** | Performance, security, observability of the existing system | Niccolò (lead) |
| **B. Detection Robustness** | Distinguishing AI scrapers from human browsers — anti-bypass | Niccolò + external review |
| **C. Web2 Onboarding** | Making the system usable for non-crypto publishers | Paolo (lead) |
| **D. Distribution & Proof** | Pilot publishers, case studies, marketplace listing | Paolo + both |
```{=openxml}
```
## 3. Q2 2026 (May – June) — Hardening & Measurement
**Theme:** Turn the hackathon prototype into software a publisher can trust in production.
### Objectives
**O1 — Establish a measurement baseline.**
- KR1: Public benchmark page with p50/p95/p99 latency for cold fetch, JWT cached path, payment settlement, measured on IOTA Rebased testnet.
- KR2: Methodology document published (reproducible tests, hardware, network conditions).
- KR3: Replace all "~2.8s / ~77ms" placeholder numbers in the deck and README with measured values.
**O2 — Security baseline.**
- KR1: Internal security review of the WordPress plugin (43% of the web is the attack surface; this must be solid).
- KR2: Threat model document covering the four main attack vectors (scraper masquerading as browser, false positive on humans, VP replay/forging, Sybil attack on DIDs).
- KR3: Stress test report — req/s ceiling on the certifier, behavior under IOTA L1 latency spikes, documented failure modes.
**O3 — Observability.**
- KR1: Opt-in telemetry deployed: number of installs, scrapers blocked, revenue captured, false-positive reports.
- KR2: Structured logging on every block/allow decision with reason code.
**Berlin event preparation (June)**
- Demo deck refreshed with measured numbers.
- One-pager handout with the four-vector threat model and our mitigation posture.
- Live demo on stable testnet endpoint.
```{=openxml}
```
## 4. Q3 2026 (July – September) — Web2 Onboarding & Detection Hardening
**Theme:** A WordPress blogger of 55 must be able to install it and earn first dollars without knowing what a wallet is. In parallel, the detection layer must be hardened against bypass.
### Track C — Web2 Onboarding
**O1 — Custodial mode by default.**
- KR1: Email/Google signup flow; wallet provisioned and held by a partner custodian (not by us — see strategic note in §7).
- KR2: "Export to self-custody" one-click for power users. Default path never shows a seed phrase.
- KR3: DID generation and binding happen behind the scenes; the publisher only ever sees their email and a dashboard.
**O2 — Fiat off-ramp integrated.**
- KR1: Integration with at least one on/off-ramp partner (Transak, Ramp, MoonPay, or local EU SEPA-compatible option).
- KR2: Publisher dashboard shows balance in EUR/USD, not in IOTA tokens.
- KR3: Withdrawal to PayPal / Stripe / SEPA available in <2 clicks.
**O3 — Setup wizard "60-second onboarding".**
- KR1: Plugin install → email confirm → first scraper blocked, all in under 60 seconds, measured on a fresh WordPress.
- KR2: Pricing UI uses human language ("€0.50 per 1000 scraper visits, suggested") with presets for blog/news/docs.
- KR3: Zero blockchain jargon on the first screen; advanced view available on demand.
### Track B — Detection Robustness (parallel)
**O4 — Layered detection model.**
- KR1: TLS fingerprinting (JA4) integrated at the certifier edge. Headless Chromium, curl, Python requests have distinct signatures from real Chrome.
- KR2: Behavioral signals: missing CSS/JS fetch within N ms of HTML, missing internal referrer chain, abnormal request rate per session.
- KR3: Optional progressive challenge (proof-of-work / Turnstile-like) configurable per publisher: off / light / aggressive. Invisible to humans, costly for mass scrapers.
- KR4: Honeypot link mechanism — invisible DOM links that trigger blocklist on follow.
**O5 — Anti-bypass guarantees.**
- KR1: VP bound to request-specific nonce + timestamp + URL hash. No replay possible.
- KR2: JWT bound to IP+UA+DID; on context change, force re-auth.
- KR3: Per-DID rate limiting + per-origin rate limiting (both, not either).
- KR4: Reputation score for DIDs: new DIDs face higher quota / cost; clean history unlocks fast lane.
**O6 — Allowlist legitimate crawlers.**
- KR1: Built-in verified allowlist (Googlebot, Bingbot, Common Crawl, Wayback) via reverse-DNS verification.
- KR2: Publisher UI to extend the allowlist.
**O7 — False positive guardrails.**
- KR1: Default-permissive policy on first hit; classification asynchronous.
- KR2: Always-available "I am human" path (cookie / link) for accessibility cases.
- KR3: Dashboard widget showing "X requests rejected, Y of them likely human" so publishers trust the system.
```{=openxml}
```
## 5. Q4 2026 (October – December) — Distribution, Proof, External Validation
**Theme:** Arrive at the next IOTA milestone with measured numbers from real publishers, not slides.
### Track D — Distribution & Proof
**O1 — 10 real pilot publishers.**
- KR1: 10 sites onboarded (not friends-and-family). Independent tech blogs, small EU/IT independent media, niche docs sites.
- KR2: Each publisher running for ≥30 days with telemetry shared.
- KR3: 3 written case studies with real numbers (revenue captured, scrapers blocked, uptime, conversion friction).
**O2 — WordPress.org marketplace listing.**
- KR1: Submission packaged and submitted in October (review process takes weeks).
- KR2: Plugin listed and downloadable from wordpress.org by end of Q4.
**O3 — Publisher-grade documentation.**
- KR1: Video tutorial (IT + EN), 5–10 min, install to first revenue.
- KR2: FAQ + troubleshooting guide.
- KR3: "Exit story" page — clear explanation of how a publisher leaves the system without lock-in.
**O4 — Demand-side enablement.**
- KR1: Reference SDK or example for legitimate AI agents that *want* to pay (Claude / OpenAI agent calling x402-protected endpoints correctly).
- KR2: Without a credible demand side, the system is just a firewall. With it, it becomes a market.
### Track A — Hardening (continuing)
**O5 — External validation.**
- KR1: Public bug bounty program (modest budget, e.g. $500–$1000 total). Signal more than amount.
- KR2: Light external security audit of the detection flow by a Web AppSec freelancer (1 week scope).
- KR3: Public whitepaper "How we distinguish humans from AI agents" — peer-reviewable, differentiator with technical publishers and IOTA Foundation.
**O6 — End-of-year report.**
- KR1: Public report with aggregate metrics: sites onboarded, scrapers blocked, € redistributed to publishers, latency p50/p95.
- KR2: Material ready for next funding round / IOTA Foundation grant continuation.
```{=openxml}
```
## 6. Detection: The Foundational Question
Everything in this roadmap rests on one capability: **reliably distinguishing a human browser from an AI scraper at request time**. If detection fails, the entire economic model collapses — scrapers bypass the 401 gate and never enter the payment funnel.
### How distinction works in IOTA Web Guardian today
The system is not pure fingerprinting. It is **opt-in via Verifiable Presentation**:
1. Human browser → standard request → 200 OK + content.
2. Compliant AI agent (x402-aware) → receives 401 → presents a Verifiable Presentation signed by its DID → 402 Payment Required → pays on IOTA L1 → receives Guardian JWT → 200 OK.
3. Non-compliant AI scraper → blocked at 401 because it cannot answer the challenge.
The technical question is therefore not "how do I fingerprint a bot" but: **how do we prevent a scraper from masquerading as a human browser and bypassing the 401 entirely?**
### The four attack vectors
**1. Scraper headless masquerading as human browser**
A Puppeteer / Playwright / Selenium with a real Chrome UA, JS enabled, cookies, realistic viewport can look identical to a real Mac user. If it passes the initial filter, it gets 200 OK without paying.
*Mitigations:* TLS JA4 fingerprinting (real Chrome and headless Chromium have distinct TLS signatures), HTTP/2 settings frame fingerprint, header order analysis, behavioral signals (no CSS/JS fetch, no internal referrer), progressive proof-of-work challenge for suspicious cases, honeypot links.
**2. Human browser falsely classified as bot**
Worse than direct attack: if a real visitor is served 401, the publisher loses the visitor and trust in the system collapses.
*Mitigations:* default-permissive on first hit, async classification, accessibility allowlist (screen readers, NoScript users), verified crawler allowlist (Googlebot, Bingbot via reverse DNS), always-available "I am human" path, false-positive telemetry visible to publishers.
**3. Replay / forging of Verifiable Presentations**
An agent pays once, receives JWT, shares with 1000 other agents.
*Mitigations:* VP bound to request-specific nonce + timestamp + URL hash, JWT bound to IP+UA+DID with re-auth on context change, short TTL (1h), nonce rotation, on-chain DID revocation if compromised.
**4. Sybil attack on DIDs**
An attacker generates 100k DIDs at near-zero cost to dodge per-DID rate limiting.
*Mitigations:* combined per-DID and per-origin rate limiting, minimum payment slightly above zero so 100k VPs become uneconomic, reputation score for DIDs (new DIDs throttled, clean history fast-lane).
### Honest framing for the pitch
Perfect anti-bot systems do not exist. Cloudflare, with billions of data points and resources, gets bypassed daily. Our defensible position is not "we are unbeatable" but:
> **"We change the economic incentive: today scraping is free; with us, scraping costs more than paying. We make bypass non-profitable, not impossible."**
This is a more honest and more defensible position. It also protects us from the day someone finds a bypass: it is not game over, it is a parameter to tune.
```{=openxml}
```
## 7. Strategic Decisions Required Before Q3
### Decision 1 — Custodial model
The single most impactful architectural choice of 2026. Two paths:
**A. We custody user funds**
- Pro: full control, simpler integration, better margins.
- Con: we become a fund custodian → KYC / AML / possible PSP license in EU. Massive compliance overhead.
**B. Partner custodies (recommended)**
- Pro: zero regulatory risk for us in 2026; we focus on product.
- Con: less control, dependency on partner pricing and reliability.
**Proposal:** go with B for 2026. Open question to bring to IOTA Foundation: "do you already have integrated custodian / on-ramp partners we can plug into?"
### Decision 2 — Magic.link as a reference, not a competitor
IOTA Foundation suggested we look at Magic.link (magic.link). Our reading:
- They run the **horizontal infrastructure**: 53M+ wallets provisioned, 200K developers, 18K apps integrated, since 2018. SOC 2 Type 2, ISO 27001:2022, GDPR. Wallets in TEE (Trusted Execution Environments), not plaintext databases. Sub-second latency (50–100ms) on wallet creation and signing.
- Their pricing is per **Monthly Active Wallet** (MAW), with unlimited signatures. Free up to 1000 MAW; $99/mo up to 2500.
- They are launching **Newton Protocol**, a policy layer governing AI-agent on-chain actions — adjacent to our problem space but more general.
**What we learn from them:**
1. **MAW pricing pattern** — predictable cost for the publisher, scaling with real business not with scraper volume. Worth considering for our pricing model.
2. **"Sub-second latency" is the right pitch** — confirms our cached JWT path (~50ms) is the message Web2 audiences expect.
3. **TEE is the security baseline** — when we discuss custodial mode in Q3, the industry standard reference is "TEE-based, not plaintext DB". Mentioning it in the deck changes perception.
4. **Email/social/SSO login is now baseline** — never asking for a seed phrase is no longer a feature, it is a hygiene requirement.
5. **Whitelabel UI is expected** — publishers do not want our brand above theirs.
6. **Newton Protocol signals market direction** — "AI agents acting on-chain under policy" is a hot space. Magic does general-purpose; we do a specific vertical (publisher content access via x402+VP). Potentially complementary, not competitive.
7. **Compliance as narrative** — SOC 2, ISO 27001, GDPR are listed on their homepage. For Web2 publishers (especially regulated EU media), this is the shopping list they will eventually require. We do not need them now, but we need a credible compliance roadmap.
**Strategic question to bring to the next IOTA call:** does it make sense for us to be "the verticalized layer" — sitting on top of an infrastructure like Magic, plus our x402+VP+content-gating logic — rather than reinventing the wallet provisioning piece? It would be a 10× faster go-to-market.
### Decision 3 — Niccolò / Paolo split
Suggested division to avoid duplication:
- **Niccolò** — performance, security, infrastructure, detection robustness, threat model, audits.
- **Paolo** — WordPress UX, onboarding wizard, publisher documentation, marketplace listing, distribution, pilot publishers.
Both jointly own: pitch deck, Berlin event, IOTA Foundation relationship, end-of-year report.
```{=openxml}
```
## 8. Key Performance Indicators — End of December 2026
Targets to evaluate the year:
| KPI | Target |
|---|---|
| Real publishers onboarded (paying or non-paying) | ≥ 10 |
| WordPress.org plugin listing | Live |
| Public benchmark with measured p50/p95/p99 | Published |
| Threat model document | Published |
| External security audit (light) | Completed |
| Detection bypass attempts documented and addressed | All known vectors mitigated to "non-economic" |
| Custodial / on-ramp partner integrated | At least 1 |
| Case studies with real numbers | ≥ 3 |
| Public whitepaper on detection methodology | Published |
```{=openxml}
```
## 9. Cross-Cutting Principles
- **No new features rule.** Any incoming feature request goes to a 2027 backlog. To be written into project README and CLAUDE.md as policy.
- **Bug bounty as signal.** Even a small program signals openness to scrutiny — worth more than its dollar amount.
- **Detection as a foundation, not a feature.** Continuous track across all quarters. If detection breaks, everything breaks.
- **Web2 first impression, Web3 underneath.** Publishers should never need to know a DID exists unless they want to.
- **Honesty in numbers.** Replace every placeholder estimate with a measurement. Trust depends on this.
```{=openxml}
```
## 10. Risks and Open Questions
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| A bypass discovered after public launch | High | Medium | Bug bounty, fast patching, layered detection |
| Custodial partner unavailable / too expensive | Medium | High | Evaluate ≥2 partners in Q2; fallback to non-custodial-only mode |
| Legitimate AI agents do not adopt x402 | Medium | High | Demand-side SDK (Q4) + Anthropic / OpenAI outreach |
| WordPress.org rejects plugin submission | Low | Medium | Pre-submission compliance review with WP guidelines |
| Latency regression on IOTA testnet upgrades | Medium | Medium | Continuous benchmarking pipeline |
| Compliance ask from large publisher (SOC 2 etc.) | Medium | Medium | Compliance roadmap published, target SOC 2 in 2027 |
```{=openxml}
```
## 11. Next Steps (Immediate)
1. **Niccolò + Paolo review** of this document (within next 48h).
2. **Send by email** to IOTA Foundation team and supporting advisors with this document attached.
3. **Berlin event prep** (June) starts Q2 work in parallel.
4. **Re-sync after Berlin** to adjust Q3 priorities based on feedback received there.
5. **Monthly progress check-in** with IOTA Foundation (proposed cadence) for the rest of 2026.
*Prepared for internal review by Niccolò and Paolo before sharing with IOTA Foundation team and project advisors.*