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 + decisionSafeSign 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.

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.
Target client/server contract for decoding supported wallet requests, expressing intent, attaching evidence and returning ALLOW / WARN / REVIEW / BLOCK recommendations.
context + payload → evidence + decisionLocal-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 signalsBrowser integration surface that can wrap supported provider requests and present a SafeSign review before forwarding the original request unchanged.
provider request → explicit continue / rejectSigned 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 constraintsEnterprise security buyers will verify claims. The developer surface therefore separates current source artifacts from production capabilities that still require validation, packaging or independent review.
The business model should scale from self-serve integration to contractual enterprise deployment without creating separate unrelated products for every customer segment.
Self-serve evaluation, reference contracts, local analysis and integration documentation. The objective is adoption before procurement friction.
EVALUATION / ADOPTIONUsage-based or contracted integration for wallets, fintechs and onchain products once production API guarantees are measurable and supportable.
SDK / API REVENUEPolicy enforcement, private deployment, procurement evidence, support commitments and multi-approval controls form the high-value institutional layer.
ANNUAL CONTRACT / PRIVATE DEPLOYMENTThe 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.
// 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 integratorThe integration contract should be side-effect free by default: request in, evidence out, original payload preserved, signer still authoritative.
Add review at the narrowest reliable boundary instead of rebuilding wallet transport, key custody or signing infrastructure.
Intercept provider methods before confirmation and render evidence without replacing the original request.
Analyze after request construction but before signer invocation; key material stays outside analysis.
Run evidence and policy before forwarding a transaction package to the institution's existing signer or custody provider.
Treat machine-generated intent as untrusted input; require policy gates and human escalation for irreversible or high-value actions.
Analyze the finalized payload, not only pre-construction parameters, so encoding or routing changes cannot bypass review.
Reuse the evidence model for post-event observability and incident triage without granting signing authority.
Unknown evidence must remain visibly unknown. Missing analysis must never silently become ALLOW.
Receive the exact request and origin before confirmation.
Identify the request family before applying generic risk logic.
Normalize methods, parameters, authority and destinations.
Attach contract, policy, freshness and simulation context where available.
Compare reconstructed authority with the user's stated intent.
Return ALLOW, WARN, REVIEW or BLOCK with explicit reasons and unknowns.
Return control to the wallet or signer. Analysis never silently signs or broadcasts.
The integration contract should be side-effect free by default: request in, evidence out, original payload preserved, signer still authoritative.
{
"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"
}Unknown evidence must remain visibly unknown. Missing analysis must never silently become ALLOW.
Unknown evidence must remain visibly unknown. Missing analysis must never silently become ALLOW.
Do not guess. Preserve the request, expose the unsupported surface and require explicit review.
unsupported → REVIEWContinue with static and contextual evidence, but make the missing simulation explicit.
simulation: unavailable → confidence: partialTreat a mismatch between stated intent and decoded authority as first-class evidence.
intent != authority → REVIEW/BLOCK policyTime-sensitive intelligence needs freshness metadata so old observations cannot masquerade as current facts.
observedAt + ttl → freshnessIntegration should fail visibly, preserve payload integrity, expose unsupported states and never convert analysis failure into implicit approval.