Jump to content


Sign in to follow this  
  • entries
  • comments
  • views

Haven Announces Long-Term Fee Structure for xUSD Exchanges

Sign in to follow this  



Over the last month, a number of third-parties have asked us to create a resilient, long-term fee structure for xUSD transactions on the Haven network.

We’ve agreed to do so and the reason is clear: in order for xUSD to be used regularly by millions of people, on the largest platforms in the world, we must implement a solution that ensures fees paid by users are flexible and transparent.

So, the first announcement we’re making today during Haven’s multi-week “Announcement Season” is the Haven 2.0 Fee Structure. These fees are designed to thwart economic attacks and manipulation attempts, while maintaining Haven’s stable storage use case and long-standing promise that “1 xUSD will always be redeemable for $1 worth of XHV”.

Today we are sharing details of a more refined fee structure that will be self-sustaining and fair to all users as Haven’s network grows. Most importantly, this structure will be less attractive to anyone wishing to negatively impact Haven’s network functions and economic stability.

The Haven 2.0 Fee Structure will be implemented soon on Haven’s mainnet via a hard fork to be announced at a later date. Haven’s xUSD fee structure will continue to be iterative moving forward based on the network’s growth and health.

Details of the updated fee structure are as follows:

xUSD exchange unlock times will be: 6 hours, 48 hours, 120 hours (5 days), and 240 hours (10 days).

A standard base fee, based on transaction weight, will be included for every xUSD exchange. This is identical to all transactions (such as transfers) performed on the Haven network.

A conversion fee will be charged based on the selected unlock time and the difference in spot and moving average (24 hours) price of XHV. Each conversion fee will include 0.2% of the value exchanged, multiplied by the priority number of the unlock time from the table below, plus the following:

  • 6 hour exchanges will pay 110% of the spot/MA difference plus 5% of the value exchanged as a speed fee. However, if the funds used as inputs are more than 30 days old, a reduced 2% speed fee will apply.
  • 48 hour exchanges will pay 100% of the spot/MA difference plus 2% of the value exchanged as a speed fee. However, if the funds used as inputs are more than 30 days old, a reduced 0.8% speed fee will apply.
  • 120 hour exchanges will pay 75% of the spot/MA difference. No speed fee will be charged.
  • 240 hour exchanges will pay 25% of the spot/MA delta. No speed fee will be charged.

Finally, since the purpose of the Haven Vault is stable storage, short term trading will be discouraged via a separate speculation fee:

  • 6 hour xUSD to XHV exchanges: If the Vault inputs used are less than 24 hours old, 50% of the XHV profit made on those inputs will be charged as a speculation fee, 40% if less than 28 hours old, and 10% if less than 120 hours old.
  • 48 hour xUSD to XHV exchanges: If the Vault inputs used are less than 120hrs old a 10% speculation fee will be charged.
  • 120 and 240 hour exchanges: no speculation fee will be charged.

In summary, the total fee paid for any xUSD exchange will be made up of the following: Base fee + conversion fee + speed fee (if applicable) + speculation fee (if applicable).

As always, xUSD exchange fees will be automatically calculated and previewed for users in their Vault before transaction confirmation.


By implementing this model of varying fees based on unlock priority, the cost of any exchange based manipulation effort increases to such an extent that it no longer makes financial sense for a bad actor, while still ensuring users operating as good actors in the system can retain their desired full value from xUSD exchanges by opting for longer unlock times.

Finally, after the full suite of Haven’s private xAssets are released, a mechanism to provide trading fee credits will be implemented. These fee credits will be applied to wallets which utilize offshore trading functions (xAsset -> xAsset) and will not be transferable between wallets.

For example, when a user makes a trade between xUSD and xCNY, a small (~0.1%) trading fee will apply. 50% of that fee will then be credited to that user’s wallet as fee credits to be used only for moving between xUSD and XHV (on and offshore). Fee credits will therefore allow users of offshore trading and storage to reduce or remove onshore and offshore fees for their individual wallets.

We look forward to implementing this updated fee structure in the near future to ensure anyone in the world, on platforms large and small, can use Haven’s xUSD with confidence and ease.

Note: special thanks to Haven community member DougieWatts for suggesting a fee mechanism based on the age of Vault inputs to encourage xUSD storage on the network.


View the full article

Sign in to follow this  


Recommended Comments

There are no comments to display.

Add a comment...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • HashVault Latest Blocks

  • HashVault Stats

    • Global Hashrate
      1.56 TH
    • Avg Hashrate
      620.41 MH
    • Total Miners
    • Miners Paid
    • Total Payments
    • Total Hashes
      9.23 EX
    • Blocks Found
  • Posts

    • IMPORTANT! Nvidia drivers for Windows 10 since ver. 460.79 (and newer) cause crash when PhoenixMiner starts. If you want to use these drivers, you need to upgrade to PhoenixMiner 5.4c or later version. IMPORTANT! Ethereum Classic (ETC) network switched to a modified version of ethash, called ETCHash. If you are mining ETC you must upgrade to PhoenixMiner 5.3b or later, otherwise you will get only rejected shares when mining ETC. IMPORTANT! All owners of AMD cards with 6 GB or 8 GB RAM must either keep drivers 20.4.x or lower (do not upgrade to 20.5.1 or later), or upgrade to PhoenixMiner 5.2e or later version to continue mining after DAG epoch 384 (ETH will pass it before the end of 2020). IMPORTANT! All owners of AMD cards with 4 GB RAM must upgrade to PhoenixMiner 5.2e or later version to continue mining after DAG epoch 373. Additionally, here are some important tips for longest possible usage of 4 GB AMD cards with PhoenixMiner 5.2e and later: Changes in version 5.5c (since 5.4c): Added native kernels for AMD RX6800 and RX6900 GPUs. These are faster than the generic kernels and produce a lot less stale shares Updated kernels for AMD Polaris, Vega and Navi GPUs that are slightly faster and use less power than before when mining ETH. To use these updated kernels, you need to use drivers 20.5.1 or later under Win10, or 20.10.x or later under Linux The Nvidia mining cards (P106, P104, etc.) can now use straps and hardware control options (power limit, memory overclock, max temperature, etc.) under Windows Added support for the latest AMD Windows driver 21.1.1 (still, we don't recommend using the 21.1.1 driver yet - we had some instability issues with it even when just idling on the desktop!) Added support for AMD Linux drivers 20.45-1164792 and 20.45-1188099. Use this drivers only if you have RX6800 or RX6900 GPU. WARNING: Vega and Navi GPUs won't work with these drivers! Automatically set -ttli instead of -tmax when the later is not supported by the driver. This will throttle down the GPUs when they reach the specified temperature to avoid overheating Added new -mcdag parameter to reset the memory overclock on Nvidia cards during DAG generation. This may allow you to set higher memory overclock on your Nvidia cards without risking corrupt DAG buffer, which can lead to excessive number of incorrect shares. Use -mcdag 1 (by default the value is 0, which means turned off) to use this new feature. Under Linux -mcdag 1 will execute provided by the user shell script named daggen.sh (if present in the current directory) for each Nvidia GPU, passing the GPU index as the first argument, and PCIE bus ID as second argument. The miner will then wait for about 7 seconds before starting DAG generation to allow the script enough time to reset the memory overclock. The -tt parameter is now strictly for controlling the fan behavior. E.g. -tt 60 sets auto-fan speed with target temperature 60C; -tt -70 sets fixed fan speed 70%; and -tt 0 turns off the fan control. All these can be specified per GPU. There is a new -hwm parameter that allows controlling the frequency of the hardware monitoring, which was also done by -tt in the previous versions of PhoenixMiner Other small improvements and fixes PhoenixMiner is fast (arguably the fastest) Ethash (ETH, ETC, Muiscoin, EXP, UBQ, etc.) miner that supports both AMD and Nvidia cards (including in mixed mining rigs). It runs under Windows x64 and Linux x64 and has a developer fee of 0.65% (the lowest in the industry). This means that every 90 minutes the miner will mine for us, its developers, for 35 seconds. PhoenixMiner also supports ETCHash for mining ETC, Ubqhash for mining UBQ, ProgPOW for mining BCI, and dual mining Ethash/Ubqhash with Blake2s. The speed is generally faster than Claymore's Ethereum miner in eth only mode (we have measured about 0.4-1.3% speed improvement but your results may be slightly lower or higher depending on the GPUs). To achieve highest possible speed on AMD cards it may be needed to manually adjust the GPU tune factor (a number from 8 to about 400, which can be changed interactively with the + and - keys while the miner is running). If you have used Claymore's Dual Ethereum miner, you can switch to PhoenixMiner with minimal hassle as we support most of Claymore's command-line options and confirguration files. Screenshot: 1. Quick start You can download PhoenixMiner 5.5c from here: Download: https://www.sendspace.com/folder/ugy44z 2. Features, requirements, and limitations * Supports AMD RX5700, Radeon VII, Vega, 580/570/480/470, 460/560, Fury, 390/290 and older AMD GPUs with enough VRAM * Supports Nvidia 30x0, 20x0, 16x0, 10x0 and 9x0 series as well as older cards with enough VRAM * Highly optimized OpenCL and CUDA cores for maximum ethash mining speed * Optional "green" kernels for RX580/570/560/480/470/460 to lower the power consumption by 2-3% with small, or no drop in hashrate * Lowest developer fee of 0.65% (35 seconds defvee mining per each 90 minutes) * Dual mining ethash/Blake2s with lowest devfee of 0.9% (35 seconds defvee mining per each 65 minutes) * Advanced statistics: actual difficulty of each share, effective hashrate at the pool, and optional showing of estimated income in USD * DAG file generation in the GPU for faster start-up and DAG epoch switches * Supports all ethash mining pools and stratum protocols * Supports secure pool connections (e.g. ssl://eu1.ethermine.org:5555) to prevent IP hijacking attacks * Detailed statistics, including the individual cards hashrate, shares, temperature, fan speed, clocks, voltages, etc. * Unlimited number of fail-over pools in epools.txt configuration file (or two on the command line) * Automatic GPU tuning for the AMD GPUs to achieve maximum performance with your rig * Supports devfee on alternative ethash currencies like ETC, EXP, Music, UBQ, Pirl, Ellaism, Metaverse ETP, PGC, Akroma, WhaleCoin, Victorium, Nekonium, Mix, EtherGem, Aura, HBC, Genom, EtherZero, Callisto, DubaiCoin, MOAC, Ether-1, and EtherCC. This allows you to use older cards with small VRAM or low hashate on current DAG epochs (e.g. GTX970). * Full compatibility with the industry standard Claymore's Dual Ethereum miner, including most of command-line options, configuration files, and remote monitoring and management. * Supports the new Ubqhash algorithm for the UBQ coin. Please note that you must add -coin ubq to your command line (or COIN: ubq to your epools.txt file) in order to mine UBQ * Supports the ProgPOW algorithm for the Bitcoin Interest (BCI) coin mining. Please note that you must add -coin bci to your command line (or COIN: bci to your epools.txt file) in order to mine BCI * Supports the ProgPOW algorithm for mining BCI. * More features coming soon! PhoenixMiner requires Windows x64 (Windows 7, Windows 10, etc.), or Linux x64 (tested on Ubuntu LTS and Debian stable).
    • Hey guys. Can somebody help me? I wanted to have some fun and start mining Monero.  This is my config:    {     "autosave": true,     "donate-level": 2,     "cpu": true,     "opencl": true,     "cuda": true,     "pools": [         {             "url": "pool.hashvault.pro:3333"         },         {             "url": "pool.hashvault.pro:443",             "user": "-------------",             "keepalive": true,             "tls": true         }     ] }   I generated on website. Can you help me with user? What should I put there? A wallet address? (i have Coinomi wallet). Where to get it? Don't have any serious expectations about mining but i have a PC with two RTX 3060 so maybe i will dig something in free time just to be happy, even if it will be worth 1$ 🙂 Thank you in advance.
    • А куда пул вообще пропал? Нужно было посмотреть txid своих старых выплат, а страница тупо пропала.
    • Dear Community,   Reading the "Getting Started" section in the Pool area and some threads on the Forum, I still have a little question.  Whom do you recommend mining solo?  The hash rate seems to be the same whether I do SOLO mining or not.  Thanks! Bee *** My machine is a simple workstation with a slim linux running: * ABOUT XMRig/6.7.0 gcc/9.3.0 * LIBS libuv/1.38.1 OpenSSL/1.1.1i hwloc/2.2.0 * HUGE PAGES supported * 1GB PAGES unavailable * CPU Intel(R) Xeon(R) CPU E3-1280 V2 @ 3.60GHz (1) 64-bit AES L2:1.0 MB L3:8.0 MB 4C/8T NUMA:1 * MEMORY 1.1/15.6 GB (7%) * DONATE 1% * ASSEMBLY auto:intel * POOL #1 pool.hashvault.pro:3333 algo auto * COMMANDS hashrate, pause, resume, results, connection * OPENCL disabled * CUDA disabled  
    • Update: Having applied the Script from the thread linked to above, I get another outcome. Is that as it is supposed to be?? Thanks again Bee alpinehost:/home/alp# chown root /usr/share/hugepages.sh alpinehost:/home/alp# /usr/share/./hugepages.sh enable Huge pages enabled alpinehost:/home/alp# sysctl -a | grep hugep sysctl: error reading key 'net.ipv6.conf.all.stable_secret': I/O error sysctl: error reading key 'net.ipv6.conf.default.stable_secret': I/O error sysctl: error reading key 'net.ipv6.conf.eth0.stable_secret': I/O error sysctl: error reading key 'net.ipv6.conf.lo.stable_secret': I/O error vm.nr_hugepages = 9 vm.nr_hugepages_mempolicy = 9 vm.nr_overcommit_hugepages = 0 alpinehost:/home/alp# The vm.nr_hugepages changed dramatically. What does it mean anyways?
  • Create New...