> For the complete documentation index, see [llms.txt](https://docs.kpk.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kpk.io/funds/infrastructure/architecture/core-concepts/roles-and-operators.md).
# Roles and operators
The Admin and Operator roles on the shares contract, and the Safe + Roles Modifier stack behind them.
Although funds are permissionless to enter and exit, certain operations are restricted. There are two distinct permission systems:
* **On the `kpkShares` contract**: OpenZeppelin `AccessControl` roles (`DEFAULT_ADMIN_ROLE`, `OPERATOR`) gate fund configuration and request settlement.
* **On the Portfolio Safe**: Zodiac **Roles Modifiers** gate what the fund can do with its assets (see [Policies](/funds/infrastructure/architecture/core-concepts/policies.md)).
## Roles on the shares contract
Roles on the shares contract.
#### Admin
* OpenZeppelin's default role; held by the fund **admin** (a Security Council / governance Safe), or by the fund's shares timelock when one is configured.
* Manages contract-level configuration (fees, TTLs, fee receiver, performance-fee module) and authorises UUPS upgrades.
* Role key: `0x00` (`DEFAULT_ADMIN_ROLE`).
#### Operator
* Held by the fund's **Manager Safe**.
* Settles subscription and redemption requests and manages the list of accepted assets.
* Role key: `keccak256("OPERATOR")` = `0x523a704056dcd17bcf83bed8b68c59416dac1119be77755efe3bde0a64e46e0c`.
### Permission matrix
| Function | Admin | Operator | Public |
| ------------------------------------------------------------------------- | :---: | :------: | :----: |
| `requestSubscription` / `requestRedemption` | | | ✅ |
| `cancelSubscription` / `cancelRedemption` (investor/receiver, after TTL) | | | ✅ |
| `recoverAssets` | | | ✅ |
| `processRequests` | | ✅ | |
| `updateAsset` | | ✅ | |
| `setManagementFeeRate` / `setRedemptionFeeRate` / `setPerformanceFeeRate` | ✅ | | |
| `setPerformanceFeeModule` / `setFeeReceiver` | ✅ | | |
| `setSubscriptionRequestTtl` / `setRedemptionRequestTtl` | ✅ | | |
| UUPS upgrade (`_authorizeUpgrade`) | ✅ | | |
## Admin API
Configuration calls, all restricted to `DEFAULT_ADMIN_ROLE`. Fee setters that change a value charge any fee accrued under the old rate first; setters emit their update event **only when the value changes**.
```solidity
function setManagementFeeRate(uint256 newRate) external; // bps, ≤ 2000
function setRedemptionFeeRate(uint256 newRate) external; // bps, ≤ 2000
function setPerformanceFeeRate(uint256 newRate, address usdAsset) external; // bps, ≤ 2000
function setPerformanceFeeModule(address newPerformanceFeeModule) external; // address(0) disables
function setFeeReceiver(address newFeeReceiver) external;
function setSubscriptionRequestTtl(uint64 ttl) external; // ≤ 7 days
function setRedemptionRequestTtl(uint64 ttl) external; // ≤ 7 days
```
A TTL change applies to **all** pending requests, not just new ones; it shifts when existing requests become cancellable.
## Operator API
Settlement and asset management, restricted to the `OPERATOR` role (the Manager Safe).
```solidity
// Settle a batch for one asset at a given share price (8-decimal USD).
// Charges fees, validates the price-deviation guard, then mints/burns per request.
function processRequests(
uint256[] calldata approveRequests,
uint256[] calldata rejectRequests,
address asset,
uint256 sharesPrice
) external;
// Add, reconfigure, or remove an approved asset.
function updateAsset(address asset, bool isFeeModuleAsset, bool canDeposit, bool canRedeem) external;
```
`updateAsset` enforces safety rules: an asset cannot be removed while it has pending subscriptions or requests, the last approved asset cannot be removed, an asset cannot be added with both `canDeposit` and `canRedeem` false, and asset decimals are capped at 36.
## Operators in practice
Operators are KPK contributors responsible for the operational management of funds. Much of the day-to-day work is handled by **automated agents** routed through the Sub Roles Modifier; operators remain responsible for actions that cannot be executed autonomously, including:
* Approving or rejecting pending subscription and redemption requests.
* Deploying capital into pre-approved DeFi strategies, as defined by the fund's [policies](/funds/infrastructure/architecture/core-concepts/policies.md).
* Bridging assets between the fund's Safes across chains (see [Bridging](/funds/infrastructure/architecture/core-concepts/bridging.md)).
* Managing liquidity and maintaining cash positions to meet redemptions.
## The Safe + Roles Modifier stack
Operators never hold the Portfolio Safe's keys. Execution is mediated by three Zodiac Roles Modifiers deployed with every fund (see [Deployment](/funds/infrastructure/architecture/deployment.md)):
The Safe and Roles Modifier stack.
* **Exec Roles Modifier**: the primary layer in front of the Portfolio Safe; owned by the **admin**, or by the fund's exec timelock when one is configured. The authoritative gatekeeper of all Portfolio Safe execution.
* **Sub Roles Modifier**: nested inside the exec layer; routes automated/bot transactions through it. Owned by the Manager Safe.
* **Manager Roles Modifier**: guards the Manager Safe's own actions. Owned by the Manager Safe.
The Portfolio Safe's only owner is the `Empty` contract, so there is no key that can bypass this stack.
---
# 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 by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.kpk.io/funds/infrastructure/architecture/core-concepts/roles-and-operators.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
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.
