Access Control Conditions

ACCs act as pre-function modifiers for smart contracts, enabling complex, multi-factor authorization beyond simple owner checks.

• Examples: A multi-signature wallet that requires 3 of 5 designated signatures (M-of-N logic).
• Examples: A treasury contract that only allows withdrawals if a governance token vote passes and a timelock expires.
• Flexibility: Conditions can combine time locks, token thresholds, and outcomes from oracle data feeds.

ACCs enable dynamic NFTs whose metadata, artwork, or utility changes based on real-world conditions or user actions.

• Examples: An NFT character that gains new visual traits after its owner completes specific on-chain quests or achievements.
• Examples: A music NFT that unlocks bonus tracks only after the album reaches a certain sales milestone, verified by an oracle.
• State Management: The ACC evaluates the condition, and if met, triggers a contract call to update the NFT's state.

DAOs use ACCs to encode their governance rules directly into the protocol, ensuring transparent and automated enforcement.

• Examples: A proposal can only be created by members with a minimum voting power (e.g., 1% of governance tokens).
• Examples: Treasury funds are automatically released for payment upon the passing of a proposal and the satisfaction of pre-set conditions (e.g., a verified delivery milestone).
• Automation: This reduces reliance on manual, multi-sig interventions for routine governance actions.

ACCs power decentralized subscription models by checking for valid, unexpired payments on-chain before granting service access.

• Examples: A decentralized video streaming service that checks for an active subscription NFT in the user's wallet.
• Examples: A software-as-a-service (SaaS) dApp that grants API access keys only to wallets holding a valid monthly payment receipt token.
• Advantage: Eliminates centralized billing systems and allows for programmable, prorated, or tiered access models.

Access Control Conditions are logical rules, typically implemented as smart contract functions, that gate access to specific actions or resources based on dynamic, on-chain or off-chain data. Their primary purpose is to enforce permissioned interactions without relying on a central administrator, enabling features like token-gated content, subscription services, and role-based governance.

• Key Function: A require statement or modifier that checks a condition before executing a function.
• Example: require(balanceOf(msg.sender) > 10, "Insufficient tokens");

Conditions can be based on a wide variety of verifiable states, creating flexible permission systems.

• Token-Based: Holding a minimum balance of a specific ERC-20, ERC-721 (NFT), or ERC-1155 token.
• Temporal: Granting access only before or after a specific block timestamp or number.
• Reputational/On-Chain History: Requiring a minimum number of transactions, a specific DAO voting record, or a positive credit score from a protocol like Chainscore.
• Composite/Boolean Logic: Combining multiple conditions using AND (&&), OR (||), and NOT (!) operators.

In Solidity, conditions are often enforced using function modifiers. A modifier is a reusable piece of code that can be attached to functions to check conditions before execution.

solidityCopy
modifier onlyHolder() {
    require(myToken.balanceOf(msg.sender) > 0, "Access denied");
    _;
}

function restrictedAction() public onlyHolder {
    // Function logic here
}

This pattern keeps access logic clean, modular, and auditable.

For gasless experiences or complex off-chain logic, conditions can be verified via cryptographically signed messages. A user signs a structured message (standardized by EIP-712) off-chain, and the smart contract verifies the signature and the message content.

• Use Case: Allowing a user to grant one-time access to a resource without paying gas, with the cost covered by a relayer.
• Process: 1) Backend creates permission criteria. 2) User signs message. 3) Relayer submits signature to contract. 4) Contract verifies and executes.

A sophisticated pattern for managing permissions for multiple actors, defined in standards like OpenZeppelin's AccessControl. Instead of checking token balances, it assigns bytes32 roles (e.g., DEFAULT_ADMIN_ROLE, MINTER_ROLE) to addresses.

• Hierarchy: Roles can be granted and revoked by addresses with the appropriate admin role.
• Granularity: Functions are protected by onlyRole(MINTER_ROLE) modifiers.
• Standard: This is the foundation for most DAO governance and multi-sig managed protocols.

Access Control Conditions are fundamental to modern Web3 applications.

• Token-Gated Communities: Unlocking Discord roles, forum access, or exclusive content based on NFT ownership.
• DeFi Vaults & Strategies: Limiting deposit/withdrawal functions to approved addresses or during specific time windows.
• Credentialing & Attestation: Using on-chain attestations (e.g., EAS - Ethereum Attestation Service) as a condition for access, proving a user has completed a task or holds a credential.
• Subscription NFTs: An NFT whose validity as an access pass is checked against a subscription expiration timestamp stored on-chain.