🧩
Trading Core
The core components of the Buffer Protocol include:
- BufferBinaryPool
- BufferBinaryOptions
- Router
- Keeper
- Publisher
- Admin
The Liquidity pool contract stores deposits and handles the main trading functions.
- Deposits: Funds are deposited into the Vault through the minting of BLP tokens. e.g. if the price of BLP is $1.50, a user can mint 1 BLP by depositing 1.50 USDC tokens.
- Withdrawals: Funds can be withdrawn from the vault through the burning of BLP tokens. e.g. if the price of BLP is $1.50, a user can burn 1 BLP to redeem 1.50 USDC tokens.
Pool locks the liquidity at the time of option buying in order to pay the profit for the ITM options at the time of expiry. The
BufferBinaryOptions contract sends the premium charged while buying an option to the pool.For ITM options at the time of expiry, the locked liquidity is sent as a reward thus resulting in a loss for the pool
For ATM/OTM options at the time of expiry, the locked liquidity is released and nothing is sent to the user. The pool thus makes a profit from the premium collected at the time of option buying
Note: locked liquidity > premium
The admin and other liquidity providers add this liquidity that’s locked in the pool to reward the users for ITM options and make a profit from the OTM and ATM options.
This profit is distributed amongst the LP in the ratio of the liquidity added.
The pool also has a lockup period of 1 day to prevent LPs from immediate withdrawal after an OTM option.
This is an ERC721 contract where each option is an NFT. The router calls this contract to open and close options. Whenever the router opens a trade, this contract mints an NFT token for the user and burns it at the time of closing.
The fee collected by the router is distributed amongst the
BufferBinaryPool and SettlementFeeDisbursal. The opening price for an option now slightly exceeds the current price for "up" options and slightly undershoots it for "below" options. This is the formula:
Spread = f(hv, oi)
- The spread linearly scales from the lowest value which is 0.4 basis points at 2.5% hv to 0.8 basis points(spread config 2) at 16% hv
- Then this lowest value of spread increases linearly to 1.5 (spread factor) times the lowest value as utilization of that market increases
Spread Formula:
function getSpread(
uint256 strike,
bool isAbove,
IOptionsConfig config,
IBufferBinaryOptions optionsContract
) public view returns (uint256) {
uint256 spreadConfig1 = config.spreadConfig1 ();
uint256 spreadConfig2 = config.spreadConfig2 ();
uint256 m = (spreadConfig2 - spreadConfig1) / 1350;
uint256 c = (22 * spreadConfig1 - 5 * spreadConfig2) / 27;
uint256 spread = (m * config.iv ( )) + c;
spread =
((spread *
(config. spreadFactor ()) *
optionsContract.totalMarket0I ( )) /
(le3 * optionsContract .getMaxOI ( ))) +
spread;
return spread;
}
function getSafeStrike(
uint256 strike,
bool isAbove,
IOptionsConfig config,
IBufferBinaryOptions optionsContract
) public view returns (uint256) {
uint256 spread = getSpread (strike, isAbove, config, optionsContract);
return
isAbove
? (strike * (le8 + spread)) / le8
: (strike * (le8 - spread)) / le8;
A single Router is shared by all the options contracts.
Each asset pair has its own options contract linked to a pool(USDC/ARB). The pair is independent of pool's deposit token. eg: in the case of the USDC pool, the user will be paying and winning in USDC.
This is the main contract, the users and keepers interact with.
A trusted admin account that signs the market prices. All the prices are stored offchain and signed by the publisher.
Keepers are special admin accounts that trigger all the transactions on user’s behalf.
Buys options by initiating the trades via router.
Can change all the custom attributes in the contracts.
This contract provides the ability to set/reset all the configurations used by the options contract
This contract stores the referral mapping for who owns which referral code and who referred whom
The Settlement Fees charged while buying an option is sent to this contract via BufferBinaryOptions to distribute it amongst the shareholders specified by the admin
BFR is the governance token of the platform, it is a regular ERC20 token that can be staked for rewards.
BLP is the liquidity provider token of the platform, it can be minted using any of the tokens within the liquidity pool, currently USDC and ARB.
The token’s price is determined by the worth of all tokens within the pool and factoring in the profits and losses of all currently opened positions.
Signature Validation
Publisher fetches the prices every second for the required asset pairs from some off-chain oracle and stores it in the DB along with a signature. The keeper picks up this data to open and close the trades. The contract validates this data by generating a signature and checking if the signer is the publisher.
The contract defines baseSettlementFeePercentageForAbove and baseSettlementFeePercentageForBelow. Sf can be discounted by subtracting (max step reduction * step size) from the base sf. This max step reduction is defined in the BufferBinaryOptions based on the referral.
- settlementFeePercentage = baseSF - (userReferralTierStep * settlementFeeStepSize) - boostPercentage
- settlement fee = settlementFeePercentage * trade size
- For a settlement fee of x%, the payout will be 100 - 2*x
- lower the settlement fee the higher the payout the user can get
- at 20% settlement fee the user can make 1.6x on their bet
- at 12.5% settlement fee the user can make 1.75x on their bet
Example: base_sf can be 20% for Crypto or 12.5% for Forex
Each tier in the Referral has a step reduction associated with it -- let's call it stepReductionViaReferral.
We have a stepSize, suppose its value is 2.5
Then the effective settlement fee for a user trading Forex with a tier 3 referral code (with a step reduction of 3) will be effective settlement fee = base sf - (
stepReductionsViaReferral * stepSize) = 12.5 - (3 * 2.5) = 5 -- > Which results in a payout of 1.9xAll these values are configurable so that we can precisely control the effective settlement fee for each case and thus incentivize the use of the referrals and NFTs on our platform based on the Market conditions
Referrals Discounts
- Referrals allow users to get fee discounts and earn rebates. The referral program has a tier system that helps to ensure that referrers receive the rebates for the users they brought onto the platform. Anyone can create a Tier 1 code. Admin can upgrade their code to Tier 2 or Tier 3.
- Referral System Mechanics:
- Referral Code Usage: Referees can utilize a referrer's referral code while performing trades within the platform. This referral code is provided by the referrer and serves as a unique identifier.
- Referee Benefits: Upon using a valid referral code, referees receive a discount on their trade amount. This incentive motivates referees to engage in trades and encourages them to join the platform through the referrer's invitation.
- Referrer Benefits: Referrers are rewarded with a rebate for each successful referral. This encourages existing users to invite new users to the platform, thereby expanding the user base.
- The "openTrades()" function, responsible for trade execution accepts a referral code as an argument. By passing the referral code to this function, referees become eligible for the associated discounts and referrers qualify for rebates.
- Settlement Fee Discount(SF) and Increased Payout: When a valid referral code is provided as an argument to the "openTrades()" function, referees are granted a discount on the settlement fee for their trades which results in increased payout.
Boosts Discounts
- Coupon Purchase and Boost Mechanism:
- Coupon Purchase: Users have the option to buy coupons from the platform to receive further discounts on the SF. The coupon price can be changed by the admin
- Boost Percentage: The boost percentage, also predetermined by the admin, determines the extent of the discount that users can avail themselves of using the purchased coupons.
- Limited Use: Each coupon offers boosts on a fixed number of trades. Once a user exhausts the specified number of trades, the coupon's benefits cease.
- NFT Tier-Based Discount: Users with NFTs can unlock additional discounts on coupon prices based on their NFT tiers. Owning higher-tier NFTs provides users with greater price reductions when purchasing coupons, encouraging engagement with the NFT ecosystem.
- Boost on SF with Referral Discounts: The boost percentage provided by the coupons is applied on top of any referral discounts. This cumulative discount mechanism ensures that users receive the maximum benefit from the available discount options.
Suppose a user pays 100 USDC to open an "up" position on ETH-USD and their effectiveSettlementFee for this trade was 20% then we'll take 20% from the amount paid by the user as protocol fees --> 20 USDC
Then we'll transfer the rest (80 USDC) to the pool and then lock another 80 USDC in the pool for the user in case the trade ends ITM (in the money).
If their trade ends ITM then we pay out 160 USDC ( 2 x 80) from the pool to the user.
This means with a 20% effectiveSettlementFee the user can make 1.6x (160 USDC on a 100 USDC trade)
Settlement Fees on Buffer are now dynamic, influenced by trading volume and payout.
Logic: periods of extreme turbulence in the market should attract higher fees since the platform is exposed to greater risk. Such a fee will also further decrease the possibility of the volatility surface being manipulated. For this reason, we have implemented a new fee mechanism under which we call the dynamic fee.
Formula:
On the FE the users can find an option to configure the slippage and partial fill.
This opens a trade of the max possible value and refunds the rest of the fees back to the user. If the user tries to buy trade for more than what the pool allows then the contract will check if the allowPartialFill flag is true.
In our case, slippage is used as the accepted price movement b/w when the user initiates the trade and when the trade is actually opened.
The FE(frontend) is fetching the price feed from some Price APIs(which take a median over multiple exchanges) --> when the user opens the trade from the FE )(launching an
initiateTrade txn), this price from the API is used --> then when the keeper opens the trade it provides the price at the blockNumber where the initiateTrade txn was accepted. So there can be a difference b/w the price provided on the FE and that used by the keeper, that is why we check for slippage.
The trade will be opened at the price provided by the keeper if it's within the slippage with the price provided by the user.
In our case -- Locking means that the funds will not be used to underwrite new options.
When the user pays 100 USDC for the trade, assuming the settlement fee is 20%, the remaining 80 USDC goes to the pool as l
ockedPremium -- this fund is locked until the option expires.Then another 160 USDC from the pool's balance is locked as
lockedAmount until the option expires.The above
lockedPremium is given to the pool as a reward for taking the risk over the lockedAmountNow 2 cases can happen --
1. if the option ends ITM -- in this case, the entire
lockedAmount is paid to the option's owner, and the lockedPremium is unlocked -- so the Pools net loss is lockedAmount - lockedPremium on this trade.2. if the option ends OTM -- in this case nothing is paid to the option's owner and the pool unlocks both lockedAmount and lockedPremium, and the pool's net profit is lockedPremium on this trade.
We have the following keeper:
- Open Keeper
- Close Keeper
- Early Close keeper
- Revoke Keeper
In every iteration, the keeper calls a
datasource to fetch the signed pending transactions that the user intends to broadcast on chain.The publisher signs market prices required to open/close for a given market at a given time.The keeper collects all the information and writes these pending transcations on chain.
Last modified 1d ago