Definition: Original digital creations (e.g., art, music, text) minted on the Cultura blockchain, typically using the CulturaDigitalAsset contract. See Minting Flow.
Purpose: Represent the foundational intellectual property within the ecosystem.
Requirement for Licensing: Must achieve Level 2: Verified Rights through the attestation and verification process to become eligible for formal licensing via integrated protocols.
Definition: Assets created after a Licensable Digital Asset has been formally licensed through a licensing protocol. They represent compliant derivative product or creative works based on the terms of the license.
Standard: Adhere to the Licensed ERC standard (an extension of ERC721/ERC1155, implemented in Licensed_ERC.sol), embedding licensing terms, rights info, and provenance.
Linkage: Always link back to the parent Licensable Digital Asset(s) via the parentDigitalAssets array stored during minting.
Verification: Can optionally undergo their own attestation and verification process to establish verified rights for licensing of the derivative work.
Representation Patterns: There are two primary ways a Licensed Creative Asset can be represented:
Direct Representation: The digital asset implementing the Licensed ERC is the licensed product. Its metadata (termsURI) points directly to the creative work (image, music file, etc.) and describes it.
Reference Representation: The NFT digital assets as a license token. Its metadata describes the license itself and might link to an external product (which could be off-chain or a separate NFT collection).
Assets progress through verification levels indicating trust and integration within the Cultura ecosystem:
Level 0: Minted: The initial state of any newly minted Digital Asset. The asset exists on-chain, but no formal claims about its authenticity or rights have been made or verified within the Cultura protocol. It is not yet licensable through Cultura-integrated protocols.
Level 1: Attested: Achieved when the asset owner successfully completes the initial attestation process using CAS.attest(). This involves bonding tokens and making a formal claim about the asset. A RightsBoundAccount is deployed for the asset. The asset is still not considered licensable via standard protocols at this level.
Level 2: Verified Rights: Achieved when a Level 1 attestation receives sufficient verification from the community or whitelisted verifiers to meet the thresholds defined by its Grade. Verifications are submitted using CAS.verifyAttestation(). An asset at Level 2 is considered a Licensable Digital Asset.
See also: Verification & Attestation FlowNote on Terminology: “Attestation” refers to the initial L0->L1 process by the owner. “Verification” refers to the L1->L2 action performed by verifiers using verifyAttestation(). “Verified Rights” refers to the resulting L2 status.
Definition: Categories (S, A, B, C) assigned during the initial attest call, chosen by the asset owner.
Function: Determine the initial bond amount (fee) required for Level 1 and the thresholds (total bonded tokens or number/type of verifiers) needed to reach Level 2.
Hierarchy:
S (0): Highest requirements, highest trust signal.
A (1): Premium requirements.
B (2): Intermediate requirements.
C (3): Entry-level requirements.
Immutability: The Grade cannot be changed after the initial attestation.
Representation: While conceptually referred to as S, A, B, C, Grades are represented numerically (0, 1, 2, 3 respectively) in contract interactions (e.g., attest function parameter, digitalAssetGrades mapping) and often in SDK function return values (getDigitalAssetGrade). Subgraph queries and results typically use the string representation (“S”, “A”, “B”, “C”).
Configuration: Defined within the CAS.sol contract (grades mapping stores configuration per numerical grade, levels mapping corresponds to Grade thresholds).
Definition: The act of locking ERC20 tokens (the designated bondToken) within the Cultura Attestation Service (CAS.sol) contract.
Purpose: To provide economic incentive (“skin in the game”) and security for attestations and verifications. Requiring a bond makes spamming attestations costly and aligns incentives for verifiers to verify valid assets.
Process:
Attestation (Level 0 -> 1): The asset owner bonds an initial amount determined by the chosen Grade.
Verification (Level 1 -> 2): Verifiers bond tokens to verify an existing attestation using CAS.verifyAttestation().
Outcome: Bonded tokens contribute to meeting the thresholds for Level 2 and are potentially used in reward/slashing mechanisms (though challenge/slashing details are less defined in current docs).
Definition: An extension of ERC721/ERC1155 standards, implemented in Licensed_ERC.sol and inherited by CulturaDigitalAsset.sol.
Purpose: To embed detailed licensing information, rights, and provenance directly into NFT metadata.
Key Features:
Stores LicenseInfo including asset name, description, creator, termsURI.
Crucially stores parentDigitalAssets array, linking derivative/licensed assets back to their original sources and defining royalty splits.
Provides getLicenseInfo function to retrieve this embedded data.
Applicability: Used for both original “Licensable Digital Assets” (where parentDigitalAssets is empty) and “Licensed Creative Assets” (where parentDigitalAssets is populated).
Metadata URI: The termsURI field within the LicenseInfo struct stores the URI pointing to the asset’s metadata JSON file (which typically includes name, description, image URI, etc., following ERC721/ERC1155 metadata standards). This termsURI is set during the minting process and is usually the same URI returned by the standard tokenURI() function.
Definition: A specific ERC20 token designated within the Cultura ecosystem for economic interactions.
Usage:
Used for bonding in the Cultura Attestation Service (CAS.sol) during attestation (Level 0->1) and verification (Level 1->2).
Used as the payment token for royalty distributions managed by the Cultura Royalty System (CRS.sol), RightsBoundAccount.sol, and VerifierModule.sol.
Note: In the current implementation and SDK (sdk.bondToken), the same token serves both purposes. Contract initializers (bondToken in CAS, _culturaPaymentTokenAddress in CRS, _tokenAddress in RBA, _paymentToken in VerifierModule) should be set to the same ERC20 token address for the system to function correctly.
