UTXOSUITE — home
PRE-SIGNATURE TRANSACTION SECURITY

See the authority behind the click.

SafeSign is the review layer between a wallet request and an irreversible authorization. It decodes what can be decoded, adds execution context, surfaces uncertainty and leaves the final decision with the user.

Learn in Academy→Security model↗
SAFESIGN / PRE-EXECUTIONLOCAL-FIRST
REQUESTeth_signTypedData_v4PermitSingle · spender 0x42…b8 · amount MAX
AUTHORITYPersistent token spend
CONTEXTNew spender · unknown
DESTINATION0x42…b8
SIMULATIONState-dependent
REVIEW BEFORE SIGNINGREVIEW
SAFESIGN / PRE-SIGNATURE REVIEWA darkened operations room with transaction graphs across a curved screen wall.
READ ONE REQUEST

A single approval, taken apart.

This is the request a drainer needs you to sign. Walk it through the review layer and watch the verdict change as the evidence arrives.

Raw wallet requesteth_sendTransaction from 0x9f1c…a034 (your account) to 0xA0b8…eB48 (USDC token contract) value 0 data 0x095ea7b3 000000000000000000000000c0ffee…b7d1 // spender ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff

What this layer establishes

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

Still unknown

  • intent
  • authority
  • assets
  • duration
  • counterparty
UNKNOWN

Current verdictUnknown never becomes safe. Missing evidence stays missing.

Layer 1/8

Illustrative walkthrough of the published review contract. The decision shown is what the policy would return for this evidence.

THE PATH OF A SIGNATURE

Understand before you sign.

Every irreversible authorization travels the same path. UTXO Suite makes each step of that path readable — and stops at the one step it must never own: the signature itself.

  1. REQUEST

    A wallet, a dApp or an agent asks for a signature. Nothing is trusted yet.

    UTXO Suite

  2. NORMALIZE

    The request is decoded into one canonical shape: method, chain, origin, parameters.

    UTXO Suite

  3. INTENT

    What the request actually does, in plain terms: a transfer, an approval, a delegation, a permit.

    UTXO Suite

  4. CONTEXT · SIMULATION

    Counterparty, origin and expected outcome. Simulation is evidence, never an oracle.

    UTXO Suite

  5. RISK

    Weighted signals: unlimited authority, unknown code, fresh contracts, mismatched destinations.

    UTXO Suite

  6. POLICY

    Your rules, applied deterministically to that evidence — a policy, not a feeling.

    UTXO Suite

  7. DECISION

    ALLOW, WARN, REVIEW or BLOCK. A BLOCK is never softened by another layer.

    UTXO Suite

  8. AUTHORIZATION

    You authorize explicitly. Even an ALLOW is not a signature.

    You

  9. PAYLOAD INTEGRITY

    The bytes about to be signed are compared to the exact bytes you reviewed.

    UTXO Suite

  10. SIGNER

    The isolated signer runs inside the wallet. UTXO Suite never holds a key or a seed.

    Vigi Wallet

  11. BROADCAST

    Optional. A signed transaction is not automatically a broadcast one.

    Vigi Wallet

  12. VERIFICATION

    What actually happened on-chain is checked against what you were promised.

    UTXO Suite
ALLOWNothing contradicts the request. It still needs your explicit authorization.
WARNSomething deserves attention before you continue.
REVIEWThe request cannot be understood without you looking closer.
BLOCKThe request must not reach a signer under the current policy.

No decision is a signature. Authorization is always yours.

Unknown never becomes safe. Missing evidence stays missing.

REQUEST → DECODE → CONTEXT → DECISION

A security path built around intent.

SafeSign is not a magic risk score. The useful output is a traceable explanation of what was requested, which authority may be granted and which assumptions remain unresolved.

01

Intercept

Capture the wallet request before confirmation without taking custody of keys.

02

Decode

Interpret transaction data, typed messages, approvals, Permit/Permit2 and supported PSBT structures.

03

Context

Compare origin, chain, destination, spender, code path, simulation evidence and policy signals where available.

04

Decide

Present the material consequences and uncertainty so the user can allow, review or reject explicitly.

DECISION-GRADE EVIDENCE

Inspect the parts that change the outcome.

The exact evidence depends on chain, request type and available local or remote context. Unsupported evidence must remain visibly unknown rather than silently assumed safe.

01 / SIGNAL

Approvals & Permit2

Expose spender, token, amount, deadline and persistent spending authority instead of treating an approval as a harmless click.

02 / SIGNAL

Destination & value

Verify chain, recipient, native value and the relationship between the visible destination and the payload.

03 / SIGNAL

Contract execution

Decode methods, surface proxy/delegatecall context where resolvable, and treat simulation as evidence rather than a guarantee.

04 / SIGNAL

Bitcoin / PSBT

Inspect supported PSBT inputs, outputs, change and fee structure so signing intent can be compared with the transaction being authorized.

BOUNDARIES

Evidence, not guarantees.

Transaction security becomes dangerous when confidence is overstated. SafeSign must be explicit about both what it can explain and what it cannot prove.

What SafeSign can do

  • Decode supported wallet requests before authorization
  • Expose broad or persistent token authority
  • Combine origin, payload, destination and execution context
  • Escalate missing or contradictory evidence for review

What SafeSign cannot promise

  • Guarantee that future execution equals a simulation
  • Make an unverified contract safe by assigning it a score
  • Recover assets after a malicious authorization is executed
  • Replace hardware, operational security or human verification
SAFESIGN / SECURITY CORE / ACADEMY

Make the irreversible part the most understandable part.

SafeSign, Security Core and Academy are designed around the same principle: inspect first, explain the consequence, and keep execution under explicit user control.

Practice in Academy →Read the security model →PRODUCTS →
SAFESIGN / THREAT MODEL

Treat the signing request as an adversarial object.

Browser copy and wallet UI are context, not proof. SafeSign should reconstruct authority from the payload and compare it with stated intent before a signer is asked to authorize anything.

REQUEST TAXONOMY

Not every signature grants the same authority.

Classify before scoring. Transfers, approvals, EIP-712, Permit2, multicalls and PSBTs expose different invariants and failure modes.

01

NATIVE TRANSFER

Verify chain, destination, native value, fee assumptions and intermediary contracts.

02

TOKEN APPROVAL

Treat allowance as durable future spending authority; inspect spender, scope and revocability.

03

EIP-712 / PERMIT

Inspect domain separator, verifying contract, chain, spender, amount, nonce and deadline.

04

PERMIT2

Model token permission, spender permission and signature deadline together; off-chain does not mean low impact.

05

CONTRACT / MULTICALL

Decode material subcalls, value movement and authority changes; the top-level target is not the full execution story.

06

BITCOIN PSBT

Compare inputs, outputs, change, fee, sighash behavior and derivation metadata with intended payment.

Evidence model

Build a decision from independent signals.

Unknown evidence must remain visibly unknown. Missing analysis must never silently become ALLOW.

01CAPTURE

Receive the exact request and origin before confirmation.

02CLASSIFY

Identify the request family before applying generic risk logic.

03DECODE

Normalize methods, parameters, authority and destinations.

04ENRICH

Attach contract, policy, freshness and simulation context where available.

05COMPARE

Compare reconstructed authority with the user's stated intent.

06DECIDE

Return ALLOW, WARN, REVIEW or BLOCK with explicit reasons and unknowns.

07AUTHORIZE

Return control to the wallet or signer. Analysis never silently signs or broadcasts.

Decision contract

Decision contract

Browser copy and wallet UI are context, not proof. SafeSign should reconstruct authority from the payload and compare it with stated intent before a signer is asked to authorize anything.

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"
}
Decision semantics

Decision semantics

Unknown evidence must remain visibly unknown. Missing analysis must never silently become ALLOW.

DECISION
TRIGGER
MEANING
NEXT
ALLOW
supported evidence consistent
No material contradiction found inside the supported evidence. Explicit authorization is still required.
EXPLICIT SIGN
WARN
material risk present
The request is understood, but the user should see the material risk before authorization.
USER REVIEW
REVIEW
incomplete or conflicting evidence
Evidence is incomplete, contradictory or outside policy. Escalate instead of pretending certainty.
SECOND REVIEW
BLOCK
policy or supported threat signal
A configured policy or supported threat signal says the request should not proceed without an explicit override path.
NO FORWARD
POLICY / FAILURE MODES

Fail safe when analysis degrades.

Unknown evidence must remain visibly unknown. Missing analysis must never silently become ALLOW.

UNSUPPORTED REQUEST

Do not guess. Preserve the request, expose the unsupported surface and require explicit review.

unsupported → REVIEW

SIMULATION UNAVAILABLE

Continue with static and contextual evidence, but make the missing simulation explicit.

simulation: unavailable → confidence: partial

INTENT MISMATCH

Treat a mismatch between stated intent and decoded authority as first-class evidence.

intent != authority → REVIEW/BLOCK policy

STALE CONTEXT

Time-sensitive intelligence needs freshness metadata so old observations cannot masquerade as current facts.

observedAt + ttl → freshness
INVARIANT

Unknown evidence must remain visibly unknown. Missing analysis must never silently become ALLOW.

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