Skip to main content
POST
Builds the setIdentityGates transaction that installs, replaces or clears the market’s borrower register and provider register in one call. The wallet holding DEFAULT_ADMIN_ROLE on the market signs it. The same POST with txHash verifies the mined transaction and records it. The borrower register gates openLoan and borrowMore on the market. The provider register is read by every registered vault before it admits a depositor, because the market itself takes direct deposits only from the operator wallet and registered vaults. Get Identity Gates describes both doors in full.
A change applies from the next open, draw, vault deposit or share transfer. Existing loans and vault holdings are not examined again, and repaying, closing and redeeming are never gated.

​
Choose What Each Side Gets

Each field is read on its own:
  • Omitted: the market keeps the register it has now.
  • An address: that register is installed.
  • null, an empty string or the zero address: the register is cleared, and the side is left without one.
Sending only borrowerRegistry therefore changes the borrower side and leaves the provider side as it is. Instead of an address, a side can name one of your verification profiles in borrowerProfile or providerProfile. The profile’s eligibility register is then installed, so the side admits exactly the wallets admitted under that profile. An address sent beside a profile must name the same register, or the request is refused with GATE_PROFILE_CONFLICT. A profile without an eligibility register is refused with ELIGIBILITY_REGISTER_NOT_SET. A side can also name one of your whitelists by its ID in borrowerAccessList or providerAccessList. See Whitelists as Gates. A side takes a profile or a whitelist, not both: sending both is refused with GATE_SOURCE_CONFLICT, and so is an address beside a whitelist that names a different contract.

​
Whitelists as Gates

A whitelist admits exactly the wallets its owner and managers listed, and examines no identity. Create and maintain one with the whitelist routes. Only a whitelist your instance keeps and has not archived can be named by its ID. Any other is refused with 404 ACCESS_LIST_NOT_FOUND, details.field naming the field you sent. A whitelist of another instance can still be installed by its address.
  • Borrower side. A whitelist cannot be the borrower gate of a MARKET market, which lends to professional borrowers only and needs a professional gate. That is refused with 409 ACCESS_LIST_NOT_ALLOWED, details.reason: MARKET_PRICE_BORROWER_GATE.
  • Purpose. A whitelist kept for depositors (purpose: DEPOSITOR) cannot become the borrower register, and one kept for borrowers (BORROWER) cannot become the provider register. That is refused with 409 ACCESS_LIST_PURPOSE_MISMATCH. A list kept for ANY fits both. The owner changes the purpose with Update Whitelist.
  • Provider side. A whitelist gates the market’s liquidity providers only on the attestation of whoever curates its members. A list your instance neither keeps nor controls through a verified wallet that owns or manages it is refused with 403 ACCESS_LIST_NOT_CONTROLLED. Every request that installs a whitelist as the provider register must send attestIdentifiedMembers: true, which confirms that the list holds identified wallets only, or it is refused with 400 ACCESS_LIST_ATTESTATION_REQUIRED. The first attestation of a list by your instance is written to the audit log as LENDING_ACCESS_LIST_ATTESTED.
The purpose, control and attestation checks run only on a side the request changes. When whether an address is a whitelist, or whether your wallets control it, cannot be read, the request answers 503 ACCESS_LIST_UNREADABLE and decides nothing.
The confirm call runs the provider-side checks again on a whitelist the transaction installed, and records nothing when one fails. The transaction has already changed the market on chain by then. Send attestIdentifiedMembers: true on the confirm call as well: confirmWith.body carries it when the build was attested.
Once a whitelist gates the market, its lender of record can maintain it only as a manager of the list. Get Identity Gates offers that step in accessListSteps.

​
Professional Borrowers

A MARKET-priced market carries the free-hand realization path under § 1259 BGB, which is open against professional borrowers only. Its borrower register must therefore admit professional clients and nobody else. The API judges that from the verification profiles bound to the register as their eligibility register, read across every instance on the market’s network and environment, not only yours. The register qualifies when:
  • At least one such profile admits wallets to it. A profile bound in the EXTERNAL mode admits nobody through Trusset, so it is not counted.
  • Every profile that admits wallets to it is limited to professional clients (professionalOnly: true): the PROFESSIONAL or ELIGIBLE_COUNTERPARTY preset, or a custom profile limited to professional clients.
  • Every one of those profiles is in the REGISTER mode, so its own instance signs each admission. A register bound as an instance register does not qualify.
A profile of another instance counts like one of yours. When one that is not limited to professional clients admits wallets to the same register, the register does not qualify, and the refusal names it only as a verification profile of another instance. The register deployed for your own PROFESSIONAL profile, named with borrowerProfile: "PROFESSIONAL", is the direct way to a qualifying gate. Any change that would leave a MARKET market with a borrower register that does not qualify is refused with PROFESSIONAL_BORROWER_GATE_REQUIRED, details.field: "borrowerRegistry". That includes a change to the provider side alone while the borrower register does not qualify, so fix the borrower side first, or in the same call. Until the borrower register qualifies, the API prepares nothing that lends on the market or moves liquidity into it. Open Loan, Borrow More, Add Liquidity and the register action of Register Vault refuse with the same code, and so do vault allocations, draw caps and rebalances for the market in the Issuer Portal. Get Identity Gates reports the state as borrowerGateCompliant. When the profiles behind the register cannot be read, those calls answer 503 STATE_UNAVAILABLE and decide nothing.
This rule is enforced by the API, not by the market contract. The contract only asks the borrower register whether a wallet is verified, so a transaction built and signed outside this API is not refused on this ground.

​
Vaults Registered on the Market

On a current market every registered vault examines its depositors against the provider register, so a new provider register must fit the vaults already registered:
  • A vault with its own register needs the provider register to be that same register, or none.
  • A vault without a register of its own takes its depositor gate from the provider registers of the markets it funds, and keeps the first one for good. Once a provider register is installed, it can be neither replaced nor cleared while such a vault is registered.
A change that breaks this is refused with PROVIDER_GATE_MISMATCH, and details.conflicts lists each vault as { vault, register }, with register null for a vault without one. Set the provider register to the vaults’ register, or deregister those vaults first with Register Vault.

​
Registers That Must Stay

A MARKET-priced market must keep a borrower register. The API refuses to clear it with IDENTITY_REGISTRY_REQUIRED, and the contract would revert the same change. On a current market the provider register can be cleared, since the market takes no third-party deposit that it would guard. A vault without a register of its own registered on the market still blocks the change, see Vaults Registered on the Market. On an older market whose pool is open to third-party providers, the API refuses to clear the provider register with IDENTITY_REGISTRY_REQUIRED. details.field names the side in both cases. A market on the earlier single-register implementation examines both sides through one register and cannot change it. It is refused with MARKET_UPGRADE_REQUIRED until the admin moves it onto the current implementation with Upgrade Market.

​
The Previous Trusset ID Register

The Trusset ID Register on Sepolia moved to 0xEf244c4Bd4d71Bd9A30EDF6Edef7CCC72642291a on 10 October 2026. The previous register, 0xE9114c40934f6fB6BB317935156b731f7A86D006, takes no new identities. A gate that still reads it admits the wallets verified on it before the move and refuses every customer verified since 10 October 2026. Get Identity Gates marks such a side with retired: true. Until the side moves, a wallet that register does not admit is refused with 409 IDENTITY_GATE_RETIRED, and the refusal names the move to the current register. Open Loan, Borrow More, Add Liquidity and Deposit to Vault return it. Install the current register on both sides:
Or send only the side that reads the previous register. The other rules on this page still apply: the borrower side of a MARKET market must qualify as a professional gate, and a new provider register must fit the vaults registered on the market. Naming the previous register as a new gate, on a side the request changes, is refused with 422 IDENTITY_REGISTRY_RETIRED. details carries field, registry and currentRegistry. A side the transaction leaves on the previous register is not refused, for example when only the other side changes. The calldata response then carries one warnings entry per such side, { code: "RETIRED_REGISTRY_KEPT", field, registry, message }.
A vault keeps its register for life. A vault registered on the market whose own register is the previous Trusset ID Register needs the provider register to be that register or none, so moving the provider side to the current register is refused with PROVIDER_GATE_MISMATCH while that vault is registered.

​
Checks Before the Calldata

Every register named is probed first. One that cannot be reached is refused with IDENTITY_REGISTRY_UNREADABLE, and one that does not answer isVerified(address) with IDENTITY_REGISTRY_INCOMPATIBLE, because as a gate it would refuse every party. ERC-3643 identity registries, ONCHAINID-based registers and the Trusset register all answer. A request that would leave both registers as they are is refused with IDENTITY_GATES_UNCHANGED rather than answered with a transaction that only costs gas. There is no unchanged: true response on this endpoint.

​
Path Parameters

​
string
required
The market’s record ID, as id on List Markets, not its contract address. See Market IDs.

​
Body Parameters

​
string
The borrower register to install, or null, "" or the zero address to clear it. Omit it to keep the current one. An address must be 0x followed by 40 hex characters, all-lowercase or with a valid EIP-55 checksum.
​
string
The provider register to install, or null, "" or the zero address to clear it. Omit it to keep the current one. Same address rules as borrowerRegistry.
​
string
A verification profile key of your instance, 1 to 60 letters, digits, - or _. Installs that profile’s eligibility register as the borrower register.
​
string
A verification profile key whose eligibility register is installed as the provider register.
​
string
The ID of a whitelist of your instance, 1 to 64 letters, digits, - or _, installed as the borrower register. Not accepted beside borrowerProfile.
​
string
The ID of a whitelist of your instance, installed as the provider register. Not accepted beside providerProfile.
​
boolean
true confirms that the whitelist installed as the provider register lists identified wallets only. Required whenever the provider register changes to a whitelist, whether named by ID or by address. Send it on the confirm call too.
​
string
Hash of the mined transaction, as a 0x-prefixed 64-character hex string. Send it to confirm; the registers are then read from the transaction’s IdentityGatesUpdated event, so the other fields are not needed, apart from attestIdentifiedMembers for a whitelist provider gate. Omit it to receive the calldata.

​
Response Fields

The calldata response:
​
object
The four signer fields are absent when the role lookup itself fails. The confirmed response:
​
object
Confirming records an IDENTITY_GATES_SET transaction on the market, visible through List Transactions, once per transaction hash, with the registers before and after the change.

​
Error Codes

Refusals from the checks above carry details as an object: field for the side concerned, registry on IDENTITY_REGISTRY_INCOMPATIBLE, priceSource on PROFESSIONAL_BORROWER_GATE_REQUIRED, and conflicts on PROVIDER_GATE_MISMATCH. IDENTITY_GATES_UNCHANGED carries the two registers the market already has. The whitelist codes are explained in Whitelists as Gates. Confirming with txHash can also return any transaction verification error, with the status listed there.