> For the complete documentation index, see [llms.txt](https://docs.t-rex.network/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.t-rex.network/reference/identity-suite/keyapprovalmodule.md). # KeyApprovalModule `KeyApprovalModule` is the execution queue of an identity: the ERC-734 functions `execute` and `approve`. A key proposes a call, the module runs it at once when the purpose of the key allows it, and otherwise keeps it until a key with enough authority approves it. One deployment serves every identity. ### At a glance | | | | ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Source** | `contracts/modules/executors/KeyApprovalModule.sol` | | **Interface** | `IKeyExecutor` | | **Module types** | Executor and fallback handler (ERC-7579) | | **Reached through** | The identity: `Identity.execute(_to, _value, _data)` and `Identity.approve(_id, _shouldApprove)` are routed to the module, which reads the caller the identity appends | | **State** | Per identity: a nonce, the requests, and the first valid request id | > **Direct calls only.** `execute` and `approve` work when a key holder calls them on the identity. A call relayed as a user operation, or dispatched by the identity to itself, carries no key holder and is refused. ### Functions | Function | Access | Reverts with | | ---------------------------------------- | ---------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `execute(_to, _value, _data)` | A key that holds `PROPOSER`, `ACTION`, `CLAIM_SIGNER`, `CLAIM_ADDER` or `MANAGEMENT` on the identity | `SenderCannotPropose`, `ReturnToAccountFailed`. Returns the `executionId`. Emits `ExecutionRequested`, then runs the request when it is approved automatically | | `approve(_id, _shouldApprove)` | `MANAGEMENT` for a management target, `ACTION` for another target | `InvalidRequestId`, `RequestInvalidated`, `RequestAlreadyExecuted`, `SenderDoesNotHaveManagementKey`, `SenderDoesNotHaveActionKey`, `ProposerNoLongerAuthorized` when approving a request whose proposer lost its key. Emits `Approved`, then runs the request when approved | | `getCurrentNonce()` | Anyone, read | The next execution id of the calling identity | | `getExecutionData(account, executionId)` | Anyone, read | The stored request | | `isManagementTarget(target)` | Anyone, read | Whether a target requires `MANAGEMENT` for the calling identity | ### What runs automatically | Key of the proposer | Target | Result of `execute` | | ----------------------------------------- | ---------------------------------------------------- | ----------------------------------------- | | `MANAGEMENT` | Any | Runs at once | | `ACTION` | An external contract that is not a management target | Runs at once | | `ACTION` | The identity, its factory or its key registry | Queued, until a `MANAGEMENT` key approves | | `PROPOSER`, `CLAIM_SIGNER`, `CLAIM_ADDER` | Any | Queued | * **The value comes from the identity.** `_value` is paid from the balance of the identity. Any value sent with `execute` is returned to the identity. * **A failed call does not revert.** The module catches the revert of the dispatched call: the transaction succeeds and the module emits `ExecutionFailed` in place of `Executed`. The request is closed either way. * **A rejection closes the request.** `approve(_id, false)` marks it executed without running it. * **An uninstall voids the queue.** Uninstalling the module from an identity voids every request queued so far (`QueueInvalidated`). A voided request reverts with `RequestInvalidated`. * **Claims are not added through the queue.** A request that targets the identity with `addClaim` or `removeClaim` cannot succeed: a claim key calls these functions on the identity directly. ### A stored request `getExecutionData` returns the struct `Execution`. | Field | Content | | --------------------- | --------------------------------------------- | | `to`, `value`, `data` | The call | | `proposer` | The address that queued it | | `approved` | Whether it was approved | | `executed` | Whether it is closed: run, failed or rejected | | `succeeded` | Whether the call ran without reverting | ### Events | Event | Emitted when | | ------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------- | | `ExecutionRequested(address indexed account, uint256 indexed executionId, address indexed to, uint256 value, bytes data, address proposer)` | A key queues a call of the identity `account` | | `Approved(address indexed account, uint256 indexed executionId, bool approved, address approver)` | The request is approved or rejected | | `Executed(address indexed account, uint256 indexed executionId, address indexed to, uint256 value, bytes data, address executor)` | The call ran | | `ExecutionFailed` (same arguments as `Executed`) | The call reverted | | `QueueInvalidated(address indexed account, uint256 firstValidId)` | An uninstall voids the requests below `firstValidId` | --- # 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.t-rex.network/reference/identity-suite/keyapprovalmodule.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.