Skip to main content
Each shield contract validates 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. 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-001BTC) 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:
The SDK accepts symbols ('BTC' | 'ETH') for the 6 active products and encodes them to bytes32. You can also pass a 32-byte hex string directly.

Common errors