For the complete documentation index, see llms.txt. This page is also available as Markdown.

Access Controls

The Access Control system implements granular, function-level permissions across all contracts of Cap. It provides a sophisticated role-based access control mechanism that allows precise management of who can call specific functions on specific contracts, building on OpenZeppelin's AccessControlEnumberable Integration.

Roles are managed by the Access Control admin, currently set to Cap's multisig address

Mechanics

  • Each function on each contract has its own unique 32-byte role ID

  • The role ID is generated by combining:

    • The function selector (first 4 bytes of the function signature)

    • The contract address

  • Permissions can be granted/revoked at the function level

  • Contracts inherit access control through the Access abstract contract and uses the checkAccess modifier on protected functions

For function signatures and data structures, see the Access Controls Contract Reference.

Role Hierarchy

DEFAULT_ADMIN_ROLE
├── access_control_admin
│   ├── oracle_admin
│   ├── rate_oracle_admin
│   ├── lender_admin
│   ├── delegation_admin
│   └── vault_config_admin
└── Emergency Admin
  1. DEFAULT_ADMIN_ROLE: Can upgrade the AccessControl contract

  2. Access Management Roles: Can grant/revoke permissions

  3. Function-Specific Roles: Control access to individual functions

Permission Types

1. Administrative Permissions

  • Contract upgrades (bytes4(0))

  • Access management (grantAccess, revokeAccess)

2. Operational Permissions

  • Vault operations (borrow, repay, mint, burn)

  • Oracle managements (setOracleData, setStaleness, setRates)

  • Asset management (addAsset, removeAsset, pauseAsset, setReserve)

  • Fee Auctions (setDuration, setStartPrice ,setPaymentToken)

  • Delegations ( addAgent, modifyAgent ,registerNetwork)

3. Emergency Permissions

  • Protocol pause (pauseProtocol, unpauseProtocol)

  • Emergency functions (emergencyWithdraw, rescueERC20)

Timelock

Critical administrative operations are routed through an OpenZeppelin TimelockController with a 1-day minimum delay (86,400 seconds). The Timelock enforces a mandatory waiting period between when an operation is proposed and when it can be executed, giving participants time to react to parameter changes.

The Timelock holds permissions on Cap contracts via the same role-based access control system described above. Operations must be scheduled, wait the full delay period, and then be explicitly executed — they cannot bypass the delay.

Parameter
Value

Min Delay

86,400 seconds (1 day)

Last updated