Skip to content
This repository was archived by the owner on Jan 9, 2026. It is now read-only.
This repository was archived by the owner on Jan 9, 2026. It is now read-only.

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

@kitty-kad

Description

@kitty-kad

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)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions