> ## Documentation Index > Fetch the complete documentation index at: https://docs.cultura.xyz/llms.txt > Use this file to discover all available pages before exploring further. # Core Concepts > Explanation of key concepts in the Cultura ecosystem like Assets, Grades, Levels, Bonding, and Verification. ## Asset Types ### Licensable Digital Assets * **Definition:** Original digital creations (e.g., art, music, text) minted on the Cultura blockchain, typically using the `CulturaDigitalAsset` contract. See [Minting Flow](../building-on-cultura/core-sdk-workflows/minting-original-asset). * **Purpose:** Represent the foundational intellectual property within the ecosystem. * **Requirement for Licensing:** Must achieve **Level 2: Verified Rights** through the [attestation and verification process](../building-on-cultura/core-sdk-workflows/verification-attestation) to become eligible for formal licensing via integrated protocols. ### Licensed Creative Assets * **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: 1. **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. 2. **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). ## Verification & Attestation Concepts ### Verification Levels 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()`](./CAS/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](#grades). Verifications are submitted using [`CAS.verifyAttestation()`](./CAS/CAS#verifyattestation). An asset at Level 2 is considered a **Licensable Digital Asset**. *See also: [Verification & Attestation Flow](../building-on-cultura/core-sdk-flows/verification-attestation)* *Note 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.* ### Grades * **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). ### Bonding * **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:** 1. **Attestation (Level 0 -> 1):** The asset owner bonds an initial amount determined by the chosen [Grade](#grades). 2. **Verification (Level 1 -> 2):** Verifiers bond tokens to verify an existing attestation using [`CAS.verifyAttestation()`](./CAS/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). ### Verification * **Definition:** The action taken by community members or whitelisted verifiers to verify a Level 1 attestation. * **Process:** A verifier calls [`CAS.verifyAttestation()`](./CAS/CAS#verifyattestation), specifying the `attestationUID` and the amount of tokens they wish to [bond](#bonding). * **Impact:** * Increases the `currentBondAmount` associated with the attestation. * Increments the count of unique verifiers (`communityUserCount` or `WLVerifierCount`). * Contributes towards meeting the [Grade](#grades)'s thresholds for promotion to Level 2. ## Standards ### Licensed ERC Standard * **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. ## Tokens ### Bond / Payment Token * **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.