> 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/the-solution.md). # The Solution How Hypotheca turns verified identity, security, payment history, and risk controls into measured credit access for autonomous agents. Instead of asking only how much collateral an agent can provide, Hypotheca evaluates what the agent can prove. The system places a filtered credit gate between an agent and Uniswap v4 liquidity pools. It turns verifiable evidence into a controlled decision about credit access. Borrowing becomes a process: establish evidence, validate it, apply risk conditions, then permit liquidity execution. ### From Evidence to Credit Credit access begins with proof, not a single balance-sheet signal. Hypotheca combines identity, security posture, and economic activity into a structured eligibility path. ``` PROOF ↓ VERIFICATION ↓ RISK CHECKS ↓ CREDIT DECISION ↓ LIQUIDITY ACCESS ``` Each stage narrows the path. Evidence provides the basis for evaluation. Verification confirms that evidence meets protocol requirements. Risk checks assess the requested borrow in its current conditions. Only then can the system approve access to liquidity. This does not make credit automatic. It makes the decision explicit: an agent must satisfy every required condition before it reaches the execution path. ### Three Layers of Trust The gate requires three independent verification layers. No single layer is sufficient. Together, they establish a broader borrower context than an isolated wallet address can provide. {% columns %} {% column %} #### Identity **Who is the borrower?** ERC-8004 identity infrastructure confirms that the agent has a valid, active identity and a reputation log. The identity must not be revoked. Its wallet must be distinct from the deployer or protocol wallet. The system also checks that the wallet is not flagged as part of a coordinated Sybil cluster. This creates a persistent identity context around the borrower. {% endcolumn %} {% column %} #### Security **Is the execution environment within the required risk threshold?** A current security report is part of credit eligibility. The report must exist, match its stored IPFS content, remain unrevoked, and be no more than seven days old. It also cannot contain critical findings. The report’s risk score determines whether the agent meets the relevant borrowing threshold. {% endcolumn %} {% endcolumns %} #### Economic activity **Has the borrower demonstrated verifiable economic activity?** Payment receipts connect claimed activity to confirmed on-chain transactions. Hypotheca requires at least three verified receipts, including one from the previous 30 days. They must match expected payment values, use approved facilitators, and come from at least two distinct payer addresses. The protocol uses USDG with six decimals. Payments use EIP-3009 authorization through approved x402 facilitators. Suspicious, farming, and circular payment patterns do not qualify. These layers are complementary. Identity provides continuity. Security assesses the environment using borrowed liquidity. Payment history demonstrates verified activity. Together, they create the evidence required to continue. {% hint style="info" %} Passing one layer does not compensate for failing another. All three must pass before the credit decision proceeds. {% endhint %} Security access also reflects the size of the request. Standard borrowing requires a risk score of 50 or lower. Large borrowing requires a score of 20 or lower. A score from 0–20 passes for full credit access across borrow tiers. Scores from 21–50 allow standard access with capped borrowing. Scores from 51–80 deny borrowing and require report renewal. Scores from 81–100 deny borrowing and are flagged. ### The Gate Before Liquidity Three-layer verification is necessary, but it is not the final decision. A verified borrower still needs to request a supported asset, borrow against a healthy oracle, and remain within permitted LTV parameters. ``` Verified identity, security, and payment history ↓ Asset allowlist ↓ Oracle status ↓ LTV limit ↓ Uniswap v4 Hook approval ↓ Borrow execution ``` This is where reputation and verification become actual credit access. The asset allowlist limits requests to supported assets. The oracle check requires the relevant price feed to be healthy and not paused. The LTV check ensures the requested amount remains within defined limits. Only after those conditions pass does the Hook approve the borrow. If a condition fails, the request is rejected with a specific reason code. The gate therefore assesses both the borrower’s evidence and the conditions surrounding the requested credit. ### A Credit Decision, Not a Single Check Hypotheca expresses the decision as an intentionally conjunctive rule: ``` Can_Borrow = Valid_Identity AND Current_Security_Report AND Payment_Receipts_Exist AND Asset_in_Allowlist AND Oracle_Not_Paused AND LTV_Within_Limits ``` In plain terms, every requirement must be true. A current security report cannot override a paused oracle. Payment history cannot substitute for an unsupported asset. Passing verification does not bypass LTV limits. That structure keeps the credit decision legible. It also ensures that eligibility is evaluated alongside the conditions that govern the requested liquidity. ### Where the Decision Becomes Execution The credit decision answers whether an agent may borrow. The Uniswap v4 Hook provides the execution control that applies that decision to liquidity access. Before a borrow-minted swap executes, `beforeSwap` intercepts the request and runs the verification gate. After a successful swap, `afterSwap` records the borrow execution and its transaction hash. The Hook also supports LTV enforcement around liquidity activity. `beforeRemoveLiquidity` prevents removal that would breach LTV requirements. `afterRemoveLiquidity` updates tracking after liquidation-related activity. The result is a direct connection between eligibility and execution. A favorable assessment alone does not release liquidity. The approval must be present at the point where the borrow is executed. ### Credit Leaves a Trail Borrowing is not treated as an isolated event. Hypotheca records material credit activity through transaction hashes, creating persistent and queryable history. ``` Borrow ↓ Repay ↓ Liquidation, if necessary ↓ Reputation update ``` A borrow record includes the agent ID, amount, asset, transaction hash, timestamp, and LTV. Repayment records capture the agent ID, amount, transaction hash, timestamp, and interest paid. Liquidation records include the amount seized and trigger reason. Reputation updates record the agent ID, score delta, transaction hash, and reason. This history ties future reputation updates to observable credit events. It preserves the record of what happened after access was granted. ### Designed to Restrict Access When Conditions Change Credit access remains conditional. The system can restrict borrowing when verification, oracle, or risk requirements are no longer satisfied. Oracle pauses, circuit breakers, and emergency controls provide high-level safeguards for unsafe conditions. They prevent the system from continuing to approve borrowing when its required operating assumptions no longer hold. This reflects a core design principle: measured access must be able to contract as well as expand. Identity, security, activity, current risk conditions, and recorded behavior each inform access without becoming a single guarantee. ### The Result Hypotheca does not treat trust as one signal. It combines identity, security, economic activity, risk conditions, and credit behavior into a structured access decision. The architecture moves from evidence to verification, risk filtering, controlled liquidity access, and persistent credit history. The following pages examine each verification and technical layer in detail. *** --- # 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/the-solution.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.