Skip to main content
Every read in the SDK returns an entity: a typed class defined in @iris-credit/core-sdk whose derived values mirror the Iris contracts exactly. The math is framework-agnostic and runs offline — positions can be projected to arbitrary timestamps without an RPC; viem is only needed to hydrate entities from the chain.

Reading through the entity

The client.iris.core(chainId) entity exposes one getter per input a flow takes. Flows are fetch-first, so one fetch can feed several builds and a stale build never hides a fetch:
Every getter accepts optional FetchParameters (blockNumber, blockTag, stateOverride) for historical or state-overridden reads.
getPositionData reads the whole venue state. Prefer getLoanData for flows that only need the loan, and hand an AccrualPosition’s .loan to those flows instead of re-fetching.
Outside the entity, every fetcher is also exported standalone from @iris-credit/core-sdk (fetchLoan, fetchAccrualPosition, fetchVenue, fetchBlm, …) — or, by importing @iris-credit/core-sdk/augment once, attached to each entity class as a fetch static:

Offline math

AccrualPosition carries the whole position model. Health, repay pricing and withdraw ceilings are plain property reads, and accrueLegs(timestamp) projects the position — venue indices included, using the venue’s own rate model — to any timestamp:
Onchain operations are mirrored as pure transitions returning a new position — repay, liquidate, liquidateBond, supplyCollateral, withdrawCollateral, supplyBond, withdrawBond and refinance — each accruing and rebasing exactly as Iris does:
Venue fields are live onchain observations and must come from the block being evaluated. Position math composed with stale venue data (old indices, an old price) silently diverges from Iris’s onchain results.

Units & precision

The SDK follows the same conventions as the Iris API:
  • Rates, LLTVs and fees are WAD-scaled (1e18). A fixedRate of 81000000000000000n is 8.1% simple annual interest.
  • Amounts are in the token’s own decimals — read decimals off a fetched Token.
  • Everything is bigint. No floats anywhere; format for display with @iris-credit/iris-ts’s format helpers.
The contracts store rates and LLTVs BP-compressed (1e14) to fit small integer slots. The fetchers rescale them to WAD on the way in — only a raw Iris.getLoan call returns the compressed values.

Bond requirements

Blm computes the bond a quote requires without a bondRequirement contract call:

Addresses & registries

Two static, per-chain sources ship with the SDK, both narrowed to the exact chain by their getter:
  • getChainAddresses(chainId) — what is deployed: the Iris core, BLMs, bundler adapters, venue adapters and common tokens.
  • getChainRegistry(chainId) — what is enabled on the Iris contract: venue ids, accepted bond LLTVs, and the market data payloads (recorded as preimages, since the contract only stores keccak256(data)).
Enablement is append-only onchain, so registry entries can only ever be stale-incomplete — never stale-wrong. Solvers can quote from the registry offline, while the fetchers re-verify mutable state (BLM params, whitelist entries, fee) at runtime.
Both sources are compile-time constants — supporting a new chain means a new SDK release. Fetchers that resolve a contract from the registry throw UnsupportedChainIdError on an unknown chain.

EIP-712 payloads

The signature builders return typed data ready for viem’s signTypedData — the same payloads Iris verifies onchain:
  • getQuoteTypedData(chainId, quote) — a solver’s Quote, consumed by take
  • getAuthorizationTypedData(chainId, authorization) — granting or revoking a manager on Iris
  • getPermitTypedData(args, chainId) — an ERC-2612 permit
  • getPermit2PermitTypedData(args, chainId) — a Permit2 allowance (PermitSingle)
  • getPermit2TransferFromTypedData(args, chainId) — a Permit2 signature transfer
Most integrations never touch these directly: transaction flows collect signatures through their requirements, and signResponse wraps the solver side.