UTXOSUITE — home
ENTWICKLERDOKUMENTATION

Integriere die Review-Grenze, nicht die Custody-Grenze.

Die Dokumentation fokussiert Transaction Security: SafeSign-Eingang, Security-Core-Analyse, Autorisierung und tatsächlichen Integrationsstatus.

DOCS / IMPLEMENTATION REFERENCEEin kompakter Edge-Server-Cluster, Statusleuchten an den Fronten.
SECURITY MODEL

Vier Invarianten vor Implementierungsdetails.

Diese Grenzen sind wichtiger als die Framework-Wahl.

INVARIANT 01

NO CUSTODY

Keine Seed- oder Private-Key-Custody.

INVARIANT 02

PAYLOAD INTEGRITY

Payload von Wallet/dApp nicht mutieren.

INVARIANT 03

EXPLICIT AUTHORIZATION

Kein Auto-Sign oder Auto-Broadcast; Autorisierung bleibt explizit.

INVARIANT 04

FAIL VISIBLE

Fehlende Evidence = Unsicherheit, niemals Silent Allow.

REQUEST LIFECYCLE

Request → Decode → Context → Review.

Originalen Request erhalten und verständliche Evidence ergänzen.

01

REQUEST

Request und verfügbaren Context empfangen.

02

DECODE

Method, Params, Typed Data, Approvals oder PSBT normalisieren.

03

CONTEXT

Policy, Destination und Simulation ergänzen.

04

REVIEW

Risiko/Unsicherheit in SafeSign zeigen; Nutzer autorisiert final.

GUARD / MANIFEST V3

Aktuelle Browser-Integrationsbasis.

Ein Chrome/Brave-Scaffold existiert, wrappt ethereum.request und wartet auf Continue/Reject. Production-Build-Pipeline ist noch nötig.

Developer Scaffold

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
}

Nur nicht-sensitive lokale Einstellungen; niemals Keys, Seeds, Raw Signatures oder vollständige Historie.

INTEGRATIONSSTATUS

Eine polierte UI beweist keine Backend-Fähigkeit.

Jede Oberfläche nennt ihre reale Implementierungsgrenze.

01

UTXO GUARD

Guard — Manifest-V3-Basis existiert; Production Build/Distribution separat.

02

UTXO WALLET

Wallet — UI existiert; reale Flows müssen SafeSign aufrufen.

03

UTXO RELAY

Relay — Route/Fee/PSBT-Analyse existiert; Signing/Execution zukünftig.

REFERENZARCHITEKTUR

Ein implementierbarer und testbarer Transaction-Review-Vertrag.

Request erhalten, strukturierte Evidenz ableiten, Unknowns protokollieren und eine erklärbare Entscheidung liefern, ohne Signaturhoheit zu übernehmen.

01 / REQUEST ENVELOPE

REQUEST ENVELOPE

Origin, Chain, Methode, Payload-Hash und Intention vor Analyse erfassen.

02 / EVIDENCE GRAPH

EVIDENCE GRAPH

Fakten, Provenance, Freshness, Widersprüche und Unknowns getrennt halten.

03 / DECISION CONTRACT

DECISION CONTRACT

ALLOW, WARN, REVIEW oder BLOCK mit Reason Codes und geprüftem Payload-Hash zurückgeben.

REFERENZ-PIPELINE

Jede Stufe hat einen Fail-Safe-Output.

Request erhalten, strukturierte Evidenz ableiten, Unknowns protokollieren und eine erklärbare Entscheidung liefern, ohne Signaturhoheit zu übernehmen.

STAGE
ARTIFACT / INPUT
EVIDENCE / MEANING
OUTPUT
CAPTURE
origin · request
Originalen Envelope erhalten.
REVIEW
DECODE
method · params
Unterstützte Autorität normalisieren und unsupported input sichtbar machen.
UNKNOWN
DECIDE
evidence · policy
Decision, Reason Codes und exakten Payload-Hash zurückgeben.
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

Ändert sich der Payload nach der Review, ist die Entscheidung ungültig und neue Review erforderlich.