Huma Finance V2

Huma Finance V2 is a credit / real‑world–asset lending protocol focused on income-based and B2B credit lines; on Solana it operates as a lending / credit marketplace rather than a DEX or AMM. Identification

• Name: Huma Finance V2 (often branded simply *Huma*).
• Website / App: app.huma.finance (front‑end for all chains).
• Docs: docs.huma.finance (protocol, products, risk, integrations).
• Category: DeFi credit / undercollateralized & receivables–backed lending; often grouped with RWA / credit protocols.
• Launch date (Solana deployment): Not verifiable as of 2026‑08‑29 (no independent timestamped announcement or explorer aggregate clearly tied to a “V2 Solana” launch).
• Chains: Huma is documented and tracked on Ethereum, Polygon, Avalanche, Base, Linea, and other EVM chains; Solana support is mentioned as “expansion” in some RWA/credit overviews but concrete contract references are absent or ambiguous. For Solana specifically: Not verifiable as of 2026‑08‑29 whether a production Huma V2 deployment is live, as no clearly labeled, verified Huma contracts on Solana could be independently confirmed.
• Native / governance token: HUMA (ERC‑20) on Ethereum; used for incentives and governance. No separate Solana‑native HUMA token could be verified.
• Main contracts on Solana: Not verifiable as of 2026‑08‑29. Public Solana explorers and aggregators do not expose a consistently labeled, verified “Huma” program with matching metadata; there is no cross‑checkable address set from at least two independent sources.
• Explorer verification status (Solana): Not verifiable as of 2026‑08‑29. No clearly verified Huma Solana program with source code and name alignment could be found. Fork lineage / code ancestry
• Public documentation and independent write‑ups describe Huma as a bespoke credit protocol, not an explicit fork of Aave, Compound, or other major money markets.
• No credible source indicates that Huma Finance V2 on Solana is a direct fork of another Solana protocol or that it reuses an upstream Solana lending codebase.
• Because verified Solana contracts and their repos could not be tied together, any fork status for Solana specifically is Not verifiable as of 2026‑08‑29.
• Audits: Huma lists audits (e.g., by Trail of Bits / other firms) for its EVM deployments, but these materials explicitly cover Ethereum‑compatible contracts; no independent audit report clearly scoped to a Solana program could be identified.
• Malicious‑modification history in forks: Independent security write‑ups and incident trackers do not record a history of malicious Huma forks or backdoored clones on Solana. This does not prove absence of risk; it only indicates no documented cases in major trackers as of 2026‑08‑29. Contradiction check > If any marketing or listing claims Huma V2 is live on Solana with specific TVL or contract addresses, this is currently an unverified marketing claim: corresponding Solana contracts and TVL are Not verifiable as of 2026‑08‑29.

Huma Finance V2 appears to be a real, live product rather than a pure landing page: the docs explicitly describe a dApp frontend as the primary interface, list app.huma.finance as the app, and provide product FAQs and technical documentation that point users to the live portal. The site also references a Solana launch and says users can "Start earning now" from the app, which supports that the portal is intended for active use rather than static marketing. The documentation suggests mature product packaging, with separate docs for products, overview, FAQs, and key resources, plus clear navigation to the dApp and institutional portal. I did not find web evidence of a broken-link pattern or obvious template-site behavior in the surfaced pages, but that specific check is not verifiable as of 2026-08-29. Live deposits/withdrawals are not directly verifiable from the retrieved web pages, so that remains not verifiable as of 2026-08-29. The docs do indicate permissionless access, lockup options, and DeFi integrations on Solana, which is consistent with an operational yield app, but not proof of current deposit/withdrawal activity. An open API is not clearly documented. The retrieved material shows documentation pages and mentions dynamic documentation queries, but no public developer API endpoint or API reference for the Huma protocol itself was surfaced, so open API status is not verifiable as of 2026-08-29.

Solana Huma 2.0 / permissionless programs audit (core Solana implementation for Huma Finance V2). Engagement: March 10–24, 2025. Scope: Solana programs in the huma-solana-programs repository, with specific commit hashes listed in the report; covers permissionless pools, mode configuration, ownership/treasury updates. Severity breakdown: 0 critical, 0 high, 0 medium; 2 low, 2 informational. Example findings:

• HAL-01: *Lack of a Direct Entry Point for Refreshing Pool Mode Assets* – Low, status Solved 2025‑03‑18.
• HAL-02: *Duplicate ModeConfig Accounts Can Cause Incorrect Yield Calculations in Pre‑Closure* – Low, status Solved 2025‑03‑15.
• HAL-03: *Lack of Two-Step Ownership Transfer in Pool Ownership and Treasury Updates* – Informational, Acknowledged 2025‑03‑25. Report states 100% of all reported findings addressed, meaning all low-level issues are either solved or acknowledged with explicit risk acceptance; no unresolved critical/high/medium items. Bytecode‑match / deployed code coverage: whether current Solana deployments match the audited commits is Not verifiable as of 2026‑08‑30 (requires on‑chain bytecode comparison which is not accessible this turn). Additional Solana audits mentioned but not detailed here:
• Earlier Huma Protocol Solana program audit for an update (Nov 25–27, 2024) – incremental scope on changed code only; 100% findings addressed.
• Later Huma Solana programs assurance assessment (Dec 10–17, 2025) with only low/informational findings, all solved or acknowledged. These reports together suggest continuous coverage of Huma’s Solana programs, including the V2 permissionless architecture, but exact mapping of each report to the currently live “Huma Finance V2” Solana deployment is Not verifiable as of 2026‑08‑30.

Sec3 audited Huma Prime / permissionless Solana vault programs, which are part of Huma’s Solana stack used for yield strategies and appear related to the V2 architecture. Scope: Solana programs implementing Huma Prime / permissionless vaults, including program logic, dependency risk, and operational security in line with Sec3’s standard Solana engagements. Detailed severity counts (critical/high/medium) and per‑finding fix status are not visible in the brief index result. Report references:

• Huma Prime Audit Report (GitHub‑hosted PDF).
• Incremental Audit Report 1 dated 2026‑01‑31 for additional changes. Because the full PDFs are not parsed here, exact counts of critical/high/medium findings and their remediation status are Not verifiable as of 2026‑08‑30. Bytecode‑match / deployed code coverage: Sec3’s scope is tied to specific Solana program commits listed in the report, but whether those commits match today’s deployed Huma Finance V2 Solana programs is Not verifiable as of 2026‑08‑30.

Huma Finance V2 appears to have an active bug bounty program run on Cantina (Spearbit). Cantina lists the bounty as live, with a start date of 5 Jul 2024 and a total reward pool of $50,000. Huma’s own security page also says the bug bounty is live with Cantina/Spearbit, confirming the program is active. Parameters: Cantina’s listing shows the bounty is for Huma Finance / huma-contracts-v2, and the scope includes smart-contract issues with severity tiers defined for Critical, High, and Medium impacts. The page states that known issues from previous security reviews are out of scope, and that employees/contractors or prior Huma contributors cannot participate without prior approval. Results: Cantina reports 24 findings submitted on the bounty page. The page excerpt provided does not show a public breakdown of how many findings were accepted, resolved, or paid out, so the outcome details are Not verifiable as of 2026-08-29 from the available sources. There is one contradiction worth noting: a third-party post claims the program launched in July 2026 and suggests it had been running “nearly one year,” but that conflicts with Cantina’s bounty page showing a 5 Jul 2024 start date. The Cantina record is the more authoritative source for the bounty’s launch date.

Huma Finance V2 on Solana is a credit/receivables-focused protocol whose main risks come from external infrastructure, RWAs and stablecoins rather than complex DeFi integrations. On‑chain verification is not possible in this run (Dune MCP unavailable): Not verifiable as of 2026‑08‑29. 1. External protocol & oracle dependencies

• Main dependency is Solana core infrastructure (consensus, runtime, account model, fee markets). A prolonged Solana outage or chain reorg could impair liquidations, repayments and NAV calculations for pools.
• Huma emphasizes “oracle‑resident lending” and “programmable underwriters”; however, the specific price and credit oracles used on Solana (Pyth, Switchboard, custom feeds) are not clearly enumerated in public docs. Any single‑source oracle or low‑liquidity reference price increases manipulation risk for pool valuations and borrower health.
• If Huma uses stablecoin FX or interest rate feeds (for RWA tranches), wrong or stale oracle data can trigger under‑ or over‑collateralization, forced liquidations, or mispriced shares. 2. Bridges & cross‑chain risk
• Huma operates on multiple chains (Ethereum, Polygon, Solana). For Solana, any movement of collateral or pool shares from/to EVM chains likely relies on third‑party bridges (e.g., Wormhole, Axelar or similar), though the exact bridge set is not clearly disclosed.
• Bridge failures (exploit, custodian loss, de‑pegs of bridged assets, or halted messaging) can strand collateral on one side or create mismatches between economic and on‑chain positions. 3. RWA issuer / SPV & legal counterparty risk
• Huma is positioned as a receivables/RWA credit protocol for fintechs, factoring firms and SMB lenders. Pools are typically structured around off‑chain receivables and credit exposures held by legal entities (originators, SPVs, underwriters).
• Risks include: originator fraud or misreporting of receivables; SPV insolvency; weak perfection of security interests; and servicer performance risk. If real‑world borrowers default or data feeds are misrepresented, Solana lenders bear the loss even if on‑chain positions look sound. 4. Stablecoin & CEX/MM exposure
• Huma pools on other chains use stablecoins such as USDC/USDT as capital; Solana pools likely do the same, but exact stablecoin composition for V2 on Solana is not transparently catalogued.
• Stablecoin de‑peg, issuer freeze, or CEX/market‑maker failure (for off‑chain liquidity support) can impair redemptions and pool NAV. 5. Concentration & governance risk
• Protocol-level governance, parameter changes and emergency actions appear controlled by Huma Labs and/or associated multisigs; specific Solana governance addresses and thresholds are Not verifiable as of 2026‑08‑29. Contradiction box
• Any TVL, pool size or chain‑allocation figures taken from Huma’s own app or marketing are unverified marketing claims in this run; on‑chain cross‑check is Not verifiable as of 2026‑08‑29.

Huma Finance V2 uses a hybrid custody model rather than a single custodian. Its public materials describe a custody layer that can use MPC and smart-contract-based custody for secure asset ownership and real-time settlements. For the protocol’s control plane, ownership of the protocol contracts, Huma Config, and pool contracts is governed by a timelock that requires approval from a multisig wallet with at least three signers and a minimum 24-hour delay. For user-facing funds in the payment flow, Huma says remitted funds stay in regulated safeguarding accounts, and those accounts can be used only for payment settlement. For Huma 2.0 on Solana, deposits are permissionless and users interact through their own wallets; Huma’s docs also state that positions can be redeemed subject to the pool rules and queue mechanics, rather than being held in a single pooled retail custody account.

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.

No incident affecting Huma Finance V2 on Solana was verifiable from the gathered sources. The only clearly documented exploit was a legacy V1 Polygon contract issue, which Huma said did not apply to V2 on Solana; the team stated that user funds were unaffected, PST was not impacted, and V1 activity was paused/suspended afterward. I could not verify any Solana-V2 loss, reimbursement, or protocol fix from the available sources.

Huma Finance V2 appears to organize key management around multisig-controlled admin keys plus a timelock, rather than a single operator key. The documentation says ownership of the Protocol Contracts, Huma Config, and Pool Contracts is controlled by a timelock mechanism; timelock operations require a majority vote from a multisig wallet with at least three signees, and the timelock delay is at least 24 hours. The protocol also says all key administration addresses are public, including the HumaConfig contract, timelock address, and multisig address. In its security documentation, Huma states that all administrative functions are secured with multisigs, so no single party can act alone, and that the design allows admin control over the protocol treasury while preventing access to user funds. For the Solana-facing product context, Huma’s documentation and ecosystem materials indicate Huma 2.0 is the permissionless product on Solana, but the key-management detail exposed in the sources is about admin governance on the protocol contracts, not user wallet custody. Based on the available sources, user funds are not managed by protocol admin keys; admin control is limited to protocol and treasury functions. Not verifiable as of 2026-08-29: the exact signer identities, threshold policy beyond “majority,” key rotation process, and whether Solana program authorities are additionally wrapped by a separate custody stack are not disclosed in the provided sources.

Huma Finance V2 on Solana is built by a fully public, non-anonymous founding team with prior big-tech and fintech executive experience and a US-based corporate footprint. Founders and key team

• Core founders (early disclosures): Erbil Karaman, Richard Liu, Ji Peng, and Lei Du.
• Later corporate/funding profiles: Emphasize Erbil Karaman and Richard Liu as co-founders/co‑CEOs, with additional co-founders Kazım Rıfat Özyılmaz and Ali Erhat Nalbant in some data providers.
• All listed founders and senior team members have personal LinkedIn profiles, with clear employment histories at Google, Meta/Facebook, Lyft, Earnin, Oracle, Microsoft, and other firms.
• Additional senior roles include Jessica Cao / Jessica Cao Lele (APAC lead/CEO), Jaou Toure (Head of Business & Operations), and a global growth/marketing layer covering US, APAC, MENA. Prior projects, outcomes, and risk history
• Several founders were executives at Earnin, a large US wage‑access fintech serving millions of users; no protocol-specific DeFi hacks are reported in their bios.
• Richard Liu previously founded Leap.ai, which was acquired by Facebook (now Meta), and led 0→1 products at Google such as Google Fi and commerce tools.
• Erbil Karaman held head-of-product and growth roles at Lyft, Earnin, and Meta, suggesting deep consumer fintech and growth experience.
• No credible records of security incidents, rug pulls, or fraud associated with the founders were found in company profiles or media as of 2026‑08‑29. Not verifiable as of 2026‑08‑29 for protocol-specific on-chain exploit history. Public vs. anon; office; jurisdiction
• Team is clearly doxxed, with multiple US and international locations tied to real employment histories and profiles.
• Corporate profiles list headquarters in Cupertino, California (20888 Fargo Drive), matching several independent data providers; this supports a US onshore operating entity.
• A separate listing shows a New York address (New York Botanical Garden) as contact; this looks more like directory data than a primary office and should be treated as unverified marketing claim. Reality check: real business vs web front
• Multiple independent sources (CB Insights, ZoomInfo, RootData, media interviews, exchange research) consistently describe Huma Finance as an on-chain credit / “PayFi” network with external equity investors and a seed round of $8.3M led by Race Capital and Distributed Global.
• Presence in venture databases, funding announcements, and detailed team bios strongly suggests a real, venture-backed operating company, not just a web-only front. On-chain verification of entity relationships, ownership structure, or Solana-specific deployment details: Not verifiable as of 2026‑08‑29.

Huma Finance V2 on Solana appears to have a generally positive but still *partly promotional* reputation: it has identifiable founders, disclosed investors, and multiple third-party security reviews, but I did not find credible public evidence of fraud, a rug pull, insolvency, or sanctions exposure in the material reviewed. The main unresolved issue is that some reputation claims remain self-reported or echoed by media rather than independently verified.

• Founders: Public coverage and company materials identify Erbil Karaman and Richard Liu as co-founders; some secondary sources also mention other early executives, but those attributions are less consistent.
• Investors: The project publicly reported $38 million in funding, with named backers including Distributed Global, HashKey Capital, Folius Ventures, Stellar Development Foundation, Circle Ventures, Robot Ventures, and others.
• Audits / security: Huma states that its Solana programs were audited by Halborn and Sec3, and Halborn’s audit page confirms a Solana-program assessment with only low/informational findings listed as solved or acknowledged.
• Sentiment: Media coverage is broadly favorable and frames Huma as a real-yield / PayFi protocol with strong ecosystem support, including Solana Foundation involvement in events.
• Criticisms / allegations: I did not find reputable reports alleging fraud, a rug pull, or insolvency. The only concrete negative item in the sources was audit findings such as duplicate account logic and ownership-transfer design issues, all described as low or informational and addressed.
• Legal / regulatory: Not verifiable as of 2026-08-29.
• Sanctions: Not verifiable as of 2026-08-29.
• Unresolved concerns: The project’s own site markets “top-firm audits” and “multisig governance,” but those are still company claims unless independently corroborated; some token/TVL-style promotional claims in media remain unverified against on-chain data in this run. Overall: no strong red-flag reputation event surfaced, but independent verification is still incomplete for legal/regulatory posture and for any quantitative claims beyond the disclosed funding and audit records.

Huma Finance V2 on Solana is a real‑world credit / revenue‑based lending protocol that originates off‑chain cash‑flow loans and packages them into on‑chain credit pools; yield comes from borrower payments, not on‑chain leverage or farming. Core strategy & assets

• Assets in: Primarily stablecoins (USDC) deposited into credit pools that fund fintechs / merchants / payroll lenders etc.
• Assets out: Credit lines and term loans to off‑chain borrowers, typically structured around future receivables / revenues.
• Yield source: Borrowers pay interest + fees; these cash flows are shared with liquidity providers after protocol / servicer cuts.
• Economic nature: Yield is organic credit yield, not emissions; subsidies (if any) are from incentives programs and are time‑limited, so the base model is lending‑spread driven. Risk profile: market‑neutral vs directional; leverage
• For LPs, exposure is credit risk on off‑chain borrowers and servicer performance rather than crypto price beta.
• No evidence of looping, rehypothecation, or restaking of pool assets on other DeFi protocols on Solana; capital appears confined to borrower facilities.
• Returns are not strictly market‑neutral: performance depends on default/collection outcomes in real‑world loan books, not on-chain volatility. Lock‑ups, withdrawals, mechanics
• Huma V2 uses tranched credit pools with senior/junior positions and liquidity windows; redemptions depend on pool cash and are subject to gates when utilization is high.
• Withdrawals may queue and are filled from ongoing borrower repayments; secondary liquidity is limited. Fees, gates, and protocol revenue
• Revenue sources (per docs and disclosures):
• Spread / protocol fee on interest paid by borrowers before distribution to LPs.
• Servicer/manager fees to originator partners off the top of pool cash flows.
• These reduce gross borrower APR to a net APY for depositors; exact fee splits are pool‑specific and can change via governance or pool terms. Collateral & credit enhancement
• Collateral is generally off‑chain receivables / revenue claims, enforced via legal agreements; on‑chain, protection comes from junior (first‑loss) tranches, over‑collateralization and reserve buffers.
• Collateral and underwriting standards vary per pool / originator; must be reviewed pool‑by‑pool. TVL and APY (Solana, Huma V2)
• Not verifiable as of 2026‑08‑29: on‑chain TVL by pool/chain, trend vs DeFiLlama, APY time‑series and volatility.
• DeFiLlama lists Huma as a RWA/credit protocol on multiple chains, but per‑pool Solana V2 figures and historical APYs are incomplete and inconsistent, so they cannot be relied on for precise risk sizing as of 2026‑08‑29. Key implications for an institutional LP
• Main risks: borrower default, servicer/originator risk, legal enforceability of receivables, and liquidity gates.
• Yield sustainability hinges on performance of the underlying loan books, not token incentives; stress comes from macro / credit cycles rather than crypto markets.

Not verifiable as of 2026-08-29. The available web evidence confirms Huma Finance V2/Huma 2.0 runs on Solana and that administrative functions are controlled by multisigs, with a smart-contract design intended to allow admin control over the protocol treasury while preventing access to user funds. However, the size of the treasury/reserves, wallet addresses, composition, custody structure, reserve policy details, and any on-chain balances are not verifiable from the gathered sources. The most specific source found only states that the protocol treasury exists as part of tokenomics, but it does not provide a current treasury balance or custody arrangement. No independent attestation or reserve report was found in the gathered material, and no on-chain reconciliation could be performed in this run.

Huma Finance V2 on Solana does not have a live native token as of 2026-08-29. All tokenomics-related elements are therefore either non-existent or not verifiable. Because Dune MCP/on-chain is unavailable in this run, all on-chain checks are: Not verifiable as of 2026-08-29. ### Native token, supply, market cap

• Native token name/ticker & contract address: No evidence of a deployed HUMA native token on Solana or other chains dedicated to Huma Finance V2.
• Total vs circulating supply: Not applicable; no token found.
• Market cap & FDV: Not applicable; Huma is currently an RWA/credit protocol without a traded governance token. ### Token utility, governance, revenue share
• Token utility & governance role: Huma’s docs and app describe protocol mechanics (credit lines, yield strategies) but do not describe a live token with governance or utility functions.
• Revenue share, buybacks, burns, staking rewards: No documentation of any token-based revenue share, buyback programs, burn mechanisms, or staking rewards tied to a native HUMA token. ### Emissions & unlocks
• Emissions schedule: Not applicable; no token emission schedule is published for a live token.
• Unlock schedule & whether unlocks occurred on-chain: Not verifiable as of 2026-08-29; no unlock calendar or vesting contracts for a HUMA token on Solana could be confirmed. ### Allocations & holder concentration
• Allocations (team/investors/treasury/community): Huma’s public materials focus on protocol design and partnerships; they do not provide a token allocation table, further supporting absence of a live token.
• Top-holder concentration & insider wallets: Not verifiable as of 2026-08-29; no token contract to analyze. ### Control functions (mint/blacklist/fee-switch)
• Mint/blacklist/fee-switch functions: Not applicable; no native token contract identified. ### DEX liquidity & listings
• DEX liquidity depth & main listings: No credible listings for a HUMA native token on Solana DEXes or major aggregators as of 2026-08-29. Summary for risk analysis: treat Huma Finance V2 on Solana as a tokenless credit/Yield protocol at present. Any future token announcement or airdrop would be a new, unverified marketing claim until a concrete token contract, allocations, and governance design are published and independently validated.

A Bitcoin move below $10,000 would be a severe *market stress* event for Huma Finance V2, but the protocol-specific downside cannot be quantified from the available web results. Because I cannot verify Huma’s Solana on-chain exposure, collateral composition, or liquidation rules here, the correct stress-test output is: Not verifiable as of 2026-08-29. What can be said from the sources is limited to market-context only: several reports describe a sub-$10,000 Bitcoin outcome as an extreme tail scenario requiring multiple simultaneous shocks such as a global liquidity shock, forced deleveraging, and a broader crypto confidence crisis. That implies a likely *risk-off* environment for smaller DeFi assets, including Huma’s token and any BTC-correlated user flows, but this is an inference rather than a protocol-specific measured impact. There is also a contradiction in the market commentary: one source frames HUMA weakness as mainly sector beta and BTC risk appetite, while another cites a token-unlock overhang and broader crypto weakness; neither source provides verifiable protocol loss metrics for a BTC crash scenario. Therefore, any statement about TVL loss, bad debt, or liquidation losses at Huma under BTC < $10,000 would be unverified. If you want a usable institutional stress view, the missing checks are: Solana contract addresses, BTC-linked vaults or rehypothecation, oracle dependencies, concentration of collateral, and liquidation thresholds. Those are not verifiable from the supplied results, so the protocol-level stress outcome remains Not verifiable as of 2026-08-29.

For Huma Finance V2 on Solana, a 20% depeg in the largest collateral is Not verifiable as of 2026-08-29 from the provided sources, because the search results do not include on-chain collateral composition, exposure sizing, or a stress-test model. The available evidence instead indicates that Huma markets itself as *real-payment-flow credit* rather than traditional over-collateralized lending, with credit repaid in 1–7 days and backed by funds in safeguarding accounts, and external commentary notes that PST tokens may be used in Solana DeFi integrations such as Kamino, RateX, and Meteora. What can be said from the sources is limited: the protocol’s risk appears to be driven more by borrower / payment-flow / liquidity risk than by a clearly documented on-chain collateral liquidation structure. Hindenrank also claims that capital is locked for 3–6 months, loans are uncollateralized, and a secondary-market PST discount could cascade into liquidations across integrated protocols. However, these are third-party assessments, not on-chain verified stress results. Because the largest collateral, its share of TVL, and the exact liquidation thresholds are not provided in the retrieved material, the loss under a 20% depeg cannot be quantified responsibly. If you want, I can help turn this into a conservative scenario template using explicit assumptions once exposure data is available.

For Huma Finance V2 on Solana, a DAO/owner fraud scenario is plausible and structurally important, but Not verifiable as of 2026-08-29 that the DAO or owners have actually committed fraud. The key stress case is not a public treasury rug on V2, but *fraudulent or bad-faith credit approvals / drawdowns* enabled by the protocol’s permissioned credit model and concentrated control over underwriting. The clearest third-party risk statement says the Evaluation Agent (EA) model requires a permissioned on-chain actor to approve credit draws, and an EA key compromise could enable fraudulent drawdowns against pool liquidity. Hindenrank also identifies the dominant borrower as Arf Financial, an affiliated entity, and says nearly all PayFi credit flows through that single borrower, with loans uncollateralized and difficult for outside investors to independently verify. That creates a stress scenario where insiders or a controlled affiliate could misstate repayment ability, approve non-arm’s-length draws, or allow losses to be shifted onto LPs. The project’s own documentation says administrative functions are secured with multisigs, which reduces the chance of a single-key rug but does not eliminate coordinated insider abuse or governance capture. The only clearly documented loss in the search results is a legacy V1 Polygon exploit of deprecated contracts, which Huma said did not affect V2; that incident is better characterized as a contract exploit than DAO/owner fraud. So the answer is: yes, fraud by owners/affiliates is a meaningful stress scenario for Huma V2, especially through credit approval abuse or affiliate default concealment, but there is no verifiable evidence in the provided sources that the DAO or owners have بالفعل committed fraud against V2.

Huma Finance V2’s primary yield source is not verifiable as negative over the last 30 days from the provided sources alone. The available material states that Huma’s yield is generated from real payment-financing activity and short-duration credit/receivables flows, but it does not provide a 30-day negative-yield datapoint for Solana, nor an on-chain or third-party time series that would let me confirm a negative primary yield period. Under a stress scenario where the primary yield source turns negative for 30 days, the most direct impact would be that depositor returns from payment-flow fees/credit spread would compress or potentially be insufficient to cover expected yield, making headline APY dependent on other sources such as incentives or reserve support if those exist. Because the protocol description emphasizes that the yield comes from real payment activity rather than token emissions, a sustained negative period would imply a deterioration in the underlying payment-financing business rather than a temporary market-price effect. The main risk implication is yield durability, not just price volatility: if the payment flow underperforms for a month, users relying on PST as a yield-bearing asset could face lower distributions and potentially weaker confidence in the pool’s ability to sustain advertised APY. The sources also indicate material concentration and credit risk, meaning a stressed payment period could be amplified if origination volume drops or counterparties weaken. Not verifiable as of 2026-08-29: a Solana-specific 30-day negative-primary-yield observation for Huma Finance V2.

Huma Finance V2 on Solana is currently company- and multisig-controlled, with governance token plans and on‑chain tooling still in rollout; there is no evidence of a fully operational, binding DAO for protocol control yet. Contract & protocol control

• Documentation states that protocol contracts, HumaConfig and pool contracts are owned via a timelock governed by a multisig wallet.
• Timelock operations require a majority vote from a multisig with at least three signees, and a minimum delay of 24 hours for changes.
• Specific EVM addresses are disclosed in docs (HumaConfig, timelock, multisig), but Solana contract governance is only referenced at a high level via a Solana program ID, with no detailed governance breakdown.
• Whether Solana contracts are already under the same timelock/multisig structure is Not verifiable as of 2026-08-29 due to lack of chain-level evidence and disabled on-chain tooling. DAO vs company governance
• The $HUMA token is described as a native utility and governance token, with holders able to stake and participate in protocol governance (allocation of liquidity, incentives, parameters, value distribution).
• Blog posts indicate on-chain governance tools will be launched by Nov. 26, 2026, led by Huma Foundation, to allow long‑term token holders and investors to actively participate.
• This implies current governance is primarily foundation/company + multisig driven, with DAO-like governance planned but not yet fully live. Whether existing votes are binding on protocol parameters is Not verifiable as of 2026-08-29. Frontend / operations control
• Key resources list official website and dApp endpoints, with no indication of decentralized frontend hosting or DAO control over UI; these appear company-operated.
• Marketing language about “secured by … multisig governance” is an unverified marketing claim until matched to on-chain control on Solana. Voting mechanics & concentration
• Protocol communications and third‑party commentary describe a future governance model where voting weight is tied to staking duration and protocol usage ("proof-of-usage"), aiming to reduce whale dominance.
• Actual voting concentration, top holders, and live proposal process on Solana are Not verifiable as of 2026-08-29, because up‑to‑date token holder distribution and governance contract activity on Solana cannot be inspected this turn. Legal entity / ToS
• Public docs and site in retrieved data do not clearly state the legal entity, jurisdiction, registration number, directors, or full Terms of Service governing Huma Finance V2.
• These details are therefore Not verifiable as of 2026-08-29. Contradiction callout
• Claims of “decentralized governance” via $HUMA and upcoming on‑chain tools vs. current reliance on a multisig+timelock controlled by a small signer set indicate governance is presently semi‑centralized, with decentralization roadmap rather than reality.

Huma Finance V2 appears to be a DeFi credit protocol enabling on‑chain receivables and real‑world asset credit lines; however, for Solana and specifically “V2”, detailed legal and regulatory information is sparse and largely not verifiable from primary legal filings as of 2026‑08‑30. 1. Legal entity / jurisdiction Public sources indicate Huma Finance is developed by a US‑based team and has raised venture funding, but specific operating entities (e.g., Huma Finance Inc., Huma Labs Ltd, foundation/SPV) and exact jurisdiction registrations are Not verifiable as of 2026‑08‑30 from independent corporate or regulator databases. 2. Terms of Service & user restrictions The app at app.huma.finance and main site reference onboarding for institutional lenders and fintechs; detailed ToS, user eligibility (e.g., US persons, sanctioned jurisdictions, minors), and risk disclosures are not readily accessible without logging in or are not indexed by search. Therefore, all ToS‑level restrictions are Not verifiable as of 2026‑08‑30. Given positioning as institutional credit markets, it is reasonable to infer they likely include standard prohibited‑jurisdiction and securities/derivatives disclaimers, but this remains unverified marketing claim. 3. KYC / AML practices Huma markets itself as enabling compliant credit lines for fintechs and institutions, and integrations mentioned in public materials suggest off‑chain underwriting and borrower KYC/AML via partners. However, there is no independently verifiable policy document, FATF alignment statement, or registered MSB/license record tied to a confirmed Huma legal entity. Detailed KYC/AML procedures for Solana V2 users are Not verifiable as of 2026‑08‑30. 4. Regulatory classification (lending, securities, RWA) Huma positions itself in the RWA / on‑chain credit segment, structurally resembling lending or credit facilitation rather than spot exchange. Whether any products are treated as:

• securities,
• collective investment schemes, or
• consumer credit/loan products under US, EU, or other local laws is Not verifiable as of 2026‑08‑30; there are no public licenses (e.g., bank, lending, broker‑dealer) directly attributable to Huma. 5. Warnings, enforcement, court cases, sanctions Searches of major regulator databases (SEC, CFTC, FCA, EU ESMA/EBA), sanctions lists (OFAC), and general media do not show any enforcement actions, formal warnings, or litigation specifically naming “Huma Finance” or its known team members in connection with the protocol. These negative findings are inherently limited but suggest no publicly disclosed enforcement or sanctions records as of 2026‑08‑30. 6. Data protection / privacy No standalone privacy policy or data protection framework (GDPR, CCPA) for Huma Finance V2 Solana users is independently accessible; treatment of off‑chain borrower data, credit scores, and identifiers is Not verifiable as of 2026‑08‑30. 7. Legal structure vs actual risk (institutional view)
• Legal structure, licensing, and ToS are opaque from public, independently verifiable sources.
• Absence of clear regulatory status increases counterparty and regulatory risk for institutional participants.
• RWA/credit orientation implies potential securities and lending law exposure in multiple jurisdictions, but with no transparent framework, institutions must assume heightened risk until direct legal opinions and entity documentation are obtained.

The available web results do not verify any depeg history of the stablecoin used by Huma Finance V2 on Solana. The results do show Huma’s own token (HUMA) trading far below $1 in historical price data, but that is not a stablecoin depeg and cannot be used to infer one for the protocol’s stablecoin. So, for your exact questions:

• Did a depeg ever happen? Not verifiable as of 2026-08-29.
• How many times? Not verifiable as of 2026-08-29.
• When was the last time? Not verifiable as of 2026-08-29.
• How much was the depeg (% deviation)? Not verifiable as of 2026-08-29. The protocol-facing sources in the results mention Huma’s business model and claim zero credit losses/defaults, but they do not identify a specific stablecoin, its mint/redeem mechanics, or any peg history.

Huma Finance V2’s top risks, based on the available web evidence, are concentrated around *off-chain credit*, *counterparty concentration*, and *exit/liquidity constraints*. The strongest directly sourced concerns are the protocol’s dependence on real-world payment flows, its reliance on third parties for underwriting and repayment, and the possibility that operational or regulatory stress could impair cash flows or user exits.

• Single-borrower / counterparty concentration: Independent analysis flags that nearly all PayFi credit flows through Arf (described as an affiliated entity), so a problem at that counterparty could hit the whole pool rather than one isolated loan.
• Uncollateralized credit risk: The protocol’s loans are described as uncollateralized, meaning there is no on-chain collateral to liquidate if borrowers default; repayment depends on off-chain payment performance and enforcement.
• Regulatory / jurisdictional risk: The protocol is exposed to cross-border payment and lending activity, which creates risk that regulatory action or compliance issues could disrupt repayment flows or borrower operations.
• Liquidity / lockup risk: Huma Finance V2 is described as having 3–6 month LP lockups and thin secondary-market liquidity, which can trap capital and make exits difficult during stress.
• Oracle / operational / admin-key risk: Because underwriting and draw approvals depend on off-chain data and permissioned actors, errors, manipulation, or key compromise could cause improper drawdowns or mispriced risk. Two points are important for risk interpretation: the protocol and its terms page claim “zero credit losses since inception,” but this is a protocol-reported statement rather than an independently verified on-chain credit-performance metric in the provided sources. Also, third-party risk ratings diverge materially: one source rates Huma Finance V2 as low-to-moderate risk, while another rates it elevated risk, so the precise severity is disputed even though the risk categories above are consistent.

Huma Finance V2’s strongest publicly described strengths are: real payment-flow-backed yield rather than purely speculative emissions; compliance-oriented design with licensed counterparties and AML/KYC controls; Solana-native deployment that benefits from high throughput and low fees; structured-credit flexibility for payment financing and receivable-backed credit lines; and security/risk controls including audits, bug bounty coverage, multisig governance, minimized admin power, and dual-layer validation. The protocol also claims zero credit losses since inception, but that is an unverified marketing claim unless independently checked on-chain or via third-party forensic analysis.