I’m working on a Solidity contract that stores image data in a custom struct. Each struct holds the image file, a title, some description text, and pricing info. Users can input this data through my frontend interface.
My question is about whether these digital assets would count as NFTs if I add buying and selling functionality. Right now I’m just storing everything in my own data structure instead of using the standard ERC721 contract.
Do I need to properly implement ERC721 and host the metadata externally to make these legitimate NFTs? Or does having purchasable digital assets automatically make them NFTs regardless of the technical implementation?
I’ve been avoiding the standard NFT approach because I wanted to keep everything simple, but I’m not sure if that’s the right move. Would love to hear thoughts from anyone who has dealt with similar situations.
hey @Elias87, this is actually a really interesting question that gets to the heart of what makes something an “NFT” in the first place!
technically speaking, your custom structs could represent unique digital assets, but calling them NFTs might be a bit of a stretch without the standardization. The whole point of ERC721 is that it creates a common language that wallets, marketplaces, and other dapps can understand and interact with.
what’s got me curious though - are you planning to make each of these image structs truly unique and non-fungible? like, can users create multiple identical copies or is each one meant to be a one-off?
also, have you thought about how users would actually prove ownership outside of your specific platform? without ERC721, these assets basically live in isolation and can’t be easily transferred to other wallets or shown in places like opensea.
i’m wondering if there’s a middle ground here - maybe you could keep your custom struct for the core functionality but still implement the ERC721 interface on top of it? that way you get the simplicity you want but also the interoperabilty benefits.
what’s your main reason for wanting to avoid the standard approach? is it just complexity or are there other factors im missing? would be interesting to hear more about your specific use case!
From my experience building similar contracts, you’re essentially creating a closed marketplace rather than true NFTs. The technical definition of an NFT really does hinge on following established standards like ERC721 or ERC1155.
I went through this exact decision process last year when building a custom asset system. Initially I thought keeping everything in custom structs would be simpler, but I quickly realized the limitations. Without standard compliance, your assets become trapped within your ecosystem - users can’t move them to hardware wallets, display them in galleries, or interact with DeFi protocols that accept NFTs as collateral.
The implementation overhead for ERC721 isn’t as bad as it seems, especially with OpenZeppelin’s contracts. You can still maintain your custom struct for additional metadata while exposing the standard interface. This gives you the best of both worlds - your simplified data structure plus ecosystem compatibility.
One thing to consider is future-proofing. If you later decide you want marketplace integration or cross-platform compatibility, retrofitting standards becomes much more complex than implementing them from the start. The gas costs and user experience issues of migrating existing assets can be significant.
honestly @Elias87 without erc721 youre basically creating a proprietary system that nobody else can interact with. sure theyre digital assets but nfts need that standardization to be reconized by the ecosystem. your custom structs wont show up in metamask or any marketplace which kinda defeats the purpose imo