UTXOSUITE — home
SECURITY CORE / LOCAL-FIRST ENGINE

Turn raw wallet requests into security context.

Security Core is the reusable analysis and policy layer behind SafeSign and transaction-security integrations. It decodes what can be decoded, compares intent with payload, surfaces authority and uncertainty, and leaves execution under explicit user control.

Open SafeSignView developer docs
SECURITY CORE / ANALYSIS ENGINEA processor under laboratory light, wired for measurement.
CAPABILITY MODEL

Evidence, not magic scores.

Security Core is designed around composable signals. No single detector is treated as an oracle, and unavailable evidence should never become a silent allow.

01

INTENT

Decode transaction intent and calldata.

02

AUTHORITY

Expose token approvals, Permit and Permit2 scope.

03

DESTINATION

Inspect destinations, chain context and contract relationships.

04

SIMULATION

Compare simulations with mutable execution assumptions.

05

POLICY

Apply deterministic policy and escalation rules.

06

EXPLANATION

Produce human-readable evidence for a final user decision.

ANALYSIS PIPELINE

Request → decode → context → decision.

The engine separates interpretation from authorization. It can assist a wallet, browser surface or developer integration without taking the user's keys or broadcasting transactions.

01

REQUEST

Receive the wallet request and the context available at the integration boundary.

02

DECODE

Normalize methods, parameters, typed data, approvals and supported PSBT structures.

03

CONTEXT

Enrich with policy, simulation, destination and execution-context signals where available.

04

DECISION

Explain material risk and uncertainty; the user or calling product remains the authorization boundary.

TRUST BOUNDARY

Useful without becoming a custodian.

The product contract is deliberately narrow: analyze and explain. Signing authority remains outside Security Core.

What it may process

Transaction requests, typed data, approvals, addresses, simulation outputs and policy context supplied by the integration.

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

What it does not need

Seed phrases, private-key custody, automatic signing, automatic broadcast or unilateral transaction execution.

Keysnever required
Signingexplicit user boundary
Broadcastoutside the engine
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.

A security layer should make the decision better — not make the decision disappear.

SafeSign is the human review surface. Security Core is the reusable engine underneath it.

Explore SafeSign →
SECURITY CORE / INTERNAL MODEL

A deterministic engine should expose why it reached a decision.

Security Core should model an evidence graph: decoded facts, provenance, freshness, policy matches, contradictions and unknowns—not a single opaque risk score.

ENGINE PRIMITIVES

Small primitives compose into stronger decisions.

Each primitive should emit structured evidence with provenance and confidence so downstream policy reasons about facts rather than UI strings.

01

NORMALIZER

Convert chain-specific requests into a stable internal representation without mutating the original payload.

02

AUTHORITY EXTRACTOR

Describe what the signature can authorize now or later: value transfer, token spend, order execution, delegation or PSBT spend.

03

CONTEXT RESOLVER

Attach origin, chain, contract relationships, freshness, simulation and intelligence with source provenance.

04

RULE EVALUATOR

Evaluate deterministic conditions such as unlimited approval, new destination, value threshold or chain mismatch.

05

EVIDENCE GRAPH

Retain facts, source, timestamps, contradictions and dependencies so every decision can be reconstructed later.

06

DECISION EXPLAINER

Translate structured evidence into consequences without hiding uncertainty behind a score.

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

Security Core should model an evidence graph: decoded facts, provenance, freshness, policy matches, contradictions and unknowns—not a single opaque risk 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"
}
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

Every material signal used in a decision should carry provenance, freshness and a clear distinction between deterministic fact, heuristic and external intelligence.

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