# Granular Permissions IronWeave is designed to enable granular permissions at the level of individual chains and blocks, offering a significant departure from existing blockchains and traditional data storage platforms. This article provides an explanation of IronWeave's approach to granular permissions and how it compares to other platforms. ## IronWeave's Granular Permissions for Chains and Blocks IronWeave's core design which is centered around its multi-blockchain Shared-Block Architecture, and the the IronWeave block as the new unit of online data, enables granular control over each element of data. ### **Individual Block Encryption and Access Control:** * Each interaction (message, file share, payment) creates its own private, encrypted block. * Only the participants of an interaction or block are aware that it even exists. * Each block is encrypted with a unique set of keys that are only available to the participants. This functions like a "separate data vault" or "separate bank vault" for each unit of data. * The IronWeave fabric and its nodes have zero knowledge of the encrypted data and do not gain keys to decrypt it. * Users have data sovereignty, meaning they own and control the data created with their chain and any interactions. They decide whom they share data with. * Fine-tuned permissions for chains and blocks enable controlled access to data. * A participant can share a single block, a collection of blocks (based on type, category, time constraint), or an entire chain with specific entities or individuals, or even make it publicly available if intended (e.g., for an oracle). ### **Chain-Level Permissions:** * Each chain in IronWeave is individually permissioned, requiring authenticated credentials to gain access. * A chain's Access Control List (ACL) can be intentionally set to public or some similar permissive setting by its owner, but by default, it's private. * Chain Keys (public/private key pairs) manage access to the chain, with the public key encrypting unique Block Keys and the private key decrypting them. * Users or organizations can have an unlimited number of independent chains for various purposes or activities. This allows for "walled gardens", where interactions among allowed participants (e.g., a consortium or geographical region) are secured against common interactions. ### **Security Mechanisms for Access Proof** * Manager Nodes will not offer the HEAD or metadata of any chain or block unless the requestor can prove knowledge of the keys with a Zero-Knowledge proof (ZK proof). A similar ZK proof is required to retrieve any block from a node unless the chain's ACL is intentionally public. * This inherent proof-of-creation mechanism allows for provenance – proof of who created the data – which has massive implications for trust and preventing spoofing in an online environment, all with inherent privacy and safety. ## Comparison to Other Blockchains IronWeave's approach contrasts sharply with the default privacy models of most other blockchain platforms, as described in the following sections. ### **Monolithic Blockchains (e.g., Bitcoin, Ethereum, Solana, Sui, others)** * These blockchains typically provide transparency at the cost of privacy. * They often expose transaction details, wallet balances, and usage patterns, leaving sensitive data vulnerable and making users easy targets for hackers, theft, extortion, or worse. * All transactions across all addresses are **grouped into global blocks** and committed to a single, monolithic chain, making all data visible to anyone observing the network. * IronWeave avoids this by having no central chain to which all blocks must reconcile, thus preventing a single point of recordation or exposure. * While some blockchains attempt privacy with solutions like ZK Proofs or Fully Homomorphic Encryption (FHE), such methods are still subject to being "scanned and copied off-chain for brute-force attacks" and account balances can often be derived through iterative queries. IronWeave, in contrast, ensures that only individual participants to each block can even know of its existence, making it "unscannable". #### **Data Storage on-chain:** * Other blockchains typically have limited, set-size blocks that must share space, and all data put on-chain is visible to the entire world. * IronWeave, with its multi-dimensional fabric, allows blocks of any size and type of data to be stored securely on-chain in encrypted, private blocks. ## Comparison to Other Platforms (Traditional Data Storage) IronWeave also provides significant advancement over traditional data storage methods. ### **Centralized Data Repositories (Databases, Data Lakes):** * Traditional systems rely on outdated, centralized systems that create massive attack surfaces, where a single breach compromises everything. * Data is stored in large databases or repositories, making them vulnerable to widespread exposure in a single breach. * IronWeave replaces this with countless individually encrypted blocks, each immutable and stored in multiple duplicates across various nodes, effectively creating a self-contained, encrypted block that exists only within its private chain(s). * This shifts control from large tech or business entities back to the users, allowing them to own, control, and automatically secure their own data and online storage. ## Summary In summary, IronWeave's architecture provides unparalleled, inherent, and robust privacy and granular access control by encrypting each individual interaction into a unique block, known only to its participants. This contrasts with the transparent nature of monolithic blockchains and the centralized vulnerabilities of traditional data stores, offering a new model for data ownership and security in the online world. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.ironweave.io/flexibility/granular-permissions.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.