UTXOSUITE — home
منصة المطورين

ادمج أمان المعاملات داخل مسار التوقيع.

يتم بناء SafeSign كطبقة تكامل للمحافظ ومنتجات fintech وتطبيقات onchain: فك الطلب وإضافة سياق أمني والحفاظ على الحمولة وطلب قرار صريح.

عرض البنية ↗مناقشة التكامل →
SAFESIGN / PRE-PRODUCTIONNON-CUSTODIALEXPLICIT AUTHORIZATION14 LOCALES
DEVELOPERS / INTEGRATION SURFACEمحطة عمل لمطوّر في غرفة معتمة، وشاشتان مفتوحتان على الشيفرة.
أسطح التكامل

محرك واحد بعدة طرق للتكامل.

عقد المنتج أصبح أضيق من قصة منظومة UTXO القديمة. يجب أن تعرض التكاملات قرارات SafeSign وأدلتها دون خلط منتجات الأعمال أو Office داخل حدود الأمان.

01CONTRACT STABILIZATION

SafeSign Decision SDK

عقد مستهدف لفك طلبات المحفظة المدعومة وإظهار النية وإرفاق الأدلة وإرجاع توصيات ALLOW / WARN / REVIEW / BLOCK.

context + payload → evidence + decision
02SOURCE PRIMITIVES

Security Core

بدائيات تحليل وسياسات محلية قابلة لإعادة الاستخدام عبر SafeSign وGuard وتكاملات المحافظ دون حفظ المفاتيح أو امتلاك سلطة التوقيع.

deterministic rules → explainable signals
03MV3 SOURCE SCAFFOLD

UTXO Guard

سطح متصفح يلتف حول طلبات provider المدعومة ويعرض مراجعة SafeSign قبل تمرير الطلب الأصلي دون تغيير.

provider request → explicit continue / reject
04PLANNED

Enterprise Policy

سياسات المؤسسة الموقعة والموافقات وضوابط النشر تأتي فوق نواة التحليل ويجب بناؤها بعد استقرار عقد القرار وحدود التدقيق.

signed policy → organization decision constraints
حد الأدلة

قل بدقة ما هو موجود.

المشترون المؤسسيون سيتحققون من الادعاءات، لذلك تفصل هذه الصفحة بين ما يوجد في المصدر الآن وبين قدرات الإنتاج التي لا تزال تحتاج إلى تحقق أو مراجعة مستقلة.

CURRENT

أدلة المستودع الحالية

  • واجهة SafeSign مركزة وبنية لأمان المعاملات.
  • مفاهيم Security Core لفك البيانات والقواعد والتحقق وحدود السياسات.
  • هيكل Guard Manifest V3 ونموذج تفاعل متابعة/رفض صريح.
NOT YET

ليست ادعاءات إنتاج بعد

  • لا يتم الادعاء هنا بوجود SLA إنتاج منشور أو تدقيق أمني مستقل موثق.
  • لا ينبغي بيع تغطية شاملة للسلاسل أو شبكة تهديدات آنية أو ضمان أقل من ثانية قبل قياسها.
  • لا تزال حزمة API للإنتاج والمصادقة والحصص والفوترة وعقود الدعم بحاجة إلى إكمال.
المسارات التجارية

تحقيق الدخل من نفس نواة الأمان بمستويات مختلفة.

يجب أن يتوسع النموذج من التكامل الذاتي إلى النشر المؤسسي التعاقدي دون إنشاء منتجات منفصلة لكل شريحة.

01

Developer

تقييم ذاتي وعقود مرجعية وتحليل محلي وتوثيق لتسهيل التبني قبل تعقيدات الشراء المؤسسي.

EVALUATION / ADOPTION
02

Product

تكامل حسب الاستخدام أو بعقد للمحافظ وfintech ومنتجات onchain بعد أن تصبح ضمانات API قابلة للقياس والدعم.

SDK / API REVENUE
03

Enterprise

فرض السياسات والنشر الخاص وأدلة المشتريات والتزامات الدعم والموافقات المتعددة تشكل الطبقة المؤسسية الأعلى قيمة.

ANNUAL CONTRACT / PRIVATE DEPLOYMENT
العقد المستهدف

واجهة قرار مستقرة، وليست محفظة أخرى.

يجب أن يستقبل SDK/API السياق وحمولة التوقيع دون تغيير ثم يعيد أدلة منظمة وتوصية بالقرار، بينما تبقى سلطة التوقيع لدى المحفظة المدمجة.

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 →مناقشة التكامل →
DEVELOPERS / عقد التكامل

ادمج المراجعة دون التنازل عن حدود التوقيع.

يجب أن يكون عقد التكامل بلا آثار جانبية افتراضياً: request يدخل، evidence يخرج، payload يبقى كما هو، وsigner يبقى صاحب السلطة.

أسطح التكامل

ابدأ حيث يوجد طلب التوقيع أصلاً.

أضف المراجعة عند أضيق حدود موثوقة دون إعادة بناء transport أو custody أو signing.

01

WALLET EXTENSION

اعترض provider methods قبل التأكيد واعرض evidence دون استبدال الطلب الأصلي.

02

EMBEDDED WALLET

حلل بعد بناء request وقبل استدعاء signer مع بقاء keys خارج التحليل.

03

FINTECH APPROVAL FLOW

شغّل evidence وpolicy قبل إرسال الحزمة إلى signer أو custody الحالي للمؤسسة.

04

AGENT / AUTOMATION

اعتبر machine intent input غير موثوق واطلب policy gates وتصعيداً بشرياً للعمليات غير القابلة للتراجع أو عالية القيمة.

05

TRANSACTION BUILDER

حلل payload النهائي لا المعاملات الأولية فقط حتى لا يتجاوز encoding أو routing المراجعة.

06

READ-ONLY MONITORING

أعد استخدام evidence model للمراقبة والتحقيق بعد الحدث دون منح signing authority.

نموذج الأدلة

ابنِ القرار من إشارات مستقلة.

يجب أن يبقى الدليل غير المعروف معلماً بوضوح كمجهول، وألا يتحول غياب التحليل بصمت إلى ALLOW.

01CAPTURE

استقبل الطلب الدقيق وorigin قبل التأكيد.

02CLASSIFY

حدد فئة الطلب قبل تطبيق منطق مخاطر عام.

03DECODE

طبّع methods والمعاملات والصلاحية والوجهات.

04ENRICH

أضف سياق العقد والسياسة والحداثة والمحاكاة عند توفره.

05COMPARE

قارن الصلاحية المعاد بناؤها بالنية المعلنة للمستخدم.

06DECIDE

أعد ALLOW أو WARN أو REVIEW أو BLOCK مع الأسباب والمجهولات بوضوح.

07AUTHORIZE

أعد التحكم إلى wallet أو signer. التحليل لا يوقّع أو يبث بصمت.

عقد القرار

عقد القرار

يجب أن يكون عقد التكامل بلا آثار جانبية افتراضياً: request يدخل، evidence يخرج، payload يبقى كما هو، وsigner يبقى صاحب السلطة.

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"
}
دلالات القرار

دلالات القرار

يجب أن يبقى الدليل غير المعروف معلماً بوضوح كمجهول، وألا يتحول غياب التحليل بصمت إلى ALLOW.

DECISION
TRIGGER
MEANING
NEXT
ALLOW
supported evidence consistent
لا يوجد تعارض جوهري ضمن الأدلة المدعومة، لكن التفويض الصريح يبقى مطلوباً.
EXPLICIT SIGN
WARN
material risk present
الطلب مفهوم لكن يجب عرض الخطر الجوهري قبل التفويض.
USER REVIEW
REVIEW
incomplete or conflicting evidence
الأدلة ناقصة أو متعارضة أو خارج policy. يجب التصعيد.
SECOND REVIEW
BLOCK
policy or supported threat signal
تمنع policy مضبوطة أو إشارة تهديد مدعومة المتابعة دون override صريح.
NO FORWARD
POLICY / FAILURE MODES

افشل بأمان عندما يضعف التحليل.

يجب أن يبقى الدليل غير المعروف معلماً بوضوح كمجهول، وألا يتحول غياب التحليل بصمت إلى ALLOW.

UNSUPPORTED REQUEST

لا تخمّن. احتفظ بالطلب وأظهر الجزء غير المدعوم واطلب review.

unsupported → REVIEW

SIMULATION UNAVAILABLE

تابع بالأدلة الثابتة والسياقية مع توضيح غياب المحاكاة.

simulation: unavailable → confidence: partial

INTENT MISMATCH

اعتبر التعارض بين النية والصلاحية المفكوكة دليلاً أساسياً.

intent != authority → REVIEW/BLOCK policy

STALE CONTEXT

تحتاج المعلومات الحساسة للوقت إلى freshness metadata حتى لا تبدو الملاحظات القديمة كحقائق حالية.

observedAt + ttl → freshness
INVARIANT

يجب أن يفشل التكامل بشكل واضح ويحافظ على payload integrity ويكشف unsupported states وألا يحول analysis failure إلى موافقة ضمنية.

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