UTXOSUITE — home
PIATTAFORMA SVILUPPATORI

Integra la sicurezza transazionale nel flusso di firma.

SafeSign viene costruito come livello di integrazione per wallet, fintech e app onchain: decodificare la richiesta, aggiungere contesto, preservare il payload e richiedere una decisione esplicita.

Vedi architettura ↗Parla di integrazione →
SAFESIGN / PRE-PRODUCTIONNON-CUSTODIALEXPLICIT AUTHORIZATION14 LOCALES
DEVELOPERS / INTEGRATION SURFACEUna postazione di sviluppo in una stanza buia, due schermi aperti sul codice.
SUPERFICI DI INTEGRAZIONE

Un motore, diversi modi per integrarlo.

Il contratto prodotto è più ristretto del vecchio ecosistema. Le integrazioni devono esporre decisioni ed evidenze SafeSign senza importare prodotti business o Office.

01CONTRACT STABILIZATION

SafeSign Decision SDK

Contratto client/server per decodificare richieste supportate, esprimere intent, allegare evidenze e restituire ALLOW / WARN / REVIEW / BLOCK.

context + payload → evidence + decision
02SOURCE PRIMITIVES

Security Core

Primitive local-first riutilizzabili in SafeSign, Guard e integrazioni wallet senza custodia di chiavi o autorità di firma.

deterministic rules → explainable signals
03MV3 SOURCE SCAFFOLD

UTXO Guard

Superficie browser che avvolge richieste supportate e presenta SafeSign prima di inoltrare l'originale invariato.

provider request → explicit continue / reject
04PLANNED

Enterprise Policy

Policy firmate, approvazioni e controlli enterprise stanno sopra il core e vanno costruiti dopo aver stabilizzato contratto e audit boundary.

signed policy → organization decision constraints
CONFINE DELL'EVIDENZA

Dire esattamente cosa esiste.

Gli acquirenti enterprise verificheranno le affermazioni. La superficie separa quindi gli artefatti attuali dalle capacità production ancora da validare o revisionare.

CURRENT

Evidenza attuale del repository

  • Una superficie SafeSign focalizzata e architettura di sicurezza transazionale.
  • Concetti Security Core per decoding, regole, validazione e confini policy.
  • Scaffold Manifest V3 di Guard e modello esplicito continua/rifiuta.
NOT YET

Non è ancora una promessa production

  • Non viene dichiarato alcun SLA production pubblicato o audit indipendente verificato.
  • Non vendere copertura universale, threat network real-time o garanzia sub-second prima delle misure.
  • Packaging API, autenticazione, quote, billing e contratti di supporto restano da completare.
PERCORSI COMMERCIALI

Monetizzare lo stesso core di sicurezza a diversi livelli.

Il modello deve scalare dal self-service all'enterprise contrattuale senza creare prodotti scollegati per ogni segmento.

01

Developer

Valutazione self-service, contratti di riferimento, analisi locale e documentazione per favorire adozione prima del procurement.

EVALUATION / ADOPTION
02

Product

Integrazione usage-based o contrattuale per wallet, fintech e prodotti onchain quando le garanzie API saranno misurabili.

SDK / API REVENUE
03

Enterprise

Policy enforcement, private deployment, evidenze procurement, support commitments e multi-approval formano il livello istituzionale.

ANNUAL CONTRACT / PRIVATE DEPLOYMENT
CONTRATTO OBIETTIVO

Un'interfaccia decisionale stabile, non un altro wallet.

L'SDK/API dovrà ricevere contesto e payload invariato, restituendo evidenze strutturate e una raccomandazione. L'autorità di firma resta al wallet integratore.

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 →Parla di integrazione →
DEVELOPERS / CONTRATTO DI INTEGRAZIONE

Integra review senza cedere il signing boundary.

Il contratto deve essere side-effect free: request in, evidence out, payload preservato e signer authoritative.

SUPERFICI DI INTEGRAZIONE

Inizia dove la richiesta di firma esiste già.

Aggiungi review nel boundary affidabile più stretto senza ricostruire transport, custody o signing.

01

WALLET EXTENSION

Intercetta provider methods prima della conferma e mostra evidenza senza sostituire la richiesta originale.

02

EMBEDDED WALLET

Analizza dopo request construction e prima del signer; le key restano fuori dall'analisi.

03

FINTECH APPROVAL FLOW

Esegui evidence e policy prima di inoltrare il pacchetto a signer/custody esistenti.

04

AGENT / AUTOMATION

Tratta machine intent come input non affidabile; richiedi policy gates ed escalation umana per azioni irreversibili o high-value.

05

TRANSACTION BUILDER

Analizza il payload finale, non solo parametri iniziali, per evitare bypass via encoding/routing.

06

READ-ONLY MONITORING

Riusa l'evidence model per observability e incident triage senza concedere signing authority.

Modello di evidenza

Costruisci una decisione da segnali indipendenti.

L'evidenza sconosciuta deve restare visibilmente sconosciuta. L'assenza di analisi non deve mai diventare ALLOW.

01CAPTURE

Ricevi la richiesta esatta e origin prima della conferma.

02CLASSIFY

Identifica la famiglia prima di applicare logica generica.

03DECODE

Normalizza metodi, parametri, autorità e destinazioni.

04ENRICH

Aggiungi contesto contract, policy, freshness e simulazione quando disponibile.

05COMPARE

Confronta l'autorità ricostruita con l'intento dichiarato.

06DECIDE

Restituisci ALLOW, WARN, REVIEW o BLOCK con motivazioni e unknowns espliciti.

07AUTHORIZE

Restituisci il controllo a wallet o signer. L'analisi non firma né trasmette silenziosamente.

Contratto decisionale

Contratto decisionale

Il contratto deve essere side-effect free: request in, evidence out, payload preservato e signer 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"
}
Semantica decisionale

Semantica decisionale

L'evidenza sconosciuta deve restare visibilmente sconosciuta. L'assenza di analisi non deve mai diventare ALLOW.

DECISION
TRIGGER
MEANING
NEXT
ALLOW
supported evidence consistent
Nessuna contraddizione materiale nell'evidenza supportata. Serve comunque autorizzazione esplicita.
EXPLICIT SIGN
WARN
material risk present
La richiesta è compresa, ma il rischio materiale deve essere mostrato prima dell'autorizzazione.
USER REVIEW
REVIEW
incomplete or conflicting evidence
L'evidenza è incompleta, contraddittoria o fuori policy. Effettuare escalation.
SECOND REVIEW
BLOCK
policy or supported threat signal
Una policy configurata o threat signal indica di non procedere senza override esplicito.
NO FORWARD
POLICY / FAILURE MODES

Fallisci in sicurezza quando l'analisi degrada.

L'evidenza sconosciuta deve restare visibilmente sconosciuta. L'assenza di analisi non deve mai diventare ALLOW.

UNSUPPORTED REQUEST

Non indovinare. Preserva la richiesta, mostra ciò che non è supportato e richiedi review.

unsupported → REVIEW

SIMULATION UNAVAILABLE

Continua con evidenza statica e contestuale, rendendo esplicita l'assenza della simulazione.

simulation: unavailable → confidence: partial

INTENT MISMATCH

Tratta il mismatch tra intento e autorità decodificata come evidenza primaria.

intent != authority → REVIEW/BLOCK policy

STALE CONTEXT

L'intelligence time-sensitive richiede freshness metadata per evitare che osservazioni vecchie sembrino attuali.

observedAt + ttl → freshness
INVARIANT

L'integrazione deve fallire visibilmente, preservare payload integrity, esporre unsupported states e non trasformare analysis failure in approval implicita.

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