دليل المنصات وجهات التكامل

كل ما تحتاجه منصة تداول أو جهة حفظ أو جهة تكامل مدفوعات لإدراج QOR ومعالجة الإيداعات والسحوبات: اختيار الواجهة المناسبة، واكتشاف الإيداعات بأمان، وتوقيع السحوبات.

ملاحظة

يستهدف هذا الدليل الشبكة الرئيسية qorechain-vladi (قيد التشغيل منذ 7 يونيو 2026؛ إصدار العقدة v3.2.3، طُبِّق عند الارتفاع 3,662,051 في 20 أكتوبر 2026). تدرّب على التدفق الكامل أولاً على شبكة الاختبار qorechain-diana — فهي تعمل بالإصدار v3.2.4 منذ 19 أكتوبر 2026، وتنتقل الشبكة الرئيسية من v3.2.3 إلى v3.2.4 عند الارتفاع 3,742,566 (مقترح الحوكمة 13)، لذا فإن التغييرات المدرجة أدناه تسري على الشبكتين متى بلغت تلك الكتلة (نقاط النهاية لكلتا الشبكتين موجودة في الشبكات). إذا كنت تشغّل عقدتك الكاملة الخاصة، فأبقِها على الإصدار الذي يوصي به بيان التنزيل ولا تنزل أبداً عن قيمة minCompatible فيه (3.2.3 على الشبكة الرئيسية حتى الترقية) — فالعقدة القديمة لا تستطيع مواكبة ترقيات السلسلة وتتوقف عند ارتفاع الترقية؛ راجع تشغيل عقدة لمعرفة ما ينبغي فعله قبل الارتفاع 3,742,566.

ما الذي تغيّر بالنسبة لجهات التكامل في v3.2.2 وv3.2.3 (صيغة التوقيع والعناوين والخانات العشرية والـ memo والرسوم كلها دون تغيير):

• تُرفض معاملات Ethereum غير المحمية (ما قبل EIP-155) في mempool وفي تنفيذ الكتل (v3.2.2). يجب أن توقّع محفظة المودِع مع معرّف سلسلة؛ وكل المحافظ الحالية تفعل ذلك.
• لا يمكن الاستحواذ على حسابات الوحدات (module accounts) عبر EVM (v3.2.2)؛ لا تستخدم عنوان حساب وحدة كعنوان إيداع أو سحب.
• لا يمكن إنشاء حسابات الاستحقاق (vesting) إلا للمُوقِّع نفسه (v3.2.3)، (ورسائل إنشاء الاستحقاق الثلاث موجودة حالياً على قائمة قاطع الدائرة في الشبكة الرئيسية).
• تحتاج رسائل مفاتيح PQC إلى التوقيع الهجين متى صار للحساب مفتاح (v3.2.3): انظر التوقيع ما بعد الكمّي. سجّل مفتاح المحفظة الساخنة مرة واحدة، وبوقت مبكر.
• يمكن تحديد نطاق نوافذ EVM (v3.2.3): يمكن للمحفظة الساخنة التي ترسل QOR العادي فقط أن تفتح نافذة native_only، انظر تطوير EVM.

ما الذي يتغيّر بالنسبة لجهات التكامل في v3.2.4 (على شبكة الاختبار منذ 19 أكتوبر 2026؛ وعلى الشبكة الرئيسية اعتبارًا من الارتفاع 3,742,566). صيغة توقيع المعاملات والعناوين والخانات العشرية والـ memo والرسوم دون تغيير، ولا يتغيّر شيء في طريقة اكتشاف الإيداع أو في توقيع السحب وبثّه:

• أقفال التوكيل الاختيارية (الوحدة الجديدة x/stakingtier). يجوز للمفوِّض أن يقفل جزءًا من تفويضه لمدة 3 أو 6 أو 12 شهرًا (الحد الأدنى للقفل 10 QOR، وبحد أقصى 16 قفلًا مفتوحًا لكل مفوِّض). لا يحدث شيء للحساب الذي لا ينشئ قفلًا. وما دام القفل مفتوحًا، لا يمكن إلغاء تفويض ذلك المبلغ ولا إعادة تفويضه، بأي مسار (معاملة عادية، أو authz، أو مجموعة، أو عقد)؛ وإنهاء القفل مبكرًا يحرق غرامة من الحصة المقفلة. ولذلك ينبغي للأمين الذي يوكّل أموال العملاء ألا يقفل الجزء الذي قد يحتاج إلى ردّه. اقرأ المعاملات من GET /qorechain/stakingtier/v1/params.
• مصدر حرق جديد، staking_tier_penalty، يظهر في إحصاءات الحرق بمجرد حدوث عمليات فك قفل مبكرة. ينبغي لمهام مطابقة المعروض التي تعدّد مصادر الحرق أن تقبل اسم مصدر غير معروف.
• حدود JSON-RPC محلية للعقدة للعقد التي تشغّلها بنفسك: تُرفض أجسام الطلبات التي تتجاوز 256 KiB (HTTP 413)، ولا يُخدَّم أكثر من 256 طلبًا في الوقت نفسه (HTTP 503 بعد ذلك)، ويُرفض أي مرشّح eth_getLogs أو eth_newFilter يتجاوز 4 مواضع للمواضيع (topics) أو 1000 بديل في موضع واحد أو 1000 عنوان. يمكن ضبط الحدود في القسم [json-rpc] من app.toml (راجع تشغيل عقدة). ينبغي لماسح الإيداعات الذي يستعلم eth_getLogs بقائمة عناوين طويلة أن يقسّم القائمة.
• يُرفض تسجيل المفتاح المتكرر قبل دفع رسومه. تَرفض العقدة التي تشغّل v3.2.4، وقت البثّ، أي MsgRegisterPQCKeyV2 يحمل المفتاح العام نفسه المسجَّل أصلًا للحساب، بالخطأ الذي كانت السلسلة ستعيده (رمز PQC رقم 7، الحساب موجود مسبقًا)، ودون خصم رسوم. تحقق من GET /qorechain/pqc/v1/account/{address} قبل تسجيل مفتاح المحفظة الساخنة، كما يُوصى أدناه.
• علامة حيازة اختيارية. يكتسب سجل الحساب حقل possession_proven يبيّن ما إذا جرى التحقق من إثبات الحيازة عند التسجيل؛ ولا يغيّر من يحق له الإرسال أو الاستقبال. راجع التوقيع ما بعد الكمّي.

اختيار مسار التكامل

QoreChain سلسلة واحدة برصيد QOR أصلي موحّد واحد معروض عبر ثلاث واجهات. المفتاح الخاص نفسه يتحكم في الأموال نفسها تحت عنوان Cosmos (qor1...) وعنوان EVM (0x...) وعنوان SVM (بترميز base58) — اختر الواجهة التي تناسب بنيتك التقنية.

	أ) Cosmos (الأصلي)	ب) EVM	ج) SVM (آلة Solana الافتراضية)
العنوان	qor1... (bech32)	0x... (Ethereum)	ترميز base58 الخاص بـ Solana (المفتاح نفسه)
الخانات العشرية (QOR الأصلي)	6 (uqor)	18 (على غرار wei)	9 (lamports؛ 1 uqor = 1,000 lamports)
الأدوات	Cosmos SDK / CosmJS	أدوات Ethereum القياسية (ethers/web3، MetaMask)	@solana/web3.js
توقيع السحوبات	يلزم توقيع PQC هجين (ML-DSA-87 + secp256k1)	secp256k1 قياسي / EIP-155، لكن فقط داخل نافذة تفويض PQC مفتوحة (مفتاح ML-DSA مسجَّل + نافذة تُفتح برسالة Cosmos موقّعة توقيعاً هجيناً)	عبر معاملة Cosmos أو الإرسال المباشر على العقدة (المسار معطَّل حالياً)
دعم الحقل التعريفي (memo / tag)	نعم (عنوان مشترك + memo)	لا (عنوان لكل مستخدم)	لا (عنوان لكل مستخدم)
اكتشاف الإيداعات	فحص أحداث MsgSend	فحص الكتل عبر eth_getBlockByNumber	getBalance / getSignaturesForAddress
الأنسب لـ	المنصات المبنية على Cosmos	المنصات التي لديها تكامل EVM قائم	المنصات التي تعتمد أدوات Solana

التوصية: استخدم المسار أ (Cosmos) للسحوبات؛ فهو المسار الأصلي ويوفّر عناوين إيداع مشتركة قائمة على الـ memo. ومنذ v3.2.0 يتطلب مسار EVM (المسار ب) أيضاً مفتاح ML-DSA-87 مسجَّلاً ونافذة تفويض EVM مفتوحة ومحدودة لا يمكن فتحها إلا برسالة في مسار Cosmos موقّعة توقيعاً هجيناً، لذا يحتاج مسار سحب عبر EVM إلى حزمة التوقيع ما بعد الكمّي نفسها المطلوبة في المسار أ بالإضافة إلى إدارة النوافذ (انظر المسار ب ونافذة تفويض EVM). يبقى المسار ب مناسباً لـ اكتشاف الإيداعات باستخدام أدوات Ethereum القياسية. المسار ج (SVM) هو واجهة كاملة لـ QOR الأصلي من الناحية النظرية، لكن مسار معاملاته معطَّل حالياً على مستوى الشبكة بأكملها (انظر المسار ج) — استخدم المسار أ، أو المسار ب لاكتشاف الإيداعات، إلى أن يُعاد فتحه.

الواجهات الثلاث ليست متنافية — الأموال المرسلة إلى صيغة 0x أو qor1 أو SVM لنفس المفتاح هي الرصيد نفسه.

تشغيل عقدتك

ينبغي لعمليات التكامل الإنتاجية التحقق من الإيداعات مقابل عقدتها المتزامنة الخاصة، لا مقابل نقطة نهاية طرف ثالث. اتبع الاتصال بالشبكة الرئيسية — فهو يغطي حزمة الملفات التنفيذية الجاهزة (مع مجاميع تحقق SHA-256)، وملف genesis، والنظراء العموميين، والحد الأدنى للرسوم (0.1uqor)، وإقلاعًا سريعًا عبر لقطة بيانات السلسلة المنشورة. لا يلزم أي ترخيص لتشغيل عقدة كاملة غير مُصادِقة.

ولأن QoreChain تتمتع بنهائية فورية (لا إعادة تنظيم للكتل)، فإن تأكيدًا واحدًا يعني النهائية؛ والانتظار كتلة أو كتلتين يمنحك هامشًا تشغيليًا مريحًا.

المسار أ — Cosmos (الأصلي)

عنوان REST الأساسي: https://api.qore.host (أو http://localhost:1317 على عقدتك).

مراقبة الإيداعات

# latest height
curl -s https://rpc.qore.host/status | jq -r .result.sync_info.latest_block_height

# all txs in a height (deposit scanning)
curl -s "https://api.qore.host/cosmos/tx/v1beta1/txs/block/{HEIGHT}" | jq '.txs'

# incoming transfers to an address
curl -s "https://api.qore.host/cosmos/tx/v1beta1/txs?query=transfer.recipient='qor1...'&limit=50" | jq '.tx_responses[].txhash'

# balance (uqor — divide by 1e6 for QOR)
curl -s "https://api.qore.host/cosmos/bank/v1beta1/balances/qor1.../by_denom?denom=uqor" | jq -r .balance.amount

قائمة التحقق ضد الإيداعات المزيفة

لا تُقيِّد الإيداع في الحساب إلا عند تحقق جميع الشروط التالية:

1. tx_response.code == 0 — نجحت المعاملة؛ لا تُقيِّد أبدًا معاملة فاشلة.
2. الرسالة هي /cosmos.bank.v1beta1.MsgSend (أو أحد مخرجات MsgMultiSend) — وليست استدعاء عقد أو وحدة أخرى.
3. حقل to_address يساوي عنوان الإيداع الخاص بك، و(في نموذج العنوان المشترك) حقل memo يطابق المستخدم.
4. denom == "uqor" والقيمة amount هي المبلغ المُقيَّد (uqor ← ÷ 10⁶ للحصول على QOR). ارفض أي denom آخر.
5. المعاملة في كتلة ملتزَم بها (قيمة height موجودة و≤ أحدث ارتفاع ملتزَم به). النهائية فورية — تأكيد واحد نهائي؛ انتظر كتلة أو كتلتين للهامش.
6. أعد حساب المبلغ من أحداث التحويل (coin_received / coin_spent) وطابقه مع مبلغ الرسالة — لا تثق أبدًا بحقل واحد أو بالـ memo وحده.
7. تحقق من وجود hash المعاملة عبر GET /cosmos/tx/v1beta1/txs/{hash} مقابل عقدتك المتزامنة الخاصة.

السحوبات — التوقيع الهجين PQC

تفرض الشبكة الرئيسية توقيعات ما بعد كمّية على معاملات cosmos (allow_classical_fallback = false): كل سحب يحتاج إلى توقيع هجين — ML-DSA-87 (Dilithium-5، FIPS-204) بالإضافة إلى secp256k1. الإيداعات لا تحتاج إلى ذلك (أنت تراقب السلسلة فقط).

مكتبة التوقيع هي @qorechain/wallet-adapter (npm)، والتي تجلب معها @qorechain/pqc للأوليات المشفّرة الخاصة بـ FIPS-204:

npm i @qorechain/wallet-adapter @qorechain/pqc @cosmjs/proto-signing@0.32 @cosmjs/stargate@0.32 cosmjs-types@0.9.0
# pin the cosmjs packages to 0.32 (the adapter's peer range) and cosmjs-types to 0.9.x — 0.10 breaks the subpath imports the adapter uses

التوقيع يتم عبر تدفق من خطوتين (يحاكي qorechaind tx pqc cosign):

الخطوة 1 — مرة واحدة لكل محفظة ساخنة: تسجيل مفتاح ML-DSA-87 الخاص بها. معاملة التسجيل الوحيدة هذه موقّعة كلاسيكيًا (إعفاء الإقلاع الأولي، لحساب ليس له مفتاح بعد؛ فبعد وجود مفتاح يجب أن تُوقَّع أي رسالة مفاتيح أخرى توقيعًا هجينًا): الرسالة /qorechain.pqc.v1.MsgRegisterPQCKeyV2 مع {sender, public_key, algorithm_id: 1, key_type: "hybrid"}. اشتق مفتاح ML-DSA بشكل حتمي بحيث يكون قابلًا للاسترداد من سرّك الحالي — مثلًا seed = SHAKE-256("qorechain:pqc:v1|" + address + "|" + mnemonic) ثم mldsa.keygen(seed) — واحفظ الـ seed إلى جانب مفتاح محفظتك الساخنة. التسجيل صريح: لا شيء يسجّل المفتاح نيابةً عنك عند ظهور أول معاملة هجينة، والمفتاح المضمَّن داخل معاملة لا يُعدّ مسجَّلاً. ترفض السلسلة مفاتيح classical_only والمفاتيح التي لا توفّر أي حماية ما بعد كمّية (الرمز 230)، وتتحقق من إثبات امتلاك اختياري عند إرفاقه (في CLI: register-key-v2 ... --pqc-key؛ أما @qorechain/sdk 0.9.0 فترفق إثباتاً بنفسها عبر ensurePqcRegistered متى طبّقت الشبكة v3.2.3، بينما لا ترفقه @qorechain/wallet-adapter 0.4.0، وهذا مقبول). حدّد الغاز صراحةً (يحتاج المفتاح البالغ حجمه 2,592 بايت إلى أكثر من القيمة الافتراضية 200,000؛ استخدم --gas 600000 في سطر الأوامر، وحدّ غاز قدره 600,000 في الشيفرة، ورسماً لا يقل عن الغاز × 0.1 uqor، أي 60,000 uqor).

الخطوة 2 — كل سحب بعد ذلك: توقيع MsgSend توقيعًا هجينًا. يدمج المحوّل توقيع ML-DSA-87 داخل امتداد لجسم المعاملة قبل توقيع secp256k1 العادي عبر signDirect، فيبقى مُوقِّعك الحالي دون تغيير:

import { QoreChainSigner } from "@qorechain/wallet-adapter";
import { MsgSend } from "cosmjs-types/cosmos/bank/v1beta1/tx.js";

// pqc = { publicKey, secretKey } from mldsa.keygen(seed)
// accountNumber + sequence from the auth query
const signer = new QoreChainSigner({ wallet, chainId: "qorechain-vladi",
  rest: "https://api.qore.host",   // used to pick the network's hybrid sign-bytes form (required on mainnet and testnet)
  address, pubkeySecp256k1, accountNumber, pqc });
const txBytes = await signer.signHybrid({
  messages: [{ typeUrl: "/cosmos.bank.v1beta1.MsgSend",
    value: MsgSend.encode(MsgSend.fromPartial({ fromAddress, toAddress,
      amount: [{ denom: "uqor", amount: "1000000" }] })).finish() }],
  fee: { amount: [{ denom: "uqor", amount: "40000" }], gasLimit: 400000n },
  sequence });

بثّ البايتات الموقّعة:

curl -s -X POST https://api.qore.host/cosmos/tx/v1beta1/txs \
  -H 'Content-Type: application/json' \
  -d '{"tx_bytes":"<base64-signed-tx>","mode":"BROADCAST_MODE_SYNC"}' | jq .tx_response.code
# 0 => accepted into the mempool
# code 20 "hybrid PQC signature required" => the transaction carries no PQC extension
#   (a classical-only transaction is refused; only the key registration itself is exempt)
# code 21 => the PQC half did not verify (wrong key or sign-bytes form), see the troubleshooting link below

ثم استعلم دوريًا عبر GET /cosmos/tx/v1beta1/txs/{hash} حتى تظهر المعاملة في كتلة مع code == 0.

إذا كنت تستخدم HSM أو مُوقِّعًا مخصصًا بلغة أخرى، فاستخدم مكتبات qorechain-pqc المستقلة الخاصة بـ FIPS-204 (npm وPyPI وcrates.io وMaven Central وGo) وركّب الامتداد نفسه. تقبل السلسلة أي توقيع ML-DSA-87 صالح وفق FIPS-204، سواء كان مُحوَّطًا (hedged) أو حتميًا؛ والتوقيع الحتمي (FIPS-204 §3.4، وهو الافتراضي في المكتبات) يمنحك توقيعًا وتجزئة معاملة قابلين لإعادة الإنتاج. انظر التوقيع الحتمي، واستكشاف أخطاء الرمز 21 إذا رُفضت معاملة هجينة.

البديل على جانب الخادم: @qorechain/chain-bridge

لعامل محفظة ساخنة يعمل بالكامل على جانب الخادم (دون أي محفظة متصفح)، تغلّف حزمة @qorechain/chain-bridge (npm) التدفق بأكمله — اشتقاق المفاتيح، والتوقيع الهجين، والبث — في استدعاء واحد. وهي JavaScript خالص (بدون إضافات أصلية)، ومناسبة للعوامل بلا خوادم (serverless):

import { ChainBridge } from "@qorechain/chain-bridge";

const bridge = new ChainBridge({
  cosmosRpc: "https://rpc.qore.host",       // or your own node
  cosmosRest: "https://api.qore.host",      // used to pick the network's hybrid sign-bytes form (required on mainnet and testnet)
  chainId: "qorechain-vladi",
  signerMnemonic: process.env.HOT_WALLET_MNEMONIC,  // from your secrets manager
});

// One call: derives the canonical ML-DSA-87 key, hybrid-signs the MsgSend, and broadcasts.
// Amounts are in uqor (6 decimals). Register the key beforehand with bridge.registerPqc({ mnemonic }).
const { txHash } = await bridge.sendTokens({
  to: "qor1recipient...",
  amountUqor: "1000000",   // 1 QOR
});

إذا لم يكن للحساب مفتاح مسجَّل بعد، فإن المكتبة نفسها ترسل معاملة MsgRegisterPQCKeyV2 الصريحة وتعيد المحاولة مرة واحدة؛ وهذا سلوك المكتبة لا سلوك السلسلة، لذا ينبغي لمسار المحفظة الساخنة تسجيل المفتاح مسبقاً والتأكد منه (GET /qorechain/pqc/v1/account/{address}) قبل أول سحب. ابتداءً من chain-bridge 0.2.3، ومع ضبط cosmosRest، يحمل التسجيل إثبات الامتلاك متى طبّقت الشبكة v3.2.3، وقبل أي إعادة تسجيل تقرأ المكتبة حالة السلسلة: فإذا كان الحساب يحمل مفتاحاً هو ليس المفتاح القانوني ولا القديم لعبارتك الاسترجاعية (mnemonic) فإنها ترمي الخطأ pqc_key_mismatch ولا ترسل شيئاً (فالتسجيل المتكرر يكلّف رسمه ويُرفض). تستخدم chain-bridge (≥0.1.1) نفس اشتقاق PQC القانوني المرتبط بالعنوان المستخدم في بقية الحزم — SHAKE-256("qorechain:pqc:v1|address|mnemonic") — لذا فالمفتاح قابل للاسترداد من العبارة الاسترجاعية (mnemonic) عبر qorechaind tx pqc recover-key. الحسابات المسجَّلة بأدوات أقدم تُعالَج تلقائيًا (الرجوع إلى المفتاح القديم)، ويمكن ترحيلها مرة واحدة إلى المفتاح القانوني عبر MsgRotatePQCKey.

المسار ب — EVM

تكامل Ethereum قياسي مقابل https://evm.qore.host (معرّف السلسلة 9801) أو المنفذ 8545 على عقدتك الخاصة.

• الخانات العشرية: يمتلك QOR الأصلي 18 خانة عشرية على مسار EVM (1 uqor = 10¹² wei). الخطأ في هذا يؤدي إلى تقييد الإيداعات بشكل خاطئ بمعامل 10¹².
• الإيداعات: افحص الكتل عبر eth_getBlockByNumber بحثًا عن التحويلات الأصلية إلى عناوينك؛ وأكّدها عبر eth_getTransactionReceipt (‏status == 0x1). معاملات EVM الخاصة بالمودِعين تخضع بدورها لقاعدة النافذة، لذا لا يستطيع مستخدم لا يملك حسابه مفتاحاً مسجَّلاً أو نافذة مفتوحة إرسال إيداع من مسار EVM (ويمكنه استخدام مسار Cosmos بدلاً من ذلك)، وتُرفض تماماً أي معاملة موقّعة دون معرّف سلسلة (ما قبل EIP-155). وقد يكون للنافذة نطاق محدد (native_only، allowed_targets)، لذا فالإيداع المقبول هو دائماً تحويل أصلي أو استدعاء تسمح به النافذة؛ ومع ذلك اقرأ الإيصال بدلاً من الافتراض.
• السحوبات: توقيع secp256k1 قياسي / EIP-155، لكن فقط من حساب لديه مفتاح ML-DSA-87 مسجَّل ونافذة تفويض EVM مفتوحة (منذ v3.2.0؛ انظر نافذة تفويض EVM والشرح التفصيلي في معاملتك الأولى). تُرفض أي معاملة خارج النافذة (النطاق pqc، الرموز 26 أو 27 أو 28). يجب فتح النافذة بمعاملة في مسار Cosmos موقّعة توقيعاً هجيناً، لذا لا يُلغي المسار ب الحاجة إلى التوقيع ما بعد الكمّي؛ حدّد max-value بحيث يغطي القيمة بالإضافة إلى الرسوم القصوى (حد الغاز × الحد الأقصى للرسوم لكل وحدة غاز) لكل سحب تتوقعه داخل النافذة (وللمحفظة الساخنة التي ترسل QOR العادي فقط، أضف --native-only عند فتحها)، وراقب GET /qorechain/pqc/v1/evm_window/{address} كي لا تنفد النافذة من المحفظة الساخنة في منتصف الدفعة. يؤدي فتح النافذة إلى زيادة رقم تسلسل الحساب، وهو أيضاً nonce الخاص بـ EVM، لذا اقرأ الـ nonce بعد فتح النافذة.
• مكافحة الإيداعات المزيفة: تحقق من حالة الإيصال، ومن أن القيمة المنقولة هي تحويل أصلي (وليست حدث ERC-20 لا تُفهرسه)، وأكّد ذلك مقابل عقدتك الخاصة.
• مطابقة العناوين: عنوان 0x وعنوان qor1 هما ترميزان للحساب نفسه — والأموال مشتركة. انظر تطوير EVM.

المسار ج — SVM (متوافق مع Solana)

مسار SVM معطَّل حاليًا

مسار تنفيذ SVM معطَّل حاليًا على مستوى الشبكة بأكملها بالنسبة لإرسال المعاملات اعتبارًا من إصدار السلسلة v3.1.89 (22 أغسطس) — أي معاملة تُرسَل إليه تُعيد code 11, "SVM module is disabled". لا تُنشئ مسار إيداع/سحب على المسار ج إلى أن يُعاد فتح هذا المسار — هذا تعطيل عند وقت الترجمة وليس معاملاً وقت التشغيل، لذا لا يمكن إعادة تشغيله بتصويت حوكمة؛ ويُتوقع أن يبقى معطَّلاً إلى أن يجيزه تدقيق خارجي. استخدم المسار أ (Cosmos) أو المسار ب (EVM) بدلاً من ذلك. قد تظل نقاط نهاية القراءة (مثل getBalance) تستجيب، لكن لا تبنِ اكتشاف الإيداعات أو تدفقات السحب مقابل SVM أثناء تعطيل إرسال المعاملات.

اعتبارًا من الإصدار v3.1.82 تخدم واجهة SVM عملة QOR الأصلية (انظر QOR الأصلي على واجهة SVM):

• الأرصدة: يُرجع getBalance القيمة بوحدة lamports (÷ 10⁹ للحصول على QOR؛ 1 uqor = 1,000 lamports).
• الإيداعات: يعطي getSignaturesForAddress سجل المعاملات لعنوان ما؛ وتحويلات System Program تنقل QOR الأصلي.
• نقاط النهاية العامة (https://svm.qore.host، ‏https://svm-testnet.qore.host) هي للقراءة فقط؛ أرسل المعاملات عبر عقدتك الخاصة.

ملخص التدفق

العملية	المسار	هل يلزم التوقيع؟
الإيداع (المستخدم ← المنصة)	راقب عقدتك المتزامنة بحثًا عن تحويلات إلى عنوانك (+ الـ memo على Cosmos)	لا — مراقبة فقط
السحب (المنصة ← المستخدم)	ابنِ التحويل، وقّع دون اتصال، ثم ابثّ المعاملة	Cosmos: توقيع PQC هجين · EVM: secp256k1 قياسي داخل نافذة مفوَّضة بـ PQC
الرصيد / التجميع	استعلام رصيد عبر REST / EVM / SVM + تحويل	التوقيع مطلوب لعملية التجميع فقط

مواضيع ذات صلة

• الاتصال بالشبكة الرئيسية — إعداد العقدة، التنزيلات، اللقطة
• تشغيل عقدة — النشر، التقليم، الفهرسة
• التوقيع ما بعد الكمّي — مكتبات FIPS-204 التي تقف خلف السحوبات الهجينة
• الشبكات — معرّفات السلاسل، نقاط النهاية، الخانات العشرية لكل واجهة