Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Standardising how capabilities should be granted for royalties on Marmalade #27

Open
kitty-kad opened this issue Sep 20, 2022 · 2 comments

Comments

@kitty-kad
Copy link

kitty-kad commented Sep 20, 2022

Current Problem

It's difficult to make a UI that can handle different royalties on Marmalade. In particular because

  1. There is no standardisation of which capabilities need to be granted to pay for royalties
  2. Royalties can be paid to an arbitrary number of parties, each payment requires a capability
  3. The UIs have no programmatic way to know which capabilities need to be granted

Proposals

There are multiple ways to do this, I have two options I'm proposing to solve this. However I have no strong opinion and am interested in what the community thinks

Option 1 - All funds are sent to the smart contract directly
It is possible to send all the funds to an account managed by the smart contract, then the smart contract pays out the royalties.
For example, during an NFT sale on Marmalade

  • The NFT was sold for 100 KDA
  • 5 KDA paid in royalties to one party
  • 15 KDA paid in royalties to another party
  • 80 KDA paid to the seller

In this scenario, a capability is granted to send 100 KDA to an account managed by the contract.
The contract than redistributes 5, 15 and 80 KDA to the necessary parties
The address for the account managed by the contract can be exposed via a function (as users might want to update the account, however I don't have any current valid scenarios where this may be the case, so it could be possible to add it to a static datum).

Pros

  1. Capability logic is simple

Cons

  1. It's not clear where the funds are going for the user (however, it is arguable if they need to know)
  2. Requires every policy to create an account with the coin (not necessarily a big issue)

Option 2 - The policy returns a list of accounts and how much they should be paid
The policy can have a method that calculates the exact amounts that need to be sent to different accounts as part of a sale.
Using the example from Option 1, the policy can can return an array of objects like so
[{"k:account1": 5.0}, {"k:account2": 15.0}, {"k:account3": 80.0}]

Pros

  1. It's clear to the user where the funds are going

Cons

  1. It requires the contract creator to add extra logic to their methods
  2. There could be complex-ish logic to avoid adding the same capability twice. I.e. if a royalty of 20 KDA is paid into the same account that sold the NFT and should get 80 KDA, two capabilities of 20 KDA + 80 KDA won't work, instead one for 100 KDA must be presented (this could be overcome by having a helper util function handle edge cases)
@kitty-kad kitty-kad changed the title Standardising how capabilities should be granted for royalties on Marmalade Standardising how capabilities should be granted for royalties Sep 20, 2022
@kitty-kad kitty-kad changed the title Standardising how capabilities should be granted for royalties Standardising how capabilities should be granted for royalties on Marmalade Sep 20, 2022
@kitty-kad
Copy link
Author

kitty-kad commented Sep 21, 2022

This may be fixed by follow on work from kadena-community/kadena.js#59
Leaving discussion for the community to decide if we should still add it to the standard or rely on code parsing libraries. (Kadena team feel free to close this off based on your opinion)

@bart-kuma
Copy link

I see this as a general problem and not only specific to marmalade. It will be a lot more easier in front-end, if we get to know what capabilities are needed for the transaction. I know it needs a lot of work.
But i believe kadena-community/kadena.js#59 will be helpful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants