You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)
The text was updated successfully, but these errors were encountered:
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
changed the title
Standardising how capabilities should be granted for royalties
Standardising how capabilities should be granted for royalties on Marmalade
Sep 20, 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)
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.
Current Problem
It's difficult to make a UI that can handle different royalties on Marmalade. In particular because
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
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
Cons
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
Cons
The text was updated successfully, but these errors were encountered: