UTXOSUITE — home
SECURITY CORE / MOTORE LOCAL-FIRST

Trasforma le richieste wallet in contesto di sicurezza.

Security Core è il livello riutilizzabile di analisi e policy dietro SafeSign. Decodifica, confronta intento e payload, espone autorità e incertezza e lascia l'esecuzione sotto il controllo esplicito dell'utente.

Apri SafeSignVedi documentazione
SECURITY CORE / ANALYSIS ENGINEUn processore sotto luce da laboratorio, cablato per la misurazione.
MODELLO DI CAPACITÀ

Evidenza, non punteggi magici.

Nessun detector è un oracolo e l'evidenza mancante non deve diventare un silent allow.

01

INTENT

Decodifica intento e calldata.

02

AUTHORITY

Espone approvals, Permit e Permit2.

03

DESTINATION

Ispeziona destinazioni, chain context e contratti.

04

SIMULATION

Confronta simulazione ed execution mutabile.

05

POLICY

Applica policy deterministiche.

06

EXPLANATION

Produce evidenza leggibile per la decisione finale.

PIPELINE DI ANALISI

Richiesta → decode → contesto → decisione.

Separa interpretazione e autorizzazione senza custodire chiavi o fare broadcast.

01

RICHIESTA

Riceve la richiesta e il contesto disponibile.

02

DECODE

Normalizza metodi, parametri, typed data, approvals e PSBT supportati.

03

CONTESTO

Aggiunge policy, simulation, destination ed execution context quando disponibili.

04

DECISIONE

Spiega rischio e incertezza; l'utente mantiene l'autorizzazione.

TRUST BOUNDARY

Utile senza diventare custodial.

Analizza e spiega; signing authority resta fuori da Security Core.

Cosa può elaborare

Richieste, typed data, approvals, indirizzi, simulazioni e policy context.

Inputrequests / typed data / approvals
Contextpolicy / simulation / destination
Outputevidence / risk / uncertainty

Cosa non richiede

Seed, private-key custody, auto-sign, auto-broadcast o execution unilaterale.

Keysnever required
Signingexplicit user boundary
Broadcastoutside the engine
IL PERCORSO DI UNA FIRMA

Capire prima di firmare.

Ogni autorizzazione irreversibile percorre la stessa strada. UTXO Suite rende leggibile ogni passaggio — e si ferma all'unico che non deve mai possedere: la firma.

  1. REQUEST

    Un wallet, una dApp o un agente chiede una firma. Non si dà ancora nulla per buono.

    UTXO Suite

  2. NORMALIZE

    La richiesta viene decodificata in una forma canonica: metodo, catena, origine, parametri.

    UTXO Suite

  3. INTENT

    Che cosa fa davvero la richiesta, in chiaro: un trasferimento, un'approvazione, una delega, un permit.

    UTXO Suite

  4. CONTEXT · SIMULATION

    Controparte, provenienza e risultato atteso. La simulazione è una prova, mai un oracolo.

    UTXO Suite

  5. RISK

    Segnali pesati: autorità illimitata, codice sconosciuto, contratti appena creati, destinazioni incoerenti.

    UTXO Suite

  6. POLICY

    Le tue regole applicate in modo deterministico su quelle prove: una policy, non un'intuizione.

    UTXO Suite

  7. DECISION

    ALLOW, WARN, REVIEW o BLOCK. Un BLOCK non viene mai ammorbidito da un altro livello.

    UTXO Suite

  8. AUTHORIZATION

    Autorizzi in modo esplicito. Nemmeno un ALLOW è una firma.

    Tu

  9. PAYLOAD INTEGRITY

    I byte che stanno per essere firmati vengono confrontati con i byte esatti che hai esaminato.

    UTXO Suite

  10. SIGNER

    Il firmatario isolato vive dentro il wallet. UTXO Suite non custodisce mai una chiave né una seed.

    Vigi Wallet

  11. BROADCAST

    Facoltativo. Una transazione firmata non è automaticamente una transazione trasmessa.

    Vigi Wallet

  12. VERIFICATION

    Ciò che è realmente accaduto sulla catena viene confrontato con ciò che ti era stato promesso.

    UTXO Suite
ALLOWNulla contraddice la richiesta. Serve comunque la tua autorizzazione esplicita.
WARNC'è qualcosa che merita attenzione prima di proseguire.
REVIEWLa richiesta non può essere compresa senza che tu la guardi da vicino.
BLOCKLa richiesta non deve raggiungere un firmatario con la policy attuale.

Nessuna decisione è una firma. L'autorizzazione resta sempre tua.

L'ignoto non diventa mai sicuro. Una prova mancante resta mancante.

La sicurezza deve migliorare la decisione, non eliminarla.

SafeSign è la superficie umana; Security Core è il motore riutilizzabile.

Esplora SafeSign →
SECURITY CORE / MODELLO INTERNO

Un motore deterministico deve spiegare perché arriva a una decisione.

Security Core deve modellare un evidence graph: facts, provenance, freshness, policy, contraddizioni e unknowns, non uno score opaco.

PRIMITIVE DEL MOTORE

Primitive piccole compongono decisioni più forti.

Ogni primitiva deve emettere evidenza strutturata con provenance per consentire alla policy di ragionare sui fatti.

01

NORMALIZER

Converte request specifiche in una rappresentazione interna stabile senza mutare payload.

02

AUTHORITY EXTRACTOR

Descrivi cosa può autorizzare la firma ora o dopo: value, token spend, ordine, delegazione o PSBT.

03

CONTEXT RESOLVER

Aggiungi origin, chain, relazioni contrattuali, freshness, simulation e intelligence con provenance.

04

RULE EVALUATOR

Valuta condizioni deterministiche come unlimited approval, new destination, value threshold o chain mismatch.

05

EVIDENCE GRAPH

Conserva facts, source, timestamps, contraddizioni e dipendenze per ricostruire ogni decisione.

06

DECISION EXPLAINER

Traduci evidenza strutturata in conseguenze senza nascondere uncertainty dietro uno score.

Modello di evidenza

Costruisci una decisione da segnali indipendenti.

L'evidenza sconosciuta deve restare visibilmente sconosciuta. L'assenza di analisi non deve mai diventare ALLOW.

01CAPTURE

Ricevi la richiesta esatta e origin prima della conferma.

02CLASSIFY

Identifica la famiglia prima di applicare logica generica.

03DECODE

Normalizza metodi, parametri, autorità e destinazioni.

04ENRICH

Aggiungi contesto contract, policy, freshness e simulazione quando disponibile.

05COMPARE

Confronta l'autorità ricostruita con l'intento dichiarato.

06DECIDE

Restituisci ALLOW, WARN, REVIEW o BLOCK con motivazioni e unknowns espliciti.

07AUTHORIZE

Restituisci il controllo a wallet o signer. L'analisi non firma né trasmette silenziosamente.

Contratto decisionale

Contratto decisionale

Security Core deve modellare un evidence graph: facts, provenance, freshness, policy, contraddizioni e unknowns, non uno score opaco.

REQUEST / INPUT
{
  "requestType": "eip712",
  "origin": "https://app.example",
  "chainId": 1,
  "method": "eth_signTypedData_v4",
  "intent": { "action": "swap", "asset": "USDC" },
  "payload": "<original wallet payload>"
}
DECISION / OUTPUT
{
  "decision": "REVIEW",
  "confidence": "partial",
  "authority": [{ "type": "token_spend", "scope": "unlimited" }],
  "evidence": [{ "signal": "new_spender", "severity": "high" }],
  "unknowns": ["future_execution_state"],
  "payloadIntegrity": "unchanged"
}
Semantica decisionale

Semantica decisionale

L'evidenza sconosciuta deve restare visibilmente sconosciuta. L'assenza di analisi non deve mai diventare ALLOW.

DECISION
TRIGGER
MEANING
NEXT
ALLOW
supported evidence consistent
Nessuna contraddizione materiale nell'evidenza supportata. Serve comunque autorizzazione esplicita.
EXPLICIT SIGN
WARN
material risk present
La richiesta è compresa, ma il rischio materiale deve essere mostrato prima dell'autorizzazione.
USER REVIEW
REVIEW
incomplete or conflicting evidence
L'evidenza è incompleta, contraddittoria o fuori policy. Effettuare escalation.
SECOND REVIEW
BLOCK
policy or supported threat signal
Una policy configurata o threat signal indica di non procedere senza override esplicito.
NO FORWARD
POLICY / FAILURE MODES

Fallisci in sicurezza quando l'analisi degrada.

L'evidenza sconosciuta deve restare visibilmente sconosciuta. L'assenza di analisi non deve mai diventare ALLOW.

UNSUPPORTED REQUEST

Non indovinare. Preserva la richiesta, mostra ciò che non è supportato e richiedi review.

unsupported → REVIEW

SIMULATION UNAVAILABLE

Continua con evidenza statica e contestuale, rendendo esplicita l'assenza della simulazione.

simulation: unavailable → confidence: partial

INTENT MISMATCH

Tratta il mismatch tra intento e autorità decodificata come evidenza primaria.

intent != authority → REVIEW/BLOCK policy

STALE CONTEXT

L'intelligence time-sensitive richiede freshness metadata per evitare che osservazioni vecchie sembrino attuali.

observedAt + ttl → freshness
INVARIANT

Ogni segnale materiale deve avere provenance, freshness e distinzione tra fatto deterministico, euristica e intelligence esterna.

EIP-712 ↗ERC-2612 ↗BIP-174 ↗OWASP SCSVS ↗