The Consent Layer (The Vault)
This layer governs identity, provenance, and cryptographic access control. It is designed to be slow, immutable, and highly secure (typically living on a Layer 1 blockchain like Ethereum or a permanent storage network like Arweave).
Data Types Handled
- Cryptographic Signatures: Ed25519 or ECDSA keys proving artist identity.
- CIDs (Content Identifiers): IPFS hashes pointing to the encrypted off-chain AI model weights.
- Access Policies: Machine-readable arrays defining exact permitted uses (e.g., `allow_remix: true`, `commercial_use: false`).
- Soulbound Tokens (SBTs): Non-transferable identity markers proving original authorship.
Artist Signs Contract Payload (Wallet)
↓
Mint Immutable Record to Layer 1 Ledger
↓
Deploy Cryptographic Access Keys to EMS
The Payment Layer (The Tollbooth)
This layer governs micro-transactions, royalty splits, and lineage tracking. It is designed for extreme speed and near-zero friction, built to handle millions of generative events (typically living on a Layer 2 rollup like Base or an AppChain).
Data Types Handled
- Derivative Lineage Trees: Directed acyclic graphs (DAGs) mapping parent capsules to child generations.
- Fractional Balances: State maps holding micro-penny balances in stablecoins (e.g., USDC) or native tokens.
- Royalty Split Arrays: Math execution rules (e.g., `[0.02 to Wallet A, 0.01 to Wallet B]`).
- Event Hashes: Lightweight receipts of a generation event from the Remix Engine.
User Triggers Remix Engine Generation
↓
Calculate Split Math via Lineage Graph
↓
Execute L2 Micro-Transaction State Update
The Execution Bridge
The two layers connect at the moment of execution. When a user requests a remix, the system checks the Consent Layer (L1) to verify the cryptographic permissions are valid. If approved, the Remix Engine generates the work, and simultaneously pings the Payment Layer (L2) to execute the fractional royalty routing. Consent unlocks the physics; Payment executes the economics.
🔥 The Structural Challenge
If the Consent Layer lives on a slow, highly secure L1, and the Payment Layer lives on a fast, cheap L2, how does your system handle state desynchronization?
Example: If an artist burns their Capsule and revokes consent on the L1, it might take 12 seconds for the block to finalize. In those 12 seconds, the high-speed Remix Engine on the L2 could process 10,000 generation requests using that artist's style. Does the L2 physically stop, or does Artiquity prioritize the speed of the Remix Engine over the absolute real-time enforcement of the Consent Layer?