Flow Diagram
Explanation
- User Initiates: The user interacts with the dApp, providing details like the asset’s name, description, and optionally an image file or URL.
- SDK Call (Dapp): The dApp calls the SDK’s
mintDigitalAssetfunction. It passes:- The recipient address (
to). - Asset name and description.
- An empty array (
[]) forparentDigitalAssets(indicating it’s an original asset). - A
termsobject containing asset-specific terms or extended metadata (e.g.,{ creatorTerms: "...", usageRights: "..." }). This is distinct from the standard ERC721 metadata. - A
tokenURIobject containing standard ERC721 metadata (e.g.,{ name, description, image: imageUrl }).
- The recipient address (
- Metadata Upload (SDK): If objects were passed for
termsandtokenURI, the SDK uploads them to IPFS automatically, obtainingtermsURIandtokenURICIDs. If strings (pre-existing URIs) were passed, the SDK uses them directly. - Contract Interaction (SDK): The SDK calls the
safeMintfunction on theCulturaDigitalAssetcontract, passing the recipient, name, description, emptyparentDigitalAssetsarray, and the finaltermsURIandtokenURI. - Minting (Contract): The
CulturaDigitalAssetcontract performs the mint operation:- Creates a new token.
- Assigns ownership to the recipient (
to). - Stores the provided
digitalAssetName,digitalAssetDescription,parentDigitalAssets(empty),termsURI(intended for specific terms/metadata), andtokenURI(standard ERC721 metadata URI) within its internal data structures. - Emits a standard ERC721
Transferevent indicating the creation of the new token ID.
- Result (SDK/Dapp): The SDK waits for the transaction receipt, extracts the
tokenIdfrom theTransferevent log, and returns it to the dApp. The dApp then notifies the user of the successful minting. - Post-Minting: The asset now exists on-chain at Level 0. The next step to make it licensable is the Verification & Attestation Flow.

