# ABOUT HUMA # What is 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. # Why 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. # Key Resources 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: Dune: # ANNOUNCEMENTS We're excited to announce the launch of Huma Prime - an innovative looping strategy vault - leveraging the yield from Huma Classic, $PST. It’s built on Huma’s Defensive Looping technology. Defensive Looping is a protected leverage strategy designed to augment yields on yield-bearing assets while mitigating the "death spiral" risks inherent in conventional looping in DeFi. It combines recursive borrowing with three primary layers of protection: * Automated leverage or deleverage based on supply and borrow rates in DeFi markets. * Primary-market redemptions to substantially reduce liquidations driven by potential depegs in secondary markets. * Isolated reserve mechanisms (coming soon) to buffer against asset impairments. The DeFi industry needs better risk management products, to create better yield markets. Huma Prime is one of the many innovative products we plan to launch in this category. # PRODUCTS # Huma (2.0) # Overview 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. ## 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. # Feathers **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**. # Modes: Classic vs Maxi 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 | 8% APY\* | $ | Yield maxis | PST | | Maxi | 0% APY | $$$$$ | Huma maxis | mPST | \*Subject to monthly adjustments based on market conditions. # Lockup 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. ## **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**. # Referral 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. ## 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. ## 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! # Redemption Redeeming your position on Huma is straightforward, subject to committed lockup periods. ## **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). ## **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**. ## **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. # Integrations ## 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. ## 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. ## 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. # User Manuals # Deposit 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**. ![Deposit](/files/ExkFY4R737a1Hep8NICn) # Withdrawal 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. ![Withdrawal](/files/YYLPrYvsXPMCgLfDaNsB) # Extending Lockup 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. ![Extending Lockup](/files/Dpd6glSDQIDLNmfyTgKg) # Switching Modes 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. ![Switching Mode](/files/FdQwx7BsmU92YukvwVrY) # Portfolio 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. ![Portfolio](/files/pd3nrqVGHAH1wQwxeAvd) # Feathers 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! ![Feathers & Leaderboard](/files/KlajDceWVSe50zfBJMfx) # $PST Here, you can access key DeFi composability features, such as swapping PST for USDC via Jupiter and borrowing USDC through Kamino. ![PST](/files/1QzTiEw0lOaQ6HSgpzQh) # Data Room This page displays key protocol and product statistics alongside links to essential documents and resources. ![Data Room](/files/ajdBVNUUhe4vQgl1HysF) # FAQs Please see the [FAQs](https://app.huma.finance/faqs) on the dApp. # Huma Institutional # Introduction # Overview 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. # Pool Types ## 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. ## 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. ## Receivable Factoring Credit The borrower can factor a receivable by receiving an advance payment, which is a percentage of the invoice amount. # Calendar 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. # Admin 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. ## 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. # Tranches 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. # P\&L 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. ## 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. # Deposit Deposits are accepted on a first-come, first-served basis until the pool liquidity cap is reached. ## 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. ## 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. ## 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. # Redemption 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. ## 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. ## 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. ## 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. # First Loss Covers 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." ## 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. ## 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. ## 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. ## 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. # User Manuals # Lenders 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. ## 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. ## 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. # Borrowers 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. # Payment ## 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. ## 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. ## 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. ## 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. ## 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. ## 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. ## 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. ## 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$. # 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 ### 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. ### 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](#using-the-sdk) section for more details. ### 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: ![Turn on AutoPay](https://github.com/00labs/huma-monorepo/blob/gitbook/0_doc/2.0-docs/products/huma-institutional/user-manuals/images/borrowers/turn-on-autopay.png) 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](#using-the-sdk) section for more information. ### 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. ### 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). # FAQs # Pool Admins 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. # Pool Owner And Pool Operators 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. ## 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. ## 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. ## 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. ## 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. ## 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. ## 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. # Evaluation Agent 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. ## 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. ## 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. ## 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. ## 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. ## 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. # ECOSYSTEM RESOURCES # Technical Docs # Huma (2.0) 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. # Huma Institutional ## 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: ### 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. ### 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. ### 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. ### 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. ### 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. # Smart Contracts ## Solana ### Program Addresses | Program | Address | | ------------------ | -------------------------------------------- | | Huma | HumaXepHnjaRCpjYTokxY4UtaJcmx41prQ8cxGmFC5fn | | Huma Institutional | EVQ4s1b6N1vmWFDv8PRNc77kufBP8HcrSNWXQAhRsJq9 | ### Account Addresses | Account | Address | | --------- | -------------------------------------------- | | PST Mint | 59obFNBzyTBGowrkif5uK7ojS58vsuWz3ZCvg6tfZAGw | | mPST Mint | HUPfpnsaJtJGpJxAPNX1vXah7BgYiQYt1c2JMgMumvPs | ## EVM ### GitHub Repo [Codebase](https://www.notion.so/Huma-2-0-Gitbook-f63276eed2c346f99a4689ebd2873737?pvs=21) ### 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 | ## Stellar | Contract Name | Address | | --------------- | -------------------------------------------------------- | | ContractFactory | CBQHYENQ7ANK5UEUOGEL5CMLZV3LUPS4IVR3EHXMMVYQTNMFOGPTLXBC | | HumaConfig | CAXZGMU3EHOHGXGXDJWVPG5PIVC2DCZQ2JO2YI3RGSM4OQK7ZIQ46FV5 | | PoolStorage | CAADAYJOZF5HXPVZXBXA3PLCU7OSRW34OKVXG2676KAGZVZBI6EYQ73L | | PoolManager | CBFX4CMIWVOVFTJCRC5BYTBOXBZVJXNUI2D5UWM6WP4J2VBXRFYV4YQC | | Pool | CDVJY4NLTSKNLHO2JIRKDERE366WYG3OSJY42VOLI7DBAX4X5Q2BY75O | | CreditStorage | CCXOG76F7A67FHR5OVJPGUVLHF55VOYJZADWEQDDMVLR66R3ODNRAIEP | | CreditManager | CBX7MQGXQN6DHGDDRARUH266PIIDTFB5H5HVFPFL365V2JJPX2OWZOZT | | Credit | CC34OGI32WJDSGFES3HWSETSKPN5BQLDEYFHFTDVTUEL2HZLJG5M2UAJ | | JuniorTranche | CDJ6AO57ZWBIDITDN32URXYQY6MTSFBNF6OFOCENRDE2MUB67UZKLKDP | | SeniorTranche | CDJ6AO57ZWBIDITDN32URXYQY6MTSFBNF6OFOCENRDE2MUB67UZKLKDP | # Security & Audits 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. ## **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. ## **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** and **Sec3** ↳ *\[*[*Huma Prime Audit Report*](https://github.com/sec3-service/reports/blob/master/reports/sec3_huma_vault.pdf)*]* ↳ *\[*[*Incremental Audit Report 1*](https://github.com/sec3-service/reports/blob/master/reports/sec3_huma_vault_incremental_20260131.pdf)*]* ↳ *\[*[*Huma 2.0 Audit Report*](https://www.halborn.com/audits/huma-finance/solana-programs-060022)*]* ↳ *\[*[*Incremental Audit Report 1*](https://www.halborn.com/audits/huma-finance/huma-solana-programs-687cbd)*]* ↳ *\[*[*Incremental Audit Report 2*](https://github.com/sec3-service/reports/blob/master/reports/sec3_huma_permissionless_incremental_20260512.pdf)*]* ↳ *\[*[*Incremental Audit Report 3*](https://github.com/sec3-service/reports/blob/master/reports/sec3_huma_permissionless_pr407_incr_20260608.pdf)*]* ↳ *\[*[*Huma Institutional Audit Report*](https://www.halborn.com/audits/huma-finance/huma---pr-124-d3c7e8)*]* ↳ *\[*[*Incremental Audit Report 1*](https://www.halborn.com/audits/huma-finance/huma---solana-program-audit-pr-113-2b46cf)*]* * **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. ## **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. # Legal [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)