CIP-???? | Native Token Fee Payment API

[TotallyNotChase]

This CIP proposes to standardize an API that can be used to provide babel-fees like functionality that dApps and wallets can easily integrate with. The hope is that the API can be supported by both stopgap solutions in the present (in absence of babel fees) and also babel fees in the potential future.

(rendered document)

[rphair]

thanks @TotallyNotChase - there are some formatting things that need to be fixed before next meeting review though there's no reason to wait until then to start reviewing the idea. Tagged Triage to put on the next agenda: https://hackmd.io/@cip-editors/116

[Crypto2099]

The standard is looking pretty good and straight forward. Would be interested to hear some feedback from those integrating "babel fees" such as Fluid Tokens teams and other to see what they think about the use and utilization of the standard.

[rphair]

@TotallyNotChase we were able to tag this for Triage during yesterday's CIP meeting and give it as much introductory consideration time as other items on the agenda.

We chose to leave it Unconfirmed (no CIP number assigned yet) mainly because of uncertainty about whether the proposed methods are acknowledged, let alone planned, by the agencies in the Abstract: as highlighted earlier by @Crypto2099 in #1052 (comment).

How "centralised" this approach might be was also considered at the meeting (mainly proposed by me: not necessarily confirmed by other editors). I think a standard for how third parties provide services like this will be valuable, and welcome in the ecosystem, but should also (in the Rationale I would hope) be compared & contrasted with more decentralised methods such as:

• (proposed: cc @polinavino @WhatisRT) #862
• (active: cc @fallen-icarus) https://github.com/fallen-icarus/cardano-swaps

Perhaps the identified needs could be covered entirely by your proposal, but in review I would also like to include the premise that "multiple points of centralisation is still centralisation."

[TotallyNotChase]

Definitely agree on trying to get feedback from other agencies that exist currently. I'm not entirely sure how to get a hold of Fluid devs but I should clarify that feesaswap is implemented by us at MLabs.

[rphair]

Definitely agree on trying to get feedback from other agencies that exist currently.

yes, this also came up in the last meeting with regard to the Path to Active: since as currently written only one API and one API user is required... and should be more for any client-server standard (otherwise the same vendor can simply produce both client & server without assuring generality or interoperability):

[rphair]

@Ryun1 you are often the one who's bumped the numbers up here: I would say two would be proof of generality & activity in the community but would defer to someone who does more day-to-day work with commercial apps.

Suggested change

	- [ ] The interface is implemented by one or more services.
	- [ ] The interface is used by one or more dApps or wallets.
	- [ ] The interface is implemented by two or more services from distinct providers.
	- [ ] The interface is used by two or more dApps or wallets from distinct providers.