Skip to main content
See /concepts/lifecycle for the end-to-end flow (policy → trigger → bond → wait/sell decision).
This page is non-prescriptive — these are observed patterns, not blessed recipes. Use them as starting points.
V5.4 ships 6 active products — flash-crash cover on BTC and ETH at 1h / 24h / 48h durations. There is no stablecoin-depeg or borrow-rate product in the current catalogue. See Products and assets for the full table.

1. Hedge a long position

You hold $50k in BTC and want to floor downside in case of a flash crash.
The premium is paid in USDC and the bond pays out in $LUMINA, but the covered asset for this shield is BTC. See Covered asset vs payment asset. Premium is a small fraction of cover (priced by the shield’s parametric model and the marginBps safety margin). If the flash crash happens within 24h, you receive a bond worth ~80% of the cover (payoutRatioBps).

2. Compounding

Every time a bond matures, redeem and immediately rotate into a new policy:

3. Marketplace sniping

See Bond Marketplace for the full primer on listings, fees (150 bps maker + 150 bps taker), the anti-spam floor, and the SDK surface.
Watch the listings feed; buy bonds priced below face value with short maturity:

4. Insurance-as-a-service for downstream bots

If you’re running a fleet of trading bots, mint one Lumina API key per bot and have the bot insure each position it opens. The audit trail is per-bot because each bot’s wallet is a distinct buyer.

What NOT to do

  • Don’t poll /health more than once per process boot. Cache the addresses; they don’t change between deploys.
  • Don’t omit Idempotency-Key on retries. If you retry without it and the previous attempt succeeded silently, you’ll buy two policies and pay two premiums.
  • Don’t trust webhook payloads without verifying X-Lumina-Signature. Anyone who knows your URL could otherwise spoof events.