Last Wednesday, Sound unveiled the Sound Protocol, a permissionless, open-source, modular smart contract framework for musicians and creators. It was inspired by many protocols in the web3 ecosystem and brought to bear a lot of the things we’ve learned while iterating on the first set of contracts we deployed nearly a year ago. Its main features are:

• Permissionless base layer

  Previously, artists needed a signed message provided by Sound to sell their music. With the new Protocol, artists can freely deploy their own Sound contracts.

• Artist-owned & non-upgradeable contracts

  All contracts in the new protocol are non-upgradeable, which we believe will give artists and collectors greater confidence in the security and sovereignty of the communities they’re building on Sound.

  Additionally, we are replacing the former artist contracts that were intended to represent an artist’s whole collection, with edition contracts that can atomically represent a song, album, mixtape, etc. We believe this is better aligned with the broader concept of music collecting, and it has the added benefit of smoother integration and composability.

• Custom metadata

  Artists and developers are free to implement custom metadata modules to suit their needs.

• Custom mint formats

  Mint formats can now be customized on a per-song basis by utilizing minter module contracts. We built minters for the existing formats on sound.xyz but any conceivable type of auction or distribution can be built into custom minters: open editions, bonding-curves, dutch auctions, and more.

• Payments & end-to-end royalties

  With each song as its own contract, Sound now supports end-to-end royalties across primary and secondary sales. Any address can be set to receive the edition’s revenue, be it the artist’s wallet or a payment splitter contract.

• Gas efficient

  A great amount of care was put into making the Sound Protocol contracts very secure and gas efficient. This was achieved primarily thanks to the contributions of Yul & Solidity expert, Vectorized, aka Optimizoor. Skip to the Optimizations section for details.

Overview

Core Contracts & Interfaces

SoundCreatorV1.sol

This contract is the first point of contact for an artist. It is a simple, non-upgradable factory which only has one job: deploy minimal proxies (clones) of SoundEditionV1 & initialize them with customizable configurations. The function for doing this is createSoundAndMints, which accepts encoded calldata for initializing the edition, as well as an arbitrary list of contract addresses and calldata used for setting up minter configurations for the edition.

SoundEditionV1.sol

This is the NFT contract that represents songs (or albums, mixtapes, etc). It’s an implementation of the highly gas-optimized ERC721A. The main thing that sets it apart from the typical NFT contract is it can implement optional module contracts that augment or override the base functionality of metadata, minting, and payments (primary & secondary revenue).

• Metadata
  • For on-chain custom metadata, a metadata module can be set by the artist, which is a contract that provides a tokenURI function that the edition’s tokenURI function calls, overriding the default response. If an artist wants to guarantee to their collectors that the metadata cannot be changed, they can call freezeMetadata, which will prevent any changes to the baseURI or metadataModule address.
• Payments
  • All primary and secondary revenue accrues to the address set to SoundEditionV1.fundingRecipient. In the case where the artist is the sole recipient, this would be their wallet address. If they are splitting revenue with other parties, it could be an 0xSplits SplitWallet (what we use on sound.xyz) or an alternative splitter contract.
• Minting
  • A few minting features are baked directly into SoundEditionV1:
    1. The artist can airdrop tokens to a list of addresses at any time, if enough supply is available.
    2. Upon each mint event, a pseudo-random number is set, which enables game mechanics like the Sound Golden Egg. While the value isn’t truly random, it is calculated through a gas-efficient mechanism that would be very difficult to game via MEV.
    3. It is possible to implement range editions directly through the edition contract, which enables some market discoverability. The way it works is a lower and upper quantity bound are defined along with a cutoff time. Prior to the cutoff time, tokens can be minted until the upper bound is reached. After the cutoff time, the current total or the lower bound become the final maximum quantity for the edition, whichever is greater.
  • Authority over minting can be granted to any number of customized minter contracts, the details of which are described further below.
• Access control
  • SoundEditionV1 implements solady OwnableRoles, a very gas-optimized on-chain contract for gating access to functions.
  • Roles can be granted & revoked for addresses. ex:
    • Minter contracts must have MINTER_ROLE.
    • Owner-defined admins must have ADMIN_ROLE.

SOUND MODULES

Metadata modules