> 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/credit-gate.md). # Credit Gate The decision layer that evaluates borrower identity, security, payment history, market conditions, and LTV before liquidity can be accessed. A borrow request does not move directly from an agent to liquidity. It passes through a gate. The Credit Gate evaluates independent borrower, asset, market, and borrowing conditions. Only when every required condition passes can the requested action proceed to execution. Eligibility is not a single signal. An agent may have a valid identity but fail security verification. It may meet borrower requirements while the requested asset, oracle status, or LTV prevents borrowing. No positive result overrides a failed required condition. ### The Gate Hypotheca places the Credit Gate between autonomous agents and Uniswap v4 liquidity. The gate decides whether a borrow request is acceptable at the moment it is made. The request moves through the following sequence: ``` Agent Requests Borrow → Identity Verification → Security Report Validation → Payment Receipt Verification → Asset Allowlist Check → Oracle Status Check → LTV Limit Check → v4 Hook Approval → Borrow Execution → Transaction Hash Recorded ``` The gate therefore checks more than whether an agent exists. It checks whether the borrower evidence, requested asset, market conditions, and borrowing parameters all remain acceptable. {% hint style="info" %} If any required condition fails, the borrow request is rejected with a reason code. {% endhint %} ### Six conditions before credit The gate applies six required conditions. The first three establish borrower evidence. The remaining conditions determine whether the specific borrow can proceed. 1. **Identity** — The agent must hold a valid, active ERC-8004 identity token with a reputation log. Its wallet must be distinct from the deployer or protocol wallet. It must also not be flagged as part of a coordinated Sybil cluster. 2. **Security** — The agent must have a current, acceptable security audit report. The report must satisfy freshness, integrity, risk-score, critical-finding, and revocation checks. 3. **Payment history** — The agent must provide sufficient verified on-chain payment receipts. This evidence demonstrates real, verifiable economic activity. 4. **Asset** — The requested borrowing asset must be on the allowlist. 5. **Oracle** — The relevant price oracle must not be paused. 6. **LTV** — The requested borrow must remain within the permitted LTV limits. Identity and Sybil-cluster checks are part of the broader verification gate. They do not establish identity uniqueness or eliminate Sybil risk on their own. #### Identity evidence Identity verification uses the ERC-8004 Identity Registry and ERC-8004 Reputation Registry. The gate confirms that the identity token is valid and active, that it has not been revoked, and that a reputation log exists. The wallet relationship also matters. The borrower wallet must be separate from the deployer or protocol wallet. Cluster checks identify wallets flagged as coordinated Sybil activity. #### Current security posture Security verification requires a current audit report. The gate confirms that a report exists, is no older than seven days, and has an IPFS hash matching its stored content. It also evaluates the report's risk score, critical findings, and revocation status. An audit report provides current evidence for this decision. It does not guarantee safety. The risk score determines the resulting 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**. #### Verified economic activity Payment verification checks whether the agent has demonstrated payment activity that can be verified on-chain. It requires at least three verified payment receipts, including receipts from at least two distinct payer addresses. Each `txHash` must map to a confirmed on-chain transaction. Receipt amounts must match the expected payment values. At least one receipt must be from the last 30 days. The gate accepts receipts through approved x402 facilitators only. It also checks for suspicious, farming, and circular payment patterns. This layer uses Robinhood Chain transaction data, USDG with six-decimal precision, and EIP-3009 authorization. It does not infer activity from unsupported evidence. #### Supported assets After the primary verification layers pass, the gate checks the requested asset: * **USDG** — `0x5fc5360D0400a0Fd4f2af552ADD042D716F1d168`; 75% LTV; Chainlink oracle. * **WETH** — `0x0Bd7D308f8E1639FAb988df18A8011f41EAcAD73`; 70% LTV; Chainlink oracle. * **Official Stock Tokens** — Governance-approved; 50% LTV, which varies; custom oracle. An asset outside this allowlist cannot proceed through the borrow path. #### Market and borrowing boundaries The gate checks the relevant oracle before allowing a borrow. Real-time price feeds use Chainlink or equivalent infrastructure. Several conditions pause borrowing: a 5% deviation between oracle sources, a stale feed exceeding 60 minutes, or a 15% price movement within one hour. The latter triggers a global borrow halt. The requested borrow must also respect the defined collateral and pool boundaries: * Minimum collateralization: **125%** * Liquidation threshold: **110%** * Liquidation bonus: **8%** * Maximum borrow per agent: **5% of the pool** * Effective LTV: never above **90%** These checks assess both agent eligibility and the requested amount. A qualified agent can still be rejected when the borrow exceeds the permitted risk boundary. ### The decision The Credit Gate uses conjunctive logic: ``` 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, a borrow can proceed only when: 1. The borrower has a valid identity. 2. The security report is current and acceptable. 3. The agent has sufficient verified payment history. 4. The requested asset is allowlisted. 5. The relevant oracle is not paused. 6. The requested LTV is within the permitted limits. Each condition is required. The gate rejects the request when any one condition fails. Passing the gate does not guarantee repayment. ### From decision to execution The Credit Gate connects to the Uniswap v4 execution path through a custom Hook: ``` Borrow Intent → beforeSwap → Credit Gate → Allow or Revert → afterSwap → Transaction Hash Recorded ``` `beforeSwap` intercepts borrow-minted swaps and runs the verification gate. The request is allowed or reverted based on the decision. `afterSwap` records successful borrow execution and its transaction hash. `beforeRemoveLiquidity` blocks liquidity removal that would breach LTV requirements. `afterRemoveLiquidity` updates tracking after liquidation-related activity. The Hook connects the decision to execution. It ensures the outcome applies to the borrowing action being attempted. ### What gets recorded Successful credit activity records a transaction hash. Relevant borrow event data includes: * `agentId` * `amount` and `asset` * `txHash` and `timestamp` * `LTV` This record links a successful execution to its borrower, amount, asset, and borrowing state. The Credit Gate does not predict trust from a single number. It requires multiple forms of evidence and multiple system conditions to align before liquidity can move. [Verification Flow](/hypotheca-docs/hypotheca/how-it-works/verification-flow.md) explains how each condition is evaluated in sequence. --- # 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/credit-gate.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.