> 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/technology/payment-verification.md). # Payment Verification How Hypotheca verifies real on-chain payment activity as evidence of an agent's economic history. Reputation becomes more useful when it is backed by economic activity. Hypotheca verifies payment receipts against on-chain transaction data. The goal is to determine whether an agent has demonstrated real payment behavior, rather than simply claiming transaction history. ### Payment requirements An agent must provide payment evidence that satisfies every requirement: * At least three verified payment receipts. * A confirmed on-chain transaction for every receipt. * Receipt amounts matching expected payment values. * Payments involving approved facilitators. * At least two distinct payer addresses. * At least one verified receipt within the last 30 days. * No suspicious, farming, or circular payment patterns. These conditions combine transaction validity, payment diversity, recency, and pattern analysis. Payment history is usable only after the underlying receipts have been verified. ### Verification flow ``` Payment Receipt → Transaction Hash → On-Chain Transaction Lookup → Transaction Status Check → Payment Amount Check → Facilitator Check → Payer Diversity Check → Recency Check → Pattern Analysis → Payment Verification Result ``` Hypotheca queries the Robinhood Chain RPC using the transaction hash. It verifies that the transaction exists and was successfully confirmed before using the receipt as evidence. ### Receipt verification Each receipt progresses through the following checks: 1. **Transaction lookup** — Confirm that the transaction exists on-chain. 2. **Transaction status** — Confirm that the transaction completed successfully. 3. **Payment amount** — Confirm that the receipt amount matches the expected payment value. 4. **Facilitator** — Confirm that the payment used an approved facilitator. 5. **Payer diversity** — Confirm that the history has the required number of distinct payer addresses. 6. **Timestamp** — Confirm that at least one qualifying payment falls within the 30-day window. 7. **Pattern analysis** — Reject suspicious farming or circular payment behavior. Invalid receipts are skipped during verification. The resulting payment history must still satisfy the aggregate requirements. ### Payment protocol The payment-verification flow uses these implementation components: * **x402** for the payment protocol. * **USDG** as the payment asset. * **Six-decimal USDG precision.** * **EIP-3009** for gasless authorization. * **Approved facilitators** for payment processing. These components support the payment evidence used by the verification layer. They do not replace the receipt-level checks. ### Transaction hashes are the evidence {% hint style="info" %} Self-reported payment history is not verified payment history. {% endhint %} Hypotheca does not rely solely on an agent-provided payment record. The transaction hash lets the system independently verify whether the claimed payment occurred and whether the associated payment conditions are satisfied. A receipt becomes usable evidence only when its on-chain transaction passes the required verification checks. ### Verification logic ``` Payment_Pass = At_Least_3_Verified_Receipts AND Confirmed_On_Chain AND Amounts_Match AND Approved_Facilitators AND At_Least_2_Payers AND Recent_Receipt_Exists AND No_Suspicious_Pattern ``` The logic applies to the verified payment history as a whole. A valid transaction alone does not satisfy the layer when the required count, diversity, recency, or pattern conditions are missing. ### Payment history and credit access Payment verification does not independently determine the borrowing amount. It establishes evidence used to assess whether an agent passes the Credit Gate and contributes to its broader credit profile. The payment layer verifies evidence. The Hypotheca Credit Score evaluates multiple signals. These are related but separate parts of the credit system. ### Example **Qualifying payment history** * Receipt 1: confirmed. * Receipt 2: confirmed. * Receipt 3: confirmed. * Two distinct payer addresses. * Latest receipt within 30 days. * Approved facilitators. * No suspicious pattern detected. **Result:** Payment verification passes. **Insufficient payment history** Only two receipts are verified. **Result:** Payment verification fails because the minimum receipt requirement is not satisfied. ### Implementation note The verification flow uses `eth_getTransactionByHash` against the Robinhood Chain RPC to validate the underlying transaction. It uses that result to confirm the transaction before the receipt contributes to payment evidence. --- # 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/technology/payment-verification.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.