Skip to main content

Access Control

Use allow and is_allowed to manage decryption permissions for handles. The same allowance also gates Attested Decrypt and Attested Compute: the covalidator checks the on-chain allowance PDA before decrypting or comparing a handle. With an Allowance Voucher, a session key can call those APIs on the sharer’s behalf — Coval verifies the voucher, then checks the sharer’s allowance PDA (not the session key’s).
The access control design is WIP and subject to change in future versions.

granting Access

Checking Access

How Allowance Works

Allowance PDA Derivation


Access Control Functions

Best Practice: Minimal Permissions

Grant minimal decryption permissions:
Access control is essential for privacy. Without explicit permission grants, encrypted values cannot be decrypted.

Client-Side: Simulation to Get Handles

Since encrypted operations produce new handles, you often need to simulate the transaction first to get the resulting handle before you can derive the allowance PDA and grant access in the same transaction.

Why Simulation is Needed

  1. Operations like e_add, mint_to, transfer produce new handles
  2. The allowance PDA is derived from [handle.to_le_bytes(), allowed_address]
  3. You need the handle value before you can compute the PDA address
  4. Simulation lets you “peek” at the result handle before actually submitting

Simulation Pattern

Example: Mint with Auto-Allow

Example: Transfer with Auto-Allow for Both Accounts

For complete working examples with simulation patterns, see the lightning-rod-solana repository.