Smart Contract Specifications
This document outlines the technical requirements for the Solidity smart contracts needed to transition the PODBUM® prototype to a live dApp.
This specification was generated based on the application's demonstrated logic.
1. PODBUM® Community Credit (PCC) Token
An ERC-20 compliant token for payments and royalties.
This contract will manage the PCC token, which is the primary currency of the ecosystem. It should adhere to the standard ERC-20 interface to ensure compatibility with wallets and exchanges.
Required Functions & Properties:
// Standard ERC-20 Functions
function name() public view returns (string) // "PODBUM Community Credit"
function symbol() public view returns (string) // "PCC"
function decimals() public view returns (uint8) // 18
function totalSupply() public view returns (uint256)
function balanceOf(address account) public view returns (uint256)
function transfer(address recipient, uint256 amount) public returns (bool)
function allowance(address owner, address spender) public view returns (uint256)
function approve(address spender, uint256 amount) public returns (bool)
function transferFrom(address sender, address recipient, uint256 amount) public returns (bool)
// Ownership and Minting (e.g., using OpenZeppelin's Ownable)
function mint(address to, uint256 amount) public onlyOwner2. PODBUM® NFT Asset Contract
An ERC-721 compliant contract for the music NFTs.
This contract will manage the creation (minting) and ownership of the individual music track NFTs. It must be ERC-721 compliant.
Core Logic & Data:
- Each token should have a unique \`tokenId\` (uint256).
- The contract should store metadata for each token, including \`name\` and \`artistName\`. The \`tokenURI\` function should point to a JSON file following the ERC-721 Metadata standard, which includes the image URL.
Required Functions:
// Standard ERC-721 Functions
function balanceOf(address owner) public view returns (uint256)
function ownerOf(uint256 tokenId) public view returns (address)
function safeTransferFrom(address from, address to, uint256 tokenId) public
function transferFrom(address from, address to, uint256 tokenId) public
function approve(address to, uint256 tokenId) public
function getApproved(uint256 tokenId) public view returns (address)
// Metadata
function tokenURI(uint256 tokenId) public view returns (string)
// Minting (Only callable by a privileged address, e.g., the Oracle service)
function safeMint(address to, uint256 tokenId, string memory uri) public onlyOwner3. Marketplace & Oracle Logic
The off-chain and on-chain logic for sales and royalty distribution.
The marketplace logic demonstrated in this prototype is largely managed off-chain, using a database (Firestore) to track sale listings and prices. The on-chain component is the actual ownership transfer. The Oracle is a backend service that reads on-chain data and distributes payments.
Marketplace "Buy" Flow:
- User clicks "Buy" in the web app.
- The web app prompts the user to sign two transactions with their wallet (e.g., MetaMask).
- Transaction 1 (Approval): The user approves the Marketplace contract to spend the required amount of their PCC tokens. Calls \`approve()\` on the PCC Token contract.
- Transaction 2 (Transfer): A backend service or a marketplace smart contract calls \`transferFrom()\` on the PCC Token contract to move funds from the buyer to the seller, and \`transferFrom()\` on the NFT Asset contract to move the NFT from the seller to the buyer.
Oracle Royalty Distribution Flow:
- An authorized backend service ("The Oracle") is triggered.
- The Oracle service queries the NFT Asset contract to get a list of all current \`tokenId\` owners at that moment.
- For each owner, the Oracle calculates the royalty amount.
- The Oracle service executes a batch of \`transfer()\` transactions on the PCC Token contract, sending the calculated royalty amount to each NFT owner.