Allowlist Interface

Understand the AllowList interface used by many Avalanche L1 precompiles and how its roles work.

Overview

Avalanche L1s ship multiple default precompiles that need access control. Rather than inventing a new permission model for each feature, many of them reuse the same audited permission interface: the AllowList interface.

This matters because once you understand Admin / Manager / Enabled, you can reason about (and safely operate) a large set of precompiles with the same mental model.

The AllowList interface

The AllowList interface exposes a small set of functions to manage roles for addresses:

Functions

setAdmin(address addr): give addr Admin role.
setManager(address addr): give addr Manager role.
setEnabled(address addr): give addr Enabled role.
setNone(address addr): remove any role from addr (back to None).
readAllowList(address addr) -> uint256: read the current role value.

Permission levels

The roles are:

Admin: can manage all roles (Admin, Manager, Enabled).
Manager: can manage Enabled addresses only.
Enabled: can use the precompile’s functionality (what that means depends on the specific precompile).
None: no access.

This is a role-based access control pattern, implemented consistently across precompiles that opt into it.

Precompiles that use AllowList

Several default Avalanche L1 precompiles implement this interface (examples):

Note on stateful precompiles

Many precompiles are stateful (they can read/write chain state at the VM layer). If you haven't seen this concept yet, review the Stateful Precompiles section in the Customizing the EVM course.