Skip to main content
This flow details how a digital asset progresses from its initial minted state (Level 0) to becoming attested (Level 1) and finally achieving Verified Rights (Level 2), making it licensable within the Cultura Proof of Rights Protocol.

Flow Diagram

Explanation

Part 1: Attestation (Level 0 -> Level 1)

  1. Owner Initiates: The owner of a minted digital asset (Level 0) uses a dApp to start the attestation process.
  2. Schema Handling (SDK): The SDK ensures the correct schema exists by calling sdk.schemaRegistry.getOrRegisterSchema(). This returns a schemaUID. This step is crucial for defining the structure of the attestation data.
  3. Bond Token Approval (SDK): The SDK prompts the owner’s wallet to approve the CASContract to spend the required bondAmount (determined by the chosen Grade) of the designated bond token. This calls sdk.bondToken.approve(). Approval must be granted before the attest call.
  4. Attestation Call (SDK): The SDK calls sdk.attestationService.attest(), providing:
    • attestationRequest: Contains the schemaUID, recipient (usually the owner), expiration time (0 for non-expiring), revocability flag, and any specific attestation data encoded according to the schema.
    • digitalAssetAddress: The contract address of the asset being attested.
    • digitalAssetId: The token ID of the asset.
    • grade: The numerical grade (0-3) chosen by the owner, influencing bond requirements and Level 2 thresholds.
    • bondAmount: The amount of bond tokens required for the chosen grade’s fee.
  5. Contract Execution (CAS):
    • The CASContract verifies the inputs (schema exists, grade is valid, etc.).
    • It transfers the bondAmount from the owner to itself using the prior approval.
    • It deploys a new RightsBoundAccount contract specifically for this asset’s attestation, linking the asset to its future royalty and rights management.
    • It stores the attestation details (UID, schema, recipient, attester, times, data, asset link, RBA link).
    • It updates the asset’s level to 1 (digitalAssetLevels mapping).
    • It emits an Attested event (containing the attestationUID) and a CulturaRightsBoundAccountDeployed event (containing the RBA address).
  6. Result (SDK/Dapp): The SDK parses the events from the transaction receipt using getAttestationDataFromReceipt to extract the attestationUID and the rightsBoundAccount address, returning them to the dApp. The asset is now Level 1 (Attested).

Part 2: Verification (Level 1 -> Level 2)

  1. Verifier Initiates: A community member or whitelisted verifier uses a dApp to verify/endorse an existing Level 1 attestation, identified by its attestationUID.
  2. Bond Token Approval (SDK): The SDK prompts the verifier’s wallet to approve the CASContract to spend the verificationBond amount they wish to contribute. This calls sdk.bondToken.approve().
  3. Verification Call (SDK): The SDK calls sdk.attestationService.verifyAttestation(), providing the attestationUID and the verificationBond amount.
  4. Contract Execution (CAS):
    • The CASContract verifies the attestation exists and is currently Level 1.
    • It transfers the verificationBond from the verifier to itself.
    • It records the verification details, linking the verifier and their bonded amount to the attestation (verifierCount, communityUserCount, WLVerifierCount, bondedAmount on the Attestation struct are updated).
    • It checks if the promotion thresholds (total bonded tokens OR number/type of unique verifiers) defined by the asset’s Grade have now been met by calling the internal _checkVerifiedVerifiedLevel function.
    • If thresholds are met: The contract updates the asset’s level to 2 (digitalAssetLevels mapping) via _promoteDigitalAsset.
    • It emits a Verified event.
  5. Result (SDK/Dapp): The SDK returns the transaction result. If the thresholds were met during this verification, the asset is now Level 2 (Verified Rights) and is considered licensable through integrated protocols.

SDK Snippets