[LIP-6] Create Harmonizing credited onboarding #42
Conversation
|
|
Great proposal @EzR3aL (and congrats on your first LIP). I would definitely agree that harmonization would be great and setting to the same price as the main flow would work well (the main flow would down the line be deprecated when there are enough apps doing onboarding). Agree also on the 50% fee split between the apps and the protocol, especially for the success on Lens Protocol, its critical to have a strong balance sheet to support the ecosystem. This parameter can also be managed via LIP as the experimentation progresses. For the implementation, something simple, easy and clean would be great to make it as easy as possible to integrate to any app. |
|
that's great for Dev |
|
This proposal suggests a crucial step towards standardizing onboarding processes across Lens apps, ensuring fairness and reducing spam. Implementing a uniform fee and introducing fee-sharing mechanisms can incentivize ecosystem growth and app contributions. As a developer, I see this as a thoughtful initiative to streamline user experiences and foster a sustainable Lens ecosystem. Looking forward to constructive discussions on this proposal. |
|
I agree with this LIP. It must be the same prices due to a few factors, which I explained here - https://hey.xyz/posts/0x06-0x01f4-DA-710ab489 A 50% split is a very fair split for applications and protocol, this allows the protocol to share revenue but also make it so it can stand on its own 2 feet in the long run. As Stani has said these parameters can be changed through LIPs easy enough. |
Harmonizing credited onboarding to a standard of 8 Matic across Lens apps with fee sharing is a good idea. applications will be able to generate income which will push them to attract more users. |
|
As im not that into the tech needed behind this, I would really appreciate seeing someone proposing a simple mechanism that all dapps can implement and that automatically splits revenue to the Lens treasury wallet and then also to the app specific treasury/wallet. And I do agree that through LIPs we should be able to change parameter in the future, add new assets that can be used to buy a profile. |
|
I agree that if the profile/handle creation is permissionless and open-for-all, then it's better for all prices come to some equilibrium, otherwise that creates arbitrage opportunities for actors to buy on the cheapest app and then sell it on NFT marketplaces with an impression of selling lower than the "official" protocol 8 MATIC floor. Which is suboptimal. These effects can be mitigated by either:
Both solutions can work fine, and even can work simultaneously. The 8 MATIC fee was initially introduced to prevent sybil attacks, spam attacks and bot attacks. This number is pretty low already (but seems that it is working), but making it even lower (without handling spam/bot/sybil protections) might create more unwanted activity. 50% fee sounds okay, given that all apps receive creation-credits for free. |
|
Great |
|
good |
|
I think it would be great if 100 gas could be free |
|
I'm generally with the proposal. While It's mainly up to the apps that build upon Lens protocol on which way they would use to attract and retain their new users. Some may prefer to have a lower entry fee a good start for marketing to retain users. So it's better give them the right to make some discounts on the harmonized mint price. |
|
I appreciate the effort to streamline the onboarding process across the Lens ecosystem as outlined in LIP-6, "Harmonizing Credited Onboarding," authored by EzR3aL. However, I have significant reservations about the proposed standardized fee of 8 MATIC for creating a profile on all Lens applications, which I believe merits reconsideration for the following reasons: Incentive Structure: While the proposal includes a fee-sharing mechanism to reward apps that facilitate user onboarding, the high upfront cost could significantly reduce the number of users willing to join the platform, thus diminishing the overall effectiveness of this incentive. Economic Feasibility for Business: The financial burden of onboarding 1 million users at a cost of 8 million MATIC (or 10 USD per transaction) is prohibitively expensive. This cost structure is unsustainable for businesses operating within the Lens ecosystem and could potentially stifle growth and innovation. An essential and potential strength of Lens is its ability to offer free and easy access, which this proposal directly undermines. Bot and Spam Mitigation: While the motivation behind the fee is to deter bots and spam, it's imperative to explore more innovative and less financially burdensome solutions. Such solutions, which are relatively simple to implement, for example, on mobile devices, are already in use in apps like Orb. Additionally, the strength of blockchain and decentralized networks lies in their ability to leverage technology to solve such issues without imposing prohibitive entry costs on users or businesses. One way to mitigate bots and unwanted activity is to transition from static sponsorship to more dynamic methods, such as using profile scores or some transparent system. Protocol and App Revenue: Revenue should be generated from activities such as paid collects, open actions, or something novel rather than charging for entry. Exploration currently drives new user entry. Why hinder it? Revenue could adopt more radical approaches, such as eliminating sponsorship completely or taking a percentage of gas fees, but entry should be accessible to everyone, with onboarding restrictions implemented through means other than financial barriers. In light of these concerns, I recommend a reevaluation of the proposed fee structure. In summary, alternative approaches, such as dynamic scaling of fees based on an application's contribution to the ecosystem or more innovative bot-detection mechanisms that do not impose financial barriers, should be considered. Our goal should be to enhance accessibility and foster a vibrant, growing community within the Lens ecosystem, without imposing undue financial burdens on users or developers. Thank you for considering these points. I look forward to a collaborative effort in refining this proposal to better suit the needs of all stakeholders within the Lens ecosystem. |
|
This makes a lot of sense imo. Implementing a uniform fee across all Lens apps and introducing a fee-sharing mechanism would be a win-win scenario for the Lens ecosystem at large. A 50/50 split of the onboarding fee seems like a good move. Being able to continuously add to the Lens treasury will only expand opportunities for builders. Thanks for putting this up @EzR3aL |
|
Introducing a fee for new account creation not only serves as a solution to combat bots and sybils but also presents an opportunity to establish a sustainable revenue stream for both the protocol and associated applications. In assessing this proposal, two key factors come into play: A) Protocol Adoption Implementing a nominal fee, such as 8 MATIC, holds promise as a viable tradeoff. However, optimizing this approach further entails the development of a dynamic algorithm. This algorithm would dynamically determine the fee based on the interplay between protocol adoption (A) and the effectiveness of bot and sybil mitigation efforts (B). Such a dynamic pricing model ensures a balance between discouraging malicious activity and fostering organic growth within the ecosystem. |
|
Logical step. Generally agree. |
|
同意應用程式和協議之間 50% 的費用分成，特別是對於 Lens Protocol 的成功而言，擁有強大的資產負債表來支持生態系統至關重要。 隨著實驗的進行，此參數也可以透過 LIP 進行管理。 |
|
nice |
|
66666666666666666 |
|
I think it would be great if 100 gas could be free |
|
fixed price in usd would be good as matic price would be volatile |
4.20$ |
|
So after a few days on letting the community discussing this LIP I wanted to give a quick summary:
Now we would need some technical instructions to know how to implement this. We would need some kind of module that every app integrates that automatically splits revenue and (if decided) dynamically tells us how much Matic has to be paid if we want the price to be fixed at 10$, regardless of Matic price. Did if forgot something? If yes, please feel free to comment. |
|
Apps are the one acquiring and spending to acquire users. They should keep soverignty over their onboarding and their buisness model. Electricity didn't become popular because it was safer or better then gas or candle light.. But it because it eventually became CHEAPER, EASIER and POPULAR enough for builders to invent actual products like microwaves and vaccum cleaners. Lens Profiles are connectors. We need centralized policy and sophisticated tools to onboard and filter for humans. |
|
I disagree with this proposal. Detriment to ScalingThis proposal would limit methods that apps can use to onboard users, which is opposed to the objective of scaling the Lens social graph. I believe that the Lens community should always move in the direction of making access to the protocol cheaper and eventually free. I advocated in LIP-5 (and still believe) that network gas fees can sufficiently deter spam and should be the only requirement to mint a profile/handle. Sustainable RevenueThe main justification for this proposal is to benefit the protocol treasury. I believe that a protocol treasury can capture more value in the long-term by making decisions to lower barriers to entry, promote exponential growth, and capture value from sustainable usage rather than exclusivity. Not HarmonizingThis is how credit onboarding is currently implemented. To enforce this proposal onchain, all profile/handle minting would need to be migrated to a new smart contract that requires all credit functions to pay 8 MATIC, but since 50% of the fee would go back to applications, the effective price is now 4 MATIC. This would not harmonize onboarding, it would simply eliminate any form of app onboarding besides onchain payment, and shift the lowest price that apps can realistically charge from FREE -> 4 MATIC. If fees are required for all credit onboarding, this would also limit the potential for the Lens community to adopt new LIPs with criteria for free onboarding in the future such as granting credits to a smart contract that allows minting from onchain verification (invites, ENS holders, etc). tl;drI think that credit onboarding should remain unchanged. I believe that the primary focus of the Lens ecosystem should be on scaling usage of the protocol, and revenue should be a secondary consideration that is only justified if it can sustainably scale with the protocol. |
|
The motivation behind the PR is good, aiming to mitigate bot activity and introduce a new revenue source. However, it hampers the overall growth of products and their strategic planning. There are alternative methods to combat bot behavior, one of them we've implemented at orb: allowing only one lens profile per real device. This approach makes it challenging for bots; to create 100 profiles, a user would need 100 real devices. For revenue, the initial focus should be on onboarding users and then on value creation, for instance, by offering more features like minting, instead of charging upfront fees. Such charges significantly deter user engagement. Moreover, only highly motivated crypto users might be willing to bear these costs, limiting our ability to reach beyond the small web3 community. In developing countries, these costs are even more prohibitive. To illustrate, while a Spotify family plan costs $17 per month in the USA, the same plan is priced at $2 in India, yet a majority still opt not to subscribe. Covering this cost is not sustainable for businesses; for instance, if I aim to onboard 1M users to my app, paying $10M just for profile creation is infeasible. It's crucial to consider whether our non-crypto friends would be willing to pay such fees for onboarding. |
|
I appreciate the intention behind the proposal to standardize the onboarding fee across the Lens ecosystem, aiming for uniformity and equity. However, I'm afraid I have to disagree with the suggested 50/50 fee-sharing mechanism for several reasons. Firstly, it's crucial to recognize that the revenue generated through the onboarding process significantly contributes to the Lens protocol's sustainability and development. According to data from Lenscan (https://lenscan.io/revenue/app), the revenue accrued by lens.xyz substantially supports the entire ecosystem's growth. Moreover, the onboarding process is predominantly facilitated by the individual frontends like Hey and Tape, each incurring unique operational and developmental costs. This effort is not just about integrating with Lens but also about providing users with a seamless, enriched experience, which is pivotal for user retention and ecosystem growth. Given these considerations, I would suggest that the entirety of the onboarding fee be allocated to the frontends conducting the onboarding. This approach would not only recognize and reward the efforts of these platforms in expanding the ecosystem but also ensure that they have the necessary resources to continue innovating and enhancing user experience. It's also important to note that the Lens protocol already benefits from a 5% revenue share from paid collects, a revenue stream that frontends do not currently have it. This existing revenue model underscores the protocol's ability to sustain and grow without needing to split the onboarding fees with the frontends. Allocating the full revenue to the frontends would encourage more applications to join and contribute to the Lens ecosystem, thereby fostering diversity, innovation, and ultimately, a richer user experience. I believe that by supporting the frontends in this manner, we indirectly contribute to the sustainability and prosperity of the Lens ecosystem as a whole. |
agree! resonates with me. |
|
Great proposal and would indeed incentivise devs to onboard more users. I think the price should be set in USDC so that the integration burden and fees involved with fiat systems are mitigated. Smart contracts could then do the split and it directs the cost of onramping to the user. What are the timelines on deciding on this? |
title: LIP-6 Harmonizing credited onboarding
description: Harmonizing credited onboarding to a standard of 8 Matic across Lens apps with fee sharing
author: EzR3aL @DeFi_EzR3aL
status: Draft
type: Protocol
created: 2024-03-04
Abstract
With the recent LIP5 Lens went permissionless and many Apps allowed user to join the ecosystem of Lens. To reduce bots and spamming a one time payment is needed to create a profile.
Motivation
The credited onboarding process has been implemented to mitigate the risk of potential bot spamming within the Lens platform. Presently, the prescribed fee by Lens stands at 8 Matic or 10 USD for transactions conducted in fiat currency (refer to https://docs.lens.xyz/docs/onboarding#credited-onboarding).
It is worth noting that various applications, such as Hey and Tape, impose distinct fees for their respective onboarding processes. This divergence in fee structures underscores the individualized approaches adopted by different applications within the ecosystem.
Specification & Rationale
In order to maintain uniformity and equitable onboarding practices across the entire ecosystem, I propose a standardized fee for all applications built on the Lens platform. Specifically, I recommend that each app charges a uniform fee of 8 MATIC or 10 USD for fiat payments during the onboarding process.
To foster the growth of the ecosystem and acknowledge the contributions of apps that consistently facilitate user onboarding, I further suggest implementing a fee-sharing mechanism.
Drawing inspiration from the approach outlined in Stanis's post (referenced here: https://hey.xyz/posts/0x05-0x221e-DA-8c3f8531), I propose a 50/50 split of the onboarding fee. Consequently, 50% of the fee would be directed towards the Lens treasury, supporting the broader sustainability of the platform, while the remaining 50% would be allocated to a wallet specified by the respective app.
This approach aims to incentivize and reward applications that actively contribute to the growth and engagement of users within the Lens ecosystem.
Copyright
Copyright and related rights waived via CC0.