LUMINA.

1. Executive Summary

Lumina Protocol is a parametric on-chain insurance system deployed on Base. It pays out automatically when an oracle confirms a measurable event — a price drop, a stablecoin depeg, a sustained borrow-rate spike — without claims adjusters, voting, or human intervention.

The protocol is built around four primitives:

• 6 parametric Flash Shields covering BTC and ETH flash crashes across three windows each (1h, 24h, 48h). Strike snapshot is the spot price at createPolicy and triggers fire when the asset drops by the configured threshold from that strike.
• A single, immutable BondVault holding 70 million $LUMINA as the protocol's reserve. When a policy triggers, the buyer receives ClaimBonds — ERC-1155 zero-coupon bonds with a fixed face value of $1 each, redeemable for $LUMINA at maturity (730 days). Payout is 80% of cover (deductible 20%, DEDUCTIBLE_BPS = 2000).
• A deflationary token (LUMINA, 100M fixed supply). Every USDC premium and every secondary-market trading fee is routed through the TWAPBurner, which buys $LUMINA on Uniswap V3 and burns it to 0xdead. There is no mint function.
• A relayer-paid API that lets autonomous AI agents purchase, redeem, and trade policies via a single signed HTTP call — without holding ETH for gas.

The current architecture is fully operational on Base Sepolia: six Flash Shields are live, premiums flow into the burner, the marketplace is open (3% fee burn — 1.5% seller + 1.5% buyer — USDC settlement), the Chainlink-backed oracle (BTC/USD + ETH/USD) feeds shields via the FlashShieldAdapter UUPS bridge, and a self-service onboarding endpoint lets agents mint API keys with a single wallet signature.

This whitepaper documents what is deployed today on V5.3. Forward-looking statements are confined to Section 14 (Roadmap) and Section 15 (Risks). Every numeric claim, contract address, and function signature is grounded in the protocol source code and the live /health endpoint of the production API.

2. Introduction

2.1 The problem: DeFi without protection for autonomous agents

Decentralized finance has matured into a programmable economy where bots and AI agents now execute the majority of on-chain volume. They can borrow, lend, swap, hedge, and rebalance — but they cannot insure themselves against the few events that wipe entire strategies in a single block: flash crashes, stablecoin depegs, rate spikes that force forced liquidations.

Existing crypto insurance — Nexus Mutual, InsurAce, Sherlock — is built around discretionary claims: an event is reported, a committee votes, a payout is issued (or denied) days or weeks later. That is fundamentally incompatible with autonomous agents that need a deterministic, sub-minute response.

2.2 What Lumina does differently

Lumina is parametric: every policy specifies an objective trigger condition (e.g., “BTC drops ≥ 5% in any rolling 1-hour window”). When an oracle confirms the condition, the payout fires automatically inside the same transaction. There is no claim form, no committee, no delay, no possibility of subjective denial.

Lumina is also agent-first. The API exposes a relayer pattern (POST /api/v1/policies) where the protocol pays the gas and an agent only needs an x-api-key header. Maintaining 24 individual skill files to streamline the most common operations means an agent can integrate Lumina end-to-end in under one hour.

3. Protocol Architecture

3.1 Component map

Twelve smart contracts collaborate to form the live protocol. They split across five concerns:

3.2 Policy purchase flow

The end-to-end flow from a buyer's perspective is four steps:

1. Buyer queries CoverRouterV2.quotePremium(productId, coverageAmount) — returns expected premium and payout.
2. Buyer approves the router to spend the premium in USDC.
3. Buyer calls CoverRouterV2.purchasePolicy(productId, coverageAmount, asset) (or purchasePolicyFor(...) via the relayer).
4. The router pulls premium USDC, forwards 100% of it to the TWAPBurner, then calls PolicyManagerV2.recordPolicy(...) to register the policy. PolicyCreated is emitted.

3.3 Trigger-payout flow

Triggers are permissionless: anyone can submit a valid oracle proof.

1. An off-chain signer (operated by Lumina or a third-party keeper) reads Chainlink price feeds.
2. It constructs an EIP-712 PriceProof(int256 price, bytes32 asset, uint256 verifiedAt) and signs it with the trusted oracleKey.
3. Anyone calls CoverRouterV2.submitTrigger(productId, policyId, oracleProof).
4. The router forwards to PolicyManagerV2.triggerPayout, which calls the shield's verifyAndCalculate. The shield checks the EIP-712 signature against LuminaOracleV2.oracleKey(), validates the proof timestamp window, the asset, the policy's coverage window, and the trigger condition.
5. If everything passes, BondVault.issueBond(buyer, payoutUSD) mints ERC-1155 ClaimBonds for the buyer in the corresponding maturity epoch.

3.4 Bond redemption flow

Bonds mature exactly 730 days after issuance. After maturity:

1. Holder calls BondVault.redeemBond(epochId, usdAmount).
2. The vault burns the holder's ERC-1155 balance for that epoch.
3. It transfers usdAmount worth of $LUMINA at the current TWAP price (read from CapacityOracle).

Bonds remain transferable through the secondary marketplace before maturity. Once they mature, they can no longer be listed (the marketplace's list() rejects matured bonds).

4. Insurance Products — the 6 Flash Shields

Lumina V5.3 ships six parametric Flash products: three BTC drawdown windows and three ETH drawdown windows. Each shield is a UUPS proxy inheriting from BaseFlashShield; each verifies its own trigger condition inside _doVerifyAndCalculate. The on-chain product registry uses canonical names of the form FLASHBTC1H-001 — the productId a caller passes is keccak256(canonicalName).

The FlashShieldAdapter (UUPS) is a bridge contract: it exposes the slim T-30a Flash shields through the legacy IShieldV2 surface that PolicyManagerV2 still calls, so the new shields plug into the existing core without redeploying it.

4.1 Flash Crash Shields (BTC, 3 windows)

Pay out when BTC's spot price drops from the strike snapshot taken at createPolicy by the configured threshold inside the policy window. Premium is quoted per $1,000 of cover (payout = $800 LUMINA per $1,000 cover after the 20% deductible).

4.2 Flash Crash Shields (ETH, 3 windows)

4.3 Common parameters (all shields)

Earlier V5.1 testnet builds also exposed a Flash BTC 4h window, a USDT Micro Depeg shield, and an Aave USDC Rate Shock shield. In V5.3 those products are not user-facing: the 4h BTC window was retired, the Micro Depeg product was dropped, and Rate Shock remains paused on-chain pending real-Aave wiring.

5. Pricing & Premium Model

5.1 Premium quote

V5.3 publishes a flat premium per $1,000 of cover for each shield. The buyer-facing surface is:

The protocol still applies a deterministic risk-loading inside the shield (marginBps = 20000, i.e. 2.00×) before the payout is computed; the published $/$1k figure already incorporates that loading. There is no probability factor exposed to callers — the buyer only ever needs to read the premium per $1k and the multiplier.

• cover — the buyer's coverage amount in 6-decimal USDC base units.
• premiumPer1k — the canonical premium per $1,000 cover from Section 4.
• payout on trigger — cover × (10000 - DEDUCTIBLE_BPS) / 10000 = 80% of cover (deductible 20%).
• marginBps — 20000 (effective economic multiplier ~1.60× after the 20% deductible is applied to the payout).

If the formula evaluates to zero (very small covers), the contract floors the premium at 1 micro-USDC ($0.000001).

5.2 Capacity check

Before recording a policy, PolicyManagerV2 queries BondVault.availableCapacityUSD(). If the policy's potential payout would push the vault below its backing floor (committed ≤ 50% of reserve value, i.e. ~200% backing), the purchase reverts with InsufficientCapacity.

Capacity is computed on a 1-hour TWAP of LUMINA price, not the spot price. This anti-MEV safeguard prevents an attacker from manipulating spot to either deny coverage or force the protocol into thin reserves.

BondVault enforces an additional throttle on burns/redemptions: cap 1.08% per week, FIFO queue, so a single block cannot drain the reserve even if a large cohort triggers simultaneously.

5.3 Auto-pause circuit breaker

If the LUMINA TWAP price falls below 0.005 USD, isProtocolAutoPaused() returns true and new purchases revert. The breaker uses hysteresis: once tripped, it requires the price to recover above 0.008 USD (the RESET_PRICE_FOR_NEW_POLICIES) before re-arming. This avoids flapping near the threshold.

5.4 Calibration table (current Sepolia, V5.3)

6. BondVault, ClaimBond & Maturity

6.1 The single-vault model

Earlier versions of Lumina used four separate vaults (one per asset class). The current architecture collapses them into a single BondVault holding 70 million $LUMINA. The vault is never funded directly by users; it receives its allocation at LuminaTokenV2.initialize() as part of the genesis distribution.

The vault has only two state-changing surfaces:

• issueBond(buyer, payoutUSD) — called by PolicyManagerV2 when a policy triggers. Mints ERC-1155 ClaimBonds in the maturity epoch corresponding to now + 730 days.
• redeemBond(epochId, usdAmount) — called by holders post-maturity. Burns the holder's ERC-1155 balance, transfers $LUMINA at the current price.

6.2 ClaimBond — ERC-1155 zero-coupon

ClaimBonds are ERC-1155 tokens grouped by monthly maturity epoch. The tokenId is the epoch identifier, computed as year × 100 + month (e.g., 202805 = May 2028). All bonds maturing in the same calendar month share the same tokenId and are fungible within that epoch.

Critically, 1 token = $1 USD face value at maturity. Quantities are integer dollars, NOT 6-decimal USDC base units. A bond row with balance 4000 represents $4,000 of face value, not $0.004.

Bonds are non-transferable peer-to-peer by design. The contract overrides _update to allow only mints (from == 0), burns (to == 0), and transfers via authorized operators. The LuminaBondMarketplace is the only authorized operator, ensuring the protocol captures the secondary-trade fee.

6.3 Maturity period

BOND_MATURITY_SECONDS = 730 days. A bond minted today by a triggered policy matures exactly two years from now. Maturity is fixed at issuance and does not change if the bond is sold on the marketplace — the buyer redeems at the same date.

6.4 Solvency floor

The protocol tracks totalCommittedUSD (sum of issued bonds) and totalReservedUSD (sum of capacity reservations from active policies). Their sum may never exceed SAFETY_FACTOR_BPS × reserveValueUSD / 10000. burnFromReserves — an admin path used to retire excess collateral — is capped at 5% of vault reserves per transaction.

7. Oracle & Verification

7.1 LuminaOracleV2 (Chainlink-backed on Base Sepolia)

The shield oracle is LuminaOracleV2.sol at 0x9bfa2f7A5098C89b8740D1694d1f716A0Bd871dD (Base Sepolia). It reads live Chainlink BTC/USD and ETH/USD feeds directly — no off-chain EIP-712 signer is required on the path; the legacy EIP-712 verifier remains in the contract for backwards compatibility and for future feeds that lack a Chainlink aggregator.

The legacy EIP-712 envelope (kept for upgrade compatibility) is:

For Flash BTC and Flash ETH the shield calls Chainlink's latestRoundData() path inside FlashShieldAdapter; the legacy EIP-712 path is only invoked when the asset has no native Chainlink feed.

7.2 PriceProof typed data

The shield calls IOracleV2(oracle).verifyPriceProofEIP712(price, asset, verifiedAt, signature) inside _doVerifyAndCalculate. The returned signer must equal the oracle's oracleKey().

7.3 Off-chain signer service

The lumina-api service exposes POST /api/v1/oracle/sign-proof, which:

1. Reads the current Chainlink price feed for the requested asset.
2. Constructs the EIP-712 envelope with verifiedAt = now.
3. Signs with the ORACLE_PRIVATE_KEY held in Railway's secret store.
4. Returns the ABI-encoded oracleProof ready to pass into submitTrigger.

The signer's address is auditable on-chain via LuminaOracleV2.oracleKey(). Any agent can fetch it via GET /api/v1/oracle/signer before submitting a trigger.

7.4 Permissionless trigger submission

submitTrigger has no access control. The argument is solely the cryptographic proof — a forged or stale proof reverts in the shield's verification path. This means anyone (the policy buyer, a keeper bot, an MEV searcher) can submit a valid proof and trigger a payout. The policy buyer is the sole beneficiary regardless of who calls.

7.5 Capacity oracle & solvency oracle

Two additional oracles serve internal protocol needs:

• CapacityOracle.getLuminaPrice() — provides a 1-hour TWAP of LUMINA's spot price, used by capacity and solvency checks.
• SolvencyOracle — monitors the BondVault's solvency ratio (200/100/70% bands); consumed by burnFromReserves to block burns that would compromise solvency.

8. Token Economics

8.1 Supply & standard

$LUMINA is an ERC-20 + ERC-20Burnable token deployed behind a UUPS proxy. Maximum supply is 100_000_000 * 1e18, fixed at construction. There is no mint function. Supply only decreases via burn.

The constructor enforces assert(totalSupply() == MAX_SUPPLY) after the genesis distribution, and totalBurned() returns MAX_SUPPLY - totalSupply().

8.2 Initial distribution (100M)

Minted exactly once in initialize() across five immutable address arguments:

8.3 BURNER_ROLE

Only the TWAPBurner contract holds BURNER_ROLE on the token. This role allows burnFrom to be called on any address — necessary because the burner pulls $LUMINA from the protocol's intermediate buffers and burns it. DEFAULT_ADMIN_ROLE manages role assignments. Renouncing DEFAULT_ADMIN_ROLE permanently locks BURNER_ROLE management; the deployer should only renounce after the final TWAPBurner deployment is confirmed.

8.4 FounderVesting V2 (8M, three independent paths)

The 8M founder allocation unlocks via FounderVesting V2: three independent gates, first-to-trigger wins, then three tranches of ~3.333M each release every 31 days.

• PATH 1 — 2-of-3 AltSeason gates sustained for 1 day: (A) ETH/BTC ratio > 0.050, (B) ETH/USD > $4,000, (C) Aave V3 USDC borrow rate > 7% APY.
• PATH 2 — ETH/USD > $5,000 sustained for 1 day (independent override of PATH 1).
• PATH 3 — Time fallback: 1,095 days (3 years) from deploy. With deploy on 2026-05-14, the absolute backstop date is 2029-05-13.

FounderVesting V2 is deployed at 0xfF4Db529bBCd4E3CC091E07b7845241EB4762832 and is wired to LuminaOracleV2 for the live ETH/USD and ETH/BTC reads.

8.5 TreasuryVesting (3M, drip)

• Initial lock: 180 days from deploy.
• Maximum monthly release: 250,000 $LUMINA.
• Math implication: 12 months of drip + 6 months lock = 18 months minimum to fully draw.

Releases are onlyOwner; one release per 30-day window, capped at the monthly maximum.

9. Adaptive Burn Distribution

The 100% of USDC routed to the TWAPBurner is not always burned outright. Before any LUMINA is bought and burned, the burner consults AdaptiveFeeDistributor to decide how the incoming USDC should split across four buckets:

• Burn — converts USDC to $LUMINA on Uniswap V3 and sends it to 0xdead (deflationary pressure).
• Buyback Reserve — accumulates USDC for future $LUMINA buybacks; activates strongest when momentum is bearish.
• Operations — treasury for keeper gas, oracle subsidies, and ops costs.
• Maintenance — pays for shield infrastructure, audits, and routine maintenance.

The split is not static. It adapts on two axes: protocol solvency and LUMINA market momentum. The 4×4 product of these two axes yields 16 possible distributions, each pre-tuned to one regime. The full matrix is implemented in AdaptiveFeeDistributor._lookupDistribution(sLevel, mLevel) and verified by 16-of-16 quadrant unit tests.

9.1 The two axes

Solvency tiers — computed by SolvencyOracle as the ratio of (BondVault LUMINA reserve × spot price) to total committed obligations in USD, expressed in basis points:

• ULTRA (sLevel 0) — deeply overcapitalized; the system can afford maximum deflationary pressure.
• HEALTHY (sLevel 1) — comfortably solvent; default operating regime.
• STRESSED (sLevel 2) — reserves under pressure; slow burn, save USDC for defense.
• CRISIS (sLevel 3) — near-undercapitalized; halt burn, accumulate USDC to defend price on recovery.

Momentum buckets — computed from the ratio between the short-window TWAP (30 minutes) and the long-window TWAP (1 day) of LUMINA's spot price:

• RALLY (mLevel 0) — ratio > 1.05; price trending up — burn aggressively while sentiment is strong.
• STABLE (mLevel 1) — 0.95 – 1.05; sideways — default split.
• DECLINE (mLevel 2) — 0.85 – 0.95; price softening — redirect more USDC to buyback reserve.
• CRASH (mLevel 3) — ratio < 0.85; sharp drawdown — halt burn entirely, funnel USDC into buyback reserve to support recovery.

9.2 The 16-quadrant matrix

Each cell shows the basis points routed to burn / buyback / ops / maintenance, summing to 10000 (100%):

Bold cell = HEALTHY/STABLE = the default operating regime. The four FALLBACK_*_BPS constants in TWAPBurner mirror this cell as the safety net if the distributor reverts.

9.3 Worked examples

• ULTRA × RALLY → 95% burn, 0% buyback. Reserves are deep, price is climbing — strongest deflation. Every USDC of premium translates into LUMINA bought and burned, amplifying the uptrend.
• HEALTHY × STABLE → 85/8/2/5. Default regime: most of the premium burns LUMINA, a small fraction accumulates as buyback reserve, the rest covers ops and maintenance.
• STRESSED × DECLINE → 38% burn, 55% buyback. Solvency is tight and price is softening — the matrix pivots: most USDC is held back as buyback reserve, less than 40% is burned. Burn pressure is preserved, but capital is staged for a future defensive intervention.
• CRISIS × CRASH → 0% burn, 96% buyback. The deepest distress regime: all burn halts, nearly all incoming USDC funnels into the buyback reserve. The protocol prioritizes recovery capital over deflationary signaling.

9.4 Implementation status (Sepolia testnet)

9.5 References

• AdaptiveFeeDistributor.sol — matrix implementation.
• SolvencyOracle.sol — solvency & momentum classification (momentum currently stubbed).
• AdaptiveFeeDistributorTest.t.sol — 16-of-16 quadrant tests.

10. Burn Engine & Deflationary Flow

9.1 Two burn paths

Every USDC entering the protocol routes through TWAPBurner:

1. Premiums — CoverRouterV2._purchase calls twapBurner.receivePremium(premium) after each policy purchase. The transfer is atomic with the purchase.
2. Marketplace fees — LuminaBondMarketplace.executeBuy deducts a 3% fee on every secondary trade, also routed via receivePremium.

USDC accumulates inside the burner until executeBurn() is called.

9.2 executeBurn parameters

9.3 Default 4-bucket distribution (when adaptive falls back)

The Burn bucket buys $LUMINA via Uniswap V3 (with Aerodrome as a sequential fallback) and sends to 0xdead. Each successful burn emits:

9.4 Permissionless caller

executeBurn is external nonReentrant — no onlyAuthorized. Any wallet can call it. The cooldown gates how often, and the min/max amounts gate per-call slippage. Anyone can be the burn keeper.

11. Secondary Marketplace

10.1 Purpose

ClaimBonds mature in 730 days. Holders who want liquidity sooner sell on the secondary market at a discount; buyers earn an implied yield by waiting for maturity. The market is permissionless and on-chain.

10.2 Listing flow

1. Seller sets ClaimBond.setApprovalForAll(marketplace, true) (one-time per epoch family).
2. Seller calls LuminaBondMarketplace.list(epochId, amount, priceUSDC). The contract verifies balanceOf(seller, epochId) ≥ amount and that block.timestamp < maturityDate(epochId).
3. The marketplace pulls the ERC-1155 amount via safeTransferFrom, stores a Listing struct, and emits Listed(listingId, seller, epochId, amount, priceUSDC).

10.3 Buy flow

1. Buyer approves USDC to the marketplace for priceUSDC.
2. Buyer calls executeBuy(listingId).
3. The marketplace transfers USDC from buyer, deducts a 3% fee (routed to TWAPBurner), pays the seller, and transfers the ERC-1155 amount to the buyer.
4. Maturity does not change — the buyer redeems at the original date, just like the original holder would have.

10.4 Cancel flow

The seller can cancel any of their own listings via cancel(listingId). The bond returns to the seller's wallet. There is no on-chain self-buy enforcement, but the frontend disables the Buy button when seller == connected wallet.

10.5 BuybackEngine (commit-reveal MEV protection)

A separate BuybackEngine consumes the buyback bucket from TWAPBurner using a commit-reveal scheme to prevent front-running. Operations are batched and revealed in a separate transaction; private mempool routing is recommended on the ops side.

12. Security Model

11.1 Upgradeability

All core contracts are UUPS upgradeable with _authorizeUpgrade gated by DEFAULT_ADMIN_ROLE. Upgrades require a single signer today and will move to a multisig before mainnet (see Roadmap).

11.2 Audit posture

Internal audit reports are public:

• docs/SECURITY-AUDIT-V5.md — latest internal audit covering the current architecture.
• docs/audit/v5.1-uups/ — per-chapter analysis: math edge cases, admin key risk, race conditions, time-based dependencies, oracle integration.
• docs/audit/PHASE4-AUDIT-REPORT.md — bond + marketplace flow.

The protocol carries an accepted risk note: no Tier-1 third-party audit pre-mainnet. The founder's bug bounty + multisig + cold-storage key go live at T+30d post-mainnet deploy.

11.3 Access control matrix

docs/ACCESS-CONTROL-MATRIX.md documents every privileged role, its current holder, and rotation policy. Key roles:

• DEFAULT_ADMIN_ROLE on every UUPS contract — deployer wallet today, multisig at mainnet.
• BURNER_ROLE on LuminaTokenV2 — only the TWAPBurner.
• onlyRouter on PolicyManagerV2 — only CoverRouterV2.
• oracleKey on LuminaOracleV2 — the off-chain signer's address (rotatable).

11.4 Threat model

Documented in docs/audit/THREAT-MODEL.md. Highest residual risks:

• Chainlink dependency. Flash BTC and Flash ETH shields trust the Chainlink BTC/USD and ETH/USD feeds on Base. A feed deviation or staleness event can cause spurious triggers or denied triggers. Mitigation: BaseFlashShield sanity-checks each round (positive answer, fresh updatedAt, round consistency) and reverts on stale data; the L2 sequencer uptime feed is also checked on Base mainnet (address(0) → no-op on Sepolia).
• Single vault concentration. One BondVault holds 70M LUMINA. A reentrancy or storage corruption bug there is existential. Mitigation: extensive testing, single-source-of-truth invariants, continued audit cadence, 1.08%/week FIFO throttle on outbound flows.

13. For AI Agents

12.1 Self-service onboarding

An autonomous agent can mint its own API key without human intervention. The flow is two on-line operations:

1. Sign the EIP-191 envelope "Lumina onboarding for {wallet} at {timestamp}" with the agent's wallet.
2. POST /api/v1/agent/onboard with {walletAddress, label?, signature, timestamp}.

The API verifies the signature, mints a lk_<64hex> key (SHA-256 hashed at rest), and returns the plaintext exactly once. Limits: max 3 active keys per wallet, 10 onboard attempts per IP per hour.

12.2 Relayer-paid policy purchase

The signature feature for agents: POST /api/v1/policies. The API's relayer wallet signs purchasePolicyFor on-chain on the agent's behalf. The agent does not need ETH for gas; only USDC for the premium (held by the agent's wallet, pulled by the contract). Idempotency keys prevent double-spend on retry.

12.3 Skill files

The lumina-api repo ships 24 skill files at docs/skills/ — one per common operation. Each file follows a fixed structure: a "What this does" plain-English block, a copy-pasteable LLM prompt, env vars, curl + TypeScript + Python examples, request/response schemas, and error codes. Designed to be dropped straight into an agent's tool list or system prompt.

12.4 Endpoint surface

14. Roadmap

Phases 1-4 — V5.3 deployed ✅ (Base Sepolia, 2026-05-14)

• 6 Flash shields (BTC and ETH; 1h, 24h, 48h) live and active behind FlashShieldAdapter.
• Chainlink BTC/USD and ETH/USD live; L2 sequencer feed wired (no-op on Sepolia).
• Single BondVault + 1.08%/week FIFO throttle live.
• Marketplace V5.3 live: 3% fee burn (1.5% seller + 1.5% buyer), USDC settlement.
• FounderVesting V2 with three independent paths live.
• Self-service agent onboarding + 24 skill files published.

Phase 5 — Testnet usage & bake (current)

• Real testnet usage and stress-tests with agent integrators.
• Marketplace liquidity bootstrap.
• Adaptive burn matrix observability dashboards.

Phase 6 — Pre-mainnet hardening

• Tier-1 external audit.
• Multisig replaces single-signer admin (Gnosis Safe, 2-of-3 to start).
• Cold-storage custody for any rotatable oracle key.
• Bug bounty live at T+30d.

Phase 7 — Mainnet launch

• Deploy contracts to Base (chainId 8453).
• Activate L2 sequencer uptime check with the real Chainlink feed address.
• Cross-chain expansion to additional L2s.
• New shield products (depeg of major LSTs, Curve pool failure, oracle staleness, custom builder shields).

15. Risks & Disclaimer

14.1 Smart contract risk

The protocol is unaudited by a Tier-1 firm at the time of writing. Internal audits are public but not a substitute. A reentrancy, storage-collision, or oracle-manipulation bug in the BondVault or shield path could result in loss of all collateral.

14.2 Oracle risk

Triggers depend on signed EIP-712 proofs from an off-chain signer. If the signer's key is compromised, every active policy can be falsely triggered, draining the BondVault. Mitigations are roadmap items (HSM, multisig signer).

14.3 Liquidity risk

Bond redemption pays out in $LUMINA at the current TWAP price. If LUMINA's secondary market liquidity is thin at the moment of redemption, holders may receive less USD-equivalent than the bond's nominal face value.

14.4 Regulatory risk

Parametric on-chain insurance is novel. It may be classified as a security, a derivative, or a regulated insurance product in some jurisdictions. The protocol's use is at the user's own legal risk.

14.5 Disclaimer

This whitepaper describes the protocol as deployed on 2026-05-14 to Base Sepolia (V5.3). It is not an offer to sell or a solicitation to buy any token, security, or insurance product. It is provided for technical and educational purposes. Forward-looking statements in Section 14 are aspirational; nothing in this document is a guarantee of future deployment, merger of features, or financial return.

16. Legal Framework

15.1 Protocol structure

Lumina Protocol is open-source software published under the MIT license at github.com/org-lumina. The contracts are deployed and operated by the founder team during testnet; on mainnet, governance and parameter authority migrate to a multisig and ultimately to on-chain governance.

15.2 Product nature

ClaimBonds are parametric payout instruments, not insurance contracts in the regulated sense. There is no claims adjuster, no underwriter, no policyholder agreement. A trigger is a deterministic on-chain event; a payout is a deterministic on-chain transfer.

15.3 Token nature

$LUMINA is a utility token with three programmatic uses: (i) it is the asset paid out by ClaimBond redemptions; (ii) the protocol's burn engine permanently destroys it as premiums and marketplace fees flow through; (iii) it is the unit of account for the BondVault's solvency. It is not designed or marketed as an investment; any speculative trading is outside the protocol's intent.

15.4 Jurisdiction

The protocol does not target users in any specific jurisdiction. Operators, integrators, and end users are responsible for their own regulatory compliance.

Appendix A — Deployed Addresses (Base Sepolia, chainId 84532)

V5.3 keeps the V5.2 core addresses (no redeploy of BondVault, PolicyManager, etc.) and adds six new shield adapters. The canonical source is always https://lumina-api-production-ac85.up.railway.app/health; if any address in this document drifts from /health, treat /health as authoritative.

Core protocol (V5.2 addresses, vigentes)

AdaptiveFeeDistributor split: 85% Burn / 8% Buyback / 2% Operations / 5% Maintenance.

Flash shield adapters (V5.3, deployed 2026-05-14)

API + relayer

Appendix B — Glossary

Appendix C — References

All technical claims in this whitepaper trace to one of these sources:

• Contract source: github.com/org-lumina/LUMINA-PROTOCOL/tree/main/src
• Tokenomics canonical: docs/TOKENOMICS.md
• Architecture overview: SECURITY.md
• Aave V3 integration: docs/architecture/AAVE-INTEGRATION.md
• Oracle V2 deep dive: docs/architecture/ORACLE-V2.md
• API endpoint reference: lumina-api README
• 24 skill files: lumina-api/docs/skills
• Live deploy state: /health
• Block explorer: sepolia.basescan.org