The fee for sweeping is 0.5 XCP regardless of the amount of assets swept. Sweeping an address containing thousands of assets cost the same as an address with only one.
For each asset ownership that is swept, one new row is added to the issuances table. The fixed fee of 0.5 XCP is a security risk. A spam attack could flood the DB cheaply. Changing the fee to be proportional to the number of assets swept can limit this risk.
I suggest a fee of 0.001 XCP per asset ownership (about $0.01 at $10 XCP). The fee level should be discussed further.
A second vulnerability is long asset descriptions. These can be of any length, only limited by how much you can encode inside a Bitcoin transaction. This means several kB (if not close to a MB with segwit encoding?)
The way issuances (including sweep) works is that the description is repeated in the DB every time. Here’s an example of a 3600 byte description. The CP DB saved it a second time when the asset got locked.
If it were to be swept, the description would be saved once again. And so on for each sweep.
The issuer pays only a minimal BTC fee for a LOCK tx, and for sweep the proposed XCP fee is too small for such long descriptions.
Note: Other issuances, such as issue additional supply and transfer ownership also add another row with the description repeated. However, in these cases the issuer needs to encode the description in the new BTC tx, so the BTC fee alone protects against spam.
I suggest limiting the asset description at 500 chars.
The description was limited initially, In 2015 the cap was removed, but a very expensive multisig encoding had to be used then. Today you can use segwit encoding. Now there are also standards such as IPFS and Arweave for permanent decentralized storage (if a hash isn’t enough for you). A 500 char description is more than enough for such solutions.
If people do want to put everything onchain, there is of course nothing preventing it. I recommend using broadcast in such a case. No length limit, can be made from the same issuance address, and using the asset name as a keyword connects the broadcast to the asset. This is the better option for CP as the data is only saved once.