UTXOSUITE — home
DOCUMENTATION DÉVELOPPEUR

Intégrez la frontière de revue, pas la garde.

La documentation se concentre sur la sécurité transactionnelle : entrée SafeSign, analyse Security Core, autorisation et état réel des intégrations.

DOCS / IMPLEMENTATION REFERENCEUn cluster compact de serveurs edge, voyants d'état en façade.
MODÈLE DE SÉCURITÉ

Quatre invariants avant les détails.

Ces contraintes comptent davantage que le framework.

INVARIANT 01

NO CUSTODY

Aucune garde de seed ou clé privée.

INVARIANT 02

PAYLOAD INTEGRITY

Ne pas muter le payload fourni par wallet/dApp.

INVARIANT 03

EXPLICIT AUTHORIZATION

Pas d'auto-signature ni auto-broadcast; autorisation explicite.

INVARIANT 04

FAIL VISIBLE

Preuve absente = incertitude, jamais autorisation silencieuse.

CYCLE DE REQUÊTE

Requête → decode → contexte → revue.

Préserver la requête et ajouter des preuves lisibles.

01

REQUEST

Recevoir requête et contexte disponible.

02

DECODE

Normaliser méthode, paramètres, typed data, approvals ou PSBT.

03

CONTEXT

Ajouter politique, destination et simulation si disponibles.

04

REVIEW

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

GUARD / MANIFEST V3

Fondation actuelle d'intégration navigateur.

Un scaffold Chrome/Brave existe, enveloppe ethereum.request et attend continuer/refuser. La pipeline production reste à faire.

Scaffold développeur

ethereum.request → SafeSign → original provider

// browser/page context — conceptual integration boundary
const original = ethereum.request.bind(ethereum)
ethereum.request = async (request) => {
  const decision = await reviewWithSafeSign(request)
  if (decision !== "continue") throw new Error("User rejected")
  return original(request) // forward unchanged
}

Préférences locales non sensibles uniquement; jamais clés, seeds, signatures brutes ou historique complet.

ÉTAT D'INTÉGRATION

Une UI polie ne prouve pas le backend.

Chaque surface déclare sa frontière réelle.

01

UTXO GUARD

Guard — fondation Manifest V3 existante; build/distribution production séparés.

02

UTXO WALLET

Wallet — UI actuelle; flux réels via SafeSign avant confirmation.

03

UTXO RELAY

Relay — analyse routes/frais/PSBT; signature/exécution futures.

ARCHITECTURE DE RÉFÉRENCE

Un contrat de revue transactionnelle implémentable et testable.

Préserver la requête, dériver des preuves structurées, enregistrer les inconnues et retourner une décision explicable sans prendre l'autorité de signature.

01 / REQUEST ENVELOPE

REQUEST ENVELOPE

Capturer origin, chaîne, méthode, payload hash et intention avant analyse.

02 / EVIDENCE GRAPH

EVIDENCE GRAPH

Conserver faits, provenance, fraîcheur, contradictions et inconnues comme nœuds séparés.

03 / DECISION CONTRACT

DECISION CONTRACT

Retourner ALLOW, WARN, REVIEW ou BLOCK avec reason codes et payload hash revu.

PIPELINE DE RÉFÉRENCE

Chaque étape possède une sortie fail-safe.

Préserver la requête, dériver des preuves structurées, enregistrer les inconnues et retourner une décision explicable sans prendre l'autorité de signature.

STAGE
ARTIFACT / INPUT
EVIDENCE / MEANING
OUTPUT
CAPTURE
origin · request
Préserver l'enveloppe originale.
REVIEW
DECODE
method · params
Normaliser l'autorité prise en charge et exposer l'entrée non supportée.
UNKNOWN
DECIDE
evidence · policy
Retourner décision, reason codes et payload hash exact.
EXPLICIT
REQUEST ENVELOPE
{
  "origin":"https://app.example",
  "chainId":1,
  "method":"eth_signTypedData_v4",
  "payloadHash":"sha256:...",
  "intent":"swap 1 ETH"
}
REVIEW RESULT
{
  "decision":"REVIEW",
  "reasonCodes":["AUTHORITY_EXCEEDS_INTENT"],
  "unknowns":["spender_reputation"],
  "payloadHash":"sha256:..."
}
INTEGRATION RULE

Si le payload change après la revue, la décision est invalide et une nouvelle revue est requise.