Guides

Manage a pool's allowlist (PRO)

For permissioned pools (allowList: true), the allowlist controls who can deposit. This guide is the recurring operations side of running it: adding addresses, removing addresses, and reading the current set.

For the concept (what the allowlist is on-chain, the role model, the field-name asymmetry between allowList and allowlistEnabled), see Staking pools → Allowlist. For the initial setup of a permissioned pool, see Plan your first pool (PRO).

⚠️

Pro only: permissioned pools are an SVM Pro feature.

How the allowlist works in one line

The allowlist is the set of addresses holding DEPOSIT_ROLE on the Pool contract: there's no separate registry. Adding an address grants it DEPOSIT_ROLE; removing it revokes the role.

Before you start

  • An SVM Pro account with the right permission set.
  • The pool is permissioned (allowList: true). Open pools have no allowlist to manage.
  • The signing wallet holds ALLOW_LIST_MANAGER_ROLE on the Pool contract. The allowlist manager is set at pool creation as allowlistManager (see Plan your first pool → Open or permissioned?).

Add addresses

🖱️

to add addresses in the UI: open the pool's Allowlist tab, click Add addresses, paste one or more addresses (separated by newlines, commas, or spaces: the form validates and de-duplicates as you paste), review, and sign. The UI batches the submission; one signature covers the batch.

</> to add an address via the API: see addToAllowList. Body: { userAddress }. The endpoint accepts one address per call; to add a batch, loop over the addresses client-side. Each call returns a partial transaction the wallet broadcasts.

Verify

  • The address shows up under the Allowlist tab.
  • data.pool.DEPOSIT_ROLE on the getAllRoleMembers response includes the new address.
  • The added address can now call the pool's deposit flow.

Remove addresses

🖱️

to remove addresses in the UI: on the Allowlist tab, tick the addresses you want to remove, click Remove selected, and sign. The UI supports batch removal.

</> to remove an address via the API: see removeFromAllowList. Same { userAddress } body. Single-address per call: loop client-side for batches.

What revocation does (and doesn't do)

Revoking DEPOSIT_ROLE only affects future deposits:

  • ✅ Prevents new deposits from the address.
  • ❌ Does not claw back the address's existing pool shares.
  • ❌ Does not force a withdrawal: existing positions stay where they are until the holder requests one through the standard withdrawal queue.

If you need to fully off-board a depositor, revoke their role and rely on the standard withdrawal flow for what's already in.

Read the current allowlist

🖱️

to view the allowlist in the UI: the Allowlist tab lists every address that currently holds DEPOSIT_ROLE on the pool.

</> to read the allowlist via the API: see getAllRoleMembers. The current allowlist is at data.pool.DEPOSIT_ROLE: an array of addresses. The same response includes data.pool.ALLOW_LIST_MANAGER_ROLE (typically one address: your manager).

Useful as a check before adding (the address may already be on the list) and as a recurring audit input.

The bypass route: admin grants

A wallet holding DEFAULT_ADMIN_ROLE on the Pool contract can grant DEPOSIT_ROLE directly through the standard role-administration flow (Assign and revoke roles) without going through the allowlist-manager flow. The end state is the same (the address is on the allowlist) but the audit trail and the on-chain event are different.

This is usually undesirable in production: it sidesteps your compliance team's workflow. Use the dedicated addToAllowList / removeFromAllowList flow unless you have a specific reason not to.

Common pitfalls

  • Trying to manage an open pool. Open pools (allowList: false) don't check DEPOSIT_ROLE at deposit time. The endpoints still work, but granting the role has no effect: anyone can deposit either way. Confirm allowList: true on the vault detail response before assuming the allowlist is enforced.
  • Forgetting the role check. A wallet without ALLOW_LIST_MANAGER_ROLE can call the API and even broadcast the returned transaction: it'll just revert on-chain. The UI hides actions for unauthorised wallets; API integrations should check beforehand.
  • Removing the manager itself. Revoking ALLOW_LIST_MANAGER_ROLE from the manager is a separate operation (lives under Assign and revoke roles, not this guide). The allowlist endpoints only touch DEPOSIT_ROLE.
  • Reading the wrong field. On the pool config write side the field is allowlistEnabled; on read it surfaces as allowList (see Glossary → allowList vs allowlistEnabled). Same state, two names.
  • Batching expectations. The UI batches an N-address paste into a single visible action, but underneath each address is its own on-chain transaction. The API mirrors this: there's no "add many" endpoint. Plan gas and time accordingly for large lists.

Related

Updated about 4 hours ago