A music collectible needs information about the track, while a marketplace needs rules for exchanging the object and accounting for payment. In Beats NFT Marketplace, those responsibilities live in separate Move modules.
Give the music object its own identity#
The version-two MusicNFT includes name, artist, genre, image URL, music URL, creator address, and trait data. Display fields make that information available to object presentation.
The object also emits events for lifecycle operations such as minting, burning, and metadata updates. These make changes observable in the source model.
An artist field is metadata. It does not by itself establish licensed use of the linked music or a payment entitlement for every named party.
Model the sale separately#
The marketplace stores listed items and a table of accumulated seller payments. A buyer must supply the exact asking value. The purchased item is transferred, while the seller's proceeds are recorded under the seller address.
Withdrawal uses the transaction sender's address. Keeping proceeds in their own table gives the marketplace an explicit accounting path instead of treating the NFT's metadata as a payment instruction.
Distinguish a seller payment from royalties#
The inspected path explains sale proceeds for a seller. It does not establish a royalty-sharing scheme among artists, collaborators, or other parties.
Adding such a scheme would require defined recipients, allocation rules, enforcement points, and evaluation. It cannot be inferred from the presence of artist and creator fields.
Preserve implementation attribution#
The marketplace module states that it adapts a Sui Foundation example and retains its attribution. The project-specific case study therefore focuses on the integration and music-object model, without presenting the underlying example as wholly original work.
This review describes the supplied source version. Identifying the deployed package and testing its behavior would be separate validation steps.