NashPoint
NashPoint
  • Introduction
    • Introduction To Nashpoint
    • Current Features & Capabilities
    • Post Launch Roadmap
  • User Documentation
    • Node Contract Overview
    • Node Owner & Rebalancer Roles
    • Portfolio Management
    • Rebalancing & Strategy Execution
    • User Deposits & Shares
    • Asynchronous Redemptions
      • Two Step Process
    • Swing Pricing
    • Processing User Redemptions
    • Management & Execution Fees
  • Developer Documentation
    • Overview
    • Role-Based Access Control
    • Smart Contract Architecture
  • Routers
    • ERC-4626 Router
    • ERC-7540 Router
    • Router Tolerance
  • Creating A Node
  • Asynchronous Redemptions
  • Managing a Node
    • Adding & Removing Components
    • Updating Component Allocations
    • Rebalance Window & Cooldown
    • Rebalancing a Node
    • Managing Rebalancers
    • Processing User Redemptions
      • Reserve vs Component Fulfillment
    • Reserve Management
    • Fees Configuration
    • Liquidation Queue Configuration
    • Max Deposit Limits
    • Operator Permissions
    • Emergency Controls
  • Upgrading a Node
    • Adding Quoters & Routers
    • Custom Router Development
    • Multi-Tier Permissioning
  • Cached Data & Gas Efficiency
  • Swing Pricing Calculations
  • Adding Routers and Components - Step by Step Guide
  • Node Execute Function
  • Resources
    • FAQ
    • Glossary
    • Supported Networks & Protocols
    • Deployments
    • Audits
    • GitHub
    • Telegram
    • NashPoint
  • Node Strategies
    • Test Node A
Powered by GitBook
On this page
  • Standard Redemption (Sufficient Reserves)
  • Component Liquidation
Edit on GitHub
  1. User Documentation

Processing User Redemptions

PreviousSwing PricingNextManagement & Execution Fees

Last updated 19 days ago

Standard Redemption (Sufficient Reserves)

When a user requests a redemption, the swing price penalty is calculated immediately based on current reserve levels and locked in. If there are sufficient assets in reserve, the rebalancer can fulfill the redemption directly from reserve during the next rebalance window. Once fulfilled, the assets (minus the predetermined swing penalty) are transferred to the escrow contract, where they become available for the user to withdraw.

Component Liquidation

If reserves are insufficient, the rebalancer must liquidate components following the liquidation queue order, and the maximum swing penalty is applied. For example:

  • User requests redemption of 100,000 USDC

  • Node has 20,000 USDC in reserve

  • Rebalancer can partially fulfill the redemption from the reserve

  • Rebalancer must liquidate components to source remaining 80,000 USDC

  • Components are liquidated in strict queue order (e.g., Aave positions before Ethena)

  • Maximum swing penalty is applied to the redemption as it has depleted the reserve

  • Once complete, assets are transferred to escrow for user withdrawal

The swing price penalty varies between reserve and component redemptions. Redemptions from reserves use a calculated penalty based on reserve impact, while redemptions requiring component liquidation automatically incur the maximum swing penalty, as defined by the Node Owner. This design protects longer term investors from short term speculative flows.