UTXOSUITE — home
साइन करने से पहले ट्रांज़ैक्शन सुरक्षा

क्लिक के पीछे की authority देखें.

SafeSign wallet request और irreversible authorization के बीच review layer है। यह supported data decode करता है, execution context जोड़ता है, uncertainty दिखाता है और अंतिम निर्णय user के पास रखता है।

SAFESIGN / PRE-EXECUTIONLOCAL-FIRST
REQUESTeth_signTypedData_v4PermitSingle · spender 0x42…b8 · amount MAX
AUTHORITYPersistent token spend
CONTEXTNew spender · unknown
DESTINATION0x42…b8
SIMULATIONState-dependent
SIGN करने से पहले REVIEWREVIEW
SAFESIGN / PRE-SIGNATURE REVIEWएक अंधेरा operations room, जिसकी घुमावदार स्क्रीन-दीवार पर transaction graphs हैं।
एक अनुरोध पढ़ें

एक अकेली approval, टुकड़ों में।

यही वह अनुरोध है जिसे drainer आपसे हस्ताक्षरित कराना चाहता है। इसे समीक्षा परत से गुजारें और देखें कि प्रमाण आते ही निर्णय कैसे बदलता है।

wallet का कच्चा अनुरोधeth_sendTransaction from 0x9f1c…a034 (your account) to 0xA0b8…eB48 (USDC token contract) value 0 data 0x095ea7b3 000000000000000000000000c0ffee…b7d1 // spender ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff

यह परत क्या स्थापित करती है

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

अब भी अज्ञात

  • intent
  • authority
  • assets
  • duration
  • counterparty
UNKNOWN

मौजूदा निर्णयअज्ञात कभी सुरक्षित नहीं बनता। जो प्रमाण नहीं है, वह नहीं है।

परत 1/8

प्रकाशित समीक्षा अनुबंध का उदाहरणात्मक भ्रमण। दिखाया गया निर्णय वही है जो इस प्रमाण पर policy लौटाएगी।

एक हस्ताक्षर का रास्ता

हस्ताक्षर से पहले समझें।

हर अपरिवर्तनीय अनुमति एक ही रास्ते से गुजरती है। UTXO Suite हर चरण को पढ़ने योग्य बनाता है — और उस एक चरण पर रुक जाता है जो उसका कभी नहीं होना चाहिए: हस्ताक्षर।

  1. REQUEST

    कोई wallet, dApp या agent हस्ताक्षर मांगता है। अभी किसी पर भरोसा नहीं किया जाता।

    UTXO Suite
  2. NORMALIZE

    अनुरोध एक मानक रूप में डिकोड होता है: method, chain, origin, parameters।

    UTXO Suite
  3. INTENT

    अनुरोध वास्तव में क्या करता है, साफ शब्दों में: transfer, approval, delegation या permit।

    UTXO Suite
  4. CONTEXT · SIMULATION

    प्रतिपक्ष, स्रोत और अपेक्षित परिणाम। Simulation प्रमाण है, oracle कभी नहीं।

    UTXO Suite
  5. RISK

    भारित संकेत: असीमित अधिकार, अनजान code, अभी बने contracts, बेमेल गंतव्य।

    UTXO Suite
  6. POLICY

    आपके नियम उसी प्रमाण पर निर्धारित रूप से लागू: एक policy, अनुमान नहीं।

    UTXO Suite
  7. DECISION

    ALLOW, WARN, REVIEW या BLOCK। BLOCK को कोई दूसरी परत कभी नरम नहीं करती।

    UTXO Suite
  8. AUTHORIZATION

    आप स्पष्ट रूप से अनुमति देते हैं। ALLOW भी हस्ताक्षर नहीं है।

    आप
  9. PAYLOAD INTEGRITY

    जो bytes अभी हस्ताक्षरित होंगे, उनकी तुलना ठीक उन्हीं bytes से होती है जो आपने देखे थे।

    UTXO Suite
  10. SIGNER

    अलग-थलग signer wallet के भीतर है। UTXO Suite कभी key या seed नहीं रखता।

    Vigi Wallet
  11. BROADCAST

    वैकल्पिक। हस्ताक्षरित लेनदेन स्वतः प्रसारित लेनदेन नहीं होता।

    Vigi Wallet
  12. VERIFICATION

    chain पर वास्तव में जो हुआ, उसे आपसे किए गए वादे से मिलाया जाता है।

    UTXO Suite
ALLOWकुछ भी अनुरोध का खंडन नहीं करता। फिर भी आपकी स्पष्ट अनुमति चाहिए।
WARNआगे बढ़ने से पहले कुछ ध्यान देने योग्य है।
REVIEWआपके करीब से देखे बिना अनुरोध समझा नहीं जा सकता।
BLOCKमौजूदा policy में यह अनुरोध किसी signer तक नहीं पहुंचना चाहिए।

कोई भी निर्णय हस्ताक्षर नहीं है। अनुमति हमेशा आपकी है।

अज्ञात कभी सुरक्षित नहीं बनता। जो प्रमाण नहीं है, वह नहीं है।

REQUEST → DECODE → CONTEXT → DECISION

वास्तविक intent के आसपास बना security path.

SafeSign कोई magic risk score नहीं है। उपयोगी output यह बताता है कि क्या request हुआ, कौन-सी authority मिल सकती है और कौन-सी uncertainty अभी बाकी है।

01

Intercept

Keys की custody लिए बिना confirmation से पहले wallet request capture करता है।

02

Decode

Transactions, typed data, approvals, Permit/Permit2 और supported PSBT structures interpret करता है।

03

Context

Origin, chain, destination, spender, code path, simulation evidence और available policy signals compare करता है।

04

Decide

Consequences और uncertainty दिखाता है ताकि user स्पष्ट रूप से allow, review या reject कर सके।

DECISION-GRADE EVIDENCE

उन हिस्सों को inspect करें जो outcome बदल सकते हैं.

Evidence chain, request type और available context पर निर्भर है। जो verify नहीं हुआ उसे safe मानने के बजाय unknown रहना चाहिए।

01 / SIGNAL

Approvals और Permit2

Spender, token, amount, deadline और persistent spending authority expose करता है।

02 / SIGNAL

Destination और value

Chain, recipient, native value और payload destination के संबंध को verify करता है।

03 / SIGNAL

Contract execution

Methods decode करता है, resolvable proxy/delegatecall context दिखाता है और simulation को evidence मानता है, guarantee नहीं।

04 / SIGNAL

Bitcoin / PSBT

Supported PSBT inputs, outputs, change और fees inspect करके signing intent से तुलना करता है।

सीमाएँ

Evidence, guarantees नहीं.

Security तब खतरनाक होती है जब certainty को बढ़ा-चढ़ाकर दिखाया जाए। SafeSign को ज्ञात और अप्रमाणित चीज़ों में स्पष्ट अंतर रखना चाहिए।

SafeSign क्या कर सकता है

  • Authorization से पहले supported requests decode करना
  • Broad या persistent token authority expose करना
  • Origin, payload, destination और execution context combine करना
  • Missing या contradictory evidence को review के लिए escalate करना

SafeSign क्या promise नहीं कर सकता

  • Future execution के simulation जैसा होने की guarantee देना
  • Risk score से unverified contract को safe बना देना
  • Malicious authorization execute होने के बाद assets recover करना
  • Device security, procedures या human verification को replace करना
SAFESIGN / SECURITY CORE / ACADEMY

Irreversible हिस्से को सबसे समझने योग्य हिस्सा बनाइए.

SafeSign, Security Core और Academy एक principle साझा करते हैं: पहले inspect करें, consequence समझाएँ और execution user के explicit control में रखें।

SAFESIGN / THREAT MODEL

Signing request को संभावित adversarial object की तरह देखें।

Browser copy और wallet UI context हैं, proof नहीं। SafeSign को payload से authority reconstruct करके intent से compare करना चाहिए।

REQUEST TAXONOMY

हर signature एक जैसी authority नहीं देती।

Scoring से पहले classify करें। Transfers, approvals, EIP-712, Permit2, multicalls और PSBT के risks अलग हैं।

01

NATIVE TRANSFER

Chain, destination, native value, fees और intermediary contracts verify करें।

02

TOKEN APPROVAL

Allowance को durable future spending authority मानें; spender, scope और revoke inspect करें।

03

EIP-712 / PERMIT

Domain separator, verifying contract, chain, spender, amount, nonce और deadline inspect करें।

04

PERMIT2

Token permission, spender permission और signature deadline को साथ model करें।

05

CONTRACT / MULTICALL

Material subcalls, value movement और authority changes decode करें; top-level target पूरी execution story नहीं है।

06

BITCOIN PSBT

Inputs, outputs, change, fee, sighash और derivation metadata को intended payment से compare करें।

Evidence model

Independent signals से decision बनाएं।

Unknown evidence को स्पष्ट रूप से unknown रहना चाहिए। Missing analysis कभी चुपचाप ALLOW नहीं बनना चाहिए।

01CAPTURE

Confirmation से पहले exact request और origin लें।

02CLASSIFY

Generic risk logic से पहले request family पहचानें।

03DECODE

Methods, parameters, authority और destinations normalize करें।

04ENRICH

जहाँ उपलब्ध हो contract, policy, freshness और simulation context जोड़ें।

05COMPARE

Reconstructed authority को user के stated intent से compare करें।

06DECIDE

ALLOW, WARN, REVIEW या BLOCK स्पष्ट reasons और unknowns के साथ लौटाएं।

07AUTHORIZE

Control wallet या signer को लौटाएं। Analysis कभी silently sign या broadcast न करे।

Decision contract

Decision contract

Browser copy और wallet UI context हैं, proof नहीं। SafeSign को payload से authority reconstruct करके intent से compare करना चाहिए।

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 को स्पष्ट रूप से unknown रहना चाहिए। Missing analysis कभी चुपचाप ALLOW नहीं बनना चाहिए।

DECISION
TRIGGER
MEANING
NEXT
ALLOW
supported evidence consistent
Supported evidence में material contradiction नहीं मिला। Explicit authorization फिर भी जरूरी है।
EXPLICIT SIGN
WARN
material risk present
Request समझ में आता है, लेकिन authorization से पहले material risk दिखाना चाहिए।
USER REVIEW
REVIEW
incomplete or conflicting evidence
Evidence incomplete, contradictory या policy से बाहर है। Escalate करें।
SECOND REVIEW
BLOCK
policy or supported threat signal
Configured policy या threat signal request को explicit override के बिना आगे नहीं बढ़ने देता।
NO FORWARD
POLICY / FAILURE MODES

Analysis degrade हो तो fail-safe करें।

Unknown evidence को स्पष्ट रूप से unknown रहना चाहिए। Missing analysis कभी चुपचाप ALLOW नहीं बनना चाहिए।

UNSUPPORTED REQUEST

Guess न करें। Request preserve करें, unsupported surface दिखाएं और review मांगें।

unsupported → REVIEW

SIMULATION UNAVAILABLE

Static/context evidence जारी रखें, लेकिन missing simulation स्पष्ट करें।

simulation: unavailable → confidence: partial

INTENT MISMATCH

Intent और decoded authority mismatch को first-class evidence मानें।

intent != authority → REVIEW/BLOCK policy

STALE CONTEXT

Time-sensitive intelligence में freshness metadata जरूरी है ताकि पुराने observations current facts न लगें।

observedAt + ttl → freshness
INVARIANT

Unknown evidence को स्पष्ट रूप से unknown रहना चाहिए। Missing analysis कभी चुपचाप ALLOW नहीं बनना चाहिए।