> For the complete documentation index, see [llms.txt](https://quantixfinance.gitbook.io/quantixfinance-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://quantixfinance.gitbook.io/quantixfinance-docs/credit-lifecycle/borrower-application.md).

# Borrower Application

A borrower applies to a specific pool, not to the protocol generically. The application establishes who the borrower is — the entity, its principals, and its operating history — and what they do: the nature of the business, how it generates revenue, and the track record that gives a delegate something concrete to underwrite against. Alongside that, the borrower states the facility they are seeking and the terms they propose: amount, tenor, intended use of proceeds, and the collateral they are able to post against the loan.

This is the delegate's starting file, not a commitment. Submitting an application creates no obligation on either side — nothing is approved, priced, or reserved at this stage. It exists so that underwriting has a real basis to work from before any capital, terms, or collateral arrangement are discussed further.

Applications are directed to the delegate whose mandate fits the borrower, not assigned at random or left for the borrower to guess. A market maker seeking a revolving facility against liquid, actively-traded collateral has a different risk profile — and belongs in a different pool — than a fund seeking a term loan against a less liquid position. Routing by mandate rather than by availability means a borrower's application reaches a delegate who actually underwrites that kind of risk, rather than one who happens to have open capacity.