Whitepaper: REX on BNB Smart Chain (BSC)

For example, in REX it’s possible to name stakes (to keep track of their purpose), split stakes (for instance, in a divorce), transfer an active stake to another address (for example, as a gift) and even withdraw already-earned staking rewards while a stake is active (instead of having to emergency-end it early). The user may also choose to create a stake as revocable (the stake can be ended early and the user can withdraw staking rewards before maturity) or irrevocable (the stake can’t be ended early and the user can’t withdraw staking rewards before maturity) to increase its Annual Percentage Rate (APR).

In the Initial Liquidity Phase users may send BUSD to the contract where it is collected. At the beginning of REX DAY 2, it mints new REX tokens and sends a predefined portion of the BUSD and REX to PancakeSwap as "initial liquidity", the rest is added over the course of 200 days. The contract receives and stores the LP Tokens as they are gradually added to the liquidity pool over the first 200 days. The participants may withdraw their LP tokens from the contract starting on day 223, 10% every 30 days. The advantage for participants providing liquidity is they add liquidity without having to provide the REX half, as it is minted for free.

Special feature: When claiming REX from an auction participation as a stake, the user will be eligible for Random Personal Big Pay Days. This feature was invented by REX to incentivize auction participation and was a popular feature in the original REX protocol. Every 24 hours a random generator distributes 75% of the BUSD received from auction that day back to eligible addresses. If an address gets hit, the contract tries to give that address all invested BUSD back, then the contract continues with the next eligible address, and so on, until the "Random-BUSD-pool" is empty. Remaining eligible means an address can be hit every day, again and again. There is no limit to the number of times a wallet can be hit. This is a unique feature only seen in REX.

⚠️ If you reveal your private keys to anyone, assume all your funds will be stolen.
⚠️ If you reveal your seed phrase to anyone, assume all your funds will be stolen.
⚠️ If you reveal your wallet password to anyone, assume all your funds will be stolen.
⚠️ If you connect your wallet to any third-party website or app, your funds can be stolen.
⚠️ When using a website/app, make sure it is official and the domain is written correctly.
⚠️ Always use contract addresses, not the name of tokens, to avoid fakes and imposters.

⚠️ Don't rely on social media. If you do, please be aware of the following risks.
⚠️ Be aware, people do steal identities, fake accounts and deceive.
⚠️ Never reveal any sensitive data to anyone for whatever reason.
⚠️ Never consider other people’s words/messages/posts as financial advice.
⚠️ Always do your own research (DYOR). Take responsibility for your actions.
⚠️ Take all the time you need to do your own research. Don't let anyone rush you.
⚠️ If anyone asks you to use third-party websites or apps or to send tokens, report them.

There is one exception. After deployment and initialization of the DAILY AUCTIONS contract, that manages the auction phase in REX and creates most of the supply in the beginning of REX, one address, the GAS_REFUNDER, has additional rights. This address is allowed to send BNB to the DAILY AUCTIONS contract (which will be used for refunding gas fees to users) and withdraw tokens from the contract after the LAST CONTRACT DAY (when the auction phase is over and the TREASURY and all POOLS have already been emptied by the users). This right will be necessary to withdraw the remaining unused BNB and for withdrawing other tokens from the contract. For example, it can retrieve tokens that have accidentally been sent to the contract and would be otherwise unrecoverable (which happens a lot). To grant full security, this withdrawal permission explicitly excludes the REX-BUSD LP TOKENS that will wait in the contract for initial liquidity providers even after the auction phase.

10% of the BUSD sent to the auctions is forwarded to the REX-BUSD Liquidty Pool (LP pair) on PancakeSwap, together with the corresponding amount of new REX, in several transactions throughout the day, whenever the BUSD amount to send reaches or exceeds 500 BUSD - limited to 1000 BUSD per transaction. The quantity of REX, which is minted and sent with the BUSD, depends upon the amount of forwarded BUSD and the actual price ("reserves") on PancakeSwap. The LP tokens are burnt, so the liquidity is forever locked and cannot be withdrawn.

A portion (1/200) of the Initial Liquidty (if any) is forwarded to the REX-BUSD Liqudity Pool (LP pair) on PancakeSwap, together with the corresponding amount of new REX, in several (500 BUSD + x REX) transactions throughout the day until the 1/200 is reached. The number of REX, which is minted and sent with the BUSD, depends upon the amount of forwarded BUSD and the actual price ("reserves") on PancakeSwap. The LP tokens received are stored in the contract and may be withdrawn by the liquidity providers when the auction phase has ended.

These new daily inflation REX tokens are not immediately minted. Instead, they are earmarked for distribution to all active stakes’ SHARES on that day. A fraction of this new REX is earmarked for each active stake in proportion to the stake's percentage of SHARES with respect to the total SHARE pool that day. Once a stake is closed (or staking rewards withdrawn), all earmarked tokens of the stake for all past days (until the desired withdrawal day, in case of a staking rewards withdrawal) are then minted at once.

    Closing a pending stake - the stake SHARES are destroyed. The entire stake principal is minted back to the user, without rewards or penalty.
    Closing an active (premature) stake - the stake SHARES are destroyed. The stake principal is penalized (see below) and minted back to the user along with all rewards accumulated thus far.
    Closing a mature stake - the stake SHARES are destroyed. The entire stake principal and all rewards accumulated are minted back to the user. If the stake is closed later than 14 days after maturity, the rewards are penalized by 1% per week thereafter.

In case there are 0 BUSD, the following will happen: The functions managing initial liquidity will not trigger. No LP tokens will be created. Still, liquidity might be added to the LP pair with the beginning of REX DAY 2, as the addLiquidity function of the daily auctions will also try to add liquidty in that moment: the 10% of the BUSD sent to the daily auctions on REX DAY 1. So, just in case there were no INITIAL_LIQ_BUSD, the addLiquidity function of the daily auctions will still provide some liquidity to the LP pair and - in this special case - also take over the task of setting the LP pair's starting price to 0.000139997 BUSD/REX by minting 7143 REX per BUSD.

On auction day 1 there will be 200,000,000 REX in the auction.
On auction day 2, there will be 140,000,000 REX in the auction.
On auction day 3, there will be 90,000,000 REX in the auction.
After day 3, the daily amount decreases by 130,000 REX every day.
On auction day 4, there will be 89,870,000 REX in the auction.
On auction day 5, there will be 89,740,000 REX in the auction.
...
On auction day 220, there will be 61,790,000 REX in the auction.
On auction day 221, there will be 61,660,000 REX in the auction.
On auction day 222, there will only be 53,230,000 REX in the auction.

On each REX reservation, the user may provide a referrer's address. The REX contract then makes note of the referrer's address and associates it with the referee's token reservation. The contract also tags the user's token reservation as having been through a referral, and this reservation is credited as having been 10% more BUSD than it actually was. When the user mints their reserved tokens at the beginning of the next day, each token reservation that was through a referral will thus mint 10% more REX than if it hadn't been through a referral.

The event of claiming REX from auctions as a stake makes an address eligible to receive BPDs (in all future BPD events). The amount of BUSD sent to auction is saved in the originalDonation storage for that address. This originalDonation of the address is the number of BUSD the address shall receive when chosen by the random generator, as long as the address is eligible. All further auction participations will raise the addresses' originalDonation and every personal BPD tries to pay back the originalDonation every time.

[Edited March 11, 2023: The above sentence is from an old paper version and unfortunately has not been updated to the new contract behavior. Correct is: "All auction participants who did not receive a Big Pay Day will receive their share from the Treasury". Notably, his discrepancy was not noticed by the three audit firms. Comment: The Treasury was designed to return all (!) remaining BUSD to auction participants who did not receive a Big Pay Day (after the contract has fulfilled its task of managing the auction phase) - instead of keeping the BUSD in the project - and this is still what the contract does. It has to be admitted that the paper here was not 100% correct, but anyway all BUSD will be given to the participants.]

    The REX contracts are written entirely in Solidity and compiled with solc 0.7.4.
    The code should adhere to the formats prescribed by the style guide section of in the official Solidity 0.7.4 documentation.
    All public interfaces (at a minimum) should be annotated using the NatSpec format.
    Unit tests should provide 100% coverage of the source code. All conceivable edge and corner cases should be covered.
    Function and variable names should convey their purpose and usage as clearly and tersely as possible, in plain English. Avoid using digits, unnecessary abbreviations, acronyms, shorthand, or slang.
    Functions should be as short as is practical. They should do what their name implies, and not much else. A good rule of thumb is that a function should try to be viewable in its entirety on a typical monitor, at a typical font size, if at all possible.
    Comments should be employed wisely. Don't comment to explain what code does. Good function and variable names will accomplish that. Rather, use comments to explain why something is coded a certain way. Use comments to explain any non-obvious technical points or decisions involved in a piece of code.
    require() function calls should return a short but descriptive error message.
    Avoid duplicated code (don't repeat yourself).
    Wherever possible and practical, write with gas efficiency as a priority. Some parts of the code may sacrifice minuscule gas efficiencies for various important reasons. When deemed to be of greater value, code legibility, clean architecture, and a straightforward and fully featured end-user experience should take priority over such tiny gas savings.

Go to the APP

Whitepaper

v3.00.00.BSC.MAINNET

written by the REX community
Date of issue: 2022-06-25

Whitepaper

v3.00.00.BSC.MAINNET

written by the REX community Date of issue: 2022-06-25

written by the REX community
Date of issue: 2022-06-25