SafeSign se está construyendo como capa de integración para wallets, fintech y aplicaciones onchain: decodificar lo solicitado, añadir contexto de seguridad, preservar el payload original y exigir una decisión explícita de autorización.
El contrato de producto es más estrecho que la antigua historia del ecosistema UTXO. Las integraciones deben exponer decisiones y evidencia de SafeSign, no mezclar productos de negocio, Office o ejecución dentro del límite de seguridad.
Contrato objetivo cliente/servidor para decodificar solicitudes compatibles, expresar intención, adjuntar evidencia y devolver recomendaciones ALLOW / WARN / REVIEW / BLOCK.
context + payload → evidence + decisionPrimitivas local-first de análisis y políticas reutilizables en SafeSign, Guard e integraciones de wallet sin custodia de claves ni autoridad de firma.
deterministic rules → explainable signalsSuperficie de navegador capaz de envolver solicitudes compatibles y presentar revisión SafeSign antes de reenviar la solicitud original sin cambios.
provider request → explicit continue / rejectLas políticas firmadas de organización, aprobaciones y controles de despliegue deben situarse sobre el núcleo de análisis y construirse tras estabilizar contrato y auditoría.
signed policy → organization decision constraintsLos compradores enterprise verificarán las afirmaciones. Por eso esta superficie separa artefactos actuales de capacidades de producción que aún necesitan validación, empaquetado o revisión independiente.
El modelo debe escalar desde integración self-service hasta despliegue enterprise contractual sin crear productos inconexos para cada segmento.
Evaluación self-service, contratos de referencia, análisis local y documentación. El objetivo es adopción antes de fricción de procurement.
EVALUATION / ADOPTIONIntegración por uso o contrato para wallets, fintech y productos onchain cuando las garantías de API sean medibles y soportables.
SDK / API REVENUEEnforcement de políticas, despliegue privado, evidencia para procurement, soporte y multi-approval forman la capa institucional de alto valor.
ANNUAL CONTRACT / PRIVATE DEPLOYMENTEl SDK/API deberá recibir contexto y un payload de firma sin modificar y devolver evidencia estructurada y una recomendación. La autoridad de firma sigue en la wallet o signer integrador.
// 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 integratorEl contrato de integración debe ser side-effect free por defecto: request entra, evidencia sale, payload original preservado y signer sigue siendo la autoridad.
Añade review en el límite fiable más estrecho en lugar de reconstruir transporte de wallet, custodia de claves o infraestructura de firma.
Intercepta métodos provider antes de confirmar y muestra evidencia sin sustituir la solicitud original.
Analiza después de construir la request y antes de invocar el signer; las claves quedan fuera del análisis.
Ejecuta evidencia y policy antes de enviar el paquete al signer o custody existente de la institución.
Trata la intención generada por máquinas como input no confiable; exige policy gates y escalado humano para acciones irreversibles o de alto valor.
Analiza el payload final, no sólo parámetros previos, para que cambios de encoding o routing no eviten la revisión.
Reutiliza el modelo de evidencia para observabilidad post-evento e incident triage sin conceder autoridad de firma.
La evidencia desconocida debe seguir siendo visible como desconocida. Un análisis ausente nunca debe convertirse silenciosamente en ALLOW.
Recibe la solicitud exacta y su origin antes de confirmar.
Identifica la familia de solicitud antes de aplicar lógica genérica de riesgo.
Normaliza métodos, parámetros, autoridad y destinos.
Añade contexto de contrato, policy, frescura y simulación cuando exista.
Compara la autoridad reconstruida con la intención declarada por el usuario.
Devuelve ALLOW, WARN, REVIEW o BLOCK con razones e incógnitas explícitas.
Devuelve el control a la wallet o signer. El análisis nunca firma ni transmite silenciosamente.
El contrato de integración debe ser side-effect free por defecto: request entra, evidencia sale, payload original preservado y signer sigue siendo la autoridad.
{
"requestType": "eip712",
"origin": "https://app.example",
"chainId": 1,
"method": "eth_signTypedData_v4",
"intent": { "action": "swap", "asset": "USDC" },
"payload": "<original wallet payload>"
}{
"decision": "REVIEW",
"confidence": "partial",
"authority": [{ "type": "token_spend", "scope": "unlimited" }],
"evidence": [{ "signal": "new_spender", "severity": "high" }],
"unknowns": ["future_execution_state"],
"payloadIntegrity": "unchanged"
}La evidencia desconocida debe seguir siendo visible como desconocida. Un análisis ausente nunca debe convertirse silenciosamente en ALLOW.
La evidencia desconocida debe seguir siendo visible como desconocida. Un análisis ausente nunca debe convertirse silenciosamente en ALLOW.
No adivines. Preserva la solicitud, expone lo no soportado y exige revisión explícita.
unsupported → REVIEWContinúa con evidencia estática y contextual, indicando claramente que falta simulación.
simulation: unavailable → confidence: partialTrata el desajuste entre intención y autoridad decodificada como evidencia de primer nivel.
intent != authority → REVIEW/BLOCK policyLa inteligencia sensible al tiempo necesita freshness metadata para que observaciones antiguas no parezcan hechos actuales.
observedAt + ttl → freshnessLa integración debe fallar de forma visible, preservar la integridad del payload, exponer estados no soportados y nunca convertir un fallo de análisis en aprobación implícita.