> 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/how-it-works/verification-flow.md). # Verification Flow How Hypotheca verifies identity, security posture, payment activity, and system conditions before approving a borrow. Credit approval begins with a question of evidence, not a balance. A borrow request moves through a progression of checks before it can reach liquidity. Hypotheca evaluates who the borrower is, whether its security posture is acceptable, and whether it has demonstrated real economic activity. It then evaluates whether the requested transaction can execute under current asset, oracle, and LTV conditions. ### A Borrow Request Enters the Gate An autonomous agent requests to borrow liquidity. The request does not immediately access the pool. It enters a verification sequence that narrows eligibility at each stage. ``` REQUEST ↓ VERIFY ↓ FILTER ↓ EXECUTE ↓ RECORD ``` The complete path is: ``` Agent Requests Borrow → Layer 1: Identity Verification → Layer 2: Security Report Validation → Layer 3: Payment Receipt Verification → Asset Allowlist Check → Oracle Status Check → LTV Limit Check → v4 Hook Approval → Borrow Execution → Transaction Hash Recorded → Repay or Liquidation → Reputation Updated ``` At any point, a failed required condition stops the request. The request is rejected with a reason code. ### Layer 1: Identity Verification Before evaluating the borrow, Hypotheca establishes a persistent identity context around the borrower. The wallet is not treated as an isolated address. Identity verification checks: * A valid ERC-8004 identity token exists. * The identity is active and not revoked. * A reputation log exists. * The wallet is distinct from the deployer or protocol wallet. * The wallet is not flagged as part of a coordinated Sybil cluster. The process uses the ERC-8004 Identity Registry and ERC-8004 Reputation Registry. ``` IDENTITY → Active? → Revoked? → Reputation exists? → Wallet separated? → Sybil cluster check? → PASS or REJECT ``` These checks provide identity context within the broader verification gate. They do not guarantee identity uniqueness or eliminate Sybil activity. ### Layer 2: Security Report Validation Once identity requirements pass, the request moves to the agent's current security posture. A report is not treated as permanent evidence. The protocol requires evidence that remains current. The security report must: * Exist and be no more than seven days old. * Have an IPFS hash matching its stored content. * Meet the required risk-score threshold. * Have no critical findings. * Not be revoked. Risk scores determine the available outcome: * **0–20 — Pass:** Full credit access across tiers. * **21–50 — Review:** Standard credit access with capped borrowing. * **51–80 — Caution:** Borrow denied and report renewal required. * **81–100 — Critical:** Borrow denied and flagged. For a standard borrow, the risk score must be **50 or below**. For a large borrow, it must be **20 or below**. Freshness matters because security posture can change. The report supplies evidence for the current decision. It does not guarantee that the agent is safe. ### Layer 3: Payment Receipt Verification The next layer evaluates demonstrated economic activity. Hypotheca requires verified payment evidence rather than relying on an unsupported claim of usage or revenue. The agent must provide: * At least three verified payment receipts. * A confirmed on-chain transaction for every `txHash`. * Receipt amounts matching expected payment values. * Receipts from approved facilitators only. * At least two distinct payer addresses. * At least one receipt from the last 30 days. * No suspicious, farming, or circular payment patterns. Payment verification follows a defined sequence: 1. Query the transaction by `txHash`. 2. Confirm that the transaction succeeded. 3. Verify the expected USDG payment. 4. Check the facilitator against the approved list. 5. Evaluate payer diversity. 6. Check receipt timing and recency. 7. Look for suspicious or circular patterns. 8. Aggregate results against the minimum requirements. This verification uses Robinhood Chain, USDG, EIP-3009, x402, and approved facilitators. Payment history supports evidence of activity. It does not guarantee future repayment behavior. ### The Verification Sequence Matters The layers are intentionally independent. A valid identity does not compensate for insufficient security evidence. An acceptable security report does not compensate for missing payment history. Borrower evidence can also pass while the requested asset is restricted, the oracle is paused, or the LTV falls outside the permitted boundary. {% hint style="info" %} One strong signal does not override a failed required condition. {% endhint %} The purpose is not to find one perfect signal. The process requires several forms of evidence and system conditions to align. ### After the Three Layers The first three layers establish borrower eligibility evidence. The protocol then determines whether the requested borrowing action is currently permitted. #### Asset Allowlist The requested asset must be supported by the protocol: * **USDG** — 75% LTV; Chainlink oracle. * **WETH** — 70% LTV; Chainlink oracle. * **Official Stock Tokens** — Governance-approved; 50% LTV, which varies; custom oracle. An asset outside the allowlist cannot proceed through the borrow path. #### Oracle Status The relevant oracle must be healthy. A 5% deviation between oracle sources triggers a pause. A 15% price movement within one hour triggers a global borrow halt. A feed stale for more than 60 minutes also triggers a pause. These conditions determine whether the market data supports borrowing at that moment. #### LTV Limit The requested amount must remain within the permitted LTV boundaries. This is the final risk boundary before execution. * Minimum collateralization: **125%** * Liquidation threshold: **110%** * Liquidation bonus: **8%** * Maximum borrow per agent: **5% of the pool** * Effective LTV: never above **90%** An agent can satisfy the three verification layers and still have its request rejected when the requested amount exceeds these limits. ### Pass or Reject #### Pass All required conditions are satisfied. The request proceeds to v4 Hook approval and borrow execution. #### Reject At least one required condition fails. The request is rejected with a reason code. The outcome reflects the condition that failed for this request. The decision remains conjunctive: ``` Can_Borrow = Valid_Identity AND Current_Security_Report AND Payment_Receipts_Exist AND Asset_in_Allowlist AND Oracle_Not_Paused AND LTV_Within_Limits ``` ### From Verification to Execution Successful verification moves the request into the Uniswap v4 execution path through the custom Hook. ``` Borrow Intent → beforeSwap → Verification Gate → Allow or Revert → afterSwap → Transaction Hash ``` `beforeSwap` intercepts borrow-minted swaps and runs the verification gate. When the conditions pass, execution can proceed. When they fail, the request reverts. `afterSwap` records successful borrow execution and its `txHash`. The Hook applies the verification outcome to the specific borrowing action without duplicating the detailed Hook implementation. ### Verification Does Not End at Approval Execution begins a recorded credit lifecycle: ``` Borrow → Repay → Liquidation if required → Reputation Update ``` Borrow records include `agentId`, `amount`, `asset`, `txHash`, `timestamp`, and `LTV`. Repay records include `agentId`, `amount`, `txHash`, `timestamp`, and interest paid. Liquidation records include `agentId`, amount seized, `txHash`, timestamp, and trigger reason. Reputation updates include `agentId`, score delta, `txHash`, and reason. These events create persistent, queryable credit history. They record the lifecycle of credit activity without reducing it to a one-time approval. --- # 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/how-it-works/verification-flow.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.