Kraken DeFi Earn users can now access a Sentora-curated USDC vault with Firelight cover built in. A protected vault gives users onchain yield with a defined answer to protocol and smart contract risk. It brings together three layers, each run by a different party: a curator that sets the strategy, vault infrastructure that runs it, and a coverage layer that absorbs protocol risk. A platform then provides access to its users. This piece explains how those layers fit, using Kraken Protected Strategies USDC as the example.

Why cover matters

Institutional platforms increasingly bring clients onchain through vaults. A vault packages strategy, execution and risk policy into a single product, one that a platform can list, report on and explain to its own compliance team.

Vaults built on the ERC-4626 and ERC-7540 standards now hold more than $15 billion in total value locked (Lagoon).

Vaults have made distribution simpler, but the underlying risk remains. A single vault can hold exposure to several protocols, oracles and bridges, and a fault in any one of them reaches every depositor. Protection has not kept pace: onchain cover across DeFi totals about $123.7 million over 27 protocols, roughly 0.14% of $88.3 billion in TVL (DefiLlama).

“It’s a step toward giving DeFi users clearer options around onchain risk, an area that’s increasingly top of mind across the space,” said Marcel Ohngemach, Product Lead, DeFi at Kraken.

How a protected vault works

The vault itself has three layers, each run by a different party.

1. The curator sets the strategy: Curators such as Sentora select the markets a vault allocates to, set allocation limits, define leverage and liquidation headroom, and decide when to rebalance. The markets a curator approves become the markets the coverage layer is asked to price.

2. Vault infrastructure runs it: Vault infrastructure providers such as Veda and Upshift supply the contracts and tooling for deposits, withdrawals, share accounting, permissioned strategy execution and protocol integrations. A curator can serve new distribution partners without rebuilding execution each time.

3. Firelight prices the strategy, its dependencies and the vault: Firelight provides the third layer. The curator enables cover on the markets the vault holds, and Firelight assesses risk at three levels: each market in the strategy, the infrastructure those markets depend on (oracles, bridges and underlying asset issuers), and the vault contracts themselves. 

Rates and capacity are published onchain in the Cover Registry and fixed for each 30-day coverage period. Each position is recorded in a Cover Token that references the full cover terms and renews at the next period's rates, so a change in the strategy mix shows up in the next period's terms.

What cover responds to

Cover responds to six failure modes, each named in advance and published onchain:

• Smart contract exploits. Logic errors, reentrancy, access control or upgrade flaws.

• Oracle failures. Stale, misconfigured, compromised or manipulated price feeds.

• Governance exploits. Flash-loan voting attacks, malicious upgrades or compromised governance contracts.

• Mechanism-driven bad debt. Liquidation or collateral mechanisms fail and leave unrecoverable bad debt.

• Mechanism-driven depegs. A pegged asset breaks from its reference because its stabilization mechanism fails.

• Redemption failures. A protocol defect blocks withdrawals or returns materially less than fair value.

For Kraken Protected Strategies USDC, Sentora and Firelight agreed a per-address cap of $100,000, enabled for this vault. Cover is also subject to the exclusions set out in Firelight's standard cover terms, including losses from user error, market price movements not caused by a covered failure, and upstream failures outside the covered scope.

From incident to depositor

When a covered incident occurs, the platform does not file a claim with Firelight. Once an exploit is confirmed, the incident is opened onchain and every active Cover Token exposed to the affected market is included automatically. The platform still runs its own incident process: opening an internal incident, keeping users informed and conducting a post-incident review.

No single party decides the outcome. ZeroShadow, Firelight's designated security partner, publishes an exploit report, and the protocol calculates a loss schedule. The Firelight Risk Consortium, an independent panel of five firms (Hypernative, Native, Credora, Cyfrin and GFX Labs), checks the event against the published criteria and validates the loss. At least three of the five members must approve through an onchain multisig, and approval triggers settlement automatically.

Settlement draws on a first-loss buffer, followed by staked capital pro rata, and the payout is released in stablecoins to the covered vault, through the beneficiary address set on each Cover Token. A distribution layer such as Merkl routes it to individual depositors.

How it all fits together

Responsibilities stay separate. The platform provides access without underwriting protocol risk, the curator manages deployment conditions without holding the capital that backs cover, and Firelight backs cover without a direct relationship with end users. That separation lets each party be assessed on the role it performs.

How a vault becomes protected

1. Select or launch a new vault. The curator enrolls an existing vault or launches a new one as protected. A new vault with no deposits can carry the same protection as an established one. 

2. Enable cover on the strategy set. The curator selects the vault's markets for cover. Rates and capacity are already published in the Cover Registry, so the cost is known before launch and fixed for each 30-day period.

3. Build the cost into the vault. The vault infrastructure provider carries the cost of cover as a fee inside the vault. Users see it in the net rate, with no separate billing flow.

4. Provide access. The platform makes the vault available within its existing earn flow, alongside the net rate and a link to Firelight's standard cover terms. Each Cover Token references the same terms, so what users read matches what is recorded onchain. Once marked for renewal, cover rolls into each new period without further setup.

Looking ahead

A protected vault lets a platform tell its users which failures are covered, how incidents are handled and how payouts reach depositors, on terms published before cover begins. Strategy, execution and cover each require different capital and expertise. We believe structures where each layer is run by a specialist will become the standard way onchain yield reaches a broader user base.

Running an earn product or curating a vault? Reach out via this form.

Firelight Coverage is not insurance. It is a protocol-based coverage mechanism enabled on the vaults platforms offer to their clients.