# Table of Contents - [Huma (2.0) | Huma](#huma-2-0-huma) - [ECOSYSTEM RESOURCES | Huma](#ecosystem-resources-huma) - [ABOUT HUMA | Huma](#about-huma-huma) - [Key Resources | Huma](#key-resources-huma) - [ANNOUNCEMENTS | Huma](#announcements-huma) - [Why Huma? | Huma](#why-huma-huma) - [PRODUCTS | Huma](#products-huma) - [What is Huma? | Huma](#what-is-huma-huma) - [Overview | Huma](#overview-huma) - [Feathers | Huma](#feathers-huma) - [Modes: Classic vs Maxi | Huma](#modes-classic-vs-maxi-huma) - [Lockup | Huma](#lockup-huma) - [Referral | Huma](#referral-huma) - [Switching Modes | Huma](#switching-modes-huma) - [Extending Lockup | Huma](#extending-lockup-huma) - [Portfolio | Huma](#portfolio-huma) - [$PST | Huma](#-pst-huma) - [Feathers | Huma](#feathers-huma) - [Data Room | Huma](#data-room-huma) - [Overview | Huma](#overview-huma) - [Introduction | Huma](#introduction-huma) - [Huma Institutional | Huma](#huma-institutional-huma) - [FAQs | Huma](#faqs-huma) - [Tranches | Huma](#tranches-huma) - [Deposit | Huma](#deposit-huma) - [Pool Types | Huma](#pool-types-huma) - [P&L Policies | Huma](#p-l-policies-huma) - [Admin Roles | Huma](#admin-roles-huma) - [Calendar | Huma](#calendar-huma) - [Redemption | Huma](#redemption-huma) - [Redemption | Huma](#redemption-huma) - [Integrations | Huma](#integrations-huma) - [Lenders | Huma](#lenders-huma) - [Borrowers | Huma](#borrowers-huma) - [User Manuals | Huma](#user-manuals-huma) - [First Loss Covers | Huma](#first-loss-covers-huma) - [Deposit | Huma](#deposit-huma) - [User Manuals | Huma](#user-manuals-huma) - [Huma Institutional | Huma](#huma-institutional-huma) - [Pool Owner And Pool Operators | Huma](#pool-owner-and-pool-operators-huma) - [Payment | Huma](#payment-huma) - [Withdrawal | Huma](#withdrawal-huma) - [Pool Admins | Huma](#pool-admins-huma) - [FAQs | Huma](#faqs-huma) - [Loan Management | Huma](#loan-management-huma) - [Security & Audits | Huma](#security-audits-huma) - [Technical Docs | Huma](#technical-docs-huma) - [Evaluation Agent | Huma](#evaluation-agent-huma) - [Legal | Huma](#legal-huma) - [Huma (2.0) | Huma](#huma-2-0-huma) - [Smart Contracts | Huma](#smart-contracts-huma) --- # Huma (2.0) | Huma [Overview](https://docs.huma.finance/products/huma-2.0/overview) [Feathers](https://docs.huma.finance/products/huma-2.0/feathers) [Modes: Classic vs Maxi](https://docs.huma.finance/products/huma-2.0/modes) [Lockup](https://docs.huma.finance/products/huma-2.0/lockup) [Referral](https://docs.huma.finance/products/huma-2.0/referral) [Redemption](https://docs.huma.finance/products/huma-2.0/redemption) [Integrations](https://docs.huma.finance/products/huma-2.0/integrations) [User Manuals](https://docs.huma.finance/products/huma-2.0/user-manuals) [FAQs](https://docs.huma.finance/products/huma-2.0/faqs) [PreviousPRODUCTS](https://docs.huma.finance/products) [NextOverview](https://docs.huma.finance/products/huma-2.0/overview) Last updated 8 months ago --- # ECOSYSTEM RESOURCES | Huma [Technical Docs](https://docs.huma.finance/ecosystem-resources/technical-docs) [Smart Contracts](https://docs.huma.finance/ecosystem-resources/smart-contracts) [Security & Audits](https://docs.huma.finance/ecosystem-resources/security-audits) [Legal](https://docs.huma.finance/ecosystem-resources/legal) [PreviousEvaluation Agent](https://docs.huma.finance/products/huma-institutional/user-manuals/pool-admins/evaluation-agent) [NextTechnical Docs](https://docs.huma.finance/ecosystem-resources/technical-docs) Last updated 8 months ago --- # ABOUT HUMA | Huma [What is Huma?](https://docs.huma.finance/about-huma/what-is-huma) [Why Huma?](https://docs.huma.finance/about-huma/why-huma) [Key Resources](https://docs.huma.finance/about-huma/key-resources) [NextWhat is Huma?](https://docs.huma.finance/about-huma/what-is-huma) Last updated 8 months ago --- # Key Resources | Huma Official Website: [huma.finance](https://huma.finance/) Huma: [app.huma.finance](https://app.huma.finance/) Huma Institutional: [institutional.huma.finance](https://institutional.huma.finance/) Docs: [docs.huma.finance](https://docs.huma.finance/) X: [x.com/humafinance](https://x.com/humafinance) Discord: https://discord.com/invite/humafinance Dune: https://dune.com/huma-finance/huma-overview [PreviousWhy Huma?](https://docs.huma.finance/about-huma/why-huma) [NextANNOUNCEMENTS](https://docs.huma.finance/announcements) Last updated 2 months ago --- # ANNOUNCEMENTS | Huma **We're excited to announce the launch of Huma 2.0**—our next leap forward in making decentralized finance truly accessible. Huma 2.0 introduces a **permissionless model** that allows **anyone** to tap into **institutional-grade PayFi yields**—opportunities that were previously reserved for professional investors. By integrating with leading DeFi protocols on **Solana**, Huma 2.0 unlocks the full power of **PayFi and DeFi combined**. **Huma 2.0** is now the flagship product of Huma Finance, branded simply as **Huma**. The existing permissioned service continues under the **Huma Institutional** brand, providing curated access for institutional partners with tailored requirements. [PreviousKey Resources](https://docs.huma.finance/about-huma/key-resources) [NextPRODUCTS](https://docs.huma.finance/products) Last updated 8 months ago --- # Why Huma? | Huma Information moves at the speed of light. Markets never sleep. Yet finance lags behind—slow, closed, fragmented. Merchants wait days for payment. Suppliers endure 60–90 day payment terms. Families lose money to remittance fees. Trillions are stuck in settlement limbo, and outdated systems like SWIFT keep global commerce crawling. Traditional banks aren't just slow—they're structurally unfair. They collect deposits from everyone, earn yield by deploying that capital into credit markets, and return almost nothing to the original depositors. The bulk of the value goes to shareholders as dividends, and what's remaining is siphoned off to cover bloated overhead, layers of bureaucracy, and executive bonuses. The system extracts far more than it gives. The infrastructure behind the global economy is broken. We need a leap forward. Every great leap has come from connecting what was once siloed—electricity, the internet, and now, finance. Stablecoins have proven that money can move instantly, without borders or friction. **PayFi** builds on that promise to create a new financial standard—faster, fairer, and always on. As the first PayFi Network, Huma is making this standard a reality. We provide the modern infrastructure that finally synchronizes money movement with modern commerce through real-time settlement. Imagine a world where merchants wake up to sales already settled. Suppliers get paid the moment goods ship. Migrant workers send money home in seconds, without middlemen or excessive fees. And savers don't just park their money—they **earn real yield** transparently, without banks skimming most of the value. **Yield is no longer reserved for the few—it's available to everyone on equal terms.** Capital flows freely. Supply chains move faster. Families keep more of what's theirs. Growth is no longer gated by inefficiency. SWIFT? Obsolete. Pre-funded accounts? Gone. Middlemen? Replaced. PayFi is accelerating this transformation. And Huma is making it happen - driven by its mission: to accelerate the movement of money for a world that's always on. [PreviousWhat is Huma?](https://docs.huma.finance/about-huma/what-is-huma) [NextKey Resources](https://docs.huma.finance/about-huma/key-resources) Last updated 8 months ago --- # PRODUCTS | Huma [Huma (2.0)](https://docs.huma.finance/products/huma-2.0) [Huma Institutional](https://docs.huma.finance/products/huma-institutional) [PreviousANNOUNCEMENTS](https://docs.huma.finance/announcements) [NextHuma (2.0)](https://docs.huma.finance/products/huma-2.0) Last updated 8 months ago --- # What is Huma? | Huma Huma is the first **PayFi network** - powering real-world payment financing with T+0 on-chain settlement. Huma connects global capital to high-quality real-world payment assets such as cross-border settlements, card payments, and payroll advances. Backed by strategic partners, including **Solana, Circle, Stellar Development Foundation (SDF), Galaxy Digital**, and others - with over **$7 billion** in on-chain transactions, Huma delivers institutional-grade credit infrastructure to DeFi, making real yield instant, transparent, and permissionless. The Huma Protocol is offered in two forms: * **Huma (Permissionless)** – Launched in **April 2025**, this version is open to all, allowing **retail investors** to participate in Huma pools and join the broader PayFi movement. * **Huma Institutional** – A **permissioned** protocol designed for **institutional investors** to access curated payment financing and RWA opportunities. This enables licensed financial institutions to scale responsibly while meeting the surging demand for flexible, compliant financial infrastructure. [PreviousABOUT HUMA](https://docs.huma.finance/) [NextWhy Huma?](https://docs.huma.finance/about-huma/why-huma) Last updated 2 months ago --- # Overview | Huma Since its launch on Solana in 2024, Huma has delivered sustainable, double-digit yields to liquidity providers (LPs) by deploying capital into various PayFi applications. These platforms generate revenue through transaction fees from businesses that leverage Huma's accelerated cross-border payment solutions, enabled by Solana's high-speed blockchain. The original product was initially tailored for institutional participants, which requires professional investor accreditation and KYB/KYC verification. [](https://docs.huma.finance/products/huma-2.0/overview#key-changes-in-huma-2.0-include) Key changes in Huma 2.0 include: ------------------------------------------------------------------------------------------------------------------------------ * **Permissionless Access** – No requirement for professional investor status or KYC/KYB. * **Classic and Maxi Modes** – LPs can choose **Classic Mode** for a balanced mix of stable yield and Huma rewards or **Maxi Mode** to maximize Huma rewards at the cost of APY. * **Flexible Lockups** – LPs can opt for **no lockup** or enhance rewards by locking capital for **3 or 6 months**. * **DeFi Integration** – PST can be integrated with top Solana DeFi protocols—**Jupiter, Meteora, Kamino, and RateX**—to access additional yield opportunities or instant liquidity. * **Huma Feathers Rewards** – The Huma rewards program has been rebranded to **Huma Feathers**, introducing a rich and dynamic system where incentives can be amplified through various multipliers and activities. [PreviousHuma (2.0)](https://docs.huma.finance/products/huma-2.0) [NextFeathers](https://docs.huma.finance/products/huma-2.0/feathers) Last updated 8 months ago --- # Feathers | Huma **Huma Feathers** are used to power our loyalty system, designed to reward community members based on their engagement with the Huma Protocol. Inspired by the mythical Huma bird, a symbol of prosperity and renewal, Feathers reflect the platform's agility, vision, and long-term alignment with its users. Starting October 2025, to provide greater certainty and clarity on $HUMA token rewards, the system will continuously allocate token rewards to the community and distribute them at the end of each airdrop season. While the reward mechanism remains powered by Huma Feathers, users will now see their allocated $HUMA token rewards directly, and the impact on APY will be reflected in the DApp. Feathers are converted to $HUMA tokens based on a Feather-to-$HUMA ratio, which can be adjusted periodically to keep rewards attractive to the community. The historical Feather-to-$HUMA ratio are: * Season 0: 8.3 * Season 1: 23.5 * Season 2: 30 (subject to adjustment if needed) The APY is calculated based on the number of $HUMA tokens rewarded and the **7-day average price of the $HUMA token**. [PreviousOverview](https://docs.huma.finance/products/huma-2.0/overview) [NextModes: Classic vs Maxi](https://docs.huma.finance/products/huma-2.0/modes) Last updated 2 months ago --- # Modes: Classic vs Maxi | Huma Huma offers two distinct participation modes to suit different strategies and risk-reward appetites. The two modes allow LPs to prioritize either consistent returns or enhanced protocol incentives based on their risk tolerance and objectives. Switching between modes is flexible and instant. Users can switch modes as often as desired, incurring only gas fees. * **Classic Mode** provides a stable APY for LPs seeking predictable, real-world yield. In this mode, users also earn a base allocation of Huma Feathers, ideal for users who prioritize consistent income while staying engaged with protocol incentives. PST (PayFi Strategy Token) is the LP token for this mode. * **Maxi Mode** foregoes the base APY in exchange for significantly higher Huma Feather rewards. Designed for committed Huma ecosystem participants, Maxi Mode rewards long-term alignment and maximizes exposure to governance and protocol upside. mPST (Maxi PayFi Strategy Token) is the LP token for this mode. Both modes operate on the same underlying pool mechanics and LP token structure but differ in how returns are allocated between fixed yield and protocol rewards. The table below provides a side-by-side comparison of the two modes. **Mode** **Stable Yield** **Huma Feathers** **Target Users** **Token** Classic 9% APY\* $ Yield maxis PST Maxi 0% APY $$$$$ Huma maxis mPST \*Subject to monthly adjustments based on market conditions. [PreviousFeathers](https://docs.huma.finance/products/huma-2.0/feathers) [NextLockup](https://docs.huma.finance/products/huma-2.0/lockup) Last updated 2 months ago --- # Lockup | Huma When depositing into the Huma pool, LPs have the option to **lock up their funds** for a fixed period in exchange for **enhanced Huma Feathers rewards**. Withdrawals are restricted during the lockup period. Once the lockup expires, the position is automatically unlocked, granting immediate access to funds. When users deposit, users can choose **no lockup**, a **3-month lockup**, or a **6-month lockup**. Users can **always move forward**: * From no lockup → 3 months or 6 months * From 3 months → extend to 6 months However, you **cannot shorten the lockup period**. For example, if you have already made a 6-month commitment, you can't reduce it to 3 months. Lockup extension gives users **flexibility and control,** allowing users to ease into longer commitments and boost rewards over time without over-committing from day one. **Lockups enable LPs to demonstrate sustained commitment to the protocol's success. Feathers earning potential scales directly with the duration of participation.** The table below outlines the available lockup durations and their corresponding reward multipliers: Lockup Redemption Rewards Multiplier No Lockup Redeem anytime 1x 3-month After 3 months 2x\* 6-month After 6 months 3x\* * During the **promotional period** of the Huma 2.0 launch, these multipliers are elevated to **3x for 3-month** lockups and **5x for 6-month** lockups. You can earn the lockup multiples only if you use Huma DApp or any other DeFi protocols that have been officially supported by Huma. [](https://docs.huma.finance/products/huma-2.0/lockup#restrictions) **Restrictions** ----------------------------------------------------------------------------------------- Positions with a lockup come with limitations on redemption and transfers: * **No early redemption**: Locked positions cannot be redeemed through the Huma DApp. Any attempt to bypass this via direct smart contract calls will be rejected. If redemption somehow occurs despite restrictions, **all Feathers earned from that position will be forfeited**. * **Bonus rewards will be forfeited upon locked token transfer**: If locked tokens are transferred—including actions like swapping on Jupiter or depositing into platforms like Kamino or RateX—the transferred portion will be treated as **unlocked**. This means **any bonus Feathers earned from the lockup will be reverted**. **Example** Suppose an LP deposits $1,000 in Classic mode with a 3-month lockup during a promotional period offering a **3x Feather multiplier**. This yields **3,000 Feathers per month**. After one month, if the LP swaps **$700** of the position on Jupiter for USDC, that portion will be treated as **unlocked from the start**. The revised Feather reward would be: * $700 × 1x = 700 Feathers * $300 × 3x = 900 Feathers * **Total = 1,600 Feathers** Since the LP had originally earned 3,000 Feathers, the **extra 1,400 Feathers** gained due to the lockup will be **revoked**. [PreviousModes: Classic vs Maxi](https://docs.huma.finance/products/huma-2.0/modes) [NextReferral](https://docs.huma.finance/products/huma-2.0/referral) Last updated 8 months ago --- # Referral | Huma Grow the Huma ecosystem and earn rewards by inviting your friends to join. When you refer someone to Huma, you'll receive **10% of the Feathers they earn** during the **first 12 months** after their initial deposit. This includes Feathers earned through both unlocked and locked positions, including any multipliers from lockups or promotional campaigns. [](https://docs.huma.finance/products/huma-2.0/referral#how-it-works) How it works --------------------------------------------------------------------------------------- * Each user has a unique referral link, which is available in the Huma DApp. * When your friend signs up and makes their first deposit using your link, the referral is automatically registered. * You'll earn **10% of their Feather rewards**—passively—for one full year. * Your friend keeps **100% of their own rewards**. Your referral bonus is **on top** of what they earn. [](https://docs.huma.finance/products/huma-2.0/referral#example) Example ----------------------------------------------------------------------------- If your friend earns 1,000,000 Feathers over their first year, you'll receive **100,000 Feathers** as a reward—at no cost to them. Start building your Feather stream by sharing your referral link today! [PreviousLockup](https://docs.huma.finance/products/huma-2.0/lockup) [NextRedemption](https://docs.huma.finance/products/huma-2.0/redemption) Last updated 8 months ago * [How it works](https://docs.huma.finance/products/huma-2.0/referral#how-it-works) * [Example](https://docs.huma.finance/products/huma-2.0/referral#example) --- # Switching Modes | Huma Flexibility is built in—you can switch between modes while keeping your lockup periods intact. For example, if you deposit $100 in Maxi Mode and receive 100 mPST tokens with a 6-month lockup, and then decide to switch to Classic Mode after 3 months and 23 hours, the following will occur: * Your 100 mPST tokens will be burned. * Given a PST price of 1.025 at that moment, you'll receive 97.5 PST tokens. * For that month, both your stable yield and Feathers rewards will be calculated using the Maxi rate for the first 23 hours and the Classic rate for the remainder of the month. This flexible structure allows you to tailor your investment strategy as your needs evolve. ![](https://docs.huma.finance/~gitbook/image?url=https%3A%2F%2F3505582914-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F6xrnZZGJOKGQIiYrafx3%252Fuploads%252Fgit-blob-eafaa5a030c57a4531e9de5bac3519760f7029f2%252Fmode-switch.gif%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=1ef2f812&sv=2) Switching Mode [PreviousExtending Lockup](https://docs.huma.finance/products/huma-2.0/user-manuals/extending-lockup) [NextPortfolio](https://docs.huma.finance/products/huma-2.0/user-manuals/portfolio) Last updated 8 months ago --- # Extending Lockup | Huma Extend the lockup period on your positions for up to 6 months to earn increased Huma Feathers rewards. Please note that you can only extend—not shorten—the lockup period. ![](https://docs.huma.finance/~gitbook/image?url=https%3A%2F%2F3505582914-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F6xrnZZGJOKGQIiYrafx3%252Fuploads%252Fgit-blob-05b4b55e1d4e3f4f10388f154766938f2befac5a%252Fextend-lockup.gif%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=90627455&sv=2) Extending Lockup [PreviousWithdrawal](https://docs.huma.finance/products/huma-2.0/user-manuals/withdrawal) [NextSwitching Modes](https://docs.huma.finance/products/huma-2.0/user-manuals/switching-modes) Last updated 8 months ago --- # Portfolio | Huma The Portfolio page serves as your central hub for managing your pool positions. Here, you can view your balance, track the total Feathers you've earned, review active positions, and check your transaction history. You can also take actions such as switching modes, extending lockup periods, or requesting withdrawals. ![](https://docs.huma.finance/~gitbook/image?url=https%3A%2F%2F3505582914-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F6xrnZZGJOKGQIiYrafx3%252Fuploads%252Fgit-blob-e63f74eeb29f72147f4456dc8551d49ee81576ad%252Fportfolio.gif%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=2a0c204e&sv=2) Portfolio [PreviousSwitching Modes](https://docs.huma.finance/products/huma-2.0/user-manuals/switching-modes) [NextFeathers](https://docs.huma.finance/products/huma-2.0/user-manuals/feathers) Last updated 8 months ago --- # $PST | Huma Here, you can access key DeFi composability features, such as swapping PST for USDC via Jupiter and borrowing USDC through Kamino. ![](https://docs.huma.finance/~gitbook/image?url=https%3A%2F%2F3505582914-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F6xrnZZGJOKGQIiYrafx3%252Fuploads%252Fgit-blob-7f27617f67aed09a92bcea8fb7535ead6fada6ce%252Fpst.gif%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=2b33d44b&sv=2) PST [PreviousFeathers](https://docs.huma.finance/products/huma-2.0/user-manuals/feathers) [NextData Room](https://docs.huma.finance/products/huma-2.0/user-manuals/data-room) Last updated 8 months ago --- # Feathers | Huma On this page, you'll find detailed information about your Feather earnings, including your total accumulation and seasonal breakdowns. All Feathers earned across your wallets under one account will be displayed on this page. You can also view your ranking among all users in the "Leaderboard" tab—aim for that top spot! ![](https://docs.huma.finance/~gitbook/image?url=https%3A%2F%2F3505582914-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F6xrnZZGJOKGQIiYrafx3%252Fuploads%252Fgit-blob-7d716e2d4394d8b98142d4151fd90a1dfc225531%252Ffeathers-leaderboard.gif%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=1e13e710&sv=2) Feathers & Leaderboard [PreviousPortfolio](https://docs.huma.finance/products/huma-2.0/user-manuals/portfolio) [Next$PST](https://docs.huma.finance/products/huma-2.0/user-manuals/pst) Last updated 8 months ago --- # Data Room | Huma This page displays key protocol and product statistics alongside links to essential documents and resources. ![](https://docs.huma.finance/~gitbook/image?url=https%3A%2F%2F3505582914-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F6xrnZZGJOKGQIiYrafx3%252Fuploads%252Fgit-blob-bb9d6b305042e036c5bdfae3b1f1ab9744afc838%252Fdata-room.gif%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=e088be9d&sv=2) Data Room [Previous$PST](https://docs.huma.finance/products/huma-2.0/user-manuals/pst) [NextFAQs](https://docs.huma.finance/products/huma-2.0/faqs) Last updated 8 months ago --- # Overview | Huma Huma Institutional is a permissioned protocol designed for institutional investors to access curated payment financing and RWA opportunities. This enables licensed financial institutions to scale responsibly while meeting the surging demand for flexible, compliant financial infrastructure. The list below highlights the key building blocks of the protocol: * **Structured finance.** This includes tranches, first loss coverage, 30/360 calendar, and day boundary yield calculations. * **Tokenization.** Allows real-world assets to be tokenized through SPV structures. * **Transparency.** Clearly present the lifecycle of real-world receivables on-chain so that the investors can easily monitor the performance of these receivables. Given the complexities of structured finance, we took a modular approach by defining critical abstractions and allowing additional modules to be added over time to enrich the protocol to suit the needs of various use cases. Below are some critical abstractions: * **Tranche policy.** It defines the P&L rules between different tranches. * **Calendar.** TradFi often uses 30/360 calendar, but more DeFi-native parties would like to take advantage of DeFi’s second-level yield calculation. * **Yield manager.** It defines how yield is calculated. Some pools may charge various fees, ranging from front-loading and back-loading to subscription fees. * **First loss cover.** First loss cover can be sourced from the borrower, insurance, or investors. A single pool might have multiple layers of first loss cover. The Huma protocol permits up to 16 layers of first loss cover, offering a flexible mechanism to configure both coverage and yield for these layers. [PreviousIntroduction](https://docs.huma.finance/products/huma-institutional/introduction) [NextPool Types](https://docs.huma.finance/products/huma-institutional/introduction/pool-types) Last updated 2 months ago --- # Introduction | Huma [Overview](https://docs.huma.finance/products/huma-institutional/introduction/overview) [Pool Types](https://docs.huma.finance/products/huma-institutional/introduction/pool-types) [Calendar](https://docs.huma.finance/products/huma-institutional/introduction/calendar) [Admin Roles](https://docs.huma.finance/products/huma-institutional/introduction/admin-roles) [PreviousHuma Institutional](https://docs.huma.finance/products/huma-institutional) [NextOverview](https://docs.huma.finance/products/huma-institutional/introduction/overview) Last updated 8 months ago --- # Huma Institutional | Huma [Introduction](https://docs.huma.finance/products/huma-institutional/introduction) [Tranches](https://docs.huma.finance/products/huma-institutional/tranches) [First Loss Covers](https://docs.huma.finance/products/huma-institutional/first-loss-covers) [User Manuals](https://docs.huma.finance/products/huma-institutional/user-manuals) [PreviousFAQs](https://docs.huma.finance/products/huma-2.0/faqs) [NextIntroduction](https://docs.huma.finance/products/huma-institutional/introduction) Last updated 8 months ago --- # FAQs | Huma [](https://docs.huma.finance/products/huma-2.0/faqs#what-is-huma-2.0-what-happens-to-the-existing-permissioned-product) What is Huma 2.0? What happens to the existing permissioned product? ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Huma 2.0 democratizes access to decentralized finance with a permissionless model, allowing anyone to tap into institutional-grade PayFi yields—previously available only to professional investors. Huma 2.0 is the flagship product, branded simply as **Huma**. The existing permissioned service continues under the **Huma Institutional** brand, serving institutional partners with tailored requirements. The **Launch App** button on [huma.finance](https://huma.finance/) provides access to both: * **Huma (permissionless)**: Launched in April 2025 * **Huma Institutional (permissioned)**: The original product prior to April 2025 [](https://docs.huma.finance/products/huma-2.0/faqs#what-are-huma-rewards-how-are-they-related-to-huma-feathers) What are Huma rewards? How are they related to Huma Feathers? ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Starting October 2025, to provide greater certainty and clarity on HUMA token rewards, the system will **continuously allocate token rewards** to the community and distribute them at the end of each airdrop season. While the reward mechanism remains powered by Huma Feathers, users will now see their accrued $HUMA token rewards directly, and the impact on APY will be reflected in the Huma App. The estimated rewards APY will be calculated based on Huma’s tokenomics and the 7-day average price of $HUMA token. Feathers are converted to $HUMA tokens based on a Feather-to-$HUMA ratio, which can be adjusted periodically to keep rewards attractive to the community. The historical Feather-to-$HUMA ratios are: * Season 0: 8.3 * Season 1: 23.5 * Season 2: 30 (subject to adjustment if needed) **Huma rewards and Feathers are non-transferable and non-tradable.** They are **tied to your wallet** and reflect your individual participation and loyalty. **Neither can be sold, transferred, or shared.** [](https://docs.huma.finance/products/huma-2.0/faqs#on-which-chains-are-huma-and-huma-institutional-available) On which chains are Huma and Huma Institutional available? ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ * **Huma 2.0**: Available only on **Solana** * **Huma Institutional**: Available on **Solana**, **EVM**, and **Stellar** [](https://docs.huma.finance/products/huma-2.0/faqs#who-can-participate-as-an-lp-in-huma-2.0) Who can participate as an LP in Huma 2.0? -------------------------------------------------------------------------------------------------------------------------------------------- Any user who is not from a [sanctioned or restricted region](https://app.huma.finance/restricted-countries) can participate, provided their wallet does not get flagged by **Chainalysis risk screening**. [](https://docs.huma.finance/products/huma-2.0/faqs#what-is-the-minimum-deposit-amount) What is the minimum deposit amount? -------------------------------------------------------------------------------------------------------------------------------- 1 USDC [](https://docs.huma.finance/products/huma-2.0/faqs#is-there-a-pool-cap-in-huma-2.0) Is there a pool cap in Huma 2.0? -------------------------------------------------------------------------------------------------------------------------- Yes. Huma has a **dynamic pool cap** based on real-world capital demand from PayFi partners to ensure high utilization rates. When the cap is reached: * New deposits are paused. * Deposits reopen only when new demand is added or existing LPs withdraw. This protects yield quality for all participants and keeps capital highly efficient. [](https://docs.huma.finance/products/huma-2.0/faqs#what-do-users-receive-when-they-deposit) What do users receive when they deposit? ------------------------------------------------------------------------------------------------------------------------------------------ Users receive a liquid LP token based on the mode they choose: * **$PST** (Classic Mode) * **$mPST** (Maxi Mode) Users can switch the mode of their existing positions to swap between $PST and $mPST. [](https://docs.huma.finance/products/huma-2.0/faqs#what-are-classic-mode-and-maxi-mode) What are Classic Mode and Maxi Mode? ---------------------------------------------------------------------------------------------------------------------------------- Huma offers two modes to match different LP strategies. You can switch between them **anytime, as often as you like**. * **Classic Mode** provides **stable yield** with **moderate $HUMA token rewards**. The current base APY is visible through the Huma App, updated monthly based on market conditions. This mode is ideal for LPs who prioritize **consistent returns**. * **Maxi Mode** offers **maximum $HUMA token rewards** by **trading away stable yield**. LPs in this mode earn only $HUMA tokens, making it the go-to choice for **token-maximizing believers**—aka the Huma maxis. [](https://docs.huma.finance/products/huma-2.0/faqs#what-are-usdpst-and-usdmpst) What are $PST and $mPST? -------------------------------------------------------------------------------------------------------------- PST stands for PayFi Strategy Token * **$PST**: LP token for Classic Mode (base yield + Huma rewards) * **$mPST**: LP token for Maxi Mode (maximum Huma rewards, no base yield) [](https://docs.huma.finance/products/huma-2.0/faqs#what-happens-if-i-switch-between-classic-mode-and-maxi-mode) What happens if I switch between Classic Mode and Maxi Mode? ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- When switching modes: * Your current token (**$PST** or **$mPST**) is **burned**, and the corresponding token is **minted**. * **Switching to Maxi**: Forgoes base APY for a higher amount of Huma rewards. * **Switching to Classic**: Captures base APY with a lower amount of Huma rewards. **Lockup status remains unchanged.** You can switch at any time, as often as you'd like. There is **currently no fee** for switching (gas fees apply), but this may change in the future. [](https://docs.huma.finance/products/huma-2.0/faqs#can-usdpst-be-used-in-other-defi-protocols) Can $PST be used in other DeFi protocols? ---------------------------------------------------------------------------------------------------------------------------------------------- Yes. Huma integrates with major Solana DeFi protocols: * **Jupiter** – PST-USDC swaps for instant liquidity * **Orca** - mPST-USDC swaps, underlying pool powering Jupiter * **Kamino** – Provide liquidity to the PST-USDC and mPST-USDC liquidity vault or engage in the Huma Market in the following ways: * Supplying USDC or USDS. * Depositing PST. * Borrowing USDC or USDS against their deposited PST. * **Note:** Each wallet can either supply or borrow, but cannot do both. * **RateX** – Enables Huma LPs to transform their $PST into structured DeFi positions (PT/YT), enabling leverage, hedging, and more tailored yield strategies. [](https://docs.huma.finance/products/huma-2.0/faqs#can-i-transfer-usdpst-or-usdmpst-to-another-wallet) Can I transfer $PST or $mPST to another wallet? ------------------------------------------------------------------------------------------------------------------------------------------------------------ Yes. Both tokens are standard SPL tokens and can be transferred to any supported wallet. However, please note: * **Transferred tokens lose their lockup status** * The transferred position will be treated as **unlocked** in the receiving wallet. * Any **extra Huma rewards earned from lockups** or **badges** will be **reverted** in the original wallet. * An exception applies only if the transfer is to protocols where Huma has officially stated that lockup status and rewards will be preserved (currently none). [](https://docs.huma.finance/products/huma-2.0/faqs#why-is-the-usdmpst-price-above-usd1) Why is the $mPST price above $1? ------------------------------------------------------------------------------------------------------------------------------ Although Maxi mode doesn’t generate a stable yield and the price is intended to remain at $1, we’ve discovered that some users accidentally burned their $mPST while leaving their USDC in the pool. This imbalance — more USDC held than $mPST outstanding — has driven the price above $1. **Implications:** * **Early depositors** (before any burning occurred) will receive slightly more USDC upon redemption than originally deposited. * **Later depositors** (after the last burning incident) will now receive **fewer $mPST tokens** per USDC deposited, since $mPST is priced above $1. But when you redeem, you’ll still get back exactly the amount of USDC deposited. **Warning:** Token burning is **irreversible**. Please double‑check before you proceed — **lost tokens cannot be recovered.** [](https://docs.huma.finance/products/huma-2.0/faqs#why-choose-a-lockup-over-no-lockup) Why choose a lockup over no lockup? -------------------------------------------------------------------------------------------------------------------------------- Locking your position boosts your **Huma reward multiplier** while still giving you full access to your capital once the lockup ends. Huma offers three lockup options: * **No Lockup**: Redeem anytime. Earns **baseline Huma rewards**. * **3-Month Lockup**: Redeem after 3 months. Earns **higher Huma rewards**. * **6-Month Lockup**: Redeem after 6 months. Earns the **highest Huma rewards**. [](https://docs.huma.finance/products/huma-2.0/faqs#what-are-the-different-ways-to-boost-your-reward-multiplier) What are the different ways to boost your reward multiplier? ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- You can stack multiple multipliers for even higher rewards: * **Mode Multiplier** – Maxi Mode > Classic Mode. * **Lockup Multiplier** – Longer lockups = higher multiplier. * **OG LP Multiplier** – Lifetime bonus for pre-Huma 2.0 LPs who remained active. * **Staking Multiplier** – $HUMA Stakers currently earn 10% APY with a 14-day unstaking cooldown. * **Vanguard Multiplier** – A lifetime bonus to reward long-term stakers of the $HUMA token. * **Community Boost Multiplier** – Temporary boost for users referred by partner communities. [](https://docs.huma.finance/products/huma-2.0/faqs#how-does-redemption-work) How does redemption work? ------------------------------------------------------------------------------------------------------------ * **No Lockup**: Redeem anytime. * **Locked Positions**: Redeem after the lockup period ends. Redemptions are processed on a **first-come, first-served** basis. Most are completed within **2 business days**, though some may take up to **7 days** per SLA. [](https://docs.huma.finance/products/huma-2.0/faqs#what-if-i-need-instant-liquidity) What if I need instant liquidity? ---------------------------------------------------------------------------------------------------------------------------- Users could swap on Jupiter leveraging the PST-USDC pool and mPST-USDC pool (via Orca) at secondary market price. Even if your position is locked, you can exit early by swapping on Jupiter. However, in that case: * The position is treated as **unlocked**. * Any **extra $HUMA token rewards** earned from the lockup will be **reverted**. * You may face slippage. [](https://docs.huma.finance/products/huma-2.0/faqs#how-will-the-capital-in-the-pool-be-used) How will the capital in the pool be used? -------------------------------------------------------------------------------------------------------------------------------------------- As the name **PayFi Strategy Token** suggests, most of the capital will be deployed into PayFi opportunities. A portion of the pool will be allocated to **market-neutral liquid assets** to ensure liquidity for redemptions. We aim to maintain a long-term ratio of 85% PayFi assets and 15% liquid assets. [](https://docs.huma.finance/products/huma-2.0/faqs#where-does-the-yield-come-from) Where does the yield come from? ------------------------------------------------------------------------------------------------------------------------ Huma primarily generates yield from **PayFi**—real-world payment financing activities such as: * Global settlement * Card payments * Trade finance Businesses pay a **daily fee** to borrow capital (typically 1–5 days), allowing: * **Capital recycling up to 100x/year**. * **Compounding effect** that drives stable, attractive returns. Unlike DeFi yield, which relies on token incentives, PayFi yield is **rooted in the real economy**. Huma also generates yield from **market-neutral digital asset deployments**. [](https://docs.huma.finance/products/huma-2.0/faqs#how-does-huma-ensure-smart-contract-and-system-security) How does Huma ensure smart contract and system security? -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Huma follows industry best practices for security: * **Minimized Admin Rights** – All admin actions require multisig. Even if keys are compromised, contracts prevent LP fund theft. * **Top-Tier Audits** – Audited by Spearbit, Halborn, and Certora. Huma 2.0 was audited by Halborn. \[[View audit report here.](https://www.halborn.com/audits/huma-finance/solana-programs-060022)\ \]. * **Infrastructure Security** – Penetration-tested backend, real-time malware monitoring, and employee security protections. [](https://docs.huma.finance/products/huma-2.0/faqs#what-are-the-requirements-for-huma-institutional) What are the requirements for Huma Institutional? ------------------------------------------------------------------------------------------------------------------------------------------------------------ Huma Institutional is available to **professional investors** who complete **KYC/KYB verification**. This requirement is unchanged from the existing permissioned product. [](https://docs.huma.finance/products/huma-2.0/faqs#is-there-a-cap-on-the-huma-rewards-i-can-earn) Is there a cap on the Huma rewards I can earn? ------------------------------------------------------------------------------------------------------------------------------------------------------ There is **no hard cap**, but your rewards depend on: * The **amount and duration** of your deposit * Your **reward multipliers** (mode, lockup, OG status, etc.) * The **reward allocation** available for the current season Rewards are **performance-based**, not arbitrarily capped. However, Huma **reserves the right to revoke rewards** if a wallet engages in **Sybil attacks or manipulation**. [](https://docs.huma.finance/products/huma-2.0/faqs#what-are-the-risks-of-participating-as-a-liquidity-provider-lp) What are the risks of participating as a liquidity provider (LP)? ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ While Huma prioritizes safety, DeFi participation carries risks, including: * **Smart Contract Risk**: Even with audits, vulnerabilities may exist. * **Slippage / Impermanent Loss**: May occur when using $PST in external DeFi. * **Liquidity Risk**: Redemptions may be delayed during peak activity. * **Regulatory Risk**: Legal changes may affect your ability to participate. * **Credit Risk**: While historically very low, PayFi borrowers may default. Huma mitigates these through: * Audited contracts * Conservative protocol design * Real-world yield generation * Transparent governance * Rigorous underwriting and risk management [](https://docs.huma.finance/products/huma-2.0/faqs#why-are-my-swap-transactions-on-jupiter-not-appearing-in-my-portfolio) Why are my swap transactions on Jupiter not appearing in my portfolio? ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ It might take a while to synchronize the actions you have taken outside Huma. If you had a successful transaction on Jupiter, your portfolio will eventually reflect that. [](https://docs.huma.finance/products/huma-2.0/faqs#what-do-i-earn-in-the-huma-market-and-liquidity-products-on-kamino) What do I earn in the Huma market and liquidity products on Kamino? ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Huma rewards are rewarded hourly, though there may be a delay before they appear in your portfolio. This is the only way for these specific tokens to earn Huma rewards—they will not earn additional Huma rewards from other areas of the Huma ecosystem. If the PST/mPST you deposit is currently under a lockup period, any extra Huma rewards you previously earned from that lockup will be deducted. Make sure you only deposit unlocked tokens. [](https://docs.huma.finance/products/huma-2.0/faqs#what-are-the-benefits-of-staking-usdhuma) What are the benefits of staking $HUMA? ------------------------------------------------------------------------------------------------------------------------------------------ **Protocol Governance**: Huma is developing an innovative governance framework designed to better align $HUMA stakers with the platform’s products, business strategy, and long-term vision. Details will be outlined in a future proposal. **Staking Rewards**: Stakers earn rewards directly, without needing to be LPs. **Boosted LP Rewards**: Stakers receive enhanced rewards on their LP positions. **Priority Access to Ecosystem Incentive Programs**: Stakers enjoy exclusive or early access to various protocol-driven and partner-based incentives. Examples include: * Early access to deposit into Huma when capacity is limited * Eligibility for Huma Yapper rewards * Eligible for promotions and airdrops from ecosystem partners [](https://docs.huma.finance/products/huma-2.0/faqs#what-is-the-staking-policy) What is the staking policy? ---------------------------------------------------------------------------------------------------------------- Stakers can request to unstake at any time, and can withdraw after a 14-day cooldown. Staking Factor plays a critical role in determining the staking reward. The initial promotional value of the Staking Factor is 10x. Staking rewards are distributed in the form of Huma rewards, similar to LP rewards. Those who staked before June 30th, 2025 can keep their 0-day unstaking cooldown. Starting Aug 26, 2025 they will stop earning Huma rewards unless they opt into the new policy: est. 10% APY with a 14-day cooldown in the Huma App. The staking reward applies retroactively to those who have staked before the staking rewards launch on June 30th, 2025. [](https://docs.huma.finance/products/huma-2.0/faqs#how-do-i-earn-badges) How do I earn badges? ---------------------------------------------------------------------------------------------------- ### [](https://docs.huma.finance/products/huma-2.0/faqs#og-lp-badge) OG LP badge Designed to reward early believers of Huma and PayFi’s vision. If you provided liquidity to the Huma protocol before Apr. 2025, you would have earned the OG LP badge. As long as you continue to provide at least 100 USDC liquidity, you keep the OG LP badge and enjoy the benefits. ### [](https://docs.huma.finance/products/huma-2.0/faqs#vanguard-badge) Vanguard badge Designed to encourage and reward long-term $HUMA stakers. You can earn a Vanguard badge by staking $HUMA. Users must meet qualification criteria following ONE of the two paths, airdrop and non-airdrop, while **maintaining their staking position for at least 6 months**. #### [](https://docs.huma.finance/products/huma-2.0/faqs#airdrop-route) Airdrop route * **< 100,000 $HUMA** → Stake **100%** * **100,000–200,000 $HUMA** → Stake **100,000 $HUMA** * **\> 200,000 $HUMA** → Stake **50%** _Notes:_ * _Staking the required amount across_ _**2 seasons**_ _within a_ _**6-month**_ _window qualifies you for_ _**Vanguard**__._ * _Includes_ _**$HUMA presale**_ _for_ _**Huma OGs**_ _and_ _**Jup**_ _stakers._ #### [](https://docs.huma.finance/products/huma-2.0/faqs#non-airdrop-route) Non-airdrop route * If you did not receive an airdrop, qualify by staking **at least 100,000 $HUMA**. * _Includes_ _**Kaito**__._ For both routes, the badge will be awarded after you have staked for six months, and you can maintain it thereafter by continuing to stake at least 10,000 $HUMA. ### [](https://docs.huma.finance/products/huma-2.0/faqs#anchor-badge) Anchor badge Designed for LPs to gain the ability to contribute more capital. To qualify: An LP must deposit at least 1,000 USDC with a six-month lockup into any Huma product. Once the deposit matures, they will have three months to redeposit for another six-month lockup. The new deposit limit will be the greater of 2x the original deposit or the per-wallet cap, and as long as the final deposit amount is at least 1,000 USDC, the LP will earn the Anchor badge. * * * **Disclaimer:** These FAQs are provided for user convenience. Accordingly, they do not fully describe the legal structure or operations of the issuer of $PST and $mPST, nor do they fully describe certain risk factors. Detailed information about the foregoing is set forth in the issuer's PayFi Strategy Memorandum (PSM), which will be provided to users as part of the deposit process. [PreviousData Room](https://docs.huma.finance/products/huma-2.0/user-manuals/data-room) [NextHuma Institutional](https://docs.huma.finance/products/huma-institutional) Last updated 2 months ago * [What is Huma 2.0? What happens to the existing permissioned product?](https://docs.huma.finance/products/huma-2.0/faqs#what-is-huma-2.0-what-happens-to-the-existing-permissioned-product) * [What are Huma rewards? How are they related to Huma Feathers?](https://docs.huma.finance/products/huma-2.0/faqs#what-are-huma-rewards-how-are-they-related-to-huma-feathers) * [On which chains are Huma and Huma Institutional available?](https://docs.huma.finance/products/huma-2.0/faqs#on-which-chains-are-huma-and-huma-institutional-available) * [Who can participate as an LP in Huma 2.0?](https://docs.huma.finance/products/huma-2.0/faqs#who-can-participate-as-an-lp-in-huma-2.0) * [What is the minimum deposit amount?](https://docs.huma.finance/products/huma-2.0/faqs#what-is-the-minimum-deposit-amount) * [Is there a pool cap in Huma 2.0?](https://docs.huma.finance/products/huma-2.0/faqs#is-there-a-pool-cap-in-huma-2.0) * [What do users receive when they deposit?](https://docs.huma.finance/products/huma-2.0/faqs#what-do-users-receive-when-they-deposit) * [What are Classic Mode and Maxi Mode?](https://docs.huma.finance/products/huma-2.0/faqs#what-are-classic-mode-and-maxi-mode) * [What are $PST and $mPST?](https://docs.huma.finance/products/huma-2.0/faqs#what-are-usdpst-and-usdmpst) * [What happens if I switch between Classic Mode and Maxi Mode?](https://docs.huma.finance/products/huma-2.0/faqs#what-happens-if-i-switch-between-classic-mode-and-maxi-mode) * [Can $PST be used in other DeFi protocols?](https://docs.huma.finance/products/huma-2.0/faqs#can-usdpst-be-used-in-other-defi-protocols) * [Can I transfer $PST or $mPST to another wallet?](https://docs.huma.finance/products/huma-2.0/faqs#can-i-transfer-usdpst-or-usdmpst-to-another-wallet) * [Why is the $mPST price above $1?](https://docs.huma.finance/products/huma-2.0/faqs#why-is-the-usdmpst-price-above-usd1) * [Why choose a lockup over no lockup?](https://docs.huma.finance/products/huma-2.0/faqs#why-choose-a-lockup-over-no-lockup) * [What are the different ways to boost your reward multiplier?](https://docs.huma.finance/products/huma-2.0/faqs#what-are-the-different-ways-to-boost-your-reward-multiplier) * [How does redemption work?](https://docs.huma.finance/products/huma-2.0/faqs#how-does-redemption-work) * [What if I need instant liquidity?](https://docs.huma.finance/products/huma-2.0/faqs#what-if-i-need-instant-liquidity) * [How will the capital in the pool be used?](https://docs.huma.finance/products/huma-2.0/faqs#how-will-the-capital-in-the-pool-be-used) * [Where does the yield come from?](https://docs.huma.finance/products/huma-2.0/faqs#where-does-the-yield-come-from) * [How does Huma ensure smart contract and system security?](https://docs.huma.finance/products/huma-2.0/faqs#how-does-huma-ensure-smart-contract-and-system-security) * [What are the requirements for Huma Institutional?](https://docs.huma.finance/products/huma-2.0/faqs#what-are-the-requirements-for-huma-institutional) * [Is there a cap on the Huma rewards I can earn?](https://docs.huma.finance/products/huma-2.0/faqs#is-there-a-cap-on-the-huma-rewards-i-can-earn) * [What are the risks of participating as a liquidity provider (LP)?](https://docs.huma.finance/products/huma-2.0/faqs#what-are-the-risks-of-participating-as-a-liquidity-provider-lp) * [Why are my swap transactions on Jupiter not appearing in my portfolio?](https://docs.huma.finance/products/huma-2.0/faqs#why-are-my-swap-transactions-on-jupiter-not-appearing-in-my-portfolio) * [What do I earn in the Huma market and liquidity products on Kamino?](https://docs.huma.finance/products/huma-2.0/faqs#what-do-i-earn-in-the-huma-market-and-liquidity-products-on-kamino) * [What are the benefits of staking $HUMA?](https://docs.huma.finance/products/huma-2.0/faqs#what-are-the-benefits-of-staking-usdhuma) * [What is the staking policy?](https://docs.huma.finance/products/huma-2.0/faqs#what-is-the-staking-policy) * [How do I earn badges?](https://docs.huma.finance/products/huma-2.0/faqs#how-do-i-earn-badges) * [OG LP badge](https://docs.huma.finance/products/huma-2.0/faqs#og-lp-badge) * [Vanguard badge](https://docs.huma.finance/products/huma-2.0/faqs#vanguard-badge) * [Anchor badge](https://docs.huma.finance/products/huma-2.0/faqs#anchor-badge) --- # Tranches | Huma Tranche support is vital for institutions participating in the Huma protocol. As mentioned before, there are two types of tranches: senior and junior. The senior tranche is generally seen as a lower-risk investment. It offers a modest yield but carries less risk. If there's a default, senior tranche lenders receive payment first. The junior tranche, on the other hand, assumes a higher risk and earns a higher yield when things go smoothly. If there's a default, junior tranche lenders are paid after those in the senior tranche. [PreviousAdmin Roles](https://docs.huma.finance/products/huma-institutional/introduction/admin-roles) [NextP&L Policies](https://docs.huma.finance/products/huma-institutional/tranches/pnl) Last updated 8 months ago --- # Deposit | Huma Deposits are accepted on a first-come, first-served basis until the pool liquidity cap is reached. [](https://docs.huma.finance/products/huma-institutional/tranches/deposit#capital-deployment) Capital Deployment --------------------------------------------------------------------------------------------------------------------- Deposits are effective immediately upon acceptance, affecting the utilization rate for both senior and junior assets. In general, the amount of utilized capital attributed to each tranche corresponds to its proportion in the pool assets. For example, if a pool contains $80 in senior assets and $20 in junior assets, senior assets account for 80% of the total. If the borrower draws down $80, the protocol allocates $64 from the senior tranche and the remaining $16 from the junior tranche. If an additional $60 in junior capital is added to the pool, keeping the utilized capital at $80, the senior assets now represent 50% of the total pool. As a result, the protocol would allocate an equal deployment of $40 from each tranche. [](https://docs.huma.finance/products/huma-institutional/tranches/deposit#lockout-period) Lockout Period ------------------------------------------------------------------------------------------------------------- A pool may establish a lockout period during which you must wait a certain number of days before you can redeem your deposits. The lockout period resets with each new deposit. For instance, if you make two deposits of $100 each on February 1st and March 1st, and the lockout period is 60 days, the lockout period resets to April 30th for the entire $200 following the second deposit. [](https://docs.huma.finance/products/huma-institutional/tranches/deposit#minimum-deposit-amount) Minimum Deposit Amount ----------------------------------------------------------------------------------------------------------------------------- The protocol mandates each pool to set a minimum deposit amount. This threshold is enforced with every deposit. The protocol's absolute minimum is 10 units of the pool's underlying asset (for instance, 10 USDC for pools using USDC as the underlying asset). However, the Pool Owner has the discretion to set a higher threshold. [PreviousP&L Policies](https://docs.huma.finance/products/huma-institutional/tranches/pnl) [NextRedemption](https://docs.huma.finance/products/huma-institutional/tranches/redemption) Last updated 8 months ago * [Capital Deployment](https://docs.huma.finance/products/huma-institutional/tranches/deposit#capital-deployment) * [Lockout Period](https://docs.huma.finance/products/huma-institutional/tranches/deposit#lockout-period) * [Minimum Deposit Amount](https://docs.huma.finance/products/huma-institutional/tranches/deposit#minimum-deposit-amount) --- # Pool Types | Huma [](https://docs.huma.finance/products/huma-institutional/introduction/pool-types#revolving-credit-line) Revolving Credit Line ---------------------------------------------------------------------------------------------------------------------------------- This is a common credit product that approves the borrower for a certain credit limit. The borrower can borrow money and repay it, repeatedly, as long as they stay under the credit limit and make timely payments. [](https://docs.huma.finance/products/huma-institutional/introduction/pool-types#receivable-backed-credit-line) Receivable-backed Credit Line -------------------------------------------------------------------------------------------------------------------------------------------------- The borrower is granted a credit line, but they must present a receivable for each borrowing transaction. This receivable must first be approved. Once approved, an advance rate (which is less than 100%) is applied to the receivable amount to determine how much the borrower can borrow using this receivable. This additional amount is then added to the borrower's available credit. [](https://docs.huma.finance/products/huma-institutional/introduction/pool-types#receivable-factoring-credit) Receivable Factoring Credit ---------------------------------------------------------------------------------------------------------------------------------------------- The borrower can factor a receivable by receiving an advance payment, which is a percentage of the invoice amount. [PreviousOverview](https://docs.huma.finance/products/huma-institutional/introduction/overview) [NextCalendar](https://docs.huma.finance/products/huma-institutional/introduction/calendar) Last updated 8 months ago * [Revolving Credit Line](https://docs.huma.finance/products/huma-institutional/introduction/pool-types#revolving-credit-line) * [Receivable-backed Credit Line](https://docs.huma.finance/products/huma-institutional/introduction/pool-types#receivable-backed-credit-line) * [Receivable Factoring Credit](https://docs.huma.finance/products/huma-institutional/introduction/pool-types#receivable-factoring-credit) --- # P&L Policies | Huma [](https://docs.huma.finance/products/huma-institutional/tranches/pnl#yield-distribution-policies) Yield Distribution Policies ----------------------------------------------------------------------------------------------------------------------------------- We support two yield distribution policies: fixed yield and risk-adjusted yield. * In fixed yield mode, the senior tranche yield remains constant as long as risk loss doesn't prevent this. * In risk-adjusted yield mode, the yield is first determined by the senior-junior asset ratio, and then a portion of the return is transferred from the senior to the junior tranche. For instance, a 20% adjustment means shifting 20% of the return from the senior to the junior tranche. [](https://docs.huma.finance/products/huma-institutional/tranches/pnl#protection-from-losses) Protection From Losses ------------------------------------------------------------------------------------------------------------------------- To guarantee adequate protection for the senior tranche, a maximum leverage ratio is set between the senior and junior tranches for each pool. A 4:1 ratio means that a minimum of 20% of the pool should be junior tranches and a maximum of 80% can be senior tranches. As long as no more than 20% of the pool defaults, the principal of the senior tranche remains secure. [PreviousTranches](https://docs.huma.finance/products/huma-institutional/tranches) [NextDeposit](https://docs.huma.finance/products/huma-institutional/tranches/deposit) Last updated 8 months ago * [Yield Distribution Policies](https://docs.huma.finance/products/huma-institutional/tranches/pnl#yield-distribution-policies) * [Protection From Losses](https://docs.huma.finance/products/huma-institutional/tranches/pnl#protection-from-losses) --- # Admin Roles | Huma [](https://docs.huma.finance/products/huma-institutional/introduction/admin-roles#protocol-level-roles) Protocol-level Roles --------------------------------------------------------------------------------------------------------------------------------- * **Protocol Owner:** The Protocol Owner (a multi-sig) is responsible for administering the entire protocol. This is the only account that can change various protocol configurations and perform administrative tasks, most notably, adding and removing pool owners and pausers, unpausing the protocol, and transferring protocol income from the pool wallet to the protocol treasury. * **Protocol Owner Treasury:** The Protocol Owner Treasury account contains the protocol fees collected from pools. It is kept separate from the Protocol Owner account to avoid concentrating too much power in one account and to enhance security. * **Pausers:** Pausers can pause the entire protocol. When the protocol is paused, no money moves out of the protocol. This is expected to happen in sporadic cases, where the safety and integrity of the protocol are threatened. There can be multiple pausers, including external security monitoring firms. After the protocol is paused, only the Protocol Owner can unpause it. [](https://docs.huma.finance/products/huma-institutional/introduction/admin-roles#pool-level-roles) Pool-level Roles ------------------------------------------------------------------------------------------------------------------------- * **Pool Owners:** Pool Owners are addresses approved by the Protocol Owner to create and manage pools. They set key parameters, choose the Evaluation Agent, and establish the fee structure through the Fee Manager. Additionally, they earn a portion of the pool income as a reward. * **Pool Owner Treasury:** The Pool Owner Treasury account contains the pool owner fees collected from the pools owned by the pool owner. It is kept separate from the Pool Owner account to avoid concentrating too much power in one account and to enhance security. * **Pool Operators:** Pool Operators act as operational staff supporting the Pool Owner. They review the results of KYC/KYB and accreditation, and they approve lenders. Pool Operator accounts do not need to be multi-sigs. * **Evaluation Agents:** Evaluation Agents (EA) are responsible for approving or disapproving credit requests. Each pool is managed by a single EA. While we expect most EAs to operate automatically, the protocol also allows for human supervision. EAs earn a portion of the pool's income as a reward for their services. To ensure accountability, EAs, like Pool Owners, must invest capital in the pools they oversee. A pool can only start accepting capital from other Lenders after both the Pool Owner and the EA have made the necessary deposits. Pool Owners may occasionally change the pool's EA. The incoming EA must fulfill the deposit requirements before the change is implemented. The outgoing EA is paid all accumulated rewards immediately after the change occurs. * **Lenders:** Lenders, also known as Liquidity Providers, contribute capital to the pool and in return, earn a share of the pool's income proportional to their contribution. * **Borrowers:** Borrowers initiate credit requests with the pools. If a credit request is approved by the designated EA, they can draw down against it. They are responsible for making interest payments and, if required by the pool, a minimal principal payment per pay period. [PreviousCalendar](https://docs.huma.finance/products/huma-institutional/introduction/calendar) [NextTranches](https://docs.huma.finance/products/huma-institutional/tranches) Last updated 8 months ago * [Protocol-level Roles](https://docs.huma.finance/products/huma-institutional/introduction/admin-roles#protocol-level-roles) * [Pool-level Roles](https://docs.huma.finance/products/huma-institutional/introduction/admin-roles#pool-level-roles) --- # Calendar | Huma Businesses operate based on specific periods such as monthly, quarterly, or semi-annually. They prefer a fixed payment amount for each period, rather than one that fluctuates based on payment timing. Reducing the payment by a few cents due to earlier payment can create more complications than benefits. One common approach is using the 30/360 day-count convention, which deviates from the regular monthly calendar. Here's how it works: * Each year is divided into 12 equal months. This ensures that the yield generated each month is the same, regardless of whether the month has 31 or 28 days. * To calculate the number of days that have passed in a month, we use the lesser of the days passed, or 30. For instance, on the 10th of a month, it's 10, but on the 31st of a month, it's 30. * To figure out how many days remain in a month, we subtract the days passed from 30. For example, it's always 20 on the 10th of a month, whether it's February, March, or April. It drops to 0 on the 30th or 31st of the month. * Each quarter is treated as three 30-day months. * Each semi-annual period comprises six 30-day months. In the Permissioned contracts, the 30/360 day-count convention is used for most time-related calculations, including yield, late fees, and due date calculations for borrowers, as well as yield calculations in the `FixedSeniorTranchesPolicy` for lenders. The exceptions to this rule are the "withdrawal lockup period" and "default grace period", which are both counted in actual calendar days. All times are in UTC. [PreviousPool Types](https://docs.huma.finance/products/huma-institutional/introduction/pool-types) [NextAdmin Roles](https://docs.huma.finance/products/huma-institutional/introduction/admin-roles) Last updated 8 months ago --- # Redemption | Huma With both senior and junior tranches, we must protect seniors’ interests. We can't simply process redemption requests in the order they're submitted, as was done in V1. Instead, we'll batch these requests and process them at the end of an epoch, prioritizing senior redemptions. The epoch window will align with the pool’s payment period. [](https://docs.huma.finance/products/huma-institutional/tranches/redemption#redemption-requests-and-cancellation) Redemption Requests and Cancellation ------------------------------------------------------------------------------------------------------------------------------------------------------------ All lenders can submit redemption requests at no cost, but only those meeting the lockout period requirements will be accepted. Redemption requests can be canceled at no cost before the epoch starts to process them. [](https://docs.huma.finance/products/huma-institutional/tranches/redemption#epoch-processing-logic) Epoch Processing Logic -------------------------------------------------------------------------------------------------------------------------------- All accepted redemption requests within this epoch, plus requests rolled over from the previous epoch, determine which requests will be honored. Senior tranche requests are evaluated first, as senior redemption cannot breach the max senior-junior-ratio constraint. If there's enough liquidity, all senior redemptions can be accepted. If not, redemption requests will be handled pro rata, with the unfulfilled portion rolled over to the next epoch. If capital remains in the pool, junior redemption requests will be evaluated next. We ensure the max senior-junior-ratio is honored, meaning only the portion of redemption that is within the max threshold will be accepted. If there's insufficient liquidity to cover all junior redemption requests, they'll be handled on a pro-rata basis, with the unfulfilled portion rolled over to the next epoch. Two things to note: 1. The protocol sets a minimum threshold to prevent the need to split infinitesimal amounts among lenders. Consequently, redemption requests will only be processed if the pool's available balance exceeds this threshold. 2. The ratio at which redemption requests are honored is based on your requested shares, not the total shares you own. Although the latter is less susceptible to gaming, implementing it involves complexities. For efficiency considerations, redemption request processing is based on the total number of shares requested rather than scanning through individual lender's requests. However, to honor approved shares based on ownership, we would have to enumerate each lender's requests. For example, if lenders L1 and L2 each have 1000 shares, L1 requested 100 shares to redeem, L2 requested 200, and the epoch has 250 shares to distribute, there is no easy way to achieve the ideal distribution (100 shares to L1, 150 shares to L2) without iterating through each lender’s ownership. Therefore, we decided to honor redemption requests based on the number of requested shares. [](https://docs.huma.finance/products/huma-institutional/tranches/redemption#redeemed-fund-withdrawal) Redeemed Fund Withdrawal ------------------------------------------------------------------------------------------------------------------------------------ Once the redemption requests are fulfilled, the redeemed amount will be made available in the `TrancheVault` contract for withdrawal. You can then withdraw your funds through the DApp. If you are familiar with smart contracts, you can also call the `disburse()` function on the `TrancheVault` contract to withdraw your funds. [PreviousDeposit](https://docs.huma.finance/products/huma-institutional/tranches/deposit) [NextFirst Loss Covers](https://docs.huma.finance/products/huma-institutional/first-loss-covers) Last updated 8 months ago * [Redemption Requests and Cancellation](https://docs.huma.finance/products/huma-institutional/tranches/redemption#redemption-requests-and-cancellation) * [Epoch Processing Logic](https://docs.huma.finance/products/huma-institutional/tranches/redemption#epoch-processing-logic) * [Redeemed Fund Withdrawal](https://docs.huma.finance/products/huma-institutional/tranches/redemption#redeemed-fund-withdrawal) --- # Redemption | Huma Redeeming your position on Huma is straightforward, subject to committed lockup periods. [](https://docs.huma.finance/products/huma-2.0/redemption#no-lockup) **No Lockup** --------------------------------------------------------------------------------------- * You can **redeem anytime**, with no waiting period. * Redemption requests are processed on a **first-come, first-served** basis. * Most redemptions are completed **within 1 business day**, though it may take up to **7 days**, per our service-level agreement (SLA). [](https://docs.huma.finance/products/huma-2.0/redemption#locked-positions-3-month-or-6-month) **Locked Positions (3-Month or 6-Month)** --------------------------------------------------------------------------------------------------------------------------------------------- * Locked positions become redeemable **only after the lockup period ends**. * Once the lockup expires, your position behaves like a no-lockup position and can be redeemed anytime. * The same SLA applies: typically processed **within 1 business day**, with a maximum of **7 days**. [](https://docs.huma.finance/products/huma-2.0/redemption#daily-redemption-cap) **Daily Redemption Cap** ------------------------------------------------------------------------------------------------------------- To maintain protocol stability, Huma enforces a **global daily redemption cap**. This cap is configurable and resets daily at **00:00 UTC**. * Once the cap is reached, additional redemption requests for that day will be **rejected**. * A future update will introduce the ability to **submit capped redemptions with a fee**, allowing users to bypass the daily limit if needed. * **LPs can redeem instantly by swapping via the PST-USDC pool on Jupiter / Meteora**, as long as sufficient liquidity is available. These redemptions are not subject to Huma's Daily Redemption Cap. [PreviousReferral](https://docs.huma.finance/products/huma-2.0/referral) [NextIntegrations](https://docs.huma.finance/products/huma-2.0/integrations) Last updated 8 months ago --- # Integrations | Huma [](https://docs.huma.finance/products/huma-2.0/integrations#jupiter-meteora-integration) Jupiter / Meteora Integration --------------------------------------------------------------------------------------------------------------------------- To enable instant liquidity, a **PST-USDC pool** has gone live on **Jupiter and Meteora** alongside the launch of Huma 2.0. This Meteora pool serves as a core liquidity venue for PST, powering both spot swaps and deep integrations across the Solana DeFi ecosystem. Liquidity providers (LPs) can earn trading fees and participate in Huma's growth. The pool is designed for **minimal slippage** and a **smooth swap experience** for both PST holders and new participants. Huma has **seeded the pool with initial liquidity** and provide **incentives to attract additional LPs**. > ⚠️ When you swap PST tokens that are part of a locked position, the swapped portion will be treated as unlocked. Any extra $HUMA rewards earned through the lockup will be reverted accordingly. [](https://docs.huma.finance/products/huma-2.0/integrations#kamino-integration) Kamino Integration ------------------------------------------------------------------------------------------------------- **Huma has been integrated into Kamino**, enabling users to participate seamlessly across multiple yield opportunities. Users can provide liquidity in the **PST-USDC** and **mPST-USDC** vaults, or engage in the Huma Market in the following ways: * Supplying USDC or USDS. * Depositing PST. * Borrowing USDC or USDS against their deposited PST. * **Note:** Each wallet can either supply or borrow, but cannot do both. A **weekly $HUMA reward budget** is allocated to both the vaults and the Huma Market. Kamino calculates rewards and distributes them directly to participants. [](https://docs.huma.finance/products/huma-2.0/integrations#ratex-integration) RateX Integration ----------------------------------------------------------------------------------------------------- Huma’s current RateX integration enables Huma LPs to transform their PST into structured DeFi positions (PT/YT), enabling leverage, hedging, and more tailored yield strategies. Earn **2x Huma Feathers** across all YT/LP activities on RateX. The feathers will be converted to $HUMA tokens and distributed to the users. [PreviousRedemption](https://docs.huma.finance/products/huma-2.0/redemption) [NextUser Manuals](https://docs.huma.finance/products/huma-2.0/user-manuals) Last updated 2 months ago --- # Lenders | Huma On Huma, lenders earn a part of the pool's profit by providing liquidity. The Huma Insitutional protocol defines two tranche types for lenders: senior and junior. A pool might either have a two-tranche structure with both tranches active or a uni-tranche structure with only the junior tranche enabled. If you want to participate in both tranches in a pool where both are active, you must obtain separate approvals. [](https://docs.huma.finance/products/huma-institutional/user-manuals/lenders#lender-approval-and-removal) Lender Approval and Removal ------------------------------------------------------------------------------------------------------------------------------------------- Since all pools on the Huma protocol are permissioned, all lenders must get approval to join a pool. Here are the steps involved: 1. Pass the Know Your Customer (KYC)/Know Your Business (KYB) checks. This step is handled by Securitize. 2. Secure investor accreditation/qualification if required in your country/region of residence. This step is also handled by Securitize. 3. Sign legal documents specified by the Pool Owner, like the investor questionnaire and lender agreement. The exact documents you need to sign can vary based on the pool you're joining. 4. Get approval from the Pool Owner or Pool Operators. Pool Operators have the discretion to remove a lender. If removed, the lender can no longer supply additional liquidity to the pool. However, the lender’s existing funds will stay in the pool, continuing to generate yield, and can be requested to redeem at any time. For a detailed walkthrough of the process, refer to the [Step-by-step Guides](https://www.notion.so/Invoice-Financing-by-Request-Huma-72adb4cca5b042128395230b28dab668?pvs=21) section. [](https://docs.huma.finance/products/huma-institutional/user-manuals/lenders#pool-closure) Pool Closure ------------------------------------------------------------------------------------------------------------- Once a pool matures, the Pool Owner will close it, allowing you to withdraw your liquidity. Any pending redemption requests submitted prior to the pool's closure will be processed when the pool is shut down, regardless of the epoch schedule. The redeemed funds will then be available for withdrawal. You can use the DApp to withdraw all funds, which includes the redeemed amount and any remaining amounts in the pool not requested for redemption. If you're familiar with interacting with the contract directly, you can also invoke the `withdrawAfterPoolClosure()` function on `TrancheVault` contracts to withdraw all your funds. [PreviousUser Manuals](https://docs.huma.finance/products/huma-institutional/user-manuals) [NextBorrowers](https://docs.huma.finance/products/huma-institutional/user-manuals/borrowers) Last updated 8 months ago --- # Borrowers | Huma Borrowers are participants who seek financing from the Huma protocol. As a borrower, you must fulfill your obligations by making timely interest payments and, if required by the specific pool terms, make a minimum principal repayment each pay period. [PreviousLenders](https://docs.huma.finance/products/huma-institutional/user-manuals/lenders) [NextPayment](https://docs.huma.finance/products/huma-institutional/user-manuals/borrowers/payment) Last updated 8 months ago --- # User Manuals | Huma [Deposit](https://docs.huma.finance/products/huma-2.0/user-manuals/deposit) [Withdrawal](https://docs.huma.finance/products/huma-2.0/user-manuals/withdrawal) [Extending Lockup](https://docs.huma.finance/products/huma-2.0/user-manuals/extending-lockup) [Switching Modes](https://docs.huma.finance/products/huma-2.0/user-manuals/switching-modes) [Portfolio](https://docs.huma.finance/products/huma-2.0/user-manuals/portfolio) [Feathers](https://docs.huma.finance/products/huma-2.0/user-manuals/feathers) [$PST](https://docs.huma.finance/products/huma-2.0/user-manuals/pst) [Data Room](https://docs.huma.finance/products/huma-2.0/user-manuals/data-room) [PreviousIntegrations](https://docs.huma.finance/products/huma-2.0/integrations) [NextDeposit](https://docs.huma.finance/products/huma-2.0/user-manuals/deposit) Last updated 8 months ago --- # First Loss Covers | Huma While most pools on Huma will be backed by income or receivables, first loss covers will be used to partially or fully cover any losses from defaults when receivables are unenforceable. Such losses are covered before they are passed onto the lenders. Each pool can have up to 16 different forms of first-loss cover. The initial three types to be included are: * Extra collateral from the borrower. * Insurance - This option is listed for future consideration as the market is not yet prepared for comprehensive liquidity insurance. * A reserve fund provided by the Pool Owner and the Evaluation Agent. Participants who contribute capital to first loss covers are known as "First Loss Cover Providers." [](https://docs.huma.finance/products/huma-institutional/first-loss-covers#deposit-and-withdrawal) Deposit and Withdrawal ------------------------------------------------------------------------------------------------------------------------------ Before a pool can be enabled, First Loss Cover Providers must deposit a sufficient amount into their layer of the first loss cover. The sufficiency level is determined by the `minLiquidity` parameter in `PoolConfig`. Withdrawals are regulated by the `readyForFirstLossCoverWithdrawal` flag. Unless this flag is set to `true`, no withdrawals are allowed. Typically, this flag is only set to true after the pool has been closed. [](https://docs.huma.finance/products/huma-institutional/first-loss-covers#covering-loss) Covering Loss ------------------------------------------------------------------------------------------------------------ In the event of a default, the amount of loss covered by the first loss covers is calculated as the lesser of the `firstLossCoverCap` and the product of `firstLossCoverRate` and the `defaultAmount`, i.e. `min(defaultAmount * firstLossCoverRate, firstLossCoverCap)`. The order of loss coverage is the same as the order of the first loss covers listed above. That is, the borrower's extra collateral will be used first, followed by insurance, and finally, the reserve fund provided by the Pool Owner and EA. [](https://docs.huma.finance/products/huma-institutional/first-loss-covers#loss-recovery) Loss Recovery ------------------------------------------------------------------------------------------------------------ If a loss is initially declared and later fully or partially recovered, the recovered funds are distributed back to those who experienced losses. Distribution follows this order: the senior tranche first, then the junior tranche, and finally, the first loss covers. Note that the order of recovery is the opposite of the loss coverage order mentioned above. [](https://docs.huma.finance/products/huma-institutional/first-loss-covers#coverage-growth) Coverage Growth ---------------------------------------------------------------------------------------------------------------- Since the first loss cover capital is not deployed, it is unproductive. Typical coverage ranges from 2% to 10% and rarely exceeds this rate. We recognize that there are likely fewer defaults early in a pool's cycle, so there's no need for excessive coverage initially. Accordingly, we have a mechanism to grow first loss coverage over time. A pool cannot be enabled until the minimum coverage for all first loss covers is met. Afterward, the Huma protocol requires the yield produced by the first loss covers to be reinvested into the cover. Also, until the coverage reaches its maximum, all fees generated for the admins (Huma Protocol, Pool Owner, EA) are automatically deposited into the first loss cover. This strategy aligns the admins' interests with the success of the pool. [PreviousRedemption](https://docs.huma.finance/products/huma-institutional/tranches/redemption) [NextUser Manuals](https://docs.huma.finance/products/huma-institutional/user-manuals) Last updated 8 months ago --- # Deposit | Huma Depositing into Huma is easy and takes just a few steps. Choose your preferred **deposit mode** (Classic or Maxi), enter the amount you'd like to deposit, select a **lockup period** (or go with no lockup), and sign the transaction with your wallet. You'll instantly see your **estimated stable yield** and your **daily Huma Feather rewards** based on your selection. Once your deposit is confirmed, head to the **Portfolio** page to view your active positions and track when each **lockup period ends**. ![](https://docs.huma.finance/~gitbook/image?url=https%3A%2F%2F3505582914-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F6xrnZZGJOKGQIiYrafx3%252Fuploads%252Fgit-blob-351495468ee58eab4b21e2d2197005dd2feb6aac%252Fdeposit.gif%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=8ac278cf&sv=2) Deposit [PreviousUser Manuals](https://docs.huma.finance/products/huma-2.0/user-manuals) [NextWithdrawal](https://docs.huma.finance/products/huma-2.0/user-manuals/withdrawal) Last updated 8 months ago --- # User Manuals | Huma [Lenders](https://docs.huma.finance/products/huma-institutional/user-manuals/lenders) [Borrowers](https://docs.huma.finance/products/huma-institutional/user-manuals/borrowers) [Pool Admins](https://docs.huma.finance/products/huma-institutional/user-manuals/pool-admins) [PreviousFirst Loss Covers](https://docs.huma.finance/products/huma-institutional/first-loss-covers) [NextLenders](https://docs.huma.finance/products/huma-institutional/user-manuals/lenders) Last updated 8 months ago --- # Huma Institutional | Huma [](https://docs.huma.finance/ecosystem-resources/technical-docs/huma-institutional#autotasks) Autotasks ------------------------------------------------------------------------------------------------------------ The Huma protocol employs OpenZepplin's Autotasks to perform certain routine processes. There are four types of Autotasks, with each of them supporting a different aspect of the pool operation: ### [](https://docs.huma.finance/ecosystem-resources/technical-docs/huma-institutional#autopay-autotask) AutoPay Autotask * Fetch all credits with a due date in the next 2 days and the credit state is in `GoodStanding` or `Delayed`. * For each credit, if the borrower has enough funds in their wallet to cover the payment amount (`nextDue + totalPastDue`), and has approved enough allowance to the pool, call `makePayment` on behalf of the borrower to pay back the pool. ### [](https://docs.huma.finance/ecosystem-resources/technical-docs/huma-institutional#close-epoch-autotask) Close Epoch Autotask * Fetch all pools where the current epoch `endTime` is in the past. * Call `processYieldForLenders` on the junior and senior tranche. * Call `closeEpoch` on the epoch manager contract. * Call `investFeesInFirstLossCover` on the pool fee manager contract. * Call `payoutYield` on all first loss cover contracts of the pool. ### [](https://docs.huma.finance/ecosystem-resources/technical-docs/huma-institutional#refresh-credit-autotask) Refresh Credit Autotask * Fetch all credit lines where `nextBillRefreshDate` is in the past and credit state is in `GoodStanding` or `Delayed`. * Call `refreshCredit` on the credit manager contract for that borrower. ### [](https://docs.huma.finance/ecosystem-resources/technical-docs/huma-institutional#start-committed-credit-autotask) Start Committed Credit Autotask * Fetch all credit lines where credit state is `Approved`, committed amount is greater than 0, and the designated credit start date is in the past. * Call `startCommittedCredit` on the credit manager contract for that credit. ### [](https://docs.huma.finance/ecosystem-resources/technical-docs/huma-institutional#submit-redemption-request-autotask) Submit Redemption Request Autotask * Fetch all pools that has the `autoRedmeptionAfterLockUp` setting enabled. * For each pool, fetch all lenders whose deposit lockup period has expired. * Call `addRedemptionRequest` on the contract to submit redemption requests for all the shares owned by the lender. Unless otherwise noted, all Autotasks run every 5 minutes. For access control, Autotasks will call contracts using the Sentinel service account wallet. [PreviousHuma (2.0)](https://docs.huma.finance/ecosystem-resources/technical-docs/huma) [NextSmart Contracts](https://docs.huma.finance/ecosystem-resources/smart-contracts) Last updated 8 months ago --- # Pool Owner And Pool Operators | Huma Pool Owners are participants authorized by the Protocol Owner to create and manage pools. As a Pool Owner, you have the ability to set key parameters, select the Evaluation Agent, and define the fee structure through the Fee Manager. You may delegate some administrative tasks to chosen Pool Operators, such as approving and removing lenders or disabling the pool. [](https://docs.huma.finance/products/huma-institutional/user-manuals/pool-admins/pool-owner-operators#pool-configuration) Pool Configuration -------------------------------------------------------------------------------------------------------------------------------------------------- A significant aspect of the Pool Owner’s role is setting the various parameters of a pool before its launch and updating configurations as necessary when the pool evolves. You can find the complete list of pool parameters in the `PoolConfig` contract here (a link to the code will be provided upon the publication of the repo). The protocol provides default values for some parameters, but you must supply values for others before enabling the pool. **Pool Settings** * `maxCreditLine`: This refers to the maximum credit line for a borrower, which is measured in terms of pool tokens. * `minDepositAmount`: This is the minimum amount a lender or First Loss Cover provider must supply each time they deposit. It is also the absolute minimum balance the pool owner needs to maintain in tranches to prevent inflation attacks. * `payPeriodDuration`: This parameter refers to the number of months in a single payment period. * `latePaymentGracePeriodInDays`: This refers to the grace period, in days, before a late fee can be charged. * `defaultGracePeriodInDays`: This is the grace period, in days, before a default can be triggered. It can be 0. * `advanceRateInBps`: This specifies the maximum credit line as a percentage (in basis points) of the receivable amount. For example, for a receivable of $100 with an advance rate of 9000 basis points, the credit line can be up to $90. * `receivableAutoApproval`: This parameter indicates whether receivables should be automatically approved during the initial drawdown. If set to `false`, then receivables must be approved before the first drawdown. **AdminRnR Settings** These settings outline the responsibilities and rewards for pool administrators: * `rewardRateInBpsForEA`: The percentage of pool income allocated to EA. * `rewardRateInBpsForPoolOwner`: The percentage of pool income allocated to the Pool Owner. * `liquidityRateInBpsByEA`: The percentage of the `liquidityCap` contributed by the EA in the junior tranche. * `liquidityRateInBpsByPoolOwner`: The percentage of the `liquidityCap` contributed by the Pool Owner in the junior tranche. **Front Loading Fee Structures** * `frontLoadingFeeFlat`: This is a part of the platform fee, charged as a flat amount when borrowing occurs. * `frontLoadingFeeBps`: This is also a part of the platform fee, but it's charged as a percentage of the amount borrowed. **Fee Structures** * `yieldInBps`: This represents the expected blended yield for the entire pool in basis points. Please note that individual credits in the pool may have different yield rates, as approved by the Evaluation Agent. * `minPrincipalRateInBps`: This is the minimum percentage of the outstanding principal to be paid in each statement period. * `lateFeeBps`: This is the late fee rate, expressed in basis points. The late fee is an additional charge applied when a payment is late. It's calculated as a percentage of the total outstanding balance. **Tranche Configuration** The following configurations govern the tranches in a pool: * `liquidityCap`: This is the maximum amount of liquidity that can be deposited into the pool. The pool value may exceed this cap due to yield income. However, LPs cannot deposit more into the pool once the liquidity cap has been reached. * `maxSeniorJuniorRatio`: This is the maximum senior-to-junior asset ratio allowed. The senior assets cannot be more than the product of the junior assets and this ratio. A ratio of zero suggests a uni-tranche setup where only the junior tranche is enabled. * `fixedSeniorYieldInBps`: This is the fixed yield rate for the senior tranche. Pools using the `FixedSeniorYieldTranchesPolicy` must set this value and leave the risk adjustment rate setting at 0. * `tranchesRiskAdjustmentInBps`: This rate dictates how much profit will be shifted from the senior tranche to the junior tranche. Pools using the `RiskAdjustedTranchesPolicy` must set this value and leave the fixed senior yield rate setting at 0. * `withdrawalLockoutPeriodInDays`: This is the lockup period for lender withdrawal. Lenders cannot withdraw until this lockup period has passed after their most recent deposit. **First Loss Cover Configuration** The following configurations are supported for each layer of first loss cover: * `coverRatePerLossInBps`: This indicates the percentage of the defaulted asset covered by the first loss cover. * `coverCapPerLoss`: This is the maximum amount the first loss cover provides when a loss occurs. * `maxLiquidity`: This is the maximum amount for this first loss cover. Once this value is reached, no more coverage can be deposited into this layer of first loss cover. * `minLiquidity`: This is the minimum amount for this first loss cover. The pool cannot be enabled until this coverage is met. * `riskYieldMultiplierInBps`: This parameter is a weighting factor that helps establish the yield for the first loss cover. All layers of first loss covers share the yield with the junior tranche. The liquidity in each layer is multiplied by this risk yield multiplier, and the results are added together (the multiplier for the junior tranche is 10,000), resulting in the total capital participation in yield distribution. Keep in mind that the value of this parameter can either be higher or lower than 10,000, and in certain cases, it can be 0. For example, the borrower's cash collateral does not participate in the yield distribution, so the risk yield multiplier for this layer of first loss cover is set at 0. [](https://docs.huma.finance/products/huma-institutional/user-manuals/pool-admins/pool-owner-operators#first-loss-cover-and-tranche-liquidity-requirements) First Loss Cover and Tranche Liquidity Requirements -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Before a pool can be enabled, the Pool Owner must meet certain liquidity requirements in the tranches and the admin's first loss cover. More specifically: * Both the Pool Owner and Evaluation Agent must together deposit at least the amount outlined by the "min liquidity" parameter of the admin's first loss cover. * The Pool Owner is required to deposit at least the amount indicated by the "liquidity rate by pool owner" parameter into the junior tranche. * For a multi-tranche pool, the Pool Owner must also deposit at least the amount specified by the "min deposit amount" parameter, as a prevention measure against inflation attacks. [](https://docs.huma.finance/products/huma-institutional/user-manuals/pool-admins/pool-owner-operators#enabling-and-disabling-a-pool) Enabling and Disabling A Pool ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ The Pool Owner can enable a pool once all required parameters are set, and liquidity and first loss cover requirements are fulfilled. The pool is considered live and begins to accept lender deposits once enabled. Either the Pool Owner or Pool Operators can disable a pool. A pool may be disabled in the event of extraordinary circumstances, such as a default. Most contract functions will be disabled when the pool is disabled. For instance, the borrower can no longer draw down or make payments, and lenders cannot deposit or request redemptions. [](https://docs.huma.finance/products/huma-institutional/user-manuals/pool-admins/pool-owner-operators#lender-eligibility-management) Lender Eligibility Management ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ The eligibility of lenders to participate in the pool is managed by the Pool Operators as follows: * Adding lenders: Pool Operators review the KYC/KYB and accreditation results, as well as the legal documents signed by potential lenders. They can then add these individuals as approved lenders in the contract. During this process, Pool Operators decide whether the lender will receive automatic yield distributions or reinvest their yield back into the pool. * Removing lenders: Pool Operators also have the ability to remove lenders from a pool, preventing them from making additional deposits. * Setting the "reinvest yield" option: Pool Operators can adjust the "reinvest yield" setting for approved lenders. [](https://docs.huma.finance/products/huma-institutional/user-manuals/pool-admins/pool-owner-operators#pool-fee-management) Pool Fee Management ---------------------------------------------------------------------------------------------------------------------------------------------------- The Pool Owner, the Evaluation Agent, and the Protocol Owner all earn a portion of the pool yield as their income. The Pool Owner and Evaluation Agent's incomes are determined by the `rewardRateInBpsForPoolOwner` and `rewardRateInBpsForEA` parameters in `PoolConfig`, respectively, and can be controlled by the Pool Owner. The Protocol Owner's income is defined by the `protocolFeeInBps` parameter in `HumaConfig` and can only be set by the Huma protocol owner. [](https://docs.huma.finance/products/huma-institutional/user-manuals/pool-admins/pool-owner-operators#closing-a-pool) Closing A Pool ------------------------------------------------------------------------------------------------------------------------------------------ The Pool Owner is responsible for closing the pool after its maturity, allowing lenders and first loss cover providers to withdraw their funds without needing to submit redemption requests. This can be done by calling the `closePool()` function on the `Pool` contract. Before closing the pool, ensure that the yield is distributed to lenders by executing the `processYieldForLenders()` function in each `TrancheVault` contract. [PreviousPool Admins](https://docs.huma.finance/products/huma-institutional/user-manuals/pool-admins) [NextEvaluation Agent](https://docs.huma.finance/products/huma-institutional/user-manuals/pool-admins/evaluation-agent) Last updated 8 months ago --- # Payment | Huma [](https://docs.huma.finance/products/huma-institutional/user-manuals/borrowers/payment#day-based-calculation) Day-Based Calculation ----------------------------------------------------------------------------------------------------------------------------------------- The Huma protocol employs a day-based calculation approach when determining yield, fees, and principal due. This is different from V1, where a second-based approach was used. This means it counts the total number of days elapsed since the last due amounts were computed. An important aspect of this method is that it always rounds up to the start of the next day, regardless of when in the current day the calculation occurs. [](https://docs.huma.finance/products/huma-institutional/user-manuals/borrowers/payment#late-payment-grace-period) Late Payment Grace Period ------------------------------------------------------------------------------------------------------------------------------------------------- Each pool can set a late payment grace period, typically 5 days. Payments made within the grace period after the due date are considered on time. This setting is referred to as `latePaymentGracePeriod` in the `poolConfig`. During this period, further drawdowns are not permitted. [](https://docs.huma.finance/products/huma-institutional/user-manuals/borrowers/payment#no-refunds-for-early-payment) No Refunds for Early Payment ------------------------------------------------------------------------------------------------------------------------------------------------------- In V1, if part of the principal was paid before the due date, the yield related to the unused days for the repaid principal portion was refunded to the borrower. This is because the capital was not employed during those days. However, this is not desirable for business lending as the capital will be idle in the pool. Therefore, the Permissioned protocol will not provide a refund if the borrower makes early repayment. [](https://docs.huma.finance/products/huma-institutional/user-manuals/borrowers/payment#simplified-yield-calculation) Simplified Yield Calculation ------------------------------------------------------------------------------------------------------------------------------------------------------- V1 used a compound yield calculation. If an account was late, all due amounts were added to the principal, and the updated principal was used to compute the due for the next period. This added complexity. In V2, we use a simpler yield calculation, more common in business lending. If an account is late, we simply apply the late payment fee, do not adjust the principal, and use the existing principal to calculate the yield for the next period. [](https://docs.huma.finance/products/huma-institutional/user-manuals/borrowers/payment#principal-payment-only) Principal Payment Only ------------------------------------------------------------------------------------------------------------------------------------------- Usually, when a payment is made, it is first applied to late fees and yield due before being applied to the principal. In special cases, the borrower may wish to pay towards the principal first to demonstrate their ability to make more frequent payments than the typical monthly basis. While this is not common in today's business, in the RWA world, some borrowers want to show that their receivables are indeed short-duration as claimed and opt to make principal payments before the due date. [](https://docs.huma.finance/products/huma-institutional/user-manuals/borrowers/payment#making-principal-payment-and-drawdown-in-one-transaction) Making Principal Payment and Drawdown in One Transaction --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Similar to the above, the borrower may wish to make a payment to show they have the necessary capital and then borrow again for a new transaction. To save time and gas fees for the borrower, these two actions can be combined into one transaction. [](https://docs.huma.finance/products/huma-institutional/user-manuals/borrowers/payment#late-fee-calculation) Late Fee Calculation --------------------------------------------------------------------------------------------------------------------------------------- If an account is late (after the late payment grace period), a late payment fee will be charged. This fee is in addition to the regular interest due for all the outstanding principal. The additional charge is calculated using: $\\frac{Pincipal \\times LateFeeInBps \\times NumberOfDaysBeingLate}{360}$. For instance, if an account with an outstanding principal of $10,000 and an APR of 12% has a `lateFeeInBps` of 18%, the actual charge on the borrower is an annualized 30% for the days when the account is late. It is charged daily to encourage the borrower to pay back as soon as possible. [](https://docs.huma.finance/products/huma-institutional/user-manuals/borrowers/payment#front-loading-fee-calculation) Front-Loading Fee Calculation --------------------------------------------------------------------------------------------------------------------------------------------------------- At the origination of a loan, the borrower may be charged a front-loading fee, also known as an origination fee. This fee is usually a combination of a percentage of the principal amount and a fixed fee. The `frontLoadingFeeFlat` parameter defines the fixed fee, and the `frontLoadingFeeBps` parameter defines the percentage of the principal to be charged. For example, if `frontLoadingFeeFlat = $2,000`, and `frontLoadingFeeBps = 100`. For a loan of $100K, the front-loading fee will be: $$2,000 + $100K \\times 100/10,000 = $2,000 + $1,000 = $3,000$. [PreviousBorrowers](https://docs.huma.finance/products/huma-institutional/user-manuals/borrowers) [NextLoan Management](https://docs.huma.finance/products/huma-institutional/user-manuals/borrowers/loan-management) Last updated 8 months ago --- # Withdrawal | Huma If your funds aren't locked up, you can redeem them anytime. However, if your funds are committed to a lockup, you can only redeem them once the lockup period ends. **Request Processing** Redemption requests are handled on a first-come, first-served basis. We aim to process most redemptions within 1 business day, although it may take up to 7 days. **Request Submission Gating** Please note that we stop accepting redemption requests once daily submissions (from 00:00 to 00:00 UTC on the next day) reach the daily redemption limit. **Fund Disbursement** Once your redemption request is processed, the smart contract will automatically transfer your funds directly to the wallet you used for your deposit. In the rare event that the transfer fails, your funds will remain safely in the pool, and you can manually claim them from the Portfolio page. ![](https://docs.huma.finance/~gitbook/image?url=https%3A%2F%2F3505582914-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F6xrnZZGJOKGQIiYrafx3%252Fuploads%252Fgit-blob-03787be0fffc9a4ae8df1c2c9680a98314a3e43b%252Fwithdrawal.gif%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=dd89117f&sv=2) Withdrawal [PreviousDeposit](https://docs.huma.finance/products/huma-2.0/user-manuals/deposit) [NextExtending Lockup](https://docs.huma.finance/products/huma-2.0/user-manuals/extending-lockup) Last updated 8 months ago --- # Pool Admins | Huma Pool Admins comprise the Pool Owner, the Pool Operators, and the Evaluation Agent. The role involves performing several administrative tasks to ensure the efficient operation of the pool. These tasks are outlined below. [PreviousFAQs](https://docs.huma.finance/products/huma-institutional/user-manuals/borrowers/faqs) [NextPool Owner And Pool Operators](https://docs.huma.finance/products/huma-institutional/user-manuals/pool-admins/pool-owner-operators) Last updated 8 months ago --- # FAQs | Huma [PreviousLoan Management](https://docs.huma.finance/products/huma-institutional/user-manuals/borrowers/loan-management) [NextPool Admins](https://docs.huma.finance/products/huma-institutional/user-manuals/pool-admins) Last updated 8 months ago --- # Loan Management | Huma ### [](https://docs.huma.finance/products/huma-institutional/user-manuals/borrowers/loan-management#loan-management) Loan Management As a borrower in a pool, the three most important actions you can perform are: * Obtaining credit approval * Initiating a drawdown * Making payments, either by enabling AutoPay or repaying manually ### [](https://docs.huma.finance/products/huma-institutional/user-manuals/borrowers/loan-management#getting-approved) Getting Approved **Borrower Approval** You must obtain credit approval from the Evaluation Agent of the pool before drawing down. The terms of a credit include: * Credit limit: This is the maximum borrowing amount. The credit limit cannot exceed 4 billion of the underlying asset (stablecoin) of the pool. * Duration: This is the loan duration, given in payment periods. Duration can be monthly, quarterly, or semi-annually. * Yield APR: This is the annualized percentage rate of the credit. It determines the yield due for each payment period. * Late fee APR: This is the pool-level setting that decides the amount of the late fee. If a payment is late, this fee is charged in addition to the regular yield charge. Like yield, it's an annualized rate. * Minimum principal rate: This pool-level setting determines the amount of principal payment due each payment period. It's a per-payment-period rate. For example, a 10% minimum principal rate means 10% of the principal must be repaid at the end of each payment period. * Committed loan amount: This is the amount the borrower pledges to borrow. Yield will be charged on this amount if the outstanding principal balance is below it. * Designated start date: This marks the commencement of the credit term. Borrowing is disallowed before this date and interest starts accumulating from this point forward. * Revolving: This indicates whether the borrower can reuse the credit after repaying a portion of the principal. For instance, if the approved credit is $1,000, the borrower has taken out $500, and $400 is repaid, the remaining credit will be $500 for non-revolving credit and $900 for revolving credit. Depending on the pool you are borrowing from, you may also need to sign legal agreements off-chain with the Pool Owner. **Receivable Approval** If you're borrowing from a Receivable-backed Credit Line pool that doesn't have receivable auto-approval, you'll need to get your receivables approved by the EA before you can use them for drawdown. However, for pools with receivable auto-approval, receivables will be automatically approved during the drawdown process, hence no manual approval would be required. ### [](https://docs.huma.finance/products/huma-institutional/user-manuals/borrowers/loan-management#drawdown) Drawdown Once your credit request is approved, you can begin the drawdown process, either through the DApp or by interacting directly with the contract to initiate the drawdown. The specific function you call depends on the type of pool you're borrowing from: * For Revolving Credit Line pools, use the `drawdown()` function in the `CreditLine` contract. * For Receivable-backed Credit Line pools, use the `drawdownWithReceivable()` function in the `ReceivableBackedCreditLine` contract. Don't forget to provide the receivable NFT token ID for drawdown. * For Receivable-factoring Credit pools, use the `drawdownWithReceivable()` function in the `ReceivableFactoringCredit` contract. Remember to supply the receivable NFT token ID for drawdown. For the last two types of pools, you'll give up your ownership of the receivable during drawdown. Ensure that you have authorized the `ReceivableBackedCreditLine` or the `ReceivableFactoringCredit` contract to perform the transfer from you. You may also use the SDK to draw down. See the [Using the SDK](https://docs.huma.finance/products/huma-institutional/user-manuals/borrowers/loan-management#using-the-sdk) section for more details. ### [](https://docs.huma.finance/products/huma-institutional/user-manuals/borrowers/loan-management#making-payment) Making Payment At the end of each period, you need to pay the total amount due. This includes any due yield, the principal if the pool requires a minimum principal payment per period, and any late fees if you've missed past payments. You can either enable AutoPay to automatically deduct the full amount due from your wallet, or you can manually pay it back through the DApp, SDK, or by interacting directly with the contract. **AutoPay** AutoPay can be enabled in the DApp on the pool details page, and requires signing a one-time transaction. You can enable AutoPay either through the borrower card section, or while drawing down from the pool: ![](https://docs.huma.finance/~gitbook/image?url=https%3A%2F%2Fgithub.com%2F00labs%2Fhuma-monorepo%2Fblob%2Fgitbook%2F0_doc%2F2.0-docs%2Fproducts%2Fhuma-institutional%2Fuser-manuals%2Fimages%2Fborrowers%2Fturn-on-autopay.png&width=768&dpr=4&quality=100&sign=f520ead&sv=2) Turn on AutoPay Under the hood, AutoPay works by approving the max allowance of the underlying token to the pool contract. While AutoPay is enabled, the pool will attempt to pull the total amount due from your wallet once a period ends. If the funds are not immediately available in your wallet, AutoPay will monitor and attempt to pay back once they are. AutoPay will check and attempt to pay every five minutes. If you have the appropriate amount of funds available and AutoPay is not working, please contact us or proceed with Manual Payment below. **Manual Payment** You have the option to make manual payments at any point during the period, even if AutoPay is enabled, although no refund for yield due will be given for early payments. The easiest way is to use the DApp. Alternatively, you can call contract functions directly to execute payments. The specific function you need to call will depend on the type of pool from which you're borrowing: * For Revolving Credit Line pools, use the `makePayment()` function in the `CreditLine` contract. * For Receivable-backed Credit Line pools, use the `makePaymentWithReceivable()` function in the `ReceivableBackedCreditLine` contract. You'll need to provide the receivable NFT token ID that you previously used for drawdown. * For Receivable-factoring Credit pools, use the `makePaymentWithReceivable()` function in the `ReceivableFactoringCredit` contract. Again, you'll need to provide the receivable NFT token ID that you previously used for drawdown. If you specify a payment amount that exceeds the payoff amount on the receivable, the contract will only collect the due amount and the remaining funds will be left untouched. Keep in mind that the pool will maintain ownership of the receivable NFT, even after it's paid off. You can also utilize the SDK to make repayments. Refer to the [Using the SDK](https://docs.huma.finance/products/huma-institutional/user-manuals/borrowers/loan-management#using-the-sdk) section for more information. ### [](https://docs.huma.finance/products/huma-institutional/user-manuals/borrowers/loan-management#credit-closure) Credit Closure Your credit will automatically be closed once it's paid off and has passed its maturity date. You also have the option to close a credit early, before its maturity date, provided the following conditions are met: * The outstanding balance on the credit has been paid off. This includes the amount due next, any past due amounts, and the outstanding principal. * There is no committed amount on a credit that has already started. You can also close a credit that's been approved but not started and has an outstanding commitment. ### [](https://docs.huma.finance/products/huma-institutional/user-manuals/borrowers/loan-management#using-the-sdk) Using the SDK The Huma SDK provides utilities for interacting with protocol contracts, along with various on-chain and off-chain data storage. It enables you to programmatically perform the borrowing-related actions described above. Download the SDK as an NPM package [here](https://www.npmjs.com/package/@huma-finance/sdk) . You can find the SDK's code in [this Github repo](https://github.com/00labs/huma-js/tree/develop/packages/huma-sdk) . [PreviousPayment](https://docs.huma.finance/products/huma-institutional/user-manuals/borrowers/payment) [NextFAQs](https://docs.huma.finance/products/huma-institutional/user-manuals/borrowers/faqs) Last updated 8 months ago --- # Security & Audits | Huma At Huma, robust security is embedded at every layer—from smart contracts and backend systems to user interfaces and internal operations—ensuring LPs can participate with confidence. [](https://docs.huma.finance/ecosystem-resources/security-audits#minimized-admin-rights) **Minimized Admin Rights** ------------------------------------------------------------------------------------------------------------------------ All administrative functions are secured with multisigs, so no single party can act alone. Our smart contracts are specifically engineered to allow admin control over the protocol treasury while preventing access to user funds. This design offers optimal protection for LP funds: even if a multisig were ever compromised, attackers would be unable to access user assets. [](https://docs.huma.finance/ecosystem-resources/security-audits#top-tier-audits) **Top-Tier Audits** ---------------------------------------------------------------------------------------------------------- Before any major update goes live on mainnet, it undergoes a comprehensive audit. Our contracts are rigorously reviewed by leading security firms across multiple ecosystems: * **Solana** programs audited by **Halborn** ↳ _\[_[_Huma 2.0 Audit Report_](https://www.halborn.com/audits/huma-finance/solana-programs-060022)\ _\]_ ↳ _\[_[_Huma Permissioned Audit Report_](https://www.halborn.com/audits/huma/huma-protocol)\ _\]_ * **EVM** smart contracts audited by **Spearbit** ↳ _\[_[_Audit Report 1_](https://github.com/00labs/huma-contracts-v2/blob/develop/audit/spearbit.pdf)\ _\]_ ↳ _\[_[_Audit Report 2_](https://github.com/00labs/huma-contracts-v2/blob/develop/audit/spearbit-incremental-Nov-2024.pdf)\ _\]_ * **Stellar** contracts audited by **Certora** ↳ _\[_[_Audit Report_](https://certora.cdn.prismic.io/certora/Z0dE1pbqstJ971DG_HumaCertoraAuditReport.pdf)\ _\]_. We also maintain an active **bug bounty program** in collaboration with **Spearbit/Cantina** to encourage ongoing white-hat reviews. [](https://docs.huma.finance/ecosystem-resources/security-audits#infrastructure-and-operational-security) **Infrastructure & Operational Security** -------------------------------------------------------------------------------------------------------------------------------------------------------- Security doesn't stop at smart contracts. We've implemented strong protection across our infrastructure and team operations: * **End-to-end penetration testing** of backend systems * **Device-level monitoring and endpoint protection** (EDR + DM) for all team members At Huma, we are committed to continuously enhancing our security posture as the protocol evolves, ensuring a secure environment for all participants. [PreviousSmart Contracts](https://docs.huma.finance/ecosystem-resources/smart-contracts) [NextLegal](https://docs.huma.finance/ecosystem-resources/legal) Last updated 8 months ago --- # Technical Docs | Huma [Huma (2.0)](https://docs.huma.finance/ecosystem-resources/technical-docs/huma) [Huma Institutional](https://docs.huma.finance/ecosystem-resources/technical-docs/huma-institutional) [PreviousECOSYSTEM RESOURCES](https://docs.huma.finance/ecosystem-resources) [NextHuma (2.0)](https://docs.huma.finance/ecosystem-resources/technical-docs/huma) Last updated 8 months ago --- # Evaluation Agent | Huma The Evaluation Agent plays the role of the underwriter for the pool, performing several crucial credit-related tasks. These include: * Reviewing and approving credit requests * Declaring default when the borrower fails to repay * Restructuring credits by updating the APY, credit limit, waiving late fees, etc. [](https://docs.huma.finance/products/huma-institutional/user-manuals/pool-admins/evaluation-agent#credit-approval) Credit Approval ---------------------------------------------------------------------------------------------------------------------------------------- As the Evaluation Agent of a pool, your responsibilities include reviewing credit requests submitted by borrowers and determining their eligibility to borrow from the pool. If deemed eligible, you must decide on the exact terms of the credit, which includes: * **Credit limit**: This is the maximum borrowing amount. The credit limit cannot exceed 4 billion of the underlying asset (stablecoin) of the pool. * **Duration**: This is the loan duration, given in payment periods. Duration can be monthly, quarterly, or semi-annually. * **Yield APR**: This is the annualized percentage rate of the credit. It determines the yield due for each payment period. * **Late fee APR**: This is the pool-level setting that decides the amount of the late fee. If a payment is late, this fee is charged in addition to the regular yield charge. Like yield, it's an annualized rate. * **Minimum principal rate**: This pool-level setting determines the amount of principal payment due each payment period. It's a per-payment-period rate. For example, a 10% minimum principal rate means 10% of the principal must be repaid at the end of each payment period. * **Committed loan amount**: This is the amount the borrower pledges to borrow. Yield will be charged on this amount if the outstanding principal balance is below it. * **Designated start date**: This marks the commencement of the credit term. Borrowing is disallowed before this date and interest starts accumulating from this point forward. * **Revolving**: This indicates whether the borrower can reuse the credit after repaying a portion of the principal. For instance, if the approved credit is $1,000, the borrower has taken out $500, and $400 is repaid, the remaining credit will be $500 for non-revolving credit and $900 for revolving credit. If you are the EA for a Receivable-backed Credit Line or Receivable Factoring Credit pool, you will also be responsible for evaluating the quality of receivables submitted by the borrower. This evaluation determines whether the receivables can be used for drawdown. [](https://docs.huma.finance/products/huma-institutional/user-manuals/pool-admins/evaluation-agent#default-trigger) Default Trigger ---------------------------------------------------------------------------------------------------------------------------------------- If it becomes apparent that the borrower will not be able to repay their obligations in full within a reasonable timeframe after a late payment, you have the authority to declare a default on the credit. This action will realize losses and initiate the loss distribution process. If the pool has established a default grace period, you can only declare default after this grace period, which begins after the due date of the borrower's first missed payment. [](https://docs.huma.finance/products/huma-institutional/user-manuals/pool-admins/evaluation-agent#restructuring-credit) Restructuring Credit -------------------------------------------------------------------------------------------------------------------------------------------------- There are a few actions available for restructuring credit: * **Updating the yield APY**: You have the option to update the yield APY of an active credit. However, the update will not be immediate. It will take effect either at the start of a new pay period when the credit is refreshed or when the borrower makes another drawdown, whichever occurs first. * **Updating the credit limit and/or committed amount**: You can also adjust the credit limit and/or committed amount of an active credit. If you need to prevent the borrower from making further drawdowns due to unfulfilled obligations, set the credit limit to 0. This update will also not be immediate and will take effect in the same manner as updating the yield APY. Note that changes may affect the yield due for the borrower if the relationship between the outstanding principal and the committed amount changes after the update. * **Extending the number of remaining periods**: You can lengthen the number of remaining periods for a credit in good standing. If the credit is in its final period where all principal is due, the borrower remains responsible for the full principal payment. * **Waiving late fees**: You have the ability to waive late fees on a credit. If the waived amount exceeds the late fees accrued on the credit, only the actual amount will be waived. [](https://docs.huma.finance/products/huma-institutional/user-manuals/pool-admins/evaluation-agent#credit-closure) Credit Closure -------------------------------------------------------------------------------------------------------------------------------------- A borrower’s credit will automatically be closed once it's paid off and has passed its maturity date. You also have the ability to close a credit early, before its maturity date, provided the following conditions are met: * The outstanding balance on the credit has been paid off. This includes the amount due next, any past due amounts, and the outstanding principal. * There is no committed amount on a credit that has already started. You can also close a credit that's been approved but not started and has an outstanding commitment. [](https://docs.huma.finance/products/huma-institutional/user-manuals/pool-admins/evaluation-agent#first-loss-cover-and-tranche-liquidity-requirements) First Loss Cover and Tranche Liquidity Requirements ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Like the Pool Owner, the EA is also subject to liquidity requirements, but they are generally less stringent: * The Pool Owner and EA must collectively deposit at least the amount specified by the `minLiquidity` parameter of the admin's first loss cover. * The EA must deposit at least the amount specified by the `liquidityRateInBpsByEA` parameter into the junior tranche. [PreviousPool Owner And Pool Operators](https://docs.huma.finance/products/huma-institutional/user-manuals/pool-admins/pool-owner-operators) [NextECOSYSTEM RESOURCES](https://docs.huma.finance/ecosystem-resources) Last updated 8 months ago --- # Legal | Huma [Terms of Service and Privacy Policy](https://app.huma.finance/terms-of-service) [PayFi Strategy Memorandum](https://agreement.huma.finance/PayFi_Strategy_Memorandum_(PSM).pdf) [PreviousSecurity & Audits](https://docs.huma.finance/ecosystem-resources/security-audits) Last updated 8 months ago --- # Huma (2.0) | Huma Huma is powered by a robust blend of on-chain and off-chain components that work seamlessly to deliver a secure, efficient experience: * **Solana Program** The core engine driving our permissionless liquidity pools and executing all essential business logic. * **Decentralized App (dApp) Frontend** Your primary interface for interacting with Huma. * **Web2 Services** Auxiliary systems that support Huma Feathers allocation and account management. * **Price Oracle** A dedicated service that tracks the price of $PST in real time. * **Off-chain Autotasks** Automated tasks that manage various operational functions within the pools. **Price Oracle** The Price Oracle continuously monitors and tracks the price of $PST, ensuring accurate and up-to-date data for all protocol operations. **Autotasks** Two primary autotasks power our pool operations: * **Redemption Request Processing Job** This job is responsible for: * Canceling redemption requests that violate lockup requirements. * Processing redemption requests in an all-or-nothing manner—if the pool lacks sufficient funds to cover a request in full, processing will pause until enough funds are available. * **Price Oracle Refresh Job** Regularly updates the Price Oracle to ensure the data remains current. Together, these components form the backbone of the Huma protocol, delivering a secure, efficient, and user-friendly experience. [PreviousTechnical Docs](https://docs.huma.finance/ecosystem-resources/technical-docs) [NextHuma Institutional](https://docs.huma.finance/ecosystem-resources/technical-docs/huma-institutional) Last updated 8 months ago --- # Smart Contracts | Huma [](https://docs.huma.finance/ecosystem-resources/smart-contracts#solana) Solana ------------------------------------------------------------------------------------ ### [](https://docs.huma.finance/ecosystem-resources/smart-contracts#program-addresses) Program Addresses Program Address Huma HumaXepHnjaRCpjYTokxY4UtaJcmx41prQ8cxGmFC5fn Huma Institutional EVQ4s1b6N1vmWFDv8PRNc77kufBP8HcrSNWXQAhRsJq9 ### [](https://docs.huma.finance/ecosystem-resources/smart-contracts#account-addresses) Account Addresses Account Address PST Mint 59obFNBzyTBGowrkif5uK7ojS58vsuWz3ZCvg6tfZAGw mPST Mint HUPfpnsaJtJGpJxAPNX1vXah7BgYiQYt1c2JMgMumvPs [](https://docs.huma.finance/ecosystem-resources/smart-contracts#evm) EVM ------------------------------------------------------------------------------ ### [](https://docs.huma.finance/ecosystem-resources/smart-contracts#github-repo) GitHub Repo [Codebase](https://www.notion.so/Huma-2-0-Gitbook-f63276eed2c346f99a4689ebd2873737?pvs=21) ### [](https://docs.huma.finance/ecosystem-resources/smart-contracts#contract-addresses) Contract Addresses Pool Contract Name Contract Address Arf 3-month Pool PoolConfig 0xebf8D31C5492Dc93FC73a6AD136d47c45AB2C7a5 JuniorTranche 0x483D02C11f8F1E31C267040A6C86AaB80c428BaB PoolSafe 0x7F4f55fAeE753D8dbB3E5F04861dB38E9DB70c3D SeniorTranche 0x4cdCedcF50266aD9ed809048BC9874320EC902bC CreditManager 0x061411d05074Bc974f814AC86309D2204f4c265d Credit 0xc6F10af4746784a0DD095f4E5718d53ff94eB4a0 Arf 6-month Pool PoolConfig 0xE9D7893B52BE6D81C540f2E81f3A65FAbF8A0fa4 JuniorTranche 0x8413a7345cD8bF8Afe8c2EfE866a764A93B305e2 PoolSafe 0xD6C357c40731a1F57173231eeeAb004eD8baE9b6 SeniorTranche 0xDe5eD603A376B93817b9656AF6E373218fD9b2bd CreditManager 0xbC015F64b023d8B351484342d35dA0AF0d42a9de Credit 0x2e3A03C8Bd31300C2c027C9C9d1b762677F6FaA6 [](https://docs.huma.finance/ecosystem-resources/smart-contracts#stellar) Stellar -------------------------------------------------------------------------------------- Contract Name Address ContractFactory CBQHYENQ7ANK5UEUOGEL5CMLZV3LUPS4IVR3EHXMMVYQTNMFOGPTLXBC HumaConfig CAXZGMU3EHOHGXGXDJWVPG5PIVC2DCZQ2JO2YI3RGSM4OQK7ZIQ46FV5 PoolStorage CAADAYJOZF5HXPVZXBXA3PLCU7OSRW34OKVXG2676KAGZVZBI6EYQ73L PoolManager CBFX4CMIWVOVFTJCRC5BYTBOXBZVJXNUI2D5UWM6WP4J2VBXRFYV4YQC Pool CDVJY4NLTSKNLHO2JIRKDERE366WYG3OSJY42VOLI7DBAX4X5Q2BY75O CreditStorage CCXOG76F7A67FHR5OVJPGUVLHF55VOYJZADWEQDDMVLR66R3ODNRAIEP CreditManager CBX7MQGXQN6DHGDDRARUH266PIIDTFB5H5HVFPFL365V2JJPX2OWZOZT Credit CC34OGI32WJDSGFES3HWSETSKPN5BQLDEYFHFTDVTUEL2HZLJG5M2UAJ JuniorTranche CDJ6AO57ZWBIDITDN32URXYQY6MTSFBNF6OFOCENRDE2MUB67UZKLKDP SeniorTranche CDJ6AO57ZWBIDITDN32URXYQY6MTSFBNF6OFOCENRDE2MUB67UZKLKDP [PreviousHuma Institutional](https://docs.huma.finance/ecosystem-resources/technical-docs/huma-institutional) [NextSecurity & Audits](https://docs.huma.finance/ecosystem-resources/security-audits) Last updated 8 months ago * [Solana](https://docs.huma.finance/ecosystem-resources/smart-contracts#solana) * [Program Addresses](https://docs.huma.finance/ecosystem-resources/smart-contracts#program-addresses) * [Account Addresses](https://docs.huma.finance/ecosystem-resources/smart-contracts#account-addresses) * [EVM](https://docs.huma.finance/ecosystem-resources/smart-contracts#evm) * [GitHub Repo](https://docs.huma.finance/ecosystem-resources/smart-contracts#github-repo) * [Contract Addresses](https://docs.huma.finance/ecosystem-resources/smart-contracts#contract-addresses) * [Stellar](https://docs.huma.finance/ecosystem-resources/smart-contracts#stellar) ---