Guides

Assign and revoke roles

Roles control who can call what on a vault: funding, minting, withdrawing, exiting validators, managing the allowlist, and so on. This guide walks through granting a role to an address and revoking it again. For what each role means, see Roles and permissions.

If you're trying to decide which roles to delegate (e.g. which to keep on a cold key, which to move to a hot key), the concept page also has the three-persona model (Owner, Admin, Node Operator) as the starting point.

Before you start

  • The signing wallet holds DEFAULT_ADMIN_ROLE on the contract you're modifying. The role administrator is the only one who can grant or revoke roles on that contract.
  • You know which contract holds the role you're granting. Most vault-level roles live on the Dashboard; pool-specific roles live on the Pool or Withdrawal Queue. The full mapping is in Roles and permissions → On-chain role catalogue.
  • You have the role identifier ready. The UI offers a dropdown; the API takes the role string as defined in the contract (e.g. MINT_ROLE, FUND_ROLE, DEPOSIT_ROLE).

Grant a role

🖱️

to grant a role in the UI: from a vault page open the Permissions tab, click Grant role, pick the role from the dropdown, paste the recipient address, review, and sign.

</> to grant a role via the API: see grantRole. Body: { role, account }.

On a pool vault, the call is gated by the Timelock: schedule it through timelockSchedule with operation: "grantRoles". Same flow as below.

Verify

  • The new role holder appears under the relevant contract in getAllRoleMembers: data.dashboard[ROLE_NAME], data.pool[ROLE_NAME], or data.withdrawalQueue[ROLE_NAME].
  • The new holder can immediately call any endpoint that requires that role.

Revoke a role

🖱️

to revoke a role in the UI: from the Permissions tab, find the address and role row, click Revoke in its actions menu, review, and sign.

</> to revoke a role via the API: see revokeRole. Same body shape as grant: { role, account }.

Verify

  • The address no longer appears under that role in getAllRoleMembers.
  • Subsequent calls from that address against endpoints requiring the role fail with an authorisation error.

Pool vaults: the Timelock detour

For pool vaults, role administration is one of the timelock-gated operations. You can't grant or revoke directly: you schedule the change, wait for the delay, then execute.

The timelock schedule call accepts a batch of role assignments, so a multi-role change happens in one scheduled operation:

</> to schedule a role change on a pool vault

Schedule: timelockSchedule: operation: "grantRoles" (or "revokeRoles"), params: { assignments: [{ role, account, target }] }. target is "dashboard", "pool", or "wq" (defaults to "dashboard").

Execute (after minDelaySeconds): timelockExecute.

Cancel before execution: timelockCancel.

The UI walks you through the same three states (scheduled, ready, executed) on the Permissions → Pending changes view.

Read current role members

To audit who currently holds what:

🖱️

to read role members in the UI: the Permissions tab lists every address per role, grouped by contract.

</> to read role members via the API: see getAllRoleMembers. Response groups members by contract (dashboard, pool, withdrawalQueue): pool and WQ are null on dedicated vaults.

Useful as a check before granting (the address might already hold the role) and as a recurring audit input.

Common pitfalls

  • Revoking your own DEFAULT_ADMIN_ROLE. Once revoked, no one can re-grant roles on that contract. If DEFAULT_ADMIN_ROLE only sat with you, the contract becomes administratively locked. Always confirm at least one other holder exists before revoking your own.
  • Granting DEFAULT_ADMIN_ROLE casually. That role can grant and revoke every other role. Treat it like the vault owner key: usually cold, never delegated to an automation wallet.
  • Wrong target contract. A pool's DEPOSIT_ROLE lives on the Pool contract, not the Dashboard. Granting it on the wrong contract is a no-op. The API distinguishes targets via the target field in the timelock schedule; the UI picks the right contract from the role name.
  • Forgetting the timelock delay on pool vaults. A grantRoles schedule can't execute until minDelaySeconds has elapsed. Don't schedule the change and assume it's live the same day.
  • Granting a role to an address that already holds it. The transaction succeeds but is a no-op. Read members first if you're not sure.

Related

Updated about 4 hours ago