# IOTA Web Guardian — Strategia e Roadmap 2026
- **Versione documento:** 1.0
- **Data:** 28 aprile 2026
- **Autori:** Niccolò, Paolo
- **Destinatari:** Team IOTA Foundation, mentor, advisor investitori
```{=openxml}
```
## 1. Sintesi Esecutiva
Dopo il feedback ricevuto durante la call con IOTA Foundation, la direzione per IOTA Web Guardian da qui a dicembre 2026 è chiara:
- **Nessuna nuova feature.** Da aprile a dicembre ci concentriamo sul rifinire, irrobustire e validare quello che già abbiamo. Il prodotto come è oggi è considerato completo a livello di scope; quello che manca è robustezza, accessibilità Web2 e prove sul campo.
- **Ponte verso il Web2.** Il sistema deve diventare utilizzabile da publisher che non capiscono il Web3. Wallet, DID e pagamenti on-chain devono sparire dietro un'esperienza di "onboarding in 60 secondi".
- **Detection come priorità.** Il modello economico funziona solo se il sistema distingue in modo affidabile gli AI scraper dai browser umani. Questa è la fondazione su cui poggia tutto il resto.
- **Distribuzione e prove.** Entro dicembre vogliamo numeri misurati su publisher reali, non slide.
Questo documento definisce i nostri obiettivi a medio-lungo termine e la roadmap da maggio a dicembre 2026, organizzati in OKR trimestrali e quattro binari paralleli.
```{=openxml}
```
## 2. Binari Strategici (Aprile – Dicembre 2026)
Il lavoro è organizzato su quattro binari paralleli. Ognuno attraversa tutti i trimestri con enfasi diverse.
| Binario | Focus | Owner (proposto) |
|---|---|---|
| **A. Hardening & Measurement** | Performance, sicurezza, osservabilità del sistema esistente | Niccolò (lead) |
| **B. Detection Robustness** | Distinzione tra AI scraper e browser umani — anti-bypass | Niccolò + review esterna |
| **C. Web2 Onboarding** | Rendere il sistema usabile da publisher non-crypto | Paolo (lead) |
| **D. Distribution & Proof** | Publisher pilota, case study, listing marketplace | Paolo + entrambi |
```{=openxml}
```
## 3. Q2 2026 (Maggio – Giugno) — Hardening & Measurement
**Tema:** Trasformare il prototipo da hackathon in un software di cui un publisher si fida in produzione.
### Obiettivi
**O1 — Stabilire una baseline di misurazione.**
- KR1: Pagina di benchmark pubblica con latenza p50/p95/p99 per cold fetch, JWT cached path, settlement del pagamento, misurati su IOTA Rebased testnet.
- KR2: Documento di metodologia pubblicato (test riproducibili, hardware, condizioni di rete).
- KR3: Sostituire tutti i numeri placeholder ("~2.8s / ~77ms") nel deck e nel README con valori misurati.
**O2 — Baseline di sicurezza.**
- KR1: Security review interna del plugin WordPress (43% del web è la superficie d'attacco; deve essere solida).
- KR2: Documento di threat model che copre i quattro principali vettori d'attacco (scraper che si maschera da browser, falso positivo su utenti umani, replay/forging di VP, attacco Sybil sui DID).
- KR3: Report di stress test — soglia req/s del certifier, comportamento durante latency spike di IOTA L1, failure mode documentati.
**O3 — Osservabilità.**
- KR1: Telemetria opt-in attiva: numero di installazioni, scraper bloccati, ricavi catturati, segnalazioni di falsi positivi.
- KR2: Logging strutturato su ogni decisione block/allow con codice di motivazione.
**Preparazione evento Berlino (giugno)**
- Deck demo aggiornato con numeri misurati.
- One-pager di consegna con il threat model dei quattro vettori e la nostra postura di mitigazione.
- Demo live su endpoint testnet stabile.
```{=openxml}
```
## 4. Q3 2026 (Luglio – Settembre) — Web2 Onboarding & Detection Hardening
**Tema:** Un blogger WordPress di 55 anni deve poter installare il sistema e guadagnare i primi euro senza sapere cos'è un wallet. In parallelo, il livello di detection deve essere irrobustito contro il bypass.
### Binario C — Web2 Onboarding
**O1 — Modalità custodial di default.**
- KR1: Flusso di registrazione email/Google; wallet provisionato e custodito da un partner custodian (non da noi — vedi nota strategica al §7).
- KR2: "Export to self-custody" con un click per power user. Il path di default non mostra mai una seed phrase.
- KR3: Generazione del DID e binding avvengono dietro le quinte; il publisher vede solo la sua email e una dashboard.
**O2 — Off-ramp fiat integrato.**
- KR1: Integrazione con almeno un partner di on/off-ramp (Transak, Ramp, MoonPay, oppure un'opzione locale EU compatibile SEPA).
- KR2: Dashboard del publisher mostra il saldo in EUR/USD, non in token IOTA.
- KR3: Prelievo verso PayPal / Stripe / SEPA in <2 click.
**O3 — Setup wizard "onboarding in 60 secondi".**
- KR1: Installa plugin → conferma email → primo scraper bloccato, tutto in meno di 60 secondi, misurato su un WordPress fresco.
- KR2: UI di pricing in linguaggio umano ("€0,50 per 1000 visite di scraper, suggerito") con preset per blog/news/docs.
- KR3: Zero gergo blockchain nella prima schermata; vista avanzata disponibile su richiesta.
### Binario B — Detection Robustness (in parallelo)
**O4 — Modello di detection a strati.**
- KR1: TLS fingerprinting (JA4) integrato all'edge del certifier. Headless Chromium, curl, Python requests hanno signature distinte da Chrome reale.
- KR2: Behavioral signals: mancanza di fetch CSS/JS entro N ms dall'HTML, mancanza di referrer chain interna, request rate anomalo per sessione.
- KR3: Challenge progressiva opzionale (proof-of-work / Turnstile-like) configurabile per publisher: off / leggera / aggressiva. Invisibile agli umani, costosa per scraping di massa.
- KR4: Meccanismo di honeypot link — link DOM invisibili che scattano una blocklist se seguiti.
**O5 — Garanzie anti-bypass.**
- KR1: VP legata a nonce specifico della richiesta + timestamp + hash dell'URL. Nessun replay possibile.
- KR2: JWT legato a IP+UA+DID; al cambio di contesto, re-auth obbligatoria.
- KR3: Rate limiting per-DID + per-origine (entrambi, non uno o l'altro).
- KR4: Reputation score per DID: DID nuovi hanno quota/costo più alto; storico pulito sblocca fast lane.
**O6 — Allowlist crawler legittimi.**
- KR1: Allowlist verificata integrata (Googlebot, Bingbot, Common Crawl, Wayback) tramite verifica reverse-DNS.
- KR2: UI publisher per estendere l'allowlist.
**O7 — Guardrail sui falsi positivi.**
- KR1: Policy default-permissive sul primo hit; classificazione asincrona.
- KR2: Path "I am human" sempre disponibile (cookie / link) per casi di accessibilità.
- KR3: Widget dashboard che mostra "X richieste rifiutate, Y probabilmente umane" così che i publisher si fidino del sistema.
```{=openxml}
```
## 5. Q4 2026 (Ottobre – Dicembre) — Distribuzione, Prove, Validazione Esterna
**Tema:** Arrivare al prossimo milestone con IOTA con numeri misurati da publisher reali, non con slide.
### Binario D — Distribution & Proof
**O1 — 10 publisher pilota reali.**
- KR1: 10 siti onboarded (non amici e parenti). Blog tech indipendenti, piccoli media indipendenti EU/IT, siti docs di nicchia.
- KR2: Ogni publisher attivo per ≥30 giorni con telemetria condivisa.
- KR3: 3 case study scritti con numeri reali (ricavi catturati, scraper bloccati, uptime, attrito di conversione).
**O2 — Listing marketplace WordPress.org.**
- KR1: Submission preparata e inviata a ottobre (il processo di review richiede settimane).
- KR2: Plugin listato e scaricabile da wordpress.org entro fine Q4.
**O3 — Documentazione publisher-grade.**
- KR1: Video tutorial (IT + EN), 5–10 min, da install a primo ricavo.
- KR2: FAQ + guida troubleshooting.
- KR3: Pagina "exit story" — spiegazione chiara di come un publisher abbandona il sistema senza lock-in.
**O4 — Abilitazione lato domanda.**
- KR1: Reference SDK o esempio per AI agent legittimi che *vogliono* pagare (agente Claude / OpenAI che chiama endpoint x402-protetti correttamente).
- KR2: Senza un lato domanda credibile, il sistema è solo un firewall. Con esso, diventa un mercato.
### Binario A — Hardening (in continuità)
**O5 — Validazione esterna.**
- KR1: Bug bounty pubblico (budget modesto, es. $500–$1000 totali). Il segnale conta più dell'importo.
- KR2: Audit di sicurezza esterno light del flow di detection a opera di un freelance Web AppSec (1 settimana di scope).
- KR3: Whitepaper pubblico "How we distinguish humans from AI agents" — peer-reviewable, fattore differenziante con publisher tecnici e con IOTA Foundation.
**O6 — Report di fine anno.**
- KR1: Report pubblico con metriche aggregate: siti onboarded, scraper bloccati, € redistribuiti ai publisher, latenza p50/p95.
- KR2: Materiale pronto per il prossimo round di funding / continuazione del grant IOTA Foundation.
```{=openxml}
```
## 6. Detection: La Domanda Fondamentale
Tutto in questa roadmap poggia su una capacità: **distinguere in modo affidabile un browser umano da uno scraper AI al momento della richiesta**. Se la detection fallisce, l'intero modello economico crolla — gli scraper aggirano il gate 401 e non entrano mai nel funnel di pagamento.
### Come funziona la distinzione oggi in IOTA Web Guardian
Il sistema non è puro fingerprinting. È **opt-in tramite Verifiable Presentation**:
1. Browser umano → richiesta standard → 200 OK + contenuto.
2. AI agent compliant (x402-aware) → riceve 401 → presenta una Verifiable Presentation firmata dal suo DID → 402 Payment Required → paga su IOTA L1 → riceve Guardian JWT → 200 OK.
3. Scraper AI non-compliant → bloccato a 401 perché non sa rispondere alla challenge.
La domanda tecnica non è quindi "come faccio fingerprint di un bot" ma: **come impediamo a uno scraper di mascherarsi da browser umano e bypassare completamente il 401?**
### I quattro vettori d'attacco
**1. Scraper headless che si maschera da browser umano**
Un Puppeteer / Playwright / Selenium con UA Chrome reale, JS attivo, cookie, viewport realistico può sembrare identico a un Mac di un utente reale. Se passa il filtro iniziale, riceve 200 OK senza pagare.
*Mitigazioni:* TLS JA4 fingerprinting (Chrome reale e Chromium headless hanno signature TLS distinte), HTTP/2 settings frame fingerprint, analisi dell'ordine degli header, behavioral signals (no fetch CSS/JS, no referrer interno), challenge progressiva proof-of-work per casi sospetti, honeypot link.
**2. Browser umano falsamente classificato come bot**
Peggio dell'attacco diretto: se un visitatore reale riceve 401, il publisher perde il visitatore e la fiducia nel sistema crolla.
*Mitigazioni:* default-permissivo sul primo hit, classificazione asincrona, allowlist accessibilità (screen reader, utenti NoScript), allowlist crawler verificati (Googlebot, Bingbot via reverse DNS), path "I am human" sempre disponibile, telemetria di falsi positivi visibile ai publisher.
**3. Replay / forging di Verifiable Presentation**
Un agent paga una volta, riceve JWT, lo condivide con altri 1000 agent.
*Mitigazioni:* VP legata a nonce specifico della richiesta + timestamp + hash dell'URL, JWT legato a IP+UA+DID con re-auth al cambio di contesto, TTL corto (1h), rotazione del nonce, revoca on-chain del DID se compromesso.
**4. Sybil attack sui DID**
Un attacker genera 100k DID a costo quasi-zero per aggirare il rate limiting per-DID.
*Mitigazioni:* rate limiting combinato per-DID e per-origine, pagamento minimo leggermente sopra zero così che 100k VP diventino antieconomici, reputation score per DID (DID nuovi limitati, storico pulito in fast-lane).
### Framing onesto per il pitch
I sistemi anti-bot perfetti non esistono. Cloudflare, con miliardi di dati e risorse, viene aggirato ogni giorno. La nostra posizione difendibile non è "siamo imbattibili" ma:
> **"Cambiamo l'incentivo economico: oggi scrapare è gratis; con noi, scrapare costa più che pagare. Rendiamo il bypass non-redditizio, non impossibile."**
È una posizione più onesta e più difendibile. Ci protegge anche dal giorno in cui qualcuno troverà un bypass: non è game over, è un parametro da tunare.
```{=openxml}
```
## 7. Decisioni Strategiche da Prendere Prima del Q3
### Decisione 1 — Modello custodial
La singola scelta architetturale più impattante del 2026. Due strade:
**A. Custodiamo noi i fondi degli utenti**
- Pro: pieno controllo, integrazione più semplice, margini migliori.
- Contro: diventiamo fund custodian → KYC / AML / possibile licenza PSP in EU. Overhead di compliance enorme.
**B. Custodisce un partner (consigliato)**
- Pro: zero rischio regolatorio per noi nel 2026; ci concentriamo sul prodotto.
- Contro: meno controllo, dipendenza dal pricing e affidabilità del partner.
**Proposta:** scegliamo B per il 2026. Domanda aperta da portare a IOTA Foundation: "avete già partner custodian / on-ramp integrati con cui possiamo connetterci?"
### Decisione 2 — Magic.link come riferimento, non competitor
IOTA Foundation ha suggerito di guardare Magic.link (magic.link). La nostra lettura:
- Loro fanno **infrastruttura orizzontale**: 53M+ wallet provisionati, 200K developer, 18K app integrate, dal 2018. SOC 2 Type 2, ISO 27001:2022, GDPR. Wallet in TEE (Trusted Execution Environments), non database in chiaro. Latenza sub-secondo (50–100ms) su creazione wallet e firma.
- Il loro pricing è per **Monthly Active Wallet (MAW)**, con firme illimitate. Free fino a 1000 MAW; $99/mo fino a 2500.
- Stanno lanciando **Newton Protocol**, un policy layer che governa le azioni on-chain di AI agent — adiacente al nostro spazio ma più generale.
**Cosa impariamo da loro:**
1. **Pattern di pricing MAW** — costo prevedibile per il publisher, scalabile col business reale e non con il volume di scraper. Da considerare per il nostro pricing model.
2. **"Sub-second latency" è il pitch giusto** — conferma che il nostro JWT cached path (~50ms) è il messaggio che il pubblico Web2 si aspetta.
3. **TEE è la baseline di sicurezza** — quando discuteremo modalità custodial in Q3, il riferimento standard è "TEE-based, non DB in chiaro". Citarlo nel deck cambia la percezione.
4. **Login email/social/SSO è ormai baseline** — non chiedere mai una seed phrase non è più una feature, è un requisito di igiene.
5. **Whitelabel UI è atteso** — i publisher non vogliono il nostro brand sopra al loro.
6. **Newton Protocol segnala la direzione del mercato** — "AI agent che agiscono on-chain sotto policy" è uno spazio caldo. Magic fa general purpose; noi facciamo una verticale specifica (accesso a contenuti publisher via x402+VP). Potenzialmente complementari, non competitor.
7. **Compliance come narrativa** — SOC 2, ISO 27001, GDPR sono in homepage da loro. Per publisher Web2 (specie media EU regolamentati), questa è la lista della spesa che ci chiederanno. Non serve averle subito, ma serve una compliance roadmap credibile.
**Domanda strategica da portare alla prossima call IOTA:** ha senso che diventiamo "il livello verticale" — appoggiandoci su un'infrastruttura come Magic, più la nostra logica x402+VP+content-gating sopra — invece di reinventare il pezzo di wallet provisioning? Sarebbe un go-to-market 10× più veloce.
### Decisione 3 — Split Niccolò / Paolo
Divisione suggerita per evitare duplicazioni:
- **Niccolò** — performance, sicurezza, infrastruttura, detection robustness, threat model, audit.
- **Paolo** — UX WordPress, wizard di onboarding, documentazione publisher, marketplace listing, distribuzione, publisher pilota.
In comune: pitch deck, evento Berlino, relazione con IOTA Foundation, report di fine anno.
```{=openxml}
```
## 8. KPI — Fine Dicembre 2026
Target per valutare l'anno:
| KPI | Target |
|---|---|
| Publisher reali onboarded (paganti o non) | ≥ 10 |
| Listing plugin WordPress.org | Live |
| Benchmark pubblico con p50/p95/p99 misurati | Pubblicato |
| Documento di threat model | Pubblicato |
| Audit di sicurezza esterno (light) | Completato |
| Tentativi di bypass detection documentati e affrontati | Tutti i vettori noti mitigati a "non-economici" |
| Partner custodian / on-ramp integrato | Almeno 1 |
| Case study con numeri reali | ≥ 3 |
| Whitepaper pubblico sulla metodologia di detection | Pubblicato |
```{=openxml}
```
## 9. Principi Trasversali
- **Regola "no new features".** Ogni richiesta di feature in arrivo va in un backlog 2027. Da scrivere come policy nel README del progetto e in CLAUDE.md.
- **Bug bounty come segnale.** Anche un programma piccolo segnala apertura allo scrutinio — vale più del suo importo in dollari.
- **Detection come fondazione, non feature.** Binario continuo attraverso tutti i trimestri. Se la detection si rompe, tutto si rompe.
- **Web2 in prima impressione, Web3 sotto il cofano.** I publisher non dovrebbero mai aver bisogno di sapere che esiste un DID, a meno che lo vogliano.
- **Onestà nei numeri.** Sostituire ogni stima placeholder con una misurazione. La fiducia dipende da questo.
```{=openxml}
```
## 10. Rischi e Domande Aperte
| Rischio | Probabilità | Impatto | Mitigazione |
|---|---|---|---|
| Bypass scoperto dopo lancio pubblico | Alta | Medio | Bug bounty, patching rapido, detection a strati |
| Partner custodian non disponibile / troppo costoso | Media | Alta | Valutare ≥2 partner in Q2; fallback a sola modalità non-custodial |
| AI agent legittimi non adottano x402 | Media | Alta | SDK lato domanda (Q4) + outreach Anthropic / OpenAI |
| WordPress.org rifiuta la submission del plugin | Bassa | Medio | Review di compliance pre-submission con linee guida WP |
| Regressione di latenza su upgrade IOTA testnet | Media | Medio | Pipeline di benchmark continuo |
| Richiesta di compliance da grande publisher (SOC 2 ecc.) | Media | Medio | Compliance roadmap pubblicata, target SOC 2 nel 2027 |
```{=openxml}
```
## 11. Prossimi Passi (Immediati)
1. **Review Niccolò + Paolo** di questo documento (entro le prossime 48h).
2. **Invio via email** al team IOTA Foundation e agli advisor di supporto, con questo documento allegato.
3. **Preparazione evento Berlino** (giugno) parte in parallelo al lavoro Q2.
4. **Re-sync dopo Berlino** per aggiustare le priorità Q3 in base al feedback ricevuto lì.
5. **Check-in mensile di avanzamento** con IOTA Foundation (cadenza proposta) per il resto del 2026.
*Preparato per review interna di Niccolò e Paolo prima della condivisione con il team IOTA Foundation e gli advisor di progetto.*