Proposal: I am proposing a fee (5%?) for the use of the Regen Ledger API, which would be sent to the Regen Network Community Pool.
**Scenario: **At current, there is an increasing number of dApps being developed that draw from the ecological credit supply listed for sale on Regen Marketplace. As the user base of these dApps grow, they are extracting value from the Regen Network community of credit origination to their privately-owned applications without providing value to the community at-large in return. The API acts as a gateway for credits to exit the Regen Network community without a clear value exchange.
While I support the rapid expansion of dApps for marketplace-adjacent use-cases, and am developing some myself, I would like to see there be a fee-for-use framework adopted for engaging with the Regen Network credit value proposition, in order to further fuel community development. I believe the revenue would be a positive force for the community and both fuel and fund creativity.
**This is a preliminary discussion, and I would like to hear the ideas of others in the community about what will best serve Regen Network. **
These are my personal opinions, not the opinions of any entity or organization. I’m just a human not representing anyone but myself in this conversation.
Thanks for bringing this up @SarahBaxRND. I’m really excited about getting on-chain % fees introduced into regen ledger, but have some questions about the approach you have in mind.
How is this proposal different from the fee structures being evaluated in the context of the tokeneconomics working group?
I’d like to better understand what you’re thinking here, and what you mean by a fee for use of the regen ledger API.
Marketplace transaction fees
If what you mean is simply adding fees to all marketplace transactions (e.g. any purchase against a open sell order), then I think this is already being considered in the context of other tokeneconomics discussions, and I’m personally in full support of us introducing such a fee. One note of clarification - it’s not technically feasible to distinguish between users who are engaging in a transaction via a 3rd party app (e.g. the API) to make a purchase, versus users who are engaging through the marketplace UI.
From my POV, it probably makes sense to have a flat fee (let’s say 5% for now, but this can always be a governance controlled % rate, and token holders can vote to adjust it as needed) for all marketplace transactions, whether or not those transactions came through API or a web app such as the marketplace. I think this is the easiest technical solution, and allows us to have fees proportional to the value of transactions being processed by the marketplace, which is a big win.
Non-marketplace transaction fees
If you’re also thinking of mechanisms for charging fees for API transactions that don’t involve marketplace transactions, this becomes much trickier. How are we to value such a transaction? If a user is retiring ecocredits, transferring ecocredits to a group module address, or converting into a basket token, there isn’t a clear way to determine the value of those ecocredits, so if the fees are expected in REGEN or some marketplace allowed currency, there’s not clean way to know
On a parallel note, I think it would also be valuable if there was a % fee for the use of the API, for it NOT to go into the general community pool, but conversely fund an application builders fund, so that the creative communities building products with the API are in fact self-funding their creative community when paying these fees. That’s a much easier sell. Hey, pay this fee and help fund the builders DAO grants programs. Got a feature you want to propose? Once the pool is large enough we’ll start doing features RFPs!
I don’t think that generally flowing % fees (API, marketplace, or any other fee structure) to the Community Pool is an effective economic decision. It’s not targeted. The value doesn’t flow from the action or product to the DAO that would provide the services of maintaining or improving that product. Without being economically specific, the abstractness leaves value floating, and disempowers the community of creators that are most intimately involved with the product development itself. This stifles economic mobility and product creativity by creating another abstraction layer to the economic paradigm. Why should every single function and every single builder have to go to the Community Pool? Why can’t they self-fund and be self-sovereign, within the overall value chain of the network? Some groups will be more succesful than others. Maybe a standard portion of each fee flows to the network at large, but then the remainder flow to context-specific funding pools or DAOs? We should let the economic competition of product-market-fit drive the economic and business flows of the network naturally, rather than forcing collectiveness economically on every token holder. No one wants that level of specificity but the do-ers themselves!
I believe we need to view Regen Network as a decentralized series of micro-economies, where value should flow both to the whole, and well as into it’s DAO, service providers, or functional parts, very very very clearly. I