# Intro (What Is WaxFusion) {% hint style="info" %} WaxFusion is an open-source liquid staking protocol on [WAX Blockchain](https://wax.io). Developed by the team behind [waxdao.io](https://waxdao.io) and sponsored by WAX. {% endhint %} ## Why WaxFusion? With WaxFusion, users can earn staking rewards on their WAX while still having access to their liquid capital. Normally when you hold WAX tokens, you have 2 choices: * Stake them and vote for block producers to earn \~8% APR, which comes with a 3 day unlock period before you can get your WAX back * Keep your tokens unstaked so you can use them for other opportunities, at the sacrifice of your staking rewards With WaxFusion, you can do both at the same time. By depositing your WAX into our open-source contracts, we handle all the staking (and voting) for you. That's right - most people don't realize that you have to actively vote for block producers on a weekly basis in order to earn the maximum APR on WAX. WaxFusion takes all that hassle away from you and acts as an open source proxy that votes for the top 21 block producers on a daily basis. When you make your deposit, you will receive a liquid token that allows you to engage in other opportunities and still earn staking/voting rewards so you can get the best of both worlds. Furthermore, WaxFusion uses funds to generate additional rewards for you via CPU rental fees, instant redemption fees, liquidity provision fees, protocol owned liquidity, and more. More details on these fee generation mechanisms can be found throughout this documentation. ## Quick links {% content-ref url="/pages/YQmCihnqQsdBxHaY8erX" %} [lsWAX Exchange Rate](/tokens/lswax-exchange-rate) {% endcontent-ref %} {% content-ref url="/pages/4k7Zh6J1tDhjOjG18DeM" %} [Tokens](/tokens) {% endcontent-ref %} {% content-ref url="/pages/5qKnIDFA9S0NDDVmrCQx" %} [Smart Contracts](/smart-contracts) {% endcontent-ref %} # Tokens WaxFusion has 2 native tokens - sWAX and lsWAX. Both of them are fully backed with actual WAX tokens, and started off with a supply of 0. These tokens are minted on demand when new WAX tokens are deposited into the platform, and destroyed again upon redemption. Therefore, their supply is elastic, and limited to the amount of WAX in WaxFusion's smart contracts. You can find more details about both tokens using the links in this section. ### Quick Breakdown | | sWAX | lsWAX | | --------------------------------------------- | ------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | | Transferable | No | Yes | | Autocompounds | No | Yes | | Need To Claim Rewards | Yes | No | | Earns Rewards Every Second | Yes | Yes | | Can Be Used For Other DeFi Opportunuties | No | Yes | | Need To Vote For Block Producers | No | No | | Reward Method | You claim WAX whenever you want | Your lsWAX gets backed by more WAX (autocompounding) | | Token Balance Changes When Rewards Are Earned | No | No | | WAX Per Token | 1 WAX = 1 sWAX always | Depends on how much WAX each 1 lsWAX is backed with. As lsWAX gets backed with more WAX, 1 lsWAX always goes up in value against 1 WAX | And to understand the benefits of WaxFusion, here's another table comparing lsWAX to staking WAX on your own. | | lsWAX | Staking WAX Yourself | | ---------------------------------- | ----- | -------------------- | | Autocompounds | Yes | No | | Need To Claim Rewards | No | Yes | | Can Access Your Capital | Yes | No | | Need To Vote For Validators | No | Yes | | Efficient | Yes | No | | Get Free Resources (CPU/NET) | No | Yes | | Earn From CPU Rentals | Yes | No | | Earn From Protocol Owned Liquidity | Yes | No | | Earn While You Unstake | Yes | No | | Helps Grow The Ecosystem | Yes | No | # sWAX When users stake WAX into the protocol, they will receive sWAX by default. sWAX is a non-transferable token that is held in the dapp.fusion smart contract, and issued at a 1:1 ratio based on the amount of WAX staked by the user. Holding sWAX allows users to earn staking rewards from the protocol, via a claimable WAX balance. Rewards accrue every second, and will remain available for claiming regardless of how long you wait. When claiming sWAX staking rewards, there are 3 options. * Claim native WAX tokens * Compound your sWAX by claiming more sWAX * Claim lsWAX, which is issued based on the current ratio of WAX:lsWAX sWAX rewards do not autocompound. If users ever want to convert their sWAX back into native WAX tokens, they have 3 options: * Liquify their tokens instantly and sell on the open market (amount of WAX received is subject to market conditions) * Instant redemption through WaxFusion (has a 0.05% fee and is subject to availability based on how much WAX is in the instant redemption pool) * Submit a withdrawal request through WaxFusion, which is free and can take anywhere from 1-21 days. sWAX withdrawals done directly through WaxFusion will be converted at a 1:1 ratio. # lsWAX Users can choose to convert their non-transferable sWAX tokens into lsWAX, which is a liquid, transferable token that can be used as capital for other DeFi opportunities. lsWAX started off at a 1:1 ratio with sWAX when WaxFusion was launched. As rewards are generated by the protocol, profits are used to buy back additional sWAX and increase the backing of lsWAX. Therefore, lsWAX is an autocompounding token that allows users to earn staking rewards simply by holding the token in their wallet. As a matter of fact, lsWAX can also be used for providing liquidity against other WAX tokens. Liquidity providers will still earn yield on their lsWAX while having it locked in a liquidity pool. This allows lsWAX holders to earn staking rewards while participating in other ecosystems. In other words, it makes little sense to pair tokens against native WAX now that WaxFusion exists. Why sacrifice your staking rewards to provide liquidity, when you can do both at the same time by using lsWAX in your liquidity pool? To redeem lsWAX, there are 3 choices: * Sell it instantly on the open market, (conversion rate is subject to market conditions) * Unliquify it (convert it back into sWAX) on WaxFusion, and submit a withdrawal request. Withdrawals can take 1-21 days depending on how far into an epoch we are, and how much WAX is available for redemption in the current and upcoming epochs. * Unliquify it and do an instant redemption on WaxFusion, which has a 0.05% fee and is subject to availability based on how much WAX is available in the instant redemption pool. # lsWAX Exchange Rate {% hint style="info" %} There has been some confusion about how the lsWAX exchange rate works. We hope this page can clarify things for you. {% endhint %} Let us start off by saying that when we say "Exchange Rate", what we are referring to is the "Backing" of lsWAX. That is, the amount of WAX in the protocol that is ***backing*** your lsWAX. We are **not referring to the price on decentralized exchanges**, as we have 0 control over that. The open market will do what the open market wants to do. It is not something in our control. We are talking solely about exchanging WAX to lsWAX, and vice versa, **directly on WaxFusion.** ### Example Scenario #### Minting Let's use a hypothetical example here. When WaxFusion first launched, there were 0 WAX in the protocol. There were also 0 lsWAX in existence. This means that if you wanted 1 lsWAX, you would've had to deposit 1 WAX (since 0 WAX was backing 0 lsWAX at this time, the exchange rate was 1 to 1). So, you deposited 1 WAX and got 1 lsWAX. 1 WAX is now backing 1 lsWAX. The exchange rate would still be 1 to 1 at this time, which means that you could bring your 1 lsWAX back to WaxFusion, and exchange it for 1 WAX. #### Rewards Now, let's say that you hold the 1 lsWAX in your wallet for a week. The 1 WAX that you deposited into the protocol will be staked, and possibly also used for CPU rentals. Let's pretend that this 1 WAX that you deposited was able to generate 0.1 WAX in rewards. If this happened, it would mean that **1.1 WAX is now backing lsWAX,** but there is still **only 1 lsWAX** that exists. This means that the new exchange rate (or *backing*) is now 1.1 WAX = 1 lsWAX. Your 1 lsWAX can now be redeemed for 1.1 WAX instead of just 1 WAX - because your initial 1 WAX is still there, plus the 0.1 WAX in rewards that it generated. #### New User Mints lsWAX At this time, we know that the exchange rate is 1.1 WAX for 1 lsWAX. This means that if a **second user** comes along and wants to mint 1 lsWAX, they need to deposit at the **current exchange rate**. This new user needs to deposit 1.1 WAX for every 1 lsWAX that they want to mint, because that is the current ratio. ### Can The Exchange Rate Ever Go Down? No! Keep in mind that once again, **we are only talking about the WaxFusion exchange rate** here (the backing of lsWAX). This has absolutely nothing to do with the price on any decentralized exchange. Since your WAX deposit stays in the protocol, and your lsWAX is constantly backed by the extra rewards that it earns, the exchange rate can only go up (1 lsWAX becomes worth more WAX over time). The only way that the exchange rate could go down, is if your WAX deposit went **"*****poof"***, and disappeared. The WAX that you deposited does not disappear into thin air. It remains there until it is redeemed. Since our contracts are open source and under a multisig with the WAX team, multiple block producers, and the OIG, we could not touch your funds even if we wanted to. **Code is law**. # Smart Contracts All of WaxFusion's smart contracts are fully open source and available for viewing on Github. In this section you will find a list of our contracts, descriptions of what they do, and links to their Github repositories. Furthermore, our contracts are audited by the WAX team, and under a 4 of 6 multisig permission structure - which means that we can not make any changes to them without 3 other signatures. The permissions for each contract can be found at the following URLs. | Contract | Link | | ------------ | ----------------------------------------------- | | dapp.fusion | | | token.fusion | | | pol.fusion | | | cpu1.fusion | | | cpu2.fusion | | | cpu3.fusion | | # dapp.fusion Our main dApp contract is the one that users interact with when they engage with the protocol. The WAX address for this contract is dapp.fusion The Github repo can be found at the following link: {% embed url="" %} To get a breakdown of the actions and tables on this contract, use the quick links below. ## Quick Links {% content-ref url="/pages/u4suWl8CSqwL4KB86etl" %} [Actions](/smart-contracts/dapp.fusion/actions) {% endcontent-ref %} {% content-ref url="/pages/VgblWnqOHrBDfisiKmxD" %} [Tables](/smart-contracts/dapp.fusion/tables) {% endcontent-ref %} {% content-ref url="/pages/9WbhW36C10pi1XvWeHHN" %} [Notification Memos](/smart-contracts/dapp.fusion/notification-memos) {% endcontent-ref %} # Actions This page lists all actions on the dapp.fusion contract, including their descriptions and a list of the parameters for each action. ## Quick Links [#addadmin](#addadmin "mention") [#addcpucntrct](#addcpucntrct "mention") [#claimaslswax](#claimaslswax "mention") [#claimgbmvote](#claimgbmvote "mention") [#claimrefunds](#claimrefunds "mention") [#claimrewards](#claimrewards "mention") [#claimswax](#claimswax "mention") [#clearexpired](#clearexpired "mention") [#compound](#compound "mention") [#createfarms](#createfarms "mention") [#init](#init "mention") [#inittop21](#inittop21 "mention") [#instaredeem](#instaredeem "mention") [#liquify](#liquify "mention") [#liquifyexact](#liquifyexact "mention") [#reallocate](#reallocate "mention") [#redeem](#redeem "mention") [#removeadmin](#removeadmin "mention") [#reqredeem](#reqredeem "mention") [#rmvcpucntrct](#rmvcpucntrct "mention") [#rmvincentive](#rmvincentive "mention") [#setfallback](#setfallback "mention") [#setincentive](#setincentive "mention") [#setpolshare](#setpolshare "mention") [#setrentprice](#setrentprice "mention") [#stake](#stake "mention") [#stakeallcpu](#stakeallcpu "mention") [#sync](#sync "mention") [#unstakecpu](#unstakecpu "mention") [#updatetop21](#updatetop21 "mention") ### addadmin > Adds a new admin wallet into the config table. Admin wallets are able to call certain actions that don't pose any risk to user funds, but are sensitive enough that they should not be able to be called by random wallets. Requires auth of this contract. | Parameter | Type | Description | | -------------- | ---- | ----------------------------------------------------- | | admin\_to\_add | name | The WAX address of the admin to be added to the table | ### addcpucntrct > Adds a new CPU contract to the config table. CPU contracts are the contracts that funds are sent to when staking/renting WAX to users (or the fallback\_cpu\_receiver). Requires auth of this contract. | Parameter | Type | Description | | ----------------- | ---- | ------------------------------------------------------------ | | contract\_to\_add | name | The WAX address of the CPU contract to be added to the table | ### claimaslswax > Allows an sWAX holder to claim their claimable\_wax, and have it converted to lsWAX in a single transaction. Requires auth of the user with the claimable balance. | Parameter | Type | Description | | --------------- | ----- | ------------------------------------------------------- | | user | name | The wallet address of the user signing the transaction | | minimum\_output | asset | The minimum amount of lsWAX the user expects to receive | ### claimgbmvote > Claims voting rewards from the CPU contract passed to the action. Voting rewards are automatically sent back to the main contract and added to the revenue\_awaiting\_distribution bucket. Can be called by anyone. | Parameter | Type | Description | | ------------- | ---- | -------------------------------------------------------------------- | | cpu\_contract | name | The WAX address of the CPU contract that has voting rewards to claim | ### claimrefunds > Loops through the cpu\_contracts in the config table, and claims available refunds from the system contract if any are available. Can be called by anyone. ### claimrewards > Allows a user to claim their claimable\_wax. Requires auth of the user with a claimable\_wax balance. | Parameter | Type | Description | | --------- | ---- | --------------------------------------------------------- | | user | name | The WAX address of the user who is claiming their rewards | ### claimswax > Allows a user to compound their sWAX by turning their claimable\_wax into more sWAX. Requires auth of the user. | Parameter | Type | Description | | --------- | ---- | --------------------------------------------------------- | | user | name | The WAX address of the user who is claiming their rewards | ### clearexpired > Allows a user to delete any of their expired redemption requests from the redeem\_requests table, freeing up their RAM. Requires auth of the user. | Parameter | Type | Description | | --------- | ---- | --------------------------------------------------------- | | user | name | The WAX address of the user who is claiming their rewards | ### compound > Claims any rewards available for swax\_currently\_backing\_lswax, and uses them to buy more sWAX to increase the backing of lsWAX. Can be called by anyone, once every 5 minutes. ### createfarms > Takes any lsWAX from the state2 singleton's incentives\_bucket, and creates LP farms on Alcor. Farm allocations are in proportion to the poolId's parts\_to\_allocate / total parts of all pairs in the lpfarms table. Can be called by anyone. ### init > Initializes the global singleton, rewards singlegon, and creates the initial epoch. Requires auth of this contract. ### inittop21 > Initializes the top21 singleton. Requires auth of this contract. ### instaredeem > Allows users to instantly redeem their sWAX for liquid WAX instead of submitting a request and waiting 1-21 days. Incurs a 0.05% fee which goes to the protocol, and is only available if the amount of WAX in wax\_available\_for\_rentals is >= the amount of sWAX the user wants to redeem. Requires auth of the user. | Parameter | Type | Description | | ---------------- | ----- | --------------------------------------------------------------- | | user | name | The WAX address of the user who wants to instaredeem | | swax\_to\_redeem | asset | The amount of sWAX that the user wants to redeem for liquid WAX | ### liquify > Allows a user to convert their sWAX into lsWAX. Requires auth of the user. | Parameter | Type | Description | | --------- | ----- | ------------------------------------------------ | | user | name | The WAX address of the user who wants to liquify | | quantity | asset | The amount of sWAX the user wants to liquify | ### liquifyexact > Allows a user to convert their sWAX into lsWAX, and also specify the minimum amount of lsWAX they expect to receive. While there is not actually any slippage/price impact incurred when liquifying, we decided it was a good idea to allow users to specify their minimum output in case they are trying to arbitrage on exchanges, and want to make sure they know exactly how much of an asset they are trading. Requires auth of the user. | Parameter | Type | Description | | --------------- | ----- | ----------------------------------------------------- | | user | name | The WAX address of the user who is calling the action | | quantity | asset | The amount of sWAX that the user wants to liquify | | minimum\_output | asset | The amount of lsWAX the user expects to receive | ### reallocate > If the most recent redemption window has ended, this action takes any unredeemed funds and reallocates them by recycling them back into the wax\_available\_for\_rentals pool. Can be called by anyone. ### redeem > If a user has requested a redemption, and the redemption window for their request is currently active, they can call this action to claim the requested funds. Requires auth of the user. | Parameter | Type | Description | | --------- | ---- | ----------------------------------------------------- | | user | name | The WAX address of the user who wants to redeem funds | ### removeadmin > Removes an admin wallet from the config singleton. Requires auth of this contract. | Parameter | Type | Description | | ----------------- | ---- | --------------------------------------------- | | admin\_to\_remove | name | The WAX address of the admin wallet to remove | ### reqredeem > Allows a user to request a redemption so they can convert their sWAX into liquid WAX. Requires auth of the user. | Parameter | Type | Description | | --------------------------------- | ----- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | user | name | The WAX address of the user who wants to request a redemption | | swax\_to\_redeem | asset | The amount of sWAX that the user wants to redeem | | accept\_replacing\_prev\_requests | bool | Redemption requests will replace any previous redemption requests. If this is set to false, the transaction will fail unless the user has no pending requests | ### rmvcpucntrct > Removes a CPU contract from the config singleton. Requires auth of this contract. | Parameter | Type | Description | | -------------------- | ---- | --------------------------------------------- | | contract\_to\_remove | name | The WAX address of the CPU contract to remove | ### rmvincentive > Removes an incentive from the lpfarms table. Requires auth of this contract. | Parameter | Type | Description | | --------- | --------- | ------------------------------------------------------ | | poolId | uint64\_t | The pool ID of the pair on Alcor's swap.alcor contract | ### setfallback > Allows an admin wallet to set the fallback\_cpu\_receiver in the config table. Requires auth of the admin wallet calling the action. | Parameter | Type | Description | | --------- | ---- | ------------------------------------------------------- | | caller | name | The WAX address of the admin wallet calling this action | | receiver | name | The WAX address of the new fallback\_cpu\_receiver | ### setincentive > Adds or updates an incentive in the lpfarms table. Requires auth of this contract. | Parameter | Type | Description | | ------------------------- | --------- | ---------------------------------------------------------------------------------- | | poolId | uint64\_t | The pool ID of the pair that we want to incentivize on Alcor's swap.alcor contract | | symbol\_to\_incentivize | symbol | The symbol of the token to create a farm for | | contract\_to\_incentivize | name | The contract of the token to create a farm for | | percent\_share\_1e6 | uint64\_t | The 1e6 scaled percentage of liquidity rewards to allocate to this pair | ### setpolshare > Adjusts the percentage of revenue that goes to the protocol. This can only be set between 5-10%. Note that this does not affect the percentage that goes to users - it only changes the balance between protocol/ecosystem fund. Requires auth of this contract. | Parameter | Type | Description | | ---------- | --------- | ------------------------------------------------------------------------------- | | pol\_share | uint64\_t | The 1e6 scaled percentage of revenue that should go to protocol owned liquidity | ### setrentprice > Allows an admin wallet to adjust the price for CPU rentals. Requires auth of the admin wallet calling the action. | Parameter | Type | Description | | ---------------------- | ----- | ------------------------------------------------------------- | | caller | name | The WAX address of the admin wallet calling this action | | cost\_to\_rent\_1\_wax | asset | The WAX amount to charge for each 1 WAX rented for 1 full day | ### stake > This action is required before a user is able to mint sWAX. It stores a row for the user in the stakers table, for which they pay the RAM cost. Requires auth of the user. | Parameter | Type | Description | | --------- | ---- | ----------------------------------------------- | | user | name | The WAX address of the user calling this action | ### stakeallcpu > If the current time is >= the next\_stakeall\_time in the state singleton, this action will take any funds from the wax\_available\_for\_rentals bucket and stake them to the fallback\_cpu\_receiver, in the epoch that is next in the rotation. Can be called by anyone. ### sync > Allows any admin wallet to sync the contract state with the current time. Requires auth of the admin wallet calling the action. | Parameter | Type | Description | | --------- | ---- | ------------------------------------------------------ | | caller | name | The WAX address of the admin wallet calling the action | ### unstakecpu > If the current time is >= the time\_to\_unstake of the epoch that started prior to the current epoch, this action can be called to unstake the CPU from that epoch, ensuring that the WAX is returned to the dapp contract in time for the redemption window. Can be called by anyone. | Parameter | Type | Description | | --------- | --------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | epoch\_id | uint64\_t | By default (if you submit 0 as the epoch\_id), the contract will attempt to unstake CPU from the most recently ended epoch. You can override this behavior by specifying an epoch\_id to unstake from | | limit | int | By default (if you submit 0 as the limit), the contract will process up to 500 rows when unstaking CPU. You can override this by specifying a limit | ### updatetop21 > If it has been >= 24 hours since the last time the top21 table was updated, anyone can call this action to sync the top21 table with the current state of the chain. # Tables This page lists all tables on the dapp.fusion contract, including their descriptions and a breakdown of each datapoint stored in the table. ## Quick Links [#account](#account "mention") [#delegated\_bandwidth](#delegated_bandwidth "mention") [#epochs](#epochs "mention") [#global](#global "mention") [#incentives](#incentives "mention") [#lpfarms](#lpfarms "mention") [#pools\_struct](#pools_struct "mention") [#producer\_info](#producer_info "mention") [#redeem\_requests](#redeem_requests "mention") [#refund\_request](#refund_request "mention") [#renters\_table](#renters_table "mention") [#rewards](#rewards "mention") [#stakers](#stakers "mention") [#state2-pol\_contract-namespace](#state2-pol_contract-namespace "mention") [#top21](#top21 "mention") ### account > The account table is a table that is used on all standard token contracts. It is referenced in this contract in order to look up WAX balances for various contracts, allowing this contract to aggregate data related to the protocol's TVL ### delegated\_bandwidth > This table is actually on the eosio system contract, and keeps track of who has CPU/NET staked. It is referred to in our contracts for CPU rental management. ### epochs > The epochs table keeps track of each epoch that has ever taken place. | Column | Type | Description | | ------------------------------------ | --------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | start\_time | uint64\_t | The epoch timestamp when the epoch started. This is used as an epoch\_id to reference the epoch in other parts of the contract | | time\_to\_unstake | uint64\_t | The epoch timestamp when the contract is able to unstake all WAX associated with an epoch, in order to ensure that funds are returned to the main contract in time for the redemption period | | cpu\_wallet | name | The CPU contract that holds the funds for this particular epoch | | wax\_bucket | asset | The amount of WAX that has been transferred to the CPU contract related to this epoch | | wax\_to\_refund | asset | The amount of WAX that has been requested by sWAX holders for redemptions from this epoch's wax\_bucket | | redemption\_period\_start\_time | uint64\_t | The epoch timestamp when redemptions begin for this epoch (this is also the epoch's end time) | | redemption\_period\_end\_time | uint64\_t | redemption\_period\_start\_time + redemption\_period\_length\_seconds from the config table. After this timestamp, unclaimed redemption funds are cycled back into the main pool | | total\_cpu\_funds\_returned | asset | The amount of WAX that has been returned to the dapp contract, from the CPU contract assigned to this epoch | | total\_added\_to\_redemption\_bucket | asset | The amount of WAX that has been added to this epoch's redemption pool, so sWAX holders who requested redemptions can claim their WAX | ### global > The global singleton keeps a record of the global state and configuration of the contract | Column | Type | Description | | ----------------------------------- | ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | swax\_currently\_earning | asset | The amount of sWAX that is issued, but has not been liquified | | swax\_currently\_backing\_lswax | asset | The amount of sWAX that is currently being used as the backing of lsWAX | | liquified\_swax | asset | The amount of sWAX that has been liquified, which is also the total supply of lsWAX | | revenue\_awaiting\_distribution | asset | The amount of rewards that have been earned by the protocol, but have not yet been distributed | | total\_revenue\_distributed | asset | The total amount of rewards generated/distributed by the protocol in its lifetime | | wax\_for\_redemption | asset | The amount of WAX that is currently allocated to redemption requests. If they go unclaimed for 48 hours, they will be moved into wax\_available\_for\_rentals | | last\_epoch\_start\_time | uint64\_t | The start\_time of the most recently started epoch | | wax\_available\_for\_rentals | asset | The amount of WAX that can currently be used for renting CPU, and instant redemptions | | cost\_to\_rent\_1\_wax | asset | The WAX price that CPU renters will pay for 1 full day of 1 WAX staked to their wallet | | current\_cpu\_contract | name | The CPU contract that is associated with the most recently started epoch | | next\_stakeall\_time | uint64\_t | The next timestamp that the contract can send wax\_available\_for\_rentals to one of the CPU contracts and stake it to maximize rewards | | last\_incentive\_distribution | uint64\_t | The epoch timestamp of the last time that new LP farms were created on Alcor | | incentives\_bucket | asset | The amount of lsWAX currently available for farming rewards | | total\_value\_locked | asset | The total amount of WAX locked across WaxFusion's contracts (not including liquidity on Alcor) | | total\_shares\_allocated | uint64\_t | The total amount of combined shares allocated to LP farms on Alcor | | last\_compound\_time | uint64\_t | The timestamp of the last time the compound action was called | | minimum\_stake\_amount | asset | The minimum amount of WAX that a user has to deposit in order to mint sWAX/lsWAX | | minimum\_unliquify\_amount | asset | The minimum amount of lsWAX that must be sent to the contract in order to unliquify (convert to sWAX) | | initial\_epoch\_start\_time | uint64\_t | The epoch timestamp of the first epoch that was created at the launch of WaxFusion | | cpu\_rental\_epoch\_length\_seconds | uint64\_t | The length of an epoch, in seconds | | seconds\_between\_epochs | uint64\_t | Amount of seconds that must elapse in the current epoch before a new epoch is created | | user\_share\_1e6 | uint64\_t | The percentage of platform revenue that is allocated to sWAX/lsWAX holders, scaled by 1e6 | | pol\_share\_1e6 | uint64\_t | The percentage of platform revenue that is allocated to protocol owned liquidity, scaled by 1e6 | | ecosystem\_share\_1e6 | uint64\_t | The percentage of platform revenue that is allocated to LP incentives, scaled by 1e6 | | admin\_wallets | vector\ | A list of approved wallets that can call actions that don't pose any risk to user funds, but shouldn't be accessible by everyone (changing the price of CPU rentals, for example) | | cpu\_contracts | vector\ | A list of proxy contracts that are used for staking WAX (each epoch is tied to a CPU contract) | | redemption\_period\_length\_seconds | uint64\_t | The amount of seconds that a redemption period lasts before the unclaimed WAX is reallocated for CPU rentals, instant redemptions etc | | seconds\_between\_stakeall | uint64\_t | The amount of seconds that must pass before unrented funds are automatically staked for CPU, in order to maximize rewards generated by the protocol | | fallback\_cpu\_receiver | name | If funds are not rented by the stakeall action is ready to be called, those funds will stake CPU for this wallet | | protocol\_fee\_1e6 | uint64\_t | The 1e6 scaled percentage fee charged by the protocol for instant redemptions | ### incentives > The incentives table is stored on the swap.alcor contract, and is referenced in our contract in order to manage the creation of new LP incentives ### lpfarms > The lpfarms table stores a list of which token pairs on Alcor will receive farming rewards from our ecosystem fund | Column | Type | Description | | ------------------------- | --------- | --------------------------------------------------------------------------- | | poolId | uint64\_t | The pool ID of the trading pair on Alcor that we want to incentivize | | symbol\_to\_incentivize | symbol | The token symbol of the token paired against lsWAX | | contract\_to\_incentivize | name | The token contract of the token paired against lsWAX | | percent\_share\_1e6 | uint64\_t | The portion of the ecosystem\_share that goes to this pair's incentive pool | ### pools\_struct > The pools struct is located on the swap.alcor contract, and is referenced in our contract in order to manage the creation of new LP incentives ### producer\_info > The producer info table is stored on the eosio system contract, and stores info about block producers. This table is necessary in order for our contracts to automatically vote for the top 21 block producers each day, and avoid any bias when selecting producers to vote for. ### redeem\_requests > This table stores all redemption requests made by sWAX holders. It is scoped by the wallet who made the request(s). | Column | Type | Description | | ---------------------- | --------- | --------------------------------------------------------------------------------- | | epoch\_id | uint64\_t | The start\_time of the epoch that the user requested a redemption from | | wax\_amount\_requested | asset | The amount of WAX the user has requested from this particular epoch's wax\_bucket | ### refund\_request > This is another table stored on the eosio system contract. It is referenced in WaxFusion's contracts in order to keep track of our pending refunds from unstaking WAX via our CPU contracts ### renters\_table > The renters table stores information about which users are renting CPU from the short term rental system. It is scoped by the epoch ID that they are renting from. Contract pays its own RAM on these rows instead of charging users. | Column | Type | Description | | ----------------- | --------- | ------------------------------------------------------------------------------------- | | ID | uint64\_t | A unique ID to identify this table row. It uses available\_primary\_key | | renter | name | The WAX address of the account who paid for the rental | | rent\_to\_account | name | The WAX address of the CPU recipient | | amount\_staked | asset | The total amount of WAX staked from the renter to the rent\_to\_account in this epoch | ### rewards > The rewards singleton stores the staking farm data for rewarding sWAX holders | Column | Type | Description | | -------------------- | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | periodStart | uint64\_t | The time when the farm was first initialized | | periodFinish | uint64\_t | The end time of the current reward period | | rewardRate | uint128\_t | The amount of WAX paid out per second, scaled by 1e8 | | rewardsDuration | uint64\_t | The amount of seconds that the current reward period lasts for | | lastUpdateTime | uint64\_t | The last time that the farm was updated | | rewardPerTokenStored | uint128\_t | The historical reward paid out per token, at the last time the farm was updated. Works similar to "reward debt" when calculating what a user is owed | | rewardPool | asset | The total amount of WAX that has been deposited into the farm, all time | | totalSupply | uint128\_t | The amount of sWAX currently staked in the farm, including the sWAX that backs lsWAX | | totalRewardsPaidOut | asset | Total amount of rewards that have been calculated when users interacted with the contract. Does not differentiate between whether or not the user has actually claimed them yet | ### stakers > The stakers table keeps a record of each user who interacts with the contract, including information about their sWAX balance, rewards balance etc | Column | Type | Description | | -------------- | --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | wallet | name | The WAX address of the user who is staking | | swax\_balance | asset | The amount of sWAX that a user is currently staking (does not include liquified sWAX) | | claimable\_wax | asset | The amount of WAX rewards that a user is currently eligible to claim (note that this may not reflect real-time data, and is only updated when a user interacts with the contract) | | last\_update | uint64\_t | The timestamp of the last time a user interacted with the contract. This is used in the sync\_user function to process past snapshots and update the user's claimable\_wax balance | ### state2 (pol\_contract namespace) The pol\_contract::state2 singleton is located on the pol.fusion smart contract, and is referenced on this contract in order to aggregate TVL data for the protocol in one place. ### top21 > The top21 singleton keeps a list of which block producers are currently in the top 21 | Column | Type | Description | | ---------------- | ------------- | ----------------------------------------------------- | | block\_producers | vector\ | The wax addresses of the top 21 block producers | | last\_update | uint64\_t | The timestamp of the last time this table was updated | # Notification Memos This page lists all notification memos on the dapp.fusion contract, their use-cases and intended behavior. {% hint style="info" %} Note: Tokens other than WAX and lsWAX will just be accepted by the contract, and not execute any logic or throw any errors. WAX and lsWAX transfers must include a proper memo, otherwise the contract will throw an error and revert the transaction. {% endhint %} ### instant redeem and rebalance memos > These memos are for internal use only. They are used for when the pol.fusion contract sends funds to the dapp.fusion contract, in order to convert lsWAX into WAX. Anyone trying to send tokens to the contract with either of these memos will have their transaction reverted. ### wax\_lswax\_liquidity > This memo is also for internal use only. When the pol.fusion contract needs to buy lsWAX in order to provide liquidity on Alcor, it will send WAX to the dapp.fusion contract with this memo. ### stake > The stake memo is used for WAX deposits from users. After using the `stake` action on the contract, users can send WAX with this memo. When the WAX is received by the contract, sWAX will be issued at a 1:1 ratio and added to the user's staked sWAX balance. ### unliquify > The unliquify memo is used for converting lsWAX into sWAX. Users must first call the `stake` action on the contract to make sure they have a balance row opened for sWAX. Once they send lsWAX with this memo, the lsWAX will be burned, and converted into sWAX which will be added to the user's balance. ### waxfusion\_revenue > This memo is used for depositing any WAX that should be given out as rewards to users. Anyone can send WAX with this memo, although it is typically used by the protocol. Received WAX will be added to the pending rewards bucket, and will be distributed to users during the next payout (once per 24 hours). ### lp\_incentives > Both WAX and lsWAX can be sent to the contract with memo. If lsWAX is sent, it will be added into the incentives bucket, where it will later be used for rewarding liquidity providers of certain lsWAX pairs on Alcor (once per week, new farms are created). If WAX is sent with this memo, it will be converted into lsWAX before adding incentives into the bucket. ### cpu rental return > This memo is for internal use only. When our CPU contracts unstake funds from the eosio system contract, and then claim those funds 3 days later, they will return the WAX to the dapp.fusion contract. When returned, the WAX will be used to fulfill any pending redemption requests from that epoch. If any WAX is leftover, it will be added into the rental pool where it can be rented and reused for generating rewards. ### rent\_cpu > This memo is used when users want to pay for a CPU rental. Several arguments must be included in this memo, as detailed in the table below. Each argument must be separated by `|pipes|` {% hint style="info" %} Structure: `|rent_cpu|receiver|wax_amount|epoch_id|`\ \ Example memo: `|rent_cpu|abc.wam|100|1710460800|` {% endhint %} | Parameter | Description | | ----------- | --------------------------------------------------------------------------------------------------------------- | | receiver | The WAX address of the wallet you want to give CPU to | | wax\_amount | The amount of WAX to rent, in whole numbers. e.g. `10` is the same as `10.00000000 WAX` | | epoch\_id | The epoch timestamp of the epoch to rent from. Epoch details can be found in the `epochs` table on the contract | ### unliquify\_exact > This memo is used for people who want to specify exactly how much sWAX they expect to receive when they unliquify. Please note that there is never any slippage or price impact when unliquifying your lsWAX. However, we realize that some people will build arbitrage bots etc, and they may want some way of guaranteeing that the output of a transaction is >= a specific amount. This memo allows them to do that, as a safety precaution so they can revert the transaction if they made a bad calculation. {% hint style="info" %} Structure: `|unliquify_exact|minimum_output|`\ \ Example memo: `|unliquify_exact|1000000000|` {% endhint %} | Parameter | Description | | --------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | | minimum\_output | The minimum amount of sWAX the user expects to receive, including 8 decimal places. If they expect to receive 10 sWAX, they should put `1000000000` | # Minting/Retiring sWAX And lsWAX The table below outlines a list of all actions/transactions that result in sWAX and/or lsWAX being minted or retired. | Action | Changes sWAX Supply | Changes lsWAX Supply | Description | | -------------------------- | ------------------- | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | claimaslswax | Yes | Yes | Allows a user to claim their claimable WAX balance, and convert it into sWAX. The minted sWAX is then liquified, resulting in new lsWAX being created. | | claimswax | Yes | No | Allows a user to claim their claimable WAX balance, and use it to buy/stake more sWAX, which results in new sWAX being minted. | | compound | Yes | No | The compound action claims any WAX rewards for self\_staker, which stakes all swax\_currently\_backing\_lswax. These WAX rewards are used to mint new sWAX, which increases the swax\_currently\_backing\_lswax. | | extend\_reward function | Yes\* | Yes\* | Any time the extend\_reward function is invoked, the reward farm will be extended if the current time > periodFinish. The portion of funds that goes to ecosystem incentives will mint new sWAX, and then liquify it, resulting in new lsWAX being minted as well. | | instaredeem | Yes | No | When a user instant redeems their sWAX balance, their previous sWAX balance will be retired. | | liquify | No | Yes | When a user liquifies their sWAX balance, new lsWAX is minted at the current ratio of sWAX/lsWAX. The user's sWAX balance is then moved from swax\_currently\_earning to swax\_currently\_backing\_lswax. | | liquifyexact | No | Yes | Same outcome as liquify. The only difference is that the user can specify a minimum output amount. | | redeem | Yes | No | When a user redeems their sWAX, they receive WAX, and their sWAX balance is retired. | | instant redeem memo | Yes | Yes | Used only internally by the POL contract. When POL instant redeems lsWAX, the lsWAX amount is retired, along with the sWAX that was backing it. | | rebalance memo | Yes | Yes | Exact same logic as instant redeem memo, the only difference being that the WAX is sent back to POL with a different memo. | | wax\_lswax\_liquidity memo | Yes | Yes | Used internally by POL. When WAX is sent to the dapp contract with this memo, the WAX is used to buy sWAX (minting sWAX), and then liquify it (minting lsWAX). The minted lsWAX is returned to POL. | | stake memo | Yes | No | When a user sends WAX with this memo, they receive sWAX at a 1:1 ratio, resulting in new sWAX being minted. | | unliquify memo | No | Yes | When a user converts their lsWAX back into sWAX, the lsWAX is retired. The underlying sWAX already exists, so no new sWAX is minted. | | lp\_incentives memo | Yes\* | Yes\* | \*Only if the received token was WAX. If WAX was received, new sWAX will be minted 1:1 with the WAX quantity. The sWAX will be liquified, meaning new lsWAX will be minted. The minted lsWAX goes into the incentives bucket for creating farms on Alcor. | | unliquify\_exact memo | No | Yes | Same as unliquify memo. The received lsWAX is retired, but the underlying sWAX already exists, so no new sWAX is minted. | # cpu.fusion Part of WaxFusion's mechanics for generating revenue is based on staking WAX for CPU, and renting CPU to users for a low cost. The actual rental logic is in the main dApp contract, but due to the way WAX's system contracts work and the complications with staking/unstaking WAX to different wallets, rented/staked WAX is sent off to 3 different proxy contracts to complete the staking process. The contract addresses for these 3 contracts are as follows: cpu1.fusion, cpu2.fusion and cpu3.fusion All 3 contracts use the same exact code, which can be found on Github at the following link: {% embed url="" %} Below is a description of each of the actions on the smart contract, their parameters, and how they are designed to behave. To get a breakdown of the actions and tables on this contract, use the quick links below. ## Quick Links {% content-ref url="/pages/SjFQDXH0iM9QvjW5BJiS" %} [Actions](/smart-contracts/cpu.fusion/actions) {% endcontent-ref %} {% content-ref url="/pages/MXmT08dlKlwfYRMd9j2M" %} [Tables](/smart-contracts/cpu.fusion/tables) {% endcontent-ref %} # Actions This page lists all actions on the cpu.fusion contract, including their descriptions and a list of the parameters for each action. ## Quick Links [#claimgbmvote](#claimgbmvote "mention") [#claimrefund](#claimrefund "mention") [#initstate](#initstate "mention") [#unstakebatch](#unstakebatch "mention") ### claimgbmvote > Claims voting rewards from the system contract if there are any available. Voting rewards are automatically sent back to the main contract and added to the revenue\_awaiting\_distribution bucket. Requires auth of the dapp.fusion contract (anyone can make this happen by calling claimgbmvote on the dapp.fusion contract) ### claimrefund > Claims refunds from the system contract if any are available. Requires auth of the dapp.fusion contract (anyone can make this happen by calling claimrefunds on the dapp.fusion contract) ### initstate > Initializes the state singleton on this contract, if it doesn't exist yet. Requires auth of this contract. ### unstakebatch > Unstakes WAX from the system contract, in order to transfer it back to the dapp.fusion contract and make it available for redemptions. Requires auth of the dapp.fusion contract. Anyone can initiate this process by calling unstakecpu on the dapp.fusion contract. | Parameter | Type | Description | | --------- | ---- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | | limit | int | The maximum number of rows to process on the system contract. i.e. if this contract is staking WAX for 1000 different accounts, 100 rows must be processed | # Tables This page lists all tables on the cpu.fusion contract, including their descriptions and a breakdown of each datapoint stored in the table. ## Quick Links [#delegated\_bandwidth](#delegated_bandwidth "mention") [#state](#state "mention") [#top21](#top21 "mention") ### delegated\_bandwidth > The delegated bandwidth table is stored on the eosio system contract, and is referenced in our CPU contracts to manage CPU rentals. ### state > The state singleton stores information about the current global state of this contract. | Column | Type | Description | | ---------------- | --------- | --------------------------------------------------------------------------------- | | last\_vote\_time | uint64\_t | The epoch timestamp of the last time that this contract voted for block producers | ### top21 > The top21 singleton is stored on the dapp.fusion contract, and is referenced on this contract so it can be accessed when voting for block producers. | Column | Type | Description | | ---------------- | ------------- | ----------------------------------------------------------------------------------------------------------- | | block\_producers | vector\ | A list of which block producers are currently in the top 21 | | last\_update | uint64\_t | The epoch timestamp of the last time the top21 block producers were synced with the state of the blockchain | # pol.fusion The concept of Protocol Owned Liquidity has been mentioned throughout these docs. This relates to funds owned by the protocol itself, which can never be withdrawn from the smart contract. The purposes of these funds are as follows. * Ensure there is enough LSWAX/WAX liquidity on the open market for users to trade their tokens * Generate rewards for WaxFusion users via long term CPU rentals and staking * Generate rewards to compound protocol owned liquidity and grow the platform's TVL Protocol Owned Liquidity is stored in the pol.fusion smart contract, and the source code can be found at the following Github URL. {% embed url="" %} To get a breakdown of the actions and tables on this contract, use the quick links below. ## Quick Links {% content-ref url="/pages/83LqpWJ4NR5Wi6zTs9wv" %} [Actions](/smart-contracts/pol.fusion/actions) {% endcontent-ref %} {% content-ref url="/pages/anDubIW7acAiRCtVUEOm" %} [Tables](/smart-contracts/pol.fusion/tables) {% endcontent-ref %} # Actions This page lists all actions on the pol.fusion contract, including their descriptions and a list of the parameters for each action. ## Quick Links [#claimgbmvote](#claimgbmvote "mention") [#claimrefund](#claimrefund "mention") [#clearexpired](#clearexpired "mention") [#deleterental](#deleterental "mention") [#initconfig](#initconfig "mention") [#initstate3](#initstate3 "mention") [#rebalance](#rebalance "mention") [#rentcpu](#rentcpu "mention") [#setallocs](#setallocs "mention") [#setrentprice](#setrentprice "mention") ### claimgbmvote > If this contract has any voting rewards to claim from the eosio system contract, this action can be called by anyone to claim those rewards. Claiming will automatically send the rewards to the main dapp contract where they will be moved into the revenue\_awaiting\_distribution bucket. ### claimrefund > If this contract has any refunds to claim from the eosio system contract, this action can be called by anyone to claim the refund. Claiming will automatically move the claimed WAX back into the wax\_available\_for\_rentals pool on this contract. ### clearexpired > Unstakes WAX from any expired orders in the renters table, and removes the rows of the expired rentals. | Parameter | Type | Description | | --------- | ---- | -------------------------------------------------------------------------------------------- | | limit | int | The maximum number of expired rentals that should be processed (to avoid CPU timeout issues) | ### deleterental > If a user calls the rentcpu action on this contract, but never pays for their rental, this action will allow them to delete the unpaid rental from our contract. Requires auth of the renter. | Parameter | Type | Description | | ---------- | --------- | ---------------------------------- | | rental\_id | uint64\_t | The ID of the rental to be deleted | ### initconfig > Initializes the config singleton, if it doesn't exist yet. Requires auth of this contract. ### initstate3 > Initializes the state3 singleton. Requires auth of this contract. ### rebalance > If the lswax\_bucket in the state singleton is empty, and the wax\_bucket has > 100 wax in it, this action will convert half of the wax into lsWAX, so that the next liquidity addition will allocate close to all of the protocol's funds. Can be called by anyone. ### rentcpu > Opens a new row for a renter, which is required before the contract can accept a rental payment. If the row already exists, the action will do nothing besides sync the current contract state. Requires auth of the renter. Renter pays RAM on their row. | Parameter | Type | Description | | ------------- | ---- | ------------------------------------------------------- | | renter | name | The WAX address of the wallet who is renting CPU | | cpu\_receiver | name | The WAX address of the wallet that will receive the CPU | ### setallocs > Updates the portion of protocol revenue that goes to liquidity on Alcor. Requires auth of this contract. | | | | | ----------------------------------- | --------- | ------------------------------------------------------------------------------------- | | liquidity\_allocation\_percent\_1e6 | uint64\_t | The 1e6 scaled percentage that should go to liquidity. Can be set between 1% and 100% | ### setrentprice > Updates the cost\_to\_rent\_1\_wax in the state singleton. Requires auth of the dapp.fusion smart contract, which calls this action inline when an admin\_wallet sets the rent price on that contract. | Parameter | Type | Description | | ---------------------- | ----- | -------------------------------------------------------------- | | cost\_to\_rent\_1\_wax | asset | The WAX price that users will pay to rent 1 WAX for 1 full day | # Tables This page lists all tables on the pol.fusion contract, including their descriptions and a breakdown of each datapoint stored in the table. ## Quick Links [#config2](#config2 "mention") [#delegated\_bandwidth](#delegated_bandwidth "mention") [#pools\_struct](#pools_struct "mention") [#refund\_request](#refund_request "mention") [#renters](#renters "mention") [#state3](#state3 "mention") [#top21](#top21 "mention") ### config2 > The config singleton stores the percentage of revenue that should be allocated to Alcor liquidity, and the long term CPU rental pool. | Column | Type | Description | | ----------------------------- | --------- | ------------------------------------------------------------------------------------------ | | liquidity\_allocation\_1e6 | uint64\_t | The 1e6 scaled percentage of POL revenue that should be used to provide liquidity on Alcor | | rental\_pool\_allocation\_1e6 | uint64\_t | The 1e6 scaled percentage of POL revenue that should be moved into the CPU rental pool | | lswax\_wax\_pool\_id | uint64\_t | The pool ID of the LSWAX/WAX liquidity pool on Alcor | ### delegated\_bandwidth > The delegated bandwidth table is stored on the eosio system contract, and is referenced in our smart contracts so it can be accessed for managing CPU rentals. ### pools\_struct > The pools struct is located on Alcor's swap.alcor contract, and is referenced in our contract so we can automate the process of managing the protocol's liquidity position on Alcor. ### refund\_request > The refund request table is located on the eosio system contract, and is referenced in our contract so that we can claim refunds after we unstake WAX from wallets who rented CPU. ### renters > The renters table is used for keeping track of wallets who have active CPU rentals through WaxFusion's long term rental system. | Column | Type | Description | | ----------------- | --------- | ----------------------------------------------------------------------------------- | | ID | uint64\_t | A unique ID to identify the row. It uses available\_primary\_key | | renter | name | The WAX address that paid for the CPU rental | | rent\_to\_account | name | The WAX address that receives the CPU from the renter | | amount\_staked | asset | The amount of WAX that is currently staked to the rent\_to\_account for this rental | | expires | uint64\_t | The epoch timestamp that the rental will be considered expired | ### state3 > The state3 singleton keeps track of the current global state of this contract | Column | Type | Description | | ------------------------------- | --------- | --------------------------------------------------------------------------------------------------- | | wax\_available\_for\_rentals | asset | The amount of WAX that is currently available for people to rent CPU | | next\_day\_end\_time | uint64\_t | The epoch timestamp that the current "full day" ends (used for timing CPU rentals) | | cost\_to\_rent\_1\_wax | asset | The WAX price that users will pay to rent 1 WAX for 1 full day | | last\_vote\_time | uint64\_t | The epoch timestamp of the last time this contract has refreshed its vote for block producers | | wax\_bucket | asset | The amount of WAX currently waiting to be allocated to protocol owned liquidity on Alcor | | lswax\_bucket | asset | The amount of lsWAX currently waiting to be allocated to protocol owned liquidity on Alcor | | last\_liquidity\_addition\_time | uint64\_t | The epoch timestamp of the last time funds were added to the protocol's liquidity position on Alcor | | wax\_allocated\_to\_rentals | asset | The amount of WAX currently being staked to users via long term CPU rental | | pending\_refunds | asset | The amount of WAX that is in the refunding process on the system contract | | last\_rebalance\_time | uint64\_t | The timestamp of the last time the rebalance action was successfully called on this contract | ### top21 > The top21 singleton keeps track of which block producers are in the top 21 on the system contract | Column | Type | Description | | ---------------- | ------------- | ------------------------------------------------------------- | | block\_producers | vector\ | A list of the top 21 block producers as of the last update | | last\_update | uint64\_t | The epoch timestamp of the last time this table was refreshed | # token.fusion The token contract for SWAX and LSWAX uses the standard eosio.token contract, with a few slight modifications. The contract address is token.fusion, and the code can be found at the following Github URL. {% embed url="" %} # Redemptions All sWAX and lsWAX tokens in circulation are always fully backed by actual WAX tokens. If a user ever wants to convert their sWAX or lsWAX back into native WAX tokens, they have 3 options. * Instant redemption through WaxFusion, which is subject to a 0.05% protocol fee. Instant redemptions are subject to availability based on how much WAX is available in the instant redemption pool. * Standard redemption which has 0 fee, and can take anywhere from 1-21 days depending on how far into an epoch we are, and how much WAX is available in a particular epoch (there are 3 active epochs at all times, and WAX in the protocol is distributed between the 3 epochs. Redemptions will always come from the first epoch if possible, but if the redemption amount is greater than the funds available in the first epoch, then the remainder of the requested amount will be taken from the 2nd epoch, and the third if necessary) * Instantly selling lsWAX on the open market, which is subject to market conditions. While there is no protocol fee charged by WaxFusion for this option, there may be a trading fee on whichever DEX you sell your lsWAX on. # Revenue The main goal of WaxFusion is to be as capital efficient as possible. In this section you will find a full breakdown of revenue sources, and distribution details for all rewards generated by the protocol. # Distribution Rewards are distributed every second, so users can claim as often as they like. Every 24 hours, the reward pool is topped up automatically and extended for another 24 hours. All fees/rewards collected by the protocol are distributed as follows.
RecipientAllocationDescription
sWAX / lsWAX Holders85%Used for autocompounding lsWAX token, and giving WAX rewards to sWAX holders, in proportion to the lsWAX:sWAX ratio
Liquidity Incentives8%Farming rewards given to liquidity providers for specific tokens that benefit the overall WAX ecosystem
Protocol Owned Liquidity7%Used for growing protocol owned liquidity, in order to increase reward generation over time for our users, as well as deepening liquidity for lsWAX/WAX on decentralized exchanges
## Ecosystem Fund In the table above, the Liquidity Incentives row mentions tokens that benefit the overall WAX ecosystem. As WaxFusion aims to positively contribute to the WAX community and its token ecosystem, we will be using 8% of revenue to add liquidity incentives for the following token pairs (note that these pairs may be adjusted over time, as we see fit).
PairShareDescriptionToken Info
WAXDAO/lsWAX5%WAXDAO is a utility token for waxdao.io, created by the developers behind WaxFusionhttps://waxdao.io/tokens/WAXDAO@token.waxdao
HONEY/lsWAX2.5%HONEY is the native token of nfthive.io, one of the largest NFT marketplaces on WAXhttps://waxdao.io/tokens/HONEY@nfthivehoney
NEFTY/lsWAX2.5%NEFTY is the token for neftyblocks.com, another popular NFT marketplace on WAXhttps://waxdao.io/tokens/NEFTY@token.nefty
WOMBAT/lsWAX2.5%WOMBAT is the token for wombat.app, created by the same people who have now taken over wax.atomichub.iohttps://waxdao.io/tokens/WOMBAT@wombattokens
LSW/lsWAX5%LSW is another liquid staking token on WAX, developed by Alcor, a popular decentralized exchangehttps://waxdao.io/tokens/LSW@lsw.alcor
TACO/lsWAX2.5%TACO is the main token of a decentralized exchange on WAX, called TacoSwaphttps://waxdao.io/tokens/TACO@t.taco
lsWAX/WAX45%LSWAX paired against the native WAX tokenhttps://waxdao.io/tokens/WAX@eosio.token
WAXUSDC/lsWAX15%WAXUSDC is a bridged version of the USDC stablecoinhttps://waxdao.io/tokens/WAXUSDC@eth.token
WAXWETH/lsWAX5%WAXWETH is a bridged/wrapped version of ETHhttps://waxdao.io/tokens/WAXWETH@eth.token
CHEESE/lsWAX5%CHEESE is the first token ever created on WAX, and a partner project that built on top of WaxFusionhttps://waxdao.io/tokens/CHEESE@cheeseburger
WUF/lsWAX5%WUF is a multichain memecoin launched by the WAX Teamhttps://waxdao.io/tokens/WUF@wuffi
TLM/lsWAX5%TLM is the native token of the Alien Worlds gamehttps://waxdao.io/tokens/TLM@alien.worlds
Total100% (of 8%)
# Revenue Sources WaxFusion currently generates rewards for the protocol (and users) via the following mechanisms. * Staking WAX deposited by users * Renting CPU generated by user-staked WAX * Staking WAX from protocol owned liquidity * Renting CPU from protocol owned liquidity * 0.05% instant redemption fee for users who don't want to wait 1-21 days to redeem (subject to availability) * Fees earned from the protocol's lsWAX/WAX liquidity * LP farm rewards generated by the protocol's lsWAX/WAX liquidity Due to all of these reward sources, the returns from staking with WaxFusion are expected to be greater than what users would earn by staking the WAX on their own. # Epochs A main source of rewards generated by the protocol is our CPU rental system. This is based on a rotating cycle of 3 epochs, which are 14 days long each. Each 14 day epoch overlaps the previous epoch by 7 days. Meaning that any time we enter a new epoch, there are 3 epochs that are considered "active" in the rotation. An example can be found in the table below. | Epoch | Start Date | End Date | | ----- | ---------- | ---------- | | 1 | 01/01/2024 | 01/14/2024 | | 2 | 01/08/2024 | 01/21/2024 | | 3 | 01/15/2024 | 01/28/2024 | As you can see, if the current date was 01/10/2024, we would be a couple days into epoch 2. However, epoch 1 would still not come to an end for another 4 days. Also epoch 3, while not actually started yet, is considered active in the rotation because it can be used for renting CPU. This is the reason that on our "Short Term Rental" page on WaxFusion, you are presented with either 2 or 3 options for rental when you try to rent CPU. You can either rent from epoch 1 (in this example) assuming there is more than 4 days left in epoch 1, or you can rent from epoch 2 or 3. The reason for these pre-determined time frames as opposed to being able to choose how long you can rent for, is simple... funds need to always come back into the main contract in a predictable timeframe to allow sWAX holders to redeem their underlying WAX. This is why redeeming takes anywhere from 1-21 days if you use the free redemption option. When you request a redemption, you are essentially requesting funds that are staked in one or more of the 3 epochs, and need to wait for them to get cycled back into the main dApp contract. # CPU Rental WaxFusion offers CPU rentals at the lowest rates on the market. The reason we are able to do this is due to the fact that we would be staking WAX regardless of renting or not, since it's the main source of generating rewards for the protocol. Any additional sources of rewards are just an added benefit that boost APRs for our users. When renting CPU from WaxFusion, you have 3 different options. * Short Term Rental * Long Term Rental * Powerup ## Short Term Rental When using the Short Term Rental option, you are renting CPU from user-deposited funds. Rentals are for pre-determined timeframes, and the duration of these timeframes is dependent on how far into an epoch the protocol is. More information about epochs, how long they last, and why they are structured the way they are can be found on the epochs page. {% content-ref url="/pages/Dh1p1PzjyPbP87Cba7bO" %} [Epochs](/epochs) {% endcontent-ref %} ## Long Term Rental The Long Term Rental option rents CPU directly from Protocol Owned Liquidity. Since the WAX staked by POL does not need to be available for redemptions, it can be rented for as long as needed. Due to the fact that the goal with POL funds is to be as efficient as possible, rentals from this pool must be at least 30 days long. The great part about Long Term Rentals is that they are a lot more flexible than the other options - renters can view/manage their existing rentals, increase the rented WAX amount, extend the rental period etc. ## Powerup Powerup is actually just the native Powerup option that has become available on WAX Blockchain since early 2024. We've built a custom UI into WaxFusion so you can conveniently powerup your account without any guesswork involved. Powerups last 24 hours and then expire, so they are great if you just need a bit of CPU when you're in a pinch and have to submit a few transactions. # Flywheel (POL) One of the most important and unique features of WaxFusion is our innovative flywheel mechanism. The key factor in this is our Protocol Owned Liquidity (referred to as POL throughout this documentation). At the launch of WaxFusion, 100,000 WAX tokens will be deposited into our POL contract. These tokens can never be removed from the contract. Similar to funds deposited by users, these POL funds will be used for CPU rentals and staking/voting to generate rewards. The key difference being that POL funds can be rented for long term (theoretically forever), since these funds do not need to be available for redemption by sWAX holders. This is in contrast to funds deposited by users, which can only be rented for a maximum of 18 days since they need to be cycled back into the dapp contract in order to allow redemptions, and maintain the lsWAX:WAX peg on the open market. Revenue generated by POL is treated exactly the same as revenue generated by WAX deposited by users - 85% of it goes to users, the rest is split up between compounding POL, and contributing to the overall WAX ecosystem via LP incentives, etc. This means that when you deposit funds into WaxFusion, you don't just earn voting rewards on your own deposit. You earn from the following sources as well: * CPU rental fees from your own staked WAX * Voting rewards from WaxFusion's POL * CPU rental fees from WaxFusion's POL * Fees generated from instant redeems * Trading fees collected from protocol owned WAX/lsWAX liquidity on DEXs * Any other current/future revenue sources built into WaxFusion Even with the service fee built into the platform, rewards are projected to be higher than the standard 8% that would be earned by simply staking the WAX yourself. And since POL compounds every time new rewards are generated, growth of WaxFusion theoretically has no ceiling. Or in more accurate terms, the floor on WaxFusion's TVL should increase on a daily basis due to the fact that as our own stake increases, we will keep generating more and more WAX for sWAX/lsWAX holders over time. # BP Voting Throughout this documentation, you will see multiple references to staking WAX deposited into the protocol, in order to generate rewards. On WAX, staking rewards are only given to wallets who actively vote for block producers (referred to as BPs from this point forward) with their staked WAX. Since many users are depositing WAX into the protocol, over time WaxFusion's balances will in theory grow larger and larger. This would pose a risk of WaxFusion gaining too much voting power, and voting for BPs in a biased manner (especially since WaxFusion team also operates the WaxDAO BP). To avoid any bias in voting, and to avoid influencing the BP rankings at all, WaxFusion's smart contracts are designed to automatically vote for the top 21 BPs once per day. This can be verified by anyone through an independent audit of our smart contracts. # Bug Bounty {% hint style="info" %} Update: We are now working with a security team to have a proper audit of our smart contracts done. As of May 18, 2024 the Bug Bounty program is currently paused until further notice. It will be reactivated once the audit is complete. There have been no bounty submissions as of the time of this writing. {% endhint %} {% embed url="" %} # Brand Assets ## Licensing Info You may use our logos when referencing our products, tokens, or when linking to our official website. If you've obtained official approval by a WaxFusion team member, you may also use our logos when announcing partnerships/collaborations. You are not permitted to use our logos in your branding or marketing materials, unless you obtain express permission from a WaxFusion team member. If you are unsure whether or not it's permitted to use our logos/branding for a specific purpose, the best approach is to reach out to us on Telegram or Discord and speak to us about it.

sWAX Token Logo

lsWAX Token Logo

# Roadmap WaxFusion's mainnet launch is considered version 1.0 of the protocol. However, development is never complete, and we have more features to look forward to in the future. You can find information about our current roadmap goals on the pages in this section. # sWAX Locker Have paper hands? One of our roadmap goals is to implement a time/price-lock mechanism, which will allow users to lock their sWAX tokens in our smart contract until one of the following occurs: * The amount of time the user chose to lock for has elapsed * WAX has reached the user's target selling price This will create a way for users to make sure they don't sell their WAX tokens too early. WAX price will be fetched from the native open-source delphioracle contract on WAX. It is worth noting that in order for a price-based unlock to occur, the current WAX price must be >= the user's target price. Therefore, if a user waits until the price goes back under their target, they will not be able to unlock until one of the criteria is met again. # OIG Voting This feature is not guaranteed, and maybe not likely to be possible. But if it can be structured properly, we would like to create a way for sWAX holders to participate in OIG elections without having to liquidate their sWAX and remove them from the WaxFusion protocol. If you are curious about what the OIG is and why it's important, you can find more information on the official OIG website. {% embed url="" %} # lsWAX Payments Being that lsWAX is the native token of our protocol, it is fitting that we should accept it for payments. In the future, lsWAX will be accepted as payment for CPU rentals on WaxFusion, providing an added utility to the token. # WaxFusion API As the platform gains traction, naturally other projects will want to build on top of it. This will require access to real-time data about the protocol. For this reason, we will create a robust API that allows developers to fetch any WaxFusion related data directly from the source, enabling them to seamlessly integrate WaxFusion into their existing applications. # Slipstreams Under construction # Autocompounding WaxFusion aims to provide the most efficient methods for you to grow your WAX. While LSWAX is already an autcompounding token, we plan to add more features for autocompounding in the future. These features include the following: * Ability to autocompound WAX rewards into more sWAX * Autocompounding for lsWAX liquidity providers # ve33 Under construction # Powerup Manager One of the possible drawbacks to using a platform like WaxFusion, is that you don't receive CPU/NET like you do when you stake native WAX directly from your wallet. Of course, this is part of the reason that we offer several CPU rental options. In addition to this, we plan to also add another feature where sWAX holders can register for automatic powerups. Users will be able to choose a percentage of their daily WAX payouts to allocate to powerups, so they never need to worry about resources. The platform will automatically powerup your wallet every 24 hours using whatever portion of your reward balance that you allocated to powerups. # Worker App Certain actions on WaxFusion's smart contracts need to be called occasionally in order to keep the protocol functioning as intended. In the spirit of keeping everything fully open source, and ensuring that no single person is ever needed for the protocol to function, all of the necessary actions can be called by any WAX wallet. To simplify this process and make it easy for anyone to call these actions, we have created an open source Node JS worker app that you can run if you'd like to provide redundancy in case our worker app ever goes down for any reason. Keep in mind that this app is a work in progress - while it does call the necessary actions, it is not nearly as efficient as it can be. For example, certain transactions are submitted at timed intervals regardless of whether it is time to call these actions or not. It would be more ideal to first check the state of the protocol via API call(s), and only submit the transactions when the protocol is ready to process them. This is something that will be improved upon over time, but at the moment it is not a huge priority as the main focus is building/launching the protocol. The Node JS worker app can be found at the following Github repo {% embed url="" %} # Farm Launcher Version 1.2.0 of the dapp.fusion smart contract allows anyone to reward LSWAX to any liquidity pair on Alcor Exchange, as long as LSWAX is one of the tokens in the liquidity pair. {% hint style="info" %} Note that a front end will be added to WaxFusion soon, to simplify this process for you. This page explains how to create farms manually, in case advanced users prefer not to wait for a front end to be created. {% endhint %} What you will need to know before creating a farm: * The `pool_id`of the liquidity pair on Alcor * How long you want the reward to last for (can be 7, 30, 90 or 365 days) To create your farm, all you need to do is send LSWAX to `dapp.fusion`with the following memo: `|new_incentive|||` For example, if the `pool_id`is 3913, and you want the farm to last for 90 days, you would send this memo: `|new_incentive|3913|90|` There are a couple of important things to note before creating a farm: * There is a minimum of 100 LSWAX required for a farm * There is a fee of 1 LSWAX, which goes to WaxFusion's protocol owned liquidity. If you send 100 LSWAX, 99 will be used for the farm, and 1 will go to POL. If you send 1,000 LSWAX, 999 will be used for the farm, etc. * If you are rewarding one of the pairs from our [Ecosystem Fund](https://docs.waxfusion.io/revenue/distribution#ecosystem-fund), then your deposit will be applied to the weekly farm when it is created (you won't see it appear instantly on Alcor) For advanced users, you can find the `pool_id`for your pair on the [swap.alcor contract's "pools" table](https://waxblock.io/account/swap.alcor?code=swap.alcor\&scope=swap.alcor\&table=pools\&lower_bound=\&upper_bound=\&limit=10\&reverse=false#contract-tables). If you are unsure how to do this, please join our [Telegram](https://t.me/waxfusion) and ask for assistance. # Donate {% hint style="info" %} We will never ask you to "donate" anything to development. However, what you can do (if you want) is add some rewards for LP incentives, or for users who hold sWAX and lsWAX. You also have the option to add to protocol owned liquidity (for staking/renting WAX), or to add to protocol owned Alcor liquidity. {% endhint %} ### Adding LP Incentives As mentioned in the [Revenue Section](/revenue/distribution), lsWAX is deposited to Alcor once per week to incentivize liquidity for certain lsWAX pairs. If you would like to contribute some liquidity incentives, you can send either **WAX or lsWAX** to the `dapp.fusion` smart contract, with the following memo: ``` lp_incentives ``` ### Rewards For sWAX And lsWAX Holders sWAX and lsWAX holders are earning rewards every second. Every 24 hours, a new reward period is started, and any rewards earned during the previous 24 hours will start being distributed to sWAX and lsWAX holders (this is the source of the APR seen on the WaxFusion website). If you want to contribute to this APR by depositing rewards, you can send **WAX only** to the `dapp.fusion` smart contract, with the following memo: ``` waxfusion_revenue ``` ### Protocol Owned WAX (For Staking/Renting) Our `pol.fusion` contract contains WAX that is permanently locked in the protocol. This WAX is used for staking and renting CPU, which generates rewards for lsWAX and sWAX holders. If you would like to contribute to these treasury funds (which would increase our earning power), you can send **WAX only** to the `pol.fusion` contract with the following memo: ``` for staking pool only ``` ### Protocol Owned Alcor Liquidity The protocol also has a position on Alcor Exchange for the lsWAX/WAX pair. This position helps to make sure that users are always able to buy/sell lsWAX on the open market, without having a large price impact. Furthermore, this position generates trading fees and farming rewards, which are shared with sWAX and lsWAX holders. If you would like to contribute to this (permanent) liquidity position, you can send **WAX only** to the `pol.fusion` smart contract, with the following memo: ``` for liquidity only ``` The protocol will automatically convert some of this WAX into lsWAX, and provide full-range liquidity on Alcor.