UTXOSUITE — home
SECURITY CORE / LOCAL-FIRST ENGINE

Wallet-Anfragen werden zu Security Context.

Security Core ist die wiederverwendbare Analyse- und Policy-Schicht hinter SafeSign. Sie decodiert, vergleicht Intent und Payload, zeigt Authority und Unsicherheit und lässt Execution unter expliziter Kontrolle des Nutzers.

SafeSign öffnenDokumentation ansehen
SECURITY CORE / ANALYSIS ENGINEEin Prozessor unter Laborlicht, für Messungen verkabelt.
CAPABILITY-MODELL

Evidence statt magischer Scores.

Kein Detector ist ein Oracle; fehlende Evidence darf niemals zu einem stillen Allow werden.

01

INTENT

Intent und Calldata decodieren.

02

AUTHORITY

Approvals, Permit und Permit2 offenlegen.

03

DESTINATION

Destination, Chain Context und Contracts prüfen.

04

SIMULATION

Simulation mit veränderlicher Execution vergleichen.

05

POLICY

Deterministische Policies anwenden.

06

EXPLANATION

Verständliche Evidence für die finale Entscheidung erzeugen.

ANALYSE-PIPELINE

Request → Decode → Context → Entscheidung.

Interpretation und Autorisierung bleiben getrennt, ohne Key Custody oder automatischen Broadcast.

01

REQUEST

Request und verfügbaren Integrationskontext empfangen.

02

DECODE

Methoden, Parameter, Typed Data, Approvals und unterstützte PSBTs normalisieren.

03

CONTEXT

Policy-, Simulation-, Destination- und Execution-Context-Signale ergänzen.

04

ENTSCHEIDUNG

Risiko und Unsicherheit erklären; Nutzer oder aufrufendes Produkt autorisieren.

TRUST BOUNDARY

Nützlich, ohne Custodian zu werden.

Analysieren und erklären; Signing Authority bleibt außerhalb von Security Core.

Was verarbeitet werden kann

Requests, Typed Data, Approvals, Adressen, Simulationsergebnisse und Policy Context.

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

Was nicht benötigt wird

Seed Phrases, Private-Key Custody, Auto-Sign, Auto-Broadcast oder einseitige Execution.

Keysnever required
Signingexplicit user boundary
Broadcastoutside the engine
DER WEG EINER SIGNATUR

Verstehen, bevor du signierst.

Jede unwiderrufliche Freigabe nimmt denselben Weg. UTXO Suite macht jeden Schritt lesbar — und hält an dem einen Schritt an, der ihm nie gehören darf: der Signatur.

  1. REQUEST

    Eine Wallet, eine dApp oder ein Agent verlangt eine Signatur. Noch gilt nichts als vertrauenswürdig.

    UTXO Suite

  2. NORMALIZE

    Die Anfrage wird in eine kanonische Form decodiert: Methode, Chain, Herkunft, Parameter.

    UTXO Suite

  3. INTENT

    Was die Anfrage tatsächlich tut, im Klartext: eine Überweisung, eine Freigabe, eine Delegation, ein Permit.

    UTXO Suite

  4. CONTEXT · SIMULATION

    Gegenpartei, Herkunft und erwartetes Ergebnis. Simulation ist Beleg, niemals Orakel.

    UTXO Suite

  5. RISK

    Gewichtete Signale: unbegrenzte Vollmacht, unbekannter Code, frisch erzeugte Verträge, unstimmige Ziele.

    UTXO Suite

  6. POLICY

    Deine Regeln, deterministisch auf diese Belege angewandt: eine Policy, kein Bauchgefühl.

    UTXO Suite

  7. DECISION

    ALLOW, WARN, REVIEW oder BLOCK. Ein BLOCK wird von keiner anderen Schicht abgeschwächt.

    UTXO Suite

  8. AUTHORIZATION

    Du gibst ausdrücklich frei. Auch ein ALLOW ist keine Signatur.

    Du

  9. PAYLOAD INTEGRITY

    Die Bytes, die gleich signiert werden, werden mit genau den Bytes verglichen, die du geprüft hast.

    UTXO Suite

  10. SIGNER

    Der isolierte Signer liegt in der Wallet. UTXO Suite hält nie einen Schlüssel oder eine Seed.

    Vigi Wallet

  11. BROADCAST

    Optional. Eine signierte Transaktion ist nicht automatisch eine gesendete Transaktion.

    Vigi Wallet

  12. VERIFICATION

    Was on-chain wirklich passiert ist, wird gegen das gehalten, was dir zugesagt wurde.

    UTXO Suite
ALLOWNichts widerspricht der Anfrage. Sie braucht trotzdem deine ausdrückliche Freigabe.
WARNEtwas verdient Aufmerksamkeit, bevor du fortfährst.
REVIEWDie Anfrage ist ohne genaues Hinsehen nicht zu verstehen.
BLOCKDie Anfrage darf unter der aktuellen Policy keinen Signer erreichen.

Keine Entscheidung ist eine Signatur. Die Freigabe bleibt immer deine.

Unbekannt wird nie sicher. Fehlende Belege bleiben fehlend.

Eine Security Layer soll die Entscheidung verbessern, nicht verschwinden lassen.

SafeSign ist die menschliche Review-Oberfläche; Security Core ist die Engine darunter.

SafeSign erkunden →
SECURITY CORE / INTERNES MODELL

Eine deterministische Engine muss erklären, warum sie zu einer Entscheidung kam.

Security Core soll einen Evidence Graph modellieren: Fakten, Provenance, Freshness, Policy Matches, Widersprüche und Unknowns, nicht einen undurchsichtigen Score.

ENGINE-PRIMITIVEN

Kleine Primitive ergeben robustere Entscheidungen.

Jede Primitive soll strukturierte Evidenz mit Provenance liefern, damit Policy über Fakten statt UI-Strings entscheidet.

01

NORMALIZER

Chain-spezifische Requests in stabile interne Repräsentation überführen, ohne Payload zu verändern.

02

AUTHORITY EXTRACTOR

Beschreiben, was die Signatur jetzt oder später autorisieren kann: Value, Token Spend, Order, Delegation oder PSBT.

03

CONTEXT RESOLVER

Origin, Chain, Contract-Beziehungen, Freshness, Simulation und Intelligence mit Source-Provenance anreichern.

04

RULE EVALUATOR

Deterministische Bedingungen wie Unlimited Approval, neues Ziel, Value Threshold oder Chain Mismatch prüfen.

05

EVIDENCE GRAPH

Fakten, Source, Zeitstempel, Widersprüche und Dependencies erhalten, damit jede Entscheidung rekonstruierbar ist.

06

DECISION EXPLAINER

Strukturierte Evidenz in Konsequenzen übersetzen, ohne Unsicherheit hinter einem Score zu verstecken.

Evidenzmodell

Eine Entscheidung aus unabhängigen Signalen aufbauen.

Unbekannte Evidenz muss sichtbar unbekannt bleiben. Fehlende Analyse darf nie stillschweigend zu ALLOW werden.

01CAPTURE

Exakten Request und Origin vor Bestätigung erfassen.

02CLASSIFY

Request-Familie vor generischer Risikologik bestimmen.

03DECODE

Methoden, Parameter, Autorität und Ziele normalisieren.

04ENRICH

Contract-, Policy-, Freshness- und Simulationskontext ergänzen, wenn verfügbar.

05COMPARE

Rekonstruierte Autorität mit der angegebenen Nutzerabsicht vergleichen.

06DECIDE

ALLOW, WARN, REVIEW oder BLOCK mit expliziten Gründen und Unknowns zurückgeben.

07AUTHORIZE

Kontrolle an Wallet oder Signer zurückgeben. Analyse signiert oder broadcastet niemals still.

Decision Contract

Decision Contract

Security Core soll einen Evidence Graph modellieren: Fakten, Provenance, Freshness, Policy Matches, Widersprüche und Unknowns, nicht einen undurchsichtigen Score.

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"
}
Entscheidungssemantik

Entscheidungssemantik

Unbekannte Evidenz muss sichtbar unbekannt bleiben. Fehlende Analyse darf nie stillschweigend zu ALLOW werden.

DECISION
TRIGGER
MEANING
NEXT
ALLOW
supported evidence consistent
Keine materielle Widersprüchlichkeit in unterstützter Evidenz. Explizite Autorisierung bleibt nötig.
EXPLICIT SIGN
WARN
material risk present
Request ist verstanden, aber materielles Risiko muss vor Autorisierung sichtbar sein.
USER REVIEW
REVIEW
incomplete or conflicting evidence
Evidenz ist unvollständig, widersprüchlich oder außerhalb der Policy. Eskalieren.
SECOND REVIEW
BLOCK
policy or supported threat signal
Konfigurierte Policy oder Threat-Signal verlangt Stop ohne expliziten Override.
NO FORWARD
POLICY / FAILURE MODES

Fail-safe verhalten, wenn Analyse degradiert.

Unbekannte Evidenz muss sichtbar unbekannt bleiben. Fehlende Analyse darf nie stillschweigend zu ALLOW werden.

UNSUPPORTED REQUEST

Nicht raten. Request erhalten, nicht unterstützte Fläche offenlegen und Review verlangen.

unsupported → REVIEW

SIMULATION UNAVAILABLE

Mit statischer und kontextueller Evidenz fortfahren, fehlende Simulation explizit markieren.

simulation: unavailable → confidence: partial

INTENT MISMATCH

Mismatch zwischen Intent und dekodierter Autorität als zentrale Evidenz behandeln.

intent != authority → REVIEW/BLOCK policy

STALE CONTEXT

Zeitabhängige Intelligence braucht Freshness-Metadaten, damit alte Beobachtungen nicht als aktuelle Fakten erscheinen.

observedAt + ttl → freshness
INVARIANT

Jedes materielle Signal braucht Provenance, Freshness und klare Trennung zwischen deterministischem Fakt, Heuristik und externer Intelligence.

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