Before the round
These validate the borrower’s request. A failure here returns400 to the borrower and no solver is contacted: nothing to do with you.
Before your endpoint is called
Four 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.On your response
Non-quote, not failure
Before any validation runs, the coordinator checks whether you declined: HTTP404, 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:1
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.2
Request mirror
Quote response requestId mismatch: your requestId must match the request exactly.3
Rate ceiling
Quote response fixedRate exceeds maxFixedRate: you quoted above the borrower’s stated ceiling.4
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.5
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: ….6
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.7
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.8
Permit2 signature
Only for quotes carrying the pair; a permitless quote skips this check. Same two failures, over the Permit2
PermitSingle: Permit2 signature signer mismatch or Permit2 signature is malformed. Sending half the pair is itself a failure: permit2Nonce and permit2Signature must be provided together: ….9
Bond sufficiency
given "bond: X" is less than "required bond: Y": your bond is below what the bond lock module demands for this debt and duration. Compute the requirement before quoting with the SDK’s blm.bondRequirement, which throws rather than returning zero when the BLM prices the debt token at nothing: that quote is unsubmittable and should be dropped, not returned with a zero bond.10
Solver funding
solver "balance: X" is less than "bond: Y": your debt-token balance cannot cover the bond you quoted. The allowance check depends on your funding mode: a permit-carrying quote fails with solver "iris allowance: X" and "permit2 allowance: Y" are both less than "bond: Z" when neither pull route covers the bond, and a permitless quote fails with permitless quote needs a standing iris allowance: "iris allowance: X" is less than "bond: Y", the standing allowance being its only route.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.
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 lock module outside the registry. Solver funding is likewise skipped when your balance and allowances could not be read: no chain connection, a failed read for your solver address, or no registered signing address to read them against. In either case your quote survives the round andIris.take() enforces the requirement instead. Solver binding is 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 lock module, 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:slope and intercept are per-debt-token parameters set by each bond lock module, 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 module are queryable; see Bond.