Standardising how capabilities should be granted for royalties on Marmalade
Current Problem
It's difficult to make a UI that can handle different royalties on Marmalade. In particular because
- There is no standardisation of which capabilities need to be granted to pay for royalties
- Royalties can be paid to an arbitrary number of parties, each payment requires a capability
- 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
- Capability logic is simple
Cons
- It's not clear where the funds are going for the user (however, it is arguable if they need to know)
- 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
- It's clear to the user where the funds are going
Cons
- It requires the contract creator to add extra logic to their methods
- 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)
This may be fixed by follow on work from https://github.com/kadena-community/kadena.js/pull/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)
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.