UTXOSUITE — home
DEVELOPER PLATFORM

Build transaction security into the signing flow.

SafeSign is being shaped as an integration layer for wallets, fintech products and onchain applications: decode what is being requested, attach security context, preserve the original payload and require an explicit authorization decision.

SAFESIGN / PRE-PRODUCTIONNON-CUSTODIALEXPLICIT AUTHORIZATION14 LOCALES
DEVELOPERS / INTEGRATION SURFACEA developer workstation in a dark room, two screens open on code.
INTEGRATION SURFACES

One engine, several ways to embed it.

The product contract is narrower than the old UTXO ecosystem story. Integrations should expose SafeSign decisions and evidence, not import unrelated business, office or execution products into the security boundary.

01CONTRACT STABILIZATION

SafeSign Decision SDK

Target client/server contract for decoding supported wallet requests, expressing intent, attaching evidence and returning ALLOW / WARN / REVIEW / BLOCK recommendations.

context + payload → evidence + decision
02SOURCE PRIMITIVES

Security Core

Local-first analysis and policy primitives intended to remain reusable across SafeSign, Guard and wallet integrations without requiring custody of keys or signing authority.

deterministic rules → explainable signals
03MV3 SOURCE SCAFFOLD

UTXO Guard

Browser integration surface that can wrap supported provider requests and present a SafeSign review before forwarding the original request unchanged.

provider request → explicit continue / reject
04PLANNED

Enterprise Policy

Signed organization policy, approvals and deployment controls belong above the analysis core. They should be built only after the decision contract and audit boundary are stable.

signed policy → organization decision constraints
EVIDENCE BOUNDARY

Say exactly what exists.

Enterprise security buyers will verify claims. The developer surface therefore separates current source artifacts from production capabilities that still require validation, packaging or independent review.

CURRENT

Current repository evidence

  • A focused SafeSign product surface and transaction-security architecture.
  • Security Core source concepts for decoding, rules, validation and policy boundaries.
  • Manifest V3 Guard scaffold and explicit continue/reject interaction model.
NOT YET

Not a production claim yet

  • No published production SLA or independently verified security audit is claimed here.
  • No universal chain coverage, real-time threat network or sub-second latency guarantee should be sold until measured.
  • Production API packaging, authentication, quotas, billing and support contracts are commercial work still to be completed.
COMMERCIAL LANES

Monetize the same security core at different depths.

The business model should scale from self-serve integration to contractual enterprise deployment without creating separate unrelated products for every customer segment.

01

Developer

Self-serve evaluation, reference contracts, local analysis and integration documentation. The objective is adoption before procurement friction.

EVALUATION / ADOPTION
02

Product

Usage-based or contracted integration for wallets, fintechs and onchain products once production API guarantees are measurable and supportable.

SDK / API REVENUE
03

Enterprise

Policy enforcement, private deployment, procurement evidence, support commitments and multi-approval controls form the high-value institutional layer.

ANNUAL CONTRACT / PRIVATE DEPLOYMENT
TARGET CONTRACT

A stable decision interface, not another wallet.

The eventual SDK/API should accept context and an unchanged signing payload, then return structured evidence and a decision recommendation. Signing authority remains with the integrating wallet or 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
DEVELOPERS / INTEGRATION CONTRACT

Integrate review without surrendering the signing boundary.

The integration contract should be side-effect free by default: request in, evidence out, original payload preserved, signer still authoritative.

INTEGRATION SURFACES

Start where the signing request already exists.

Add review at the narrowest reliable boundary instead of rebuilding wallet transport, key custody or signing infrastructure.

01

WALLET EXTENSION

Intercept provider methods before confirmation and render evidence without replacing the original request.

02

EMBEDDED WALLET

Analyze after request construction but before signer invocation; key material stays outside analysis.

03

FINTECH APPROVAL FLOW

Run evidence and policy before forwarding a transaction package to the institution's existing signer or custody provider.

04

AGENT / AUTOMATION

Treat machine-generated intent as untrusted input; require policy gates and human escalation for irreversible or high-value actions.

05

TRANSACTION BUILDER

Analyze the finalized payload, not only pre-construction parameters, so encoding or routing changes cannot bypass review.

06

READ-ONLY MONITORING

Reuse the evidence model for post-event observability and incident triage without granting signing authority.

Evidence model

Build a decision from independent signals.

Unknown evidence must remain visibly unknown. Missing analysis must never silently become ALLOW.

01CAPTURE

Receive the exact request and origin before confirmation.

02CLASSIFY

Identify the request family before applying generic risk logic.

03DECODE

Normalize methods, parameters, authority and destinations.

04ENRICH

Attach contract, policy, freshness and simulation context where available.

05COMPARE

Compare reconstructed authority with the user's stated intent.

06DECIDE

Return ALLOW, WARN, REVIEW or BLOCK with explicit reasons and unknowns.

07AUTHORIZE

Return control to the wallet or signer. Analysis never silently signs or broadcasts.

Decision contract

Decision contract

The integration contract should be side-effect free by default: request in, evidence out, original payload preserved, signer still 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"
}
Decision semantics

Decision semantics

Unknown evidence must remain visibly unknown. Missing analysis must never silently become ALLOW.

DECISION
TRIGGER
MEANING
NEXT
ALLOW
supported evidence consistent
No material contradiction found inside the supported evidence. Explicit authorization is still required.
EXPLICIT SIGN
WARN
material risk present
The request is understood, but the user should see the material risk before authorization.
USER REVIEW
REVIEW
incomplete or conflicting evidence
Evidence is incomplete, contradictory or outside policy. Escalate instead of pretending certainty.
SECOND REVIEW
BLOCK
policy or supported threat signal
A configured policy or supported threat signal says the request should not proceed without an explicit override path.
NO FORWARD
POLICY / FAILURE MODES

Fail safe when analysis degrades.

Unknown evidence must remain visibly unknown. Missing analysis must never silently become ALLOW.

UNSUPPORTED REQUEST

Do not guess. Preserve the request, expose the unsupported surface and require explicit review.

unsupported → REVIEW

SIMULATION UNAVAILABLE

Continue with static and contextual evidence, but make the missing simulation explicit.

simulation: unavailable → confidence: partial

INTENT MISMATCH

Treat a mismatch between stated intent and decoded authority as first-class evidence.

intent != authority → REVIEW/BLOCK policy

STALE CONTEXT

Time-sensitive intelligence needs freshness metadata so old observations cannot masquerade as current facts.

observedAt + ttl → freshness
INVARIANT

Integration should fail visibly, preserve payload integrity, expose unsupported states and never convert analysis failure into implicit approval.