Why Blend integration breaks during collateral auctions
Blend integration starts with a simple fact: a perpetual NFT loan holds the collateral not with the borrower but in the contract.
While the position is alive, the token is locked, and the position health factor is recalculated every time the collateral price and debt principal change.
As soon as it approaches the liquidation threshold, the contract is entitled to put the collateral up for auction — and from then on, everything depends on how quickly the integration learned about it.
The gap usually occurs not on a method call but on state polling. A service that checks positions every few minutes learns about crossing the boundary with a delay, while the auction window fits into a handful of blocks.
Collateral auction monitoring based on periodic reads cannot keep up: by the first request, the price has already moved and some lots are closed.
The second gap is bid processing. When the step and upper bound are calculated manually, the operator is late: the transaction goes out after the lot closes, fails to meet the conditions, or outbids its own bid.
The collateral is sold below market price, and the borrower loses not only the position but also the token with its history.
The third layer is fault tolerance. Without an event log and repeatable handlers, resending a bid duplicates the charge, and a missed auction cannot be replayed retroactively.
How this is closed — calculating the factor on every block, subscribing to contract events, and automatic bidding within a predefined range — we break down below.
What a managed loan provides: liquidity and risk control
After connecting to Blend, the position stops being a black box: collateral state, health factor, and the auction queue arrive in a single event stream.
Already here you can see which loans have approached the liquidation boundary — the reaction begins not after the liquidation event, but several steps before it.
Next, collateral management kicks in. The module compares the current factor with the target and, during a drawdown, adds collateral or partially repays the debt; thresholds are configured for the risk profile rather than taken by default.
In practice, up to 80% of positions exit the liquidation zone without manual intervention, while the rest go into a separate queue for review.
At the same time, bid automation works: as soon as an auction opens, the system places a pre-calculated limit step by step, relying on liquidity and market depth.
Auction reaction time decreases from hours to tens of seconds — the position is bought out while the price has not yet fallen further.
The failure class that disappears is "we came in the morning and the collateral had already been sold." Loan risk control is moved into a separate layer: collateral limits, stop conditions, a log of every action with the ability to manually prohibit it.
If the position still cannot be held, exit from liquidation follows an agreed scenario, without racing against other bots.
Connection methods: direct calls, intermediary service, hybrid
The choice of connection method to the protocol determines how quickly new loan offers, auction bids, and collateral state changes appear in the system — and who is responsible for a failure along the way.
Direct contract calls read data without a wrapper layer and do not require trust in third-party code, but we write all the surrounding integration layer: reconnection, resubmission, and error handling.
The intermediary service takes on this routine, but adds a second point of failure and a delay between an event on the network and its appearance in the interface. The hybrid scheme reads critical data directly, while operational and analytical data go through the intermediary.
| Option | When it fits | Limitations and overhead |
|---|---|---|
| Direct contract calls | Fresh data and full control are needed: your own wallet, your own signing rules, minimal trust in third-party code | In-house handling of connection drops and retries, higher requirements for node resilience, longer launch |
| Intermediary service | Quick start is needed: auction monitoring, notifications, reporting without your own wrapper layer | Dependence on third-party availability and request limits, delay of seconds, some scenarios unavailable |
| Hybrid scheme | There are critical operations (buyout, refinancing) and bulk reads for analytics | Two integrations instead of one, periodic source reconciliation required, more expensive to maintain |
We handle critical collateral operations through direct calls, while bulk reads and notifications go through an intermediary service with a fallback route. Before launch, we run failure scenarios: node unavailability, data mismatch between sources, state rollback. This check shows which route remains operational when the primary fails.
Implementation stages: from collateral audit to handover of procedures
A perpetual loan has no repayment date: the position remains open as long as the health factor holds, and when it falls below the threshold, an auction starts.
Below is the workflow for integration with Blend, in which handover includes not only contracts but also working procedures.
- Collateral position audit. We export active collaterals, calculate the health factor, interest rates, and liquidation thresholds, and separately mark positions in the borderline zone — we get a risk map and priorities.
- Interaction scheme. We fix roles: who creates and accepts offers, what the service does itself, and what requires human confirmation. Separately, we describe the collateral price source and system behavior when data diverges.
- Access setup. For each process — a dedicated wallet with a threshold signature and operation limit; key rotation is described in advance so that withdrawal of funds does not depend on one person.
- Loan and offer cycle. We implement submitting and canceling an offer, acceptance, refinancing, and early repayment. Every action is idempotent: a repeated request does not create a second transaction.
- Monitoring setup. Subscription to contract events, warning thresholds as liquidation approaches, alerts to multiple channels with escalation if the first does not acknowledge receipt.
- Test environment. We run a sharp price drop, lot start and buyout, oracle unavailability, duplicate event delivery, and transaction rollback — only after that do we roll out to production.
- Handover and training. We hand over procedures, diagrams, and the auction action sequence, and review incidents with the client's team.
What remains with you: diagrams, access policies, documentation
Integration with Blend does not end with working code. We hand over a set of artifacts that your team can use to spin up the environment, explain any decision, and continue development without a contractor.
- Integration configuration — network connection parameters, supported collections, loan term and size limits, behavior during state desynchronization.
- Flow diagrams — the path of an application from wallet to auction, branching points, and rules for exiting a stuck transaction.
- Key access policies — who signs which operation, where keys are stored, how rotation works, and where to view the action log.
- Auction response procedure — trigger thresholds, decision window, escalation procedure, and notification templates for the on-call operator.
- Solution documentation — module descriptions, data formats, rationale for the chosen scheme, and a list of known limitations.
- Team instructions — analysis of typical failures, diagnostics, manual intervention, and safe rollback to the previous state.
Handover to production follows a checklist: access, alerts, KPIs, on-call staffing. We confirm each item at acceptance together with your engineer — without the phrase "it works on our staging environment."
Case: Blend integration and collateral auction monitoring
Before
NFT-collateralized positions were managed manually: an on-call operator checked loan statuses in a spreadsheet every few hours and made early repayment decisions "by eye." Between checks, the loan passed the point at which it is put up for auction, and the collateral was sold at auction below market. Reaction took hours, and some assets were lost irretrievably.
What changed
We connected Blend and moved auction monitoring into a separate service: it listens to events for each position, recalculates the buffer to the threshold, and maintains a notification queue with escalation until work on the loan begins.
Rules define at what buffer it is more profitable to repay the loan on your own and when it is wiser to enter the auction and buy back the collateral. A separate branch confirms that after top-up the position has returned to the safe zone and removes it from monitoring.
Effect: reaction time decreased from 4–6 hours to 3–5 minutes, the share of positions reaching auction fell from 18% to 2%, and the share of preserved collateral assets increased from 63% to 96%.
The auction log and history of triggered rules remain as reporting: you can see what decision was made, when, and how it ended.
How does a perpetual NFT loan differ from a fixed-term loan?
A fixed-term loan lasts until the repayment date: the borrower returns the principal and interest by the deadline, otherwise the protocol initiates collateral liquidation.
In Blend, a perpetual loan is structured differently — there is no repayment date, the position remains open as long as the collateral covers the debt with a buffer, and it can be closed at any time. The price for this is not a term but constant monitoring of the position health factor.
The position health factor is the ratio of collateral value to debt, calculated using the oracle price rather than the last trade on a thin market. As long as it is above the threshold, the borrower pays only interest.
If the NFT price falls or the rate rises, the factor declines and the safety margin disappears — the risk here is market-driven, not calendar-driven.
This is the fundamental difference: a fixed-term loan has a deadline known in advance, while for a perpetual loan the liquidation decision is made by the market.
Below the threshold, the auction starts: the collateral is listed with a price reduction step, the first bids cover the debt with a surplus, then the price drops until a buyer is found.
The proceeds repay the debt and accrued interest, the remainder is returned to the borrower; if the auction was insufficient to cover it, the lender covers the difference.
For integration, this means an event stream rather than scheduled polling: auction start, bids, position closing. It is important for the engineer to see the decline in the factor before the auction starts — then the owner has time to add collateral or repay part of the debt.
Technical concerns before starting work
We address typical technical concerns before starting — they determine the access scheme, failure modes, and how much will need to be touched in the existing system. Below are direct answers, each of which we verify during the assessment stage.
To whom and how are contract keys transferred?
Private keys and owner rights remain with you. We work through a multisignature wallet or hardware signing module: engineers are granted roles for reading state and preparing transactions, while signing is performed by your side.
This is sufficient for building and verifying the logic — without issuing keys, we test on a local copy of the network.
What happens during a sharp market move?
When the collateral price changes, loans enter the liquidation zone unevenly. The monitoring service recalculates the health factor of each loan and sends a notification in advance, before the threshold is crossed.
As the boundary is approached, a predefined scenario is triggered: adding collateral, partial repayment, or listing for auction — according to your risk policy.
What if an external service is unavailable?
Network access providers and price sources fail regularly. We set up two independent providers, a retry queue, and a cache of the last confirmed state.
Calculations continue using valid data, and discrepancies between sources are flagged and included in a report rather than leading to a false liquidation.
Can already written code be modified?
Yes. First, we determine where signing is, where loan parameters are calculated, and where module boundaries are. We connect new monitoring via adapters without stopping current processes and leave the ability to return to the previous version. We rewrite legacy areas that impede fault tolerance selectively, not entirely.
Let's discuss your task and come back with an estimate and plan
An accurate estimate depends on input data: the more specifically the process is described, the fewer assumptions make it into the work plan. Before discussing the task, gather what you already have on hand — this will be enough for the first version of a stage-by-stage plan.
- accesses: read keys to a node or indexer, a test environment, and a sandbox for running scenarios;
- list of positions: NFT collections, collateral pairs and pools that require monitoring;
- role scheme: who issues loans, who confirms auction actions, who has rights to withdraw funds;
- contract addresses and a registry of active loans, if the integration is added to an existing system;
- monitoring scenarios: position health threshold, notification channel and recipient when it is breached;
- infrastructure constraints: occupied services, requirements for logging operations and storing history.
In response, you receive an estimate and a work plan with stages, connection order, rollback point, and critical dependencies. We separately show the role scheme and the path of an auction event to the signal — at which step it appears and who receives it.
Preparation for launch
After the scope is agreed, we deploy the test environment, move your scenarios into verifiable ones, and fix what result we consider achieved.
Preparation for launch does not slow down development: while access is being configured, engineers are already assembling the framework of the integration layer.
Describe the task in free form and attach a list of positions — we will come back with an estimate and work plan.