Chain allowlists
--allowed-chains constrains which destination chains Beam will pay on without prompting.
Usage
$ beam fetch --allowed-chains <NAME|ID>[,<NAME|ID>...] <URL>
If a payment request targets a chain that is not in the allowlist, Beam fails instead of prompting on that network.
Examples
$ beam fetch --allowed-chains base https://paywall.example/article
$ beam fetch --allowed-chains base,8453 https://paywall.example/article
$ beam fetch --allowed-chains base,arb,payydev https://paywall.example/article
Selectors
--allowed-chains accepts the same selectors as the rest of Beam: canonical names (ethereum, base, arbitrum, payy-testnet), aliases (eth, bsc, arb, payydev), and numeric chain ids (1, 8453, 42161).
Interaction with --chain
--chain <name|id> and --allowed-chains behave slightly differently:
--chain <name|id>forces x402 offer selection on that chain. For MPP, it's an explicit constraint — if the challenge already includes a differentchainId, Beam fails instead of prompting.--allowed-chainsis the auto-approve set. A request that targets a chain outside the allowlist always fails, regardless of--chain.
The combination — pin to one chain with --chain, then restrict approvals to that same chain with --allowed-chains — is the safest pattern for autonomous agent runs.
Without --allowed-chains
When --allowed-chains is not set and the payment request targets a chain different from your selected/default chain, Beam prompts for confirmation. For non-interactive agent runs, always pass --allowed-chains.
Why it matters for agents
A buggy or compromised paywall could attempt to redirect payment to an unexpected chain (e.g., a network where you hold more value). --allowed-chains makes that class of redirect impossible.
beam --from agent --chain base fetch \
--max-fee 0.001 \
--allowed-chains base \
https://paywall.example/api/data