Developing Merge and Split was one of the greatest challenges Merabet had to overcome. His initial idea for the Merge function was that it would add up the metadata values of the inputs (Deeds), update the metadata of one of the existing Deeds to reflect the combined value, and burn the other Deed(s) that were no longer needed. There is no way to literally ‘fuse’ two tokens together on the blockchain, so the process was always going to involve burning leftover Deeds.
That being said, it was still not an ideal solution. For one, how would the function choose which Deed was going to be preserved (as the updated, Merged version)? Additionally—and this was the more substantial point of concern—some marketplaces don’t refresh metadata on NFTs automatically. This means that some users may not even realize their NFTs have been properly merged, because the marketplace is reading the cached (old) metadata and not the newly updated metadata. On a large scale, you can imagine how this may cause issues with people buying and selling NFTs that are, effectively, mislabeled.
The natural conclusion of this line of reasoning was that both Merge and Split would have to produce newly minted NFTs. This would be the only way to ensure that they had the proper metadata being read, no matter where/when they were being viewed. “If we have two different Deeds, with two different token IDs, we can add their [metadata] amounts and create a new [Deed], mint [it], and burn the initial Deeds.”
All of these steps are contained within the single Merge function. It scans the inputted Deeds, adds together their metadata values, burns them, and mints an entirely new NFT with the combined metadata. For the user, it’s like magic; for the engineer, it’s the product of much blood, sweat, and digitized tears.