> 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.md).

# How It Works

Understand how Hypotheca evaluates an agent, applies risk controls, and turns verified evidence into measured credit access.

Credit access is not a single transaction in Hypotheca. It is a sequence of checks.

Before liquidity moves, the borrower has to prove that it should move. Hypotheca evaluates identity, security, economic activity, asset eligibility, market conditions, and borrowing limits before execution.

### From Request to Credit

```
Agent Request
    ↓
Proof
    ↓
Verification
    ↓
Risk Checks
    ↓
Credit Decision
    ↓
Liquidity Access
    ↓
On-Chain Record
```

An agent begins with a borrow request and supplies the required evidence. Hypotheca verifies that evidence, then checks whether the requested asset and market conditions permit borrowing.

Every required condition must pass. A failed condition rejects the request.

Once approved by the v4 hook, the borrow executes. Its transaction hash records the resulting credit event.

### Three layers of verification

The credit gate evaluates three independent layers of evidence. **All three are required** before a request can move forward.

#### Identity

Identity verification establishes who the agent is. Its ERC-8004 identity must be valid and active, with a reputation record. Wallet separation and Sybil-cluster checks also apply.

#### Security

Security verification evaluates the agent's current security posture. The audit report must meet freshness, IPFS integrity, risk-score, critical-finding, and revocation requirements.

#### Economic activity

Economic activity verification establishes evidence of payment behavior. Verified on-chain receipts must satisfy count, payer diversity, recency, facilitator, transaction, and pattern requirements.

### Beyond verification

Passing verification establishes eligibility evidence. It does not release liquidity automatically.

The requested action continues through:

**Asset Allowlist** → **Oracle Status** → **LTV Limit** → **v4 Hook Approval**

These controls determine whether the specific borrow is permitted now. The internal credit score supports measured access, rather than serving as a standalone approval signal.

{% hint style="info" %}
The borrow decision requires valid identity, a current security report, payment receipts, an allowlisted asset, an active oracle, and LTV within limits.
{% endhint %}

### Credit becomes history

The process continues after execution. Borrow, repay, liquidation, and reputation-update events can be recorded through transaction hashes.

This creates persistent, queryable credit history. Hypotheca therefore treats credit as an evolving history, not a one-time approval.

### Explore the system

#### [Credit Gate](/hypotheca-docs/hypotheca/how-it-works/credit-gate.md)

How the protocol determines whether a borrow request can proceed.

#### [Verification Flow](/hypotheca-docs/hypotheca/how-it-works/verification-flow.md)

How identity, security, payment, asset, oracle, and LTV checks are evaluated.

#### [Credit Scoring](/hypotheca-docs/hypotheca/how-it-works/credit-scoring.md)

How Hypotheca combines reputation, security, payment history, repayment behavior, and account age into its internal credit score.

The following pages move from the high-level lifecycle into the individual mechanisms that make the credit decision possible.


---

# 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.md?ask=<question>&goal=<endgoal>
```

`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.