Skip to content

[Contract] OpenZeppelin-Based NFT-Fungible Batch Distribution Contract for Starshop#113

Description

@aguilar1x

馃幆 Objective

Design and implement an NFT-fungible batch distribution smart contract using OpenZeppelin鈥檚 Stellar contracts, allowing sellers to mint and transfer NFTs in batches to buyers as part of the purchase process in the Starshop marketplace. This contract leverages role-based access control and OpenZeppelin鈥檚 standard library to ensure security, scalability, and compatibility with Stellar.


馃彈 Contract structure

nft-fungible-batch-contract/src/

  lib.rs             // Exports and main entry
  mint.rs            // NFT creation and batch mint logic
  transfer.rs        // Token transfer functionality
  roles.rs           // Role-based access control (admin, minter)
  events.rs          // Standardized event emission
  storage.rs         // State management per token and role

馃梻 Requirements

1. Core NFT Logic

  • Fungible-like NFTs using unique token IDs
  • Sellers can mint NFTs in batches to buyers (mint_batch)
  • Each call defines quantity of tokens delivered to one user
  • All NFTs are transferible once received
  • NFTs are not tied to metadata unless extended

2. Role Management

  • Roles: DEFAULT_ADMIN_ROLE, MINTER_ROLE
  • Only sellers with MINTER_ROLE can call mint_batch
  • Only ADMIN_ROLE can assign or revoke MINTER_ROLE
  • Role assignment is event-emitting and access-controlled
  • Use OpenZeppelin鈥檚 AccessControl module

3. Minting & Claim Logic

  • mint_batch(recipient, quantity) validates inputs:

    • recipient must be valid address
    • quantity > 0
    • caller must have MINTER_ROLE
  • Each NFT minted must have unique token ID

  • Emits NFTMinted and NFTBatchMinted events with full details

  • Can be extended to support product-based mapping if needed

4. Transfer Functionality

  • NFTs are fully transferible by recipients

  • transfer(from, to, token_id) must:

    • Check ownership
    • Prevent unauthorized transfers
    • Emit Transfer event
  • Compatible with future listing or trading functionalities in Starshop

5. Initialization Logic

  • Contract is initialized once via initialize()
  • Sets the first ADMIN_ROLE
  • Marks the contract as initialized using storage guard
  • Reinitialization attempt must revert
  • Emits ContractInitialized once

6. State & Storage Isolation

  • Use well-structured key prefixes per section:

    • role:{address}
    • token:{id}
    • owner:{address}:{token_id}
  • Persistent mapping of token ownership and supply

  • Storage keys must be isolated and non-overlapping

7. Event Emission

  • Emit detailed events for all on-chain actions:

    • ContractInitialized
    • NFTMinted(token_id, recipient)
    • NFTBatchMinted(quantity, recipient)
    • Transfer(from, to, token_id)
    • RoleGranted(role, account)
    • RoleRevoked(role, account)
  • Events support Starshop frontend and Stellar listeners


馃攳 Clarity

  • Batch minting reflects seller intent and product logic
  • Ownership is clearly trackable and auditable
  • Role-based access ensures secure and decentralized control
  • Minting, transferring, and initialization flows are distinct and well-guarded
  • State reflects real-time ownership and contract state

馃敆 References


馃搶 Additional Notes

  • Compatible with Starshop鈥檚 buyer/seller roles

  • Can be extended to include:

    • NFT metadata per product or tier
    • Burnable logic (revoke, invalidate)
    • Vesting or unlock conditions
  • Consider integration with payment validation module via Stellar XLM in future


Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions