UTXOSUITE — home
SECURITY CORE / LOCAL-FIRST ENGINE

Wallet requests को उपयोगी security context में बदलें।

Security Core, SafeSign और transaction-security integrations के पीछे reusable analysis और policy layer है। यह request को decode करता है, intent को payload से मिलाता है, authority और uncertainty दिखाता है और execution को user के explicit control में छोड़ता है।

SECURITY CORE / ANALYSIS ENGINEप्रयोगशाला की रोशनी में एक processor, माप के लिए जुड़ा हुआ।
CAPABILITY MODEL

Evidence, कोई जादुई score नहीं।

किसी detector को oracle नहीं माना जाता और missing evidence कभी silent allow नहीं बनना चाहिए।

01

INTENT

Transaction intent और calldata decode करें।

02

AUTHORITY

Approvals, Permit और Permit2 scope दिखाएँ।

03

DESTINATION

Destinations, chain context और contract relationships inspect करें।

04

SIMULATION

Simulation को mutable execution assumptions से compare करें।

05

POLICY

Deterministic policies और escalation rules लागू करें।

06

EXPLANATION

Final user decision के लिए readable evidence बनाएँ।

ANALYSIS PIPELINE

Request → decode → context → decision.

Engine interpretation को authorization से अलग रखता है और keys लेने या auto-broadcast किए बिना integrations की सहायता करता है।

01

REQUEST

Wallet request और उपलब्ध integration context प्राप्त करें।

02

DECODE

Methods, parameters, typed data, approvals और supported PSBT को normalize करें।

03

CONTEXT

Policy, simulation, destination और execution-context signals जोड़ें।

04

DECISION

Material risk और uncertainty समझाएँ; authorization user या calling product के पास रहे।

TRUST BOUNDARY

Custodian बने बिना उपयोगी।

Product contract सीमित है: analyze और explain. Signing authority Security Core के बाहर रहती है।

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

Requests, typed data, approvals, addresses, simulation outputs और integration से मिला policy context.

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

इसे क्या नहीं चाहिए

Seed phrases, private-key custody, auto-sign, auto-broadcast या unilateral transaction execution.

Keysnever required
Signingexplicit user boundary
Broadcastoutside the engine
एक हस्ताक्षर का रास्ता

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

हर अपरिवर्तनीय अनुमति एक ही रास्ते से गुजरती है। 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 तक नहीं पहुंचना चाहिए।

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

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

Security layer को decision बेहतर बनाना चाहिए, decision को गायब नहीं करना चाहिए।

SafeSign human review surface है; Security Core उसके नीचे reusable engine है।

SafeSign देखें
SECURITY CORE / INTERNAL MODEL

Deterministic engine को बताना चाहिए कि decision क्यों आया।

Security Core को evidence graph model करना चाहिए: facts, provenance, freshness, policy matches, contradictions और unknowns; single opaque score नहीं।

ENGINE PRIMITIVES

Small primitives मिलकर stronger decisions बनाते हैं।

हर primitive structured evidence + provenance दे ताकि policy UI strings नहीं, facts पर reason करे।

01

NORMALIZER

Chain-specific requests को stable internal representation में बदलें, payload mutate किए बिना।

02

AUTHORITY EXTRACTOR

बताएं signature अभी या बाद में क्या authorize कर सकती है: value, token spend, order, delegation या PSBT।

03

CONTEXT RESOLVER

Origin, chain, contract relationships, freshness, simulation और intelligence को source provenance के साथ जोड़ें।

04

RULE EVALUATOR

Unlimited approval, new destination, value threshold या chain mismatch जैसे deterministic conditions evaluate करें।

05

EVIDENCE GRAPH

Facts, source, timestamps, contradictions और dependencies retain करें ताकि हर decision reconstruct हो सके।

06

DECISION EXPLAINER

Structured evidence को consequences में translate करें, uncertainty को score के पीछे छिपाए बिना।

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

Security Core को evidence graph model करना चाहिए: facts, provenance, freshness, policy matches, contradictions और unknowns; single opaque 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 को स्पष्ट रूप से 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

हर material signal में provenance, freshness और deterministic fact, heuristic तथा external intelligence का स्पष्ट distinction होना चाहिए।