> For the complete documentation index, see [llms.txt](https://docs.zama.org/protocol/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.zama.org/protocol/solidity-guides/smart-contract/acl.md). # Access Control List This document describes the Access Control List (ACL) system in FHEVM, a core feature that governs access to encrypted data. The ACL ensures that only authorized accounts or contracts can interact with specific ciphertexts, preserving confidentiality while enabling composable smart contracts. This overview provides a high-level understanding of what the ACL is, why it's essential, and how it works. ## What is the ACL? The ACL is a permission management system designed to control who can access, compute on, or decrypt encrypted values in fhevm. By defining and enforcing these permissions, the ACL ensures that encrypted data remains secure while still being usable within authorized contexts. ## Why is the ACL important? Encrypted data in FHEVM is entirely confidential, meaning that without proper access control, even the contract holding the ciphertext cannot interact with it. The ACL enables: * **Granular permissions**: Define specific access rules for individual accounts or contracts. * **Secure computations**: Ensure that only authorized entities can manipulate or decrypt encrypted data. * **Gas efficiency**: Optimize permissions using transient access for temporary needs, reducing storage and gas costs. ## How does the ACL work? ### Types of access * **Permanent allowance**: * Configured using `FHE.allow(ciphertext, address)`. * Grants long-term access to the ciphertext for a specific address. * Stored in a dedicated contract for persistent storage. * **Transient allowance**: * Configured using `FHE.allowTransient(ciphertext, address)`. * Grants access to the ciphertext only for the duration of the current transaction. * Stored in transient storage, reducing gas costs. * Ideal for temporary operations like passing ciphertexts to external functions. * **Permanent public allowance**: * Configured using `FHE.makePubliclyDecryptable(ciphertext)`. * Grants long-term access to the ciphertext for any user. * Stored in a dedicated contract for persistent storage. **Syntactic sugar**: * `FHE.allowThis(ciphertext)` is shorthand for `FHE.allow(ciphertext, address(this))`. It authorizes the current contract to reuse a ciphertext handle in future transactions. ### Transient vs. permanent allowance | Allowance type | Purpose | Storage type | Use case | | -------------- | ---------------------------------------------- | ----------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- | | **Transient** | Temporary access during a transaction. | [Transient storage](https://eips.ethereum.org/EIPS/eip-1153) (EIP-1153) | Calling external functions or computations with ciphertexts. Use when wanting to save on gas costs. | | **Permanent** | Long-term access across multiple transactions. | Dedicated contract storage | Persistent ciphertexts for contracts or users requiring ongoing access. | ## Granting and verifying access ### Granting access Developers can use functions like `allow`, `allowThis`, and `allowTransient` to grant permissions: * **`allow`**: Grants permanent access to an address. * **`allowThis`**: Grants the current contract access to manipulate the ciphertext. * **`allowTransient`**: Grants temporary access to an address for the current transaction. * **`makePubliclyDecryptable`**: Grants permanent, global permission for any entity to decrypt the cleartext value associated with the given ciphertext (handle) off-chain. ### Verifying access To check if an entity has permission to access a ciphertext, use functions like `isAllowed` or `isSenderAllowed`: * **`isAllowed`**: Verifies if a specific address has permission. * **`isSenderAllowed`**: Simplifies checks for the current transaction sender. * **`isPubliclyDecryptable`**: Verifies whether any entity is permitted to retrieve the ciphertext's cleartext value off-chain. * **`checkSignatures`**: Verifies the authenticity of a cleartext value by checking cryptographic signatures. This ensures that the value submitted back to the chain originated from a legitimate public decryption operation on the associated ciphertext handle. * **`isAccountDenied`**: Checks whether an account is on the deny list. Denied accounts are blocked from `allow*` calls inside the ACL contract, so they cannot grant or receive new permissions on encrypted values. ### User decryption delegation The ACL supports delegating user decryption rights from one account to another (for example, a backend service or relayer). The **delegator** is whichever account calls into the ACL — an EOA when calling `IACL.delegateForUserDecryption` directly, or `address(this)` when a contract uses the `FHE.delegateUserDecryption` helper. The two patterns are not interchangeable. * **`delegateUserDecryption`**: Grants a delegate the right to user-decrypt on behalf of the caller contract for a specific `contractAddress`, with an expiration date. * **`delegateUserDecryptionWithoutExpiration`**: Same as above, but without an expiration date. * **`revokeUserDecryptionDelegation`**: Revokes a previously granted delegation. * **`isUserDecryptable`**: Checks if a handle can be decrypted by a user in the context of a specific contract. For the EOA-side flow, the full constraints, and worked examples, see [User decryption delegation](/protocol/solidity-guides/smart-contract/acl/delegation.md). For the API reference, see [FHEVM API reference](/protocol/solidity-guides/smart-contract/functions.md#user-decryption-delegation). ## Practical uses of the ACL * **Confidential parameters**: Pass encrypted values securely between contracts, ensuring only authorized entities can access them. * **Secure state management**: Store encrypted state variables while controlling who can modify or read them. * **Privacy-preserving computations**: Enable computations on encrypted data with confidence that permissions are enforced. * **Publicly Verifiable Result Reveal**: Enable the public reveal of a confidential operation's final result. For example, enabling the public to verify the final price in a sealed-bid confidential auction. *** For a detailed explanation of the ACL's functionality, including code examples and advanced configurations, see [ACL examples](/protocol/solidity-guides/smart-contract/acl/acl_examples.md). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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, and the optional `goal` query parameter: ``` GET https://docs.zama.org/protocol/solidity-guides/smart-contract/acl.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.