In its current form, the protocol does not have a clear mechanism to âshareâ revenues with the platform. There are multiple ways to achieve this, but none of them feels very obvious. I wanted to start a thread after @mankins raised that issue during our latest Office Hours.
We currently have these approaches:
The platform could require the lock manager to change the beneficiary to be some kind of smart contract (multisig, split⌠etc) where the revenues can then be shared between the âoriginalâ beneficiary and the platform.
The platform could be an âapprovedâ beneficiary. The lock manager could approve a âfixedâ amount for the platform to withdraw from the lock
I am not sure these are good enough.
Iâd love to hear ideas fro the community! For example, I want to propose an approach where the lock could define a âreferrerâ %age fee, similar to our gasRefund fee works where the âreferrerâ would automatically receive a share of the proceeds paid by the prospective member.
Here are some of the requirements I can think of:
Maintain the cross platform aspect: we should expect a given lock to sell its keys on multiple platforms at conce
Be permissionless: each lock could decide of its own settings (including none!) and each platform should decide if these settings are âacceptableâ.
The example is this: imagine I am a youtubber and I post my content on Youtube. Youtube will show a lock, but would want to take a cut on the memberships I am selling. This is what this is about: how can we implement that âcutâ at the protocol level.
I think if there must be a fee at the protocol level it should be 1% max or less
Why?
The protocol needs to stay competitive and ensure it implements the fee if necessary for it survival (if not, I donât recommend it to stay competitive for web3 future ahead).
There also needs to be a comparison of current payment processor fees integrated into the protocol like a Card payment processor to ensure potential protocol users are not sold out to competing protocols due to fees.
This has also been discussed on discord with @julien and in https://outwave.io, we decided to solve this by creating a facade contract that will forward TX to Unlock and Public Lock. Lock Managers will always interact with Unlock and their PublicLock smart contracts through our facade, which is:
the only owner of the Public Locks
implements ILockKeyPurchaseHook
Every time a new public lock is created using the âfacade contractâ, setEventHooks sets the address of the facade contract
IPublicLock(address).setEventHooks(
address(this), // here we set the facade contract address
....);
By implementing the onKeyPurchase in the contract facade, we are able to immediately withdraw a % fee, for each key purchase.
Hope the following diagrams help understand better this pattern.
You make great points! To be clear, I donât think the protocol should set the %age itself, but have a mechanism for lock manager to set a %age of fee theyâre willing to pay to platforms. The default would be 0 but I can imagine a scenario in which a platform might say âwe will let you creator, use your lock on our platform, but only if we get x% of the revenues you makeâ. The creator can then decide if they agree to that or not.
Yes this is a good approach too! If I remember correctly there was more than just the âbeneficiaryâ that you wanted to make sure could not be abused, correct?
I think the hook could indeed be worth exploringâŚ
what about if the protocol add the code to make lock creator set the amount desired as you said but it could have a minimum of like 0.1% (this makes it effective or most may likely ignore it altogether making it of no use adding it in the first place), maximum of about 1%(this ensure creators with less tech knowhow would not mistakenly set higher percent unwillingly when setting up the lock).
So, the lock manager has the free will to decide what % to put in between 0.1%-1% without feeling compelled inbetween
As I have a few more discussions with more folks, I realize an important aspect is to let the lock manager decide what platform they want to share revenues with, and allow them to set the % for each of them.
So for now, here is a proposal I would like to make: lock managers should be able to set a fee (between 0 and 100%) that a specific referrer would receive on each purchase transaction for which the referrer is set and matches.
The fee creates challenges around cancellation and refunds. Indeed, the lock night not be able to refund the fee paid by the consumer, since the platform has taken a fee. I believe it is not strictly a vulnerability because the lock manager could then âblockâ the platform from collecting fees, but it will be important to make sure lock managers, as well as members realize this.
thereâs an interesting perspective shift here that iâm trying to understand better. in web2, the platform is the center of the universe, and both creators and fans are locked into whatever rules and terms the platform states.
riffing on @julienâs post upthread, is there a model where the creator (aka lock manager) is the center of the universe, and the web2 platform is (effectively) acting as a lead generation mechanism for the creator. with that framing, the creator could give a %age to the platform â basically, an affiliate fee (which i guess is the platform acting as the referrer! )â to the platform for referring a prospective member who then joins the creatorâs community. with this model, the creatorâs community could span multiple platforms, and each platform would be compensated by a percentage when they referred members who joined the creatorâs membership.
After a bit more thinking here is where we are currently lending in terms of approach. a lock manager should be able to set a referrer fee on their lock for a specific referrer address. This lets them have multiple âlevelsâ of fees, based on the platform, but also protects them from âabuseâ where someone who wants to purchase a membership would trigger the purchase manually and put their address in the referrer to get a discountâŚ
Once this is set, any call to purchase (or extend for renewals`) where the referrer is set to one of the addresses for which there is a referrerFee would result in the platform receiving a fee for that specific membership.
@Miro Do you mind sharing the code for the facade contract youâve built?
Weâre trying to implement something similar and would be really helpful to have a look at your contracts if theyâre verified or open source
Quick question that I had was, how exactly do you make use of the onKeyPurchase hook? I see that the actual ERC20 transfer along with the msg.value check in purchase() happens only after the hook call. So how could the beneficiary or lock manager facade / hook contract actually withdraw the ERC20 tokens during the hook call? Are you using only ETH / native tokens as the key price?
Unfortunately, at the moment we cannot share the code, in the current stage of the development. Itâs something that we pursue, but it will be done once our project has been finalized. Iâm sorry for this.
Related to the ERC20, we have the same problem, it can be solved by withdrawing only after the second purchase.
A better alternative would be to:
Implement in ILockKeyPurchaseHook a function onKeyPurchased. (please note the past tense)
Add the call to the interface in the purchase function in PublicLock.solafter the token.transferFrom(msg.sender, address(this), totalPriceToPay);
If this makes sense to @julien and he agrees, I could develop it and submit a pull request.
We are currently targeting public lock v10, but it should not be a big deal to update to the latest changes, as I see on the master branch there is version 11 (unlock/MixinLockCore.sol at master ¡ unlock-protocol/unlock ¡ GitHub) which i donât know if has been yet released or not.
The only problem that I can see in this, is related to the public lock contract being too big, even for this small change.
Another question I had: Having a facade contract that owns the Locks would also prohibit the actual owners from editing the collection on OpenSea, to like set the royalties, perhaps?
Actually it should not prevent that. The lock as a setOwner function that just sets the owner value on the contract to be any address. It can be called by any lock manager and that owner does not have any real permission on the contract. We explicitly created it for OpenSea
