Risk methodology

How Honeycomb selects reserves, sets allocations, monitors risk, and operates the keeper. Written in plain language. Updated as our process evolves.

1. Reserves we will supply into

Honeycomb USDC supplies only into Kamino lending markets that meet four criteria:

  • ·Audited collateral acceptance — the reserve only accepts collateral types Kamino has reviewed and listed.
  • ·Battle-tested oracles — supported price feeds (Pyth, Switchboard, or Scope-aggregated) with documented update cadence and stale-price fallback behavior.
  • ·Healthy utilization curves — interest-rate slopes that price in liquidity stress and that we have observed across at least one cycle of utilization shocks.
  • ·No unbounded supply caps where the cap is being actively raised on a short cadence — this is a signal of capital chasing yield rather than the market normalizing.

Today, Honeycomb USDC is allocated across three USDC reserves: Prime Market, Main, and OnRe. Reserve addresses are linked from the Allocation Breakdown on the strategy page.

2. Allocation weights

Current weights are 50% Prime Market / 30% Main / 20% OnRe. The weights are written on-chain in the vault’s allocation strategy account and only the curator can change them.

Weights are reviewed against three signals:

  • ·Trailing 7-day supply APY per reserve, smoothed against single-day noise (incentive vesting, large borrower entry/exit).
  • ·Available supply-cap headroom — we will not target an allocation that would force the next invest to revert.
  • ·Utilization stability — reserves with sustained 90%+ utilization receive lower target weights because they are closer to the kink in the rate curve and small withdrawals can spike borrow rates.

Today, weight changes are reviewed and applied manually by the curator. An automated proposal-and-approval flow (curator alerts via Telegram, sign in a web admin panel) is in development; until it ships we document each manual change in the public commit log of our scripts.

3. Operational separation of authorities

Honeycomb maintains two separate signing authorities. They have different powers and different blast radii.

  • ·Curator key — controls allocation weights, performance fee, and metadata. Held in cold storage on the curator’s own wallet, not on any server. Used only when allocations are intentionally changed.
  • ·Keeper key — runs on the Honeycomb Render service and signs only the permissionless invest instruction. The keeper holds a small SOL float for transaction fees and no USDC. A full keeper compromise can only force more frequent invests, which is the keeper’s job; it cannot move funds, change weights, or claim fees.

Both addresses are public and linked from the homepage Trust section.

4. Auto-invest cadence

User deposits land in the vault’s idle bucket. Yield only begins when an invest transaction sweeps the idle balance into the allocated reserves. Honeycomb’s keeper checks the vault every 30 minutesand invests automatically when the idle balance exceeds 0.5 USDC.

The interval and threshold are configurable and are deliberately set to err on the side of frequent rather than batched invests — small idle balances earning zero are a worse outcome than a few extra cents of transaction fees.

5. What we do not do

  • ·No leverage loops — Honeycomb USDC is a pure supply position. We do not borrow against the vault to amplify yield.
  • ·No incentive farming — yield comes from underlying borrow demand, not from emissions of short-lived governance tokens.
  • ·No off-chain capital allocation — every dollar lives in a public Kamino reserve, traceable from the vault address.
  • ·No admin-pausable user funds — the program does not give the curator the ability to freeze withdrawals.

6. Failure modes we plan for

  • ·Reserve oracle stalls — Kamino reserves halt borrow operations when their oracle is past the staleness window. Our position remains intact; redeem is unaffected for supply.
  • ·Reserve at supply cap — invest into that reserve reverts; the keeper gracefully skips and logs. Capital sits in idle until the cap is raised or weights are re-curated.
  • ·Indexer lag in display — Kamino’s public metrics endpoint can lag the chain by a few minutes. The /earn page falls back to on-chain reads so the displayed TVL and price-per-share remain real-time.
  • ·Keeper outage — invest is permissionless, so anyone (including the user) can run scripts/trigger-invest.ts and earn yield without our infrastructure.

7. Audit status

The Kamino kvault and klend programs that custody Honeycomb funds have been audited by their respective firms — see the Kamino audit repository.

Honeycomb’s own infrastructure (curator scripts, keeper, web app) has not yet completed a third-party audit. We will publish audit reports here when they are available. In the meantime, the code is open and the on-chain actions are public.

8. Fees

  • ·Performance fee — 5% of earned interest, accrued continuously by the kvault program and claimable by the curator. The fee is recognized only against interest that has actually accrued; principal is never charged.
  • ·Management fee — 0%. We do not charge users a time-based fee independent of performance.
  • ·Withdrawal fee — 0%. Unrestricted withdrawals are part of the non-custodial guarantee.

9. Verifiable on-chain

This page describes our current process. As Honeycomb evolves we will revise it in place rather than retire and replace, so the document reflects what we actually do today. Material changes will be flagged in our research feed.