Litepaper

LITEPAPER
Version 1.0
BUMPER PROTOCOL LITEPAPER
PLEASE NOTE: While Bumper branding draws heavily on retro ‘80s computer games, Bumper should
only be used by those who are familiar with its mechanisms and are comfortable with the potential risks
of owning and speculating on cryptocurrencies. If you are such an informed DeFi user, we hope Bumper
can provide you with a useful tool to prevent volatility from ruining your day. Please see the final page of
this document for further information.
© 2022 bumper.fi
bumper.fi © 2022
GOD-MODE
FOR CRYPTO
CONTENT
1 EXECUTIVE SUMMARY 1
2 INTRODUCTION 3
2.1 DECENTRALISED APPLICATIONS 3
2.2 EXISTING METHODS OF PRICE PROTECTION 3
2.3 DEFI’S NEW RISK MARKET 4
2.4 CORE ASSUMPTIONS 6
2.4.1 ASSUMPTION ONE: VOLATILITY IS BOUNDED 6
2.4.2 ASSUMPTION TWO: ACTOR HETEROGENEITY 6
2.4.3 ASSUMPTION THREE: INCENTIVE EFFECTIVENESS 7
2.5 PROTOCOL OBJECTIVE 7
3 SYSTEM OVERVIEW 8
3.1 ACTORS 8
3.1.1 TAKER-SPECIFIC FUNCTIONS 8
3.1.2 MAKER-SPECIFIC FUNCTIONS 9
3.1.3 JOINT FUNCTIONS 9
3.2 LIQUIDITY AND LIABILITY 9
3.2.1 POOLS AND RESERVES 9
3.2.2 POOLED VALUE EXCHANGE 11
3.2.3 MEASURING LIABILITY 11
3.3 THE PREMIUM 12
3.3.1 MEETING LIABILITIES 12
3.3.2 POOLED PREMIUMS 12
3.3.3 PREMIUM EFFICIENCY 12
3.4 OTHER FEES AND INCENTIVES 13
3.4.1 NETWORK BOND 13
3.4.2 NETWORK FEE 13
3.4.3 BUMP INCENTIVES 13
3.5 YIELD 14
bumper.fi © 2022
3.6 REBALANCING 15
3.6.1 VIRTUAL EXCHANGE 15
3.6.2 ARBITRAGE 15
3.7 MARKET CONFIGURATION 16
4 THE BUMP TOKEN 17
4.1 MARKET ACCESS IN DEFI 17
4.2 DESIGN BACKGROUND 18
4.3 BUMP UTILITY 18
4.3.1 CORE MARKET ACCESS 19
4.3.2 COORDINATION STIMULUS 19
4.3.3 GOVERNANCE 19
4.3.4 STAKING 19
KEY LINKS 20
DISCLAIMER 20
bumper.fi © 2022
LIST OF TERMS
Term Description
Taker A user of the system who wishes to protect against downward asset price
movements. Primary actor.
Maker A user of the system who wishes to earn a yield. Primary actor.
Staker A BUMP token holder who is not currently a protection market participant, who
stakes their token into the protocol for a BUMP yield.
Arbitrageur An auxiliary actor who, where available, executes a profit-making trade with the
protocol in order to balance its pools.
Deposit A Maker taking a position with the Protocol by supplying USDC. Generates
bUSDC.
Position Taken by a Maker or Taker when engaging with the protocol.
Term The lock-in period for a given user’s position. Active until expiry.
Floor An individual Taker’s chosen protection price.
Tier An individual Maker’s chosen level of exposure to risk.
Renew When a Taker or Maker renews their position for another Term. Renewal is a
toggled setting on a position.
Discontinue A Taker or a Maker notifying the protocol that they wish to discontinue the
automatic renewal of their position.
Close At the end of a protection term, a Taker Closes their protection and withdraws
their asset from the Asset Pool, minus premiums, if the price is above their
protection floor. This action is mutually exclusive with a Claim.
Claim At the end of a protection term, a Taker Claims their protection and withdraws
USDC or a combination of ETH and USDC, from the Capital Pool, minus
premiums, if the price is below their protection floor. This action is mutually
exclusive with a Close.
Cancel A Taker exiting the protocol before the expiry of their Term. Cancellation incurs
a break fee and requires the return of bETH.
Abandon Maker existing the protocol before the expiry of their Term. Abandonment
incurs a break fee, and requires the return of bUSDC.
BUMP The name of the Bumper protocol token.
bETH A token (or tokens) returned by the Bumper protocol which represents a Taker’s
positions.
bUSDC A token (or tokens) returned by the Bumper protocol which represents a
Maker’s positions.
bumper.fi © 2022
Bond Refers to locking BUMP tokens with the protocol in order to access a position.
A Bond is required to access certain protocol functions, such as creating Maker
and Taker positions. Bonding does not provide a reward.
Network Incentive An incentive for early participation. Only applies to Makers and Takers.
Boost Incentive An additional incentive that activates under scenarios of liquidity stress.
Asset Pool Primary pool of ETH in the protocol.
Asset Reserve A reserve of ETH that captures new ETH from Taker Premiums, Levies and
Fees.
Capital Pool Primary pool of USDC in the protocol.
Capital Reserve A reserve of USDC used to regulate price volatility.
Treasury A fund composed of ETH and USDC that is captured to fund

governance-approved activities, such as software upgrades.
The Book Total ETH liability to Takers.
The Liability Total USDC liability to Takers.
The Debt Total USDC liability to Makers.
Impermanent Loss Where the Capital Pool is lower than the Debt, typically due to Taker Claims.
Impermanent Loss in Bumper is defined differently to other DeFi protocols.
Realised Loss Incurred when a Maker elects to exit the protocol under a condition of
impermanent loss.
Liquidity Ratio A core measure of the protocol’s economic health. Several liquidity ratios are
used as inputs to the premium and rebalancing logic.
Adequacy The extent to which ETH and USDC liquidity provisions match their target.
Configuration Protocol settings that relate to static values, which can only be executed via
Governance proposals.
bumper.fi © 2022
1 EXECUTIVE SUMMARY
The emergence of secure, public blockchains such as Ethereum provide the infrastructure to host
autonomous software applications. This includes decentralised equivalents of present-day digital
markets, which have the potential to manifest as public digital commons, completely autonomous
and without any operator or owner.
Several novel designs for such public markets have emerged over the past few years, including digital
asset exchange [Uniswap, Curve], autonomous asset management [Yearn], lending [Compound, Aave],
payments and stablecoins [Tether, Maker, Havven], which, together with the numerous alternatives
that mimic them, have collectively produced the innovative private financial system known as
Decentralised Finance (“DeFi”).
In this paper we describe Bumper, a novel DeFi protocol that provides decentralised blockchain token
price risk measurement and exchange. The “protocol” is, in essence, a set of autonomous smart
contracts that expose public functions for two well-defined types of actors, referred to as “Makers”
and “Takers”. The Bumper protocol offers an alternative to traditional derivatives markets (that are
universally very complex for end-users and subject to counterparty profit motive), and centralised
exchange stop-loss functions (that incur slippage).
The protocol allows anyone to freely participate in digital asset price risk management in a way that is
simple, provably fair, and entirely decentralised, eliminating counterparty risk and using only
information that is natively available on-chain.
Bumper’s simple design is expected to have an impact beyond the disruption of legacy derivatives
markets. For a user of the Bumper, creating a protection position is extremely simple (unlike
deciphering Options contracts), and does not require constant monitoring for rebuy decisions (unlike
a stop-loss). While such features may not appeal to certain traders who engage in zero-sum profit
competition with other traders, Bumper is designed for those users who wish to protect against price
risk with minimal effort.
Takers are users who wish to protect their assets from downside risk, in the event of a price drop, by
setting a ‘floor’ below which they are protected from further loss. Takers enter into this protected
position by paying a fee (premium) into the protocol. The premium is calculated as a function of the
protocol’s internal liquidity and is variable for the duration of a fixed term. Bumper’s internal
mechanisms are calibrated to ensure a fair balance between Taker premium costs and Maker yields.
Makers provide stablecoin liquidity to the protocol and assume a downside price risk that diminishes
over time. Liquidity provision is incentivised by a stablecoin yield, derived from the premium, and from
the protocol lending out deposited assets to external yield farming opportunities. Although the
protected asset price is volatile, Maker yield has a positive, expected (probabilistic) yield over time.
When Takers consign assets to the protocol, they are returned a tokenised version of that asset with
the down-side volatility risk removed. Similarly, Makers consign stablecoin and in return receive a
tokenised version that is yield-bearing. In order to access their respective market functions, users
bumper.fi © 2022 1 of 20
must “Bond” (similar to being held in escrow) Bumper’s native protocol token (BUMP) for the duration
of their position.
Deposits of assets and stablecoin confer control to the protocol, which uses a set of four liquidity
pools to calculate premiums and transfer the beneficial ownership of stablecoins and assets
dynamically. Bumper’s quad-pool design provides superior liquidity efficiency for calculating the
premium and helping to ensure that market participants may freely deposit and withdraw at any time.
The premium is a function of a set of internal liquidity ratios, and can be calibrated to withstand
virtually any price volatility scenario, however proper calibration is important to balance Taker costs
and Maker incentives, as well as ensure economic robustness over a range of volatility settings.
Optimised settings will maximise market utility and overall protocol value.
Bumpered assets open a range of interesting possibilities for improved capital efficiency and risk
management across DeFi, with the protection and yield tokens that are issued back to users being
freely composable into other use cases and their protocols, such as a replacement for collateral in
lending, or liquidation protection in leveraged trading.
There is currently no equivalent of Bumper within DeFi or traditional finance. Bumper is completely
decentralised, autonomous and permissionless, and the protocol’s novel design demonstrates how
new decentralised markets can provide superior outcomes, when compared with traditional methods,
by re-organising the utilities of the market participants.
2 INTRODUCTION
2.1 DECENTRALISED APPLICATIONS
At their core, blockchains provide secure means to reverse the cost of hosting software applications,
by moving away from a single entity to instead be borne by the individual users interacting with them.
The impact of this is profound.
Historically, open source software has only ever existed as open (public) source code, freely available
over the Internet. Now, decentralised technology gives new meaning to the words “open source
software”; after being deployed to a blockchain, open source, public code manifests instead as an
open source, public application. Developers no longer have to commercialise code in the traditional
way for it to be made available for people to use, meaning that popular web applications no longer
require subscriptions, advertising, or suffer the subtle deleterious effects of centralised data
collection.
The most powerful application of this technology is perhaps to reform the most common software
application of them all, currently serving as the fundamental architecture of every securities exchange,
online marketplace and social network in the world: the Digital Market.
2.2 EXISTING METHODS OF PRICE PROTECTION

Risk management in any market can be a complex endeavour. This is perhaps especially true in
cryptocurrency markets, where price volatility can be extreme. For our context, the digital markets of
interest are asset exchanges and options markets, which currently provide the only two methods for
DeFi participants to manage the risk of future asset price.
The Stop-Loss
A stop-loss is a simple and universal mechanism available to traders operating on centralised

exchanges. A stop-loss incurs a transaction fee as well as losses in the form of spread and slippage,
the latter of which is exacerbated when there is poor buy-side liquidity. These costs however are
relatively low on centralised platforms given the very low trading latency with other users. Ethereum
(onto which Bumper is to be initially deployed), by comparison, has extremely high latency, and its
public nature exposes transactions to (ostensibly) greater risk of losses from front-running. This,
along with the high price of committing transactions into blocks, renders a simple exchange-style
swapping mechanism impractical in protecting against price volatility on a blockchain.
The Put Option
The second example of existing solutions for price protection is the Put Option; structured financial
products typically bought and sold by professional traders. Options have complex pricing and have an
enormous set of potential inputs to calculate their value. Just like a stop-loss, they too are traded on a
typical bilateral exchange where there is a profit-maker and a loss-maker.
The seller determines the price of an option, including how much profit is to be added on top of their
expected cost. Consider a theoretical options market where all sellers use a consistent scheme for
calculating the cost of their options. A race condition naturally develops for them to sell their
contracts ahead of others, meaning that one seller can succeed in selling multiple options over other
sellers, who fail to make their trades. Theoretically this benefits the buyer, who should expect to see
convergence to ‘fair’ pricing1. The reality of these markets, however, is that sellers still spend
significant time attempting to manage their profit because they compete with other sellers, and until
expiry, buyers never have complete confidence in whether the price they pay is worthwhile.
There is particularly limited choice and availability in cryptocurrency options markets for participants
to hedge market volatility. Centralised Options and Futures exchanges (for example, Deribit, Bakkt,
CME) each offer structured hedging instruments for cryptocurrencies, but these come at high cost,
while DeFi-based options protocols (for example, Hegic, Opyn) simply use smart contracts to
essentially recreate centralised options markets. While the DeFi versions indeed remove some
centralisation and counterparty risks, these platforms ultimately inherit the same issues of cost and
complexity for end-users, all the while competing with their larger centralised rivals with weaker
market depth, slower transactions, and front-runnable trades.
STOP LOSS ORDER OPTIONS CONTRACT BUMPER

Loss Prevention Yes Yes Yes
Upside Exposure No Yes Yes
User Experience Simple Complex Simple
Relative Cost Cheap Expensive Cheap
Spread Fixed, but complex and Variable

Pricing Method
Slippage time-consuming Algorithmic
2.3 DEFI’S NEW RISK MARKET

Price risk is commonly defined in terms of upside risk and downside risk. Traditional measures of
price volatility used in structured finance include both, as market actors are assumed to have a
profit-maximisation motive and so structured products infer a corresponding strategy onto the
individual participant that assumes they make use of both. The reality, however, is that there are a
variety of motives, strategies and levels of sophistication with potential market actors.
In DeFi, a common alternative to matching individual buyers and sellers bilaterally is to use pooled
liquidity. Bumper’s design similarly collects Taker and Maker deposits into two protocol-controlled
pools; their positions are not with a matched counterparty, but with the protocol, without any need for
third party intermediation between mutually untrusting buyer and seller.
1
In essence, the “efficient market hypothesis”.
Pooling in general has two major advantages:
(i) it minimises the ‘parasitic’ cost of slippage from many individual trades.
(ii) it ensures that buyers of short-term price volatility protection can always be matched
with long-term yield-chasing investors; on an options exchange, each position is only
able to be matched once - one buyer and one seller.
This is where the potential similarities of Bumper with other protocols start to diverge.
While most DeFi protocols typically feature two pools (one for each asset type), Bumper’s design has
four. Using liquidity pools in quadrature allows Bumper to calculate premiums efficiently based on
internal liquidity, and dynamically control the beneficial ownership of stablecoins and assets, while
helping to ensure that market participants are not limited in when they can deposit or withdraw due to
illiquidity in market depth.2 Profit-reducing costs, such as those derived from slippage, spread and
transaction fees are also minimised.
Bumper’s two additional pools are reserves of assets and capital that are used in several ways to
manage the risk of price volatility. Specifically, the risk being managed is one of liquidity, and this
drives a requirement to monitor not only asset prices, but also the protocol’s balances of assets and
capital against its liabilities. Both measures (price behaviour and liquidity) are used to automatically
adjust the protocol’s internal adequacy targets for asset and capital liquidity, which in turn drives
premiums and yields.
Bumper has been designed to maximise the efficiency of risk transfer pricing. The protocol:
(i) measures and dynamically responds to price change as well as demand,
(ii) shares risk amongst liquidity providers, and
(iii) shares the cost of risk amongst protection buyers
The potential inputs for managing price volatility are manifold, and the protocol is extensible to
accommodate additional risk vectors such as derivatives to the price and liquidity risk measures,
concentration risk (referring to both concentration of protection or concentration of asset),
operational risk (referring to failures of people, process or systems, including fraud or smart contract
bugs), liability risk over time, prices in the external market, measures of sentiment, as well as
‘real-world’, or information, external to the blockchain.
The core of the protocol’s design, and philosophy, is that all risk and profit is shared, meaning that
protection Takers don’t have to worry whether or not they're paying a fair price, and protection Makers
don’t have to compete with other Makers.
2
The use of the term quadrature carries multiple complementary semantic interpretations, simultaneously
referring to the accumulation of premiums over time, the two dimensions of premium calculation, and the handy
overtone of using four liquidity pools.
2.4 CORE ASSUMPTIONS

A robust cryptoeconomic protocol demands taking an exhaustive approach to finding, expressing and
reducing any and all fundamental design assumptions. For Bumper, we make three core assumptions
upon which the protocol’s market design rests:
1. Maximum Variance
There exists no future asset price change that exceeds an expected maximum cumulative
variance (i.e. a maximum future price volatility) over some given period of time.
2. Minimum Heterogeneity
That there exists some set of actors with a price risk perspective distribution that effectively
segments Takers from Makers.
3. Minimum Incentive
Cryptoeconomic incentives are minimally effective such that there exists a non-zero subset of
Takers and Makers who are incentivised to join the protocol.
2.4.1 ASSUMPTION ONE: VOLATILITY IS BOUNDED
This refers to the configuration bounds of the protocol to withstand extreme theoretical scenarios of
asset price movement, such as the market price of a protected asset never instantaneously changing
to $0 and remaining there indefinitely, or, for example, continuously oscillating between historical
highs and historical lows over a relative short time period.
2.4.2 ASSUMPTION TWO: ACTOR HETEROGENEITY
Potential participants for such a marketplace are likely to exhibit both muted risk appetites and
forward price perspectives relative to professional traders who actively monitor and trade
cryptocurrencies. Takers for example may have some existing exposure to cryptocurrencies, but do
not have the means or inclination to frequently manage that exposure. By contrast, a relatively ‘high’
frequency actor will actively manage multiple positions on several centralised exchanges
simultaneously, or employ hedging strategies via structured products or derivatives. Takers pay a
premium for the Term of their protection and as such may be construed as being more akin to an
insurance instrument, but they may also be loosely categorised as buying an option, as they are
effectively acting with a “short” outlook for the Asset over some time horizon. Similarly, Makers can be
considered to be “long”, as their exposure within the Bumper protocol is based on the assumption that
the asset, although volatile, doesn’t have a negative price outlook over the long term. Of course,
Makers can always act on this outlook by similarly buying (or selling) an option, however we define
them similarly to Takers wherein, individually, Maker risk appetite is tempered by their ability to
actively manage their portfolio.
The protocol prioritises shorter-term Taker Claim events over Maker yields, the latter of which are
developed over longer time periods. By understanding and assessing risk, more sophisticated actors
can operate in one or more risk markets, or tiers made available by the protocol, to blend their risk
exposure but customised for their individual perspective.
2.4.3 ASSUMPTION THREE: INCENTIVE EFFECTIVENESS
Calibration of Bumper’s settings ensures a balance of outcome between Takers and Makers. For
Takers, this means ensuring that the average premium is less than or equal to an equivalent
Black-Scholes option price. It is similar for Makers, who also consider the availability of external yield
opportunities, with consideration to the quality (or, risk) of those opportunities.
With an appropriate calibration, and in the presence of availability of Takers and Makers, the protocol
assumes that its pricing and incentives motivate some non-zero set of actors to engage with Bumper.
2.5 PROTOCOL OBJECTIVE

The protocol’s objectives are generally to:
● Remain solvent to both Takers and Makers according to liquidity needs
● Minimise the cost of price protection for Takers (premiums and other fees), and
● Maximise yields for Makers
Achieving these objectives can be performed in various ways, but the natural tension between them
requires either a clear priority, or a way to satisfy them simultaneously. Bumper uses a “priority
balance” to satisfy opposing objectives parametrically. The chosen protocol settings govern the
relative strength of Taker and Maker liquidity and balance the respective utilities based on the
prevailing economic health of the protocol. This is aided by in-built escalation mechanisms to ensure
robust operation under a well-defined range of market scenarios.
Bumper’s purpose is to develop a mutual price risk facility that minimises individual loss, as opposed
to a more traditional venue that optimises for maximum individual profit.
3 SYSTEM OVERVIEW
This section provides a brief introduction to key system components and terms as a reference, ahead
of explanation in the sections that follow.
3.1 ACTORS
The Bumper protocol defines two key actors: Takers and Makers. Takers deposit Assets (initially ETH
in v1.0) into the system, in order to obtain a protected price position. The current price is measured
from an on-chain source, and the Taker selects both a fixed Term and a price Floor for their position,
each chosen from a list of five options.
On the other side of the market, Makers deposit Capital (initially USDC in v1.0), and, similarly, choose
a fixed Term and a Tier of risk which determines their level of exposure to potential yield and the
associated risk of loss. Maker USDC deposits are at risk to Claims which temporarily diminish the
capacity of the protocol to pay Makers a positive return. Tiers, Floors and Terms for Makers and
Takers may not be changed until expiry, unless a Taker Cancels, or a Maker Abandons, their position,
which incurs a penalty.
At the end of a protocol period, (a given interval of time, or a given percentage change in ETH price), a
global Premium, calculated in USDC terms, accumulates against the ETH pool.
At the end of their Term, where the current ETH price is above their floor, Takers can either Close their
position and draw ETH from the protocol (minus their individual premium, levied in ETH), or, where the
current ETH price is below their floor, Takers instead may Claim on the protocol to draw USDC (minus
the value of their individual premium, levied in USDC), or a combination of ETH and USDC.
Bumper further disperses the concentration of liquidity risk by allowing users to segment themselves
into risk categories. For Takers, this is the chosen Floor price at which a Claim is able to be made. For
Makers, this is their yield exposure based on their time of entry and their selected term. Makers are
suitably incentivised to enter at times of stress, and/or for longer fixed terms.
3.1.1 TAKER-SPECIFIC FUNCTIONS
Action Description
Protect Seeking to purchase protection against negative asset price movements, Takers Protect
their asset by depositing a principal into the Asset Pool, choosing a fixed term and a price
floor.
Close At the end of a protection term, a Taker Closes their protection and withdraws their asset
from the Asset Pool, minus premiums, if the price is above their protection floor. This action
is mutually exclusive with a Claim.
Claim At the end of a protection term, a Taker Claims their protection and withdraws USDC or a
combination of ETH and USDC, from the Capital Pool, minus premiums, if the price is below
their protection floor. This action is mutually exclusive with a Close.
3.1.2 MAKER-SPECIFIC FUNCTIONS
Action Description
Deposit Intending to earn a yield from Bumper’s mechanisms over time, Makers Deposit stablecoin to
the Capital Pool, selecting both a fixed term and a risk exposure tier.
Withdraw When they wish to recall funds from the protocol, Makers terminate their position and
Withdraw stablecoin from the Capital Pool after the expiry of the current term.
3.1.3 JOINT FUNCTIONS
Both Takers and Makers can also:
Action Description
Cancel / A Taker (Cancellation) or Maker (Abandonment) exiting the protocol before the expiry of their
Abandon Term. Incurs a break fee.
Renew When a Taker or Maker renews their position for another Term. Renewal is a toggled setting
on a position.
Discontinue A Taker or a Maker notifying the protocol that they wish to discontinue the automatic renewal
of their position.
In addition to Takers and Makers, Bumper also defines two other actor types:
● Stakers, who speculate on the future utility of the protocol by staking BUMP to earn a yield in
BUMP. Staked BUMP is at risk of liquidation under specific conditions, and,
● Arbitrageurs, who wish to earn a profit from the protocol by executing rebalancing trades
between the pools. These trades are offered by the protocol under certain conditions.
3.2 LIQUIDITY AND LIABILITY
3.2.1 POOLS AND RESERVES
All value within the system (ETH and USDC) is controlled between four pools:
● Asset Pool (AP)

The main store of ETH. Captures initial ETH deposits for protection positions.
● Asset Reserve (AR)

A secondary store of ETH which collects ETH premiums and ETH that is left behind by Takers
when they make Claims.
● Capital Pool (CP)

The main store of USDC. Captures initial USDC deposits for liquidity provider positions.
● Capital Reserve (CR)

A secondary, prudential store of USDC which assists the protocol to measure and manage
short term liquidity.
Bumper’s Reserves are a novel construct in DeFi. They serve multiple purposes, including covering
short-term liquidity needs (BORROW, SETTLE), as well as providing a convenient method for
measuring liquidity adequacy. Liquidity adequacy is used as an input to the premium calculation, and
is used in triggering inter-pool rebalancing (arbitrage) swaps.
To gain a better intuitive understanding of the function of the reserves, consider how having reserves
of ETH and USDC can mitigate the urgency to swap between the primary pools in the presence of
price volatility. A reserve of USDC for example can be used in place of swapping ETH for USDC, which
also acts to provide time for protocol incentives to take effect to help rebalancing. This mechanic
works by activating the Capital Reserve to temporarily provide USDC liquidity to the Capital Pool in
place of activating a swap of ETH to USDC from the Asset Reserve. A strategy of frequent and hard
rebalancing trades would mean there is no time window for actors to take advantage of incentives,
and would accumulate undesirable slippage costs in the process.
3.2.2 POOLED VALUE EXCHANGE
All user interactions in Bumper take place between the user and a pool, rather than between users
directly. The balance of each pool is deterministic based on the existing state of each pool, the current
price, and new user interactions, which either increase or reduce one or the other pool; while the
outcome of a single operation on the protocol’s state is knowable ahead of time, future states are a
function of future user behaviour. All inputs to the protocol are either from on-chain sources, or from
user interaction, meaning that the future state of the protocol can be estimated probabilistically based
on an assumed future volatility, and the effectiveness of incentives over time.
Every position that is initiated by a Maker (buys risk, earns yield, supplies stablecoin) or a Taker (sells
risk, supplies assets, pays premiums) is done so against their respective Pool. Every position that is
created debits a number of assets or stablecoins from the user’s wallet and is then credited to the
relevant protocol Pool.
3.2.3 MEASURING LIABILITY
Monitoring and responding to liability is core to Bumper’s mechanics. When a single Taker enters the
protocol, dual liabilities are created; one recorded for ETH and another recorded for USDC. However,
while more liabilities are produced than assets exist to service them both simultaneously, the
converse also applies upon Taker exit; a Taker may only perform either a withdrawal of ETH or a claim
of USDC, which removes both the ETH and USDC liability for that Taker. This is why balance between
the pools is important for Bumper, as the target balance is a function of the protocol’s expected
liabilities between ETH and USDC.
The total of all potential Taker withdrawals is referred to as the “Book”, and the total of all potential
Taker Claims is referred to simply as the “Liability”.
When a Maker deposits USDC into the protocol, a single liability is recorded. The sum of all of the
Maker USDC liabilities is referred to as the “Debt”. Similar to the Taker liabilities, the value of the Debt
is reduced as Makers exit the protocol with their resultant positions. The Debt is also used as a
means to slowly convert the value of accumulating ETH premiums to USDC in the Capital Pool. This is
done by incrementally adding a “Yield Factor” to the Debt every time the Premium is calculated. As the
value of the Debt to Makers increases, the protocol’s incentives and mechanisms work to rebalance
the pools over time, ensuring that there is appropriate USDC liquidity available for Maker withdrawals.
3.3 THE PREMIUM
3.3.1 MEETING LIABILITIES
The protocol recognises three distinct liabilities (ETH for Takers, USDC for Takers, and USDC for
Makers3) and only two sets of liquidity (the Asset Pool and Reserve, and the Capital Pool and Reserve)
with which to meet those liabilities. Bumper does this by shifting ETH and USDC liquidity to match a
pair of ETH and USDC liquidity targets, internally calculated as a probability between the Book and the
Liability materialising in a user payout. Specifically, at every point in time, the protocol calculates a
“Probability of Claim” based on the difference between the current ETH price and a protocol-wide floor
price. This produces a set of liquidity “targets” for the pools which are used as an input in calculating
premiums.
The premium is a function of the protocol’s current ETH and USDC liquidity (across the four pools),
the current ETH and USDC liabilities, based on a Probability of Claim derived from the current price of
ETH.
Bumper measures the ETH price as the median of a cluster of on-chain and off-chain sources using
the Chainlink price oracle.
3.3.2 POOLED PREMIUMS
In the implementation, the premium is calculated incrementally, triggered by changes in asset price.
Premiums are calculated and applied, on average, every 15 minutes4. This is why we often refer to “the
Premium,” as it is calculated and applied in aggregate for all Takers at the same time. At the end of a
Taker’s term, Bumper calculates their individual share of the accumulated premiums, which are
payable from the value of their initial deposit.
The Premium is denominated in the protected asset currency (ETH) and is levied against the Asset
Pool at each increment, accumulating in the Asset Reserve. This benefits Takers with the convenience
of not requiring any separate currencies with which to pay their premium.
3.3.3 PREMIUM EFFICIENCY
Bumper’s pricing efficiency is achieved by charging premiums dynamically, only in response to

measured risk. This means that while the cost of protection is unknown ahead of time (unlike a
traditional European Put Option, where the premium is agreed up-front), the formula for calculating the
premium is known. This is in stark contrast to Options in which the pricing method for the Option is
3
As a worst-case reduction of a combination of ETH and USDC liability to Makers.
4
The minimum time between two premiums is the Ethereum block time at approximately 13 seconds. The
maximum time between two premiums is approximately 60 minutes, corresponding with Chainlink’s ETH-USD
oracle time-out setting.
opaque to the buyer, including the magnitude of the seller’s profit, leaving it up to them to decide
whether or not it was worthwhile to purchase the Option right up until expiry.
With Bumper, this guess-work is eliminated, ensuring that the protocol only charges premiums when it
needs to in response to price volatility. For users of the protocol, while there is some uncertainty in the
premium to be paid (not unlike most DeFi yield farming activities), the benefit is the method by which
the premium is calculated is no longer opaque, meaning there will never be ambiguity between Taker
and Maker about the fair value of their interaction.
3.4 OTHER FEES AND INCENTIVES
3.4.1 NETWORK BOND
In order for a Maker or a Taker to create a new position in Bumper, they must provide the protocol with
a certain amount of BUMP tokens. This is known as “Bonding”, and the quantity of BUMP that is
supplied by the user is the “Bond”. The value of the Bond is calculated based on the value of the
position being taken out; the higher the position, the higher the Bond. Bonds are returned to users
(plus any BUMP incentives that were earned) at the end of their position, except for users who cancel
their position early, in which case the Bond is forfeited, along with earned BUMP tokens, instead being
used to increase the incentive pool for new Maker and Taker positions.
Section 4 provides the background to Bonding.
3.4.2 NETWORK FEE
A Network Fee is payable for Takers (ETH) and Makers (USDC), irrespective of other pricing
components, at the start of their term. This fee is captured into protocol Treasury to support future
protocol activities, as directed by the Bumper DAO.
3.4.3 BUMP INCENTIVES
Two different incentives are potentially payable to users in BUMP at the start of their term.
● A Network Incentive is payable to early protocol adopters, calculated as a diminishing function

of increasing TVL (Total Value Locked).
● A Boost Incentive is payable to users who help to restore liquidity balance. The Boost will only
activate beyond a certain liquidity imbalance to support the natural incentives of premiums
and yield if required.
Further detail on the Bond and the Network and Boost incentives is provided in Section 4.
3.5 YIELD
Individual Maker yield is calculated by the amount of USDC in the Capital Pool and their owned share
(nominally: “bUSDC”) with respect to their initial deposit. Yield is realised for the Maker when they
return their bUSDC to the protocol. A Maker’s bUSDC is computed when they enter the protocol based
on: their principal, their selected risk tier, the amount of USDC in the Capital Pool, the total amount of
bUSDC currently on issue across the market, and the amount of ETH in the Asset Reserve. A bUSDC
bonus is applied based on the length of their term, with longer terms attracting a higher bonus.
Yield is developed for Makers by applying an incremental increase to the protocol’s USDC liquidity
ratios, constructed from the values of the Capital Pool, Liability and Debt. Yield works by increasing
the value of the Debt (being the amount owed to Makers) over time, such that the protocol’s incentives
and rebalancing functions can increase USDC holdings and pay out positive yields.
Impermanent Loss in Bumper is defined as an insufficient value in the Capital Pool to cover both the
Debt and the current expected Liability at the same time (even though these will not all fall due at the
same time). Given this definition, a state of impermanent loss can occur routinely in instances of rapid
asset price declines, even with a balanced calibration of protocol settings. Impermanent loss is
calculated on the basis of the Capital Pool only, even though the value of the Asset Reserve (which
will have grown substantially if there are many Claims by Takers on the Capital Pool) is still owed to
Makers. Recall that the Asset Reserve represents the current, but unconverted, Maker Yield, along with
any capital in excess of the Liability already held within the Capital Pool.
Together with fixed terms, this impermanent loss mechanic minimises the propensity for capital flight.
It is founded upon all three of the core design assumptions for Bumper (refer to Section 2.4),
particularly that of a bounded forward price volatility (the protocol is calibrated to withstand volatility
beyond historical maximums), and that Maker outlook on asset price risk is at least neutral over
longer time horizons. The second assumption can also be interpreted through a more traditional lens
in so far as Makers have purchased ETH at a lower price than when they entered the protocol, but at a
higher price than the current market price. This is similar to selling a Put Option that resolves as being
“in-the-money” for the buyer. Makers must remain in the protocol (ideally, to the end of their term) to
receive the benefit of this ETH to give the protocol time to convert it to USDC. Depending on
calibration, some ETH is held in the Asset Reserve as a “liquidity cache” against asset price rebounds,
which, based on historical data, occur with some expected value.
To enforce this consistency, the protocol apportions any calculated impermanent loss among Makers
according to their elected risk. If a Maker ultimately decides to leave the protocol with a non-zero
Impermanent Loss, then this proportion is deducted from their final payout figure as a Realised Loss.
Surplus ETH will often remain in the Asset Reserve, after accounting for satisfying both the ETH and
USDC liquidity targets. In situations where the asset price increases from a state of liquidity balance,
the Maker Yield target will be exceeded, and benefit those Makers who have maintained a positive
price outlook until that time. Thus, Makers are incentivised to remain in the protocol where there are
instances of short-term volatility, consistent with our original assumption of an “at-least neutral” price
outlook over some time horizon.
3.6 REBALANCING
3.6.1 VIRTUAL EXCHANGE
Assets and stablecoin shift between Bumper’s pools and reserves under different conditions. Each of
the four has a unique set of rules governing when tokens may be transferred out to another pool,
based on the current liquidity needs of the protocol as it responds to price volatility. We define three
types of use for funds in each pool. The default use is the expected use for the tokens under
low-volatility conditions, whereas the secondary and tertiary usages are short-term changes to a
pool’s ruleset in scenarios of high volatility or low liquidity.
Whereas a Put Option might transfer the beneficial ownership of ETH to a Maker after a Taker Claim,
ETH premiums can remain in the Asset Reserve for a period of time. For a Maker looking to exit, the
USDC component of their final position may be withdrawn from the Capital Pool without necessarily
converting ETH to USDC at the time of Maker withdrawal. This minimises the number of swaps the
protocol needs to perform, thus minimising slippage and gas costs for the Maker initiating the
transaction, which would otherwise increase Taker premiums and reduce Maker yield.
3.6.2 ARBITRAGE
Liquidity adequacy is determined by the volatility of the protected asset price. When there is high
volatility, the Liquidity Ratios may diverge too far from their target. When the ratios change too quickly
for the protocol’s incentive mechanisms to affect restoration of the balance, Bumper will open a swap
between the pools to occur. This is known as “Arbitrage”, and is used to “hard” rebalance the value
between the protocol’s pools. This occurs in two scenarios:
● In the case of insufficient USDC, the Asset Pool offers an increasing amount of ETH for sale
at an increasing discount to the current price, with proceeds being deposited to the Capital
Pool, and,
● In the case of insufficient ETH, the Capital Pool offers to buy an increasing amount of ETH at
an increasing premium to the current price, to be deposited in the Asset Pool.
Arbitrage is an opportunity for external actors to make a profitable trade with the protocol, allowing
the protocol to simultaneously increase the value of one pool and decrease the value of the other.
This is a form of slippage loss, but is only incurred where there is a combination of high volatility and
a relatively slow response of Taker and Maker participation.
An Arbitrageur decides on whether to execute a trade with the protocol on the basis of: (i) the quantity
that is made available by the protocol to trade, and (ii) the discount to the market value that is applied
in order to make the trade marginally profitable.
3.7 MARKET CONFIGURATION

Bumper’s v1.0 release supports multiple protection markets for the DeFi ecosystem on Ethereum,
starting with a protection market for Ether. The protocol is currently designed such that every
protection market creates a unique set of smart contracts. Thus, each protected asset has a unique
Asset and Capital Pool pair, and, for Makers, this means choosing in which markets to participate, and
how to segment their capital between them. Markets can also be reconfigured in future to form
“superpools”, which provide the ability to aggregate backing capital, and diversify risk with
anti-correlated assets.
As at time of writing, economic modelling is being performed on wrapped Bitcoin (wBTC) for inclusion
as the second supported asset. For the addition of further assets to the whitelist, Bumper community
input is planned.
Support for multiple stablecoins is scheduled in a future release, with the groundwork for this already
in place with v1.05. Under the hood, USDC stablecoin deposits are wrapped before being deployed into
a protection market which provides a modular interface for additional stablecoins to be added,
including stablecoins for different currencies, without changing any market logic.
5
Referred to as “Superstability” in Bumper’s roadmap.
4 THE BUMP TOKEN

4.1 MARKET ACCESS IN DEFI
The price of access to centralised digital markets is determined by the owners and operators of that
market. This price includes the cost of operating the market software, but it also includes profits that
are distributed back to the market’s owners. The amount of added profit is a function of supply and
demand, influenced by the strength of competitive alternatives. Pricing for any centralised service is
generally designed to maximise profit, calibrated between maximising the per-unit price and the
number of units sold. The other factor at play with centralised markets is the high cost of user
transition, often referred to as ‘stickiness’; because centralised markets are disconnected from each
other, both user profiles and on-market sale products face additional difficulty in changing venue that
is naturally imposed by the nature of the technology (and naturally exploited by its proprietors).
In contrast, competing markets domiciled on a common blockchain are highly connected. This
reduces switching costs to near zero and maximises market competition. Further, using a fixed-supply
utility token to access a decentralised software market allows the cost of access to float and respond
directly to user demand. Such pricing response is indeed present in the centralised model, but it is far
more weakly coupled by virtue of being manually adjusted by the market’s owner, and the common
user expectation of pricing stability for centralised products and services.
Critically, a utility token-based access scheme means that the traditional notion of profit can be
removed from the unit cost of market access for an end-user. If we consider operating costs to be
equivalent between centralised and decentralised models, then we might represent the cost stacks for
each in the following illustration:
In practice, centralised models may not impose excessive profit over the market’s utility value, and
decentralised models may have inconvenient price fluctuations, and be subject to other market forces
such as speculation. Critically, however, while the operational costs for the digital infrastructure may
be sunk in both models, a bonded utility token model allows for something else that is very
unconventional: the cost for access is refundable.
4.2 DESIGN BACKGROUND
The BUMP token has been designed using the following fundamental concepts that apply to
blockchains and DeFi in general:
1. Distributed software enables digital peer-to-peer markets.
No intermediating party is required to provide custody and thus be entrusted with ensuring the
correctness of shared digital records for market transactions.
2. Market network effects can be tokenised.
All markets have optimal price discovery when network effects are maximised. An individual
transaction bears some utility, but the ease and cost with which that transaction is made results from
market network effects. Tokenising network effects allows the separation of the value of the network
effect from the utility of an individual transaction.
3. Market network effects can be sustained using incentive mechanisms.
Despite the market logic being open source, and the market’s users and transaction information being
public, the tokenised value of network effects can themselves be used to incentivise and co-ordinate
actors to sustain the network effect.
4.3 BUMP UTILITY

At its core, Bumper develops a two-sided marketplace between (a) actors wishing to buy price
protection for an on-chain asset, and (b) those seeking to buy asset price risk in return for the
opportunity to collect premiums. The network effect of the Bumper market is supported by a utility
token, BUMP, which is required to be bonded in escrow by market participants for the duration of their
engagement with the protocol. In this way, the demand for the use of Bumper is intrinsically linked to
token demand, making the market value for BUMP a proxy for the utility value of Bumper. The
intended function of BUMP is to incentivise participation in Bumper and support the protocol’s
network effect. Linking protocol utility with token demand in this way naturally supports its market
price, meaning that incentive mechanisms designed to influence real-world (economically-rational)
actors to interact with the protocol can be effective.
Specifically, Bumper’s native token has been intrinsically woven into several core protocol functions
discussed below.
4.3.1 CORE MARKET ACCESS
A proportional “Bond” is required to be deposited by Takers and Makers at the start of their Term. A
Bond is required to have been posted at all times an actor has an active position. Bonds are returned
to users at the end of their engagement.
The purpose of the bond is to bind the value of the market’s network effect to the value of the token.
With a fixed supply of tokens available, the market value of BUMP will converge with the value of
market demand for Bumper over time.
4.3.2 COORDINATION STIMULUS
BUMP tokens may be issued to Takers or Makers by the protocol under various conditions in order to
support either additional asset or capital liquidity when regular premiums and/or yields are not
attracting sufficient new participants quickly enough. This is referred to as the “Boost” incentive.
Additionally, a “Network” incentive is a payment in BUMP as a participation reward for early adopters
of market functions (i.e. Takers and Makers). The network incentive is designed to bootstrap network
effects by using the token as a signalling device to coordinate agent behaviour in joining Bumper. This
incentive decreases with increasing TVL.
4.3.3 GOVERNANCE
BUMP is also used as the mechanism for owner-users (BUMP token holders) to influence new
Bumper features, configuration updates or other changes via representative voting. Voting is
time-weighted to mitigate the ability for wealthy individuals or collectives to perturb decentralisation
in voting by temporarily buying tokens to increase voting power.
Changes to the protocol are conducted via Bumper Improvement Proposals as commonly found
among established decentralised protocols. Bumper’s decentralised governance processes include:
1. Raising and publishing improvement proposals,
2. Voting on improvement proposals based on time-weighted BUMP holding, and
3. A final approval and deployment process once voting has concluded.
4.3.4 STAKING
Actors who hold the BUMP token, but are not currently engaged in direct market participation as
Takers or Makers can support the protocol via a staking program. Staked tokens are at risk of
liquidation up to a predefined maximum percentage if certain community-endorsed economic or
operational triggers manifest. Token holders, however, are incentivised to stake their tokens to
improve the security of the protocol, as this returns a BUMP yield to the pool of Stakers that is
proportionally distributed.
KEY LINKS
Bumper Website https://bumper.fi
Discord Community https://discord.gg/YyzRws4Ujd
Terms and Conditions https://bumper.fi/terms-and-conditions
BUMP Token Metrics https://www.coingecko.com/en/coins/bumper
DISCLAIMER
PLEASE READ THIS DISCLAIMER CAREFULLY. SEE BUMPER.FI FOR FULL TERMS AND CONDITIONS.
The views expressed herein are for informational purposes only and, unless
otherwise stated, reflect only the subjective views of the applicable speaker,
which are subject to change. Nothing herein constitutes investment, legal, or tax
advice or recommendations. This material does not constitute or form part of an
offer to issue or sell, or of a solicitation of an offer to subscribe to, or buy,
any securities or other financial instruments, nor does it constitute a financial
promotion, investment advice, or an inducement or incitement to participate in any
product, offering or investment. This material should not be relied upon as a basis
for making an investment decision. It should not be assumed that any investment or
speculative activity that is undertaken in relation to the information described
herein, or any company or asset described herein, will be profitable. There can be
no assurance that future events or market factors will lead to results similar to
those discussed in this paper, or any other paper related to the Bumper project.
Any projections, estimates, forecasts, targets, prospects, and/or opinions
expressed in these materials, or other materials in relation to Bumper, are subject
to change without notice and may differ or be contrary to opinions expressed by
others. No representation or warranty, express or implied, is made as to the
accuracy or completeness of the information contained herein.
Absolutely no guarantees or warranties are, or can be, made. Bumper is an

experimental technology, and this is a technical document that in no way
constitutes, nor should it be construed as, any kind of offer or inducement.
This document may be amended or updated periodically. It is the recipient’s

responsibility to check and/or request for any such updates.
VERSION: 28 April 2022, 11:27am UTC

Litepaper

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Litepaper

Uploaded by

Copyright:

Available Formats

LITEPAPER

2.1 DECENTRALISED APPLICATIONS 3

2.2 EXISTING METHODS OF PRICE PROTECTION 3

2.3 DEFI’S NEW RISK MARKET 4

2.4 CORE ASSUMPTIONS 6

2.4.1 ASSUMPTION ONE: VOLATILITY IS BOUNDED 6

2.4.2 ASSUMPTION TWO: ACTOR HETEROGENEITY 6

2.4.3 ASSUMPTION THREE: INCENTIVE EFFECTIVENESS 7

2.5 PROTOCOL OBJECTIVE 7

3.1.1 TAKER-SPECIFIC FUNCTIONS 8

3.1.2 MAKER-SPECIFIC FUNCTIONS 9

3.1.3 JOINT FUNCTIONS 9

3.2 LIQUIDITY AND LIABILITY 9

3.2.1 POOLS AND RESERVES 9

3.2.2 POOLED VALUE EXCHANGE 11

3.2.3 MEASURING LIABILITY 11

3.3 THE PREMIUM 12

3.3.1 MEETING LIABILITIES 12

3.3.2 POOLED PREMIUMS 12

3.3.3 PREMIUM EFFICIENCY 12

3.4 OTHER FEES AND INCENTIVES 13

3.4.1 NETWORK BOND 13

3.4.2 NETWORK FEE 13

3.4.3 BUMP INCENTIVES 13

3.6.1 VIRTUAL EXCHANGE 15

3.7 MARKET CONFIGURATION 16

4 THE BUMP TOKEN 17

4.1 MARKET ACCESS IN DEFI 17

4.2 DESIGN BACKGROUND 18

4.3 BUMP UTILITY 18

4.3.1 CORE MARKET ACCESS 19

4.3.2 COORDINATION STIMULUS 19

Position Taken by a Maker or Taker when engaging with the protocol.

Floor An individual Taker’s chosen protection price.

Tier An individual Maker’s chosen level of exposure to risk.

BUMP The name of the Bumper protocol token.

Asset Pool Primary pool of ETH in the protocol.

Capital Pool Primary pool of USDC in the protocol.

Capital Reserve A reserve of USDC used to regulate price volatility.

Treasury A fund composed of ETH and USDC that is captured to fund

The Book Total ETH liability to Takers.

The Liability Total USDC liability to Takers.

The Debt Total USDC liability to Makers.

The impact of this is profound.

2.2 EXISTING METHODS OF PRICE PROTECTION

A stop-loss is a simple and universal mechanism available to traders operating on centralised

The Put Option

STOP LOSS ORDER OPTIONS CONTRACT BUMPER

Upside Exposure No Yes Yes

User Experience Simple Complex Simple

Relative Cost Cheap Expensive Cheap

Spread Fixed, but complex and Variable

2.3 DEFI’S NEW RISK MARKET

Pooling in general has two major advantages:

(i) measures and dynamically responds to price change as well as demand,

(ii) shares risk amongst liquidity providers, and

(iii) shares the cost of risk amongst protection buyers

2.4 CORE ASSUMPTIONS

2.4.1 ASSUMPTION ONE: VOLATILITY IS BOUNDED

2.4.2 ASSUMPTION TWO: ACTOR HETEROGENEITY

2.4.3 ASSUMPTION THREE: INCENTIVE EFFECTIVENESS

2.5 PROTOCOL OBJECTIVE

● Remain solvent to both Takers and Makers according to liquidity needs