UTXOSUITE — home
ENTWICKLERPLATTFORM

Transaktionssicherheit direkt in den Signaturfluss integrieren.

SafeSign wird als Integrationsschicht für Wallets, Fintech-Produkte und Onchain-Anwendungen aufgebaut: Anfrage dekodieren, Sicherheitskontext ergänzen, Payload erhalten und eine explizite Autorisierung verlangen.

Architektur lesen ↗Integration besprechen →
SAFESIGN / PRE-PRODUCTIONNON-CUSTODIALEXPLICIT AUTHORIZATION14 LOCALES
DEVELOPERS / INTEGRATION SURFACEEin Entwicklerarbeitsplatz in einem dunklen Raum, zwei Bildschirme mit Code.
INTEGRATIONSFLÄCHEN

Eine Engine, mehrere Integrationswege.

Der Produktvertrag ist enger als die frühere UTXO-Ecosystem-Erzählung. Integrationen sollen SafeSign-Entscheidungen und Evidenz liefern, nicht Business- oder Office-Produkte in die Sicherheitsgrenze ziehen.

01CONTRACT STABILIZATION

SafeSign Decision SDK

Zielvertrag für unterstützte Wallet-Requests: dekodieren, Intent abbilden, Evidenz anhängen und ALLOW / WARN / REVIEW / BLOCK empfehlen.

context + payload → evidence + decision
02SOURCE PRIMITIVES

Security Core

Local-first Analyse- und Policy-Primitives für SafeSign, Guard und Wallet-Integrationen, ohne Key-Custody oder Signaturhoheit.

deterministic rules → explainable signals
03MV3 SOURCE SCAFFOLD

UTXO Guard

Browser-Integrationsfläche, die unterstützte Provider-Requests umschließt und SafeSign zeigt, bevor der Original-Request unverändert weitergeht.

provider request → explicit continue / reject
04PLANNED

Enterprise Policy

Signierte Organisations-Policies, Freigaben und Deployment-Kontrollen gehören über den Analyse-Core und erst nach stabilem Decision Contract und Audit Boundary.

signed policy → organization decision constraints
EVIDENZGRENZE

Exakt sagen, was existiert.

Enterprise-Käufer prüfen Aussagen. Deshalb trennt diese Oberfläche vorhandene Source-Artefakte von Production-Fähigkeiten, die noch Validierung, Packaging oder unabhängige Prüfung benötigen.

CURRENT

Aktuelle Repository-Evidenz

  • Eine fokussierte SafeSign-Oberfläche und Transaktionssicherheits-Architektur.
  • Security-Core-Quellkonzepte für Decoding, Regeln, Validierung und Policy-Grenzen.
  • Manifest-V3-Guard-Scaffold und explizites Continue/Reject-Modell.
NOT YET

Noch kein Production-Claim

  • Hier wird kein veröffentlichtes Production-SLA und kein unabhängig verifiziertes Security-Audit behauptet.
  • Keine universelle Chain-Abdeckung, Echtzeit-Threat-Network oder Sub-Second-Garantie verkaufen, bevor sie gemessen ist.
  • Production-API-Packaging, Authentifizierung, Quotas, Billing und Supportverträge sind noch umzusetzen.
KOMMERZIELLE WEGE

Denselben Security Core auf unterschiedlichen Ebenen monetarisieren.

Das Modell soll von Self-Service bis zu vertraglichen Enterprise-Deployments skalieren, ohne pro Segment neue, unverbundene Produkte zu erfinden.

01

Developer

Self-Service-Evaluation, Referenzverträge, lokale Analyse und Dokumentation – Adoption vor Procurement-Friktion.

EVALUATION / ADOPTION
02

Product

Usage-based oder vertragliche Integration für Wallets, Fintechs und Onchain-Produkte, sobald API-Garantien messbar und supportbar sind.

SDK / API REVENUE
03

Enterprise

Policy Enforcement, Private Deployment, Procurement-Evidenz, Support-Zusagen und Multi-Approval bilden die hochwertige institutionelle Schicht.

ANNUAL CONTRACT / PRIVATE DEPLOYMENT
ZIELVERTRAG

Eine stabile Entscheidungs-Schnittstelle, nicht noch eine Wallet.

Das SDK/API soll Kontext und unveränderten Signing-Payload annehmen und strukturierte Evidenz plus Entscheidungsempfehlung zurückgeben. Die Signaturhoheit bleibt beim integrierenden Wallet/Signer.

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 →Integration besprechen →
DEVELOPERS / INTEGRATIONSVERTRAG

Review integrieren, ohne die Signaturgrenze abzugeben.

Integrationsvertrag standardmäßig side-effect free: Request rein, Evidenz raus, Payload unverändert, Signer authoritative.

INTEGRATIONSFLÄCHEN

Dort beginnen, wo die Signaturanfrage bereits existiert.

Review an der engsten verlässlichen Grenze ergänzen, ohne Wallet-Transport, Custody oder Signing neu zu bauen.

01

WALLET EXTENSION

Provider-Methoden vor Bestätigung abfangen und Evidenz anzeigen, ohne Original-Request zu ersetzen.

02

EMBEDDED WALLET

Nach Request-Konstruktion und vor Signer-Aufruf analysieren; Keys bleiben außerhalb der Analyse.

03

FINTECH APPROVAL FLOW

Evidenz und Policy vor Weitergabe an bestehenden institutionellen Signer oder Custody anwenden.

04

AGENT / AUTOMATION

Machine-generated Intent als untrusted input behandeln; Policy Gates und Human Escalation für irreversible oder High-Value-Aktionen verlangen.

05

TRANSACTION BUILDER

Finalen Payload analysieren, nicht nur Vorparameter, damit Encoding oder Routing Review nicht umgehen.

06

READ-ONLY MONITORING

Evidence Model für Post-Event Observability und Incident Triage wiederverwenden, ohne Signing Authority zu vergeben.

Evidenzmodell

Eine Entscheidung aus unabhängigen Signalen aufbauen.

Unbekannte Evidenz muss sichtbar unbekannt bleiben. Fehlende Analyse darf nie stillschweigend zu ALLOW werden.

01CAPTURE

Exakten Request und Origin vor Bestätigung erfassen.

02CLASSIFY

Request-Familie vor generischer Risikologik bestimmen.

03DECODE

Methoden, Parameter, Autorität und Ziele normalisieren.

04ENRICH

Contract-, Policy-, Freshness- und Simulationskontext ergänzen, wenn verfügbar.

05COMPARE

Rekonstruierte Autorität mit der angegebenen Nutzerabsicht vergleichen.

06DECIDE

ALLOW, WARN, REVIEW oder BLOCK mit expliziten Gründen und Unknowns zurückgeben.

07AUTHORIZE

Kontrolle an Wallet oder Signer zurückgeben. Analyse signiert oder broadcastet niemals still.

Decision Contract

Decision Contract

Integrationsvertrag standardmäßig side-effect free: Request rein, Evidenz raus, Payload unverändert, 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"
}
Entscheidungssemantik

Entscheidungssemantik

Unbekannte Evidenz muss sichtbar unbekannt bleiben. Fehlende Analyse darf nie stillschweigend zu ALLOW werden.

DECISION
TRIGGER
MEANING
NEXT
ALLOW
supported evidence consistent
Keine materielle Widersprüchlichkeit in unterstützter Evidenz. Explizite Autorisierung bleibt nötig.
EXPLICIT SIGN
WARN
material risk present
Request ist verstanden, aber materielles Risiko muss vor Autorisierung sichtbar sein.
USER REVIEW
REVIEW
incomplete or conflicting evidence
Evidenz ist unvollständig, widersprüchlich oder außerhalb der Policy. Eskalieren.
SECOND REVIEW
BLOCK
policy or supported threat signal
Konfigurierte Policy oder Threat-Signal verlangt Stop ohne expliziten Override.
NO FORWARD
POLICY / FAILURE MODES

Fail-safe verhalten, wenn Analyse degradiert.

Unbekannte Evidenz muss sichtbar unbekannt bleiben. Fehlende Analyse darf nie stillschweigend zu ALLOW werden.

UNSUPPORTED REQUEST

Nicht raten. Request erhalten, nicht unterstützte Fläche offenlegen und Review verlangen.

unsupported → REVIEW

SIMULATION UNAVAILABLE

Mit statischer und kontextueller Evidenz fortfahren, fehlende Simulation explizit markieren.

simulation: unavailable → confidence: partial

INTENT MISMATCH

Mismatch zwischen Intent und dekodierter Autorität als zentrale Evidenz behandeln.

intent != authority → REVIEW/BLOCK policy

STALE CONTEXT

Zeitabhängige Intelligence braucht Freshness-Metadaten, damit alte Beobachtungen nicht als aktuelle Fakten erscheinen.

observedAt + ttl → freshness
INVARIANT

Integration muss sichtbar fehlschlagen, Payload-Integrität bewahren, unsupported states offenlegen und Analysis Failure nie zu implizitem Approval machen.

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