LIP:16 Standardizing Fees for Collecting NFTs and Other Paid Actions

[kkpsiren]

---

title: LIP-16 Standardizing Fees for Collecting NFTs and Other Paid Actions
description: This proposal aims to establish a foundational infrastructure for the sustainability of applications and protocols through nominal fees from value-imbued microtransactions, such as paid collect NFTs and other paid actions.
author: @lens/kipto and @lens/nilesh
status: Draft
type: Protocol
created: 2024-03-06

Abstract

The introduction of $bonsai, a potential first native Lens token, signals a pivotal moment for the Lens Protocol. It emphasizes the necessity to build a sustainable circular economy that benefits all ecosystem participants. By introducing and standardizing fees for microtransactions, including paid NFT collects and other paid actions such as paid follows, we propose creating an equitable framework that ensures value created within the ecosystem is fairly distributed. This approach aims to foster a balanced and sustainable growth, benefiting applications developed on the protocol and ensuring the longevity and resilience of the ecosystem.

Motivation

The current model, primarily sponsored by the protocol, offers tremendous value to users and applications but lacks a viable path towards sustainability. It's imperative to address the long-term sustainability of both the protocol and its applications. By implementing a small fee on microtransactions, we can create a revenue model that supports the ecosystem's growth while maintaining its user-friendly experience. This model will allow for a fair and sustainable distribution of value between the protocol, applications, and content creators, ensuring the continued provision of a gasless experience and the onset dynamics for a circular economy.

Specification & Rationale

We propose a standardized fee mechanism for paid collects and follows, benefiting applications, content creators, and the protocol. A fixed percentage fee on these actions will secure a steady revenue stream, distributing value across the ecosystem. The protocol will take a nominal portion of this fee and to the application where the content was created and consumed, with the majority allocated to content creators and referrer, promoting a fair and sustainable economy.

To ensure uniformity and equitable practices across the ecosystem, we suggest a fixed nominal fee in percentage points for revenue sharing for the protocol and platform. A predetermined portion of this fee will directly be directed to the Lens treasury, supporting the protocol's development and gasless experience, while the main part will reward the application that enabled the content creation and collect experience.

One purely hypothetical example could be a 4-4-2 model, where 2% of the fee goes to the protocol, 4% to the application where content was created, and 4% to the application where the content was collected.

Drawing from successful experiments like Orb's community wallet feature, which redirected a fixed fee percentage to clubs, we advocate for standardizing this practice. This not only supports creators but also incentivizes applications that drive user engagement and revenue generation in novel ways, without significantly detracting from creators' earnings.

This proposal aims to balance growth, sustainability, and equitable value distribution, ensuring a thriving ecosystem for all stakeholders.

Copyright

Copyright and related rights waived via CC0.

[height]

Link Height tasks by mentioning a task ID in the pull request title or commit messages, or description and comments with the keyword link (e.g. "Link T-123").

💡Tip: You can also use "Close T-X" to automatically close a task when the pull request is merged.

[ZKJew]

I agree that there should be an aggregate small and nominal fee to be included in the protocol; however, I am unsure on the 4-4-2 distribution. Personally I think it should be a 2.5-2.5-5 distribution where the protocol gets half the fees and the apps either get half or a quarter depending on the action presented. I think unlike the idea, this metric will be very contentious. I just think the protocol ought to have funding and if apps are in need you can swing to the other direction - but it is quite hard to swing back towards the protocol.

[ZKJew]

Also, should a segment be devoted for rewarding upstarting creators retroactively?

[imthatcarlos]

I agree with @ZKJew here; I think that the protocol should take the largest chunk purely because that is its sole revenue stream. Applications will be integrating many open actions, etc and thus generating fees from each. That being said, 5-2.5-2.5 makes sense.

We definitely need this, as most of the open actions we've built at MadFi support client fee share but in a non-standard and often after-thought kind of way.

[mvanhalen]

This is much needed. Totally agree and support.

[joshstevens19]

There are excellent comments here. Thank you all.

We could do this:

Instant actions

• Protocol adds 5% onto all follow paid actions and open paid actions (including collect)
  The app can already take a split of revenue from collects by using the MultirecipientFeeCollectModule. They can pass their address to one of the recipients with an x% fee cut and then state it to a user. This is powerful as apps can decide their split depending on their services.
• Any verified modules in the future must have revenue protocol payouts in the module itself, as the module code is the code that pays out. If they do not do this, we will not verify the module on the GitHub. Note that the module will still be usable but will not accept gasless logic on the API.

Revenue shared between apps

The protocol does not have a module which supports someone posting on app A, but collecting on app B; in this case, app B should get something as well; in my eyes, a 50/50 split of what the fee revenue app A would take. Maybe @imthatcarlos or someone else could build a new module that allows apps to share this revenue; I think we could start with the collect modules first and then do something similar for the follow modules as it will be very similar.

My example will be on a collect module:

• Create a new module
• within initializePublicationCollectModule calldata it asks for:
  • an array of recipients with % splits (to make it possible to split with many people peer to peer)
  • a single revenue address with % defined against it (this is what the app will take)
  • all the other parameters a collect has, amount, collectLimit, currency, referralFee, followerOnly, endtTimestamp
• In the processCollect calldata, you allow the apps to pass in their address (can decide the structure of that data, but it can be included in the calldata itself and easily decoded).
• Within the processCollect, you pay the revenue to the protocol, and you check if != address(0) of the parameter in the calldata; if it is defined, you then split the recipient 50/50 with what the app would have got with that address.

You now have a module which works with app sharing and pays out live onchain.

[Pech04]

Totally agree and support!

[boboji]

This is a good idea and can balance the interests of the lens project and developers.

[koric00]

I agree with the views above, but I want to emphasize one point: the entire economic ecosystem would be best designed around the Lens token (if there is one), to form a virtuous cycle, so that the whole protocol can thrive.

[luduvigo]

Interesting proposal.

Anyway I believe that with a model like this in place we are far away from the point in which we can generate a sustainable revenue stream for the protocol and the apps.
There could be some usecases, like paid content that can generate substantial revenues in the future, but it is still not happening.

Traditional social media has generated a lot of revenues by selling space to brands on their feeds (ads), maybe that model is more sustainable with the type of content we have now on Lens.

Happy to get your feedback on this one.

[eberson7]

I see no issues with this proposal, proceed....

[562864126]

Very good proposal, no payment and token ecology, what system is the source of nothing, very supportive

[hjjlxm]

Examples to draw on include mirror.xyz and zora.co, with a fixed percentage of the revenue allocated to protocol and the rest to creators and other designated recepiants. For the sake of long term development of lens protocol, I think it makes sense to create such a standardization, of course, the exact proportions may need to be fine-tuned.

[danubio93]

I agree, without a doubt it is a correct path towards sustainability without penalizing the user too much.

[benalistair]

I think this makes a lot of sense. I'm also in the same boat regarding allocating 5% to the protocol. Implementing a framework like this seems like a good step to keep things sustainable as the ecosystem continues to grow. Thank you for putting this LIP together @kkpsiren & Nilesh

[devdefifury]

I'm happy this is coming up and I fully support the idea.

I can already think of interesting uses cases when it comes to Clubs/Communities.

So many revenue points waiting to be maximized.

[Driss2906]

A big part for the protocols

[bradorbradley]

I am strongly supportive of a "reward fee" that aligns the economic incentives of all the relevant stakeholders in the Lens ecosystem. Zora's protocol rewards feature has been a key contributing factor to attracting both creators and builders to the Zora ecosystem. Perhaps more importantly, Zora's protocol rewards system ensures that all parties - including creators, smart contract developers, front-end builders, and Zora protocol itself - all share in the upside.

I believe Lens can take this one step further by recognizing that where a post is created and where a post may be collected are not the same app. Many apps on Lens are currently built with a primary behavior in mind - for example, Orb currently does not offer a way to collect or do paid actions on mobile just yet, but is extremely convenient to create content from mobile. Apps like Orna are more focused on curation (and collection), and Hey and Tape are popular for collecting as well. While this will change over time, it's reasonable to say that, thanks to the distribution benefits Lens offers, more than one application can (and often will) contribute to a user taking a paid action. Should an app emerge that is successful in both content creation and content collection, they should get to "double dip" on the reward fee.

To this end, the need for a module that enables apps where a post is created AND collected critical. Without this, apps do not have an incentive to allow other apps to distribute content created on their own site. We learned about this in practice with the Artists by Refraction community - where users posted collectible content to the Refraction club on mobile on Orb, but users could only collect on Hey. In this case, the apps also needed to share API keys with each other to allow this use case, and Orb did not receive any revenue from posts created on their feed but that were collected on Hey. This is why creating a standard for open community feeds onchain is also important to this discussion as described in LIP-10

Don't Forget About Curator Apps!
Another idea to consider would be also accounting for apps where a post was curated to be included in the revenue share. For example, if a post was created on app A, mirrored on app B, and collected on app C, all 3 apps (A, B, and C) contributed to the final sale. In this example the user who mirrored on app B would be eligible for any mirror referral fees assigned by the creator to the post, but app B where the user who mirrored would not receive anything. While this is "less fair" it also might not be technically feasible (@joshstevens19 perhaps you can speak to the technical considerations here).

With a "curator app fee" as I'm calling it, more apps would be incentivized to add curation features and take greater advantage of the mirror referral fee, which remains one of the most innovative and least-understood or utilized features on the protocol. To-date, 923 unique users have driven over $17,000 in mirror referral fees, or over $18 - for mirroring collectible posts on Lens (See screenshot from this Lens Creator Economics dashboard by the SixDegrees team
)

As the supply of content continues to grow, greater curation features beyond just the individual user level, but also at the community/group feed-level and application levels would benefit the entire Lens ecosystem. With more paid open actions coming, curation should not be forgotten as the third leg of the content fly wheel in addition to creation and collection. I can't speak to the technical complexity to account for this additional "mouth to feed" in the rewards framework discussed here, but I can say with confidence that curators are an undervalued type of user and behavior. Lens already addresses this at the user level with the mirror referral fee, but I believe now is the time to consider expanding incentivized curation to apps and community feeds as part of this LIP.

In terms of the fee % itself, I do not have a strong perspective on the overall % or the split between the different stakeholders other than that content creation, curation, and collection apps that all contribute to a sale should be equally incentivized on a share-of-reward basis. Would love to hear what others think!

[rajgottipati]

This LIP proposal presents a well-thought-out approach to addressing the long-term sustainability of the Lens Protocol ecosystem. The introduction of standardized fees for paid actions, such as collecting NFTs and paid follows, offers a promising solution to ensuring a fair distribution of value among the protocol, applications, and content creators.

The motivation behind this proposal is clear and compelling. As the ecosystem evolves, it is crucial to establish a viable revenue model that supports growth while maintaining a user-friendly experience. The proposed fee structure strikes a balance between these objectives, creating a circular economy that benefits all participants.

The specification and rationale section provides a detailed explanation of how the standardized fee mechanism would work in practice. The suggested 4-4-2 model, where 2% of the fee goes to the protocol, 4% to the application where content was created, and 4% to the application where the content was collected, seems like a reasonable starting point. This distribution ensures that the protocol can continue to support its development and provide a gasless experience, while also incentivizing applications to drive user engagement and revenue generation.

Drawing inspiration from successful experiments like Orb's community wallet feature is a smart move, as it demonstrates the potential effectiveness of this approach. Standardizing this practice across the Lens Protocol ecosystem could lead to a more equitable and sustainable environment for creators and applications alike.

Overall, this LIP proposal presents a well-researched and thoughtful solution to a critical challenge facing the Lens Protocol ecosystem. By implementing a standardized fee structure for paid actions, the protocol can foster a balanced and sustainable growth model that benefits all stakeholders. The proposal's emphasis on equitable value distribution and support for both creators and applications is commendable, and I believe it deserves serious consideration by the Lens community.

[EthWarrior]

Thank you @kkpsiren for opening up the discussion. It’s a great time to establish some genesis fees to steer towards a sustainable protocol ecosystem and normalize fees for applications across various actions.

Based on @joshstevens19 categorization, I recommend proceeding with instant actions, as these are quick wins for the community. It seems like the community is leaning towards a 5% protocol fee, which makes sense to bootstrap the protocol treasury. This can be governed by a LIP down the line and should be periodically reviewed. Applications can set any fee above the floor.

The second initiative would be to enable revenue sharing between applications, which would be an even more powerful tool for the Lens community to thrive as a shared social network. It would be great to see a community member building the module. The revenue sharing economics could be standardized or left for the open market (i.e., apps can choose how much they want to share).

I also agree with @bradorbradley on the point of curators. It would be good to include in the module a simple referral system. The easiest implementation would be for the app that creates the content to set the referral fee (or pass it to the user).

Overall, I think time is of the essence, and the community should aim for quick wins now and adjust these models and parameters based on learnings over time.

[chau90]

404 Polygon soon Bonsai

[kozuky]

should to do, many people make lot off acc to gain airdrop or something and when they must pay for action they will think to make many acc

[kyp1994]

This is much needed. Totally agree and support.

[nileshrathore]

This is super powerful! Thanks to everyone for chiming in on the conversation.

As everyone leaning towards a percentage share by protocol, I especially like the idea mentioned by @hjjlxm, I think it's a more sustainable way to go about it.

Examples to draw on include mirror.xyz and zora.co, with a fixed percentage of the revenue allocated to protocol and the rest to creators and other designated recepiants. For the sake of long term development of lens protocol, I think it makes sense to create such a standardization, of course, the exact proportions may need to be fine-tuned.

In general, I believe distribution should receive a larger share. This belief isn't solely because we are building an app, but because I genuinely believe in it. That's why we have been experimenting with the club treasury recently, allocating a higher percentage share to the club treasury from all the collectibles created in the club. We conducted this experiment earlier with the Refraction community in orb v1, but now we are doing it with the Bonsai club. Given our belief that distribution should receive a higher percentage, and considering the club is curating distribution in this case, we aim for the club treasury to receive a larger share, allowing club moderators to decide on its distribution. Currently, in the case of Bonsai, 10% goes to the treasury and 90% to the creator. Since orb is not taking a cut, this arrangement seems fair. However, as the protocol and app begin to take a cut, we need to find a balance that benefits everyone, where the distribution of percentage shares prioritizes club treasury > apps > protocol.

Lastly, I like the idea from @bradorbradley, which we have all overlooked: to also include curation apps where Mirror took place.

[datArtist-io]

This is an amazing proposal and I feel it will lead to a more sustainable future for Lens Protocol, although I have an issue with the 4-4-2 model. It says 2% goes to the protocol, 4% goes to the app where it was created and 4% goes to the app where it was collected. Where will the remaining 90% go?

If you say the creator, I don't think that will be necessary since it's a fee. Can I assume that it's an error?

[linmaizi]

Native tokens can serve as incentives for the entire LENS protocol, which can bring breakthrough growth to LENS

[0xchristinab]

Setting the protocol rewards bucket at 5% establishes a solid initial standard. Seems this is in agreement by all.
This figure can be adjusted in the future pending community consensus and open for discussion for potential increases.

As @stani suggested I support the decision to initially launch without sharing with the mirrorer to avoid complicating the MVP. However, we can revisit this decision later through another LIP but consensus and speed is most important now so we should limit variables.

Question remains on the split between applications and the protocol.

Regarding the allocation between applications and the protocol, we can draw insights from the distribution model of Zora protocol rewards, which allocates as follows:

Create Referral Reward: 0.000111
Mint Referral Reward: 0.000111
Zora Fee: 0.000111
Creator reward: 0.000333
First Minter Reward: 0.000111 (most analogous to the mirrorer in this scenario)

While not directly analogous in structure, in the zora model protocol and distribution (Create Referral Reward and Mint Referral Reward) are allocated equally from the protocol rewards pie.

At this early stage, following this would mean an equal split of the 5% allocation in this manner, with adjustments made as we progress and fine-tune this. But noted some contenders here support a higher allocation at the protocol level.

Seems there are two options here:

Option 1

5% split equally across protocol and applications i.e. 33% of this each

Option 2

5% split 50% protocol and 25% to each application per @imthatcarlos & @ZKJew suggestion

[bigint]

@0xchristinab I'd say Option 1 for sure!

[sasicodes]

Setting the protocol rewards bucket at 5% establishes a solid initial standard. Seems this is in agreement by all. This figure can be adjusted in the future pending community consensus and open for discussion for potential increases.

As @stani suggested I support the decision to initially launch without sharing with the mirrorer to avoid complicating the MVP. However, we can revisit this decision later through another LIP but consensus and speed is most important now so we should limit variables.

Question remains on the split between applications and the protocol.

Regarding the allocation between applications and the protocol, we can draw insights from the distribution model of Zora protocol rewards, which allocates as follows:

Create Referral Reward: 0.000111 Mint Referral Reward: 0.000111 Zora Fee: 0.000111 Creator reward: 0.000333 First Minter Reward: 0.000111 (most analogous to the mirrorer in this scenario)

While not directly analogous in structure, in the zora model protocol and distribution (Create Referral Reward and Mint Referral Reward) are allocated equally from the protocol rewards pie.

At this early stage, following this would mean an equal split of the 5% allocation in this manner, with adjustments made as we progress and fine-tune this. But noted some contenders here support a higher allocation at the protocol level.

Seems there are two options here:

Option 1

5% split equally across protocol and applications i.e. 33% of this each

Option 2

5% split 50% protocol and 25% to each application per @imthatcarlos suggestion

Option 1 - a good split.

[joshstevens19]

Great conversation, so to make things start moving on our side, we are going to do these things ASAP:

1. Enable 5% on all collect modules, follow modules, reference modules, and legacy collection modules. Of course, this will only apply to paid actions.
2. we will enable 5% royalties on 2nd sales on handles and profiles; even though these are guardian ON by default, it's still a nice place to pick up protocol revenue
3. Apps can add their own revenue using the MultiFeeCollectModule attached a percentage if they wish to do so. That will be solely down to the apps and already live on the protocol.

as stated above #43 (comment)

We will be open to giving someone a grant if they want to build a module that reflects revenue on all accounts, i.e., the app it posted on, the app it collected, and the app it mirrored on all get part of the revenue. With that, we can work on a situation where the protocol takes back less to give back more and curates together to produce the best outcome there (this can be proposed with a LIP once the module is written). As modules are open for all to build, we will support the builder who wants to do that.

[bigint]

@joshstevens19 Technically, MultiFeeCollectModule sounds more like a hack; it's always a better idea to have a parameter on all paid collect modules so that apps can pass in the address where they can get the fees like Zora and others do!

It should always be a standard to fix the fees for protocol and apps so apps will not come up with their own fees, as the same happened with permissionless signups.

[nileshrathore]

agree with @bigint! multirecipient is def a hack. would be cool to have a proper way for app protocol split.

also, i'm in favor of option 1 suggested by @0xchristinab: 33% split each for protocol, creator app, and minter app.

seems other builders @bigint and @sasicodes are also in favor of the same!

[joshstevens19]

Yeah, but number 3 can come after IMHO. We can be part of building that module, but protocol fees are taken in the module layer and not in the core protocol itself. I do not think MultiFeeCollectModule is a hack, it is something apps can do now if they wish to put a fee on collects without the main module built.

I agree the future is a way it's all paid and handled in the module itself, which can come in number 3 as stated above but i do not think they have to come together.

let's also note the protocol is paying for 99% of all the sponsored gas transactions so gaining more protocol fees now to allow the protocol to keep sponsoring to the levels it is to offer the incredible UX for everyone is critical. On top the protocol itself is offering all the infra these apps run on for no cost to the apps.

[bigint]

I do not think MultiFeeCollectModule is a hack, it is something apps can do now if they wish to put a fee on collects without the main module built

Let's consider if we using MultiFeeCollectModule

If someone created a post on App - 1 and collect on App - 2

Does this focus only on Creator Referral (for App - 1)? How about Mint Referral fees(for App -2)?

It doesn't make sense to send fees to App - 1 whilst people collecting all from App - 2

Thoughts @nileshrathore @sasicodes 🙇🏼

[kkpsiren]

If we knew where collect and mirror took place, we could even start by having 5% taken by the protocol and retroactively redistributing the fees to the relevant parties (mirror, collect, create and protocol) while starting to build the relevant module on priority. For mirror app there was already the relevant feature in V2 - not sure is implemented? For collect app out of box no idea if origin is evident.

[joshstevens19]

Let's consider if we using MultiFeeCollectModule

If someone created a post on App - 1 and collect on App - 2

Does this focus only on Creator Referral (for App - 1)? How about Mint Referral fees(for App -2)?

It doesn't make sense to send fees to App - 1 whilst people collecting all from App - 2

Thoughts @nileshrathore @sasicodes 🙇🏼

I hear what you are saying about that, which is why a proper payout module is the end game. That said, it was just an approach to capture fees from one side for an app for now. It doesn't make a difference to App 2 if they power it; they lose nothing they have now, but at least apps can capture fees on the posting experience first, and then we build the referrer fee share in that module for the true endgame. As I said, I do not think they have to come together. We can add protocol revenue first and then add app-sharing revenue afterwards.

Let's also note the protocol allows apps with credits to keep 100% of the onboarding money, which is protocol revenue sharing @bigint raised over 80,000$ from protocol revenue to hey; with that in mind, we want to do similar here but be fairer on the protocol as it has gas to pay for and other critical features so making it all come from the protocol revenue is a big factor.

[nileshrathore]

If we knew where collect and mirror took place, we could even start by having 5% taken by the protocol and retroactively redistributing the fees to the relevant parties (mirror, collect, create and protocol) while starting to build the relevant module on priority. For mirror app there was already the relevant feature in V2 - not sure is implemented? For collect app out of box no idea if origin is evident.

i believe this might be good approach while we build proper module!

[imthatcarlos]

If we knew where collect and mirror took place, we could even start by having 5% taken by the protocol and retroactively redistributing the fees to the relevant parties (mirror, collect, create and protocol) while starting to build the relevant module on priority. For mirror app there was already the relevant feature in V2 - not sure is implemented? For collect app out of box no idea if origin is evident.

this is a quick win for now, and totally doable 👍

[joshstevens19]

If we knew where collect and mirror took place, we could even start by having 5% taken by the protocol and retroactively redistributing the fees to the relevant parties (mirror, collect, create and protocol) while starting to build the relevant module on priority. For mirror app there was already the relevant feature in V2 - not sure is implemented? For collect app out of box no idea if origin is evident.

Ok, I think this is a solid idea, so we turn on fees to 5%, let them build up and once the new module is out we can work on retroactively redistributing the fees back to apps who would of gained them or work on a way to make sure the apps get rewarded still from the past protocol fees.

I am very onboard with that

[sasicodes]

If we knew where collect and mirror took place, we could even start by having 5% taken by the protocol and retroactively redistributing the fees to the relevant parties (mirror, collect, create and protocol) while starting to build the relevant module on priority. For mirror app there was already the relevant feature in V2 - not sure is implemented? For collect app out of box no idea if origin is evident.

Ok, I think this is a solid idea, so we turn on fees to 5%, let them build up and once the new module is out we can work on retroactively redistributing the fees back to apps who would of gained them or work on a way to make sure the apps get rewarded still from the past protocol fees.

I am very onboard with that

this sounds like a good approach👌

Do we really need a new module for the fee distribution? instead, is it possible to add a parameter to the existing on-chain mutations? (eg: createReferrer/mirrorReferrer/collectReferrer)

[joshstevens19]

If we knew where collect and mirror took place, we could even start by having 5% taken by the protocol and retroactively redistributing the fees to the relevant parties (mirror, collect, create and protocol) while starting to build the relevant module on priority. For mirror app there was already the relevant feature in V2 - not sure is implemented? For collect app out of box no idea if origin is evident.

Ok, I think this is a solid idea, so we turn on fees to 5%, let them build up and once the new module is out we can work on retroactively redistributing the fees back to apps who would of gained them or work on a way to make sure the apps get rewarded still from the past protocol fees.
I am very onboard with that

this sounds like a good approach👌

Do we really need a new module for the fee distribution? instead, is it possible to add a parameter to the existing on-chain mutations? (eg: createReferrer/mirrorReferrer/collectReferrer)

I think we want to build something a bit more complex than that but we will do some research and think of the best approach which can cover all the cases we want (for example on a mirror we may want to pay out 3 people and take less protocol fee on top sharing with it). We also want this to be forced and not bypassed by anyone.

[joshstevens19]

This has now been executed thanks all - https://polygonscan.com/tx/0x90eb8362c3bb2b645e32b4bd0a3d84dad4880ff678595eeb0511a030aab84a68

[mrsalitre]

I strongly disagree with this.

One of the promises of blockchain is the freedom to build from wherever you come from.

This is like putting walls around the sea; there are many native currencies wrapped in ERC-20. Using only one native currency is denying such a valuable technology.

The importance of being able to build regardless of where you come from is fundamental to the philosophy being carried out, and this only benefits the bonsai team.

I understand that 75% of bonsai is for the community, but I have not seen the community building this currency.

context:

"The introduction of $bonsai, a potential first native Lens token, signals a pivotal moment for the Lens Protocol. It emphasizes the necessity to build a sustainable circular economy that benefits all ecosystem participants. By introducing and standardizing fees for microtransactions, including paid NFT collects and other paid actions such as paid follows, we propose creating an equitable framework that ensures value created within the ecosystem is fairly distributed. This approach aims to foster a balanced and sustainable growth, benefiting applications developed on the protocol and ensuring the longevity and resilience of the ecosystem."