CIP-0027 | Standardization of royalties #116
Conversation
|
This is quite abstract for me, would it be possible if you could provide examples in a CIP? In addition, I don't get how distribution of royalties would be made, for this one needs smart contract right? |
huths0lo
changed the title
This isnt meant to directly create royalties; at least not initially. The expectation is that secondary markets would respect the tagging. This is something the larger ones have all stated they plan to implement. Without a standard defined, royalty payments would become fragmented, depending on which market an NFT is resold on. As far as smart contracts, I dont believe there is any function that will be released in the Alonzo update. So the tagging serves two purposes. Allows for immediate adoption of royalties'. And with the standard defined, a future update could provide a smart contract that honors the tags. With the instruction set held off chain, the instructions can be updated if that becomes necessary. I have updated the CIP to include an example of what the metadata would look like. |
Adjust Formatting
|
Shouldn't that be an update proposal for CIP-0025 instead of a new CIP? CIP-0025 describes the NFT metadata format. So why not do a "royalty" key in there? Just a few thoughts: |
KtorZ
changed the title
All valid questions. The changing of royalty percentage at a future date is a potential problem point. Another option would be to require the aggregate royalty percent to be a static on chain tag. This way the percentage cannot be changed in the future. For hashing, I've been trying to think of a way to accomplish that. The challenge is that the royalties payments are likely to change in the future. At some point, people pass away, payment wallets can get lost or stolen, etc. If we assume that someone will continue to earn royalties long after their gone, which is how it should be, we need a way to adjust things in the future. And that future will would be long after the NFT's minting policy expires. As silly as it sounds, I think having a central authoritative list of valid roylaties jsons would make good sense. It doesnt all have to be handled by one entity. You could look at it like SSL certificates. As long as a source is considered to be valid, you can have several different curated repositories. But with that said, it doesnt have to be required either. If we're just using a shortened link to point somewhere, that somewhere can always be moved. For moving an NFT between wallets, owned by the same person, there shouldnt be any problem. Since these royalties would not be a blockchain smart contract function, they would only be triggered when an nft passes through a marketplace. This of course means there are ways to circumvent them. But thats not really all that different than royalties in the music industry today. Any major player will respect the royalties, but there will always be cheaters. To the last point of should this be part of the metadata standard proposal; it could be. I just felt that this topic is worthy of its own proposal. Especially since this one tag is going to take allot of community input to solidify. And its important to have allot of eyes on it, because its something the community needs to agree upon so that future marketplaces coding would be able to identify this info. And lastly, by having kept the instruction set offnet, the royalties standard could be updated. I think its a bit too big of a topic to place it within the metadata standard proposal. |
This is an extensive rewrite of proposal CIP-0027. All previous iterations are to be considered deprecated. This proposal has been developed through extensive community outreach, and represents community compromise for scalability and simplicity. The community intends to proceed with using this standard forthwith. We respectfully ask that the CIP be considered a priority measure, given the significant impact it will have on the Cardano Community.
|
This latest update was the result of a large-scale roundtable of prominent individuals involved in the CNFT creation and marketplace space. The goal being to develop a community-accepted standard for how royalties should be handled as it relates to native assets in general on the Cardano blockchain and not exclusively to the CIP-25 NFT Metadata standard. Having a separate JSON index to describe royalties and a procedure to create an ultimate and immutable source of truth protects both consumers and marketplaces from the "evolutionary" aspect of metadata for current tokens on chain and also allows us to minimize "ledger bloat" by needing to repeat static information in the metadata of individual tokens. I, for one, am happy to accept and support this proposal. |
|
Whats the plan to enforce such payments on the blockchain? Who is going against sales without royalties payments? How do you differ between private-to-private sales and private-to-own-private wallet transactions? There should be rules in the CIP how to enforce something like this on the chain, what do you do when the originally assigned payment-address gets lost by the artist and the artist is providing this information publicly? Do you still send %pct to the lost payment-address instead of a new working one? |
At the moment, there doesnt appear to be a mechanism at the blockchain level to enforce these payments. Thats why this becomes a community driven effort to be enforced through the marketplaces. But it DOES create a framework, that a future generation smart contract could be modeled after. The questions regarding how to differ between private party and ones own wallet are what makes enforcement through a smart contract an unlikely use case. And there would be no way to prevent a private party sale and enforce a royalty. But if done through the marketplaces, it should capture a substantial amount of exchanges. The question about the wallet is one that was agreed upon through community discussion. The key desire was to keep the entire instruction set on chain. Therefore it becomes the burden of the asset creator to take this in to serious consideration, and understand the consequences of losing access to the royalties wallet. There is a high likelihood that another type of business will be born out of this, where this 3rd party will manage royalties for CNFT creators. This way there can be further breakdown of the royalties payments. |
|
We should change the address to a nft. People change wallets. You can send the nft to the new wallet, and not have to keep a wallet open for 30 years. |
That was one of the ideas proposed. And it is an excellent idea. But in the end, everyone agreed up the address as being the preferred method. Its been suggested, but currently uncomfirmed, that a smart wallet may be able to provide this function. So the payment address would feed to a smart contract, and the smart contract would manage the distribution(s) based on where this new NFT is placed. It could even be a fungible that breaks down the payments for more people. We think that the latest revision as is, represents the the best compromise for simplicity of implementation, best mitigation of bad actors gaming the system, and predictable results; with the bonus that smart contracts can be used downstream for whatever is desired after the royalties are forwarded. I also see that a business could be born out of this, that is distinctly for managing royalties for artists. They would use their clients master wallet. Then do the distributions on the back end. This obviously requires risk mitigation. But every wallet does. |
Hope that answered your question I'll close the comment. But feel free to ask follow up questions if you have them. Or you're welcome to reach out to me, and I can get a dialogue going between some or all of the parties involved with this proposal. |
|
Reopening |
Updated contributor section
Add line 23 to state clearly that the royalty token needs to be made prior to the assets under it.
|
Have you considered an array of pct / addr pairs instead of only a single pct and addr at the top level? For example: This way if a piece of art (or music) was a collaboration, or if an artist wanted to also support a charity, this scheme could handle that as well. |
This was considered and rejected by the community leaders. A Smart Contract could be the target for the royalty, so the separation of funds can be handled there. There is also minimum UTxO's to consider. |
How is this going to work for a lot of existing projects? |
It distinctly wont work for pre-existing projects. It would be a rug pull for someone to attach a royalty to tokens that have already been purchased, when the buyer wouldnt have been aware that the cnft creator would add them at a later date. Its for the same reason that only the first mint of the no name token will be honored. It wouldnt be acceptable for the cnft creator to be able to change the royalties after the fact. |
|
maybe a good idea to also include an implementation conclusion part and an ill-formatted part like we did here? |
| 3) Only the first minted set of instructions will be honored. Any future updates or rewrites will be ignored. This prevents a Cardano Asset maker from changing the royalties at a future date. | ||
| 4) Within this created asset will be the metadata for royalties distributions. It will use a tag of 777, and then have two tags to identify the percentage of future sales requested as a royalty, and the payment address to forward those royalties to. Those tags will be "rate" and "addr" respectively. | ||
| 5) The "rate" key tag can be any floating point value from 0.0 to 1.0, to represent between 0 and 100 percent. For example, a 12.5 percent royalty would be represented with "rate": "0.125". Previous version 1.0 of this proposal used pct instead of rate. Marketplaces to continue to honor legacy pct tag. | ||
| 6) The "addr" key tag can be a string value, or an array. It is to include a single payment address. By allowing for an array, the payment address can exceed the per line 64 character limitation. This payment address could be part of a smart contract, which should allow for greater flexibility of royalties distributions, controlled by the asset creator. |
There was a problem hiding this comment.
Note that in principle, an address is at most 59 bytes. The reason why addresses become a problem here is because of the choice to represent them as bech32-encoded strings. I reckon that JSON has been chosen here as it is quite human-readable but, I would argue that it doesn't have to be since the primary target of the metadata are programs, tools and services.
Hence alternatively, you could either:
-
Encode addresses as bytes. This is supported by various tools by prefixing the string with
0xand encoding the payload in hexadecimal. For instance, here{ "777": { "rate": "0.2", "addr": "0x616796190577269c59e85fae13708fcfe602211fde63cd7e339d01444c" } } -
Use the detailed schema for metadata, which can fully capture the on-chain format:
{ "777": { "map": [ { "k": { "string": "rate" }, "v": { "string": "0.2" } }, { "k": { "string": "addr" }, "V": { "bytes": "616796190577269c59e85fae13708fcfe602211fde63cd7e339d01444c" } } ] } }
Both results in the same binary data.
There was a problem hiding this comment.
Why not enhance it further and implement
0.2: 616796190577269c59e85fae13708fcfe602211fde63cd7e339d01444c,
or laternatively 616796190577269c59e85fae13708fcfe602211fde63cd7e339d01444c: 0.2
we know that there are only percentages/rates, so no need to also add a string "rate"/"pct" and "addr". Saves us 7/8 bytes.
There was a problem hiding this comment.
Why not enhance it further and implement
0.2: 616796190577269c59e85fae13708fcfe602211fde63cd7e339d01444c, or laternatively616796190577269c59e85fae13708fcfe602211fde63cd7e339d01444c: 0.2we know that there are only percentages/rates, so no need to also add a string "rate"/"pct" and "addr". Saves us 7/8 bytes.
Removing the labels makes it less human friendly and makes it more difficult to extend in the future.
There was a problem hiding this comment.
Note that in principle, an address is at most 59 bytes. The reason why addresses become a problem here is because of the choice to represent them as bech32-encoded strings. I reckon that JSON has been chosen here as it is quite human-readable but, I would argue that it doesn't have to be since the primary target of the metadata are programs, tools and services.
Hence alternatively, you could either:
* Encode addresses as _bytes_. This is supported by various tools by prefixing the string with `0x` and encoding the payload in hexadecimal. For instance, here ```json { "777": { "rate": "0.2", "addr": "0x616796190577269c59e85fae13708fcfe602211fde63cd7e339d01444c" } } ``` * Use the detailed schema for metadata, which can fully capture the on-chain format: ```json { "777": { "map": [ { "k": { "string": "rate" }, "v": { "string": "0.2" } }, { "k": { "string": "addr" }, "V": { "bytes": "616796190577269c59e85fae13708fcfe602211fde63cd7e339d01444c" } } ] } } ```Both results in the same binary data.
Where does the 64 character limit come from?
Can it be increased or removed?
If standards are being created with hacks like concatenating array elements, which makes it harder to understand for people and machines, it seems there is a strong case to increase or remove the limit.
| ## Revised proposal - August 28th, 2021 | ||
| ## Minor Revision - August 31st, 2011 | ||
| ## Minor Revision - September 27th, 2021 | ||
| ## Minor Revision - November 8th, 2021 |
There was a problem hiding this comment.
The changelog section seems redundant with git here. If there's really a strong will to keep it, then I would recommend to not use h2 (##) titles which are unnecessarily big, but instead resort to a list of bullet points or use a somewhat standardize format such as keep-a-changelog
|
Hi there, I have a question about this proposal. What are folks thoughts on using a different royalty address besides the one in the royalty token for a project? There are instances where a creator might decide to leave a project, or accidentally mints a token with the wrong address, and I believe marketplaces should be able to send royalties to a new address chosen by a meaningful majority of the community in these instances. We are hosting a Twitter space with ADA Clouds, a rugged NFT project where the community is trying to take over and redirect royalties away from the creator who left. The Twitter space is tomorrow on our main Twitter account, @jpgstoreNFT at 20:00 UTC if any of you are interested in sharing your opinions in person. Otherwise, I will have my notifications on if anyone prefers to respond here! |
It is up to the marketplaces to decide what to do, this is an informational CIP so it merely advertises "this is what we wanna do, this is how we're going about it". With that said, if you decide to go on that route, it should be a separate CIP which circles back to this one so that everyone can adopt it also and you can get wider adoption. In addition, ideally the decision would be made by the NFT holders themselves thru an on-chain vote. |
This was a community driven proposal. Many ideas were discussed. Ultimately the most important design aspect of the 777 standard is its inflexibility, to prevent a project team from making changes. The expectation is if you are in a position of making assets, you should know how to do exactly that. It is noted in the CIP that the address could be a smart contract address; thus allowing modification through that. As of lately I personally am thinking it might make more sense to not have an address at all. And like an $adahandle, you would send the 777 token to the address you want to receive the royalties. You could then move it wherever you please. The 777 token would still have to be the first one minted, and would still have the pct tag (or rate for the only person on this planet that feels like that is the correct tag). But alas, this was community driven, with community democratic vote. It was always intended to revisit it at a point in the future. It might be time to have another community discussion now that more marketplaces have come online. It really requires another majority vote before making a change to the proposal as is. |
This is extremely useful context, thanks @huths0lo! Curious how the community democratic vote was held? I definitely think not burning the token, and allowing it to be moved to new wallets would be extremely helpful for creators. I've also had some creators ask us to send royalties to multiple addresses. I think there are many ways for this proposal to be improved, so would love to be part of that effort! I will share these perspectives with the folks who attend our Twitter space tomorrow. |
I'm gonna delete this branch, since is now very stale. But feel free to email me at john@digitalsyndicate.io; or hit me up on twitter. I sent you guys a tweet. You should get this reply in your inbox though. |
Apologies about my reply to your message. I didnt realize I was replying to another person, and misunderstood the context of it. |
|
I think paying the royalties to the address holding the 777 token is brilliant. |
|
Not to mention that you can fractionalize said token like Fracada does and distribute the royalties among different team members in second stage of protocol execution. |
This idea, specifically was proposed by Fencemaker. So he would deserve all of the credit if that were to be used. But the reason we didnt do multiple tokens, and probably ultimately didnt further pursue using tokens is because of min-utxo. But I dont think we stopped to consider leaving it as a single token. Aside from this one change, I think everything else should remain unchanged with the 777 token. It needs to be the first mint. We only honor the first mint. The rate/percent is locked in. And its backwards compatible, because it either has an addr, or it doesnt. If it doesnt, we query db-sync to locate it. And its non commercialized. I'm sure there will be many services pop up like $adahandle. I was actually working on a similar concept earlier in 2021, but didnt see it through. So leaving it as a no name token, keeps it true to its intent. But regardless, I would want to have a meeting of the minds before introducing a potential change to the CIP. The plan was to meet as needed every few months to discuss potential changes. And I think it makes allot of sense at this point. Adam Dean did a survey about a month ago. At that time we had over 9000 royalty tokens. Its very clear that the standard is being widely adopted. And I've never opposed challenging views on it. What I've opposed is a challenging view, with no proposal that worked that could replace it. To date, no one has proposed anything viable. I'm going to try to set up another meeting in the not too distant future. |
You're both right and wrong at the same time. I know that you're correct, that the language "rate" is technically correct. But where this goes wrong is that we dont see rate used anywhere. Mark was totally correct when he responded last night. This was community driven, and really needed to remain using pct, as that was what the community decided. You'll note I was completely opposed to making that change; and it was for that reason. I finally caved because we were starting to get too many squeaky wheels, making allot of noise (with no useful proposed replacements) who were opposing the standard. It finally just made sense to adopt that one change to get it across the finish line. And, respectfully, the change was not appreciated. And I'm not saying that for myself. We made this change well over a month after the community meeting was completed. Everyone that participated went on with their lives, and used the standard as discussed. I've been publicly lambasted by at least a couple for making the change; because they felt like we picked something by vote, and then I personally arbitrarily changed it. But the numbers also dont lie. Out of the 9000+ 777 tokens, only something like 10 use rate. The rest use pct. And out of all tokens made, I think 2 used a whole integer. The CIP is a set of instructions; and there will always be a handful of people who just dont know how to read. Anyone competent enough to create a royalty token (something that has to be done totally manually at the moment; since I know of no scripts that do it) should be able to understand that we use a float to represent the percent. I know you strongly feel that rate is the correct tag; and I understand why. But take a step back and consider the bigger picture. This is not something anyone else wants. If I were to make any changes to the proposal, at this point, I would move back to pct because no one is using rate. |
|
Regarding the proposed change: Regarding the whole rate/pct thing, I understand your perspective and I am sorry if that caused undue trouble for you or any implementers. |
|
I agree it would need to be backwards compatible. I would expect that you
would have two choices; with a permanent address or follow the token.
I think we’re going to set up another meeting of the minds In the next few
weeks. There’s enough interest at this point that it makes good sense.
And it was always intended to be revisited. What we’ve seen is a wide
adoption from asset makers, but little in the marketplaces. The only one
that provides native support is Tokhun. Now that the space is more mature
and more people are aware of CIP-0027, the timing feels right. Ping me a
good email so I can ensure you are invited. ***@***.***
I do know there are quite a number of minor proposed concepts that go hand
in hand. And I also know some people want it to remain as is. So it would
definitely be hotly debated.
…On Sun, Jan 9, 2022 at 12:20 PM Shawn McMurdo ***@***.***> wrote:
Regarding the proposed change:
It would be good to clarify the case where you have an existing 777 token
containing an addr and what happens if it is sent to a different wallet.
A - If you stick with the addr then the existing projects don't get the
benefit of the new feature.
B - If you go with the holder of the 777 token, it's possible a few
existing projects sent the token somewhere where they don't want the
royalties to go because they understood the addr to be permanent. My guess
would be that would be a small number of cases.
This decision is important for people minting 777 tokens in the short term
since if we go with A you would not want to include the addr in order to
take advantage of t
he new feature but if we go with B you could include the addr so it works
with current marketplaces and you would still be able to transfer the
rights.
Lastly, what happens if the 777 token is burned?
Does that end all royalties whether it contains an addr or not?
Regarding the whole rate/pct thing, I understand your perspective and I am
sorry if that caused undue trouble for you or any implementers.
With standards there is often tension between accepting common use and
attempting to improve the standard.
I felt my proposal was a way of accomodating both.
—
Reply to this email directly, view it on GitHub
<#116 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ASZQAMGFQEQ4WRWUPQXVD5LUVHUYXANCNFSM5CFGGCAQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
I could not find any way to direct message you so I'm posting here. |
|
A suggestion of using "version": 2
If found follow asset to use current location as royalty destination. If
version 2 is used addr would be ignored if specified.
…On Sun, Jan 9, 2022, 7:01 PM Shawn McMurdo ***@***.***> wrote:
I agree it would need to be backwards compatible. I would expect that you
would have two choices; with a permanent address or follow the token. I
think we’re going to set up another meeting of the minds In the next few
weeks. There’s enough interest at this point that it makes good sense. And
it was always intended to be revisited. What we’ve seen is a wide adoption
from asset makers, but little in the marketplaces. The only one that
provides native support is Tokhun. Now that the space is more mature and
more people are aware of CIP-0027, the timing feels right. Ping me a good
email so I can ensure you are invited. *@*.*** I do know there are quite
a number of minor proposed concepts that go hand in hand. And I also know
some people want it to remain as is. So it would definitely be hotly
debated.
… <#m_-5500884524070308645_>
On Sun, Jan 9, 2022 at 12:20 PM Shawn McMurdo *@*.*> wrote: Regarding the
proposed change: It would be good to clarify the case where you have an
existing 777 token containing an addr and what happens if it is sent to a
different wallet. A - If you stick with the addr then the existing projects
don't get the benefit of the new feature. B - If you go with the holder of
the 777 token, it's possible a few existing projects sent the token
somewhere where they don't want the royalties to go because they understood
the addr to be permanent. My guess would be that would be a small number of
cases. This decision is important for people minting 777 tokens in the
short term since if we go with A you would not want to include the addr in
order to take advantage of t he new feature but if we go with B you could
include the addr so it works with current marketplaces and you would still
be able to transfer the rights. Lastly, what happens if the 777 token is
burned? Does that end all royalties whether it contains an addr or not?
Regarding the whole rate/pct thing, I understand your perspective and I am
sorry if that caused undue trouble for you or any implementers. With
standards there is often tension between accepting common use and
attempting to improve the standard. I felt my proposal was a way of
accomodating both. — Reply to this email directly, view it on GitHub <#116
(comment)
<#116 (comment)>>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASZQAMGFQEQ4WRWUPQXVD5LUVHUYXANCNFSM5CFGGCAQ
<https://github.com/notifications/unsubscribe-auth/ASZQAMGFQEQ4WRWUPQXVD5LUVHUYXANCNFSM5CFGGCAQ>
. Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you were mentioned.Message ID: @.*>
I could not find any way to direct message you so I'm posting here.
You can reach me at ***@***.*** .
—
Reply to this email directly, view it on GitHub
<#116 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AANNWZBWIHWGSFXVJWLTXT3UVIOTXANCNFSM5CFGGCAQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you commented.Message ID:
***@***.***>
|
We're still trying to decide how we want to handle the ADA Clouds case where the creator rugged the project after minting the royalty token and never paid the artists. If I understand correctly, the purpose of the original proposal was to enable buyers of an NFT collection to have a guarantee that the royalty percentage won't be changed on them in the future thus potentially harming their investment. In this view, it should be okay for us to modify the address, but not the percentage of the minted royalty token. Does anyone object to this? We really want to support ADA Clouds given the scenario, their community had a vote with something like +95% approval that they didn't want to trade on any marketplaces honoring the original royalty token. Furthermore, it seems the folks here are planning to create a 2nd version of this proposal which would allow for the royalty token to switch addresses in the near future. |
|
Its not that cut and dried. You have to consider both 1) Strain on the
marketplaces. Every time something changes, we're effectively telling them
they need to make code update. 2) Min-utxo.
…On Mon, Jan 10, 2022 at 9:15 AM Blake Brown ***@***.***> wrote:
Not to mention that you can fractionalize said token like Fracada does and
distribute the royalties among different team members in second stage of
protocol execution.
This idea, specifically was proposed by Fencemaker. So he would deserve
all of the credit if that were to be used. But the reason we didnt do
multiple tokens, and probably ultimately didnt further pursue using tokens
is because of min-utxo. But I dont think we stopped to consider leaving it
as a single token.
Aside from this one change, I think everything else should remain
unchanged with the 777 token. It needs to be the first mint. We only honor
the first mint. The rate/percent is locked in. And its backwards
compatible, because it either has an addr, or it doesnt. If it doesnt, we
query db-sync to locate it. And its non commercialized. I'm sure there will
be many services pop up like $adahandle. I was actually working on a
similar concept earlier in 2021, but didnt see it through. So leaving it as
a no name token, keeps it true to its intent.
But regardless, I would want to have a meeting of the minds before
introducing a potential change to the CIP. The plan was to meet as needed
every few months to discuss potential changes. And I think it makes allot
of sense at this point. Adam Dean did a survey about a month ago. At that
time we had over 9000 royalty tokens. Its very clear that the standard is
being widely adopted. And I've never opposed challenging views on it. What
I've opposed is a challenging view, with no proposal that worked that could
replace it. To date, no one has proposed anything viable.
I'm going to try to set up another meeting in the not too distant future.
We're still trying to decide how we want to handle the ADA Clouds case
where the creator rugged the project after minting the royalty token and
never paid the artists.
If I understand correctly, the purpose of this proposal is to enable
buyers of an NFT collection to have a guarantee that the royalty percentage
won't be changed on them in the future thus potentially harming their
investment.
In this view, it should be okay for us to modify the address, but not the
percentage of the minted royalty token. Does anyone object to this? We
really want to support ADA Clouds given the scenario, their community had a
vote with something like +95% approval that they didn't want to trade on
any marketplaces honoring the original royalty token. Furthermore, it seems
the folks here are planning to create a 2nd version of this proposal which
would allow for the royalty token to switch addresses regardless.
—
Reply to this email directly, view it on GitHub
<#116 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ASZQAMCJRJEEGOXFSF6NF73UVMH2DANCNFSM5CFGGCAQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Min-UTXO applies in the case of multiple royalty addresses, which I totally understand. TBH I don't think we should support something like this until the release of hydra, or another scaling solution to lower the fees for buyers. As for the strain on other marketplaces, I suppose it is up to each marketplace to decide how they would prefer to handle these situations. We already have to make some centralized decisions, for example how we handle fake NFT's like photos of SpaceBudz uploaded to our marketplace under a different policy ID. Ideally, these decisions should become more and more decentralized over time as we build the proper infrastructure to support it. Similar to the Cardano blockchain itself. |
|
Indeed.
The second round community discussion will be starting up in a couple of
weeks. If you feel like you have something to contribute, and would like
to participate, please reach out to me directly. You can hit me up on my
huths0lo and/or cnfthub twitter.
On Mon, Jan 10, 2022 at 10:24 AM Blake Brown ***@***.***>
wrote:
… Its not that cut and dried. You have to consider both 1) Strain on the
marketplaces. Every time something changes, we're effectively telling them
they need to make code update. 2) Min-utxo.
… <#m_6482734460801158391_>
On Mon, Jan 10, 2022 at 9:15 AM Blake Brown *@*.*> wrote: Not to mention
that you can fractionalize said token like Fracada does and distribute the
royalties among different team members in second stage of protocol
execution. This idea, specifically was proposed by Fencemaker. So he would
deserve all of the credit if that were to be used. But the reason we didnt
do multiple tokens, and probably ultimately didnt further pursue using
tokens is because of min-utxo. But I dont think we stopped to consider
leaving it as a single token. Aside from this one change, I think
everything else should remain unchanged with the 777 token. It needs to be
the first mint. We only honor the first mint. The rate/percent is locked
in. And its backwards compatible, because it either has an addr, or it
doesnt. If it doesnt, we query db-sync to locate it. And its non
commercialized. I'm sure there will be many services pop up like
$adahandle. I was actually working on a similar concept earlier in 2021,
but didnt see it through. So leaving it as a no name token, keeps it true
to its intent. But regardless, I would want to have a meeting of the minds
before introducing a potential change to the CIP. The plan was to meet as
needed every few months to discuss potential changes. And I think it makes
allot of sense at this point. Adam Dean did a survey about a month ago. At
that time we had over 9000 royalty tokens. Its very clear that the standard
is being widely adopted. And I've never opposed challenging views on it.
What I've opposed is a challenging view, with no proposal that worked that
could replace it. To date, no one has proposed anything viable. I'm going
to try to set up another meeting in the not too distant future. We're still
trying to decide how we want to handle the ADA Clouds case where the
creator rugged the project after minting the royalty token and never paid
the artists. If I understand correctly, the purpose of this proposal is to
enable buyers of an NFT collection to have a guarantee that the royalty
percentage won't be changed on them in the future thus potentially harming
their investment. In this view, it should be okay for us to modify the
address, but not the percentage of the minted royalty token. Does anyone
object to this? We really want to support ADA Clouds given the scenario,
their community had a vote with something like +95% approval that they
didn't want to trade on any marketplaces honoring the original royalty
token. Furthermore, it seems the folks here are planning to create a 2nd
version of this proposal which would allow for the royalty token to switch
addresses regardless. — Reply to this email directly, view it on GitHub
<#116 (comment)
<#116 (comment)>>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASZQAMCJRJEEGOXFSF6NF73UVMH2DANCNFSM5CFGGCAQ
<https://github.com/notifications/unsubscribe-auth/ASZQAMCJRJEEGOXFSF6NF73UVMH2DANCNFSM5CFGGCAQ>
. Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you were mentioned.Message ID: @.*>
1. Applies in the case of multiple royalty addresses.
I understand 1) the strain on other marketplaces. I suppose it is up to
each marketplace to decide how they would prefer to handle these situations.
—
Reply to this email directly, view it on GitHub
<#116 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ASZQAMCDSA4WDLQAU7WGDATUVMP63ANCNFSM5CFGGCAQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
I have been thinking in ways to handle fake NFTs but I'm sure its going to have to be a joined effort with markets and asset makers too. I've been thinking in the idea of using a MD5checksum for the metadata of the minted transaction. We asset makers should verify within our history for the existence of a minted asset and "flag" them accordingly, I suppose. A MD5checksum can be stored, indexed and be quickly available to verify the uniqueness of the computed file within our systems. It's also backward compatible in the way we can calculate the MD5checksum for existing tokens and store it in the DBSync database for example. I may be completely wrong about it haha but It would be really nice to have a way to append this information which is unique to each file before minting new tokens. |
rphair
removed
the
State: Last Check
No description provided.