UTXOSUITE — home
SECURITY CORE / MOTEUR LOCAL-FIRST

Transformez les requêtes wallet en contexte de sécurité.

Security Core est la couche réutilisable d'analyse et de politique derrière SafeSign. Il décode, compare intention et payload, expose autorité et incertitude et laisse l'exécution sous contrôle explicite de l'utilisateur.

Ouvrir SafeSignVoir la documentation
SECURITY CORE / ANALYSIS ENGINEUn processeur sous lumière de laboratoire, câblé pour la mesure.
MODÈLE DE CAPACITÉS

Des preuves, pas un score magique.

Aucun détecteur n'est un oracle et l'absence de preuve ne doit jamais devenir une autorisation silencieuse.

01

INTENT

Décoder intention et calldata.

02

AUTHORITY

Exposer approvals, Permit et Permit2.

03

DESTINATION

Inspecter destinations, chaîne et relations contractuelles.

04

SIMULATION

Comparer simulation et exécution mutable.

05

POLICY

Appliquer des politiques déterministes.

06

EXPLANATION

Produire des preuves lisibles pour la décision finale.

PIPELINE D'ANALYSE

Requête → decode → contexte → décision.

Le moteur sépare interprétation et autorisation sans prendre les clés ni diffuser la transaction.

01

REQUÊTE

Recevoir la requête et le contexte disponible.

02

DECODE

Normaliser méthodes, paramètres, typed data, approvals et PSBT pris en charge.

03

CONTEXTE

Ajouter politique, simulation, destination et contexte d'exécution quand disponibles.

04

DÉCISION

Expliquer risque et incertitude; l'utilisateur conserve l'autorisation.

FRONTIÈRE DE CONFIANCE

Utile sans devenir custodial.

Analyser et expliquer; l'autorité de signature reste hors de Security Core.

Ce qu'il peut traiter

Requêtes, typed data, approvals, adresses, simulations et contexte de politique.

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

Ce dont il n'a pas besoin

Seed, garde de clés privées, auto-signature, auto-broadcast ou exécution unilatérale.

Keysnever required
Signingexplicit user boundary
Broadcastoutside the engine
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.

Une couche de sécurité doit améliorer la décision, pas la faire disparaître.

SafeSign est la surface humaine; Security Core est le moteur réutilisable.

Explorer SafeSign →
SECURITY CORE / MODÈLE INTERNE

Un moteur déterministe doit exposer pourquoi il arrive à une décision.

Security Core doit modéliser un graphe de preuves : faits, provenance, fraîcheur, policy, contradictions et inconnues, pas un score opaque.

PRIMITIVES DU MOTEUR

De petites primitives composent des décisions plus robustes.

Chaque primitive doit émettre des preuves structurées avec provenance pour que la policy raisonne sur des faits.

01

NORMALIZER

Convertir les requêtes spécifiques en représentation interne stable sans modifier le payload.

02

AUTHORITY EXTRACTOR

Décrire ce que la signature peut autoriser maintenant ou plus tard : valeur, token spend, ordre, délégation ou PSBT.

03

CONTEXT RESOLVER

Ajouter origin, chain, relations contractuelles, fraîcheur, simulation et intelligence avec provenance.

04

RULE EVALUATOR

Évaluer des conditions déterministes comme approval illimité, nouvelle destination, seuil de valeur ou chain mismatch.

05

EVIDENCE GRAPH

Conserver faits, source, timestamps, contradictions et dépendances afin de reconstruire chaque décision.

06

DECISION EXPLAINER

Traduire les preuves structurées en conséquences sans masquer l'incertitude derrière un score.

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

Security Core doit modéliser un graphe de preuves : faits, provenance, fraîcheur, policy, contradictions et inconnues, pas un score opaque.

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

Chaque signal matériel doit porter provenance, fraîcheur et distinction entre fait déterministe, heuristique et intelligence externe.

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