Scoped authority
Scoped authority limits a governance process at an account's execution boundary to an explicit set of calls and, when supported, constraints on their arguments or native-token value. This lets an organization divide responsibility between processes while external contracts continue to recognize one account.
Scoped authority is a product rule for preserving separation of powers as an account's authority is composed and changed. It uses OSx permission triples and conditions. For the actors and call boundaries, see Authorization and execution; for the concrete Aragon routes, see OSx authorization paths.
The execution-boundary premise
In the usual Aragon path, a process approves a batch of actions, calls DAO.execute, and the DAO account calls each action target as itself. Each target therefore applies its access-control rules to the DAO address, not to the process that selected the action. External targets can give the account ownership, roles, or managed authority while the account's own permission configuration determines which processes may direct it.
Because the account is also the treasury, limiting the calls a process may direct limits the treasury operations and externally granted powers it can exercise through that address.
For caller paths, permission checks, and ROOT administration, see OSx authorization paths.
Prevent executor collapse
A bare EXECUTE_PERMISSION_ID grant places no target or calldata restriction at the DAO boundary. When its holder calls DAO.execute, downstream guards see the DAO as caller; those guards, balances, and contract state still determine which calls complete.
Scoped authority puts an Execute condition on that grant so the executor may forward only the selected calls. In OSx, an execute selector condition evaluates every action inside DAO.execute against configured selector and native-transfer allowances; see OSx authorization paths for the exact call cases. The batch passes only when every action passes. The configured scope can keep a process's authority aligned with its assigned responsibility.
Set an explicit scope
A selector allowlist names the target contract and function selector a process may use. It can start empty, making the conditioned grant a default-deny grant until an allowed pair is added. Removing a pair withdraws that action scope.
A selector limits the function class, not its arguments. ExecuteSelectorCondition can also control whether an action may carry native value to a target, but it does not cap the amount. A specific recipient, token amount, native-token amount, or other argument requires a condition that evaluates the relevant calldata or value. A process receives only the guarantee the configured condition can enforce.
Separate responsibilities without changing the account
Each organization can assign independent scopes to its processes: treasury operations to one, protocol parameters to another, and permission configuration to another. The onchain grants and conditions make that division inspectable independently of the app. A scope can move to a different process while assets remain held at the same address and external targets continue to recognize that address; gradual permission handover applies this principle to selected powers.
In OSx, the DAO combines the organization's shared permission authority, general-purpose execution account, stable identity, and treasury. Separate governance plugins can receive independently scoped Execute grants into that account, so several processes can hold distinct powers over one treasury. The authorization model compares shared authority and asset custody across OSx and OpenZeppelin arrangements.
Change authority through configuration
Granting, revoking, and conditioning permission entries, or changing an execute-condition allowlist, are permission and configuration actions. They change authority configuration and condition state; they do not upgrade the account's or a target's implementation code. The governed ROOT route for those actions belongs to OSx authorization paths.
The governance designer sets a new process's initial scope: Any action gives it a bare Execute grant, while Specific actions creates a selector-scoped grant. The action builder composes governed change actions. Permission Viewer presents the account-wide indexed grants and conditions, while the process details page presents the selected authorized actions for one process.
Last updated on