UTXOSUITE — home
SECURITY CORE / MOTOR LOCAL-FIRST

Transforme pedidos da wallet em contexto de segurança.

Security Core é a camada reutilizável de análise e políticas por trás do SafeSign. Decodifica, compara intenção e payload, expõe autoridade e incerteza e deixa a execução sob controle explícito do usuário.

Abrir SafeSignVer documentação
SECURITY CORE / ANALYSIS ENGINEUm processador sob luz de laboratório, cablado para medição.
MODELO DE CAPACIDADES

Evidência, não pontuações mágicas.

Nenhum detector é tratado como oráculo e evidência indisponível nunca deve virar permissão silenciosa.

01

INTENT

Decodificar intenção e calldata.

02

AUTHORITY

Expor approvals, Permit e Permit2.

03

DESTINATION

Inspecionar destinos, chain context e contratos.

04

SIMULATION

Comparar simulação e execução mutável.

05

POLICY

Aplicar políticas determinísticas.

06

EXPLANATION

Gerar evidência legível para a decisão final.

PIPELINE DE ANÁLISE

Pedido → decode → contexto → decisão.

Separa interpretação de autorização sem custodiar chaves ou transmitir transações.

01

PEDIDO

Receber o pedido e o contexto disponível.

02

DECODE

Normalizar métodos, parâmetros, typed data, approvals e PSBT suportados.

03

CONTEXTO

Adicionar policy, simulation, destination e execution context quando disponíveis.

04

DECISÃO

Explicar risco e incerteza; o usuário mantém a autorização.

LIMITE DE CONFIANÇA

Útil sem virar custodial.

Analisar e explicar; signing authority fica fora do Security Core.

O que pode processar

Pedidos, typed data, approvals, endereços, simulações e contexto de política.

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

O que não precisa

Seed, custódia de private key, auto-sign, auto-broadcast ou execução unilateral.

Keysnever required
Signingexplicit user boundary
Broadcastoutside the engine
O CAMINHO DE UMA ASSINATURA

Entenda antes de assinar.

Toda autorização irreversível percorre o mesmo caminho. O UTXO Suite torna cada passo legível — e para no único que nunca deve possuir: a assinatura.

  1. REQUEST

    Uma wallet, uma dApp ou um agente pede uma assinatura. Ainda não se confia em nada.

    UTXO Suite

  2. NORMALIZE

    O pedido é descodificado numa forma canónica: método, cadeia, origem, parâmetros.

    UTXO Suite

  3. INTENT

    O que o pedido faz de facto, em claro: uma transferência, uma aprovação, uma delegação, um permit.

    UTXO Suite

  4. CONTEXT · SIMULATION

    Contraparte, proveniência e resultado esperado. A simulação é evidência, nunca um oráculo.

    UTXO Suite

  5. RISK

    Sinais ponderados: autoridade ilimitada, código desconhecido, contratos acabados de criar, destinos que não batem certo.

    UTXO Suite

  6. POLICY

    As suas regras aplicadas de forma determinista sobre essa evidência: uma política, não uma intuição.

    UTXO Suite

  7. DECISION

    ALLOW, WARN, REVIEW ou BLOCK. Um BLOCK nunca é suavizado por outra camada.

    UTXO Suite

  8. AUTHORIZATION

    Você autoriza explicitamente. Nem um ALLOW é uma assinatura.

    Você

  9. PAYLOAD INTEGRITY

    Os bytes prestes a ser assinados são comparados com os bytes exactos que reviu.

    UTXO Suite

  10. SIGNER

    O assinante isolado vive dentro da wallet. O UTXO Suite nunca guarda uma chave nem uma seed.

    Vigi Wallet

  11. BROADCAST

    Opcional. Uma transacção assinada não é automaticamente uma transacção difundida.

    Vigi Wallet

  12. VERIFICATION

    O que aconteceu mesmo na cadeia é confrontado com o que lhe foi prometido.

    UTXO Suite
ALLOWNada contradiz o pedido. Continua a precisar da sua autorização explícita.
WARNHá algo que merece atenção antes de continuar.
REVIEWO pedido não pode ser entendido sem que o observe de perto.
BLOCKO pedido não deve chegar a um assinante com a política actual.

Nenhuma decisão é uma assinatura. A autorização é sempre sua.

O desconhecido nunca passa a seguro. A evidência que falta continua a faltar.

Uma camada de segurança deve melhorar a decisão, não apagá-la.

SafeSign é a superfície humana; Security Core é o motor reutilizável.

Explorar SafeSign →
SECURITY CORE / MODELO INTERNO

Um motor determinístico deve expor por que chegou à decisão.

Security Core deve modelar um grafo de evidência: fatos, provenance, freshness, policy, contradições e unknowns, não um score opaco.

PRIMITIVAS DO MOTOR

Primitivas pequenas compõem decisões mais fortes.

Cada primitiva deve emitir evidência estruturada com provenance para policy raciocinar sobre fatos.

01

NORMALIZER

Converta requests específicos em representação interna estável sem alterar payload.

02

AUTHORITY EXTRACTOR

Descreva o que a assinatura pode autorizar agora ou depois: value, token spend, ordem, delegação ou PSBT.

03

CONTEXT RESOLVER

Adicione origin, chain, relações de contrato, freshness, simulation e intelligence com provenance.

04

RULE EVALUATOR

Avalie condições determinísticas como unlimited approval, new destination, value threshold ou chain mismatch.

05

EVIDENCE GRAPH

Preserve fatos, source, timestamps, contradições e dependências para reconstruir cada decisão.

06

DECISION EXPLAINER

Traduza evidência estruturada em consequências sem esconder incerteza atrás de um score.

Modelo de evidência

Construa uma decisão com sinais independentes.

Evidência desconhecida deve continuar claramente desconhecida. Falha de análise nunca vira ALLOW silencioso.

01CAPTURE

Receba o request exato e origin antes da confirmação.

02CLASSIFY

Identifique a família antes de aplicar lógica genérica.

03DECODE

Normalize métodos, parâmetros, autoridade e destinos.

04ENRICH

Adicione contexto de contrato, policy, freshness e simulação quando disponível.

05COMPARE

Compare a autoridade reconstruída com a intenção declarada.

06DECIDE

Retorne ALLOW, WARN, REVIEW ou BLOCK com razões e unknowns explícitos.

07AUTHORIZE

Devolva controle à wallet ou signer. A análise nunca assina ou transmite silenciosamente.

Contrato de decisão

Contrato de decisão

Security Core deve modelar um grafo de evidência: fatos, provenance, freshness, policy, contradições e unknowns, não um 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 decisão

Semântica de decisão

Evidência desconhecida deve continuar claramente desconhecida. Falha de análise nunca vira ALLOW silencioso.

DECISION
TRIGGER
MEANING
NEXT
ALLOW
supported evidence consistent
Sem contradição material na evidência suportada. Autorização explícita continua necessária.
EXPLICIT SIGN
WARN
material risk present
O pedido é compreendido, mas o risco material deve ser mostrado antes da autorização.
USER REVIEW
REVIEW
incomplete or conflicting evidence
A evidência é incompleta, contraditória ou fora da policy. Escale.
SECOND REVIEW
BLOCK
policy or supported threat signal
Uma policy configurada ou threat signal indica que não deve prosseguir sem override explícito.
NO FORWARD
POLICY / FAILURE MODES

Falhe de forma segura quando a análise degrada.

Evidência desconhecida deve continuar claramente desconhecida. Falha de análise nunca vira ALLOW silencioso.

UNSUPPORTED REQUEST

Não adivinhe. Preserve o request, exponha o que não é suportado e exija review.

unsupported → REVIEW

SIMULATION UNAVAILABLE

Continue com evidência estática e contextual, deixando a falta de simulação explícita.

simulation: unavailable → confidence: partial

INTENT MISMATCH

Trate divergência entre intenção e autoridade decodificada como evidência principal.

intent != authority → REVIEW/BLOCK policy

STALE CONTEXT

Inteligência temporal precisa de freshness metadata para que observações antigas não pareçam atuais.

observedAt + ttl → freshness
INVARIANT

Cada sinal material deve ter provenance, freshness e distinção entre fato determinístico, heurística e intelligence externa.

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