UTXOSUITE — home
UTXO GUARD / BROWSER SECURITY

Intercept risky wallet requests before they become blind clicks.

Guard is the browser-side integration surface for SafeSign. The current repository contains a Manifest V3 foundation that wraps wallet-provider requests, keeps non-sensitive preferences locally and waits for an explicit continue or reject decision.

SOURCE SCAFFOLD / MANIFEST V3
UTXO GUARD / BROWSER BOUNDARYA small isolated signing device on a desk, connected by a single cable.
CURRENT SURFACE

What exists in the current product surface.

The source scaffold exists; a production extension build pipeline is still required before this should be described as a finished browser extension.

01

Provider request guard

Wrap supported ethereum.request calls in the page context.

02

Local preferences

Store only non-sensitive enablement, strict-mode and allowlist preferences.

03

SafeSign overlay

Present a human-readable continue/reject review before forwarding the unchanged request.

04

Fail-safe behavior

Prefer warning and explicit fallback over hidden approval if analysis or interception fails.

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.

Security boundary

UTXO Guard

Guard may observe supported wallet requests and local non-sensitive settings. It must not store private keys, seed phrases, raw signatures or full transaction history.

Next integration boundary

SafeSign

The extension build should route supported requests through SafeSign, preserve the original payload unchanged and prefer warning/fallback behavior over silently authorizing anything.

Open SafeSignAll products
UTXO GUARD / EXTENSION BOUNDARY

Intercept requests without becoming the wallet.

Guard sits between the web application and wallet provider. It observes the exact provider request, attaches SafeSign context and forwards only after explicit continuation.

01DAPP

Initiates provider request.

02INTERCEPT

Capture method, origin and payload before wallet UI.

03SAFESIGN

Decode authority, context and unknowns.

04REVIEW

Explain consequence and require explicit continue/cancel.

05WALLET

Original provider remains signing authority.

COMPONENT BOUNDARIES

SYSTEM ARCHITECTURE

Current source provides the extension/UI surface. End-to-end interception and SafeSign enforcement still require validation against real wallet providers before production claims.

COMPONENT
READS
WRITES
FORBIDDEN
CONTENT SCRIPT
origin · provider method
review request
seed · key · sign
SAFESIGN ADAPTER
payload · origin · context
decision · evidence
mutate payload
REVIEW UI
decision · evidence
continue / cancel
auto-approve
WALLET PROVIDER
original payload
wallet-specific signing flow
bypass review after mutation
REQUEST / RESULT CONTRACT

INPUT → REVIEW → RESULT

Guard sits between the web application and wallet provider. It observes the exact provider request, attaches SafeSign context and forwards only after explicit continuation.

REQUEST / INPUT
{
  "origin":"https://app.example",
  "method":"eth_signTypedData_v4",
  "payloadHash":"sha256:...",
  "request":{"primaryType":"PermitSingle"}
}
DECISION / RESULT
{
  "decision":"REVIEW",
  "reasonCodes":["UNLIMITED_AUTHORITY","NEW_SPENDER"],
  "payloadHash":"sha256:...",
  "forwardAllowed":false
}
SECURITY INVARIANTS

CURRENT STATE

Current source provides the extension/UI surface. End-to-end interception and SafeSign enforcement still require validation against real wallet providers before production claims.

01

NO KEY CUSTODY

Analysis must not require seed phrases or private-key custody.

02

NO SILENT SIGN

Review must never become an implicit signature, approval or broadcast.

03

PAYLOAD INTEGRITY

The payload finally authorized must match the payload that was reviewed; any mutation requires a new review.

04

VISIBLE FAILURE

Unsupported methods, missing context and failed analysis must remain visible instead of degrading to ALLOW.

CURRENT STATE

Current source provides the extension/UI surface. End-to-end interception and SafeSign enforcement still require validation against real wallet providers before production claims.