Whiteheart (WHITE)

Whiteheart: Ethereum Hedge Contracts Built Around WHITE Staking

Whiteheart was designed to turn downside protection for ETH and WBTC into on-chain hedge contracts. Its architecture combines pooled USDC collateral, oracle-based pricing, tokenized protected assets, and a WHITE staking mechanism, but the available evidence also points to limited recent activity and unresolved questions around control and ongoing maintenance.

What Whiteheart is designed to do

Whiteheart is an Ethereum-based hedging protocol built on the Hegic options framework. Its central product is a hedge contract intended to protect the dollar value of an underlying crypto asset for a defined period. The original design focused on ETH and WBTC through two instruments called WHETH and WHWBTC. These combine exposure to the underlying asset with an at-the-money put-style protection mechanism, so the holder can receive a USDC-denominated payment if the protected asset declines during the contract period.

The intended users are therefore different from ordinary spot holders and from liquidity providers in a conventional automated market maker. A hedge buyer pays for defined downside protection, while liquidity providers supply USDC collateral and take the economic risk that protected assets fall. The model is closer to selling insurance or options than to passive lending: providers may earn fees when protection is not heavily exercised, but they must be able to absorb claims when market prices move against them.

How the hedge mechanism works

In the original implementation, a user acquired a protected asset by paying the underlying asset plus the hedge cost. The protocol converted the payment into USDC and allocated collateral through dedicated hedging pools. The resulting WHETH or WHWBTC position could be represented as a transferable token, allowing the protected exposure to be used in other DeFi applications in principle. Protection periods described in the launch documentation ranged from 14 to 28 days, with the settlement amount calculated against the asset’s price and the contract’s strike conditions.

Pricing and settlement depend on external data. Whiteheart’s launch material identifies Chainlink price feeds as an input for estimating asset prices and calculating protection costs. That creates a practical dependency on oracle availability, feed behavior, asset coverage, and the protocol’s handling of stale or abnormal prices. USDC is also central to the design because it serves as the collateral and settlement denomination rather than merely being an optional payment asset.

The role of WHITE and sWHITE

WHITE is not the protected asset and is not the collateral backing WHETH or WHWBTC. The documented role of WHITE is primarily connected to staking. Users stake WHITE to receive sWHITE, and the launch design allocated 30% of protocol hedge fees to sWHITE holders. The same documentation states that sWHITE holders were intended to receive fee distributions without taking the direct hedge-loss exposure of the WHETH and WHWBTC liquidity pools.

This utility should be read as a description of the original economic design, not as proof of current fee generation or continuing distributions. The public material reviewed for this article is largely from the 2021 launch period, and it presents projected fee examples rather than independently verified results. The token’s practical value therefore depends on whether hedge contracts remain active, fees are actually generated, staking contracts remain usable, and distributions continue under the deployed contracts.

Control, administration, and code history

The available audit record does not establish a fully documented token-governed upgrade system. PeckShield identified an owner account in the reviewed USDC pool that could set the lockup period and whitelist supported hedge-asset addresses. The finding was marked fixed in the reviewed code version, but that does not by itself prove that all privileged roles were removed, transferred to a DAO, or retained under a timelock. Users evaluating the protocol should distinguish between a fixed audit finding and evidence of current governance control.

The open-source front end points to a separate whiteheart-v1 repository for compiling and deploying contracts, while the audit identifies Solidity contracts deployed for Ethereum. That provides a code trail, but the evidence reviewed here does not show a maintained governance forum, a current upgrade policy, or a recent public release process. The status of administrator keys, emergency controls, and any replacement contracts remains a material research question rather than a settled project fact.

Security record and operational dependencies

Whiteheart received a PeckShield review dated March 3, 2021. The report listed two medium-severity findings, four low-severity findings, and two informational findings in the reviewed version, including concerns involving privileged administration, slippage control, staking withdrawals, and token-transfer compatibility. The report records the listed findings as fixed or addressed in the reviewed code process, but an audit is limited to the specified code and scope; it is not a guarantee that deployed contracts, later changes, integrations, or economic assumptions are safe.

Whiteheart also inherits dependencies from Ethereum transaction execution, USDC liquidity, price oracles, and the Hegic-derived contract model. A current third-party protocol snapshot reviewed for this article showed Whiteheart operating on Ethereum with a small amount of tracked protocol liquidity relative to its token valuation. That observation is not a complete measure of usage, but it suggests that available collateral and active hedging demand should be checked directly before treating the system as a liquid insurance market.

What remains uncertain

Whiteheart’s concept is easy to describe but harder to assess from public evidence because the clearest technical and economic documents are historical. The launch material explains the intended products, fee routing, and oracle design, while the available current snapshot offers limited evidence about active hedge issuance, claims, liquidity-provider participation, or ongoing development. The main unanswered questions are whether the original contracts remain the primary system, whether newer deployments exist, how current administrators are controlled, and whether WHITE staking still produces the described fee flow.

Key takeaways

• Whiteheart was designed as an on-chain downside-protection system for ETH and WBTC, using hedge contracts backed by USDC collateral.
• WHETH and WHWBTC were intended to combine underlying-asset exposure with a time-limited put-style hedge.
• WHITE’s documented role is staking for sWHITE and receiving a share of protocol fees, not serving as hedge collateral.
• The system depends on Ethereum, USDC liquidity, Chainlink price feeds, and contracts derived from Hegic’s architecture.
• The 2021 security review recorded several findings and marked them fixed in the reviewed version, but it does not validate later deployments or current administration.
• Recent public evidence is insufficient to establish sustained protocol usage, active fee distributions, or a clearly documented token-governed upgrade process.

Risks and open questions

• Oracle failure, stale pricing, or an unexpected price-feed condition could affect hedge pricing or settlement.
• Insufficient USDC collateral or thin active liquidity could limit the protocol’s ability to meet protection claims.
• The current status of administrator keys, emergency controls, and upgrade authority is not clearly documented in the sources reviewed.
• The original fee-sharing design may not reflect current contract behavior or current protocol activity.
• The 2021 audit is historical and does not cover every later deployment, integration, economic risk, or operational change.
• A small amount of tracked protocol liquidity raises questions about current hedge demand and liquidity-provider participation, although third-party tracking may be incomplete.