UTXOSUITE — home
PLATEFORME DÉVELOPPEURS

Intégrez la sécurité transactionnelle au flux de signature.

SafeSign est conçu comme une couche d'intégration pour wallets, fintechs et applications onchain : décoder la requête, ajouter du contexte, préserver le payload et exiger une décision explicite.

Voir l'architecture ↗Discuter intégration →
SAFESIGN / PRE-PRODUCTIONNON-CUSTODIALEXPLICIT AUTHORIZATION14 LOCALES
DEVELOPERS / INTEGRATION SURFACEUn poste de développement dans une pièce sombre, deux écrans ouverts sur du code.
SURFACES D'INTÉGRATION

Un moteur, plusieurs modes d'intégration.

Le contrat produit est plus étroit que l'ancien récit UTXO. Les intégrations doivent exposer décisions et preuves SafeSign, sans mélanger produits business ou Office.

01CONTRACT STABILIZATION

SafeSign Decision SDK

Contrat client/serveur cible pour décoder les requêtes prises en charge, exprimer l'intention, joindre des preuves et retourner ALLOW / WARN / REVIEW / BLOCK.

context + payload → evidence + decision
02SOURCE PRIMITIVES

Security Core

Primitives local-first d'analyse et de politique réutilisables dans SafeSign, Guard et les intégrations wallet, sans garde de clés ni autorité de signature.

deterministic rules → explainable signals
03MV3 SOURCE SCAFFOLD

UTXO Guard

Surface navigateur pouvant envelopper les requêtes prises en charge et présenter SafeSign avant de transmettre la requête originale inchangée.

provider request → explicit continue / reject
04PLANNED

Enterprise Policy

Les politiques signées, approbations et contrôles de déploiement doivent se placer au-dessus du noyau et être construits après stabilisation du contrat et de l'audit.

signed policy → organization decision constraints
FRONTIÈRE DE PREUVE

Dire exactement ce qui existe.

Les acheteurs enterprise vérifieront les affirmations. Cette surface sépare donc les artefacts actuels des capacités production encore à valider ou auditer.

CURRENT

Preuves actuelles du dépôt

  • Une surface SafeSign ciblée et une architecture de sécurité transactionnelle.
  • Concepts Security Core pour décodage, règles, validation et frontières de politique.
  • Scaffold Manifest V3 de Guard et modèle explicite continuer/refuser.
NOT YET

Pas encore une promesse production

  • Aucun SLA production publié ni audit indépendant vérifié n'est revendiqué ici.
  • Ne pas vendre de couverture universelle, réseau de menaces temps réel ou garantie sub-second avant mesure.
  • Packaging API, authentification, quotas, facturation et contrats de support restent à finaliser.
VOIES COMMERCIALES

Monétiser le même noyau de sécurité à différents niveaux.

Le modèle doit passer du self-service au déploiement enterprise contractuel sans créer des produits sans lien pour chaque segment.

01

Developer

Évaluation self-service, contrats de référence, analyse locale et documentation pour favoriser l'adoption avant le procurement.

EVALUATION / ADOPTION
02

Product

Intégration à l'usage ou sous contrat pour wallets, fintechs et produits onchain lorsque les garanties API sont mesurables.

SDK / API REVENUE
03

Enterprise

Policy enforcement, déploiement privé, preuves procurement, engagements support et multi-approval forment la couche institutionnelle.

ANNUAL CONTRACT / PRIVATE DEPLOYMENT
CONTRAT CIBLE

Une interface de décision stable, pas un wallet de plus.

Le SDK/API devra recevoir le contexte et un payload intact, puis retourner des preuves structurées et une recommandation. L'autorité de signature reste au wallet intégrateur.

SAFESIGN / DECISION CONTRACTILLUSTRATIVE TARGET
// Target interface — illustrative, not a published package
const review = await safeSign.review({
  origin,
  chainId,
  method,
  payload,        // preserved unchanged
  expectedIntent, // optional user/app intent
});

review.decision // ALLOW | WARN | REVIEW | BLOCK
review.evidence // structured, explainable signals
review.payload  // same signing payload supplied by integrator
SafeSign →Security Core →UTXO Guard →Discuter intégration →
DEVELOPERS / CONTRAT D'INTÉGRATION

Intégrer la revue sans céder la frontière de signature.

Le contrat doit être side-effect free : requête entrante, preuves sortantes, payload préservé et signer toujours autoritaire.

SURFACES D'INTÉGRATION

Commencez là où la requête de signature existe déjà.

Ajouter la revue à la frontière fiable la plus étroite sans reconstruire transport, custody ou signing.

01

WALLET EXTENSION

Intercepter les provider methods avant confirmation et afficher les preuves sans remplacer la requête originale.

02

EMBEDDED WALLET

Analyser après construction de la requête et avant invocation du signer ; les clés restent hors analyse.

03

FINTECH APPROVAL FLOW

Exécuter preuves et policy avant d'envoyer le package au signer ou custody existant.

04

AGENT / AUTOMATION

Traiter l'intention machine comme entrée non fiable ; exiger policy gates et escalade humaine pour actions irréversibles ou sensibles.

05

TRANSACTION BUILDER

Analyser le payload final, pas seulement les paramètres initiaux, pour que encoding/routing ne contournent pas la revue.

06

READ-ONLY MONITORING

Réutiliser le modèle de preuves pour observabilité et incident triage sans accorder d'autorité de signature.

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 contrat doit être side-effect free : requête entrante, preuves sortantes, payload préservé et signer toujours autoritaire.

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

L'intégration doit échouer visiblement, préserver l'intégrité du payload, exposer les états non supportés et ne jamais convertir un échec d'analyse en approbation implicite.

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