Bumper Docs
bumper.fiDiscordForum
  • Learn
    • What is Bumper?
    • Documentation Structure
    • Why Use Bumper?
      • Comparison with stop-loss
      • Comparison with options
    • BUMP Token
      • Overview
      • BUMP Token Ecosystem
        • Design Background
        • Token Utility
        • Token Network
          • Network Bond (Primary Utility)
          • Network Incentive (Primary Utility)
          • Representative Governance (Primary Utility)
          • Network Boost (Secondary Utility)
          • Staking (Secondary Utility)
        • Roadmap
        • Token Metrics
          • Token Details
          • Token Emission
        • DAO Governance
          • Current Status
          • Future Status
    • Staking
    • Guides
      • Connect a wallet
      • Hedge - Open a position
      • Hedge - Exit a position
      • Hedge - Renew a position
      • Earn - Open a position
      • Earn - Close a position
      • Earn - Renew a position
      • dApp Interface
        • Dashboard
        • Hedge Positions
        • Earn Positions
      • Risk Rating
      • How do I add my BUMP to Metamask?
      • How do I add my bUSDC token to MetaMask?
      • How to buy BUMP on Uniswap
      • Liquidity Mining
        • How to Participate In Bumper’s Liquidity Mining Program - A step-by-step guide
      • Troubleshooting
      • Use cases & strategies
      • Legacy Guides
        • How to unstake & claim rewards from legacy staking
        • Claiming vested BUMP tokens
        • Withdrawing liquidity from Bumper's legacy LP program
        • Claiming BUMP tokens for Public Sale Participants
    • Protocol Risks
      • General risks
      • Taker liquidations
      • Maker liquidations
    • Premiums and Yields
    • FAQs
    • Troubleshooting
  • Protocol
    • Overview
      • Preliminaries
      • User Positions
    • Premium
      • Price Risk Factor (PRF)
      • Liability Risk Factor (VRF)
      • Probability of Claim
      • Liquidity Risk Factor (LRF)
      • Computing the Premium and Updating State
      • Visual Representation of Premium
    • Rebalancing
      • Cross-Side Rebalance and Swap Deadband
      • Asset and Capital Ledger
      • Rebalancing Trade Grid
      • Computing Swap Amounts
      • Same-Side Rebalancing
    • Taker Lifecycle
      • Taker Optionality
      • Taker Share
      • Taker Fungibility
      • Taker Position Token
      • Taker Risk Rates
      • Taker Renewal
      • Taker Close and Claim
      • Taker Position Expiry
      • Taker Ejection
      • Taker Cancellation
    • Maker Lifecycle
      • Maker Optionality
      • Maker Share
      • Maker Fungibility
      • Maker Position Token
      • Maker Risk Rates
      • Maker Withdrawal
      • Maker Renewal
      • Negative Yields
    • Simulation
    • Glossary
  • Governance
    • Overview
    • DAO Overview & Structure
      • Purpose of the DAO
      • Committees
      • Forum
      • Quorums
    • Economic Settings
      • Parameter tuning
      • Community involvement
    • Voting Power
      • vBUMP
      • Staking & Locking
    • Bumper Improvement Proposals (BIPs)
      • Before a proposal is created
      • Raising a proposal
      • Committee review
      • Warmup Period
      • Voting period
      • Grace & Queue periods
      • Abrogation
    • DAO user guides
      • How to Stake tokens in the Bumper DAO
      • How to Unstake tokens in the Bumper DAO
      • How to Claim Staking Rewards in the Bumper DAO
      • How to Lock tokens in the Bumper DAO
      • Delegating vBUMP
      • How to Undelegate vBUMP in the Bumper DAO
      • Voting on a governance proposal
      • Cancelling a vote
      • Voting on an Abrogation Proposal
      • Creating a Proposal in the DAO
      • Execute a proposal in the Bumper DAO
    • DAO Legal
  • Developers
    • Architecture
    • Modules
    • Contract Address List
  • Community
    • Community Code of Conduct
    • Alpha
      • Feedback and Support
      • Reporting Bugs
      • Connecting to Bumper network
  • Security
    • Audits
  • Legal
    • Terms and Conditions
    • Disclaimer
    • Privacy Policy
Powered by GitBook
On this page
  1. Protocol
  2. Rebalancing

Computing Swap Amounts

PreviousRebalancing Trade GridNextSame-Side Rebalancing

Last updated 1 year ago

Following on from the Basic Swap Grid, the hedging strategy is further refined for each scenario:

In the table, we have two scenarios in which we perform a swap when the Capital Ledger is in deadband, while we only have one scenario where a swap is performed when the Asset Ledger is in deadband. This is because we need to accumulate surpluses into the Capital Pool for Market Yield. It also follows that when we have a surplus in the Capital Pool, we do not wish to reduce this surplus unless it is strictly necessary to replenish the Asset side in cases where the ratios determine there are insufficient assets to cover potential Taker Closes (Asset Adequacy).

Under settings of asset price volatility, the protocol will tend to oscillate between its shortfall and surplus states. While there may be situations where the protocol measures an asset shortfall, it is expected that assets will generally be in surplus given that our configuration of the liquidity operating bands favours the asset side of protocol liquidity to mitigate the risk of swapping USD back for ETH. However while the protocol may routinely be in a state of shortfall, the protocol maintains the Capital Reserve to begin to cover the Liability if the currently measured yield reduces below zero (see subsection: Shortfall).

In general we wish to minimise the number of swaps (maximise swap size) due to accumulative gas costs on blockchains, but also minimise the real time to execute a swap where one may be necessary in order to minimise slippage.

The minimum swap size should be much larger than the expected gas cost (say, approximately 100 times) so as to make the gas cost small relative to the number of swaps triggered over time.

Cross-side rebalancing should be called after a user action function is used (except for Renew), and after each premium update. User action functions (Deposit, Withdraw, Protect etc) assume that protocol state is up to date (including that rebalancing has been performed). Before any rebalancing action is performed, the protocol liabilities should all be updated; the function of rebalancing is to determine how to update the values of the Pools and Reserves (see Section: System Summary - State).

By way of convention, we refer to the Asset side of the protocol as requiring it to be either bought or sold (the effect of a trade reducing/increasing tokens in one pool simultaneously reduces/increases the other).

lambda being a tuning parameter