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