Idea for Dynamic Fees for Counterparty

XCP fees are needed for two reason

  • Limit the load on counterparty server
  • Protect the scarce asset name space from squatting

I suggest dynamics within the protocol to set the fees. It will ensure reasonable fees independently of the XCP dollar value.

  • Fees have two components (as is the case today; BTC miner fee and XCP fee)
  • For simple / basic transaction the BTC fee is sufficient to discourage spam / attacks
  • For heavy load transactions (like dividend, asset registration, and possibly the new multi send tx) additional XCP fees should be paid
    • Why not give each transaction a weight (or gas price if using ethereum jargon)
  • Count global gas units used
  • If global gas units exceed a threshold (set where the server load is getting dangerously high) then increase the gas price
  • If gas units consumed are below a low threshold (thus very low server load) then decrease the gas price
  • The process is automatic and happens at given intervals
  • For the asset name space, only the alphabetic needs an additional asset squatting fee component. Subassets have a monoply namespace, so no need there. Numerics do have some scarcity in good numbers, but other general fees should be sufficient to prevent squatting.

Fee Adjustment Algorithm

This is just a possible way to do it. Numbers are used for illustration, the real implementation must be discussed later

  • Dividend recipients cost 1 gas unit each
  • Multi send recipients cost 1 gas unit each
  • Registering asset costs 1000 gas units

The initial gas price is set to 0.00010000 XCP (that’s 10,000 XCP-satoshis).

  • Every 1000 blocks (~ 4 days) count the global sum of gas units used.
  • If more than 200,000, increase the gas price by 10%
  • If less than 100.000, decrease the gas price 10%
  • Else keep it as is

For alphabetic assets the fee has some more components to it. Let it adjust down by the number of assets registered and by time. A possible equation is : Fee = 0.5 + 1000 * gasPrice - 0.0001 * sqrt(NumOfAssets) - 0.05 * sqrt((blockHeight-470000)/87600). With around 50k assets today, this will reduce the fee by 0.22 XCP. The time factor reduces the fee by 0.1 XCP the first year, but less for each subsequent year.

Yes, there are plenty of magic numbers involved, which is far from ideal. But I believe it’s worth it. It does solve some critical issues:

  • The server load will never stay very high for long because fees adjust up and force less use of the protocol (if this ever becomes an issue)
  • If the XCP price suddenly increases (thus fees in dollar too) so much that usage goes down, the fees will automatically adjust down to a reasonable level
  • No hard fork is ever needed to change fees directly, only to adjust non-critical magic numbers
1 Like

What is being used for server monitoring? If the servers are in a virtualized environment(sorry for being uninformed), as in my opinion they should be Datadog would be my solution of choice, as long as there are enough devs and support. I’m not a fan of Datadog per se, but as opposed to some Open-Source solutions, Datadog allows timestamps and if your GitHub repo contains a support wiki(presumably end-user issues), infrastructure and development - a Wiki gives an option to link GitHub to Datadog where re-occurring issues could be solved by 1-st line support by simply looking up the Wiki Support link. I would propose this scenario in case staff is considered as asset, thus reimbursed for work.