params.asset against a hardcoded literal.
Sending the wrong asset reverts with InvalidAsset(bytes32) even though
the payment token (USDC) is the same for every product. The asset is
a what-it-covers tag, not the payment token.
The 6 V5.4 products
The bytes32 hashes below come from the live/products endpoint and match
the PRODUCT_ID constants in each BaseFlashShield deployment on Base
mainnet. /products returns 6 active shields. Agents should still filter by
active === true to be forward-compatible with future product retirements.
Each shield is fronted by a
FlashShieldAdapter (UUPS proxy) — discover
the adapter address with productShield(productId) on PolicyManagerV2,
or just read it off /products.
Recommended: pass productName and let the SDK resolve everything
SDK 0.6.x auto-resolves both the bytes32 productId hash AND the per-shield
asset literal from the canonical name. You don’t need to compute keccak
yourself, and you can’t accidentally pair FLASHBTC1H-001 with ETH.
REST: pass productName to POST /api/v1/policies
The same shortcut works at the API level. asset is optional; if you
omit it, the API auto-resolves from the registry.
Sandbox: switch shields with productName
POST /sandbox/try resolves the asset from productId (default
FLASHBTC1H-001 → BTC) or accepts productName for friendlier
switching. See Sandbox-first for the full
no-wallet path.
Advanced: explicit asset override
If you want to bypass the auto-resolver (e.g. to reproduce a revert in testing), pass the bytes32 explicitly:'BTC' | 'ETH') for the 6 active products and
encodes them to bytes32. You can also pass a 32-byte hex string directly.