> ## Documentation Index > Fetch the complete documentation index at: https://docs.anchorage.com/llms.txt > Use this file to discover all available pages before exploring further. # Permission levels > Understand role-based permissions and what each user role can do. Porto uses role-based access control. Each user has a role that defines what they can do in the system. Roles can be different at the organization level and within individual vaults, allowing fine-grained control over permissions. ## Organization-level roles When you're invited to a Porto organization, you're assigned an organization role. This role determines your base permissions across all vaults. | Role | Organization permissions | Vault access | | :------------ | :------------------------------------------- | :------------------------------------------ | | **Viewer** | View organization structure, settings, users | View vaults and assets (no actions) | | **Operator** | Create receive addresses, request deposits | Same as Vault Operator | | **Initiator** | Initiate transfers and withdrawals | Same as Vault Initiator | | **Approver** | Approve operations from others | Approve quorum requirements | | **Admin** | Full access to all settings and users | Full vault control, can modify all policies | ## Vault-level roles Within individual vaults, you can have a different role than your organization role. This allows more granular permission management. | Role | Vault permissions | Can approve | Can initiate | | :------------ | :----------------------------------------- | :---------- | :----------- | | **Viewer** | View vault details, assets, activity | — | — | | **Operator** | Create deposit addresses, request deposits | — | — | | **Initiator** | Initiate transfers and withdrawals | — | ✔ | | **Approver** | Approve operations in this vault | ✔ | — | | **Admin** | Full vault control | ✔ | ✔ | ## What each role can do ### Viewer **Can:** * View all vaults you're added to * View vault details (name, balance, users, policies) * View asset balances and transaction history * See pending operations and approvals **Cannot:** * Initiate any operations * Approve operations * Create deposit addresses * Modify any settings **Best for:** Auditors, observers, compliance staff who need read-only access. ### Operator **Can:** * View vault details and balances * Create new deposit addresses * Request incoming transfers/deposits * View Activity and approvals **Cannot:** * Initiate outgoing transfers or withdrawals * Approve operations * Modify vault settings **Best for:** Treasury team members, account coordinators who work with incoming assets. ### Initiator **Can:** * Do everything Operator can do * Initiate transfers (between vaults) * Initiate withdrawals (to external addresses) * Initiate stablecoin swaps * Request Anchorage review for large transfers **Cannot:** * Approve operations (unless they're also an Approver) * Modify vault policies or user permissions * Change vault settings **Best for:** Operations team, trading staff who initiate movements. ### Approver **Can:** * Approve operations initiated by Initiators * View pending approvals and operations * See approval history * Provide comments on approvals **Cannot:** * Initiate operations * Modify vault settings * Add or remove other users **Best for:** Risk officers, compliance reviewers, senior management. ### Admin **Can:** * Do everything (all permissions) * Manage users (add, remove, change roles) * Modify vault and admin policies * Configure quorum and approval rules * Access vault recovery and security features * Export activity and reports **Best for:** Vault owners, account managers, senior leadership. ## Role separation principle The **principle of least privilege** suggests: * Give each user only the minimum permissions they need * Separate the "initiator" and "approver" roles — don't give both to the same person * This prevents unauthorized operations and reduces fraud risk **Example structure:** * Treasurers = **Initiators** (they request operations) * Finance managers = **Approvers** (they review and approve) * Compliance = **Viewers** (they audit) * One executive = **Admin** (oversees everything) ## Organization role vs. vault role Your permissions are the **most restrictive** of: * Your organization role * Your vault-specific role **Example:** * You're a Viewer at the organization level * But you're an Initiator in Vault A * **Result:** You can only View other vaults, but can Initiate in Vault A This allows organizations to give elevated permissions for specific vaults without granting them organization-wide. ## Permission matrix Complete permission matrix across all operations: | Action | Viewer | Operator | Initiator | Approver | Admin | | :---------------------- | :----- | :------- | :-------- | :------- | :---- | | **View vault/assets** | ✔ | ✔ | ✔ | ✔ | ✔ | | **View activity** | ✔ | ✔ | ✔ | ✔ | ✔ | | **Request deposit** | — | ✔ | ✔ | — | ✔ | | **Initiate withdrawal** | — | — | ✔ | — | ✔ | | **Initiate transfer** | — | — | ✔ | — | ✔ | | **Approve operation** | — | — | — | ✔ | ✔ | | **Add user** | — | — | — | — | ✔ | | **Remove user** | — | — | — | — | ✔ | | **Modify policy** | — | — | — | — | ✔ | | **Change user roles** | — | — | — | — | ✔ | ## Checking your permissions
From the home screen, tap **Settings**. Go to **Users**, **Team**, or **People**. Look for your user profile in the list. You'll see: * Your organization role * Your vault-specific roles (if different) * When you were added * Your status (active, pending, etc.)
Team screen showing user roles and permission levels
## Requesting role changes If you need different permissions: 1. **Talk to your administrator** — Explain why you need the permission change 2. **Get approved** — Your admin will review and approve the change 3. **Role updates** — Your new role takes effect immediately 4. **Verify access** — Check your settings to confirm the new role is active Role changes are tracked in your Activity log for compliance. ## Common role scenarios **Team member getting access to new vault:** * Admin creates them as an Initiator in the new vault * They keep their Operator role in other vaults * They can initiate in new vault, but only operator permissions elsewhere **Promoting someone to approver:** * Admin changes them from Initiator to Approver * They can now approve operations * They can no longer initiate (unless they're an Initiator + Approver both) **Limiting someone's access:** * Admin removes them from a vault or changes them to Viewer * They retain other roles in other vaults * Changes take effect immediately ## Best practices for role management * **Regular audits** — Review user roles quarterly to ensure they still match job functions * **Principle of least privilege** — Always start with the minimum role needed * **Separate roles** — Keep initiators and approvers separate when possible * **Document changes** — Record why role changes were made for compliance * **Onboarding checklist** — New team members should be set up with correct roles from day one * **Off-boarding** — Remove or disable accounts immediately when someone leaves ## Next steps To configure approval rules for operations based on roles, see [Policies & approvals](/knowledge-base/porto/policies/admin-policies). For instructions on managing users and changing permissions, see [Managing users](/knowledge-base/porto/users/managing-users).