UTXOSUITE — home
SÉCURITÉ TRANSACTIONNELLE AVANT SIGNATURE

Voyez l'autorité derrière le clic.

SafeSign est la couche de revue entre une requête wallet et une autorisation irréversible. Il décode, ajoute le contexte d'exécution, expose l'incertitude et laisse la décision finale à l'utilisateur.

Apprendre dans Academy→Modèle de sécurité↗
SAFESIGN / PRE-EXECUTIONLOCAL-FIRST
REQUÊTEeth_signTypedData_v4PermitSingle · spender 0x42…b8 · amount MAX
AUTORITÉPersistent token spend
CONTEXTENew spender · unknown
DESTINATION0x42…b8
SIMULATIONState-dependent
REVOIR AVANT SIGNATUREREVIEW
SAFESIGN / PRE-SIGNATURE REVIEWUne salle d'opérations dans la pénombre, des graphes de transactions sur un mur d'écrans incurvé.
LIRE UNE REQUÊTE

Une seule approbation, démontée.

Voici la requête qu'un drainer a besoin de vous faire signer. Faites-la traverser la couche d'analyse et regardez le verdict évoluer à mesure que les preuves arrivent.

Requête brute du walleteth_sendTransaction from 0x9f1c…a034 (your account) to 0xA0b8…eB48 (USDC token contract) value 0 data 0x095ea7b3 000000000000000000000000c0ffee…b7d1 // spender ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff

Ce que cette couche établit

method
eth_sendTransaction
origin
app.claim-rewards-portal.xyz
chain
eip155:1 · Ethereum
to
0xA0b8…eB48

Encore inconnu

  • intent
  • authority
  • assets
  • duration
  • counterparty
UNKNOWN

Verdict actuelL'inconnu ne devient jamais sûr. Une preuve manquante reste manquante.

Couche 1/8

Parcours illustratif du contrat d'analyse publié. La décision affichée est celle que la politique renverrait pour ces preuves.

LE CHEMIN D'UNE SIGNATURE

Comprendre avant de signer.

Toute autorisation irréversible emprunte le même chemin. UTXO Suite rend chaque étape lisible — et s'arrête à la seule qu'il ne doit jamais posséder : la signature.

  1. REQUEST

    Un wallet, une dApp ou un agent demande une signature. Rien n'est encore tenu pour acquis.

    UTXO Suite

  2. NORMALIZE

    La requête est décodée en une forme canonique : méthode, chaîne, origine, paramètres.

    UTXO Suite

  3. INTENT

    Ce que la requête fait réellement, en clair : un transfert, une approbation, une délégation, un permit.

    UTXO Suite

  4. CONTEXT · SIMULATION

    Contrepartie, provenance et résultat attendu. La simulation est une preuve, jamais un oracle.

    UTXO Suite

  5. RISK

    Signaux pondérés : autorité illimitée, code inconnu, contrats fraîchement déployés, destinataires incohérents.

    UTXO Suite

  6. POLICY

    Vos règles appliquées de façon déterministe à ces preuves : une politique, pas une intuition.

    UTXO Suite

  7. DECISION

    ALLOW, WARN, REVIEW ou BLOCK. Un BLOCK n'est jamais adouci par une autre couche.

    UTXO Suite

  8. AUTHORIZATION

    Vous autorisez explicitement. Même un ALLOW n'est pas une signature.

    Vous

  9. PAYLOAD INTEGRITY

    Les octets sur le point d'être signés sont comparés aux octets exacts que vous avez examinés.

    UTXO Suite

  10. SIGNER

    Le signataire isolé vit dans le wallet. UTXO Suite ne détient jamais de clé ni de phrase de récupération.

    Vigi Wallet

  11. BROADCAST

    Facultatif. Une transaction signée n'est pas automatiquement une transaction diffusée.

    Vigi Wallet

  12. VERIFICATION

    Ce qui s'est réellement produit sur la chaîne est confronté à ce qui vous avait été annoncé.

    UTXO Suite
ALLOWRien ne contredit la requête. Elle exige toujours votre autorisation explicite.
WARNQuelque chose mérite votre attention avant de continuer.
REVIEWLa requête ne peut pas être comprise sans que vous y regardiez de plus près.
BLOCKLa requête ne doit pas atteindre un signataire sous la politique actuelle.

Aucune décision n'est une signature. L'autorisation vous appartient toujours.

L'inconnu ne devient jamais sûr. Une preuve manquante reste manquante.

REQUÊTE → DÉCODER → CONTEXTE → DÉCISION

Un parcours de sécurité centré sur l'intention.

SafeSign n'est pas un score magique. Le résultat utile est une explication traçable de la requête, de l'autorité potentiellement accordée et des inconnues restantes.

01

Intercepter

Capture la requête avant confirmation sans garde de clés.

02

Décoder

Interprète transactions, typed data, approvals, Permit/Permit2 et PSBT pris en charge.

03

Contextualiser

Compare origin, chaîne, destination, spender, chemin de code, simulation et politiques disponibles.

04

Décider

Présente conséquences et incertitudes pour permettre, revoir ou refuser explicitement.

ÉVIDENCE DÉCISIONNELLE

Inspectez ce qui peut changer le résultat.

L'évidence dépend de la chaîne, de la requête et du contexte disponible. Une information non vérifiée doit rester inconnue.

01 / SIGNAL

Approvals & Permit2

Expose spender, token, montant, deadline et autorité persistante.

02 / SIGNAL

Destination & valeur

Vérifie chaîne, destinataire, valeur native et cohérence avec le payload.

03 / SIGNAL

Exécution du contrat

Décode les méthodes, résout proxy/delegatecall si possible et traite la simulation comme preuve, jamais comme garantie.

04 / SIGNAL

Bitcoin / PSBT

Inspecte inputs, outputs, change et fees des PSBT prises en charge pour comparer intention et transaction.

LIMITES

Des preuves, pas des garanties.

La sécurité devient dangereuse lorsqu'elle surestime sa certitude. SafeSign distingue ce qu'il explique de ce qu'il ne peut prouver.

Ce que SafeSign peut faire

  • Décoder les requêtes prises en charge avant autorisation
  • Exposer les permissions larges ou persistantes
  • Combiner origin, payload, destination et contexte
  • Escalader les preuves absentes ou contradictoires

Ce que SafeSign ne peut promettre

  • Garantir qu'une exécution future égalera une simulation
  • Rendre sûr un contrat non vérifié par un score
  • Récupérer les actifs après une autorisation malveillante exécutée
  • Remplacer la sécurité matérielle, les procédures ou la vérification humaine
SAFESIGN / SECURITY CORE / ACADEMY

Rendez la partie irréversible la plus compréhensible.

SafeSign, Security Core et Academy suivent le même principe : inspecter, expliquer la conséquence et conserver l'exécution sous contrôle explicite de l'utilisateur.

Pratiquer dans Academy →Lire le modèle de sécurité →PRODUCTS →
SAFESIGN / MODÈLE DE MENACES

Traitez la requête de signature comme un objet potentiellement hostile.

Le navigateur et l'UI wallet donnent du contexte, pas une preuve. SafeSign doit reconstruire l'autorité depuis le payload et la comparer à l'intention.

TAXONOMIE DES REQUÊTES

Toutes les signatures n'accordent pas la même autorité.

Classer avant le scoring. Transferts, approvals, EIP-712, Permit2, multicalls et PSBT ont des risques différents.

01

NATIVE TRANSFER

Vérifier chain, destination, valeur native, frais et contrats intermédiaires.

02

TOKEN APPROVAL

Traiter l'allowance comme une autorité future persistante ; inspecter spender, portée et révocation.

03

EIP-712 / PERMIT

Inspecter domain separator, verifying contract, chain, spender, montant, nonce et deadline.

04

PERMIT2

Modéliser ensemble token permission, spender permission et signature deadline.

05

CONTRACT / MULTICALL

Décoder subcalls, mouvements de valeur et changements d'autorité ; le target principal ne décrit pas toute l'exécution.

06

BITCOIN PSBT

Comparer inputs, outputs, change, fee, sighash et métadonnées avec le paiement attendu.

Modèle de preuves

Construire une décision à partir de signaux indépendants.

Une preuve inconnue doit rester explicitement inconnue. Une analyse absente ne doit jamais devenir ALLOW.

01CAPTURE

Recevoir la requête exacte et son origin avant confirmation.

02CLASSIFY

Identifier la famille avant toute logique de risque générique.

03DECODE

Normaliser méthodes, paramètres, autorité et destinations.

04ENRICH

Ajouter contexte contrat, policy, fraîcheur et simulation lorsqu'ils existent.

05COMPARE

Comparer l'autorité reconstruite avec l'intention déclarée.

06DECIDE

Retourner ALLOW, WARN, REVIEW ou BLOCK avec raisons et inconnues explicites.

07AUTHORIZE

Rendre le contrôle au wallet ou signer. L'analyse ne signe ni ne diffuse silencieusement.

Contrat de décision

Contrat de décision

Le navigateur et l'UI wallet donnent du contexte, pas une preuve. SafeSign doit reconstruire l'autorité depuis le payload et la comparer à l'intention.

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"
}
Sémantique de décision

Sémantique de décision

Une preuve inconnue doit rester explicitement inconnue. Une analyse absente ne doit jamais devenir ALLOW.

DECISION
TRIGGER
MEANING
NEXT
ALLOW
supported evidence consistent
Aucune contradiction matérielle dans les preuves supportées. Autorisation explicite toujours requise.
EXPLICIT SIGN
WARN
material risk present
La requête est comprise, mais le risque matériel doit être affiché avant autorisation.
USER REVIEW
REVIEW
incomplete or conflicting evidence
Les preuves sont incomplètes, contradictoires ou hors policy. Il faut escalader.
SECOND REVIEW
BLOCK
policy or supported threat signal
Une policy configurée ou un signal de menace indique de ne pas poursuivre sans override explicite.
NO FORWARD
POLICY / FAILURE MODES

Échouer en sécurité lorsque l'analyse se dégrade.

Une preuve inconnue doit rester explicitement inconnue. Une analyse absente ne doit jamais devenir ALLOW.

UNSUPPORTED REQUEST

Ne pas deviner. Préserver la requête, exposer l'élément non supporté et exiger une revue.

unsupported → REVIEW

SIMULATION UNAVAILABLE

Continuer avec preuves statiques et contextuelles en signalant l'absence de simulation.

simulation: unavailable → confidence: partial

INTENT MISMATCH

Traiter l'écart entre intention et autorité décodée comme une preuve majeure.

intent != authority → REVIEW/BLOCK policy

STALE CONTEXT

Les données temporelles ont besoin de métadonnées de fraîcheur pour éviter qu'une observation ancienne paraisse actuelle.

observedAt + ttl → freshness
INVARIANT

Une preuve inconnue doit rester explicitement inconnue. Une analyse absente ne doit jamais devenir ALLOW.

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