Smart contracts

Managers target Euler as the lending market: each market is a manager instance bound at deployment to one immutable collateral/debt vault pair, deployed through a factory that serves as the system-wide registry. Solidity ^0.8.20, OpenZeppelin 5.4.0, Ethereum Vault Connector, and the Pyth SDK for oracle updates. Integrators index state through events and view calls.

Architecture

The request-lifecycle contracts are OpenZeppelin minimal-proxy clones: managers (cloned and initialised by their factories), one escrow per request, one user wallet per user, a fee collector per manager, and on the unwind side a shared liquidator and the auction contract. Factories, adapters, the unwind extension, and the pending-settlement tokens are ordinary deployments. Every clone points at an immutable implementation, and each factory holds those implementation addresses as immutables, so fixing a defect means deploying a new factory, not a new market through the existing one. A new manager factory also means a new user wallet factory, which changes every user’s wallet address and so requires fresh issuer whitelisting. Already-deployed escrows never change. The unwind manager splits its logic between a core contract and a delegatecall extension sharing one storage layout, to stay within the contract size limit. Its admin can remap which extension contract serves the extension-routed functions (finalisation, the liquidation hooks, configuration, pausing, fee withdrawal, views); that mapping is the one code path in the system whose behaviour can change after deployment. Request creation, settlement, the receipt NFT, and the remap itself stay in the core.

Three structural facts matter to integrators:

• Escrow addresses are deterministic. The request ID doubles as the CREATE2 salt (keccak256 of the requester and a manager-local nonce), so an escrow address is predictable before the request is submitted. This is load-bearing for wind: the destination sub-account must authorise the escrow as its EVC operator ahead of finalisation. Unwind finalisation does not depend on it.
• PSBA bridges the settlement gap. While real collateral is away being minted or redeemed, a mintable pending-settlement base asset (PSBA) is deposited in a dedicated vault so the escrow’s lending market position stays healthy. It is minted at request time and burned during finalisation. Auction liquidation of a redeeming escrow seizes PSBA, and the manager burns it as the debt is taken over.
• Funds flow through per-user wallets. Each user has one deterministic wallet clone that holds and forwards funds for the tokenised asset platform interactions; see user wallets.

Compliance gating

Wind requests and liquidation-auction bids require a valid Keyring credential for the market’s policy, checked explicitly by the contracts (checkCredential in requestWind and submitBid). Both checks are skipped where the market’s policy id is zero. Unwind requests carry no explicit check: they are gated implicitly, because the Euler cluster’s vault hook credential-checks the operations the request performs against the account’s owner. All checks resolve against the same KeyringCore registry documented under Connect; Unwind is a consumer of Keyring credentials, not a separate compliance system.

In depth