Huma Finance V2

Protocol identification

• Name: Huma Finance V2 (often branded Huma 2.0).
• Website / app: app.huma.finance (primary interface).
• Docs: docs.huma.finance with dedicated Huma 2.0 and technical sections.
• Category: Real‑world‑asset (RWA) / PayFi yield protocol providing real yield from payment flows via permissionless liquidity pools on Solana.
• Chains (V2 focus): Huma 2.0 is launched on Solana; broader Huma is live on Polygon, Celo, Stellar, Scroll and Solana.
• Launch date (V2 / Solana): Publicly announced as “Huma 2.0 is now LIVE. Only on Solana” on April 10, 2025.
• Native / reward token: Documentation and blog describe a PST token used in PST‑USDC pools and integrated across Solana DeFi; Huma Feathers are the reward program branding.
• Main contracts / program addresses (Solana):
• Huma Solana Program (core engine for liquidity pools): address listed in docs under “Program Addresses – Huma” (Solana program for permissionless pools).
• Huma Institutional Program: separate Solana program address for institutional flows. These addresses are documented and marked as program addresses in official docs, but on‑chain verification status and exact explorer labels are Not verifiable as of 2026‑09‑04 due to lack of direct chain access. Fork lineage / code origin
• Huma Finance V2 / Huma 2.0 on Solana is described as a “complete rewrite on Solana with no shared code” relative to the deprecated V1 contracts (which were on Polygon and suffered a minor exploit).
• Available information characterizes V2 as a fresh implementation, not a fork of a named upstream protocol; no explicit upstream fork lineage (e.g., Aave, Compound) is cited in docs or reviews.
• A risk review notes “6+ security audits” for V2, implying multiple independent audits of the rewritten Solana codebase.
• I cannot confirm individual audit firm names or specific reports for the Solana program; detailed audit coverage is Not verifiable as of 2026‑09‑04 beyond the aggregate claim on the security/audits page and secondary reviews.
• No public record of malicious modifications in forks of Huma V2 has been identified; any such history across third‑party forks is Not verifiable as of 2026‑09‑04.

Huma Finance V2 appears to be a real, functional Solana app rather than a pure landing page: the docs explicitly describe a Solana program plus a decentralized app frontend, and Huma’s launch post directs users to app.huma.finance to start earning. The docs also describe live product features such as permissionless access, Classic/Maxi modes, lockups, PST/mPST outputs, and integrations with Jupiter, Meteora, Kamino, and RateX, which is consistent with an active DeFi portal rather than a static brochure. On UX/documentation maturity, the docs site is fairly developed: it has structured product pages, FAQs, smart-contract addresses, and even markdown/ask-query support for documentation navigation, which is a sign of deliberate product tooling rather than a template stub.

The docs also state that Huma 2.0 is available only on Solana and that the Solana program was audited by Halborn, which supports a more mature release posture. What is not verifiable from the gathered web data is whether deposits and withdrawals were live at this exact moment, whether any links are broken, and whether any dashboard metrics are fake; these require direct app inspection or on-chain checks that are unavailable here. Not verifiable as of 2026-09-04.

On open API: there is evidence of a developer-facing surface, but not a clearly documented public open API from the results alone. The docs expose dynamic query support for documentation pages and the APIs.io listing references a first-party JavaScript SDK and Solana permissionless SDK, but that is not enough to confirm a public open API for protocol use. Not verifiable as of 2026-09-04.

Huma Finance V2 has an active bug bounty program hosted on Cantina (Spearbit). It started on 5 Jul 2024 and the listed total reward pool is $50,000. The program covers the huma-contracts-v2 repository and uses severity-based rewards: High impact pays $50,000 at high likelihood or $25,000 at medium likelihood; Medium impact pays $25,000 at high likelihood or $10,000 at medium likelihood.

The program page shows 24 findings submitted. The official Huma V2 security page also states the bug bounty is live with Cantina and that the program is active. No independently verifiable public payout history or disclosed remediation results were found in the gathered sources.

As of September 5, 2026, no active dependency failure was identified in the reviewed sources; however, on-chain confirmation is unavailable. dependency_failure_active is therefore null. Primary counterparty risk remains concentrated in Arf and its payment-service-provider borrower network. Independent risk reviews describe Huma/Arf-related entities as the dominant originator/borrower exposure, with repayment dependent on short-duration cross-border payment flows, banking/on-off-ramp rails, borrower performance, licensing, and off-chain enforcement.

Arf-related credit is described as largely uncollateralized, creating insolvency, fraud, regulatory-loss, and recovery risk outside the Solana program. RWA/SPV exposure: the reviewed materials identify Arf Financial GmbH and an Arf Capital Ltd. SPV structure; legal enforceability and segregation of receivables are jurisdiction-dependent.

No independent trustee, audited loan tape, credit rating, or independently verified default data was evidenced. External DeFi dependencies include Jupiter/Meteora liquidity, Kamino lending/vault markets, and RateX PT/YT structuring. PST price weakness or oracle error could cause slippage, collateral liquidations, and reflexive losses across these venues even without an underlying credit default.

Oracle risk is material: Huma documents an internally operated PST price-oracle service and off-chain refresh/autotask infrastructure. Mispricing, stale NAV inputs, operator failure, or key compromise could impair redemptions and collateral markets. Stablecoin exposure is principally USDC and USDS; depeg or settlement disruption would impair liquidity and repayment.

Huma 2.0 is documented as Solana-only, and no bridge dependency was identified. No LST/restaking, CEX, market-maker, or independent custodian exposure was verified: Not verifiable as of September 5, 2026. Failure scenarios: Arf/PSP insolvency or license loss; borrower defaults; banking-rail interruption; PST oracle failure; DEX liquidity evaporation; Kamino/RateX liquidation cascades; redemption queues exceeding liquid buffers; or stablecoin depeg.

Quantified maximum exposure is not verifiable as of September 5, 2026; max_exposure_pct is null.

Huma Finance V2 on Solana appears to use a split custody model: users interact through their own wallet, while protocol operations are handled by smart contracts plus off-chain autotasks and Web2 services; Huma also states that administrative functions are controlled by multisigs and that admins can manage the protocol treasury without accessing user funds. That supports a self-custodial design at the user-wallet level, with operational custody/controls separated from user asset control. I did not find a verifiable source indicating segregated custody in the sense of legally ring-fenced client assets versus house assets, so that remains Not verifiable as of 2026-09-05.

I also did not find evidence that withdrawals are paused; the documented withdrawal flow says users can redeem when funds are not locked, subject to lockups and daily limits, which implies withdrawals are operationally active rather than paused.

Bug bounty: Huma says an active bug bounty program is live with Spearbit/Cantina. This is supported by Huma’s security/audits page and a third-party security listing that references the same program.

Huma Finance V2: Access Control via Improper Access Control on Polygon; loss $101,400 (DeFiLlama hacks registry). Remediation status: remediation_in_progress (retained evidence).

Huma Finance V2’s key management is organized around multisig control plus a timelock for protocol administration. The docs say ownership of the Protocol Contracts, Huma Config, and Pool Contracts is controlled by a timelock mechanism; timelock actions require a majority vote from a multisig wallet with at least three signers, and the timelock delay is at least 24 hours. The same page publishes the key admin addresses, including the protocol timelock and multisig, which indicates the administration setup is intended to be transparent and externally inspectable.

The security documentation further states that all administrative functions are secured with multisigs, so no single party can act alone, and that the design is meant to let admins control protocol treasury functions while preventing access to user funds. Huma also describes its custody/security stack as using advanced custody methods such as MPC and smart-contract-based custody in the broader PayFi architecture, but that is a general platform statement rather than a protocol-specific on-chain control detail for V2. In practical terms, this means Huma V2 appears to separate admin authority from user-fund custody: multisig signers approve privileged actions, the timelock delays execution, and the protocol claims compromised admin access would not permit direct withdrawal of LP/user assets.

Not verifiable as of 2026-09-04: the exact signer set, signer identities, and any operational key rotation policy are not disclosed in the provided sources.

Scope / confidence — as of 2026-09-05. Solana-specific on-chain verification was unavailable; therefore, all claims requiring account-state, instruction, event, timelock, or authority-history confirmation are Not verifiable as of 2026-09-05. Identified deployment. Public documentation lists the Huma 2.0 Solana program as HumaXepHnjaRCpjYTokxY4UtaJcmx41prQ8cxGmFC5fn; PST mint 59obFNBzyTBGowrkif5uK7ojS58vsuWz3ZCvg6tfZAGw; mPST mint HUPfpnsaJtJGpJxAPNX1vXah7BgYiQYt1c2JMgMumvPs. Solscan currently displays the program as upgradeable, with upgrade authority D6GEJYVtQGVrLVj1QSZbxWW73NnKJyHEzMBDAtCzraaF, labeled “Multisig”; it also reports the program as unverified. This is explorer evidence, not an independently reproduced on-chain check. Architecture. User wallet → Huma Solana program → pool/PDA state + USDC custody → PST/mPST mint; ancillary components include a price-oracle service and off-chain redemption/refresh autotasks.

Solana uses upgrade authority rather than an EVM proxy-admin implementation pattern. Exact proxy/buffer/governance architecture, multisig threshold, timelock, and authority history: Not verifiable as of 2026-09-05. Admin and exit risk. Huma claims multisig-protected administration and that LP funds cannot be withdrawn by compromised administrators; this remains an unverified marketing claim for the deployed program. Documented controls include configurable daily redemption caps, lockups, redemption processing, and oracle/autotask dependencies.

No-lockup positions are described as redeemable anytime, while locked positions become redeemable after expiry; secondary-market exit depends on liquidity. Exact pause, withdrawal, fee, oracle, strategy, emergency, and upgrade instruction permissions are Not verifiable as of 2026-09-05. Worst case. A compromised upgrade authority could deploy malicious program logic; a compromised operational/admin key could potentially freeze processing, alter configuration, or impair exits. Whether user funds can be directly drained, and whether users can exit trustlessly during administrator failure, is Not verifiable as of 2026-09-05.

Halborn audited a permissionless Solana program commit and reported zero critical/high findings in that engagement, but this does not prove the current deployment or unresolved status. Risk conclusion: upgradeability and centralized operational dependencies are material; rug/freeze risk cannot be ruled out without live authority and instruction-state verification.

Newly published Sec3 audit listed for Huma Permissionless Incremental, August 2026. The Sec3 index confirms the report exists and is for Solana; the exact PDF filename, detailed severity breakdown, remediation status, and bytecode/deployed-code match are not exposed by the retrieved evidence.

Corrected publication-date record: Halborn Huma Solana Programs report was published/last updated on December 29, 2025, although the engagement ended December 17, 2025. Scope covered 80 files in huma-solana-programs at commit b508edf. Findings: 0 critical, 0 high, 0 medium, 1 low, and 1 informational.

The low finding was solved; the informational finding was acknowledged. Deployed-code match is not verifiable as of 2026-09-05 because the report assesses a source commit and no on-chain bytecode check was available.

Corrected publication-date record: Halborn Solana Programs report was published/last updated on April 1, 2025, although the engagement ended March 24, 2025. Scope covered the permissionless Solana program, including commits c19bddf and PRs 207/208. Findings: 0 critical, 0 high, 0 medium, 2 low, and 2 informational.

Both low findings were solved; both informational findings were acknowledged. Deployed-code match is not verifiable as of 2026-09-05 because the report assesses source commits and no on-chain bytecode check was available.

Multiple audits of Huma Finance Solana programs (Huma 2.0 / permissionless / institutional), referenced on Huma’s Security & Audits page and Halborn’s site.

Auditor: Halborn; report: Huma Protocol Update; report_date: 2024-11-27 (engagement end); scope: Solana programs, commit PR#113; link: https://www.halborn.com/audits/huma-finance/huma---solana-program-audit-pr-113-2b46cf; deployed-code match: Not verifiable as of 2026-09-04 (Solana program; no Dune/on-chain check).

Auditor: Halborn; report: Huma - PR 124; report_date: 2025-01-02; scope: Huma Solana programs, commit 7d84086 and PRs 113/118/119/120/123/124; deployed-code match: Not verifiable as of 2026-09-04.

Auditor: Halborn; report: Solana Programs; report_date: 2025-03-24; scope: permissionless Solana program, commit c19bddf; deployed-code match: Not verifiable as of 2026-09-04.

Auditor: Halborn; report: Huma Solana Programs; report_date: 2025-12-17; scope: 80 files, commit b508edf; deployed-code match: Not verifiable as of 2026-09-04.

Audit(s) of Huma Solana programs (Huma Prime / permissionless vault) referenced in Huma’s Security & Audits page and an external disclosure.

Auditor: Sec3; report: Huma Vault; report_date: 2026-01; scope: Solana Huma Vault; deployed-code match: Not verifiable as of 2026-09-04.

Auditor: Sec3; report: Huma Permissionless Incremental; report_date: 2026-05; scope: Solana permissionless program; deployed-code match: Not verifiable as of 2026-09-04.

Auditor: Sec3; report: Huma Permissionless PR407 Incremental; report_date: 2026-06-08; scope: Solana permissionless PR407 changes; deployed-code match: Not verifiable as of 2026-09-04.

Huma Finance V2 on Solana is run by a fully public, U.S.-based founding team with prior big-tech and fintech leadership experience; no evidence of prior project hacks was found, but on-chain verification is not possible in this run (Not verifiable as of 2026-09-04). Founders & core team (public vs anon, prior track record)

• Erbil Karaman – Co-founder / CEO or Co-CEO: Public LinkedIn profile, based in the San Francisco Bay Area, previously led user growth at Facebook and Lyft and held executive roles at EarnIn, a major U.S. fintech.
• Richard Liu – Co-founder & Co-CEO/CTO: Public LinkedIn profile, ex-Google engineer for Google Fi and other 0–1 products, founder of Leap.ai (acquired by Facebook), former CTO at EarnIn.
• Additional co-founders cited across independent profiles: Ji Peng and Lei Du (co-founders with backgrounds at Microsoft, OpenDoor, EarnIn), plus Kazım Rıfat Özyılmaz and Ali Erhat Nalbant, who have prior roles in venture and RWA/payments projects (e.g., Arf).
• Non-founder leadership: Head of Business/Operations (ex-McKinsey, Stanford MBA) and regional/growth leads with visible profiles, suggesting a reasonably staffed, professional team rather than a thin shell. All key individuals are real, doxxed people with long-standing corporate résumés in the U.S. tech/fintech sector, which materially increases credibility versus anon DeFi teams. Prior projects, outcomes, and any hacks
• Track record is predominantly growth and product leadership at Facebook, Lyft, Google and executive roles at EarnIn, a large wage-access fintech.
• No independent source in the gathered set reports security incidents or hacks attributable to these founders’ prior projects; however, this is "absence of evidence" and cannot be fully verified on-chain or across all prior companies in this run (Not verifiable as of 2026-09-04). Location, office, onshore/offshore, business reality
• Multiple profiles and interviews place Huma’s leadership in the San Francisco Bay Area, with seed funding led by U.S.-based VCs Race Capital and Distributed Global, consistent with an onshore, U.S.-centric corporate setup rather than a pure offshore shell.
• Public company-profile databases list Huma Finance as a registered company with a multicomponent founding team, indicating a real corporate entity, though exact legal domicile and physical office address are not independently verified in this run (Not verifiable as of 2026-09-04). Reality check
• Strengths: Fully doxxed team; significant big-tech and fintech operating experience; backed by known VCs; media/interview footprint.
• Gaps / residual risk: No direct on-chain verification of Solana deployment or treasury structure; no independent confirmation of office address or regulatory status; reliance on off-chain reputational signals rather than hard on-chain evidence (Not verifiable as of 2026-09-04).

Huma Finance V2 on Solana currently has a strong reputational profile driven by credible investors and multiple recent audits, with no public allegations of fraud, rug, insolvency, sanctions, or regulatory enforcement as of 2026‑09‑04. Founders & team Open sources describe Huma as a PayFi / RWA lending platform focused on payment‑backed credit, but do not centralize detailed founder bios in the documents retrieved; the brand is positioned as institutional‑grade and compliant, including a Swiss‑regulated entity Arf providing settlement liquidity to licensed financial institutions. Investors & funding

• Seed round: $8.3m co‑led by Race Capital and Distributed Global, with ParaFi Capital, Circle Ventures, Robot Ventures participating.
• Later rounds / RWA+equity: $38m announced, led by Distributed Global, with Hashkey Capital, Folius Ventures, Stellar Development Foundation, TIBAS Ventures (İşbank CVC); Stellar committed $10m to the RWA component.
• Aggregator summaries list additional backing from Solana Foundation, Galaxy Digital, Coinbase Ventures, Fenbushi Capital, Hard Yaka, Santiago Roel Santos, etc., totaling around $46m+ raised, though these are secondary sources and should be treated cautiously. This investor set is broadly regarded as reputable in institutional crypto, which is a positive signal for governance and due diligence. Auditors & security posture (Solana / V2) Huma 2.0 Solana programs and institutional programs have been audited by Halborn and Sec3, with multiple incremental audit reports in 2025–2026. This indicates ongoing engagement with top‑tier auditors rather than one‑off pre‑launch reviews, which is favorable for risk perception. Sentiment & ecosystem reputation
• Launch communications and documentation frame Huma 2.0 as a “permissionless, compliant, and composable yield platform built on Solana” with integrations into leading Solana DeFi protocols such as Jupiter, Meteora, Kamino, RateX.
• Independent coverage (e.g., Coindesk and other investment memos) presents Huma as a notable RWA/PayFi player bridging regulated payment flows and DeFi, with generally positive tone focusing on growth and institutional partnerships. Criticisms, incidents, and legal/regulatory issues
• No evidence in retrieved sources of hacks, insolvency, rug‑pull accusations, sanctions listings, or regulatory enforcement actions against Huma Finance V2 or its Solana program as of 2026‑09‑04. Not verifiable as of 2026‑09‑04 for on‑chain incident data.
• No prominent public controversies or critical investigative reports surfaced in major crypto media within the last year. Unresolved concerns / analytical caveats
• Protocol‑side claims of “compliant” and “real yield” are unverified marketing claims unless supported by independent regulatory filings or legal opinions.
• RWAs and payment‑backed credit intrinsically carry counterparty, legal, and data‑quality risks that are not fully assessable from marketing and high‑level audits alone; granular loan‑book performance, default statistics, and legal structuring for Solana pools are Not verifiable as of 2026‑09‑04 based on the data retrieved. Overall, institutional reputation appears positive but still emerging, with strong investors and auditor coverage, and no visible major red flags in public information as of this date.

Strategy/assets: Solana permissionless pool. Users deposit USDC and receive PST (Classic) or mPST (Maxi). Classic targets stable yield plus HUMA rewards; Maxi pays 0% base APY for higher Feathers/HUMA incentives.

Underlying capital is primarily PayFi financing: settlement, card-payment and trade-finance liquidity, generally 1–5-day borrowing. Huma states a long-term target of 85% PayFi assets / 15% market-neutral liquid assets. Yield profile: The economic yield is intended to be borrower-paid financing fees, not directional crypto beta; HUMA/Feathers are subsidized/token-based incentives. Launch guidance cited 10.5% USDC APY; current documentation shows 9% Classic APY, adjusted monthly, while Maxi is 0%.

A complete APY history, realized volatility, and sustainability series is Not verifiable as of September 5, 2026. Organic-yield percentage is therefore unknown. Leverage/external exposure: Base Huma positions are not inherently leveraged or restaked. PST is composable on Jupiter/Meteora, Kamino and RateX; users can borrow against PST, create PT/YT structures, or loop externally.

Huma Prime is a separate defensive-looping vault. Current protocol-wide leverage and external exposure are Not verifiable as of September 5, 2026. Liquidity/terms: No lockup, 3-month, or 6-month options. Locked positions cannot redeem early through Huma; DEX sale is possible but forfeits lockup rewards.

Unlocked redemptions are first-come, generally within 1 business day and up to 7 days, subject to a daily global cap. Minimum deposit is 1 USDC; pool caps are dynamic. Switching modes currently has no protocol fee beyond gas. Revenue/TVL: DeFiLlama reports $279.94m TVL: Solana $192.14m (68.6%), Ethereum $85.08m (30.4%), Stellar $2.73m (1.0%); 30-day fees $1.69m and reported protocol revenue $0.

TVL rose 29.2% over 30 days. Dune/on-chain verification and product-level TVL are Not verifiable as of September 5, 2026. CONTRADICTION: User scope says Solana-only, but DeFiLlama currently attributes Huma Finance V2 to three chains; Solana remains the majority exposure.

As of September 5, 2026: Assessment — reserves/treasury:

• Liquid reserves (USD): Not verifiable as of September 5, 2026.
• Liabilities (USD): Not verifiable as of September 5, 2026.
• Treasury size and composition: Huma’s tokenomics allocate 11.1% of the 10 billion HUMA maximum supply—1.11 billion HUMA—to the “Protocol Treasury,” intended for development, grants, partnerships, and protocol-owned liquidity. This is an allocation policy, not evidence of current treasury holdings or liquid reserves. The same disclosure says only 1% of the treasury allocation unlocked at TGE, with the remainder released through eight quarterly tranches.
• Addresses: Huma publishes Solana program and mint addresses, including Huma program HumaXepHnjaRCpjYTokxY4UtaJcmx41prQ8cxGmFC5fn, Huma Institutional program EVQ4s1b6N1vmWFDv8PRNc77kufBP8HcrSNWXQAhRsJq9, PST mint 59obFNBzyTBGowrkif5uK7ojS58vsuWz3ZCvg6tfZAGw, and mPST mint HUPfpnsaJtJGpJxAPNX1vXah7BgYiQYt1c2JMgMumvPs. These are not identified as dedicated treasury wallets.
• Custody/control: Huma states administrative functions use multisigs. Its documentation says protocol administration can control treasury assets but is designed not to access user funds. For the institutional product, a separate “Protocol Owner Treasury” is described as holding protocol fees. The multisig addresses, signer set, threshold, and current balances were not independently verified.
• On-chain balances via Dune: Dune MCP was unavailable in this run; therefore balances, token composition, custody, and liabilities are Not verifiable as of September 5, 2026. No Dune query ID or execution ID is available.
• Attestations/reserve policy: No independent reserve attestation or liabilities report was located; Not verifiable as of September 5, 2026. Contradiction / scope note: DeFiLlama currently reports $192.09m TVL on Solana and $279.9m across Solana, Ethereum, and Stellar, but this is aggregator TVL—not treasury reserves—and conflicts with the supplied Solana-only scope.

Huma Finance does have a native token: HUMA. It is the utility and governance token of the Huma PayFi ecosystem and exists on Solana (token queried: HUMA1821qVDKta3u2ovmfDQeW2fSQouSKE8fkF44wvGw) and other chains. Token identity (Solana focus)

• Name / ticker: Huma Finance / HUMA.
• Solana contract address: HUMA1821qVDKta3u2ovmfDQeW2fSQouSKE8fkF44wvGw (Raydium/DEX Screener and Phantom).
• Network in your scope: Solana; note that some references describe HUMA as multi‑chain or Ethereum‑native, but Phantom explicitly lists it as a Solana asset. Supply, market cap, FDV Figures differ slightly across aggregators; all are off‑chain estimates (on‑chain not verifiable as of 2026‑09‑04).
• Max / total supply: 10,000,000,000 HUMA (fixed cap).
• Circulating supply: ranges ~1.73B–3.54B HUMA depending on source and date; Phantom and tokenomics.com both show ~1.73B as of mid‑/late‑2026.
• Market cap: about $36–38M based on ~1.7B circulating and ~$0.021–0.022 price.
• FDV: around $200–220M at current price levels. Utility and governance role
• Governance: HUMA holders can vote on protocol parameters, fee structures, new product launches, and treasury allocations.
• Utility: used across the PayFi network for incentives, staking, and ecosystem alignment for users, LPs, partners, and builders.
• Staking & liquidity incentives: HUMA is used for staking and to reward liquidity provision (including CEX and on‑chain pools). Revenue share, buybacks, burns
• According to Binance Academy, 50% of borrower fees are used to buy back and burn HUMA, linking protocol revenue to token value via a deflationary mechanism. Emissions & unlock schedule
• Initial supply at TGE (May 2025): about 1.73B HUMA (17.3% of total) in circulation.
• Emission horizon: ~10 years total; Year 1 releases ~29.9% of supply, the rest over the following 9 years.
• Unlock tracking: specific vesting and unlock events are listed on tokenomics/vesting dashboards, but whether each scheduled unlock executed on‑chain is Not verifiable as of 2026‑09‑04. Allocations (high‑level)
• Tokenomics.com describes allocation across Foundation, Community, Public Sale, Team/Investors/Treasury with 17.3% unlocked at TGE and the rest vested over 10 years, but exact % per bucket are not fully visible in the snippet. Treat this as aggregator data, not on‑chain‑verified. Holder concentration / insider wallets
• No independent holder‑distribution data or labeled insider wallets for the Solana token were found; Not verifiable as of 2026‑09‑04. Control functions (mint/blacklist/fee‑switch)
• Off‑chain sources state a fixed capped supply of 10B, implying no further minting beyond that cap.
• No reliable documentation of blacklist functionality, fee‑switch controls, or specific admin key arrangements for the Solana contract; Not verifiable as of 2026‑09‑04. DEX liquidity & listings (Solana)
• Raydium pool on Solana shows:
• Price around $0.00059 in an earlier snapshot, with ~$142K liquidity and market cap/FDV near $5.9M for that pool context.
• Solflare reports very low liquidity and marks HUMA as *unverified* in Solana’s token registry, with no consolidated DEX liquidity figure. Given conflicting and time‑varying aggregator data, all quantitative metrics above are off‑chain estimates; detailed on‑chain Solana tokenomics (actual circulating, holder concentration, unlock execution) are Not verifiable as of 2026‑09‑04 under your constraints.

For Huma Finance V2 on Solana, a Bitcoin drop below $10,000 would most likely be a severe negative crypto-beta shock, but the protocol’s exact loss transmission path is Not verifiable as of 2026-09-04 because I could not confirm the Solana market design, collateral mix, reserve assets, or liquidation rules from the available sources. What is verifiable from the web is limited: Huma markets itself as a real-yield / real-payment-flows protocol, and it says each transactional credit is repaid in 1 to 7 days and backed by funds already deposited into safeguarding accounts. If that description is accurate, direct exposure to BTC price should be lower than for a BTC-collateralized lending protocol, but that remains an inference and is not independently verified here.

Under a BTC crash scenario, the main risks to watch would be:

• Liquidity stress: users may de-risk from all crypto assets, reducing deposits and secondary-market demand.
• Counterparty/funding stress: if Huma relies on crypto-native liquidity providers or token incentives, those sources may weaken in a broad market selloff.
• Token price pressure: any HUMA token could still fall sharply with the sector, even if protocol revenues are less BTC-linked.
• TVL and borrow-demand compression: if users withdraw capital or reduce activity, fee generation and utilization may fall. I cannot verify a specific Solana TVL share, BTC linkage, or stress-loss estimate from the provided sources. The available third-party material is mostly price commentary and non-technical summaries rather than protocol-level risk data. A more defensible stress statement is: BTC <$10k would be a high-severity macro stress event for Huma Finance V2, but the magnitude of protocol loss cannot be quantified from the current evidence. If you want, I can next produce a chain-specific risk memo template for Huma V2 on Solana with clearly marked “verifiable” vs “not verifiable” fields.

Not verifiable as of 2026-09-04. The available sources for Huma Finance V2 do not provide an on-chain or documented collateral composition for Solana that would let me calculate the impact of a 20% depeg of the largest collateral. The protocol documentation and third-party risk notes instead describe Huma V2 primarily as a real-yield / credit product with first-loss cover, junior/senior tranche loss absorption, and redemptions that may be capped or queued, but they do not specify a collateral basket, largest-collateral weight, or a depeg stress test result for that scenario.

What can be said from the sources is limited: if losses occur, first-loss cover is used first, then junior tranche capital, and senior tranche investors are affected only after those buffers are exhausted. Hindenrank also notes that Huma V2 uses first-loss cover layers and that losses beyond those caps can propagate to junior and then senior LPs. However, those descriptions are about credit/default loss allocation, not a measurable largest-collateral depeg on Solana.

Because no verifiable collateral breakdown was provided, the stress outcome for this specific shock remains unavailable.

For Huma Finance V2 on Solana, if the largest borrower/counterparty becomes insolvent, the primary impact path is through under‑collateralized positions and the junior/first‑loss capital, not directly on the protocol contracts themselves. Current specifics are Not verifiable as of 2026‑09‑04. ### 1. Expected loss path

• In a typical Huma pool, credit losses first hit the junior/first‑loss tranche, then the senior liquidity providers, subject to pool‑specific waterfall rules.
• If the top counterparty fully defaults (no repayment, collateral insufficient), the loan’s principal and accrued interest are written down in the pool accounting; senior LPs take losses only after junior capital is exhausted.
• On Solana, this would be reflected as a drop in pool asset value / share price, not an immediate smart‑contract failure. Exact Solana V2 mechanics are Not verifiable as of 2026‑09‑04. ### 2. Who absorbs the loss
• First‑loss / junior capital providers (often sponsors or specialized investors) are structurally set up to absorb initial credit losses in Huma’s designs.
• Once their tranche is wiped, senior liquidity providers in that specific pool bear remaining losses via reduced NAV and future yield.
• The broader Huma protocol (token holders, other pools) are economically insulated; contagion is mostly within the affected pool, unless there are cross‑guarantees or shared reserves (Not verifiable as of 2026‑09‑04). ### 3. Compensation mechanisms
• Huma emphasizes risk‑tranching and underwriting, not protocol‑wide insurance. Any compensation is via:
• Higher expected yields for junior investors ex‑ante (risk premium).
• Potential off‑chain recovery actions by originators/underwriters (legal claims, collateral liquidation), then reflected on‑chain as repayments.
• No evidence of a protocol‑level insurance fund for Solana V2: Not verifiable as of 2026‑09‑04. ### 4. Impact path through smart contracts
• Smart contracts should:
• Update loan status to default, halt new draws, and stop interest accrual.
• Adjust pool accounting / share price to realize the loss for each tranche.
• Enforce any remaining collateral liquidation flows and distribution of recovered funds per waterfall.
• Governance or parameter changes (e.g., tightening risk limits, pausing new lending) would occur via admin or DAO control contracts, but the core loss recognition is mechanical within the pool contract. Because Solana V2 contracts, addresses, and exact loss waterfall logic are not available via current search, all implementation‑level details are Not verifiable as of 2026‑09‑04.

Fraud by the DAO or owners is not verifiable as of 2026-09-04. The available evidence does not show a confirmed DAO/owner fraud event for Huma Finance V2 on Solana; instead, the documented security incident in the search results concerns a legacy V1 smart-contract exploit that the project said did not affect the current V2 system. Huma’s documentation claims administrative powers are constrained by multisigs and that user funds remain protected even if an admin multisig is compromised, which reduces—but does not eliminate—owner-risk concerns; however, this is a protocol self-claim and not independent proof against fraud. For a stress scenario, the highest plausible governance/owner-risk is a malicious or compromised admin multisig or a governance action that misroutes funds.

The public audit results show several admin/ownership-related issues were found historically, including incomplete new-owner validation in ownership transfer and a pool-creation treasury validation issue, with some findings acknowledged or accepted rather than fully eliminated. That means the protocol has had recognized control-plane weaknesses, but the search results do not establish an actual fraud by DAO members or owners. Bottom line: treat this as Not verifiable as of 2026-09-04; the evidence supports a *governance/admin compromise risk* rather than a proven fraud case.

For Huma Finance V2 on Solana, a stress scenario with the primary yield source at -30% over 30 days means the protocol’s core payment-financing cash flows would be deeply negative relative to expectation, so any borrower-fee- or receivables-backed yield leg would likely be unable to support positive LP returns during that window. Huma’s own documentation says its yield comes from payment financing activity and that its defensive looping design can deleverage when borrowing costs exceed asset yield, which is the relevant failure mode in a negative-yield stress case. The key risk implication is that the primary yield source is not guaranteed to stay positive under stress; Huma explicitly describes a deleveraging fail-safe when the cost of debt threatens to exceed yield, and its P&L framework for tranches depends on the realized return from the underlying pool.

If the 30-day primary yield is negative, the likely outcomes are: reduced or zero distributable yield, rapid deleveraging if the product structure includes borrowing against the yield leg, and possible principal impairment if losses exceed reserve or tranche protections. A 30-day negative yield shock is also consistent with third-party risk descriptions that Huma’s returns depend on continued origination volume, borrower performance, and settlement rails; if those weaken simultaneously, the yield engine can compress or turn negative. However, the exact magnitude of losses, reserve coverage, and chain-specific exposure on Solana are Not verifiable as of 2026-09-04 from the available sources.

Assessment — as of September 13, 2026. Huma Finance V2 on Solana has no verifiable live token-holder governance controlling upgrades or protocol parameters. Huma’s own roadmap says on-chain governance tools are planned by November 26, 2026, so the DAO is currently symbolic/unimplemented rather than a proven control layer. Control surface: The V2 architecture includes Solana programs, a Huma-controlled dApp frontend, Web2 rewards/account services, a price-oracle service, and off-chain autotasks. Development is publicly associated with the 00labs GitHub organization, which maintains Huma repositories and a governance UI, but this does not establish decentralized control. Funds/admin powers: Huma documentation claims administrative functions use multisigs and that treasury control is separated from user assets.

Institutional documentation describes a protocol-owner multisig that can change configuration, manage pausers/pool owners, unpause, and transfer protocol income to treasury; pausers can halt fund movement. These are protocol claims, and their applicability to the exact V2 Solana deployment was not independently verified. > Contradiction / verification gap: Marketing and documentation claim multisig protection and no access to user funds, but Dune MCP was unavailable in this run; therefore authorities, signer independence, thresholds, treasury balances, and actual drain paths cannot be confirmed on-chain. Governance process: No verifiable current proposal, voting, delegation, quorum, execution, or timelock process. Not verifiable as of September 13, 2026. Voting concentration and top holders via Dune: Not verifiable as of September 13, 2026. Company control is indicated by the privacy policy naming Huma Technologies Inc.; jurisdiction, registration number, directors, and operative Terms of Use were not reliably verified.

As of September 4, 2026, Huma Finance V2 is presented as a permissionless Solana product operated by Huma Technologies Inc. Huma’s privacy policy states that it is headquartered in the United States and lists a Cupertino, California mailing address; the exact state of incorporation is Not verifiable as of September 4, 2026. A third-party registry mirror reports Delaware incorporation, but this was not independently confirmed from an official state record. Terms/restrictions and KYC/AML. Huma 2.0 is marketed as permissionless: no professional-investor status or KYC/KYB is required.

Participation is nevertheless restricted for sanctioned/restricted regions and wallets flagged by Chainalysis. The separate Huma Institutional product requires KYC/KYB and, where applicable, investor accreditation. Publicly accessible Huma 2.0 terms, restricted-jurisdiction schedule, and a standalone AML policy were not located: Not verifiable as of September 4, 2026. Classification. Huma expressly warns that its FAQ does not fully describe the legal structure or operations of the issuer of PST/mPST and directs users to a PayFi Strategy Memorandum.

PST/mPST are yield-bearing LP/strategy tokens linked to payment-financing activity; their treatment could raise securities, collective-investment, lending/credit, money-transmission, or other financial-regulatory questions depending on jurisdiction. No regulator classification or exemption specific to Huma/PST was located: Not verifiable as of September 4, 2026. Warnings/enforcement/court/sanctions. Huma’s own materials identify regulatory, credit/default, liquidity, smart-contract, and lockup risks.

No public regulator enforcement action, court case, or sanctions designation against Huma Technologies Inc. or Huma Finance was identified in the searches performed; an exhaustive negative determination is Not verifiable as of September 4, 2026. Data protection / actual risk. The privacy policy (effective February 22, 2023) covers contact, financial, wallet, device and usage data; permits sharing with affiliates, service providers, evaluation agents, authorities and blockchain-visible recipients; and allows international transfers. Legal structure risk remains material: the issuer/entity and off-chain oracle, autotask, frontend and account-management components remain centralized points of legal and operational exposure despite on-chain execution.

No exact GLEIF LEI record for 'Huma Technologies Inc', 'Huma Finance V2'. OFAC SDN screening of 'Huma Technologies Inc', 'Huma Finance V2': no match. SEC litigation and administrative release feeds: no mention.

Huma Finance V2 on Solana uses USDC as the deposited stablecoin, and there is no verifiable evidence in the available sources that the protocol issues its own stablecoin. No stablecoin depeg event could be confirmed from the available sources, so the depeg count, last depeg date, and max depeg percentage are not verifiable as of 2026-09-05. The protocol is therefore treated as stable only in the limited sense that no depeg was confirmed, not as a positive chain-verified conclusion.

Huma Finance V2’s main risks are concentrated in the underlying PayFi credit book, redemption liquidity, Solana program and administrative controls, and variable yield/receipt-token behavior. Audits and documented controls reduce—but do not eliminate—loss risk; on-chain verification of current balances, concentration, authorities, and live liquidity was unavailable in this run, so those items are not independently confirmed.

Huma Finance V2’s top strengths are: (1) a PayFi-specialized design for payment financing, including credit lines and receivable-backed credit lines; (2) a modular structured-finance architecture that supports different calendars, fee structures, and tranche structures; (3) built-in dynamic risk management via DSP and external adapters, which is positioned as a foundation for adaptive underwriting; (4) a permissionless Solana deployment in Huma 2.0 with no KYC/KYB requirement for LP access, plus flexible lockups and reward modes; and (5) Solana ecosystem composability, since PST can integrate with Jupiter, Meteora, Kamino, and RateX for added yield or liquidity. These are the clearest protocol strengths surfaced by the most relevant sources, while claims such as “zero credit losses” are protocol-marketing claims and not independently verified here.