Risk

Position health

Every unwind request checks the LTV of the portion being unwound against the market’s liquidation threshold with a configured buffer on top: the request is rejected unless that LTV sits the buffer distance below the liquidation LTV, which comes from the lending market itself. Wind requests are bounded by the market’s leverage range and minimum equity instead. Requests accept oracle price updates in the same transaction, so health checks run on fresh prices rather than stale ones.

Illustrative thresholds: a market with an 86% liquidation LTV and a 6-point buffer rejects unwind requests above 80%. Oracle prices are refreshed in the same transaction as the check.

Pause and recovery

A safety manager can pause a manager, which blocks new requests, settlement, finalisation, and most configuration changes. Liquidations are deliberately not blocked by a pause: keeping unhealthy positions liquidatable during an emergency preserves solvency for everyone else. Recovery mechanisms depend on the market’s deployed contracts and lending market. Each market page describes any additional recovery permissions. For the lending market side, see when the tokenised asset side fails.

Isolation and its limits

Each request on an asynchronous market runs in its own escrow: collateral, debt, and interim assets are separated per request, so one user’s exit cannot consume another’s collateral. Positions on markets that wind synchronously carry no escrow; they sit on the user’s own account. Settled proceeds are recorded per request on the manager and liquidation payouts are reserved per request in the auction contract, so one request’s liquidation cannot draw on another request’s proceeds. What the operator controls is timing and, on markets where the issuer delivers part of a wind later, how many of the delivered tokens it attributes to which request. That attribution is final and, for a user with several pending requests, decides what each of them settles for. The operator does not control how a request’s settled proceeds are allocated between debt, fee, auction winners, and holder.

Upgradeability

Escrows, user wallets, the liquidator, the auction, and both managers are minimal-proxy clones of immutable implementations with no upgrade path. Fixing a defect means deploying a new factory, which also gives every user a new user wallet address to be whitelisted again; already-deployed escrows never change either way.

The unwind manager is the exception in one respect: some of its functions are served by a separate contract, and the admin can point them at a different one. Pausing is among them, so that remap reaches the safety manager’s pause control. It is the one part of the system whose behaviour can change after deployment; see smart contracts.

When the tokenised asset side fails

If the underlying asset itself fails (an issuer default, a sanctions event, an exploit on the tokenised asset platform), the safety manager pauses the market. Affected requests keep their escrows and their Receipt NFT claims. Liquidations are not blocked: an unhealthy escrow can still be auctioned, and the winner repays its debt in exchange for a claim on the redemption proceeds. If a request’s settled proceeds fall below its debt, it cannot be finalised and stays escrowed. The same holds if the issuer cancels a redemption, since the manager then has nothing to settle. There is no protocol treasury or insurance backstop.

Loss allocation happens one level down, on the lending market. A hook on the cluster’s vaults can cap withdrawals and redemptions pro rata and freeze share transfers while recovered funds are distributed, which spreads a loss across the cluster rather than restoring it. Recovering value from the failed asset itself happens off-chain, outside the protocol.

Permissioned assets

Markets that list a permissioned tokenised asset depend on the issuer’s whitelist. Every transfer of the asset requires the issuer to have whitelisted both parties, so a wallet that loses its whitelist entry cannot receive or move the token, and transfers revert. See how it works.

Roles

Admin: Configuration; on the unwind manager, also which extension contract serves the extension-routed functions.
Keyring operator: Settles individual requests and finalises them on users’ behalf. Once a configured window has passed after a wind settles, the operator can also finalise it into a replacement account that has authorised the escrow.
Liquidation auction manager: Opens auction rounds for unhealthy unwinding escrows. Bidding needs the market’s auction credential; only the best bidder can execute; expiring a lapsed round and closing a healed one need no credential at all.
Liquidation path: Auction-based for unwinding escrows, credential-gated bidders; native lending market liquidation for active positions.
Safety manager: Pause and unpause; a market page lists any additional recovery permissions. A winner’s payout on a request that is not yet finalised waits for the unpause, because finalisation is paused; payouts on already finalised requests can still be claimed.
Fee recipient: Withdraws accrued Keyring fees. The address is admin configuration, and only it can withdraw.
Factory owner: Deploys markets and marks managers active. Marking is not limited to managers the factory deployed, and only the adapter of an active manager can move funds through user wallets, so this role decides what may touch them.
User wallet factory owner: Sets which tokens the owner-triggered verification transfer may send, and their daily limits.
Interim collateral admin: Controls which contracts may mint and burn the pending-settlement base asset. The managers hold that right.