> For the complete documentation index, see [llms.txt](https://docs.usd.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.usd.ai/usdai/how-it-works.md). # How It Works USD.AI issues loans backed by GPU collateral. Learn how the protocol works end-to-end, from borrower underwriting to depositor yield. USD.AI is a two-sided credit protocol that connects AI infrastructure operators who need capital with depositors who want yield exposure to compute-backed lending. The protocol originates GPU-secured loans, funds them through onchain deposits, and distributes yield through a tokenized instrument stack; all while maintaining a traditional, legally enforceable lending structure off-chain. The system operates across three layers: a depositor layer where capital enters, a lending layer where loans are originated and serviced, and a governance layer where protocol parameters are set by CHIP token holders. ### Capital In: USDai and sUSDai Capital enters the protocol when depositors deposit PYUSD (PayPal's regulated, dollar-backed stablecoin) in exchange for USDai, a synthetic dollar pegged 1:1 and fully backed by the underlying PYUSD. USDai itself does not generate yield; it is a stable, composable asset designed for holding, transferring, or use across DeFi. To earn yield, depositors stake USDai in exchange for sUSDai, the protocol's yield-bearing token. sUSDai captures income from two sources: interest payments on active GPU-backed loans, and Treasury bill yield earned on idle reserves. This yield accrues continuously and is reflected in a rising exchange rate between USDai and sUSDai - holders do not need to claim anything manually. Direct minting and redemption of USDai at the smart contract level is currently permissionless, but AML controls are implemented on the app frontend and in the contract. USDai and sUSDai are always permissionless to hold, transfer, stake, and trade on secondary markets. ### Loans Out: GPU Infrastructure Financing On the borrowing side, AI infrastructure operators — neoclouds, data center companies, and compute providers — apply for financing to acquire GPU hardware. Loans are non-recourse and secured by the physical GPU assets themselves along with their contracted cashflows, structured similarly to traditional equipment finance. Every loan follows a four-phase process. First, an escrow is established and funded (held by Wilmington Trust). Second, the OEM builds and ships the servers. Third, hardware is installed, tested, and verified at the datacenter, and a permanent lien is filed. Fourth, escrow is released, bridge lenders (or the OEM, if providing net terms) are repaid, and the borrower enters standard repayment — interest and principal due every 30 days over a 3-year amortization schedule. Each borrower operates through a bankruptcy-remote Delaware SPV, legally isolating the GPU collateral from the operator's broader balance sheet. A comprehensive legal package — including a Loan and Security Agreement, UCC-1 filings, pledge agreements, and datacenter lien waivers — ensures enforceable collateral rights in the real world. ### The Hybrid Structure: Onchain Meets Offchain USD.AI operates simultaneously across two record systems. Offchain, the legal infrastructure provides real-world enforceability: perfected liens, SPV structures, bank accounts, escrow, and insurance. Onchain, the protocol provides transparency and programmability: Loan NFTs represent collateral positions, the Onchain Record serves as the authoritative lender register, and smart contracts automate the payment waterfall and reserve drawdowns. These two layers are synchronized at every material event. The Loan NFT is only minted once all off-chain conditions are met (servers delivered, installed, verified, liens filed) and all on-chain conditions are satisfied (wallet provisioned, record updated). Escrow cannot release until the NFT exists. In default, the loan documents govern. All cash is swept to lenders, with or without acceleration, and the USD.AI Protocol freezes the Loan NFT, which can then move only at the Agent’s direction. USD.AI records the default onchain manually, which can lag a day or two (e.g., over a weekend). Offchain, the Requisite Lenders direct the Agent’s remedies: taking control of the borrower’s bank accounts and its data center and customer contracts, enforcing the pledge of the SPV’s equity, and taking possession of the servers. The Agent can accelerate the loan on its own, and must if the Requisite Lenders direct it. ### Risk Mitigation and Collateral Protection Loans are originated at 70–80% loan-to-value ratios, and blended loan-to-value across the portfolio may not exceed 80%. Borrowers fund a Debt Service Reserve Account (DSRA) at closing, covering one to three months of peak debt service. The protocol maintains layered protections including property insurance (via Alliant), residual value protection on the servers (via Barkr), required where the offtaker is not investment-grade or the compute is sold as on-demand rental, real-time hardware monitoring (via Aravolta or similar), and a default process that keeps the SPV operating under a replacement operator or sells it as a whole first, with ITAD firms as the fallback for selling the servers individually. Borrowers who hold their DSRA in USDai receive a rate compression benefit: the yield generated by that USDai (from the PayPal PYUSD incentive) flows back into their interest rate, reducing their effective borrowing cost. {% hint style="info" %} Readers can verify live collateral and loan visibility in [View Proof of Reserves](https://app.usd.ai/reserves). {% endhint %} ### Redemptions and Liquidity Because the protocol's capital is deployed into illiquid, amortizing GPU loans, sUSDai redemptions operate on a 30-day epoch cycle using a FIFO queue. Available USDai is distributed to queued redemptions at each epoch close. During periods of high utilization, redemption queues may extend across multiple epochs. The protocol does not prematurely liquidate loans to satisfy withdrawals. The maximum sUSDai utilization (the share of sUSDai capital deployed in loans) for deploying new loans is 90%. A future mechanism called Queue Extractable Value (QEV) will introduce auction-based priority bidding for redemption positioning, allowing depositors to pay for faster exits while redistributing those fees to passive stakers. ### Governance: CHIP CHIP is the protocol's governance token. CHIP holders vote on the parameters that shape how the system operates: which GPU hardware qualifies as eligible collateral, how interest rates are tiered across different offtake qualities, what borrower eligibility criteria apply, how protocol fees are set and routed, and when smart contract upgrades or new integrations are approved. ### The Sections That Follow The pages that follow provide detailed documentation for each side of the protocol. The **Borrower** section covers the full loan lifecycle, legal structure, onchain/offchain mechanics, and partner ecosystem. The **Depositor** section covers USDai, sUSDai, yield mechanics, redemption processes, and QEV. The **Governance** section covers CHIP utility, staking, and tokenomics. The **Technical Overview** provides smart contract architecture, audit reports, and deployed contract addresses. {% hint style="success" %} Ready to enter the protocol? [Mint USDai](https://app.usd.ai/buy). {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.usd.ai/usdai/how-it-works.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.