CIP - Payment Information Attached to Royalty Payments

Developers CIPs
1

I would like input for a new CIP “Process” regarding Royalties payments.

Abstract:
When markets begin distributing royalty payments the receiving party has no method to easily determine the reason for a payment. In the future when an artist has sales on multiple markets one might desire a method to understand the context of an incoming payment.

Motivation:
I can imagine come tax reporting time one might want to know the source of their income.

Specification:
I would like input from the community on the types of information one might place in the payment metadata, the following items seem important for tracking.
PolicyID
Period
Sender

{"674":
{
"policyid": "policyid-here",
"period": ["UTCDATE-START", "UTCDATE-END"],
"sender": "Market Name"
}
}

Rationale:
Attach a simple report using metadata to the payment to provide the ability for a party to properly track their income, this would already be visible in the existing wallets without any changes needed upstream.

3

Requiring additional meta data for limited tracking capability is significantly less efficient then simply using the transaction details for the same purpose.

  1. Why include magic number 674 as a key?
  2. Did you mean a policy id and asset name hash for tracking minted tokens?
  3. If so, why would any token be required to receive a royalty payment from a platform?
  4. All transactions already provide time. Period can be determined by time between repeated transactions.
  5. All transactions include a sender address. What advantage is there to an immutable byte string without localization support?

If the platform or service itself does not provide any ability for tracking payments that is out of the scope of a CIP. Regardless the user could simply provide a different receive address for each payment source to easier facilitate this independently without incurring additional fees for persisting redundant data in the ledger.

As you said users may want to know this temporarily for tax reporting purposes, accounting, etc. Ideally the platform would provide this on their behalf for their account on an as needed basis. For example exchanges do not bake additional data into every transaction and trade you perform across every blockchain to provide the annual report, transaction history, etc for your account.

1 Like
4

  1. CIP-0020 defines magic number 674 to be used for transaction message or comment metadata.

  2. I am suggesting only use the policy ID and not attempt to report on royalties for each asset sold as that would be more burden on the markets.

  3. There exists another CIP regarding royalty payments already and I am attempting to fill a gap in the existing implementation. Asking why a token would be required to receive a royalty payment sounds like you don’t understand my solution to the problem. A token would not receive a royalty payment a wallet address would. People are registering their intent to receive royalty payments using “magic number 777” and in the future these payments will start coming in from market places that the artist has no relation with. This proposal seeks to fill the gap in understanding the source of payments. If I receive royalty payments for multiple projects to the same address I need a method to distinguish why I am receiving this payment. From your reply this sounds like a solution that does not belong with the blockchain.

  4. Maybe time period does not belong in this specification but I can see that payments may not come to each seller regularly and having in the report what period you are being paid is no different than a pay stub showing you what period the pay covers. For tax reporting purposes we need to know what period the income is to be reported.

  5. Using only the sender address and not having metadata attached to the distribution, how am I to know as a user who is sending me the funds? We do not yet have naming services for our address. Do we not take tax reporting seriously, do we not consider random payments as taxable events?

The data is not redundant as we do not have any means obtain it in the first place. New markets are coming online and I guess the current plan is to expect that each person wanting royalties to find each market and sign up even if they are not selling using that market and what next, ask for their sending address and when a payment comes into their wallet just go check all 10 or so markets until they find out who sent it? Weird my bank records the name in their ledger when I am paid by direct deposit. Even publishing a sending name alone would be helpful in this case. You seem to think that an artist needs to have an account with a market to receive royalties and that is not the way this was designed. Exchanges keep track of your interactions and provide you with a report of what you did at the end of the year but this is different because you did it directly with them, in the case of secondary sales - people you have no control over sell a product and you get income from it, this could come from a new market that is not localized in your language - this presents an impossible challenge to artists to find every market where the public might sell their product?

5

I guess we are both making some assumptions.

My assumption is the context of the payment can be deduced and that context does not matter for the primary use case cited. To use your example you do not need to include ACH transactions, bank names, etc when determining total royalty income for tax purposes even if you receive many payments from many sources.

If the artist is able to receive the payment then there must have been an address or wallet registered on their behalf to earn royalties. It is the platform the artist initially registered with that should be tracking all transactions related to them on their behalf to provide this convenience feature. Call it “royalty insights” as it borders data analytics use cases as well.

Anyway my point was even if the platform they are using doesn’t do this there is nothing hindering the user from using a specific wallet or address and tracking it themselves. For example I should have a separate bank account and corporate entity in the centralized world for all my music ventures if I want to make taxes and accounting easier on myself. In blockchain I would use a dedicated wallet.

Replicating a centralized banking feature such as royalty payments on blockchain does not require replicating it verbatim nor does it require every aspect to be decentralized or all data to be on-chain. Artists used to get a check in the mail from a third party issuer on behalf of a bank that represented the distributor. Blockchain doesn’t require stamps so we likely should not make a CIP about them to support the mailing of a royalty check feature for certain application platforms.

I realize that last one is a straw man argument. I am very poorly attempting to illustrate we should focus CIP on things that improve Cardano as a whole not a minor implementation detail of a feature that is for a small niche preference.

1 Like