UTXOSUITE — home
PLATAFORMA PARA DESENVOLVEDORES

Integre segurança transacional ao fluxo de assinatura.

SafeSign está sendo construído como camada de integração para wallets, fintechs e apps onchain: decodificar o pedido, adicionar contexto, preservar o payload e exigir decisão explícita.

Ver arquitetura ↗Falar de integração →
SAFESIGN / PRE-PRODUCTIONNON-CUSTODIALEXPLICIT AUTHORIZATION14 LOCALES
DEVELOPERS / INTEGRATION SURFACEUm posto de desenvolvimento numa sala escura, com dois ecrãs abertos em código.
SUPERFÍCIES DE INTEGRAÇÃO

Um motor, várias formas de integrar.

O contrato do produto é mais estreito que a antiga narrativa UTXO. Integrações devem expor decisões e evidências do SafeSign, sem misturar produtos de negócio ou Office.

01CONTRACT STABILIZATION

SafeSign Decision SDK

Contrato cliente/servidor para decodificar requests, expressar intenção, anexar evidência e retornar ALLOW / WARN / REVIEW / BLOCK.

context + payload → evidence + decision
02SOURCE PRIMITIVES

Security Core

Primitivas local-first de análise e políticas reutilizáveis em SafeSign, Guard e wallets sem custódia de chaves ou autoridade de assinatura.

deterministic rules → explainable signals
03MV3 SOURCE SCAFFOLD

UTXO Guard

Superfície browser que envolve requests compatíveis e apresenta SafeSign antes de encaminhar o pedido original intacto.

provider request → explicit continue / reject
04PLANNED

Enterprise Policy

Políticas assinadas, aprovações e controles enterprise ficam acima do core e devem ser construídos após estabilizar contrato e auditoria.

signed policy → organization decision constraints
LIMITE DE EVIDÊNCIA

Dizer exatamente o que existe.

Compradores enterprise verificarão as afirmações. Por isso a superfície separa artefatos atuais de capacidades de produção que ainda exigem validação ou revisão independente.

CURRENT

Evidência atual do repositório

  • Uma superfície SafeSign focada e arquitetura de segurança transacional.
  • Conceitos do Security Core para decoding, regras, validação e limites de políticas.
  • Scaffold Manifest V3 do Guard e modelo explícito continuar/rejeitar.
NOT YET

Ainda não é claim de produção

  • Nenhum SLA de produção publicado ou auditoria independente verificada é afirmado aqui.
  • Não vender cobertura universal, threat network em tempo real ou garantia sub-second antes de medir.
  • Packaging da API, autenticação, quotas, billing e contratos de suporte ainda precisam ser concluídos.
VIAS COMERCIAIS

Monetizar o mesmo núcleo de segurança em diferentes profundidades.

O modelo deve escalar de self-service a enterprise contratual sem criar produtos desconectados para cada segmento.

01

Developer

Avaliação self-service, contratos de referência, análise local e docs para adoção antes do procurement.

EVALUATION / ADOPTION
02

Product

Integração por uso ou contrato para wallets, fintechs e produtos onchain quando garantias da API forem mensuráveis.

SDK / API REVENUE
03

Enterprise

Policy enforcement, private deployment, evidência para procurement, suporte e multi-approval formam a camada institucional.

ANNUAL CONTRACT / PRIVATE DEPLOYMENT
CONTRATO-ALVO

Uma interface estável de decisão, não outra wallet.

O SDK/API deverá receber contexto e payload intacto, retornando evidência estruturada e recomendação. A autoridade de assinatura permanece na wallet integradora.

SAFESIGN / DECISION CONTRACTILLUSTRATIVE TARGET
// Target interface — illustrative, not a published package
const review = await safeSign.review({
  origin,
  chainId,
  method,
  payload,        // preserved unchanged
  expectedIntent, // optional user/app intent
});

review.decision // ALLOW | WARN | REVIEW | BLOCK
review.evidence // structured, explainable signals
review.payload  // same signing payload supplied by integrator
SafeSign →Security Core →UTXO Guard →Falar de integração →
DEVELOPERS / CONTRATO DE INTEGRAÇÃO

Integre review sem ceder a fronteira de assinatura.

O contrato deve ser side-effect free: request entra, evidência sai, payload preservado e signer continua authoritative.

SUPERFÍCIES DE INTEGRAÇÃO

Comece onde o pedido de assinatura já existe.

Adicione review no boundary confiável mais estreito sem reconstruir transport, custody ou signing.

01

WALLET EXTENSION

Intercepte provider methods antes da confirmação e mostre evidência sem substituir o request original.

02

EMBEDDED WALLET

Analise após construir o request e antes de invocar signer; keys ficam fora da análise.

03

FINTECH APPROVAL FLOW

Execute evidência e policy antes de enviar o pacote ao signer/custody existente.

04

AGENT / AUTOMATION

Trate machine intent como input não confiável; exija policy gates e human escalation para ações irreversíveis ou high-value.

05

TRANSACTION BUILDER

Analise o payload final, não só parâmetros prévios, para que encoding/routing não contornem review.

06

READ-ONLY MONITORING

Reutilize o evidence model para observability e incident triage sem conceder signing authority.

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

O contrato deve ser side-effect free: request entra, evidência sai, payload preservado e signer continua authoritative.

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

Integração deve falhar visivelmente, preservar payload, expor unsupported states e nunca transformar analysis failure em approval implícito.

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