How it works

Wind

The user deposits the base asset and selects target leverage. The system borrows against interim collateral, a pending-settlement base asset (PSBA) minted for the request, on the lending market and submits the deposit request to the tokenised asset source in the same action. While the asset settles off-chain (T+1 or longer, depending on the asset), the interim collateral backs the borrow in the request’s escrow; once the asset is delivered, it replaces the interim collateral and the user, or a Keyring operator on their behalf, finalises the request. The result is an ordinary collateralised position in the user’s own lending market account.

Synchronous markets

Some markets wind synchronously instead: the position opens in a single transaction, with no interim collateral and no separate finalisation step.

Holdbacks

A synchronous wind can carry a holdback. Some issuers subscribe instantly at a price above the latest published NAV (a wedge) and withhold a portion of the collateral, delivering it after the asset’s next valuation. The holdback lands in the user’s wallet rather than in the position, so the position runs at its opening leverage and LTV until the delivery arrives. The wedge and the delivered amount are issuer terms: the amount depends on how the NAV moves, and it is not a guaranteed return.

Permissioned assets and whitelisting

A permissioned asset is a tokenised asset whose transfers the issuer restricts: every transfer requires both parties to be whitelisted by the issuer. Whitelisting is a know-your-customer step run by the issuer, not by Keyring, and it is separate from the Keyring credential the market’s policy requires. A wallet without a whitelist entry cannot receive or move the token, and transfers revert. Winding such a market has two prerequisites: the issuer’s whitelist entry and a valid Keyring credential.

Unwind

The user locks the position; the market’s provider settles the redemption. The request mints a Receipt NFT (ERC-721) that tracks the locked position until fulfilment; each request runs in its own escrow, isolated from every other request.

Settlement runs through the tokenised asset’s own redemption process, within a configured window aligned to the asset’s redemption cycle, at a fixed on-chain fee. The architecture admits other provider types per market.

Once proceeds land, the escrow repays the debt, fees are deducted from the redeemed proceeds, and the remainder goes to the Receipt NFT holder in the base asset.

The request lifecycle

An unwind escrow moves through a small state machine:

1. Initialized. Escrow deployed for the request.
2. Pending. Debt pulled from the user’s account into the escrow.
3. Redeeming. Collateral sent to the provider’s adapter for redemption; interim collateral maintains the lending market position.
4. Finalized. Debt repaid, proceeds distributed, escrow closed. If the position turns unhealthy before settlement completes, the escrow is liquidated instead and the payout is claimable later through the Receipt NFT (see liquidations).

Fees

Fees are paid in the base asset and deducted from redemption proceeds. The Keyring infrastructure fee is set in basis points in each market’s on-chain manager configuration, which is the same value the app displays before a request. A market’s fees are the Keyring fee plus any provider fee the market defines.

Roles

Operation is split so no single party both configures and operates: an admin configures markets, a Keyring operator finalises requests and settles queues on users’ behalf, a liquidation path handles unhealthy escrows, and a safety manager can pause new activity. Liquidations are deliberately never blocked by a pause; see risk.