> ## Documentation Index
> Fetch the complete documentation index at: https://docs.iris.credit/llms.txt
> Use this file to discover all available pages before exploring further.

# Validation

> Every check a quote passes, in order, and which ones reject rather than skip.

A quote that fails validation is **dropped silently**. The round continues with the remaining quotes, the borrower never sees the failure, and your endpoint gets no error back. That makes this page the one to read when your quotes are not winning and you cannot see why.

Checks run in three stages: before the round, before your endpoint is called, and on your response.

## Before the round

These validate the borrower's request. A failure here returns `400` to the borrower and **no solver is contacted**: nothing to do with you.

| Check             | Failure                                                                                           |
| ----------------- | ------------------------------------------------------------------------------------------------- |
| Request schema    | Any field missing, malformed, or out of bounds                                                    |
| Supported tokens  | `Token is not supported for collateral: 0x…`; either token is outside the protocol's token list   |
| Registered venues | `venueBitmap has bits outside registered venues: …`; the bitmap names a venue that does not exist |

## Before your endpoint is called

Three filters decide whether you are contacted at all. Failing one is not an error: you simply are not part of that round, and it costs you nothing. Covered in [Eligibility](/rfq/concepts#eligibility).

## On your response

### Non-quote, not failure

Before any validation runs, the coordinator checks whether you declined: HTTP `404`, or `bond: "0"`. Either is recorded as a non-quote and skips validation entirely. Declining is never counted as a validation failure.

### Definitive checks

Every check below rejects the quote outright. They run in this order, and the first failure is the one reported:

<Steps>
  <Step title="Response schema">
    Every field parsed and range-checked. Common causes: a signature that is not exactly 65 bytes, a `deadline` outside the two-minute quote window, a `venueId` above 127, or a numeric field sent as a JSON number instead of a decimal string.
  </Step>

  <Step title="Request mirror">
    `Quote response requestId mismatch`: your `requestId` must match the request exactly.
  </Step>

  <Step title="Rate ceiling">
    `Quote response fixedRate exceeds maxFixedRate`: you quoted above the borrower's stated ceiling.
  </Step>

  <Step title="Venue allowed">
    `Quote response venueId not in allowed venueBitmap: bit N not set in M`. Note that `venueId` is an **index**, not a mask. Venue 1 means bit 1, i.e. the value `2` in the bitmap.
  </Step>

  <Step title="Enablement">
    Your `bondLltv`, `blm`, and `data` must each be enabled on `Iris`. Reported as `bondLltv is not enabled on Iris: …`, `blm is not enabled on Iris: …`, or `market data payload is not enabled on Iris: …`.
  </Step>

  <Step title="Solver binding">
    `quote solver 0x… does not match registered address 0x… for the endpoint`: your `solver` must be the signing address registered for your endpoint.
  </Step>

  <Step title="Quote signature">
    `Quote signature signer mismatch: recovered 0x…, expected solver 0x…` means you signed different terms than you returned. `Quote signature is malformed` means recovery failed outright.
  </Step>

  <Step title="Permit2 signature">
    Same two failures, over the Permit2 `PermitSingle`: `Permit2 signature signer mismatch` or `Permit2 signature is malformed`.
  </Step>

  <Step title="Bond sufficiency">
    `given "bond: X" is less than "required bond: Y"`: your bond is below what the bond liquidity manager demands for this debt and duration.
  </Step>
</Steps>

<Callout kind="info">
  A signer mismatch almost always means a field diverged between signing and responding. The signature covers your quote's terms **and** the request's, so reconstruct from the request you received, not from a cached or re-derived copy.
</Callout>

### Checks that fail open

**Bond sufficiency** is skipped rather than failed when the bond parameters could not be fetched: no chain connection, a fetch failure, or a bond liquidity manager outside the registry. Your quote survives the round and `Iris.take()` enforces the requirement instead. **Solver binding** is likewise skipped when no signing address is registered for your endpoint.

This is the general doctrine: `take()` re-verifies everything on-chain, so the coordinator rejects only on a **definitive** invalid and skips any check it cannot run. Surviving validation here does not guarantee `take()` will succeed.

## Enablement can lag

Enablement is checked against a registry shipped in the SDK. Because enablement on-chain is append-only, a registry **hit** is always correct, but a registry **miss** can be a stale registry rather than a genuinely disabled value.

If you are quoting a bond LLTV, bond liquidity manager, or market-data payload that was enabled on-chain recently and your quotes are being dropped for enablement, the registry may not have caught up. Raise it during onboarding rather than working around it.

## Bond requirement

The required bond scales with both the debt and the term:

```text theme={null}
ratio          = slope × durationDays + intercept
requiredBond   = debt × ratio / 1e18
```

`slope` and `intercept` are per-debt-token parameters set by each bond liquidity manager, both WAD-scaled, with `slope` charged per day. The ratio can exceed `1e18`, so a required bond can exceed the debt itself. Current values for every enabled manager are queryable; see [Bond](/api/iris-core#bond).