Access List

Overview

The purpose of the Access List Plugin is to restrict pool access to approved users only.

Briefly, a pool that uses this plugin checks tx.origin against an access list registry before allowing the following actions:

• swaps

• adding liquidity

• flash loans

• pool initialization

Liquidity removal is always allowed. This ensures that verification is enforced for entry and active usage, without preventing users from exiting an existing position.

Details

The access list module is designed to work through the following Algebra plugin hooks:

• beforeSwap

• beforeFlash

• beforeModifyPosition

• afterInitialize

For liquidity modification, only positive liquidityDelta values are checked, so adding liquidity is gated while removing liquidity is not.

The plugin uses tx.origin as the end-user identifier. In practice, this means the registry validates the externally owned account (EOA) that initiated the transaction, rather than an intermediate router or helper contract.

Some "whitelist systems" solve this by keeping a msgSender() method on supported routers, which returns the original EOA. This approach can work well, but it depends on router-level integration. In this plugin, a simple sender parameter check is not sufficient. since pool actions are typically called through peripheral contracts such as routers or position managers.

For this reason, the implementation relies on tx.origin. This approach is simpler and does not require custom router support, but it comes with trade-offs:

• weaker compatibility with account abstraction and smart wallets

• limited support for relayers and meta-transactions

If required, a router-based approach can be added later by adding msgSender()-style methods to the position manager and swap routers, then requiring third-party integrations to support the same interface.

The plugin does not perform identity verification on-chain. The expected flow is:

1. The user completes verification via a website or another off-chain process.

2. A backend or operator decides whether the wallet should be approved.

3. An ACCESS_LIST_MANAGER account updates the AccessListRegistry.

4. Pool actions are allowed or reverted based on the registry state.

Access List Registry

AccessListRegistry is the single source of truth for whitelist status.

It provides the following management methods:

• setWhitelisted(address user, bool status)

• setWhitelistedBatch(address[] users, bool[] statuses)

• pause()

• unpause()

When the registry is paused, all access list checks are bypassed. This serves as an emergency mechanism, alowing the protocol to temporarily disable access list enforcement without updating plugin configuration on every pool.

AccessListRegistry does not store per-pool state. It manages users globally. However, different pools may use different registries if their plugins point to different registry contracts. If the registry address is not set, all access list checks are bypassed.

How To Configure the Access List Plugin

Whitelist users who should be allowed to interact with access-list-protected pools by calling: setWhitelisted(address user, bool status) or setWhitelistedBatch(address[] users, bool[] statuses).

Operational notes:

• setting the plugin registry to address(0) disables access list for that plugin

• pausing the registry bypasses checks for all plugins pointing to that registry

Roles

There is access list-specific role in AccessListRegistry :

• ACCESS_LIST_MANAGER

ACCESS_LIST_MANAGER can:

• add or remove a single user from the whitelist

• batch update whitelist statuses

• pause verification

• unpause verification

The registry enforces access via IAlgebraFactory(algebraFactory).hasRoleOrOwner(...), which allows the Algebra factory owner to act as an administrative fallback (if suppported by the factory implementation).

The plugin has a separate admin role:

• ALGEBRA_BASE_PLUGIN_MANAGER can call AccessListRegistry``(address)