> For the complete documentation index, see [llms.txt](https://hypotheca.gitbook.io/hypotheca-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hypotheca.gitbook.io/hypotheca-docs/hypotheca/introduction/overview.md). # Overview An introduction to Hypotheca, a reputation-secured credit access system for autonomous agents built around verified identity, security, payment history, and measured credit access. Collateral tells you what someone owns. Reputation tells you what someone has done. For autonomous agents, that distinction changes the credit question. An agent may show productive activity and earning capacity without holding substantial initial capital. A collateral-first model does not directly recognize that history. **Hypotheca does not lend against what you own. Hypotheca lends against what you have proven.** Hypotheca is a reputation-secured credit access system for autonomous agents. It places a multi-layer verification gate before agents can access liquidity from Uniswap v4 pools. Verified identity, current security evidence, and payment history form the basis for measured access. ### A Different Credit Model Over-collateralized lending serves borrowers with capital already deposited. It also creates a barrier for agents whose productive history exists before their balance sheet does. Hypotheca adds demonstrated history to the credit decision. This does not remove collateralization or lending risk. It introduces evidence about the borrower alongside defined risk parameters. {% hint style="info" %} Credit access is conditional. An agent must satisfy verification and risk requirements at the time of borrowing. {% endhint %} ### Credit Built on Verifiable Evidence Three independent layers establish whether an agent can enter the credit path. Passing one does not satisfy the others. 1. **Identity**\ ERC-8004 identity verification confirms a valid, active agent identity with a reputation record. It also checks that the borrowing wallet is distinct and not part of a coordinated Sybil cluster. 2. **Security**\ A current security audit report must meet Hypotheca’s requirements. The report is validated for integrity, risk threshold, critical findings, and revocation status. 3. **Economic activity**\ Verified on-chain payment receipts demonstrate actual activity and payment history. Receipts must map to confirmed transactions and meet defined checks for recency, payers, facilitators, and suspicious patterns. > Credit is not granted because an agent claims to be trustworthy.\ > Credit is granted because the protocol verifies evidence of trustworthiness. ### The Credit Gate Hypotheca sits between an agent’s request and Uniswap v4 liquidity. The gate evaluates each required condition before the v4 Hook can approve a borrow. ``` Agent ↓ Identity ↓ Security ↓ Payment History ↓ Asset & Oracle Checks ↓ LTV Check ↓ Uniswap v4 Hook ↓ Credit Access ``` The requested asset must be allowlisted. Oracle conditions must remain available. The requested loan-to-value ratio must also stay within limits. Any failed verification or risk condition rejects the request with a specific reason code. A successful request proceeds through the Hook to borrow execution. ### From Activity to Credit History Credit behavior is not treated as an isolated event. Borrowing, repayment, liquidation, verification, and related reputation activity are recorded through transaction hashes. This creates persistent, queryable history. The internal Hypotheca Credit Score combines several signals: * Reputation and security audit status * Verified payment activity and credit repayment history * Account age That score is separate from external reputation. It supports credit limits that scale with demonstrated reputation and defined risk parameters. ### Designed to Fail Safely Measured access depends on controls that can restrict borrowing when conditions become unsafe. * **Asset allowlists** constrain eligible borrowing assets. * **Oracle monitoring** can pause access when price data deviates, moves sharply, or becomes stale. * **LTV limits and liquidation controls** maintain defined collateralization boundaries. * **Circuit breakers and emergency controls** restrict borrowing during unsafe system conditions. These controls work with the verification layers. They ensure a valid agent profile alone does not guarantee access. ### Why Hypotheca Hypotheca introduces additional verification and reputation-based controls into the credit decision: * **Reputation-backed credit access** uses demonstrated history. * **Security-aware borrowing** requires validated, current audit evidence. * **Verified economic activity** relies on on-chain payment receipts. * **Measured credit limits** apply defined risk parameters. * **Persistent on-chain history** records credit activity through transaction hashes. * **Explicit risk controls** restrict access under unsafe conditions. Credit should reflect what an agent has proven, not only what it can deposit. *** --- # 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://hypotheca.gitbook.io/hypotheca-docs/hypotheca/introduction/overview.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.