श्वेतपत्र · 12

अंतरसंचालनीयता

A-REX टोकन मौजूदा दुनिया में कैसे फ़िट होता है: Ethereum टोकन मानक, अनुपालन इंजन, ट्रेसेबिलिटी डेटा मानक, विधिक-दस्तावेज़ रजिस्ट्री, पहचान प्रणालियाँ, क्रॉस-चेन इन्फ्रास्ट्रक्चर और मौजूदा फ़ार्म सिस्टम।

Ethereum इकोसिस्टम के साथ

A-REX Core टोकन एक ERC-1155 टोकन है। ERC-1155 को समझने वाले वॉलेट, एक्सप्लोरर, मार्केटप्लेस और इंडेक्सर बिना बदलाव के काम करते हैं: बैलेंस, बैच ट्रांसफ़र, uri(id), अनुमोदन, सेफ़-ट्रांसफ़र रिसीवर जाँच। A-REX इवेंट और व्यू जोड़ता है; कुछ हटाता नहीं।

A-REX Core टोकन एक ERC-7943 मल्टी-टोकन है। ERC-7943 को लक्षित करने वाले अनुपालन इंजन और अभिरक्षा प्लेटफ़ॉर्म (Chainlink के Automated Compliance Engine ने संगतता प्रदर्शित की है; ERC-7943 गठबंधन के जारीकरण प्लेटफ़ॉर्म इसे अपना रहे हैं) canTransfer, forcedTransfer, setFrozenTokens, canSend और canReceive को बिना अनुकूलन के पहचानते हैं।

मानक	संबंध
ERC-1155	आधार; A-REX Core एक एक्सटेंशन है
ERC-165	इंटरफ़ेस खोज; पाँच आईडी प्रकाशित
ERC-7943	अनिवार्य; प्रवर्तन सतह शब्दशः अपनाई गई
ERC-3643	अनुकूलन द्वारा संगत: ERC-3643 अनुपालन मॉड्यूल को `IARexHook` के रूप में रैप किया जा सकता है (`moduleCheck` की एक कॉल); A-REX हुक को ERC-3643 टोकन के सामने उपलब्ध कराया जा सकता है। ERC-3643 के साथ उपयोग की जाने वाली पहचान रजिस्ट्री (ONCHAINID) पात्रता हुक के रूप में जुड़ती हैं।
ERC-735 / ONCHAINID दावे	दावा विषय सीधे `IARexAttest` विषयों से मैप होते हैं (`bytes32(uint256 topic)`)
Ethereum Attestation Service	स्कीमा UID वैध `IARexAttest` विषय हैं; EAS-समर्थित एटेस्टेशन रजिस्ट्री `isAttested` को प्रत्यायोजित करके `IARexAttest` लागू कर सकती है
ERC-7201	संदर्भ कार्यान्वयन का स्टोरेज लेआउट
ERC-7573, होल्ड/एस्क्रो पैटर्न	डिलीवरी-बनाम-भुगतान और एस्क्रो हुक या सहायक कॉन्ट्रैक्ट हैं; मानक निपटान निर्धारित नहीं करता
ERC-7802 / Chainlink CCIP	क्रॉस-चेन मिंट/बर्न एडेप्टर टोकन को रैप कर सकते हैं; वंशावली मूल चेन पर रहती है, संदर्भ यात्रा करते हैं

ट्रेसेबिलिटी डेटा मानकों के साथ

GS1 EPCIS 2.0 / CBV

ऑन-चेन	EPCIS 2.0
`BatchCreated`	`ObjectEvent` ADD, `bizStep = commissioning`/`harvesting`, `quantityList` (इकाई Rec. 20 से)
`TransferSingle` / `TransferBatch`	`ObjectEvent` OBSERVE, `bizStep = shipping`/`receiving` के साथ; स्रोत/गंतव्य `from`/`to` से
`BatchTransformed`	`TransformationEvent` (`inputQuantityList`, `outputQuantityList`, `transformationID`)
`BatchStatusChanged`	`disposition` के साथ `ObjectEvent`
`Attested`	प्रमाणन / सेंसर तत्व या समर्पित `ObjectEvent`
मेटाडेटा `gs1.*`	GTIN, LGTIN, SSCC, GLN, Digital Link

मेटाडेटा स्कीमा जान-बूझकर EPCIS/CBV नामों का उपयोग करती है ताकि निर्यातक अवधारणाओं को नहीं, फ़ील्ड को मैप करे।

FSMA 204

प्रमुख डेटा तत्व मेटाडेटा फ़ील्ड (traceabilityLotCode, GLN, तिथियाँ, मात्राएँ) और इवेंट हैं; ट्रांसफ़ॉर्मेशन CTE BatchTransformed है; 24 घंटे का रिकॉर्ड अनुरोध एक इंडेक्सर क्वेरी है। पूर्ण मैपिंग के लिए विनियामक अध्याय देखें।

Codex, ISO 22000, GLOBALG.A.P., जैविक योजनाएँ

सभी एटेस्टेशन विषय हैं। मानक उन्हें गिनाता नहीं: keccak256("GLOBALGAP:IFA"), keccak256("AREX:CERT:ORGANIC_EU"), keccak256("CODEX:MRL") ऐसी परंपराएँ हैं जिन्हें जारीकर्ता अपने मेटाडेटा स्कीमा के साथ प्रकाशित करता है।

विधिक-दस्तावेज़ रजिस्ट्री के साथ

A-REX टोकन विधिक लिखतों को संदर्भित करते हैं; जब तक कोई क्षेत्राधिकार स्वयं टोकन को मान्यता नहीं देता, वे उनकी जगह नहीं लेते:

लिखत	कहाँ रहता है	टोकन उसे कैसे संदर्भित करता है
U.S. इलेक्ट्रॉनिक वेयरहाउस रसीद (7 CFR 869)	USDA-अधिकृत EWR प्रदाता	`documents[].registry`, `originRef`
ब्राज़ीली CPR-e, CDA/WA	केंद्रीय बैंक-अधिकृत रजिस्ट्रार	`documents[].registryId`; `producedAt == 0` वाला कटाई-पूर्व बैच
अर्जेंटीनी certificado de depósito / warrant (Law 9.643)	वेयरहाउस	`originRef` हैश
इलेक्ट्रॉनिक बिल ऑफ़ लैडिंग (MLETR क्षेत्राधिकार)	eBL प्लेटफ़ॉर्म	दस्तावेज़ हैश; MLETR क्षेत्राधिकारों में टोकन स्वयं अनन्य नियंत्रण को पूरा कर सकता है
EUDR ड्यू-डिलिजेंस कथन	EU Information System	`origin.eudr.ddsReference`, एटेस्टेशन `EUDR:DDS`

पहचान प्रणालियों के साथ

टोकन केवल canSend(account) / canReceive(account) पूछता है। उस प्रश्न के पीछे हो सकता है:

जारीकर्ता द्वारा संचालित अनुमति/ब्लॉक सूची (EligibilityHook);
दावा विषयों वाली ONCHAINID पहचान रजिस्ट्री (ERC-3643 मॉडल);
खाते पर Ethereum Attestation Service के एटेस्टेशन;
वेरिफ़ायबल क्रेडेंशियल जिन्हें ऑफ़-चेन सत्यापित किया जाता है और रिले करने वाले द्वारा ऑन-चेन प्रतिबिंबित किया जाता है;
क्रेडेंशियल सत्यापनकर्ता के माध्यम से राष्ट्रीय e-ID योजना (EU में eIDAS 2.0 वॉलेट)।

इनमें से कोई भी मानक का हिस्सा नहीं है, यही कारण है कि ब्राज़ील और जर्मनी के जारीकर्ता अलग-अलग प्रदाताओं का उपयोग कर सकते हैं और फिर भी अंतरसंचालनीय बने रह सकते हैं।

क्रॉस-चेन डिप्लॉयमेंट

मानक चेन-अज्ञेयवादी है। व्यावहारिक पैटर्न:

प्रति जारीकर्ता एक होम चेन (अनुशंसित): वंशावली और प्रवर्तन सुसंगत रहते हैं; अन्य चेन ERC-7802-शैली एडेप्टर या CCIP के माध्यम से रैप किए गए निरूपण रखती हैं।
अनुमति-आधारित EVM चेन उन जारीकर्ताओं के लिए जिनका डेटा-संरक्षण प्राधिकरण या एंकर संस्था इसे अपेक्षित करती है; EDPB अनुमति-आधारित डिज़ाइनों का स्पष्ट रूप से पक्षधर है। वही बाइटकोड।
तरलता के लिए मिरर: होम चेन पर बैच आईडी, अन्यत्र ERC-20 रैपर; रैपर के लिए होम टोकन के canTransfer का पालन करना या स्वयं को पात्र धारकों तक सीमित रखना अनिवार्य है।

वंशावली कभी चेन पार नहीं करती; संदर्भ करते हैं।

फ़ार्म प्रबंधन और ERP प्रणालियों के साथ

इंटीग्रेशन बिंदु किसी भी ERC-1155 टोकन जैसे ही हैं, साथ में बैच व्यू:

राइट पाथ: एक ओरिजिनेशन सेवा ISSUER_ROLE रखती है और ERP इवेंट (वेब्रिज टिकट, रसीद जारी करना) से createBatch कॉल करती है; वेयरहाउस इवेंट से setBatchStatus/setBatchMetadata; प्रोसेसिंग ऑर्डर से transform।
रीड पाथ: एक इंडेक्सर बैच, वंशावली, एटेस्टेशन और प्रवर्तन इवेंट को ERP की ट्रेसेबिलिटी तालिकाओं में मटीरियलाइज़ करता है; साझेदारों और नियामकों के लिए EPCIS निर्यात।
प्री-फ़्लाइट: transferCheck ERP को ट्रांज़ैक्शन सबमिट करने से पहले किसी ऑपरेटर को इनकार का कारण समझाने देता है।
आइडेंटिफ़ायर: मेटाडेटा में GS1 कुंजियाँ मौजूदा EDI और EPCIS रिपॉज़िटरी से सेतु बनाती हैं; UN/CEFACT इकाइयाँ ERP में पहले से हैं।

संगतता मैट्रिक्स

क्षमता	स्थिति
ERC-1155 वॉलेट / मार्केटप्लेस	नेटिव
ERC-7943 अनुपालन टूलिंग	नेटिव
ERC-3643 अनुपालन मॉड्यूल	हुक एडेप्टर के माध्यम से
ERC-735 / EAS एटेस्टेशन	विषय मैपिंग
EPCIS 2.0 निर्यात	स्कीमा में फ़ील्ड मैपिंग; इंडेक्सर-पक्ष
अनुमति-आधारित EVM	वही बाइटकोड
क्रॉस-चेन	रैपर; वंशावली होम पर रहती है