βš™οΈHow it works

Basics

BurnifyApp operates on a cycle-based system, with each cycle lasting approximately 24 hours. During every cycle, a predetermined amount of $BFY tokens is minted. The initial cycle begins with the minting of 10,000 $BFY tokens, decreasing by 0.2% with each subsequent cycle. For example, the first day mints 10,000 $BFY, the second day 9,980 $BFY, and so forth, reaching around 5,000 $BFY by the 365th day and eventually tapering off to zero around the 22,630th day.

  • The process is designed to happen in cycles. Every cycle would take ~24 hours.

  • Every cycle a fixed quantity of $BFY is set to be minted. 1st day should start with 10,000 and decrease by 0.2% every cycle.

  • 1st day: 10 000 $BFY 2nd day: 9 980 $BFY ... 365th day: 5 000 $BFY ... ~22630th day: 0 $BFY

How to get $BFY

To acquire $BFY tokens, users must send at least one batch to the Smart Contract within a cycle. Each batch requires a total contribution of 0.03 $EGLD, split as follows:

1 batch = 0.03 $EGLD in total

1 batch = 0.015 $EGLD + 0.015 $EGLD in $MEX/$ONE/etc

$BFY Cycle distribution

At the end of each cycle, the Smart Contract should distribute the allocated $BFY tokens proportionally based on the number of batches each user has contributed. For instance, on the first day, 10,000 $BFY should be distributed to participants who have sent batches. The maximum number of batches allowed per user is set to 10,000.

UserRewardsCycle=TotalRewardsCycleβˆ—UserBatchesNb/TotalBatchesCycleβˆ—90UserRewardsCycle = TotalRewardsCycle * UserBatchesNb/TotalBatchesCycle * 90%

$MEX & other tokens

There could be more tokens listed in Burnify alongside $MEX. BurnifyApp supports the burning of multiple tokens within the MultiversX ecosystem, including but not limited to $MEX, $ONE, $JEX, $RARE, $XLH, $CPA, $BSK, $XBID, $UPARK, $XBONK, $HYPE, $CTP, $ESTAR, $BHAT, $SFIT, $XAPES, $AERO, $PADAWAN, $ZPAY, $KRO, etc. At the end of each cycle, all tokens except $EGLD should be burned through their corresponding Smart Contracts, ensuring effective supply reduction.

  • At the end of every cycle, all these tokens except $EGLD should be BURNED by means of the corresponding Smart Contract.

Slippage

Users should have the option to set a slippage percentage when creating batches to account for token price fluctuations. The target peg for tokens is 0.015 $EGLD per batch. For example, if a user sets a slippage of 1% and attempts to burn 88 $ONE tokens, the Smart Contract should require 88.88 $ONE. If the price of $ONE fluctuates beyond the set slippage during the transaction, the batch should fail. Otherwise, any excess tokens beyond the slippage tolerance should be returned to the user.

Example: 1 batch = 0.015 $EGLD + 88 $ONE Slippage set to 1%: user will send 0.015 $EGLD + 88.88 $ONE.

EGLD

All $EGLD contributions in a cycle should be pooled and distributed as follows:

  • 90% should be distributed proportionally to all cycle participants who are staking $BFY.

  • 5% should be allocated for administrative costs, including team expenses, marketing, design, hosting, new feature development, operations, partnerships, and reserve funds.

  • 5% should be allocated to BUFU NFT strength holders.

Claiming rewards ($BFY)

At the end of each cycle, $BFY tokens assigned to a user should be automatically staked within the protocol. If a user chooses to claim their $BFY tokens, they will no longer generate protocol fees ($EGLD) for the current and subsequent cycles. To resume earning $EGLD rewards, users must re-stake their $BFY tokens.

  • There is no lock or unbonding period required for claiming $BFY.

There is NO lock/unbonding period for claiming $BFY.

Claiming Protocol Fee ($EGLD)

All rewards earned through protocol fees ($EGLD) would be available for withdrawal at any time, allowing users to access their earnings as needed.

Staking $BFY

  • Unclaimed $BFY tokens would be automatically staked within the protocol, so the process of claim -> stake can be deemed redundant.

  • Claimed or unstaked $BFY tokens need to be staked back into the protocol in order to be able to receive further rewards.

  • In order to avoid flash loans, after staking $BFY, it was settled that the users wouldn't be able to withdraw $BFY tokens for the current cycle and the next cycle, but they would still generate protocol rewards.

Why burn tokens and join the process?

Participating in the token-burning process would offer a range of benefits for users and the ecosystem:

Earn rewards: Users receive $BFY tokens and $EGLD rewards for their contributions further generating locking benefits. Provide a burning service: Burning project tokens in exchange for fairly determinable amounts of $BFY tokens can provide desirable benefits for some users. In addition, for those who would still hold that respective project token, this may enhance its scarcity.

Foster ecosystem growth: The process would encourage long-term commitment, promoting a healthy and robust community that can contribute based on an outstanding concept to the $BFY token's success within the Web3 environment. Support scarcity of your project tokens: By removing tokens from circulation, burning can help maintain the overall value and relevance of the project tokens.

Incentivize engagement: The process may attract users to actively engage each cycle, driving further growth and adoption.

Promote sustainable growth: By managing token supply and distributing rewards, the process encourages sustainable growth, benefiting the ecosystem in the long run.

Claim $BFY: At any point, you would have the option to claim your $BFY tokens and trade them on a DEX.

Last updated