Discussion for ARC-0018: ASA Transfer Royalty Enforcement Specification

fabrice102 commented 2 years ago

This is the new page of discussion for ARC-0018. Moved from #70

fabrice102 commented 2 years ago

I haven't fully read the new ARC but one comment I have first is the following. The current ARC constrains the design of royalty in two ways:

It forces the keys used in local and global storage
It forces the way some functions (such as royalty_free_move) are permissioned: namely must be called by some specific administrator.

I think that removing these restrictions would allow more flexibility for the contract designer while still allowing clients (wallets, exchanges, explorers) to use the ARC. Concretely:

Forcing the keys limit the number of ASA that can be handled while better schemes could be used compressing data in the value.
Forcing the existence of a single administrator account means that setting policy and royalty free move need to be performed by the same party. But we could imagine that we want to use two different parties. Or that "cheap" assets can be royalty-free move with a less secure account than "expensive" assets. In theory, we could allow all of the above by making the administrator an application account. But this looks to me like more complex than just not specifying the permissioning mechanism.

Another way to say it is that I think the way ARC-0020 is written allows more flexibility while providing similar value: it does not specify how permissioning works nor how storage works.

What do you think @barnjamin @cusma @wheresaddie?

cusma commented 2 years ago

@fabrice102 I agree, since ARC-0018 requires ARC-0020 I think is worth sharing the same approach here and allow for more flexibility, leaving those decision to the reference implementations (so not mandating them in the standard itself).

GGManera commented 2 years ago

After reading the documentation and discussion regarding ARC-18 I am comfortable to say that it already seems to be the best solution to give NFT artists/creators the opportunity of choosing Royalties Percentages for their artworks without sacrificing marketplace interoperability. I understand that what is being proposed and developed (please correct me if I'm mistaken) is an ASA standard that forces a pre-established percentage of all resells of an NFT to be sent to pre-established wallet address(es), being those pre-establishments made exclusively in the moment of creation of said ASA by the creator, not being susceptible to changes in the future by anyone, including even the ASA creator.

Since the proposal is to implement an ASA standard that has much potential of being mass adopted by artists and creators to mint their NFTs, it is extremely important to keep the already existing conveniences that ARC-3 and ARC-69 brings, which are exactly what enables so much freedom for creative utility and marketing strategies in Algorand’s NFT ecosystem, while giving collectors a truly satisfying sense of ownership. I felt the necessity of pointing out the following scenarios in order to raise awareness to the possible limitations that the current ARC-18 could bring, which in my opinion would be enough for it not being used at all.

Direct ASA Transfers between wallets shouldn't configure a selling, thus it shouldn't be necessary to Enforce Royalties in this case. I'm pointing out three scenarios where needing to pay royalties would make ARC-18 very inconvenient:

1.1 Using a hot wallet to buy an NFT and then Transferring it to a safe wallet of your ownership;

1.2 Giveaways;

1.3 Gifting someone;

I couldn’t figure out the necessity of Enforcing Royalties when directly transferring assets, only if atomic-swaps are involved. I apologize if those scenarios were already thought out and I just couldn’t figure out by reading the doc and discussion. I’m not a code developer, only a community member which have much interest in Algorand’s NFT Ecosystem. With that said, finally I want to congratulate all developers involved in this discussion and development so far! Thanks for always bringing Algorand to a next level.

/gabriel.algo

barnjamin commented 2 years ago

Hi @gbrgmanera good points and worth considering!

In this spec we've added an "escape valve" for doing transfers royalty free, namely the royalty_free_move method. This method will allow for transfers without enforcing a royalty payment.

It would be up to the application creator to determine how exactly to offer this method generally. It's hard to offer an API that takes into account the intent of the sender and the acceptability of a transfer sans royalty by the creator so I think it'd have to be on a case by case/application specific basis.

That said, it may make sense to demonstrate how an application may want to implement such behavior so that creators can approve (maybe automatically) certain types of transfers.

cusma commented 2 years ago

@barnjamin @gbrgmanera I think that royalty_free_move could be easily used to realize giveaways logics. What is harder, in my opinion, is adopting that same method to realize transfers between wallets belonging to the same owner, since it's more difficult to prove that two different public keys belong to the same user. This being said I agree this use case should be solved by specific ARC-18 implementations rather than by the ARC-18 standard directly.

robdmoore commented 2 years ago

Has any thought been given to the feasibility of using a single contract for multiple ASAs. For instance, let's say I mint 1000 assets that I all want to be controlled by the same royalty contract. It would be very convenient from a cost and administration perspective to be able to deploy the royalty contract once and then set the clawback for all 1000 assets to that contract. I get this is probably more a discussion for ARC-20 since this is associated with that though?

barnjamin commented 2 years ago

@robdmoore With the current ARC18 spec the expectation is that any number of ASAs may be managed by a single application. While ARC18 is meant to be an implementation of ARC20, the current ARC20 reference implementation only allows for a single ASA to be managed so it will need to be tweaked to allow any number

Current ref for arc18 https://github.com/algorand-devrel/royalty

and some WIP references using beaker https://github.com/algorand-devrel/beaker/tree/master/beaker/contracts/arcs

cusma commented 2 years ago

@robdmoore ARC-20 does not mandate a single-Smart-ASA-per-app, but is open to a multi-SmartASA-per-App in principle. The current reference implementation of ARC-20 allows a single Smart ASA per App due to limitation in Global Storage that could be potentially overcome once Boxes are available. But again, ARC-20 is open to this possibility, is just a matter of implementation complexity.

FrankSzendzielarz commented 2 years ago

Why basis points (uint64) as opposed to Arc4 ABI Type Fixed Point?

barnjamin commented 2 years ago

basis points seem good enough to convey the requirement and dont need any special codec

SudoWeezy commented 2 years ago

I have a point to raise on this.

The royalty Receiver can be any account ( App, LSig, wallets)

Royalty Receiver - The account that receives the royalty payment. It can be any valid Algorand account.

Usually, creators do not work alone.

If I want the whole team to be paid at once, there are 2 possibilities.

I create a Lsig/App that will be the royalty_receiver, and with a crontab, I call the Lsig/App to split the payment. Pros:
- We keep the arc as is. Easier for the marketplace to implement it Cons:
- We add friction to people who need this kind of feature
We add a new *OPTIONAL method after_transfer_call that needs to be called at the end of any transaction. This method might call a "Payment_Splitter" or any Application that needs to be called at the end of a transaction. Pros:
- Creators should not have to worry about setting up a server or running the application manually Cons:
- More work for the marketplace

I think 2 is better and should be considered to make Smart Asa ARC-20 Smarter.

cusma commented 2 years ago

As per Royalty Receiver description:

The Royalty Receiver is then responsible for any further royalty distribution logic, making the Royalty Enforcement Specification more general and composable.

I'm inclined to keep the relationship between the Royalty Enforcer and the Royalty Receiver modular.

There could be different "royalty distribution logic" depending on: distribution time schedules, minimum distribution amounts, different distribution shares among creators, etc. etc.

Since each project / NFT / marketplace could have its own distribution logic I would keep the implementation and the requirements of a Royalty Receiver (and eventually Distributor) separate, giving to the marketplaces, minting platforms, wallets, etc. the possibility of managing the distribution as they prefer (e.g. on a crontab time basis, etc.).

So for example:

Marketplace XYZ will use a Royalty Enforcer to collect 3% on each trade in the Royalty Receiver. The Royalty Receiver is then an Application programmed to redistribute 1% to the Marketplace XYZ and 2% to the Creator if and only if the Royalty Receiver balance is greater than a given minimum_distribution_amount (to save fees).
Artists Collective ABC will simply use a Royalty Enforcer and then set up a MultiSignature Account (between the member of the Collective) as Royalty Receiver address.