This article explains how access control works in Organizations, who can do what, and on which accounts. For how approval policies govern those actions, see Policies, approvals, and governance. For a high-level overview, see About Organizations.
Access in Organizations is built on two layers:
Permissions define what a Member is allowed to do and on which accounts.
Policies determine whether an action is completed immediately or must be approved by other Members first.
A Member's effective access depends on both layers. Permissions determine what a Member can do; the workflow's policy determines whether the action completes immediately or requires independent approval first.
You can allow some Members to complete actions immediately while requiring everyone else to go through approval, or require approval for every request, regardless of who initiates it.
For how policies and approvals work, see Policies, approvals, and governance.
Permissions define what a Member is authorized to do. They fall into two categories based on what they scope access to.
Account permissions define which actions a Member can perform and on which accounts. Each grant is scoped to a specific account — access to one account does not carry over to another. During Beta, only one account is available — see Beta limitations. The effective access is a combination of the permission grant, the account scope, and the workflow policy.
Permission | What it allows |
|---|---|
Handla | Place and manage orders on Spot and Margin markets |
Earn Allocate | Allocate assets into Earn (staking and yield) products |
Earn Deallocate | Deallocate (unstake) assets from Earn products |
Account permissions take effect immediately for trading and Earn operations. As multi-account support becomes available, risk will also be managed through account segregation, controlling which accounts a Member can operate on.
Workflow permissions govern how actions are performed within each workflow. These permissions apply to Members only. Service Users are authorized through API key permissions instead — see Service Users for details.
Every workflow supports the same four levels:
Permission level | What it allows |
|---|---|
Visa | Read-only access to the workflow's data and request history |
Initiera | Create a new request. The request enters the approval queue unless the Member also holds Execute and the policy allows immediate completion. |
Godkänna | Review and approve or reject a pending request created by another Member |
Verkställ | Complete actions immediately without waiting for approval, but only when the workflow policy allows it |
How a request is completed depends on the Member's permissions and the workflow's policy:
Member's permissions | "Always require approval" | What happens |
|---|---|---|
Initiate (without Execute) | OFF or ON | Request enters the approval queue |
Initiate + Execute | OFF | Request completed immediately |
Initiate + Execute | ON | Request enters the approval queue |
Execute bypasses the approval queue when the workflow policy allows it. When "Always require approval" is ON, Execute has no effect.
See Execute and policy interaction for details.
Some permissions are automatically granted so Members have the visibility they need:
When a Member has... | They automatically receive... | Why |
|---|---|---|
Initiate or Approve on any workflow | View on that same workflow | Members who participate in a workflow need to see its data |
Initiate or Execute on Initiate Withdrawal | View on Manage Addresses | Members who can withdraw funds need to see whitelisted destinations |
Initiate or Execute on Manage Policies | View on Manage Access | Members who can edit policies need to see current permissions |
These implicit grants cannot be removed independently. To remove an implicit View grant, remove the permission that triggered it.
All governed actions are organized into workflows. Each workflow contains a defined set of operations and has its own independently configurable policy. The four permission levels (View, Initiate, Approve, Execute) work the same way across all workflows.
Controls who can request, approve, and complete fiat and crypto withdrawals.
Operations:
Because withdrawals move funds out of the Organization, this workflow is typically the first one configured to require approval.
How permissions apply here:
Controls who can add or remove whitelisted withdrawal destinations. Funds can only be sent to addresses on this list, so changes here directly affect withdrawal risk.
Operations:
How permissions apply here:
When a Member uses Execute to complete an address change immediately, the system requires email confirmation before the change takes effect. During Beta, the confirmation is sent to the Organization Owner. See Email confirmation for address changes.
Important: Administration workflows follow the same governance model as funding workflows. Once configured with a policy, the Owner and all Members are bound by the same approval rules, including for managing access and changing policies.
Controls who can manage the Organization's Members and Service Users.
Operations:
How permissions apply here:
Controls who can modify the approval rules that apply to each workflow. This is the workflow that governs how all other workflows operate.
Operations:
How permissions apply here:
Caution: Manage Policies is one of the highest-impact workflows. A change here can affect how every other workflow operates. See Locking policies for details.
If the Manage Access workflow has a policy configured, your changes may enter the approval queue instead of taking effect immediately. See Policies, approvals, and governance for details.
You can change a Member's permissions at any time by returning to Manage Access and editing their configuration. The same governance rules apply to permission changes as to the original assignment.
When assigning permissions, you can choose from predefined role templates that bundle common permission combinations. Templates are a starting point — you can adjust individual permissions after applying a template.
Role template | Intended use |
|---|---|
Observatör | Read-only access across all workflows |
Handlare | Account trading permissions with no administrative access |
Fund Manager | Permissions for funding operations (withdrawals, address management) |
Initierare | Can initiate requests across workflows but cannot approve or execute |
Approver | Can approve requests across workflows but cannot initiate or execute |
Admin | Full permissions across all workflows |
Anpassa | Manually configured permission set tailored to your needs |
During Beta, Custom roles cannot be saved and reused. You can create the same Custom configuration with a previously used name as long as it does not use the reserved role template names listed above.