In this article, we will take a look at how Bumper records and deals with protocol liabilities. If you are not already familiar with how Bumper’s pools work, it is highly recommended you read this article before continuing.
In the Bumper protocol, the different network participants (Takers and Makers) deposit their tokens (either cryptocurrencies such as ETH, or stablecoins such as USDC) into distinct pools.
Each of these 2 pools is further supported by a reserve pool, making a total of 4 pools (we call these our Quadrature of Pools). These pools are:
Bumper has three general objectives:
The seemingly complex architecture of Bumper is designed specifically to ensure that these protocol objectives can be met in virtually all situations, including during rare edge-cases and ‘Black Swan’ events. Of course, the three objectives form a trilemma, and so the protocol is configured to balance all three outcomes in a range of scenarios.
Bumper Protocol Liabilities
When we talk about the protocol’s “liabilities”, we are referring simply to the value locked into the system which is owed to users when they withdraw.
There are four distinct liabilities present in the protocol, which are individually referred to as the Book, the Liability, the Debt, and the Yield:
For the sake of clarity, Liability (capitalised L) refers to the specific liability of potential stablecoin claims as described above, whereas liability (lower case l) refers to liabilities in general.
The value of the four liabilities combined generally exceeds the total value of combined crypto assets and stablecoins in the system, a situation which occurs because when Takers deposit crypto for protection, not one, but two liabilities are assumed by the system, representing the two possible outcomes which occur when the position ends without being renewed - a close or a claim:
Although Bumper records two separate liabilities when a Taker opens a position (Book and Liability), only one of these will be paid out when their position ends, and the other liability is cancelled.
The diagram above shows a user depositing ETH into Bumper, which creates two distinct liabilities that are recorded by the protocol - one for the ETH Book, and one for the USDC Liability. In this example, the user’s position ends above the floor so they close their position and withdraw their ETH (less the premium). The Book is marked as paid, and the Liability is cancelled.
However, both of these Taker liabilities exist whilst the position is open, and so the system must ensure there is always sufficient liquidity available in each pool to service withdrawals.
Bumper achieves this through a number of complex mathematical calculations which determines a set of target ranges for each pool based on the statistical likelihood of a withdrawal from a pool at a certain point in the future.
This is a fine balancing act, and the system continuously monitors the current state of the system and the crypto assets’ price action.
When the amount of liquidity in a pool strays outside of its target range, the pool signals to the other pools that it either has a deficit or a surplus.
The other pools signal back their readiness to either accept, or provide, some excess tokens, and Bumper’s smart contracts then perform the rebalancing by transferring (swapping) assets between the pools as required to bring them back into the target ranges.
Bumper employs a range of strategies to increase liquidity as required. The first-order mechanism for increasing liquidity is the "current" premium and yield, which increases or decreases depending on whether more crypto assets (e.g. ETH) or stablecoins are required for balancing.
Additionally, using a ‘Boost Incentive’, Bumper occasionally attempts to encourage new participants to open positions by issuing them additional BUMP tokens.
Boost incentives are calculated when joining the protocol, and locked up with the Bond and released when the participant withdraws, closing their position. The Boost incentive, therefore, makes it more attractive for users to open positions, and thus their deposit increases the available liquidity in the appropriate pool, helping to restore that pool toward its target.
A rebalancing mechanism comes into play if the protocol incentives are not sufficiently effective in returning the Asset and Capital pool to within range of their target liquidity ratios.
In this case, the protocol unlocks some of the crypto assets captured by the system (for example crypto which has been collected for premiums) and trades them on an external DEX (Decentralised Exchange), with the exchanged token being returned to the appropriate pool in the protocol.
In order to minimise losses from slippage, spread, and MEV (Miner extractable value, essentially gas fees), the protocol balances the frequency of trades with the amount traded.
For most users, digging into the complex maths and the under-the-hood functionality is unnecessary, but it is useful to understand the basics of how Bumper manages liquidity and ensures that the protocol meets its core objectives.
Ultimately, Bumper has been designed to serve its users by offering crypto price protection to Takers, and yield generating opportunities to Makers.
For more details on how Bumper’s pools and liquidity works, we recommend reading the Bumper Litepaper, and we encourage you to join our Discord community and ask questions!
Disclaimer:
Any information provided on this website/publication is for general information purposes only, and does not constitute investment advice, financial advice, trading advice, recommendations, or any form of solicitation. No reliance can be placed on any information, content, or material stated on this website/publication. Accordingly, you must verify all information independently before utilising the Bumper protocol, and all decisions based on any information are your sole responsibility, and we shall have no liability for such decisions. Conduct your own due diligence and consult your financial advisor before making any investment decisions. Visit our website for full terms and conditions.
