Fee on Numeric Assets

Development Counterparty
1

I suggest adding a 0.01 XCP fee on every issuance (initial and subsequents issuances alike). Also, invalid issuances should be ignored and no longer be stored in the DB.

I am against the planned 0.25 XCP fee on numeric assets.

Why fee on every issuance

From my understanding, the problem lies with the issuances table. Many use cases, like data storage, should move to broadcasts. To encourage this, a fee must be applied to every issuance, not just the first one. Otherwise you can issue an asset, pay the initial fee, but then update the asset description thousands of times for free (meaning btc fee only, no more expensive than broadcast).

Why 0.01 XCP

This is low enough not to kill legitimate usage but high enough to discourage spam. For example, a 10k collection of 1/1 NFTs will cost 100 XCP. A fair price IMO if you have a serious project but probably not worth it for the Nth punk derivative.

A cost of 0,01 XCP theoretically puts a limit of ~200 million issuances before we run out of XCP. Practically speaking, we will never run out, rather the XCP price will go up until “spamming” becomes prohibitively expensive.

This said, a static fee is not a good permanent solution. If in the future a super-majority wants to adjust the fee, and ideally make it dynamic, we should be open to this.

Named assets and subassets

Named assets should still cost 0.5 XCP for the initial issuance. The 0.01 XCP fee will apply to subsequent issuances.

Subassets should have a 0.01 XCP fee for the initial issuance, as well as for subsequent issuances.

2

I am wondering where the public discussion is to approve this motion to go against the founding parameters. I appreciate you bringing this topic to the message board in an attempt to facilitate the illusion of choice.

The consequence of facilitating STAMPS misuse of the protocol has created its own problem. Why was this ignorant bloat encouraged? Part of the original declaration was to prove to ordinal users that XCP was not needed to make NFTs. We have very ironically come full circle to imposing a fee on these “free” transactions. It seems to me that some people have no intention to know or live up to what “free” means in terms of open source software. Time will show the current despot that sometimes consensus means fork.

3

Here’s a formal CIP draft. I kindly ask to add it to the github repo as CIP 29.

CIP: 29
Title: Asset Issuance Fees
Author: JP Janssen
Discussions-To: https://forums.counterparty.io/t/fee-on-numeric-assets/6601
Status: Draft
Type: Standards
Created: 2023-05-22

Abstract

Add XCP fees to all asset issuance transactions.

Motivation

Balance the cost of issuing assets with that of running nodes/infrastructure, and to encourage use of broadcasts when issuances are not strictly needed.

Rationale

The issuances and assets tables are growing rapidly, making it expensive to run nodes and infrastructure. In particular, one project has within the last weeks issued [X]% of all assets ever created – with no intent of using the token system. They could just as well have used broadcasts, which would have been less resource incentive for Counterparty nodes.

Adding an XCP fee to issuances will discourage the issuance of useless assets by making it cheaper to use broadcasts.

Another benefit of XCP fees, as opposed to BTC tx fees only, is that the XCP price is very responsive to demand. If there’s a surge in asset issuances, there will be a shortage of XCP around, increasing the cost of issuance.

This holds true even with a static XCP fee. However, it is crucial to set the fee appropriately, and to be open for adjusting the fee through a fork in the future. For example, if the DB is optimized in the future, making it cheaper to run a node, a lower fee will make sense.

I suggest a fee of 0.05 XCP for a registering a numeric assets. This implies a theoretical limit of about 40 million numeric assets ever being created. The realistic number is much lower as some XCP is presumed lost, and most XCP will likely not reach the market.

From the perspective of the current XCP price of $4.60, a 0.05 fee only adds $0.23 to the registration of an asset. This is less than the BTC fee, but this is intentional. It is enough to encourage the use of broadcasts instead. And it is enough to make it difficult to spam with 1,000,000 new registration, as this will require 50,000 XCP – which is hardly available on the market.

Specifications

  • 0.05 XCP fee for registering a new numeric asset
    – this will apply to subassets too, which are technically numeric assets.
    – note that this CIP will change the subasset fee from 0.25 to 0.05 XCP
  • 0.50 XCP fee for named assets remains unchanged
  • 0.01 XCP fee for all other updates to the issuances table
    – this includes changing asset description, locking and issuing supply, and transfer of asset ownership
  • no longer save invalid transactions to the issuances table

Copyright

This document is placed in the public domain.

1 Like
4

Thank you for putting this CIP together with your thoughts JP. I agree that something needs to be done to limit abuse on numeric assets and issuances, and push the experimentation to the broadcast system.

I also agree with the additional XCP fee on all issuances as well. However, I don’t feel that it is appropriate at this time to make a change to the subasset fee. I think we should have more discussions on how to apply the XCP anti-spam fee to various CP functions in a fair and balanced way, based off the amount of data written to the CP database. There are other attack vectors that we need to close sooner rather than later.

My fee preference would be :

  • 0.50 XCP = Named Assets
  • 0.25 XCP = Subassets
  • 0.10 XCP = Numeric assets
  • 0.01 XCP = On All issuances besides first

Additional thoughts:

  • Dynamic Fee Model - The founders intention was always to move to a dynamic fee model for asset registrations, to ensure that the supply of XCP would never run out. Perhaps now might be appropriate time to start discussions on what that dynamic fee model would look like.
  • Recycle XCP Fees to support Dev - Perhaps we should consider rather than burning XCP in all of these new CP functions, having the funds go to a CP community/general fund address to support development. IMO XCP used to register Named assets and Subasset should still be burned/destroyed, to ensure that XCP remains deflationary… but we could also start recycling some of this XCP back into the community to fund dev rather than destroying the XCP.
2 Likes
5

I’m okay with this. Should I update and add the CIP to github?

I agree that a dynamic is the best-long term solution but I believe it will take months to implement properly. So why not add the mentioned fixed fees to issuances now with the expectation that a dynamic model will be added in the future?

Dev funding is an essential topic. Let’s open a new thread for this.

3 Likes
6

Sure, if you want to update the CIP with my suggested fees, works for me… Can prolly push to get this implemented in the next release :wink:

2 Likes
7

I hereby withdraw this CIP.

A lot has changed over the past nine months. I do no longer think a fee on numeric asset is the way to go.

  1. Two OG founders just re-emerged and seem willing to help with scaling Counterparty. A fee (disincentive to register assets) may not be necessary. [1] [2] [3]

  2. High BTC fees. Full blocks are likely here to stay. The Onchain NFT Genie is out of the bottle :wink:

  3. Competing bitcoin meta protocols. Adding an XCP fee puts Counterparty at a disadvantage.

  4. Fork risk. The community is obviously divided on this. IMO a rule change like this should only be made if a super-majority agrees on it. Forcing this change == fork risk.

Anyone still in favor of a fee on numeric assets can write a new CIP that replaces this one.

1 Like