UTXOSUITE — home
SECURITY CORE / MOTOR LOCAL-FIRST

Convierte solicitudes de wallet en contexto de seguridad.

Security Core es la capa reutilizable de análisis y políticas detrás de SafeSign y las integraciones de seguridad transaccional. Decodifica lo que puede, compara intención y payload, expone autoridad e incertidumbre y mantiene la ejecución bajo control explícito del usuario.

Abrir SafeSignVer documentación
SECURITY CORE / ANALYSIS ENGINEUn procesador bajo luz de laboratorio, cableado para medición.
MODELO DE CAPACIDADES

Evidencia, no puntuaciones mágicas.

Security Core trabaja con señales combinables. Ningún detector se trata como un oráculo y la evidencia ausente nunca debe convertirse en un permiso silencioso.

01

INTENT

Decodifica intención y calldata.

02

AUTHORITY

Expone approvals, Permit y Permit2.

03

DESTINATION

Inspecciona destinos, cadena y relaciones entre contratos.

04

SIMULATION

Contrasta simulaciones con condiciones de ejecución mutables.

05

POLICY

Aplica políticas deterministas y reglas de escalado.

06

EXPLANATION

Genera evidencia legible para la decisión final del usuario.

PIPELINE DE ANÁLISIS

Solicitud → decode → contexto → decisión.

El motor separa interpretación y autorización. Puede asistir a una wallet, navegador o integración sin tomar claves ni hacer broadcast.

01

SOLICITUD

Recibe la solicitud y el contexto disponible en el límite de integración.

02

DECODE

Normaliza métodos, parámetros, typed data, approvals y PSBT compatibles.

03

CONTEXTO

Añade políticas, simulación, destino y señales de execution context cuando existen.

04

DECISIÓN

Explica riesgo material e incertidumbre; el usuario o producto llamante conserva la autorización.

LÍMITE DE CONFIANZA

Útil sin convertirse en custodio.

El contrato del producto es deliberadamente estrecho: analizar y explicar. La autoridad de firma permanece fuera de Security Core.

Qué puede procesar

Solicitudes, typed data, approvals, direcciones, resultados de simulación y contexto de políticas aportado por la integración.

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

Qué no necesita

Seeds, custodia de claves privadas, firma automática, broadcast automático ni ejecución unilateral.

Keysnever required
Signingexplicit user boundary
Broadcastoutside the engine
EL CAMINO DE UNA FIRMA

Entiende antes de firmar.

Toda autorización irreversible recorre el mismo camino. UTXO Suite hace legible cada paso — y se detiene en el único que nunca debe poseer: la firma.

  1. REQUEST

    Una wallet, una dApp o un agente pide una firma. Todavía no se confía en nada.

    UTXO Suite

  2. NORMALIZE

    La petición se descodifica a una forma canónica: método, cadena, origen, parámetros.

    UTXO Suite

  3. INTENT

    Qué hace realmente la petición, en claro: una transferencia, una aprobación, una delegación, un permiso.

    UTXO Suite

  4. CONTEXT · SIMULATION

    Contraparte, procedencia y resultado esperado. La simulación es evidencia, nunca un oráculo.

    UTXO Suite

  5. RISK

    Señales ponderadas: autoridad ilimitada, código desconocido, contratos recién creados, destinos que no cuadran.

    UTXO Suite

  6. POLICY

    Tus reglas aplicadas de forma determinista sobre esa evidencia: una política, no una intuición.

    UTXO Suite

  7. DECISION

    ALLOW, WARN, REVIEW o BLOCK. Un BLOCK jamás lo suaviza otra capa.

    UTXO Suite

  8. AUTHORIZATION

    Autorizas de forma explícita. Ni siquiera un ALLOW es una firma.

    Tú

  9. PAYLOAD INTEGRITY

    Los bytes que se van a firmar se comparan con los bytes exactos que revisaste.

    UTXO Suite

  10. SIGNER

    El firmante aislado vive dentro de la wallet. UTXO Suite nunca guarda una clave ni una semilla.

    Vigi Wallet

  11. BROADCAST

    Opcional. Una transacción firmada no es automáticamente una transacción difundida.

    Vigi Wallet

  12. VERIFICATION

    Lo que ocurrió de verdad en la cadena se contrasta con lo que se te prometió.

    UTXO Suite
ALLOWNada contradice la petición. Aun así necesita tu autorización explícita.
WARNHay algo que merece atención antes de continuar.
REVIEWLa petición no puede entenderse sin que la mires de cerca.
BLOCKLa petición no debe llegar a un firmante con la política actual.

Ninguna decisión es una firma. La autorización siempre es tuya.

Lo desconocido nunca pasa a ser seguro. La evidencia que falta sigue faltando.

Una capa de seguridad debe mejorar la decisión, no hacer que desaparezca.

SafeSign es la superficie humana. Security Core es el motor reutilizable que hay debajo.

Explorar SafeSign →
SECURITY CORE / MODELO INTERNO

Un motor determinista debe exponer por qué llegó a una decisión.

Security Core debe modelar un grafo de evidencia: hechos decodificados, procedencia, frescura, coincidencias de policy, contradicciones e incógnitas; no un único risk score opaco.

PRIMITIVAS DEL MOTOR

Primitivas pequeñas se combinan en decisiones más fuertes.

Cada primitiva debe emitir evidencia estructurada con procedencia y confianza para que policy razone sobre hechos, no strings de UI.

01

NORMALIZER

Convierte requests específicos de red a una representación interna estable sin modificar el payload original.

02

AUTHORITY EXTRACTOR

Describe qué puede autorizar la firma ahora o después: valor, token spend, ejecución de órdenes, delegación o gasto PSBT.

03

CONTEXT RESOLVER

Adjunta origin, red, relaciones de contrato, frescura, simulación e inteligencia con procedencia de fuente.

04

RULE EVALUATOR

Evalúa condiciones deterministas como approval ilimitado, destino nuevo, umbral de valor o chain mismatch.

05

EVIDENCE GRAPH

Conserva hechos, fuente, timestamps, contradicciones y dependencias para reconstruir cada decisión.

06

DECISION EXPLAINER

Traduce evidencia estructurada a consecuencias sin ocultar incertidumbre detrás de un score.

Modelo de evidencia

Construye una decisión con señales independientes.

La evidencia desconocida debe seguir siendo visible como desconocida. Un análisis ausente nunca debe convertirse silenciosamente en ALLOW.

01CAPTURE

Recibe la solicitud exacta y su origin antes de confirmar.

02CLASSIFY

Identifica la familia de solicitud antes de aplicar lógica genérica de riesgo.

03DECODE

Normaliza métodos, parámetros, autoridad y destinos.

04ENRICH

Añade contexto de contrato, policy, frescura y simulación cuando exista.

05COMPARE

Compara la autoridad reconstruida con la intención declarada por el usuario.

06DECIDE

Devuelve ALLOW, WARN, REVIEW o BLOCK con razones e incógnitas explícitas.

07AUTHORIZE

Devuelve el control a la wallet o signer. El análisis nunca firma ni transmite silenciosamente.

Contrato de decisión

Contrato de decisión

Security Core debe modelar un grafo de evidencia: hechos decodificados, procedencia, frescura, coincidencias de policy, contradicciones e incógnitas; no un único risk score opaco.

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"
}
Semántica de decisión

Semántica de decisión

La evidencia desconocida debe seguir siendo visible como desconocida. Un análisis ausente nunca debe convertirse silenciosamente en ALLOW.

DECISION
TRIGGER
MEANING
NEXT
ALLOW
supported evidence consistent
No se detecta contradicción material dentro de la evidencia soportada. Sigue siendo necesaria autorización explícita.
EXPLICIT SIGN
WARN
material risk present
La solicitud se entiende, pero el usuario debe ver el riesgo material antes de autorizar.
USER REVIEW
REVIEW
incomplete or conflicting evidence
La evidencia es incompleta, contradictoria o queda fuera de policy. Escala en lugar de fingir certeza.
SECOND REVIEW
BLOCK
policy or supported threat signal
Una policy configurada o señal soportada indica que la solicitud no debe continuar sin una vía explícita de override.
NO FORWARD
POLICY / FAILURE MODES

Falla de forma segura cuando el análisis se degrada.

La evidencia desconocida debe seguir siendo visible como desconocida. Un análisis ausente nunca debe convertirse silenciosamente en ALLOW.

UNSUPPORTED REQUEST

No adivines. Preserva la solicitud, expone lo no soportado y exige revisión explícita.

unsupported → REVIEW

SIMULATION UNAVAILABLE

Continúa con evidencia estática y contextual, indicando claramente que falta simulación.

simulation: unavailable → confidence: partial

INTENT MISMATCH

Trata el desajuste entre intención y autoridad decodificada como evidencia de primer nivel.

intent != authority → REVIEW/BLOCK policy

STALE CONTEXT

La inteligencia sensible al tiempo necesita freshness metadata para que observaciones antiguas no parezcan hechos actuales.

observedAt + ttl → freshness
INVARIANT

Cada señal material usada en una decisión debe tener procedencia, frescura y una distinción clara entre hecho determinista, heurística e inteligencia externa.

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