श्वेतपत्र · 06

कोर मानक

A-REX Core के प्रत्येक तत्व का औचित्य: बैच रिकॉर्ड में ठीक यही फ़ील्ड क्यों हैं, वंशावली मैपिंग के बजाय ऑपरेशन क्यों है, प्रवर्तन ERC-7943 से क्यों आता है, एन्यूम की जगह कोड क्यों लेते हैं, और किन सबकों ने डिज़ाइन को आकार दिया।

डिज़ाइन लक्ष्य: सबसे छोटा इंटरफ़ेस जिसे कोई तृतीय पक्ष लागू करेगा

किसी मानक को तब अपनाया जाता है जब उसे लागू करने की लागत अंतरसंचालनीय न होने की लागत से कम हो। A-REX Core के प्रत्येक फ़ील्ड, फ़ंक्शन और नियम को एक परीक्षा पास करनी थी: क्या अर्जेंटीना में ग्रेन एलिवेटर प्लेटफ़ॉर्म या कोलंबिया में कॉफ़ी निर्यातक की प्रणाली बनाने वाली कोई स्वतंत्र टीम अंतरसंचालनीयता के बदले यह बाध्यता स्वीकार करेगी? फ़सलों के एन्यूमरेशन, अमेरिकी ग्रेड नाम, अनिवार्य फ़ार्म रजिस्ट्री, निर्धारित पहचान स्टैक और मूल्यांकन सूत्र, सभी इस परीक्षा में विफल रहे। बैच पहचान, वंशावली, प्रवर्तन और एक एक्सटेंशन बिंदु उसमें उत्तीर्ण हुए।

फ़ील्ड-दर-फ़ील्ड बैच रिकॉर्ड

फ़ील्ड	यह ऑन-चेन क्यों है	इसका आकार ऐसा क्यों है
`commodity: bytes32`	हुक, मार्केटप्लेस और नियामकों के लिए मेटाडेटा पार्स किए बिना उत्पाद के आधार पर फ़िल्टर कर सकना अनिवार्य है	`keccak256("HS:100199")` मानक में किसी तालिका के बिना किसी भी योजना (HS, FAO/CPC, GTIN, राष्ट्रीय कोड) को स्वीकार करता है; एन्यूम डिप्लॉयमेंट के समय ही दुनिया की फ़सल-सूची को तय कर देता
`unit: bytes32`	इकाई के बिना मात्राएँ अर्थहीन हैं; `1000` का ट्रांसफ़र 1000 किग्रा है या 1000 बॉक्स	UN/CEFACT Recommendation 20 वह कोड सूची है जिसका उपयोग EDI, EPCIS और सीमा शुल्क में होता है
`producedAt: uint64`	नाशवानता, सीज़नलता और फ़ॉरवर्ड कॉन्ट्रैक्ट, सभी उत्पादन समय पर निर्भर करते हैं	`0` का अर्थ है "अभी उत्पादित नहीं": फ़सल प्राप्य, फ़ॉरवर्ड और भावी फ़सलों पर वारंट लैटिन अमेरिका में कृषि वित्तपोषण के प्रमुख लिखत हैं और उनका निरूपण संभव होना अनिवार्य है
`expiresAt: uint64`	कृषि में सबसे आम ट्रांसफ़र नियम है "इस तिथि के बाद नहीं"	`0` का अर्थ है कोई नहीं; समाप्ति का क्या अर्थ है, यह हुक तय करते हैं
`originRef: bytes32`	उद्गम का सिद्ध किया जा सकना अनिवार्य है (EUDR, जैविक, भौगोलिक संकेतक)	एक हैश या संदर्भ, कभी निर्देशांक नहीं: उत्पादक का प्लॉट जियोलोकेशन व्यक्तिगत डेटा है (EDPB Guidelines 02/2025 v2.0, जुलाई 2026) और एक अपरिवर्तनीय सार्वजनिक चेन डेटा मिटाने के अनुरोध का पालन नहीं कर सकती
`metadataHash: bytes32` + `uri`	बाकी सब ऑफ़-चेन है, परंतु टोकन का उसके प्रति कमिट करना अनिवार्य है	प्रकाशित स्कीमा का पालन करने वाले कैनोनिकल JSON दस्तावेज़ का हैश; `uri` IPFS, HTTPS या GS1 Digital Link हो सकता है
`status: uint8`	लॉट एक जीवनचक्र से गुज़रता है और कुछ स्थितियों में गति का अवरुद्ध होना अनिवार्य है	दो निश्चित बिंदुओं (`0` सक्रिय, `255` रिटायर) वाले खुले मान; पिछला नौ-स्थिति वाला एन्यूम एक आपूर्ति शृंखला की शब्दावली को कोड करता था और किसी भी धारक द्वारा बदला जा सकता था
`issuer`, `createdAt`	जवाबदेही और ऑडिट	कॉन्ट्रैक्ट द्वारा सेट, कॉलर द्वारा कभी नहीं

जो जान-बूझकर अनुपस्थित है: अक्षांश और देशांतर, फ़ार्म आइडेंटिफ़ायर, ग्रेड एन्यूम, नमी और प्रोटीन, सत्यापन फ़्लैग और सत्यापनकर्ता का पता, quantity फ़ील्ड (ERC-1155 सप्लाई ट्रैकिंग प्रामाणिक है), और मूल्य की कोई भी धारणा।

वंशावली एक ऑपरेशन के रूप में

PROCESSED स्थिति वाला जीवनचक्र, पर प्रसंस्कृत वस्तु बनाने का कोई तरीका नहीं — यह एक आम भूल है। ट्रेसेबिलिटी व्यवस्थाएँ स्पष्ट हैं कि ट्रांसफ़ॉर्मेशन एक इवेंट है जो इनपुट को आउटपुट से जोड़ता है: FSMA 204 का ट्रांसफ़ॉर्मेशन क्रिटिकल ट्रैकिंग इवेंट, inputQuantityList और outputQuantityList के साथ EPCIS 2.0 का TransformationEvent। किसी प्रशासक द्वारा लिखी गई पैरेंट की मैपिंग न मात्राएँ वहन करती और न एटॉमिकता।

transform(from, to, inputIds, inputAmounts, outputs, outputAmounts, processRef) एक ही ट्रांज़ैक्शन में बर्न और मिंट करता है, प्रत्येक आउटपुट पर पैरेंट दर्ज करता है, सभी मात्राओं और एक प्रक्रिया संदर्भ के साथ एक इवेंट इमिट करता है, और प्रत्येक लेग पर हुक पाइपलाइन चलाता है। विभाजन (1→n), मर्ज (n→1) और प्रसंस्करण (n→m) एक ही फ़ंक्शन हैं। संदर्भ कार्यान्वयन किसी भी धारक को री-बैच करने देता है (समान कमोडिटी और इकाई, संरक्षित मात्रा), परंतु वस्तुओं की प्रकृति या मात्रा बदलने के लिए TRANSFORMER_ROLE की आवश्यकता रखता है — मिल गेहूँ को आटे में बदल सकती है, किसान गेहूँ को सोने में नहीं बदल सकता।

प्रवर्तन ERC-7943 से, नए सिरे से नहीं गढ़ा गया

कृषि लॉट पर नियमित रूप से ग्रहणाधिकार, वारंट, एम्बार्गो, दिवाला कार्यवाहियाँ और रिकॉल लागू होते हैं। जो टोकन किसी अधिकृत पक्ष द्वारा धारक की इच्छा के विरुद्ध फ़्रीज़ या ट्रांसफ़र नहीं किया जा सकता, वह ऐसे लॉट का निरूपण बैंक, न्यायालय या नियामक के सामने नहीं कर सकता। ERC-3643 ने 2021 में प्रतिभूतियों के लिए इसे हल किया; ERC-7943 ने इसे किसी भी वास्तविक-जगत परिसंपत्ति के लिए सामान्यीकृत किया और मई 2026 में ERC-1155 संस्करण के साथ Final स्थिति तक पहुँचा। A-REX उस इंटरफ़ेस को अपना स्वयं का परिभाषित करने के बजाय शब्दशः अपनाता है, ताकि ERC-7943-जागरूक अनुपालन इंजन (Chainlink ACE, ERC-3643 टूलिंग) बिना अनुकूलन के A-REX टोकन को पहचान लें।

मल्टी-टोकन संस्करण ERC-1155 में स्वाभाविक रूप से बैठता है: फ़्रीज़ करना प्रति खाता और प्रति बैच आईडी होता है, बलपूर्वक ट्रांसफ़र बैच का नाम बताते हैं, पात्रता प्रति खाता होती है।

एक हुक, क्रमबद्ध, कोड के साथ

पाँच क्षमता इंटरफ़ेस पर बना मॉड्यूल सिस्टम, जिनमें से प्रत्येक की प्रत्येक ट्रांसफ़र पर supportsInterface से जाँच की जाती है, स्केल नहीं करता; आठ मॉड्यूल और बैच ट्रांसफ़र में पाँच आईडी के साथ किसी भी नियम के चलने से पहले अस्सी स्थिर कॉल हो जाती थीं। अस्वीकृतियाँ मुक्त-रूप स्ट्रिंग थीं जिन्हें कोई इंडेक्सर समझ नहीं सकता था और कोई टेस्ट विश्वसनीय रूप से तुलना नहीं कर सकता था।

A-REX Core एक हुक इंटरफ़ेस परिभाषित करता है, जिसमें पंजीकरण के समय कैश किया गया स्थिर फ़्लैग बिटमैप होता है। टोकन हुक का निश्चित क्रम में मूल्यांकन करता है और पहले गैर-शून्य bytes32 कोड पर रुक जाता है, ARexHookRejected(hook, code) के साथ रिवर्ट करते हुए। क्रम ऑडिट-योग्य है (getHooks), हटाने पर वह बना रहता है, और हुक को msg.sender से कॉल करने वाले टोकन का पता चलता है, इसलिए एक डिप्लॉयमेंट अनेक टोकन की सेवा करता है। पात्रता (canSend/canReceive) को उसी इंटरफ़ेस में समाहित किया गया है ताकि टोकन के ERC-7943 व्यू उसके हुक का संयोजन हों।

हुक से कस्टम एरर के बजाय कोड क्यों? क्योंकि check एक व्यू है जिसका संयोज्य होना अनिवार्य है: टोकन को प्रत्येक हुक से पूछना, उत्तरों की तुलना करना, और रिवर्ट किए बिना transferCheck के माध्यम से पहला उत्तर उपलब्ध कराना होता है। कोड सस्ते, इंडेक्स-योग्य, अनुवाद-योग्य और नेमस्पेस-युक्त हैं (keccak256("AREX:BATCH_EXPIRED"), keccak256("MYHOOK:QUOTA"))।

प्रति बैच एटेस्टेशन, प्रति विषय जारीकर्ता

किसी उत्पादक को प्रमाणित करना एक पहचान समस्या है जिसके परिपक्व समाधान हैं (ONCHAINID, Ethereum Attestation Service, वेरिफ़ायबल क्रेडेंशियल, राष्ट्रीय e-ID)। किसी लॉट को प्रमाणित करना वही है जो क्रेता, सीमा शुल्क अधिकारी और नियामक सत्यापित करते हैं, और उसका कोई मानक रूप नहीं था। IARexAttest (batch, topic) → (issuer, reference, validity) दर्ज करता है और प्रशासक को यह तय करने देता है कि कौन-सा जारीकर्ता किस विषय पर एटेस्ट कर सकता है, जो ERC-3643 की विश्वसनीय-जारीकर्ता रजिस्ट्री को प्रतिबिंबित करता है, बिना किसी पहचान प्रदाता को निर्धारित किए। विषय खुले bytes32 हैं, इसलिए ERC-735 दावा विषय, EAS स्कीमा आईडी और प्रमाणन नामों के हैश साथ-साथ मौजूद रह सकते हैं।

isAttested वह एकमात्र प्रश्न है जो कोई हुक पूछता है: यह false है यदि एटेस्टेशन अनुपस्थित, निरस्त या समाप्त है, या उसके जारीकर्ता ने विश्वास खो दिया है। इससे हुक छह पंक्तियों में "कॉफ़ी बैच को बेचे जाने से पहले EUDR ड्यू-डिलिजेंस संदर्भ चाहिए" लागू कर सकता है।

मानक क्या नहीं कहता

यह नहीं कहता कि बैच कौन बना सकता है, स्टेटस कौन बदल सकता है या प्रवर्तन कौन कर सकता है — केवल इतना कि ये भूमिकाएँ हैं, कभी बैलेंस नहीं।
यह नहीं कहता कि स्टेटस 1..254 का क्या अर्थ है; जारीकर्ता मेटाडेटा में तालिका प्रकाशित करता है।
यह नहीं कहता कि बैच का मूल्यांकन कैसे हो, वह कैसे क्षय हो, सीज़नल रूप से उसका व्यापार कब हो सकता है, उसकी डिलीवरी या बीमा कैसे हो: ये सब हुक या सहायक कॉन्ट्रैक्ट हैं।
यह नहीं कहता कि कौन-सी चेन, कौन-सा पहचान प्रदाता, कौन-सा ऑरेकल, कौन-सी रजिस्ट्री।
यह नहीं कहता कि टोकन प्रतिभूति है या कमोडिटी।

वे सबक जिन्होंने डिज़ाइन को आकार दिया

सबक	A-REX Core में परिणाम
जिस मानक में फ़ार्म रजिस्ट्री और पहचान प्रणाली अनिवार्य के रूप में शामिल हों, वह टोकन मानक नहीं, एक उत्पाद है	टोकन के बाहर कुछ भी अनिवार्य नहीं है
फ़ंक्शन सिग्नेचर में बंद एन्यूम कमोडिटी की किसी भी "डायनामिक रजिस्ट्री" को डेड कोड बना देता है	कमोडिटी, इकाइयाँ, स्टेटस और विषय खुले कोड हैं
बैलेंस से व्युत्पन्न प्राधिकार बहु-धारक टोकन में एक कमज़ोरी है	स्टेटस परिवर्तन भूमिका-नियंत्रित हैं; RETIRED अंतिम है
कोर में बिज़नेस लॉजिक "बिज़नेस लॉजिक के बिना कोर" का खंडन करता है	मूल्यांकन, क्षय और विंडो हुक में रहते हैं
जो बिल्ड साफ़ क्लोन से कंपाइल नहीं होता, वह संदर्भ कार्यान्वयन नहीं है	डिपेंडेंसी पिन की गई, लॉकफ़ाइल कमिट की गई, प्रत्येक पुश पर CI
श्वेतपत्र में विनियामक तिथियाँ पुरानी पड़ जाती हैं; उन पर निर्भर कोड का पुराना पड़ना स्वीकार्य नहीं है	टोकन संदर्भ और हैश संग्रहीत करता है, विनियामक तर्क कभी नहीं

पश्चगामी संगतता

A-REX Core टोकन पूर्ण ERC-1155 और ERC-7943 टोकन हैं। ERC-1155 को जानने वाले वॉलेट, मार्केटप्लेस और इंडेक्सर बिना बदलाव के काम करते हैं; ERC-7943-जागरूक अनुपालन टूलिंग प्रवर्तन सतह को पहचानती है। अन्य टोकनों के लिए लिखे गए नियम इंजन IARexHook एडेप्टर के माध्यम से जुड़ते हैं, बशर्ते उनके निर्णय केवल कॉल पैरामीटर और बैच रिकॉर्ड पर निर्भर करते हों।