BEAM·v0.1.1·MACOS · LINUX·SHA-256 VERIFIED

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 different chainId, Beam fails instead of prompting.
  • --allowed-chains is 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