Skip to main content
Address allowlists control where an agent can send funds and which contracts it can call. An agent restricted to a specific set of addresses cannot send funds anywhere else — even if it is compromised. Allowlists are set in the policies field of a PactSpec at submission time and are fixed once the pact is activated.

​
Two allowlist types

​
Destination address allowlist

Restricts which wallet addresses an agent can transfer funds to. The allowlist is per-chain — the same address on two different chains must be listed separately.

​
Contract address allowlist

Restricts which smart contracts an agent can call. Each entry specifies a chain and contract address. Optionally, a function selector can be included to restrict the agent to specific functions on that contract — for example, allowing only swap() on a DEX router while blocking any administrative functions on the same contract. For Solana, the equivalent restricts by program ID.

​
How allowlists work

An allowlist is set as part of an ALLOW policy’s match conditions. If destination_address_in or target_in is specified, the policy only covers operations that match those addresses. Operations to any address not in the list are not covered and will be blocked. Leaving the address condition unset means all destinations are permitted (subject to other controls).

​
Use cases

DCA agent restricted to a specific DEX: configure the contract allowlist with the DEX router’s address and the relevant function selectors. The agent can execute swaps but cannot call any other contract. Payroll agent restricted to known recipients: configure the destination allowlist with the approved recipient addresses. The agent can execute distributions but cannot send funds anywhere else. Multi-step DeFi strategy: configure multiple protocol contracts (DEX router, lending protocol, staking contract) across the chains involved. The agent is pre-authorized for the full execution path and blocked from interacting with anything outside it.

​
Further reading

  • Policy engine — how address allowlists fit into the three-stage evaluation pipeline
  • Spend limits — how to combine allowlists with value and count limits