Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.lumina-org.com/llms.txt

Use this file to discover all available pages before exploring further.

See /concepts/shields for the products themselves, and /concepts/triggers for how a trigger reaches the adapter.
A Flash Shield Adapter (FlashShieldAdapter) is a thin UUPS-upgradeable proxy that sits in front of every V5.3 flash shield. Its only job is to expose the legacy IShieldV2 surface that PolicyManagerV2 was built against, while delegating the actual condition logic to the slim BaseFlashShield underneath.

​
Why the adapter exists

V5.3 introduced BaseFlashShield (sprint T-30a): a slim, common implementation that all 6 flash shields share. The new surface is narrower than IShieldV2 — it doesn’t carry triggerProbBps, old-style asset enum fields, or the per-shield admin functions PolicyManagerV2 calls during purchasePolicyFor / recordTrigger. Two choices were available:
  1. Migrate PolicyManagerV2 to the new ABI — but PM is the most-integrated contract in the protocol (router, indexer, agents-API, SDK, dashboards all read it). A breaking ABI change there would force every downstream to redeploy in lockstep.
  2. Insert a tiny adapter that bridges legacy IShieldV2 → BaseFlashShield per shield. The PM surface stays identical; the slim shield gets its clean ABI; the adapter is the only thing that knows both.
The adapter was chosen (T-30b adapter pattern decision). This is the canonical seam between V5.2-era integrations and V5.3-era shield internals.

​
Where the adapter sits

       PolicyManagerV2 (unchanged IShieldV2 ABI)
                │
                │ productShield(productId) → ADAPTER address
                ▼
       FlashShieldAdapter  (UUPS proxy, IShieldV2)
                │
                │ delegates to
                ▼
       BaseFlashShield (slim V5.3 logic)
                │
                ▼
       LuminaOracleV2  /  PolicyManagerV2  /  BondVault
When you read PolicyManagerV2.productShield(productId), you get the adapter address, not the underlying BaseFlashShield. Calls land on the adapter, which decodes the legacy ABI and forwards to the slim shield. Most agents never need to touch the inner BaseFlashShield directly — but the address is published (see below) for verifiability.

​
Properties

PropertyValue
PatternUUPS upgradeable (one proxy per product)
SurfaceIShieldV2 (legacy) — submitTrigger, productId, payoutRatioBps, etc.
BackingOne BaseFlashShield instance per adapter
OwnerGovernance (same multisig as the rest of the protocol)
Upgrade scopeAdapter-only; upgrading the adapter does not redeploy the underlying shield, and vice versa

​
The 6 adapters (Base Sepolia, V5.3)

ProductAdapter (what PM points to)Underlying BaseFlashShield
Flash BTC 1h0x5fC732D28c09DfcA2e7eF0AAd6C9491c8474eAdB0x06ED1ffB6bA493c036472bf1C58EC9301B5A2363
Flash BTC 24h0x844A5fDb3C910DC33Eb720fDB5387C3d55eC867d0x9E4C1E799AA41a36ae074768b33198b9D8aCC173
Flash BTC 48h0x0840d638a3E79919afE3b1AB589E6D4b5E8C45Bb0x815802E93cD7fB0C4Ce49f290F1A1Ee9473F0406
Flash ETH 1h0xeC42c7169B4D80F4D8A113607367F75c2df029350xF858b572De264DF8980dF57A680762B7cb88E351
Flash ETH 24h0xb0f143beF75F32BcAB569766e9159366f8fD69C40x18ccC1eE644C8A79DD93D0F4694960FeC5348eFA
Flash ETH 48h0x26db224D3Ddc00F4bFcF8ab26A92B9f7c81A47E60xC42360BC94401B07ca337Bc4d0Fb338604F8f4cE

​
Calling pattern from an agent

You almost never call the adapter directly. The flow that matters:
  1. Purchase. CoverRouterV2.purchasePolicy(productId, …) → PM looks up productShield(productId) → calls the adapter, which forwards to BaseFlashShield.recordPolicy(...).
  2. Trigger. ShieldKeeper (or any caller) calls adapter.submitTrigger(payload, signature). The adapter forwards to BaseFlashShield.submitTrigger(...) for the actual signature + sequencer + drop checks. On accept, the base shield calls BondVault.mint(...).
For 99% of agents the adapter is transparent — read productShield(productId) on PM, treat the returned address as “the shield”, call submitTrigger on it. To confirm an adapter is wired to the expected BaseFlashShield: 
# 1. Get the adapter address PM is pointing to:
cast call $POLICY_MANAGER 'productShield(bytes32)(address)' \
  $(cast keccak 'FLASHBTC1H-001') --rpc-url $BASE_SEPOLIA

# 2. Ask the adapter which BaseFlashShield it forwards to:
cast call $ADAPTER 'implementation()(address)' --rpc-url $BASE_SEPOLIA
The first call should return one of the six adapter addresses in the table above. The second should return the matching BaseFlashShield.

​
Upgradeability and safety

Because the adapter is UUPS, governance can upgrade the legacy-ABI translation layer without touching the underlying shield (e.g. add a new field to the legacy ABI, change the way oracle proofs are routed) — and vice versa. Each adapter has its own upgrade timelock; an upgrade to one adapter does not affect the other five.

​
See also