Euler cluster

An Unwind market uses a cluster of Euler EVaults rather than one pooled product vault. A completed leveraged position belongs to the user through an Ethereum Vault Connector account. Per-request escrows use the same lending market while subscription or redemption settles outside it.

Vault roles

The cluster has four functional vaults:

PSBA means pending-settlement base asset. Each direction has its own mintable PSBA token and collateral EVault. Wind and unwind can share the real collateral and debt vaults, but they do not share PSBA accounting.

The debt vault’s oracle values both the real collateral and PSBA. Its collateral configuration defines borrow and liquidation limits. Its interest-rate model sets the cost of debt. Read these from the vault; they are live configuration.

Each market sets who can change them. The vault’s governor sets LTVs and the interest-rate model. The oracle address is fixed when the vault is created, but it usually points at a router whose price routes have their own governor, which can be a different address.

EVC accounts

The Ethereum Vault Connector groups an owner address with related sub-account addresses. A position sub-account enables the tokenised asset EVault as collateral and the base asset EVault as its controller.

Managers verify that a requested sub-account belongs to the authenticated EVC owner. The manager call itself executes on behalf of that owner. The position sub-account is passed as a separate function argument.

Every request receives a deterministic escrow address. For a wind, the user authorises that predicted escrow as an operator for the position sub-account in the same batch as the request, because wind finalisation needs the authority to move the completed debt into the account. An unwind request itself needs no operator authority: the collateral shares move under a share approval the batch grants to the manager on behalf of the sub-account, and taking over the debt needs no permission from the account that is relieved of it. Unwind finalisation repays the escrow’s whole debt and returns any leftover collateral shares by plain transfer, so it does not need the authority either; if the grant exists, the escrow only uses it to revoke itself.

Wind transition

A wind request creates an escrow, mints wind PSBA, deposits it in the wind PSBA EVault, and borrows the base asset. After the external subscription is fully attributed to the request, finalisation deposits the delivered tokenised asset in its collateral EVault. The escrow withdraws its PSBA to the manager, transfers the collateral-vault shares and accrued debt to the user’s sub-account, and removes its operator authority. The manager burns the returned PSBA.

Unwind transition

An unwind request moves a selected amount of collateral-vault shares and debt from the user’s sub-account into a new escrow. The manager mints unwind PSBA in the same native units as the collateral assets being redeemed. The escrow deposits that PSBA and withdraws the real tokenised asset to the manager, which submits it for redemption through the market adapter.

After the full request is claimable, finalisation uses proceeds to repay the escrow’s whole remaining debt. It returns any residual collateral shares to an EVC sub-account owned by the Receipt NFT holder, withdraws PSBA, and removes the escrow’s operator authority if it was granted. The manager burns the returned PSBA and pays the remaining base asset.

Hooks and access

EVaults can use Keyring hooks to restrict account and token operations. Managers hold the hook administration needed to grant a request escrow temporary access. They revoke it after finalisation. Finalisation and liquidation preserve any qualifying permission that existed before the manager granted it.

The hook checks and a manager’s explicit credential checks serve different purposes. The hook protects vault operations. A manager can also require a credential at a product entry point, such as a wind request or auction bid.

Loss allocation is a hook concern too, not a manager one. A sidepocket variant of the hook caps withdraw and redeem per account against a cumulative liquidity index the admin advances as funds are recovered, and disables share transfers while it is active. Nothing in the managers repays a request’s debt on a user’s behalf.

Liquidation

Euler is the source of truth for solvency. Ordinary user positions use Euler native liquidation. An escrow that is already redeeming uses Unwind’s auction to select a liquidator, then a shared liquidator contract invokes Euler native liquidation against that escrow.

Liquidation removes debt and seizes PSBA collateral. The manager burns the seized PSBA. It does not cancel the external redemption or create a separate liquidated escrow state. The request remains redeeming until settlement and normal finalisation, which reserves the auction winner’s payout before paying the Receipt NFT holder.

Integration invariants

• Read collateral, debt, LTV, health, vault configuration, and prices directly from Euler contracts when freshness matters.
• Treat indexed request data as workflow history, not the source of live financial state.
• Pair every request ID with its manager address in multi-manager systems. The request hash is manager-local even though each manager produces a unique CREATE2 escrow address.
• For a wind, predict and authorise the escrow against the correct position sub-account before request creation. An unwind needs a collateral-share approval to the manager instead.
• Call the canonical EVC batch function directly. Unwind does not require a separate general-purpose batch helper contract.

Concrete vault and manager addresses belong on each market page.