Sharing revenues with the "platform"

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”.
3 Likes

To get things right. The “platform” here refers to “Unlock DAO Treasury” or what?

Ha, not quite @Foskaay .

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.

2 Likes

@julien thanks I understand better now.

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.

3 Likes

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.

1 Like

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…

1 Like

Ok

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

Actually, our requirement was to:

  • ensure lock managers are able to fully manage their locks
  • ensure lock managers are not able to remove the platform fee from locks created.

Our solution allows this even if lock managers are actually not lock owners as we provide a specific ABI to manage locks through our facade.

I will share more on this as soon as we finalize our code and we go live with our public contracts.

Honestly I am not sure the protocol needs to set limits. Each lock manager should be free to decide on their specific lock.

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.

2 Likes

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.

needs more thought for sure…

2 Likes

Hmmm.

For the refund. That is truely screwed indeed. Because lock manager did not receive 100% full payment. Its difficult to have them refund 100%.

There are multiple ways to handle that. One could you our onKeyCancelledHook to get the platform to make a partial refund to.

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.

What are everyone’s thoughts on this?

1 Like

@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?

1 Like

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.sol after 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.

2 Likes

@Miro Thanks for the response.

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 :slight_smile:

2 Likes

That’s cool! Thanks!