Musings on the fee model

[PaulRBerg]

Context

The goal is to monetize Sablier V2.

Desiderata

1. Add a percentage fee in the core contract, which applies to all streams.
2. The fee can be turned off by the contract administrator.
3. Split the fee with potential third-party front-end developers ("TPFEDs").

Open-Ended Questions

1. Should the fee be a universal percentage that applies to all tokens, or should it be set on a per-token basis?
2. Should the fee be charged in a different token, e.g. USDC?
3. If yes, how do we properly measure the fees based on the deposit amount? Or do we just charge a flat fee in USDC?
4. Should we lazily store the fees in the contracts and make them withdrawable via a bespoke function?

Potential Solution

I call this the Router Allowlist solution.

By default, the contract charges a fee that is cashed in by us. However, if the caller is an allow-listed router, then the fee is split with the router (e.g. we get to keep 20%). The router would be a middleware smart contract that would create the stream on behalf of the end user, and it would be the responsibility of the TPFED to build it (we could recommend them to use something like PRBProxy).

Limitations with this approach are:

• The % that we get to split with all TPFEDs is fixed. We cannot split preferentially based on how much TVL the TPFED brings to Sablier. It's quite important to be able to charge preferentially because as the TPFED grows, they will increasingly have an incentive to move away from Sablier
• We cannot at the same time not charge a fee on our UI and let TPFED charge fees. When the fee is disabled, it is disabled for everyone.

[razgraf]

From a past discussion with one of our users, I discovered some bitterness against a percentage fee. While for stablecoins the expected value of the fee is easy to pre-compute, for volatile assets it gets tricky.

Their rationale was skewed towards the token (DAO token) appreciating in time, which meant paying a potentially huge dollar value in fees. One one hand I totally understand where they are coming from. On the other, the practice is already being used by DEXs, although at a different scale (low fee = low impact to the user, but high volume = big impact for the LP).

This leaves us with another question of fine-tuning the value of the fee and its denomination.

[PaulRBerg]

Yeah, I agree, charging a percentage is not great for governance tokens. I don't think the comparison with DEXes is accurate because in the one case, you are not putting your entire company treasury, whereas in the other, you are (or at least we hope that our users will trust us with their treasuries!).

Charging selectively (what you call "fine-tuning the value") is easy. You just have a mapping like this:

mapping(IERC20 => UD60x18) internal fees;

Whereby the key is an ERC-20 token address, and the value is a PRBMath UD60x18 fixed-point type.

However, what is not easy is changing the nature of the fee (what you call "fine-tuning the denomination") on a per-token basis. I.e. charging USDC for some tokens, and enforcing this as a rule at the smart contract level, not a soft rule at the front-end level.

[andreivladbrg]

I don't think using UD60x18 for storing a percentage is the right choice, would be better to use a much smaller uint.

[razgraf]

Haha gas golfing as a way of life ⛳️

[PaulRBerg]

@andreivladbrg this discussion is not aimed at gas optimizations, but FWIW using UD60x18 would be the right choice:

1. User-defined value types are zero-cost abstractions, i.e. they don't cost any extra gas cast to use.
2. Mapping are dynamic types so there is no tight variable packing like there is in structs. The EVM hashes the key and the value together and stores the value at the resultant hash on disk. There's nothing to gain by using smaller integers here.

[razgraf]

In response to the opening post, as well as the user situation presented above, I propose flipping the "split" and creating a different fee model.

Suggested fee model (A)

The total fee would be computed from two different values:

1. First, a Sablier fee
   • set in the contracts and editable by the core team or later, the Sablier DAO
   • capped to 0.05% or some hard value for safety
2. Second, an Operator fee
   • set as an argument to the create method, by the operator/UI that triggers the transaction
   • capped to 10% or some hard value for safety (this cap could be editable by the core team or later, the DAO)

The first part would create a mechanism of value accrual for Sablier itself. The fee can be set at 0% at the start and later tweaked if in time the product doesn't find other smart ways of monetization. The second part leaves it up to the operator to charge their customers. They could leave the fee at 0% and charge on the side (e.g. subscription service in USDC for their entire tool stack) or set it and earn automatically.

Of course, this could also benefit from an AllowList engine that would waive the first fee for certain stream creators or tokens.

[PaulRBerg]

This is absolutely great. Love the flexibility and optionality that this model provides. Basically porting over Uniswap's fee model to Sablier (the LPs are the Operators in our case).

Re fee distribution - I think we could go a little bit higher, potentially 0.1%. If V2 is as successful as V1 from a safety and reliability point of view, we might be able to capitalize on that.

[razgraf]

We should totally run some simulations but I'm sure we (or the DAO) will figure out the right fee to ask for.

To your comment above, yes, flat percentages does bring up the question of impact of fees when you reduce them to a dollar value. 1% of COMP is far from 1% of FOX. We could either leave it on the account of the fee actually being pretty small anyways, or we could combine this idea with the fees mapping discussed above.

[PaulRBerg]

Flat percentages are a big no, no. If we end up charging a base percentage fee at all, it should be customizable on a per-token basis.

[razgraf]

Other questions:

• Is the fee taken when the stream is created or when the stream if finalized? Delaying until final withdrawal/cancel means ++skin in the game, but asks the fee recipients to be very patient

[PaulRBerg]

It's a good question.

I think we shouldn't charge at withdrawal time, because that would slightly violate the social contract with our users. They would be disincentivized from claiming often (regardless of how small fee is, human psychology would view this as a disincentive), which would gnaw away at the "by-the-second" nature of Sablier.

Then, charging at cancel time is more complicated to implement in practice, because it's an action that can be triggered by both the sender and the recipient. Should they both pay if the cancel, or only one side?

Thus I recommend applying the KISS principle and stick with charging only at creation time. Doing this also has the nice benefit of preventing DoS attacks (I don't know why anyone would want to do this, but still).

[razgraf]

I think we shouldn't charge at withdrawal time, because that would slightly violate the social contract with our users

I think you're working with the incorrect mental model. You've kind of reached the right conclusion but using the wrong formulae haha. We wouldn't show the user a fee they have to pay each time they withdraw.

When the stream is created, we would tell the user they will end up paying

• amount B (the base that's actually streamed) and
• amount F (the fee on top).

For example, when they input USDC 1000 we'll tell them that the total ends up being USDC 1010 to account for $10 in fees. That's it, they never have to think of that fee ever again.

Switching sides to the operator, my question was: when are the operator's funds going to become available. The possibilities were:

1. At the time of stream creation (the createtx assigns $10 to a referral address - our operator)
2. After a fee claim action that can be called only after the stream ends (end date is reached)
3. After a fee claim action, where the amount to be claimed is proportional to the percentage of funds having been streamed
4. Another way

IMO option #1 is the simple approach (KISS) but it doesn't benefit from skin in the game. Option #2 is nice, although has the downside of the operator waiting a loooong time for streams that have very late end dates. Option #3 is too complex. What other options do we have?

[PaulRBerg]

incorrect mental model

I think I was working with the correct model for what I thought we were talking about, which is whether we should charge recipients for withdrawing from streams.

For example, when they input USDC 1000 we'll tell them that the total ends up being USDC 1010

Yes, this is what I also had in mind.

when are the operator's funds going to become available

Ok, now I understand. This is what I meant by "lazily store the fees" in the original post. The answer is "1. At the time of stream creation".

Lazily assign the fees in a mapping:

mapping(address => uint256) internal collectedFees;

Whereby the key is a front-end operator's address and the value is the total amount of fees they collect. The collection happens instantaneously after a stream is corrected, so this solution wouldn't involve "skin in the game" as you say (though btw I don't think that the use of SITG is fitting in this context).

The fact of the matter is that the service of the front-end operator has finished as soon as the stream is created - for what the operator knows, the user might never come back. So it makes sense to assign the fees to the operators at the time of creating the streams.

[razgraf]

This mapping doesn't take into account the fact that one operator may collect fees in different tokens. It would actually be address => address => uint256 as in owner => token => amount.

[PaulRBerg]

That's right.

[PaulRBerg]

There's one important aspect we have to take into account before settling upon an implementation of any fee model - the legal implications of enabling a smart contract protocol fee.

Two of the recurring themes in my conversations with the lawyers and insurers I talked to about Sablier have been:

1. User identity and country of origin.
2. Split of revenue by geography.

My understanding is that a UK company has a legal responsibility to not accept revenues from some jurisdictions, and take extra caution when working with others.

Obviously, blockchains blow the Overton window wide open when it comes to user geography, so I don't know how we can cater for this legal requirement while the Sablier protocol is managed by a UK private limited company (it'd be a different story with a DAO).

KYC at the front-end level (which is completely unacceptable due to other businesses reasons, but assuming we would do it) wouldn't cut it, because there would still be the protocol fee that would earn us fees whenever some blockchain user interacts with the smart contract via any other possible way.

Therefore, this is what I suggest doing before making any final decision on this head:

1. Reach a landing internally on our desired fee model, but also agree upon on a backup that has no base protocol fee (only a front-end operator fee).
2. Prepare a short explainer in English for how the V2 fee models would work.
3. Share the model with SM and engage them to perform a reg analysis on it.

[razgraf]

Suggestion of a 4th point: Leave the fee at 0% until the DAO takes over and activates it to any other value betwen 0% and a hard-coded safety threshold. Sablier Labs should remain impartial regarding earnings while the protocol is under its control.

[PaulRBerg]

Could you restate the last sentence in other words? Sorry, I didn't get what you meant to say there.

Also I don't think this is a 4th point, it's more like a point that we should make in the fee model explainer, i.e. "we may or may not activate the fee, and we ask you SM to advise us on the consequences in both cases".

[razgraf]

I'm saying, for legal and accounting simplicity, we should not charge anything while the protocol is in the hands of the company and not the DAO. The protocol fee feature would be coded but set to 0% during that period.

But that's fair, this point is merely anticipating what our legal advisors would say anyway.

[PaulRBerg]

Thanks for explaining.

My point is, the mere optionality that Sablier Labs has over enabling or disabling the fee could bear legal implications, which is why I would prefer SM to comment on the optionality itself, and on the cases when the fee is zero and the fee is not zero, regardless of what we will actually choose to do.

[maxdesalle]

Some quick thoughts:

• If applied to all tokens, it shouldn't be paid in the token itself, and it should probably be a flat fee. I would imagine a new project launching a governance wouldn't want to give up a significant share of their own token just to pay for vesting. And it's obviously in our best interest to get a a fee model set up which works for every token out there, given a significant share of our users use Sablier to stream their own token instead of a stablecoin.

• It would probably make more sense to charge ETH instead of USDC, in that case, as the former is needed for every transaction which the latter isn't. Every Sablier user must have ETH in their wallet, but they don't necessarily must have USDC in order to use Ethereum.

• Flat fee is the way to go IMO. We will get very quickly outcompeted if we take the route of charging a percentage fee.

[PaulRBerg]

Thanks Max for chiming in to share your thoughts.

Generally, I am in agreement with you, i.e. we should indeed avoid a one-size-fits-all pricing structure, but the devil is in the details. With @razgraf's proposal to set up a two-pronged fee model, where we have a per-token Sablier fee and a per-token Operator fee, we would be able to enact either a percentage fee or a flat fee, depending upon the token and/ or the client.

I don't think we should rule out percentage fees from the get-go. They might be a good solution in some cases, e.g. stablecoin streams.

Interesting idea to charge ETH! though I think this would be something like "Pay a flat fee? Choose either ETH or USDC".

[PaulRBerg]

Locking, since after merging #220, we have settled the API for the protocol and the operator fees.