Digital Asset Standard — Request for Comments

[austbot]

Introduction

Reflecting on the 15+ million NFTs minted on the Solana blockchain, the Metaplex Foundation is excited to share a new standard for Digital Assets that accounts for describing Fungible Tokens (FT), and representing Non-Fungible Tokens (NFT) and Semi-Fungible Tokens (SFT).

The current Metaplex Protocol, while being only a year old at the time of writing, has served as the foundation for a decentralized ownership community of over 2 million users and 15 million NFTs minted. The trends of self-custody, digital trading, and decentralized infrastructure have created a market for typical digital asset systems to move into new ventures where they can prove ownership, distribute rights, limitations, and licensing in more transparent ways.

The existing Metaplex NFT Protocol is focused on visual art, namely bitmap images, with some nascent support for 3D assets and other multimedia. In order to serve the needs of the shifting market into decentralizing traditional digital assets, the proposed protocol will add first-class support for more than images.

What's included in the new Digital Asset Standard

The proposed Digital Asset Standard (DAS) is a way of representing ownership on the Solana blockchain while adding native support for various multimedia types.

The proposed standard contains the two following components:

1. A Digital Asset Smart Contract that ensures the representation of an owned asset on-chain and allows for the creation of industry-specific use cases such as video, music, dynamic HTML content, 3D assets, etc.
2. An Extension Smart Contract that enables builders to add functionality by integrating with other components.

We want your feedback

This living document is a "Request for Comments" where Metaplex hopes to accomplish the following goals:

1. A good-faith discussion on the proposed standard to gather feedback.
2. Create transparency on the future of the Metaplex Protocol landscape.
3. Encourage early adopters to contribute and help us make the standard more secure, stable, and mature for the entire ecosystem of tooling SDKs and apps on the protocol.

What's included in this document

1. A technical overview of the new Digital Asset Standard we'd like feedback on.
2. A summary of our work around the new Digital Asset RPC Read API.
3. A summary of our work around the NFT Compression project.
4. A Note on Upgrading to the new Digital Asset Standard.

---

💡 Reminder This document is a "Request for Comments", which means that the contents presented here may evolve based on community comments before the new Digital Asset Standard is built. We plan to share updates on this proposal as we collect more feedback. Please leave your comments and feedback below

[fisprak]

Dynamic HTML Content and App deep-links as Digital Assets are interesting. It's in the Digital Asset Standard.

What is the use case?

[turshija]

@austbot We developed "Dynamic NFT" during the last week's hacker house in Belgrade, which was basically off-chain hosted dynamic image (centralized). We were thinking of implementing it as a small HTML app instead (hosted on Arweave) which just consumes on-chain data, but not a single wallet supports HTML NFTs at the moment, and one of the main reasons we haven't implemented it in Solflare yet is that we are a bit skeptic about the security implications those kind of NFTs can impose, especially in web wallet.

Is there anything that a malicious HTML page could do to compromise a security in its parent/origin if we decide to implement HTML NFTs that are loaded in small iframes? Or its recommended just to open those links in a new tab and run in its own tab instead?

[Arrowana]

@turshija See https://solscan.io/token/777eq8tgtKJgmrnYiZsA7svg2SWoAyuBjzypwMdGJ89r
The baby blob is in a iframe with sandbox="allow-scripts"

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe#attr-sandbox

[turshija]

@turshija See https://solscan.io/token/777eq8tgtKJgmrnYiZsA7svg2SWoAyuBjzypwMdGJ89r The baby blob is in a iframe with sandbox="allow-scripts"

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe#attr-sandbox

That's great! Do you know if any Solana wallet supports HTML NFTs? I see huge potential, but wallets would need to allow rendering those NFTs...
At the moment, Solflare renders those as static images only, but it would take just a few hours of effort to fully support HTML previews - https://solflare.com/g/6eCZRr2DDgnwFQwNwmjn42jzHgKE2aJh1iKJqRZi36Cc/66gy1CNSpMzTtf6P8CFGY1mo5K3n7wn2bE249p31tehv

[jozanza]

Unfortunately for HTML media, there are a lot of security and UX implications that aren't solved by iframe sandbox attributes.

[turshija]

Unfortunately for HTML media, there are a lot of security and UX implications that aren't solved by iframe sandbox attributes.

mind sharing some more info on that? I'm genuinely interested and would love to read more about it. Only idea I'm having is someone making DoS scripts which take 100% CPU or something like that...

[turshija]

Can metadata be stored on-chain? Or at least mostly used parts of metadata such as name (we have this already but not all projects are using it correctly because its redundant since offchain JSON contains name as well), logo uri and symbol

Currently, we have to fetch an external JSON just to retrieve an image url. Since Solana tokenlist is deprecated and everything is moving to Metaplex Fungible tokens for tokens metadata, in order to fetch 100 tokens for a wallet, we need to fetch 100 metaplex accounts (which can be done in just a single getMultipleAccounts), and after that we need to fetch 100 externally hosted JSON files in order to display those 100 tokens with their name, ticker (symbol) and logo.

[austbot]

Thanks for your comment, we will be rolling up feedback and answering it in bulk, but in short yes we mention in the URI section that we would allow JSON metadata uris as solana://Pubkey which would be an onchain address. Keep in mind the best way to see the metadata will be with the DAS API which is an api built on top of the Solana Validator Plugin System

[jpbogle]

I think just a single account to store the data doesn’t provide a ton of value at all other than novelty and it should really be a way to define a schema that can pull attributes from any account with any byte offset so other programs can own those attributes

We have played around with on-chain NFTs a good amount already. Currently in the form of a serverless function which uses the anchor IDL schemas and then a way to define fields (https://github.com/cardinal-labs/cardinal-generator/#dynamic-attributes) to pull from that schema and assign human names to each field, and returns that in the metaplex json format as attributes. There is also a sample program to store a schema but thus far it has been entirely defined in the URI itself using : and ; separated tuples of account IDs until it hits the URI limits set in metadata-program

on-chain metadata value is that you could say if the NFT represents a car, it could have health, a gas tank, a number of doors, equipment on the car like a set of tires you bought from the gas station these may or may not be modeled by the same programs. So you could have a gas station program the user interacts with to fill up the gas which just updates that field in that program, but will get reflected in the NFT attribute pointing to that account. If its just a single account you also cant name attributes human readable way, cant pick and choose which ones to show etc. The value of having it at the attribute level opens up way more doors...

pub struct Attribute {
    // solana address for where this attribute is stored
    pub address: Pubkey,
    // byte offset in this address for where this attribute is stored
    pub byte_offset: u64,
    // a type for how to deserialize this attribute
    pub attribute_type: String,
    // name for this attribute
    pub name: String,
    // optional display name to ovverride the name field when displaying in human readable form
    pub display_name: Option<String>,
}

#[account]
pub struct MetadataConfig {
    pub base_metadata_uri: String,
    pub attributes: Vec<Attribute>,
}

is what we are using in the on-chain program

[omarkilani]

Thanks for your comment, we will be rolling up feedback and answering it in bulk, but in short yes we mention in the URI section that we would allow JSON metadata uris as solana://Pubkey which would be an onchain address. Keep in mind the best way to see the metadata will be with the DAS API which is an api built on top of the Solana Validator Plugin System

One thing to keep in mind regarding solana:// URIs is that arweave, ipfs, etc have an inbuilt notion of immutability via cache control headers that would need some equivalent to achieve usable performance.

Not sure what that looks like on-chain.

Having some data in-line with the token instead of an external URI would be pretty neat though.

[turshija]

For on-chain data, caching read requests is done on RPC level. And one big advantage of using Solana address instead of off-chain url is that you can batch fetching multiple accounts in a single call, where off-chain data needs separate http request for each url.

[omarkilani]

For on-chain data, caching read requests is done on RPC level. And one big advantage of using Solana address instead of off-chain url is that you can batch fetching multiple accounts in a single call, where off-chain data needs separate http request for each url.

How do you know that the account data hasn’t changed on the client side?

With HTTP/2 and HTTP/3, almost every HTTP library parallelizes requests, and a Solana RPC is a HTTP request in the first place…

With normal HTTP requests you get permanent object cacheability in a CDN POP less than 10ms away, as well as memory and disk caching at the client.

[arcticmatt]

Thanks for sharing all these resources!

I haven't read through all the docs fully, but my preliminary feedback is that I'd like to see more exposition about what problems this new standard solves. For the most part, the docs seem very focused on presenting a (rather complex) solution, but do not really explain the motivating factors behind the solution

[austbot]

hanks for your comment, we will be rolling up feedback and answering it in bulk, but in short the current standard got us here so there is no shade but here are some of the following reasons,

1. High Cost relative to other Solana programs
2. Extensibility is only available using PDAs which will require every wallet and dapp and viewer system to know about those thigns, instead with the new standard which is schema based on both the extension system and the json off chain stuff will allow standard representation fields and data items
3. Performance, ask any validator team the Metaplex account set need 1TB of ram to be indexed properly, instead we need to use the new geyser plugin system and serve that data in a secure way just like regular RPC with much better performance characteristics because we are no longer putting a write lock on the accounts while a GPA is running as it is today
4. Speed of delivery, the system is extremely strict at every level even down to the byte level, we believe we can get greater shipping speed as well as security by leveraging other technologies that arent in scope for the current version of token metadata.
5. Historical decisions, looking at the original design with a critical eye and seeing the new features available to us in solana allows us to see ways we can make the standard safer, cheaper, faster and more flexcible. One example is the multiple authorities system

[statikdev]

thanks for the overview. Could it get added as an intro to the Notion document so it lays the foundation of what is trying to be achieved?

[Findiglay]

First of all this sounds amazing and big step forward. I think unentangling from spl-token is a tough but necessary pill to swallow.

I understand this is still at proposal phase, but is it too early to have an idea of timelines? Are we talking 2023? I ask because anyone stating to build a solana program today will be dealing with a moving target and there is a need to balance delivering features on the current protocol vs planning and for the new.

Also wanted to ask about Stealth NFTs. This is mentioned under the list of encryption providers. Is there any chance it will be included in the new protocol?

[austbot]

I really hope it doesnt take all year to build, but we dont know exact timelines yet, but we hope to get alot of feedback and find interested parties to work with us on it.

Stealth NFTs are incubating now, we have a solution along with lit protocol and darkbloc, but we see all of them as encryption providers and we will support encrypted assets in the core spec

[amilz]

Is this the best place to provide feedback?

Digital Asset Standard

1. Thanks for taking the time and thought to do this​. Very thorough and well thought out. Appreciate you taking feedback. Very much generally support what I have seen.
2. RE: Core Life cycle events...Maybe this is idea would just be an extension (or possible a native extension). On Ownership: what if there was is some type of owner/user-controlled locking mechanism as opposed to freeze which is a creator-controlled locking mechanism. The idea being... Almost like two factor authentication so an NFT couldn't leave a wallet unless it had some secondary authorization. I'm thinking about a safeguard against wallet drainers that a user could protect highly valuable assets like a property deed or a board ape or something like that. Perhaps this is covered by the transfer concept defined. If so, I very much support it.
3. RE: ​Financial extension...(1) what about lien (freeze) or creditor function that would almost function like an escrow but prevent somebody from transferring an asset until certain contract terms are satisfied. Similarly
4. Usage Extension Lifecycle: what if there was a "Share" [freeze] concept in here. Think about trophies that are transferred from a league to a winner, then rotated over time. It's a flex to hold in the wallet for a time, but it's not yours forever. Authority has revoke privileges built in or under certain terms (e.g. after 365 days)
5. There's some good thought in here RE: nondigital assets, and I really think this is a great opportunity to solicit feedback outside of industry to build out some of these concepts. Some specific ideas: real estate professionals, insurance brokers, estate attorneys, and other experts that have loads of experience in unique asset classes. I believe this is a real opportunity to open doors into new sectors by pulling in non web3 native professionals into the design-think process.
6. Curious what @aeyakovenko thinks

[austbot]

this is a great place to put feedback.

1. Thanks!
2. Yes we think this would be possible with the new system the freeze event and perhaps with modularity rights module cold allow an extension to be approved on the nft that will not allow the asset to move (since the trasnfer goes through the program) unless there is a two factor (other siganture, or other method)

[austbot]

3. I think this is the freeze event
4. I beleive this is where @jpbogle at cardinal labs did an amazing job, we think we can do this in the rights module and it can be used by other systems on top.

[austbot]

5. Yeah thats the plan, do you have any connections in some of these industries you mentioned?

[amilz]

Thanks for reply!
RE: 5--will put some feelers out.

[amilz]

also--today lots of discussion re: royalties. Looking at this a little closer:

Sale events are now forced to go through the protocol, this is so things like Royalties will now be enforced at the contract-level, Indexing is standardized across all sales contracts and the value of the asset can be understood based on its previous sales. Within the discussion of modules, we will mention that the Royalties module depends on this event in order to distribute the money to the royalty targets.

Curious how this would/could be enforced. Contract must receive the funds for a transfer? Then contract distributes royalties? What about a trade? Or just transferring an NFT to another wallet.

[mmdhrumil]

This is an excellent proposal. Our team is working on a product for dynamic NFTs based on on-chain state, and have to rely on centralized metadata URIs to do so. Excited to see that this proposal can open up many more possibilities with digital assets. 🚀

[austbot]

yes the data layout will allow for dynamic uri sizes, and even on chain uris where the "json" is stored on chain in a compressed json format such as msgpack

[mattdeco]

First off I want to say that this is a great start and there are some fantastic ideas here. What follows is relatively raw, subjective feedback from my perspective as a developer with a background in streaming, audio, and other forms of media. Thank you for being receptive to feedback, especially in the early days of this project.

JSON Schemas
It is excellent to see thoughtful consideration of this topic. In addition to the schemas that are maintained by Metaplex, schema validation tools are going to be essential. Think things like the Facebook OpenGraph Debugger, the Twitter Card Validator, or an RSS feed validator. Schema validation tools will need to be used by creators to validate that their JSON meets spec, and if it doesn’t then they are given clear feedback as warnings or errors that can be addressed. Also, teams that are building rendering contexts will also need validation tools to ensure they are fully supporting the spec and the features that creators expect to be in place. Think something like the Acid3 browser test.

The duplication of file format metadata in the JSON schema is concerning. Examples include ID3 tag data from an MP3 file or EXIF data from a RAW file. Having this exposed has many uses, but mismatches between the metadata stored in the file and the metadata stored in the JSON are inevitable. Can the extracting of file metadata and rendering of that data in the JSON schema be automated or validated in any way? This could be another opportunity for tooling to address a need.

The inclusion of the concept of asset quality in the schema overlaps with other ways to manage quality that are specific to certain media types. For streaming media like video and audio for example, HLS and DASH both have robust support for multiple renditions in one asset manifest. This is broadly supported across native OS media APIs and popular AV player clients. In the scenario of a native app, the developer can pass an HLS URL to the iOS media player and get all the benefits of adaptive bitrate streaming from the OS. In the current concept of quality in the schema approach, it seems like the developer would need to implement their own approach to adaptive quality based on detecting bandwidth capacity, connection quality, display resolution, or other heuristics.

Likewise with the example of how images would work with context values, especially with respect to web-desktop and web-mobile. Responsive web technologies like srcset and media queries focus on aspects of how an image is displayed, such as the width of the viewport or the pixel density of the screen, rather than on device types like mobile, tablet, and desktop. It seems like tying asset quality selection to device form factor descriptions will eventually encounter scalability challenges.

Lastly, using the existing JSON-LD and Schema.org standards seems highly advisable, as well as drawing inspiration from other things like OpenGraph. Using existing standards should be strongly encouraged.

Core Module Primitives
The Signature section speaks to the ability for assets to act as wallets and sign for transactions, the backbone of Identity. More information is needed on this topic. One thing missing in general from discussion of media types is DRM and the ability for access to off-chain files to be restricted to the wallet that holds the token representation of those files. Is there a way to account for a use case where off-chain storage can respond with a 403 if a credential provided by the render context is missing from the request, or something along those lines?

Compression
More information is needed on this topic for quality feedback to be gathered. For example, give concrete cost comparisons with the current standard with several use cases. Also give more details and examples on the tradeoffs and what is and isn’t possible with compression. Something similar to the “A note on cost” blockquote in the On-Chain Data section.

Interfaces
Examples of how rendering contexts and interfaces interact to provide render hints, compatibility, and other concerns would be really helpful. One of the biggest pain points today is how different wallets and apps render (or don’t render) media assets other than static images.

SPL Token Compatibility
This seems important to preserve but I admittedly don’t fully understand the implications of not being compatible with SPL tokens. Part of the beauty of NFTs on Solana is that they are “just tokens” and thus are more approachable from a conceptual standpoint if you already understand other Solana fundamentals.

Additional General Thoughts
There seems to be some conflating of concerns between the Digital Asset Standard and existing file formats and protocols. In general, the scope and boundaries of the DAS feel a little overextended in terms of design. For example, the way media quality is being defined is not really compatible with any of the existing solutions for variable media quality on the web. There is a sense of trying to boil the ocean on some of these topics, when these concerns might be best addressed by developers building the off-chain storage solutions for certain things or by developers building the rendering contexts described in the standard. It seems that coming up with new ways to address these sorts of things could hamper adoption if it makes it harder for developers to leverage existing capabilities of the web and native platforms.

More architecture diagrams would be helpful, as well as a more formal writing style and format that is closer to that of RFCs from W3C, IETF, etc, especially if this documentation is intended to be used by developers to implement against. Having this available on GitHub where changes can be tracked and the community can contribute would be helpful, even if there’s an automated process controlled by Metaplex that publishes the latest to a standalone documentation site.

This is a lot of general feedback to put in a GitHub comment; consider alternate forms of group communication where details can be discussed. I have more thoughts that are more conversation topics than concrete feedback but this thread doesn’t feel like the best venue for that.

If you made it here, thank you for taking the time to read all of this! 🙌

[austbot]

@mattdeco said "JSON Schemas..."
I 100% agree that validation tools and creation tools are table stakes for this version of the standard. And I dont think that its extremely hard to manage that but it does take intentional focus.

First of all thanks, this is probably the best feedback we have seen so far on the json standards. As far as standards that already embed metadata into the file and adaptive bit-rate and quality sections. I also have worked in live-streaming and have built web players from the ground up. Its a complicated business and I would argue that the most tools do not make it very easy to set up those bit-rates and even the built in music formats are great but they do require you to at least download the header or some of the bytes of the music file. Many systems like spotify and youtube and other still follow those standards but implement their own layers of read on top so that the file does not have to fully download. This is definable impl specific. But it points at a few things, 1. I dont know of a way to use cryptographic signing of id3 (and other metadata) 2. by using json we can get closer and closer to sending it through the blockchain to verify schemas in the future 3. in the schema design if an author is intentional about their hls and mp3 metadata formats we can produce a metadata schema that instructs rendering contexts and sdks to look into the file for the meta. Imagining a marketplace style page with hundres of nfts where you need to start streaming the head of the hls file or mp3 file to grab the id3 seems high overhead to me.
All that being said I agree it would be weird for the two locations with meat to be out of sync. but if we consider the NFT as the packaging format I feel it makes alot of sense to have the metadata at that layer specifically as we are specifically not producing a system where the random mp3 file is located deep in that high school laptop used to sync itunes over to you sweet clickly ipad with the magnetic disk :).

I'm happy to work with you to create something that allows both scenarios. Having it JSON driven seems like non negotiable since we dont want the SDK doing backflips for basic information.

As far as quality values and how they map to contexts, the Idea here is to give the author more control over how the asset is displayed.
The "PLAN" is actually for our team to build out renderer that can implement all this logic and can be built on top of, although this may be too lofty a goal. At the very least the logic will be in the SDK to select the most appropriate asset give the constraints on both sides. Please get involved here and help us come up with the best values here. I dont think assuming wallets and dapps will care deeply to select the most desired media type by the author for the give scenario is realistic but if we do that work for them then I think we solve problems for them and they will use the libraries and be able to more quickly adopt new features.

[austbot]

@mattdeco - "Lastly, using the existing JSON-LD and Schema.org standards seems highly advisable, as well as drawing inspiration from other things like OpenGraph. Using existing standards should be strongly encouraged."

This is my query to the community do we prefer the already built taxonomies and the rigid structure of schema.org ? Or do we prefer a light weight system. I'm in favor of using ecisting standards but that also requires really good tools .

[austbot]

"This seems important to preserve but I admittedly don’t fully understand the implications of not being compatible with SPL tokens. Part of the beauty of NFTs on Solana is that they are “just tokens” and thus are more approachable from a conceptual standpoint if you already understand other Solana fundamentals."

Spl Tokens are amazing, but they complicate a simple single NFT type of token. Also as you noticed the spec is meant to be much more than PFP tokens. Not every Asset needs creators or royalties or supply but some do.

As mentioned in the document SPL token compatibility already requires two token programs. And we can make DAS2 compatable with token programs in a few ways. Keep in mind we cannot enforce royalties without some change in how the token is represented as we do not see the transfer. The "just tokens" approach was cool, but was also a source of limitations and complexity. with DAS 2 tokens are used when needed to represent supply but paying the overhead of a mint, token account for all possible use-case doesn't seem like something we need to continue

[austbot]

"More information is needed on this topic for quality feedback to be gathered. For example, give concrete cost comparisons with the current standard with several use cases. Also give more details and examples on the tradeoffs and what is and isn’t possible with compression. Something similar to the “A note on cost” blockquote in the On-Chain Data section." I agree here but we do have a fully public system and repo about this since this work is already done/doing https://github.com/jarry-xiao/candyland#getting-started

[mattdeco]

@austbot thanks for all of the replies and additional context + information! 🙌

[jpbogle]

Regarding the read API -- is the point to have it run as a validator plugin, exposing all NFTs (tokenkey, token-22, compressed, digital-asset) under a common interface? If so does there not also need to be some write interface? Or is it expected that the read respones will just have a type and wallets / dApps will just need to know how to support these types? Wondering if this can be built generically to actually expose a common NFT interfaces that anyone can add new implementations of

Re extensions -- The spec mentions either on-chain CPI post-action, or basically giving the right to run lifecycle events to another contract. While these are definitely opening up a large surface area for "attack", I believe that this level of flexibility is important for composability and extensibility in the future. The main issue being that solana program extensibility can become challenging but this decoupling would allow extensions to evolve on top of the existing spec. I don't see this as being a huge attack vector if either the NFT owner or creator is approving the extensions to be added because its not different than them giving up update authority of the token for example. I'm envisioning an extension app-store so-to-speak where extensions can have reviews people will know which one they are interacting with or adding to the NFT and anyone can build new extensions that do specific things with the lifecycle events and allow creators to register those. To me the CPI to extension programs portion of the doc is critical for this to work

[mjzuppe]

Thanks for the transparent process for feedback. A few notes specific to music:

• Regarding On-Chain Digital Asset Smart Contract and supported multi-media formats - you may want to consider changing the term "music" to "audio" as it's the media format itself and covers more broad applications (e.g. podcasts, audiobooks, audio samples, etc.)
• Regarding JSON Schemas for several formats of media and quality - I'm joining @mattdeco in that this seems like a good intention, but likely a stretch too far into how off-chain media can be managed and delivered to end users. I do get @austbot 's response in that in the least, it would help point to options to render properly. However, note that the existence itself of this more advanced approach could actually introduce poor data governance (e.g. same asset URI in every quality key) or give the impression that it's necessary and which increase the data storage costs.

[jbar2797]

Are there plans to create support for the same type of system that WaX chain offers, in which you can collect specific NFTs and then "turn them in" in exchange for a new NFT. An example could be you collect a rock nft and a stick nft, and combine them to make an axe nft.

[Findiglay]

I think this would probably fall under the scope of the token entangler https://github.com/metaplex-foundation/metaplex-program-library/tree/master/token-entangler

[arcticmatt]

Finally got a chance to read through this more thoroughly, leaving my feedback/questions/thoughts below (for context, I work on Formfunction)

General questions/feedback

1. It would be great to see more info in the Notion about the problems this new spec solves.
2. Before diving into all the technical details, it would be nice to see some examples about new use cases this spec unlocks. User stories are typically a good way to move people towards a high-level understanding of what you’re building.
3. What is the difference between “Identity Assets” and “Identity NFTs”?
4. Are the identity assets similar to Soulbound tokens?
5. Under music, “support for other rich metadata” is quite generic—examples would help.
6. For 3D assets, would be nice to list specific content types supported, like the OpenSea spec does.
7. Is this spec at all related to xNFTs? Will xNFTs use this spec?
8. I would love more details about how you plan on helping developers/companies upgrade to this new standard, and also more details about the planned timeline. It seems like it will be quite the lift—now everyone needs to support two standards instead of just one, on the program level in addition to any client-side and backend code. For example, I work on Formfunction, and based on my understanding so far, we would likely need to deploy a new marketplace program to work with the DAS (or keep wrapping/unwrapping, which seems suboptimal). Besides the non-trivial workload we’ll have to incur, I’m concerned this my lead to fragmentation in the ecosystem, where somethings work with the just old standard, some things work with just the new standard, and some things work with both.
9. One general concern I have is that the standard is quite complicated, which may hinder adoption. Comparatively, the existing NFT standard is much simpler, and friendlier to new devs. Part of the problem may just be presentation—I think if there was more explanation about how a “normal” NFT works, it would be easier to digest. An analogy is ERC721—the IERC721 interface is quite simple and easy to digest. There are also a bunch of extensions, like ERC721Pausable, etc., but you don’t need to understand those in order to understand the base interface.
10. In general, curious about Metaplex’s philosophy about what should be supported in their programs, and what should be the responsibility of other programs to support. Based on the document, it seems like Metaplex wants to stuff as much functionality as possible into their own programs. This makes everything more standardized, but may make it harder for people building NFT products to innovate.
11. It would help my understanding if a more detailed specification were provided (e.g. what instructions will the program have, what args and accounts will they take, etc.)
12. It would be nice to elaborate on other possible approaches the Metaplex team considered (e.g. continuing to update the current program), the pros and cons of each approach, and why the proposed approach was eventually chosen.
13. Did you take motivation from standards on other blockchains (Ethereum, NEAR, etc.)? Where do you think those standards fall short?
14. Did you consider splitting out the off-chain spec into a separate document? It seems pretty perpendicular to the on-chain spec.
15. Will the read API work for the old protocol as well? Or only the new standard?

Technical Deep Dive Section

Lifecycle

1. Is it accurate to think of each lifecycle event as a separate instruction of the DAS program? Put another way, will a lifecycle event be associated with one more more instructions?
2. It would be nice to get more details about the “Sale” lifecycle event. I’m mainly curious about how flexible it is—can it support splitting the payment between multiple creators? Does it support payment only in SOL, or also in SPL tokens?
3. In general, more descriptive definitions of each event would be nice (e.g. “asset use” is extremely generic and could mean multiple things)

Data

1. What does on-chain and off-chain data look like for compressed vs. not compressed NFTs?
2. Did you consider using the OpenSea Metadata Standard for off-chain data? Why/why not?
3. Having a bunch of JSON specs makes the off-chain data very flexible, but may make it more troublesome for clients to support rendering all the different possible specs. Curious if you plan on having some library that helps out with this.
4. I see there are multiple image qualities included in the “Simple image” JSON spec. Imo this is the wrong level of abstraction to handle this—it is much easier for clients to use a service like Imgix that is specifically designed to serve assets at different sizes, quality levels, file formats, etc.
5. In the below example, what is the point of using $$schema? Instead of having metadata be an object where description is one of the keys

{
  "$schema": "https://schema.metaplex.com/image_nft_1_0",
  "metadata": [
    {
      "$$schema": "description",
      "name": "Austbot on his tractor",
      "description": "When not writing bareley readable code and complaining about the temperature of his office, he is found in his unnatural habitat. Outside the Austbot encounters wild animals, so he stays on his tractor to avoid the scorching heat of the pavement and the dangers of the Texas fauna"
    }
  ],

Core Module Primitives

I’m a bit confused about the module interface example. I think it would help if the pseudo-code was more fleshed out, I really don’t have a good idea about what is going on.

Interfaces

1. Some pseudo-code would help my understanding here. I think an interface just specifies which modules a digital asset supports?
2. Is there a required set of modules for all digital assets? Or can a digital asset be composed of an arbitrary set of modules (if so, which ones)? Can it have zero modules?
3. “By utilizing these Interfaces we can provide strict rendering rules for rendering contexts.”
   • I'm a bit confused by this part, since a large part of rendering NFTs relies on the off-chain data
4. Is there a way to check which modules an asset contains other than looking at the interface? E.g. lets say I have an asset which contains some arbitrary set of modules that are not defined by a single interface (not sure if this is possible btw)—can I check exactly which modules it contains? Seems like this would be useful.

Extensibility

1. “As we have seen Digital Assets encode and the state machines of Lifecycle Actions and state changes are reduced from them”
   • This sentence doesn't make sense to me
2. Would be nice to clarify the advantages of this system vs. the current option of just making your own account and storing extra data in it. AFAICT the main two advantages are discoverability (via the registry) and making things easier to keep in sync (because the DAS will emit info about lifecycle events).

[etodanik]

1. My main worry is interoperability with the existing spl-token functionality. Right now, for instance, it's quite wonderful that SFT are simply a Token with Metadata, but are also composable with existing Swaps (trading in-game wood for ore via Phantom?), the Serum order book e.t.c It could be quite limiting to suddenly cut off NFT's from all this composable functionalty.
2. Another worry is that right now there is an "API" (a contract between the users of Metaplex) of all the quirky side effects that can be achieved via the simplicity of the current protocol. For example: there's a huge debate about mutability / immutability - but having mutable NFT can achieve many interesting things, like for instance:

• Mystery NFT's (let people mint identical looking NFT & then use the mutability of the contract to change them)
• NFT's with a lifecycle of growth (mint babies and watch them grow)
• Natural disasters (system mutates your NFT to a dead state)
• and many more...
  It would be VERY important that the new standard preserves some backwards compatibility (for example, if SPL Tokens are mutable, this should be too, anything that can be done now should still be doable on the next standard), rather than becoming too opinionated for its' own good.

[Leowhyx]

NFT is really plenty. After all, you can still earn on the created nft. If anyone is looking for additional information on creating nft, I recommend this post