If a protocol's documentation makes no mention whatsoever of soft-liquidation-related terms, can I directly conclude it uses traditional liquidation?
A reasonable inference, but worth one more step of confirmation. Most protocols adopting a soft liquidation mechanism, since it's a relatively advanced, marketing-worthy design feature, usually explicitly describe it in documentation, not likely to deliberately hide this mechanism's existence; if documentation makes no mention at all, it's reasonable to infer this protocol most likely uses traditional liquidation.
But a worthwhile extra step of confirmation is directly querying the protocol's smart contract code (if the protocol has publicly verified source code), confirming whether the contract genuinely has only a single liquidation function, with no code corresponding to gradual adjustment logic at all. This step mainly rules out the relatively rare but genuinely possible gap of 'the protocol documentation isn't sufficiently complete, but actually a similar mechanism has been implemented, just not specifically emphasized.' In most cases, documentation and contract code align, but if you're committing a larger amount of capital, spending a few extra minutes on this cross-verification is a worthwhile extra safeguard.
When verifying the smart contract, if I can't read code, is there an easier alternative way to get started?
A few alternative ways that don't require coding capability: verify whether the protocol has undergone a security audit by a well-known third-party firm with a publicly released audit report — this kind of report usually describes the protocol's liquidation mechanism design (including whether soft liquidation is adopted) in relatively plain language, letting you obtain a professional firm's verification result without needing to read through smart contract code line by line yourself; check the protocol's official community (such as Discord or a governance forum), searching whether community members or the development team have publicly discussed the liquidation mechanism design in the past — this kind of discussion thread usually explains how the mechanism operates in relatively accessible language, far easier to understand than reading code directly.
Another relatively accessible approach is directly using a blockchain explorer, searching for this protocol's actual past liquidation-related transaction records (no need to read contract code, just observe the transaction pattern — is it one-time large amounts, or a series of small amounts) — the on-chain detective technique for verifying a JIT liquidity attack covered in an earlier article applies the same logic here too, equally applicable when verifying a liquidation pattern.
If a protocol offers both soft liquidation and traditional liquidation options simultaneously, letting the borrower choose, is this design reasonable?
This kind of hybrid design genuinely exists, and to some extent is a reasonable compromise — different borrowers' willingness and ability to 'actively manage their position' inherently differs. Some users want more buffer space and a chance to actively remediate, willing to accept a relatively higher processing fee in exchange; other users lean toward simple and direct, preferring the traditional liquidation model's lower fee structure in exchange for a clearer, easier-to-understand trigger rule, not needing to continuously watch the soft liquidation stage's progress. Letting a borrower choose the liquidation mode suited to their own risk preference and management effort, to some extent, better satisfies different users' actual needs than forcing everyone to use the same single mechanism.
If the protocol you use offers this option, it's worth thinking through which type of user you are before establishing a position — if you plan to adopt a relatively passive strategy without frequently actively intervening in management, the traditional liquidation model's clear threshold might actually suit you better, since the buffer period soft liquidation gives you, if you don't genuinely use it to actively remediate, to some extent only delays when the problem occurs, not genuinely lowering the ultimate risk. Understanding this layer helps you, when given a choice, make a decision that genuinely fits your own actual operating habits, rather than mindlessly choosing soft liquidation purely because it 'sounds safer.'
Is a newly launched protocol's soft liquidation mechanism, not yet having weathered a genuine stress test, worth trusting?
This needs to be viewed more cautiously, for a reason similar to logic covered in an earlier article — a mechanism looking reasonable in theoretical design doesn't mean it'll actually operate as smoothly as expected under genuine extreme market conditions. One of soft liquidation's core assumptions is that market liquidity is sufficient to support continuous, batched small-scale cash-outs — if this assumption itself doesn't hold up under a genuinely stressed scenario (say, an extreme liquidity crunch condition similar to Black Thursday), the soft liquidation mechanism might not operate normally as designed, and could even, due to the mechanism's own complexity, produce new problems unanticipated at the theoretical design stage.
For a newly launched soft liquidation mechanism without a genuine stress-test track record yet, a more cautious approach first views this mechanism's protective effect with a relatively conservative mindset, not directly assuming your position is genuinely safer than a protocol using traditional liquidation just because the protocol's marketing copy emphasizes 'safer gradual liquidation.' You can continuously watch whether this mechanism has been through actual testing during subsequent market stress events after launch — if, after a period, it genuinely operates well under real stress, that's more concrete evidence worth trusting, rather than simply believing in a theoretical design not yet verified.
An earlier article covered soft liquidation's mechanical principle — once a position falls below the safety threshold, rather than immediately auctioning in full, a gradual adjustment mechanism activates, giving the borrower room to actively remediate. But not every protocol adopts this mechanism, and verifying it isn't difficult. This article teaches you how to specifically judge whether a protocol uses traditional liquidation or soft liquidation, plus details worth noting during the verification process.
The most direct verification starting point is the protocol's official documentation or technical whitepaper. Traditional liquidation usually defines only one liquidation threshold (say, 'collateralization ratio falling below 150% triggers liquidation'); soft liquidation usually explicitly defines two different thresholds — a relatively looser soft liquidation trigger point, and a stricter full liquidation point. If the documentation contains terms like 'gradual,' 'partial liquidation,' or 'recovery mode,' or explicitly describes two different liquidation stages, this is usually direct evidence a soft liquidation mechanism exists.
Documentation's description doesn't necessarily fully reflect the actual on-chain code logic — a safer approach is directly querying the protocol's liquidation-related smart contract, searching for function names corresponding to soft liquidation logic (such as function names containing terms like `partialLiquidation`, `gradualAdjust`, or `recoveryMode`), and confirming whether these functions are genuinely enabled on-chain, not just reserved code that's never actually triggered.
A mechanism theoretically written into the contract doesn't mean it genuinely operates as designed in practice. Check whether this protocol has ever had a position hit the soft liquidation threshold in the past, and if so, specifically review the on-chain record — do you genuinely see a series of small, batched collateral adjustment transactions, rather than a one-time full auction; does the time interval between these transactions match the gradual adjustment cadence the protocol documentation describes. If you can find this kind of actual case, it means the soft liquidation mechanism isn't just theoretical design, but genuinely operated under real market conditions.
One of soft liquidation's core value propositions is that the processing fee should be noticeably lower than traditional liquidation's liquidation bonus discount. A concrete way to verify this is finding the fee ratio the protocol documentation sets separately for the soft liquidation stage versus the full liquidation stage, comparing the two directly. If the so-called soft liquidation stage's fee ratio is actually similar to traditional liquidation's, then even if the mechanism is formally gradual, it hasn't genuinely lowered the cost a borrower bears during this stage — worth putting a question mark on this protocol's soft liquidation design.
Some protocols in the market genuinely use terms like 'soft liquidation' in their marketing copy, while the actual mechanism design doesn't genuinely achieve gradual adjustment's core spirit. Especially worth watching for during verification: once soft liquidation triggers, does it genuinely give the borrower a meaningful reaction window (say, hours to days), or does the so-called 'soft liquidation' actually still complete the vast majority of position adjustment within an extremely short time (say, the same block), just with a more gentle-sounding name; and does the soft liquidation stage's collateral adjustment genuinely proceed proportionally, in small steps, or is it named soft liquidation while the first trigger already adjusts away most of the position, not substantively different from traditional liquidation.
Next time you assess whether to put capital into a lending protocol, don't just feel reassured because the protocol's marketing copy mentions the term 'soft liquidation' — spending time walking through the four verification steps above helps you more accurately judge whether this protocol's liquidation mechanism genuinely provides extra buffer protection, or is just a traditional mechanism with a different name. Understanding what processing flow your position genuinely goes through the moment it dips below the safety threshold is a concrete detail that shouldn't be led by marketing terminology, but personally verified, when assessing any lending protocol's risk profile.