The interaction between [[ZKP/Data Marketplace/User Interactions/Data Uploader Capabilities|uploaders]] and [[ZKP/Data Marketplace/User Interactions/Data Purchaser Capabilities|purchasers]] is facilitated by the [[ZKP/Data Marketplace/Intro|marketplace's]] infrastructure through a well-defined workflow: 1. **Uploader Tokenization:** The uploader submits a dataset via the mintDataset function in the [[ZKP/Data Marketplace/Tokenized Datasets/Smart Contract for Dataset Tokenization/DatasetToken Smart Contract|DatasetToken contract]] or native pallet, specifying its CID, size, and access tiers. The system validates the CID against IPFS, encrypts the dataset with AES-256 (GCM mode), and stores metadata in Patricia Tries, costing 245,000 weight equivalent in testnet simulations [80]. 2. **Purchaser Browsing:** The purchaser queries metadata at [[ZKP/Data Marketplace/Tokenized Datasets/Tiered Access Control|Tier 0]] using the getDataset function or pallet call, retrieving details like schema and statistical summaries without cost. 3. **Access Request:** The purchaser requests access via the [[ZKP/Data Marketplace/Tokenized Datasets/Smart Contract for Dataset Tokenization/Core Functions|accessDataset]] function or pallet extrinsic, submitting a [[ZKP/Data Marketplace/Technical Basis/Cryptographic Foundations/Lifecycle of zk-SNARKs|zk-SNARK]] proof of token holdings and specifying duration (e.g., 30 days) and tier (e.g., Tier 3). Off-chain workers dynamically adjust tier requirements based on demand, using a median-based aggregation of access frequency (e.g., 800 accesses/hour in testnet) to ensure fair allocation [92]. 4. **Access Granting:** Upon verification through the verification infrastructure, the system grants access, emitting an AccessExtended event (375 weight) through the event system and providing the purchaser with the CID for IPFS retrieval, secured by [[Proof of Space (PoSp)]] See also: [[ZKP/Data Marketplace/Technical Basis/Technical Underpinnings of EVM and ZKPs|Technical Underpinnings of EVM and ZKPs]]