> For the complete documentation index, see [llms.txt](https://spree-finance.gitbook.io/spreefinance/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://spree-finance.gitbook.io/spreefinance/spree-studio/roles-and-access.md).

# Roles & Access

Spree separates **Studio account access** (who can log in to the dashboard) from **on-chain roles** (what your wallet can call at the contract level). Both layers matter; they answer different questions.

## Studio Account Access

Authentication is email-OTP. You enter your email, receive a 6-digit code, and verify. Your session is a JWT scoped to your account.

Organization membership grants access to that organization's deployments. Members are added or removed from `/admin`.

## On-Chain Roles

The on-chain role model uses OpenZeppelin AccessControl. Each role is a `bytes32` hash that gates specific contract functions. Granting and revoking roles is itself a role-gated action.

| Role                    | Contract                  | Gates                                                                                                           | Typical holder                           | How granted                                          |
| ----------------------- | ------------------------- | --------------------------------------------------------------------------------------------------------------- | ---------------------------------------- | ---------------------------------------------------- |
| `DEFAULT_ADMIN_ROLE`    | Factory, Points, PSPVault | Upgrade auth, role admin, oracle / fee receiver, transfer-whitelist add/remove on Points                        | Brand admin multisig                     | Held by deployer; migrate to multisig for production |
| `MANAGER_ROLE`          | Factory                   | Mint/redeem rates, basket mode, pegging offsets, collateral status, mint and redeem whitelist add/remove, pause | Brand operator                           | Auto-granted to deployer wallet at deploy completion |
| `EXECUTOR_ROLE`         | Factory                   | Finalize and reject redemption requests                                                                         | Settlement service                       | Manual                                               |
| `PAUSER_ROLE`           | Factory, vaults           | Pause Factory and vault operations                                                                              | Risk / ops                               | Manual                                               |
| `CAMPAIGN_ADMIN_ROLE`   | PSPVault                  | Create, activate, deactivate campaigns                                                                          | Brand campaign manager                   | Auto-granted to deployer wallet                      |
| `ISSUING_ADMIN_ROLE`    | PSPVault                  | Mint pSP into existing campaigns                                                                                | Distribution service or external partner | Auto-granted; often delegated                        |
| `SETTLEMENT_ADMIN_ROLE` | PSPVault                  | Settle pSP → SP, clawback (`expire`) unfulfilled pSP                                                            | Settlement service                       | Auto-granted                                         |
| `TRANSFER_ADMIN_ROLE`   | PSPVault                  | Admin transfer of pSP between users                                                                             | Compliance / support                     | Auto-granted                                         |

The roles you receive automatically (`MANAGER`, `CAMPAIGN_ADMIN`, `ISSUING_ADMIN`, `SETTLEMENT_ADMIN`, `TRANSFER_ADMIN`) cover all standard operations. `DEFAULT_ADMIN`, `EXECUTOR`, and `PAUSER` are intentionally narrow and you decide who holds them.

## Treasury and Multisig

You can attach a Gnosis Safe to your deployment as the holder of the highest-authority roles. Owners and threshold are set during onboarding. Partners running production programs typically migrate `DEFAULT_ADMIN_ROLE` from the deployer wallet to a Safe with a 2-of-3 or 3-of-5 threshold.

## Partial Authority Delegation

A common pattern: you want to delegate one slice of operations to a partner without giving them control over the whole system. The PSPVault offers two delegation paths, in increasing scope:

1. **Per-campaign delegated minter** — `setMinter(campaignId, minter, limit, active)` on a single campaign. The delegate can call `mint(campaignId, ...)` for that one campaign up to `limit` total. No on-chain role is required, and the delegate cannot mint into any other campaign. Use this for tightly-scoped issuance partners (e.g., a partner running one specific campaign).
2. **Global `ISSUING_ADMIN_ROLE`** — the holder can call `mint(...)` on **any** active campaign on the vault, budget-limited only. Use this for internal distribution services that handle every campaign you launch.

Both paths leave Factory authority (mint/redeem rates, fee config, pause) untouched, so neither delegate can break your branded SP economics.

See [Whitelist Management → Partner A → Partner B walkthrough](/spreefinance/spree-studio/whitelist-management.md#worked-example-partner-a--partner-b-partial-delegation) for the canonical scoped-delegation example with Studio, SDK, and HTTP API steps.