Le fasce di ricompensa qui sotto sono preliminari e saranno sostituite dai valori definitivi quando il programma sarà lanciato insieme al primo rilascio sottoposto ad audit. Il perimetro, il modello di gravità e le regole di invio non sono preliminari: sono le regole da seguire oggi.
Perimetro
In perimetro
Tutto ciò che un attore malintenzionato potrebbe usare per rubare fondi degli utenti, sospendere il protocollo, corrompere lo stato definitivo o violare le proprietà da cui dipende l’architettura — esecuzione riproducibile, prezzi certificati nel blocco che li consuma, rischio che gira atomicamente con il matching o cambiamenti di stato riconducibili alla transazione che li ha causati — è in perimetro per impostazione predefinita. In concreto:- IntentionKernel — semantica di esecuzione, insieme di istruzioni a mondo chiuso, disciplina di sequenziamento, determinismo a livello di byte. Qualsiasi cosa che permetta all’esecuzione di un validatore di divergere da quella di un altro, o a una transazione di produrre un effetto non previsto dalla specifica del protocollo.
- IntentionBFT — safety e liveness del consenso, elezione del leader, impegni sul sequenziamento canonico, aggregazione delle firme e il percorso di migrazione post-quantistica.
- Oracolo e quorum sui prezzi — invio delle osservazioni, scarto degli outlier basato sulla MAD, l’involucro del prezzo certificato, e qualsiasi percorso che permetta a una transazione di leggere un prezzo non consolidato nello stesso evento di consenso.
- Bridge cross-chain — il flusso di deposito e prelievo attestato dai validatori, i contratti on-chain del bridge sulle catene di destinazione supportate, il processo di firma a soglia e di gestione delle chiavi, e i controlli operativi che li circondano.
- Motore di negoziazione — matching, calcolo del prezzo mark, cascate di liquidazioni, fondo assicurativo, ADL, regolamento del funding e la pipeline di rischio nativa del protocollo.
- Interfacce API pubbliche — endpoint REST e WebSocket, autenticazione, firma, rate limit e qualsiasi percorso di codice raggiungibile da internet.
- Software del validatore — il binario del nodo, la gestione delle chiavi, il trasporto peer-to-peer e qualsiasi strumento operativo che un validatore esegue in produzione.
Fuori perimetro
Le categorie seguenti sono escluse esplicitamente dal programma di bounty. Le segnalazioni contro questi bersagli riceveranno riscontro ma non danno diritto a una ricompensa.- Attacchi denial-of-service volumetrici contro l’infrastruttura dei validatori o gli endpoint RPC pubblici. La difesa da questi sta nella mitigazione operativa al bordo della rete, non nelle patch al protocollo.
- Problemi in software, dipendenze o servizi di terze parti che Intention non controlla.
- Segnalazioni che dipendono dall’accesso fisico all’hardware dei validatori, dall’ingegneria sociale contro dipendenti di Intention Labs o da attacchi alla catena di fornitura degli strumenti che il team usa internamente.
- Self-XSS, content spoofing senza impatto di sicurezza, header di sicurezza mancanti e altri problemi a basso impatto contro il sito di marketing o questo sito di documentazione.
- Bug in software formalmente dismesso e non più in esecuzione su alcun validatore né in alcun servizio di produzione.
- Attacchi teorici che richiedono precondizioni improbabili (per esempio la compromissione del 51% dello stake onesto) senza un percorso concreto per innescarle.
Classificazione di gravità
Le segnalazioni sono valutate su una scala a quattro livelli. Il livello è determinato dalla combinazione di impatto (che cosa può ottenere un attaccante) e probabilità (quanto è realistico lo scenario d’attacco, incluse precondizioni e risorse necessarie). Il valore a rischio è il fattore d’impatto dominante per ogni segnalazione che tocca fondi degli utenti.
La gravità è decisa dal team di sicurezza di Intention insieme a chi ha segnalato. Il team motiverà per iscritto il livello assegnato a ogni segnalazione, e chi segnala può contestarlo portando nuove prove.
Fasce di ricompensa
Tutte le ricompense del programma sono pagate in USDC su un indirizzo di wallet indicato da chi segnala. Non è coinvolto alcun token nativo.
Le fasce sono segnaposto finché il programma non apre. La matrice definitiva sarà pubblicata in questa pagina quando uscirà il primo rilascio sottoposto ad audit.
Alcune regole valgono per ogni pagamento:
- Un bounty per ogni vulnerabilità distinta. Se la stessa causa radice produce più segnalazioni, il team le accorpa in un unico riconoscimento alla gravità più alta applicabile.
- Vince chi segnala per primo. Le segnalazioni duplicate di un problema già in triage ricevono riscontro ma non ricompensa.
- Nessuna ricompensa per problemi già noti. Le segnalazioni che coincidono con voci già presenti nel backlog interno del team di sicurezza, o già coperte da un audit pubblicato, non danno diritto a ricompensa. Quando succede, il team condivide il riferimento pertinente.
- La ricompensa dipende dalla collaborazione. La divulgazione pubblica prima della correzione, un exploit che vada oltre un proof of concept minimo, o qualsiasi danno agli utenti fanno decadere la ricompensa.
Regole di ingaggio
I ricercatori che partecipano al programma accettano i vincoli seguenti. Esistono per proteggere gli utenti, per proteggere gli altri ricercatori e per mantenere il programma sostenibile per Intention.- Niente test in produzione con fondi reali degli utenti. Usa la testnet pubblica (quando sarà attiva) o un fork privato. Se una segnalazione è riproducibile solo in produzione, contatta prima
contact@intention.xyze non eseguire il proof of concept finché il team di sicurezza non ha dato riscontro alla richiesta. - Niente ingegneria sociale. Non prendere di mira dipendenti, collaboratori, validatori o partner di Intention Labs con phishing, pretexting o altri attacchi sociali.
- Niente attacchi volumetrici. Nessun denial-of-service per saturazione del traffico, nessun attacco di esaurimento delle risorse contro infrastrutture condivise.
- Solo un proof of concept minimo. Dimostra l’impatto con l’azione più piccola possibile. Non esfiltrare dati degli utenti, non spostare fondi oltre l’importo necessario a provare il problema, e non mantenere accesso al sistema dopo aver completato il proof of concept.
- Niente divulgazione pubblica prima della correzione. La divulgazione coordinata è la regola di base. Una volta distribuita la correzione, il team di sicurezza concorderà con te i tempi della divulgazione pubblica.
- Rispetta la legge applicabile. Le clausole di safe harbor qui sotto valgono per la ricerca condotta in buona fede secondo queste regole. Le attività che violano le norme sui reati informatici in una qualsiasi giurisdizione rilevante non sono protette.
Come inviare una segnalazione
1
Prepara la segnalazione
Una segnalazione completa contiene: una descrizione scritta e chiara della vulnerabilità, il componente e la versione interessati, la riproduzione passo per passo, un proof of concept minimo (codice o hash di transazione), l’impatto che ritieni abbia il problema, ed eventuali proposte di correzione. Più la segnalazione è chiara, più veloce è il triage.
2
Invia a contact@intention.xyz
Manda la segnalazione via email a
contact@intention.xyz con Security nell’oggetto. Una chiave PGP per gli invii cifrati sarà pubblicata al lancio del programma; fino ad allora manda la prima email in chiaro e il team sposterà i dettagli sensibili su un canale cifrato al primo scambio. Non pubblicare alcuna parte della segnalazione prima che il team abbia dato riscontro.3
Ricevi un riscontro entro 48 ore
Il team di sicurezza dà riscontro a ogni invio entro due giorni lavorativi. Il riscontro conferma la ricezione, chiede le informazioni eventualmente mancanti e assegna un responsabile del triage. Se dopo 72 ore non hai ricevuto riscontro, invia di nuovo.
4
Triage e correzione
Le segnalazioni convalidate passano alla correzione. Il team di sicurezza lavora con i responsabili tecnici competenti per rilasciare una correzione, e aggiorna chi ha segnalato con cadenza regolare. Il team può chiedere chiarimenti o ulteriori passi di riproduzione; le risposte arrivano di norma entro un giorno lavorativo.
5
Ricompensa e divulgazione
Una volta distribuita la correzione e reso il problema non più sfruttabile, la ricompensa viene pagata in USDC all’indirizzo fornito da chi ha segnalato. Chi ha segnalato viene citato nel post-mortem e in ogni divulgazione successiva, previa sua autorizzazione. I post-mortem completi vengono pubblicati quando farlo non espone gli utenti a un rischio residuo.
Safe harbor
La ricerca di sicurezza condotta in buona fede nel rispetto delle regole qui sopra non sarà perseguita legalmente da Intention Labs. L’impegno di safe harbor copre i ricercatori che:- Restano dentro il perimetro e le regole di ingaggio di questa pagina
- Non accedono, non modificano e non distruggono dati degli utenti oltre lo stretto necessario a dimostrare l’impatto
- Segnalano in privato e rispettano i tempi della divulgazione coordinata
- Non sfruttano le segnalazioni per profitto personale né per qualsiasi scopo estraneo al programma di bounty
Contatti
Email:contact@intention.xyz. Metti Security nell’oggetto per una segnalazione di vulnerabilità; tutto il resto — richieste di assistenza, stampa, partnership o domande sul programma che non siano segnalazioni — va allo stesso indirizzo, senza.
Grazie per il tempo che dedichi a guardarci dentro. Il protocollo è migliore grazie a ogni ricercatore onesto che lo legge.