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

Support multiple fee recipients #10

Open
stanly-johnson opened this issue Dec 21, 2021 · 2 comments
Open

Support multiple fee recipients #10

stanly-johnson opened this issue Dec 21, 2021 · 2 comments
Assignees
Milestone

Comments

@stanly-johnson
Copy link
Member

Currently the fee_handler function can handle only one fee recipient
fn apply_fees(from: &Account, to: &Account) -> (Account, Percent);

We can improve this function by returning a list of fee recipients
fn apply_fees(from: &Account, to: &Account) -> Vec<(Account, Percent)>;

In the release extrinsic, the fee amount should be transferred to all recipients returned by apply_fees provided the count is less than MAX_FEE_RECIPIENTS. It is also important to implement dynamic weights for this extrinsic to account for too many recipients.

@olanod
Copy link
Member

olanod commented Feb 18, 2022

Since we are using the bounded vec already I think this is something we can tackle now, I'm thinking the bound of the recipient limit can even be hardcoded(e.g. 8 or 16) to make it easier with the weights.
One extra feature we can have to future proof this more is to return the bounded vec of Fee objects that have besides an account(&self) -> &Account method have a total/apply or equivalent that receives the total amount and returns an amount. A Fee::Percent(_, Percent) does the calculation but other kinds of fee(e.g. Fee::Fixed, Fee::System,...) would just return the already stored amount.

@olanod
Copy link
Member

olanod commented Mar 4, 2022

Throwing more ideas to the pot, fees don't have to be just a list of accounts that will receive money from the payer it can also include accounts that will "give money" money to the payer, in other words discounts.
Discounts and promotions are very common in the e-commerce world, our fee handler can be more of a FeeAndDiscountHandler(better name required) that returns similar to the previously mentioned Fee object a struct that can represent fixed amounts or percentages that can be either positive or negative.

To give an example, imagine 🧑‍🌾 Bob selling milk in a marketplace and 👩🏽Alice buying a bottle for 100 MLK, 🐮 milkyplace takes a 3% fee for each bottle that Bob sells, there's also a tax for diary products in their local community of 0.1%, Alice might be the holder of a NFT coupon that gives her a 5% discount and on top of that the Virto nation wants their people to have strong bones so it gives people 50MLK for each bottle. Alice still pays 100MLK(bottle) + 3MLK(fee) + 0.1MLK(tax) + 5MLK(example release incentive) = 108.1MLK, but the since the list now part of the payment detail also includes discounts, those are reserved from the accounts returned from the handler(i.e. 5MLK taken from the coupon issuer and 50MLK from Virto) so when Alice releases the funds it gets back 60MLK🥛!.

@olanod olanod transferred this issue from virto-network/virto-node Mar 20, 2022
@olanod olanod added this to the Payments V1 milestone Mar 20, 2022
@olanod olanod removed the payments label Mar 21, 2022
@stanly-johnson stanly-johnson self-assigned this Mar 22, 2022
@stanly-johnson stanly-johnson linked a pull request May 9, 2022 that will close this issue
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

Successfully merging a pull request may close this issue.

2 participants