For the complete documentation index, see llms.txt. This page is also available as Markdown.

Position Management

Overview

Curvance Position Managers are router-style contracts that wrap leverage and deleverage actions inside an isolated lending market. They let users borrow, swap, deposit as collateral, withdraw collateral, swap, and repay through one PositionManager call while the linked cTokens and MarketManager continue to enforce listing, borrowability, collateral caps, debt caps, account liquidity, and repayment rules.

Architecture Design

Core Components

PositionManagementBase

BasePositionManager is the abstract base contract for PositionManager implementations. It provides the shared external entrypoints, callback handling, delegation checks, reentrancy protection, pre/post account-value slippage checks, protocol leverage/deleverage fee handling, and common validation. Concrete managers implement the asset-specific leverage and deleverage conversion hooks.

Shared entrypoints include depositAndLeverage, leverage, leverageFor, deleverage, and deleverageFor.

Specialized Implementations

Each implementation extends the base functionality for a specific asset or protocol path:

  • SimplePositionManager: generic non-native ERC20 leverage and deleverage.

  • SingleSidedVaultPositionManager: ERC4626-style vault positions that enter the vault on leverage and use the simple deleverage path.

  • DualSidedVaultPositionManager: vault positions that can redeem vault shares during deleverage before optionally swapping into the debt asset.

  • NativeVaultPositionManager: native-token vault positions that unwrap wrapped native assets or swap into native assets before depositing.

  • PendlePTPositionManager: Pendle principal token positions.

Key Data Structures

LeverageStruct

Encapsulates all data needed for a leverage operation, including which token to borrow, how much to borrow, and which position token to leverage against.

DeleverageStruct

Contains data for deleverage operations, specifying which collateral to withdraw, which debt market to repay, the minimum debt-asset amount the PositionManager must hold after the deleverage route, and the swap or protocol-specific exit instructions. repayAssets is a floor, not always the final repayment amount. After the route runs, the PositionManager reads fresh debt and repays min(assetsHeld, currentDebt).

Integration Points

Position Managers interact with these Curvance components:

  • MarketManager: authorizes PositionManager contracts, checks token listing, debt caps, collateral caps, account liquidity, repayment review, and redemption review.

  • CentralRegistry: provides protocol-wide configuration, including protocolLeverageFee() and approved external calldata checkers.

  • cTokens and BorrowableCToken: live cTokens are implemented through BorrowableCToken; they are not two separate live role classes. A cToken can receive deposits and can be posted as collateral when market configuration allows it. A cToken is borrowable in a specific market only when marketManager.debtCaps(cToken) > 0. PositionManager flows call borrowForPositionManager on the borrowed cToken and withdrawByPositionManager on the collateral cToken, then cToken and MarketManager logic perform the terminal checks.

  • SwapperLib: executes approved external swap calldata and checks swap value through oracle-priced slippage.

  • External protocols: specific PositionManager implementations handle Pendle, ERC4626-style vaults, and native vaults.

Security Features

The PositionManager architecture combines several safety checks:

  • Swap-level checks through SwapperLib._swapSafe, including approved calldata checkers and oracle-priced value-loss checks.

  • Position-level sanity checks through BasePositionManager.checkSlippage, which compares the account's collateral-minus-debt value before and after the action.

  • Route-specific floors such as expectedShares on leverage and repayAssets on deleverage.

  • Market-level constraints enforced by cTokens and the MarketManager, including listing checks, borrow pauses, debt caps, collateral caps, account liquidity, hold-period checks, and repayment/redemption review.

  • A protocol leverage/deleverage fee taken from the borrowed or withdrawn assets before the manager-specific route runs.

  • Reentrancy protection on the PositionManager entrypoints and the relevant cToken entrypoints.

There is no standalone global max leverage ratio inside BasePositionManager. The practical ceiling comes from market configuration, caps, available liquidity, prices, fees, and route slippage.

Protocol Interactions

During leverage, the user calls depositAndLeverage, leverage, or leverageFor. The PositionManager checks pre/post account value with checkSlippage, calls BorrowableCToken.borrowForPositionManager, receives the borrowed assets in the callback, applies the protocol leverage fee, runs the manager-specific swap or protocol entry logic, deposits the resulting asset into action.cToken as collateral for the account, enforces expectedShares, and then the borrowable cToken performs the terminal MarketManager.canBorrow(...) check.

During deleverage, the user calls deleverage or deleverageFor. The PositionManager checks pre/post account value with checkSlippage, verifies repayAssets != 0, calls cToken.withdrawByPositionManager, receives withdrawn collateral in the callback, applies the protocol leverage/deleverage fee, runs the manager-specific exit or swap logic, requires that the PositionManager holds at least repayAssets of the debt asset, repays up to the account's fresh debt balance, and refunds leftover debt, collateral, and swap-output balances to the owner.

This architecture enables Curvance to support complex leverage strategies across diverse asset types while maintaining protocol security and risk parameters.

Last updated

Was this helpful?