हमने SPL tokens को डिप्लॉय किया है और उनके साथ इंटरैक्ट किया है, लेकिन उनमें से किसी के साथ भी नाम, प्रतीक (symbol), या कोई metadata जुड़ा नहीं था। इसके बजाय, हमने प्रत्येक टोकन को उसके mint account address से पहचाना। इसके विपरीत, ERC20 टोकन में टोकन के नाम और प्रतीक को पढ़ने के लिए फ़ंक्शन शामिल होते हैं (लेकिन यह ध्यान देने योग्य है कि ये केवल मानव-पठनीय (human-readable) सुविधाएं हैं, ऐसा कुछ भी नहीं है जो अलग-अलग टोकन को एक ही नाम या प्रतीक रखने से रोकता हो)। ERC721 और ERC1155 में एक tokenURI फ़ंक्शन भी शामिल होता है जो ऑफ-चेन (off-chain) metadata की ओर इशारा करने वाला URI लौटाता है।

लेकिन जैसा कि हमने अब तक देखा है, SPL mint account में नाम, प्रतीक या URI फ़ील्ड नहीं होता है।

Solana पर इसके लिए दो मुख्य समाधान हैं:

• Metaplex Token Metadata Standard
• SPL Token-2022

The Metaplex Token Metadata Standard: Solana पर टोकन में metadata जोड़ने के लिए यह सबसे व्यापक रूप से इस्तेमाल किया जाने वाला दृष्टिकोण (approach) है। जब आप चित्र (images) वाले NFTs या नाम और प्रतीक वाले टोकन (जैसे प्रसिद्ध “dog wif hat” मेमकॉइन) देखते हैं, तो वे संभवतः इसी standard का उपयोग कर रहे होते हैं। यह एक अलग metadata account के माध्यम से काम करता है जो आपके टोकन से जुड़ा होता है। यह ERC-721 के काम करने के तरीके के विपरीत है - ERC-721 में, टोकन कॉन्ट्रैक्ट metadata की ओर इशारा करता है, लेकिन Metaplex में, metadata account टोकन mint की ओर इशारा करता है।

यह चित्र एक SPL Token Mint, Metadata Account, और अतिरिक्त metadata के लिए Off-chain JSON के बीच के संबंध को दर्शाता है।

The SPL Token-2022: यह मूल SPL Token प्रोग्राम से एक अलग प्रोग्राम है जिसमें टोकन metadata और अन्य उन्नत सुविधाओं (advanced features) के लिए अंतर्निहित (built-in) समर्थन शामिल है। हालाँकि यह अधिक आधुनिक है, लेकिन लिखते समय तक इसे Metaplex standard की तरह व्यापक रूप से नहीं अपनाया गया है।

आज हम Metaplex समाधान पर ध्यान केंद्रित करेंगे और Token-2022 को एक अलग लेख में कवर करेंगे।

हम Metaplex समाधान के अपने कवरेज को दो भागों में विभाजित करेंगे: इस लेख में, हम Metaplex का परिचय देंगे और चर्चा करेंगे कि यह SPL टोकन के लिए metadata को कैसे संभालता है। अगले लेख में, हम Anchor का उपयोग करके एक SPL टोकन के लिए Metaplex metadata लागू (implement) करेंगे।

Metaplex क्या है और यह टोकन metadata कैसे प्रदान करता है?

Metaplex, Solana पर बने ओपन स्टैंडर्ड्स और टूल्स का एक सेट है। इन स्टैंडर्ड्स का रखरखाव Metaplex Foundation द्वारा किया जाता है और ये Solana पर डिजिटल संपत्तियों (digital assets) को बनाने और प्रबंधित करने का प्राथमिक तरीका बन गए हैं।

व्यावहारिक (Practical) रूप में:

• जब आप अपने Phantom वॉलेट में किसी चित्र (image) के साथ एक NFT या टोकन देखते हैं, तो वह छवि लिंक संभवतः Metaplex metadata से आता है।
• जब आपके वॉलेट में किसी टोकन का केवल एक एड्रेस होने के बजाय कोई नाम और प्रतीक होता है, तो वह सबसे अधिक संभावना है कि Metaplex metadata का उपयोग कर रहा है।
• Solana पर लोकप्रिय NFT कलेक्शंस (जैसे DeGods या Okay Bears) Metaplex स्टैंडर्ड्स का उपयोग करते हैं।

यह कुछ ऐसा दिखता है: https://explorer.solana.com/address/EKpQGSJtjMFqKZ9KQanSqYXRcF8fBopzLHYxdM65zcjm/metadata

Metaplex कई टूल्स प्रदान करता है, लेकिन अभी के लिए हमारा ध्यान Token Metadata Program पर है, जो आपको किसी भी SPL टोकन में metadata जोड़ने की सुविधा देता है।

Metaplex Token Metadata Program

Metaplex Token Metadata Program, जिसका एड्रेस metaqbxxUerdq28cj1RbAWkYQm3ybzjb6a8bt518x1s है, का उपयोग SPL टोकन में नाम, प्रतीक, चित्र और विवरण जैसे अतिरिक्त metadata जोड़ने के लिए किया जाता है। यह metadata accounts बनाता और प्रबंधित करता है, जो किसी विशिष्ट SPL mint से जुड़े स्ट्रक्चर्ड (structured) metadata को स्टोर करते हैं।

जिस तरह SPL Token Program सभी mint accounts और ATAs का मालिक होता है, उसी तरह Metaplex Token Metadata Program अपने अंतर्गत आने वाले सभी metadata accounts का मालिक होता है। यह एक निष्पादन योग्य (executable) और अपग्रेड करने योग्य (upgradeable) प्रोग्राम है।

उच्च स्तर (High level) पर, यह प्रोग्राम हमें इसकी अनुमति देता है:

1. एक SPL टोकन mint के लिए एक metadata account बनाना ताकि इस अकाउंट में नाम, प्रतीक और URI जैसे स्ट्रक्चर्ड डेटा को स्टोर किया जा सके।
2. विशिष्ट निर्देशों (instructions) के साथ इस डेटा को अपडेट करना।

हम नीचे दिए गए “Metaplex Token Metadata Program Instructions” अनुभाग (section) में निर्देशों (instructions) के बारे में अधिक विस्तार से जानेंगे।

अब आइए देखें कि ये metadata accounts कैसे संरचित (structured) और बनाए जाते हैं।

Metaplex Metadata Account

एक Metaplex metadata account एक Program Derived Address (PDA) है जिसे एक SPL टोकन में अतिरिक्त डेटा जोड़ने के लिए Metaplex Token Metadata Program के माध्यम से बनाया जाता है। यह PDA तीन सीड्स (seeds) का उपयोग करके डिराइव किया जाता है: स्ट्रिंग "metadata", token_metadata_program_id, और mint_account_address।

केवल mint address बदलता है; "metadata" स्ट्रिंग और प्रोग्राम ID निश्चित (fixed) होते हैं। यह सुनिश्चित करता है कि किसी दिए गए mint account के लिए केवल एक ही metadata account डिराइव किया जा सके।

जबकि metadata account टोकन के बारे में बुनियादी ऑन-चेन (on-chain) जानकारी स्टोर करता है, यह एक URI भी रख सकता है जो ऑफ-चेन (off-chain) संसाधनों की ओर इशारा करता है। उदाहरण के लिए, एक NFT का metadata account टोकन का नाम और प्रतीक ऑन-चेन स्टोर कर सकता है, जबकि URI एक JSON फ़ाइल की ओर इशारा करता है जिसमें पूरा विवरण, चित्र और IPFS, Arweave या किसी वेब सर्वर पर संग्रहीत अतिरिक्त विशेषताएँ (attributes) होती हैं।

नीचे दिया गया चित्र Metaplex Token Metadata Program और Metadata account के बीच संबंध को दर्शाता है।

नीचे दी गई छवि metadata account की हमारी चर्चा से संबंधित फ़ील्ड्स को दिखाती है, अगर अभी ये सभी समझ में नहीं आते हैं तो चिंता न करें, हम बाद में उन्हें समझाएंगे।

Metadata account एक mint account के बारे में metadata (नाम, प्रतीक, चित्र, आदि) स्टोर करता है। चूँकि metadata account का एड्रेस सीधे mint account के एड्रेस से डिराइव किया जा सकता है, यदि यह मौजूद है तो वॉलेट्स आसानी से metadata account को खोज सकते हैं।

ऊपर दी गई छवि से, यहाँ बताया गया है कि प्रत्येक की (key) क्या दर्शाती है:

• key: यह एक अकाउंट डिस्क्रिमिनेटर (account discriminator) है (वर्तमान में MetadataV1)। हालाँकि वेरिएबल का नाम key बहुत वर्णनात्मक (descriptive) नहीं है (एक अधिक सटीक नाम version या discriminator होगा), लेकिन Metaplex अपने कोडबेस में इसी का उपयोग करता है। यह वर्तमान में उपयोग किए जा रहे metadata संरचना (structure) संस्करण को इंगित करता है और वॉलेट्स व टूल्स को अकाउंट को सही ढंग से पार्स (parse) करने देता है। प्रत्येक mint में केवल एक metadata account हो सकता है क्योंकि PDA डेरिवेशन मैकेनिज्म (derivation mechanism) mint address को एकमात्र सीड के रूप में उपयोग करता है जिसका मान निश्चित (fixed) नहीं होता है।
• update_authority: वह वॉलेट एड्रेस जिसके पास metadata account को अपडेट करने का अधिकार (authority) होता है। यह update authority, metadata account बनाते समय सेट की जाती है, और बाद में केवल यही authority ही metadata को संशोधित कर सकती है। Update authority इन अधिकारों को किसी अन्य एड्रेस पर स्थानांतरित (transfer) कर सकती है या authority को null पर सेट करके स्थायी रूप से नियंत्रण छोड़ सकती है, जिससे metadata अपरिवर्तनीय (immutable) हो जाता है। प्रत्येक अपडेट ऑपरेशन (update operation) के लिए वर्तमान authority एड्रेस से एक वैध हस्ताक्षर (valid signature) की आवश्यकता होती है, और यह टोकन के metadata में अनधिकृत परिवर्तनों को रोकता है। हम इस लेख में बाद में authority को अपडेट करने और स्थानांतरित करने के विशिष्ट निर्देशों पर चर्चा करेंगे।
• mint: यह इस metadata द्वारा वर्णित SPL टोकन mint account की ओर इशारा करता है। यह metadata को वास्तविक टोकन से जोड़ता है।
• data: यह फ़ील्ड SPL टोकन एसेट डेटा (asset data) को दर्शाता है। इसमें निम्नलिखित शामिल हैं:
  • name: टोकन का नाम (उदा., “Circle US Dollar Stablecoin”)। यह 32 बाइट्स तक सीमित है, इसलिए नाम संक्षिप्त होने चाहिए। जैसा कि यहाँ परिभाषित किया गया है।
  • symbol: टोकन के लिए एक संक्षिप्त पहचानकर्ता (identifier) (उदा., “USDC”)। यह 10 बाइट्स तक सीमित है, और आमतौर पर अपरकेस (uppercase) में होता है।
  • uri: एक ऑफ-चेन JSON फ़ाइल का लिंक जिसमें विस्तारित (extended) metadata होता है, ठीक उसी तरह जैसे ERC721 और ERC1155 में NFT URIs काम करते हैं। यह JSON एक मानकीकृत प्रारूप (standardized format) का पालन करता है, और इसमें विवरण (description), चित्र (image), एनिमेशन URL, विशेषताएँ (attributes) और बहुत कुछ के लिए फ़ील्ड शामिल होते हैं। URI की आकार सीमा 200 बाइट्स है। हम बाद में इस JSON के बारे में और अधिक विस्तार से जानेंगे।
  • seller_fee_basis_points: यह टोकन की सेकेंडरी बिक्री (secondary sales) पर लागू होने वाली रॉयल्टी फीस (royalty fee) को दर्शाता है, जिसे बेसिस पॉइंट्स (basis points) में व्यक्त किया जाता है (जहाँ 1% 100 बेसिस पॉइंट्स के बराबर होता है)। टोकन बेचने पर क्रिएटर्स को कितनी राशि (amount) भेजनी है, यह निर्धारित करने के लिए मार्केटप्लेस (Marketplaces) इस जानकारी का उपयोग करते हैं। रॉयल्टी जानकारी मार्केटप्लेस के लिए एक लागू नियम (enforced rule) के बजाय एक सुझाव (suggestion) है, और इन मानों (values) के लिए अनुमेय सीमा (permissible range) 0 से 10,000 (अर्थात, 0% से 100%) तक है।
  • creators: अधिकतम 5 addresses का एक वेक्टर जो टोकन के क्रिएटर(s) के रूप में कार्य करता है, जिसमें प्रत्येक एड्रेस को सेलर फीस (रॉयल्टी) का एक प्रतिशत (percentage) सौंपा जाता है। इन प्रतिशतों का कुल योग 100 होना चाहिए। creators फ़ील्ड का यह उपयोग मार्केटप्लेस के लिए एक सिफारिश (recommendation) है, कोई सख्त नियम नहीं।
  • इसके अलावा, data में NFTs के लिए एक वैकल्पिक (optional) collection फ़ील्ड शामिल हो सकता है। यह फ़ील्ड दो प्रकार की जानकारी रखता है: एक पब्लिक की (public key) और एक बूलियन फ्लैग (boolean flag)। पब्लिक की (public key) एक अन्य NFT का mint address है जो कलेक्शन के पहचानकर्ता (identifier) के रूप में कार्य करता है। Ethereum के विपरीत, जहाँ कलेक्शंस आमतौर पर कॉन्ट्रैक्ट-आधारित होते हैं, Metaplex पूरे कलेक्शन का प्रतिनिधित्व (represent) करने के लिए एक विशेष NFT का उपयोग करता है। यह “collection NFT” सामान्य NFTs के समान ही metadata account का उपयोग करता है, लेकिन इसके metadata account में एक अतिरिक्त collection_details फ़ील्ड शामिल होता है जो इसे एक कलेक्शन के रूप में पहचानता है। बूलियन फ्लैग (दूसरी जानकारी) को कलेक्शन की update authority द्वारा सेट किया जाता है ताकि यह सत्यापित (verify) किया जा सके कि NFT वैध (legitimately) रूप से उस कलेक्शन से संबंधित है। यह ऑन-चेन सत्यापन प्रणाली (verification system) वॉलेट्स और मार्केटप्लेस को उनके कलेक्शन के आधार पर NFTs को समूहीकृत (group) और प्रदर्शित (display) करने की अनुमति देती है।
• primary_sale_happened: यह एक बूलियन फ्लैग है जो ट्रैक करता है कि क्या प्रारंभिक बिक्री (initial sale) हुई थी। एक बार true पर सेट होने के बाद, इसे पलटा (reversed) नहीं जा सकता है। यह कुछ मार्केटप्लेस में रॉयल्टी वितरण (royalty distributions) को प्रभावित करता है, क्योंकि अधिकांश मार्केटप्लेस प्राथमिक बिक्री (primary sale) होने के बाद ही रॉयल्टी लागू करना शुरू करते हैं।
• is_mutable: यह निर्धारित करता है कि निर्माण (creation) के बाद metadata को अपडेट किया जा सकता है या नहीं। यदि false पर सेट किया जाता है, तो metadata स्थायी रूप से फ़्रीज़ (frozen) हो जाता है (जिसका अर्थ है कि कोई और अपडेट संभव नहीं है, यहां तक कि update authority द्वारा भी नहीं)।
• edition_nonce: Master Editions के लिए उपयोग किया जाने वाला एक वैकल्पिक फ़ील्ड, जो एक उन्नत सुविधा (advanced feature) है जो NFTs की सीमित संस्करण प्रतियां (limited edition copies) बनाने की अनुमति देता है। Metadata कैसे काम करता है, यह समझने के लिए यह आवश्यक नहीं है। यदि आप इस सुविधा में रुचि रखते हैं, तो आप Metaplex documentation में और अधिक जान सकते हैं।
• token_standard: एक एनम (enum) जो टोकन प्रकार की पहचान करता है, यह निम्नलिखित में से कोई भी हो सकता है:
  • Fungible (मानक (standard) SPL टोकन),
  • NonFungible (बिना किसी संस्करण (editions) वाले अद्वितीय (unique) NFTs),
  • FungibleAsset (metadata वाले फंजिबल (fungible) टोकन, यह ERC1155 के समान उपयोग-मामले (use-case) वाले इन-गेम आइटम हो सकते हैं)

Metaplex Token Metadata Program Instructions

Metaplex Token Metadata Program में कई निर्देश (instructions) हैं जिन्हें हम किसी प्रोग्राम या क्लाइंट से कॉल कर सकते हैं। उनके साथ, हम SPL टोकन के लिए metadata बनाते और प्रबंधित करते हैं।

निर्देश (instructions) इस प्रकार हैं:

• CreateMetadataAccountV3: यह निर्देश एक SPL टोकन mint के लिए एक नया metadata account बनाता है। यह टोकन में नाम, प्रतीक, URI और क्रिएटर जानकारी जैसे metadata जोड़ता है। यह आपके टोकन को केवल उसके mint address से परे एक पहचान (identity) देने का प्राथमिक तरीका है। यहाँ V3 का मतलब केवल यह है कि यह इस निर्देश का तीसरा संस्करण (version) है। केवल टोकन की mint authority ही इसके लिए metadata बना सकती है, यह किसी को भी उन टोकन में अनधिकृत (unauthorized) metadata जोड़ने से रोकता है जिन्हें वे नियंत्रित नहीं करते हैं।
• UpdateMetadataAccountV2: यह निर्देश किसी मौजूदा टोकन के metadata को अपडेट करता है। यह नाम, प्रतीक, URI, क्रिएटर्स जैसे फ़ील्ड को संशोधित कर सकता है, नए एड्रेस पर authority ट्रांसफर कर सकता है, और अन्य विशेषताओं (attributes) को बदल सकता है जब तक कि metadata को mutable के रूप में चिह्नित किया गया हो और update authority लेनदेन (transaction) पर हस्ताक्षर (sign) करती हो। केवल निर्दिष्ट (designated) update authority ही metadata को संशोधित कर सकती है, यह authority तब सेट की जाती है जब metadata पहली बार बनाया जाता है।
• UpdatePrimarySaleHappenedViaToken: यह निर्देश चिह्नित (marks) करता है कि NFT की प्राथमिक बिक्री (primary sale) हो चुकी है। एक बार true पर सेट होने के बाद, इसे पलटा (reversed) नहीं जा सकता। यह कुछ मार्केटप्लेस में रॉयल्टी वितरण (royalty distributions) को प्रभावित करता है, क्योंकि अधिकांश प्राथमिक बिक्री के बाद ही रॉयल्टी लागू करना शुरू करते हैं। केवल update authority ही इस निर्देश को लागू (invoke) कर सकती है।
• SignMetadata: यह निर्देश metadata में सूचीबद्ध (listed) क्रिएटर्स को metadata पर हस्ताक्षर करके अपनी पहचान सत्यापित करने की अनुमति देता है। जब कोई क्रिएटर हस्ताक्षर करता है, तो उनका “सत्यापित (verified)” स्टेटस true हो जाता है, जिससे खरीदारों को टोकन की प्रामाणिकता (authenticity) की पुष्टि करने में मदद मिलती है।
• CreateMasterEditionV3: यह निर्देश एक NFT के लिए एक मास्टर संस्करण खाता (master edition account) बनाता है। इसे प्रति mint केवल एक बार कॉल किया जा सकता है, और तभी जब सप्लाई ठीक 1 हो। यह एक नियमित (regular) NFT को एक मास्टर संस्करण (master edition) में बदल देता है जो सीमित संस्करण प्रतियां (limited edition copies) बना सकता है। जैसा कि पहले बताया गया है, केवल mint के लिए update authority ही इस निर्देश को लागू कर सकती है।
• MintNewEditionFromMasterEditionViaToken: यह निर्देश एक मास्टर संस्करण से एक नया सीमित संस्करण (limited edition) NFT बनाता है। नए संस्करण का अपना mint और metadata होता है लेकिन यह मास्टर संस्करण से जुड़ा होता है।
• SetAndVerifyCollection: यह निर्देश एक NFT को एक कलेक्शन से जोड़ता है और इसे एक ही चरण (step) में सत्यापित (verify) करता है। इसके लिए कलेक्शन की update authority को लेनदेन (transaction) पर हस्ताक्षर (sign) करने की आवश्यकता होती है, जो इस बात की पुष्टि करता है कि NFT कलेक्शन का एक आधिकारिक (official) हिस्सा है।
• VerifySizedCollectionItem: यह निर्देश सत्यापित करता है कि एक NFT एक आकार वाले (sized) कलेक्शन से संबंधित है। Sized collections अपने अंतर्गत आने वाले आइटम्स की सटीक संख्या को ट्रैक करते हैं, जो मार्केटप्लेस में सटीक प्रतिनिधित्व (accurate representation) में मदद करता है।
• VerifyCollection: यह निर्देश सत्यापित करता है कि एक NFT एक कलेक्शन से संबंधित है। इसके लिए कलेक्शन की update authority को हस्ताक्षर (sign) करने की आवश्यकता होती है, जो कलेक्शन में NFT की सदस्यता (membership) की पुष्टि करता है।
• UnverifyCollection: यह निर्देश किसी कलेक्शन से NFT की सत्यापन स्थिति (verification status) को हटा देता है। इसके लिए या तो कलेक्शन की update authority या NFT की update authority के हस्ताक्षर (sign) की आवश्यकता होती है।
• Utilize: यह निर्देश उस NFT के उपयोग को ट्रैक करता है जिसमें “uses” सुविधा सक्षम (enabled) है। यह NFTs को समाप्त (expire) होने या स्थिति (state) बदलने से पहले सीमित संख्या में उपयोग करने की अनुमति देता है।
• ApproveUseAuthority: यह निर्देश किसी NFT का उपयोग करने के अधिकार (authority) को किसी अन्य एड्रेस को सौंपता (delegates) है, जिससे कोई अन्य व्यक्ति NFT का निर्दिष्ट (specified) संख्या में उपयोग कर सकता है।
• RevokeUseAuthority: यह निर्देश पहले दिए गए उपयोग अधिकार (use authority) को रद्द (revokes) करता है, जो डेलिगेट (delegate) को NFT का आगे उपयोग करने से रोकता है।
• ApproveCollectionAuthority: यह निर्देश कलेक्शन आइटम्स को सत्यापित (verify) करने के अधिकार (authority) को किसी अन्य एड्रेस को सौंपता (delegates) है।
• RevokeCollectionAuthority: यह निर्देश पहले से सौंपे गए (delegated) कलेक्शन अधिकार (collection authority) को रद्द (revokes) करता है।
• BurnNft: यह निर्देश एक NFT को बर्न (burn) करता है, जिससे टोकन और उसका metadata दोनों नष्ट हो जाते हैं। यह अपरिवर्तनीय (irreversible) है और NFT को संचलन (circulation) से हटा देता है।

कम उपयोग होने वाले Metaplex Token Metadata Instructions

निम्नलिखित निर्देश कम उपयोग किए जाते हैं लेकिन फिर भी Metaplex Token Metadata Program का हिस्सा हैं:

• CreateMetadataAccount: CreateMetadataAccountV3 का लिगेसी (Legacy) संस्करण।
• CreateMetadataAccountV2: CreateMetadataAccountV3 का लिगेसी संस्करण।
• UpdateMetadataAccount: UpdateMetadataAccountV2 का लिगेसी संस्करण।
• CreateMasterEdition: CreateMasterEditionV3 का लिगेसी संस्करण।
• CreateMasterEditionV2: CreateMasterEditionV3 का लिगेसी संस्करण।
• VerifySizedCollectionItem: यह किसी आइटम को एक NFT कलेक्शन के हिस्से के रूप में सत्यापित करता है।
• SetAndVerifySizedCollectionItem: यह एक निर्देश में एक आइटम को NFT कलेक्शन के हिस्से के रूप में सेट और सत्यापित करता है।
• FreezeDelegatedAccount: यह एक डेलिगेटेड अकाउंट (delegated account) को फ़्रीज़ (freeze) करता है।
• ThawDelegatedAccount: यह पहले से फ़्रीज़ किए गए डेलिगेटेड अकाउंट को अनफ़्रीज़ (Thaw) करता है।
• RemoveCreatorVerification: यह एक NFT से किसी क्रिएटर के सत्यापन (verification) को हटा देता है।
• PuffMetadata: यह छोटे फ़ील्ड्स को null बाइट्स के साथ पैडिंग (padding) करके metadata account को उसके अधिकतम आकार तक बढ़ाता है। जब metadata फ़ील्ड्स (जैसे name, symbol, URI) उनकी अधिकतम अनुमत (allowed) लंबाई से छोटे होते हैं, तो यह निर्देश शेष स्थान को शून्यों (zeros) से भर देता है। अधिकतम आकार हैं: name (32 बाइट्स), symbol (10 बाइट्स), और URI (200 बाइट्स)।

निष्कर्ष

संक्षेप में (To wrap up): Metaplex Token Metadata Program, mint से जुड़े एक अलग metadata account के माध्यम से SPL टोकन को नाम, प्रतीक और चित्र जैसी पहचान देता है। यह अकाउंट एक PDA है और स्ट्रक्चर्ड फ़ील्ड्स को स्टोर करता है, जिसमें एक URI शामिल है जो एक ऑफ-चेन JSON की ओर इशारा करता है। हमने विस्तार से बताया कि प्रत्येक फ़ील्ड का क्या अर्थ है और यह कैसे प्रभावित करता है कि वॉलेट्स और मार्केटप्लेस टोकन को कैसे संभालते हैं। अंत में, हमने प्रोग्राम द्वारा प्रदान किए जाने वाले निर्देशों और उनके कार्यों को देखा।

अगले ट्यूटोरियल में, हम एक SPL टोकन के लिए metadata बनाएंगे।

यह लेख Solana पर एक ट्यूटोरियल श्रृंखला (tutorial series) का हिस्सा है।