The MoonCatRescue project has an infrastructure that is doing something like that (which I helped develop). The MoonCatRescue project predates the ERC721 standard, but there is a wrapper contract at
0xc3f733ca98E0daD0386979Eb96fb1722A1A05E69 which wraps MoonCats into ERC721-compatible tokens (in-lore, those MoonCats are “acclimated” to life on the blockchain, and can participate in other ERC721-compatible projects). MoonCats that are acclimated then can visit The Boutique and buy additional accessories to wear.
The Boutique is powered by the contract at
0x8d33303023723dE93b213da4EB53bE890e747C63, which is not ERC6551-compatible, but for paralleling your idea, fills that role. The Accessories contract is a custom contract, but it is possible to tell how many accessories a MoonCat owns by calling
balanceOf(uint256), and then use the
AccessoriesByMoonCat(uint256, uint256) function to iterate through them (first argument is the MoonCat’s token ID, second argument is the zero-based index of their purchased Accessories). To tell what the Accessory itself looks like, the
accessoryInfo functions give that (they’re stored on-chain as PNG-formatted pixel art).
So, putting all that together, there’s a contract at
0x91CF36c92fEb5c11D3F5fe3e8b9e212f7472Ec14 that is an example of what you’re aiming to do: That contract (
MoonCatAccessoryImages) has an
accessorizedImageOf(uint256) function that if you put in a MoonCat’s token ID (you can use “1289” to get my main avatar MoonCat) you get out an SVG that has several “layers” (
<g> groups in the SVG code) to it. The base layer is the MoonCat itself, and then because my MoonCat is currently wearing three Accessories (a visor, a bowtie, and a vehicle), there’s three
<image href="data:image/png;base64... embeds that are the PNG-formatted Accessories.
This is done on-chain in the contract by querying the Accessories contract for which Accessories are owned by that MoonCat, generating PNG data for each owned Accessory, creating a data-URL style tag for embedding each in an SVG and returning it. The code for that contract is posted on Etherscan if you want to peruse the Solidity behind it.
You could take this one step further and have the contract wrap that SVG in a JSON object that is the format expected for NFT marketplaces for the
So, to accomplish “on-chain rendering of SVGs of an NFT and any Accessories they own, that change as they buy/activate others” you don’t need to use any standards, but if your “Accessories” are ERC721-style tokens in ERC6551 token-owned accounts, if your Accessories contract uses enumerable metadata (
tokenOfOwnerByIndex or similar), you can use that to figure out which Accessories a given token owns pretty easily.
If you’re interested in learning more about how we accomplished storing the Accessory appearances themselves on-chain, I did a writeup on that in a Reddit post.