> For the complete documentation index, see [llms.txt](https://takes.gitbook.io/takes-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://takes.gitbook.io/takes-docs/security-and-trust/roles-and-permissions.md). # Roles and permissions Takes relies on privileged keys for account setup, trading, and request processing. | Role | Authority | Main limitation | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------- | | Holder | Request, cancel accepted requests where supported, and claim their entitlement | Cannot execute requests or claim another holder's funds. | | Creator | Choose initial configuration, earn the creator share of the pool's fees, and hand future shares to another wallet | Cannot change the fixed basket, the fee split, or withdraw holder backing. | | Attestation signer | Sign the backend attestation that registers a pool's first creator with the fee distributor | Cannot replace a registered creator or move earned balances. | | Platform owner | Owns each chain's platform registry: rotates roles, sets the fee recipient, replaces the fee quoter, registers factories, resumes pools and ends maintenance | Production ownership requires a multisig-controlled timelock with at least 72 hours' delay. It does not grant beacon upgrade authority. | | Guardian | Turns maintenance on, restricts a pool, and revokes a pool's trading wallet, immediately | Cannot end maintenance, resume a pool, start a wind-down, install a trading wallet, change settings or move funds. | | Launcher | Pair or activate tokens, set and rotate trading wallets, approve builder fees, and configure remote hubs | Cannot re-pair a token or change trading wallets during maintenance. Rotating the launcher in the registry revokes it everywhere. | | Beacon owner | Replace implementation code for all proxies attached to its beacon | Can change custody logic; production ownership requires a multisig-controlled timelock with at least 72 hours' delay. | | Request operator | Execute eligible requests, publish settlement prices and gas, restrict pools and start wind-downs | No direct arbitrary withdrawal or trading function. Fees stay below the owner's ceiling. | | Trading API wallet | Sign exchange actions for the account | Does not control holder claims; trading can still cause losses. | | Relayer and keeper | Deliver valid messages and advance ready account steps | Cannot forge attestations or redirect validated payouts. | The percentage fee is fixed at 10 bps. Each network's fee distributor splits it at fixed rates; its owner sets the attestation signer and can upgrade it. Production policy requires timelock governance; the recorded testnet owners are listed separately in the deployment manifest. Each request's settlement fee is computed onchain by the registry's fee quoter from gas and prices the operator publishes, and is bounded by the request's own limit and the owner's ceiling. The launcher can replace a token's trading wallet, giving the replacement authority to trade its backing. Worker trading limits are policy, not a contract restriction on every action a compromised trading key could sign. If the launcher key is compromised, the guardian turns maintenance on, which blocks further wallet changes, and revokes the affected trading wallets; the owner then replaces the launcher. Every hub's maintenance follows its chain's registry: native hubs read it through their token, and CCTP and Orbit hubs are initialized with the HyperEVM registry. A revocation from a CCTP token reaches its hub as soon as Circle attests it; one from an Orbit token waits for rollup confirmation. Beacon upgrades do not require individual holder approval and can alter behavior described here. The owner can replace operator, launcher and guardian keys. Trading wallets are rotated by Takes services before they expire. Trading keys are stored encrypted. Encryption does not prevent a compromised service from using a key it can access. Basket publication and editing belong to the signed-in author wallet. The author earns the creator share once registered; pool contracts keep no creator fee setting. Historical creator metadata remains readable. ## Upgrades and governance For the beacon design described here, a beacon upgrade replaces the implementation used by every attached token or hub proxy. Pool addresses and storage remain in their proxies, but new implementation code can change custody and permissions without individual holder approval. This description applies to the listed beacon deployments, including HyperEVM's separate local hubs. Archived deployments may use a different design; identify the deployment and governance addresses through the [manifest](/takes-docs/reference/contract-addresses.md). The production governance policy requires a multisig-controlled timelock with at least 72 hours between scheduling the exact upgrade and execution. Takes must publish the proposed implementation address and operation ID. The multisig can cancel a queued operation immediately; a replacement requires a new full delay. Maintenance controls can act immediately but do not bypass the upgrade delay. Before execution, Takes must check storage and configuration compatibility, pause new admissions and execution, and reconcile outstanding requests and cross-chain messages. Confirmations, claims and supported recovery remain available. Cross-chain upgrades are not atomic, so both sides must remain compatible with messages already in flight. A 72-hour delay does not guarantee every holder can finish an asynchronous exit. After execution, the implementation and proxy associations must be verified before normal processing resumes. Reverting to old code cannot undo transfers, trades or state changes already made. These are governance requirements, not evidence that a particular deployment or upgrade has satisfied them. See [Custody](/takes-docs/security-and-trust/fund-custody.md#fund-custody) and [Security controls](/takes-docs/security-and-trust/threats-and-mitigations.md#security-controls). --- # 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://takes.gitbook.io/takes-docs/security-and-trust/roles-and-permissions.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.