Protocol specification
HNST Protocol Whitepaper
A Solana-native earn protocol for passive liquidity providers and active yield seekers, designed around transparent rate formation, explicit leverage risk, and safety controls.
Abstract
HNST Protocol proposes a two-sided yield marketplace on Solana. Passive lenders deposit supported assets into Earn Vaults. Active yield seekers borrow against collateral to enter Leveraged Vault strategies. Borrow demand determines utilization, utilization contributes to borrow and supply rates, and protocol safety controls monitor health factor, oracle freshness, negative APY periods, and liquidation thresholds.
The protocol is structured around two complementary markets: Earn Vaults for passive liquidity and Leveraged Vaults for users who actively manage risk in pursuit of higher returns. The system exposes the relationship between supplied liquidity, borrowed capital, utilization, fees, oracle inputs, and liquidation thresholds so yield can be evaluated before a position is opened.
1. Problem Statement
DeFi yield remains difficult for ordinary users to evaluate. Headline APRs often collapse multiple variables into one number: borrow demand, utilization, token rewards, strategy risk, liquidation risk, oracle risk, smart contract risk, and liquidity availability. Users can see the result but not the moving parts that produce it.
HNST frames the problem directly: earn is hard, earn is complex, and the protocol exists to make capital productive without hiding risk. The design target is therefore not maximum APR at any cost. The target is legible yield: clear rate mechanics, clear participant roles, and clear failure modes.
2. Design Goals
| Goal | Specification |
|---|---|
| Passive yield access | Earn Vault users can deposit and withdraw supported assets subject to available liquidity. |
| Explicit risk selection | Users choose between low-risk lending exposure and higher-risk leveraged strategy exposure. |
| Transparent rate formation | UI and docs disclose utilization, borrow rate, supply fee, and projected supply APY. |
| Safety by default | Leveraged positions expose health factor, liquidation threshold, oracle source, and safety mode state. |
| Solana-native execution | Vault operations are designed for fast, low-cost transactions and clear wallet signing flows. |
3. Architecture Overview
HNST establishes a unified market in which lenders and yield seekers are connected inside the same protocol. Lenders deposit assets to earn passive yield. Yield seekers borrow those assets to enter strategies with leverage. The protocol coordinates custody, accounting, rate updates, strategy entry, repayment, liquidation, and risk controls.
Each component is designed to be independently auditable. Strategy adapters must be isolated so a failure in one strategy cannot silently contaminate unrelated vault accounting.
Integration Surface
The protocol is designed to connect with common Solana liquidity, staking, oracle, and routing infrastructure. These surfaces are listed as technical candidates and data dependencies, not as partner claims unless a separate integration announcement is published.
Solana
Pyth
Jupiter
JLP
INF
JitoSOL
bSOL
USDC
PYUSD
4. Participants
| Actor | Role | Primary risk |
|---|---|---|
| Lender | Deposits USDC, SOL, or other supported assets into Earn Vaults. | Utilization can delay withdrawals when vault liquidity is borrowed. |
| Yield seeker | Posts collateral and borrows liquidity to enter Leveraged Vault strategies. | Liquidation, oracle movement, strategy drawdown, and borrow-rate expansion. |
| Liquidator | Repays unhealthy debt and receives liquidation compensation. | Execution slippage and strategy exit risk. |
| Guardian / multisig | Executes emergency actions and parameter changes before governance maturity. | Operational key risk and governance capture. |
| HNST holder | Participates in incentives, parameter governance, and fee alignment as modules are activated. | Token utility and governance rights are defined by the published tokenomics schedule. |
5. Vault Mechanics
5.1 Earn Vaults
Earn Vaults are designed for passive liquidity providers. Users deposit a supported asset and receive exposure to borrower-paid interest. Deposits are designed to be simple, withdrawals are available whenever vault liquidity is sufficient, and the interface discloses when high utilization reduces immediately withdrawable funds.
| Target APR range | 10% to 30% estimated, subject to utilization and strategy demand. |
|---|---|
| User type | Passive liquidity provider. |
| Liquidation exposure | No position-level liquidation from user leverage. |
| Liquidity constraint | Withdrawals can be delayed if most vault assets are borrowed. |
5.2 Leveraged Vaults
Leveraged Vaults are designed for risk takers. The user posts collateral, borrows additional assets, and enters an approved strategy. A 3x position borrows 2x the user's collateral, making the position three times larger. HNST presents this relationship directly in the transaction preview.
| Target APR range | 30% to 500% estimated, not guaranteed. |
|---|---|
| Maximum leverage | Up to 10x, with conservative launch caps during guarded rollout. |
| Supported strategy examples | JLP-style liquidity strategy, INF-style liquid staking strategy, and approved future adapters. |
| Mandatory disclosures | Borrowed amount, borrow APY, health factor, liquidation price/threshold, safety mode state. |
6. Technical Calculations
Every leveraged position is presented as a position size, a debt value, a leverage ratio, and a projected net yield. The interface should show the math before transaction signing and refresh it when price, utilization, borrow rate, or fee inputs change.
6.1 Position Size
LP = C x LR
LR = (C + D) / C
D = LP - C
| LP | Leveraged position size, denominated in USD or the vault accounting unit. |
|---|---|
| C | User collateral posted to open or increase the position. |
| D | Borrowed debt principal before accrued interest and fees. |
| LR | Leverage ratio selected by the user and bounded by vault parameters. |
6.2 Yield Preview
Leveraged APY = Base Strategy APY x LR
Net APY = Leveraged APY - Borrow APY - Strategy Fees - Protocol Fees
24h APY = (Daily Position Yield - Daily Borrow Cost - Daily Fees) / C
Yield previews are indicative. They are computed from current inputs and can change with utilization, oracle prices, strategy returns, fee settings, or execution slippage.
6.3 PnL and ROI
PnL = Current Position Value - Debt - Accrued Interest - Fees - Initial Collateral
ROI = PnL / Initial Collateral
HNST treats realized and unrealized performance separately. Unrealized values depend on oracle prices and estimated exit execution. Realized values are recorded after strategy exit, repayment, fees, and final wallet settlement.
6.4 Worked Examples
| Scenario | Inputs | Preview result | Main risk |
|---|---|---|---|
| USDC into a JLP-style vault | 100 USDC collateral, 3x leverage, 200 USDC debt. | 300 USDC gross position before slippage, borrow cost, and fees. | JLP price movement, borrow APY expansion, and liquidation buffer compression. |
| SOL into an INF-style vault | 1 SOL collateral, 3x leverage, 2 SOL debt equivalent. | 3 SOL-equivalent gross position with health factor tracked against SOL-relative pricing. | Liquid staking depeg, oracle latency, and strategy exit liquidity. |
7. Rate Model
The protocol rate model links lender yield to borrower demand. At a minimum, the whitepaper and product UI expose the following variables:
UR = Total Debt / Total Supply
Supply Rate APY = (Borrow Rate APY x UR) - Supply Fee
Available Liquidity = Total Supply - Total Debt - Reserved Liquidity
A high utilization rate implies strong borrowing demand but creates withdrawal risk for lenders. A low utilization rate implies more available liquidity but weaker supply APY. HNST displays both the reward and the liquidity tradeoff.
7.1 Kinked Borrow Curve
Borrow APY is modeled as a utilization curve with explicit kink points. The launch configuration should publish each point per asset so users can understand how expensive leverage becomes when vault liquidity is scarce.
| U1 / U2 | Utilization kink points where the borrow curve slope changes. |
|---|---|
| R0 / R1 / R2 | Borrow APY levels at the base, first kink, and second kink. |
| Rmax | Maximum borrow APY applied near full utilization. |
| Reserve factor | Share of borrower-paid interest reserved for protocol safety, treasury, or insurance policy. |
8. Oracle and Pricing Policy
Leveraged vaults require asset prices for health factor checks, liquidation thresholds, strategy previews, and PnL estimates. HNST specifies the oracle policy as part of each vault rather than treating price data as a hidden implementation detail.
| Rule | Specification | Failure behavior |
|---|---|---|
| Primary oracle | Pyth-style pull oracle feeds are the default candidate for listed assets with sufficient coverage. | If the feed is unavailable, new leverage opens pause for the affected vault. |
| Freshness threshold | Each vault publishes a maximum price age in seconds. | Stale prices block new leverage and can block liquidations if policy requires a fresh update. |
| Confidence threshold | Each vault publishes a maximum accepted confidence interval or deviation band. | Wide confidence bands trigger conservative pricing or a vault-level pause. |
| Fallback policy | Fallback sources are pre-approved per asset and used only under documented conditions. | No undocumented fallback can be used for liquidation-sensitive calculations. |
9. Liquidation and Health Factor
A leveraged position becomes liquidatable when the health factor reaches 1.0 or lower. Health factor expresses the relationship between collateral value, liquidation threshold, debt, and accrued interest. This model is subject to audit review before production deployment.
HF = (Vault Price x Vault Amount x Liquidation Threshold) / (Debt + Accrued Interest)
Liquidation Threshold = 1 - Liquidation Spread
Liquidation Spread = Spread Rate + Liquidation Penalty Fee
| Zone | Health factor | Meaning |
|---|---|---|
| Liquidated | ≤ 1.00 | Position can be taken over and debt repaid by liquidators. |
| Danger | 1.01-1.10 | Position is close to liquidation and requires immediate risk reduction. |
| Caution | 1.10-1.50 | Position is moderately safe but sensitive to market movement. |
| Safe | ≥ 1.51 | Position has a larger buffer, though not immunity. |
10. Safety Mode and Risk Engine
Safety Mode is not a promise that funds cannot be lost. It is a policy layer for reducing risk when observable thresholds are crossed. The initial HNST risk engine includes the following controls:
| Control | Trigger | Action | Residual risk |
|---|---|---|---|
| Emergency Eject | Net APY remains negative beyond a user-selected or vault-defined duration. | Close the position or reduce exposure according to the user's safety setting. | Exit slippage, oracle delay, congestion, and adverse execution. |
| Liquidation Saver | Health factor, collateral price, or vault price crosses the configured trigger. | Repay part of the debt, add available collateral, or reduce leverage where permitted. | Fast market moves can still outrun automation. |
| Take Profit | ROI, PnL, or asset price reaches the configured target. | Close or partially close the position and repay outstanding debt. | Target execution can miss during volatility or low liquidity. |
| Exposure cap | Vault, asset, or strategy limit reached. | Block new deposits or new leveraged positions. | Limits can be miscalibrated or delayed by governance. |
11. Parameters
HNST publishes parameter names, ownership, and change processes alongside initial values. The protocol separates global parameters from local vault parameters and calibrates values per asset and per strategy.
| Parameter | Initial range | Owner before governance | Notes |
|---|---|---|---|
| Supported assets | USDC, SOL, PYUSD candidates | Guardian multisig | Final launch set requires liquidity, oracle, and audit review. |
| Maximum LTV | ≤ 90% maximum ceiling | Guardian multisig | Per asset and strategy; lower caps recommended at beta launch. |
| Minimum deposit | 10 USDC / 10 PYUSD / 0.1 SOL initial floor | Guardian multisig | Should account for Solana fees and vault accounting dust. |
| Protocol fee | 5% initial target; final value published per vault | Guardian multisig, then governance | Must be disclosed per vault and reflected in APY previews. |
| Borrow/supply fee | 0%-10% utilization-based range | Guardian multisig, then governance | Capped by governance and visible in transaction previews. |
| Liquidation penalty | Published per supported asset | Guardian multisig | Must incentivize liquidators without over-penalizing borrowers. |
| Oracle freshness | Published per vault | Guardian multisig | Maximum age for accepted price data before operations pause or require update. |
| Utilization kinks | U1, U2, R0, R1, R2, Rmax per asset | Guardian multisig, then governance | Defines how quickly borrow APY rises as liquidity becomes scarce. |
12. Token Utility, Fees, and Treasury
The HNST token contract is public. The tokenomics schedule covers total supply, circulating supply, allocation, vesting, treasury policy, fee routing, governance rights, and incentive emissions as these modules move toward production.
| Topic | Protocol position | Publication standard |
|---|---|---|
| Token utility | Governance participation, fee alignment, incentives, and access signals. | Exact rights and limitations published before activation. |
| Fee routing | Protocol fees flow to treasury-controlled addresses during guarded beta. | Wallet addresses, reporting cadence, and spending controls. |
| Emissions | Emissions are controlled by the published incentives schedule. | Emission schedule, caps, recipients, vesting, and sunset rules. |
| Governance | Progressive decentralization after audit and guarded beta. | Voting power, proposal thresholds, quorum, timelocks. |
13. Governance Model
Governance begins conservative. Early protocol changes are controlled by a disclosed multisig with public signers, timelocks where practical, and emergency procedures for pausing deposits, pausing strategy adapters, changing caps, and replacing compromised oracle feeds. Over time, HNST holders may receive governance rights if the token model explicitly grants them.
A mature governance specification must define proposal creation, voting eligibility, quorum, approval thresholds, execution delay, emergency vetoes, treasury spending, and conflict-of-interest disclosures.
14. Security and Risk Disclosures
HNST Protocol cannot eliminate DeFi risk. The production whitepaper and app must disclose at least the following categories:
- Smart contract vulnerabilities in vaults, routers, ledgers, adapters, or upgrades.
- Oracle failure, stale pricing, manipulation, or source degradation.
- Liquidity risk when high utilization prevents immediate lender withdrawals.
- Strategy risk from JLP/INF-style integrations or any future adapter.
- Liquidation risk for leveraged users, especially during volatility.
- Governance, multisig, treasury, and operational key risk.
- Solana network congestion, wallet signing mistakes, and transaction failure.
- Regulatory and tax uncertainty across jurisdictions.
Before public vault deployment, the protocol publishes audit reports, bug bounty terms, guardian addresses, treasury addresses, pause authority, upgrade authority, and incident response policy.
15. Roadmap
- Research and demand mapping Validate demand, supported assets, user risk profiles, and final token utility.
- Simulation release Publish vault calculator for utilization, supply APY, leverage, health factor, and liquidation threshold.
- Guarded beta Launch capped Earn Vaults and conservative Leveraged Vaults with Safety Mode visible by default.
- Audit and parameter hardening Complete external audits, risk committee review, and public parameter registry.
- Progressive decentralization Move selected parameters and treasury decisions from guardian control to governance.