UTXOSUITE — home
TRANSAKTIONSSICHERHEIT VOR DER SIGNATUR

Sieh die Berechtigung hinter dem Klick.

SafeSign ist die Prüfschicht zwischen Wallet-Anfrage und irreversibler Autorisierung. Es dekodiert, ergänzt Ausführungskontext, zeigt Unsicherheit und lässt die endgültige Entscheidung beim Nutzer.

In Academy lernen→Sicherheitsmodell↗
SAFESIGN / PRE-EXECUTIONLOCAL-FIRST
ANFRAGEeth_signTypedData_v4PermitSingle · spender 0x42…b8 · amount MAX
BERECHTIGUNGPersistent token spend
KONTEXTNew spender · unknown
ZIEL0x42…b8
SIMULATIONState-dependent
VOR DEM SIGNIEREN PRÜFENREVIEW
SAFESIGN / PRE-SIGNATURE REVIEWEin abgedunkelter Leitstand mit Transaktionsgraphen auf einer gebogenen Bildschirmwand.
EINE ANFRAGE LESEN

Eine einzige Freigabe, auseinandergenommen.

Das ist die Anfrage, die ein Drainer dich signieren lassen muss. Schick sie durch die Analyseschicht und sieh zu, wie sich das Urteil mit jedem Beleg ändert.

Rohe Wallet-Anfrageeth_sendTransaction from 0x9f1c…a034 (your account) to 0xA0b8…eB48 (USDC token contract) value 0 data 0x095ea7b3 000000000000000000000000c0ffee…b7d1 // spender ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff

Was diese Schicht feststellt

method
eth_sendTransaction
origin
app.claim-rewards-portal.xyz
chain
eip155:1 · Ethereum
to
0xA0b8…eB48

Weiterhin unbekannt

  • intent
  • authority
  • assets
  • duration
  • counterparty
UNKNOWN

Aktuelles UrteilUnbekannt wird nie sicher. Fehlende Belege bleiben fehlend.

Schicht 1/8

Illustrativer Durchlauf des veröffentlichten Analysevertrags. Die gezeigte Entscheidung ist die, die die Policy für diese Belege zurückgäbe.

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.

ANFRAGE → DEKODIEREN → KONTEXT → ENTSCHEIDUNG

Ein Sicherheitsweg rund um die tatsächliche Absicht.

SafeSign ist kein magischer Risikoscore. Entscheidend ist eine nachvollziehbare Erklärung dessen, was angefragt wird, welche Rechte entstehen und welche Unsicherheit bleibt.

01

Abfangen

Erfasst die Anfrage vor Bestätigung, ohne Schlüssel zu verwahren.

02

Dekodieren

Interpretiert Transaktionen, Typed Data, Approvals, Permit/Permit2 und unterstützte PSBTs.

03

Kontext

Vergleicht Origin, Chain, Ziel, Spender, Codepfad, Simulation und verfügbare Policies.

04

Entscheiden

Zeigt Folgen und Unsicherheit, damit ausdrücklich erlaubt, geprüft oder abgelehnt wird.

ENTSCHEIDUNGSRELEVANTE EVIDENZ

Prüfe die Teile, die das Ergebnis verändern.

Welche Evidenz verfügbar ist, hängt von Chain, Anfrage und Kontext ab. Nicht Verifiziertes muss sichtbar unbekannt bleiben.

01 / SIGNAL

Approvals & Permit2

Zeigt Spender, Token, Betrag, Deadline und persistente Spending Authority.

02 / SIGNAL

Ziel & Wert

Prüft Chain, Empfänger, Native Value und Übereinstimmung mit dem Payload.

03 / SIGNAL

Contract-Ausführung

Dekodiert Methoden, löst Proxy/delegatecall soweit möglich auf und behandelt Simulation als Evidenz, nicht Garantie.

04 / SIGNAL

Bitcoin / PSBT

Prüft Inputs, Outputs, Change und Fees unterstützter PSBTs gegen die Signing-Absicht.

GRENZEN

Evidenz, keine Garantien.

Sicherheit wird gefährlich, wenn Gewissheit übertrieben wird. SafeSign muss klar zwischen Wissen und nicht beweisbaren Annahmen unterscheiden.

Was SafeSign leisten kann

  • Unterstützte Anfragen vor Autorisierung dekodieren
  • Breite oder persistente Token-Rechte offenlegen
  • Origin, Payload, Ziel und Ausführungskontext kombinieren
  • Fehlende oder widersprüchliche Evidenz eskalieren

Was SafeSign nicht versprechen kann

  • Garantieren, dass reale Ausführung einer Simulation entspricht
  • Einen unverifizierten Contract per Score sicher machen
  • Assets nach ausgeführter bösartiger Autorisierung zurückholen
  • Gerätesicherheit, Prozesse oder menschliche Verifikation ersetzen
SAFESIGN / SECURITY CORE / ACADEMY

Mach den irreversiblen Teil zum verständlichsten Teil.

SafeSign, Security Core und Academy folgen demselben Prinzip: zuerst prüfen, Konsequenzen erklären und Ausführung unter expliziter Nutzerkontrolle halten.

In Academy üben →Sicherheitsmodell lesen →PRODUCTS →
SAFESIGN / BEDROHUNGSMODELL

Behandle die Signaturanfrage als potenziell adversariales Objekt.

Browser-Text und Wallet-UI liefern Kontext, aber keinen Beweis. SafeSign soll Autorität aus dem Payload rekonstruieren und mit Intent vergleichen.

REQUEST-TAXONOMIE

Nicht jede Signatur erteilt dieselbe Autorität.

Vor dem Scoring klassifizieren. Transfers, Approvals, EIP-712, Permit2, Multicalls und PSBT haben unterschiedliche Risiken.

01

NATIVE TRANSFER

Chain, Ziel, nativen Wert, Fees und Intermediär-Contracts prüfen.

02

TOKEN APPROVAL

Allowance als dauerhafte zukünftige Ausgabenhoheit behandeln; Spender, Scope und Widerruf prüfen.

03

EIP-712 / PERMIT

Domain Separator, Verifying Contract, Chain, Spender, Amount, Nonce und Deadline prüfen.

04

PERMIT2

Token Permission, Spender Permission und Signature Deadline gemeinsam modellieren.

05

CONTRACT / MULTICALL

Materielle Subcalls, Wertbewegungen und Authority-Änderungen dekodieren; Top-Level-Target ist nicht die ganze Ausführung.

06

BITCOIN PSBT

Inputs, Outputs, Change, Fee, Sighash und Derivation-Metadaten mit Zahlungsabsicht vergleichen.

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

Browser-Text und Wallet-UI liefern Kontext, aber keinen Beweis. SafeSign soll Autorität aus dem Payload rekonstruieren und mit Intent vergleichen.

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

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

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