Authorization and execution model

Access control is the policy and set of guards that determine which callers may cause protected effects and who may change those rules. Authorization is one guard's decision about an attempted call. Execution turns an intended action into one or more calls, and each protected call boundary evaluates the caller and context it receives.

Effective authority in an Ethereum system is the set of protected effects an actor, process, or account can cause through its available execution paths. Access-control administration changes the policy. For Aragon’s concrete caller paths and checks, see OSx authorization paths.

From an intended action to an onchain callCopy Anchor Link

An actor may call a contract directly, or a governance process may resolve actors' preferences into approved actions. An action specifies an intended call: its target address, native-token value, and calldata. Execution carries that action into the EVM as one or more calls.

Every call has a caller and a target. For an ordinary EVM CALL, the target sees the caller as msg.sender. These terms are relative to a call frame: when contract A calls contract B, A is the caller and B is the target; if B calls C, B is the next caller. A transaction starts from a signed account, while a contract account can make later calls only through its code.

A governor and an execution account can be the same contract or separate ones. The important question is always the same: which address makes the call that a protected target function receives? That address, rather than the actor who originally expressed a preference or submitted the transaction, is the input to ordinary caller-based authorization.

What authorization decidesCopy Anchor Link

A guarded target can base its authorization decision on:

• the caller requesting the call;
• the target contract whose function is guarded;
• the function selector;
• the call data, when the rule needs to constrain arguments or a batch of calls; and
• the native-token call value, when value changes what the call is allowed to do.

The guard may also use relevant contract state, such as a time delay. If it denies the call, execution reverts at that boundary.

Access-control policy can be target-local or shared; this distinction describes where its configuration and decision logic live:

• Target-local policy. The target contract keeps an owner or roles and checks them in its own code. OpenZeppelin AccessControl supports role-based checks, but the role assignment and the function's required role belong to each target contract.
• Shared policy. One authority applies policy across protected functions or contracts. OpenZeppelin AccessManager provides this arrangement for AccessManaged targets. In OSx, each DAO applies its permission policy to its own guarded functions, and DaoAuthorizable contracts ask that DAO to decide their checks within the organization. Every protected function must consult the relevant authority.

How authority composes across layersCopy Anchor Link

Authority can first bundle at one target: if one role permits two functions, every caller with that role may use both.

Authority can also aggregate across targets. An account may hold ownership or roles for many target functions. Higher in the call stack, a governance process that directs the account can cause only the calls that its execution grant permits and downstream targets accept under the supplied calldata and value, the current authorization configuration, balances, and contract state. Downstream guards still run and see the account as caller.

If the execution grant permits arbitrary targets and calldata, the process can exercise through that route all downstream authority the account can exercise. Limiting the grant to selected calls can preserve distinctions between processes when the configured scope enforces them; see scoped authority for that product rule. Gradual permission handover applies it over time.

Shared authority and execution custodyCopy Anchor Link

OpenZeppelin AccessManager is also shared access control. Its core policy assigns caller roles to target-function selectors, with optional delays and a schedule/execute route. An AccessManaged target called directly authorizes the original caller, while a call routed through AccessManager.execute reaches the target with AccessManager as the caller after the manager authorizes or schedules the original caller. OSx records (where, who, permissionId) grants and can attach a condition that evaluates the full data supplied to the permission check; a permission ID names a capability independently of function selectors.

In an AccessManager-based architecture, the designer separately chooses which component holds assets and broader execution authority. GovernorTimelockAccess connects a Governor to the manager's workflow while the Governor can retain its assets and permissions. The comparable separation can therefore be composed from OpenZeppelin contracts; OSx provides the organization-specific account, treasury, permission authority, and execution boundary together in the DAO.

Administer access controlCopy Anchor Link

Grants, revocations, role assignments, and selector mappings are authorization configuration. An authorized administrator or governed account performs those configuration actions, and the resulting configuration changes who may call the protected functions. Changing that configuration does not upgrade a target contract's code.

Understanding a configuration means inspecting who may change the access-control policy and which calls the configured execution paths let each process cause a target to accept; OSx authorization paths applies that inspection to Aragon's contracts.