Should we support both Permit2 and traditional ERC-20 approvals?

[andreivladbrg]

During our last call, we discussed using Permit2 and we pretty much agreed that it would be a good option. However, I have a question: are we planning to require all users to approve the Permit2 contract, or will we provide an option to approve our contracts? A user might not trust Permit2.

We could implement two different versions of the create function: create and permit2Create. Although, this may confuse some users and require additional information on our end.

For maximum clarity this pattern would be used only for the target contract, the core does not integrate Permit2:
user --> proxy --> target --> core

Regarding using Permit2: it offers a more user-friendly experience in the DeFi ecosystem (e.g. allowing users to create streams without needing to approve if they've already done that on other platform), there is also the risk of potential loss if the Permit2 contract were to be hacked. It's worth noting that Uniswap has not experienced any such incidents in the past.

Check this link for a great explanation.

What do you guys say?

[PaulRBerg]

I am not sufficiently familiar with the flow of the Permit2 system to make an educated decision about this. However, instinctively, I would say that if we want to use Permit2 (which I think we do), we should start implementing only its approval mechanism. Then, if and when we realize that we need or want traditional approvals, we can implement them at the appropriate time.

Worth noting that this may bear implications for the front-end implementation - cc @razgraf and @gavriliumircea; you might have to change the ERC-20 approval system that you guys have already implemented and ask the user to sign permit messages.

Side note - as I said on the call yesterday, we should think of the target contracts as a special type of Solidity system that can be easily swapped and upgraded (unlike the core contracts). This is, in fact, one of the significant advantages of the proxy approach.

[andreivladbrg]

I have just found out that the Permit2 contract has only been deployed on the Ethereum, Optimism, Arbitrum, Polygon, and Celo chains. Therefore, if we intend to deploy our v2 contracts on other chains, we must support both Permit2 and traditional ERC-20 approvals.

[PaulRBerg]

Multicall3 is deployed on 50+ networks.

I suggest we use only Multicall v3.

[razgraf]

We are already using M3 through wagmi.
Doesn't mean we shouldn't explicitly make sure the deployment is where we wanna go.

Ronin for example is not on that list. Same will be true for any new chain we pick that's in beta. Point is: we need to include it in the checklist 👍

[PaulRBerg]

We are already using M3 through wagmi.

Ok so we don't need M2, do we?

Doesn't mean we shouldn't explicitly make sure the deployment is where we wanna go.

We just did, didn't we?

Ronin for example is not on that list.

I will open a discussion about this; I'm quite strongly opposed to supporting Ronin in V2.

Same will be true for any new chain we pick that's in beta

There shouldn't be many if we pick up development for V3 shortly after launching airstreams.

We should have a discussion about this at some point (not now).

We need to include it in the checklist

Yep, but FWIW I'm in close touch with the creator of M3 (Matt Solomon) so deploying to any chain unsupported yet won't take long.

[razgraf]

Lots of good things to go over in the thread above but all beside the point I was trying to make. Simply put, Multicall is an external dependency which makes it important that we check for it especially in less popular ecosystems (as opposed to taking it for granted).

Just like The Graph, RPC nodes, PRB-Proxy etc.

---

• No M2.
• I didn't get the comment
• Sure, we should figure out a list of chains we want to deploy on (I think you've recently inquired about that on Slack as well)
• Ronin was just an example, replace it with Base testnet 2+ days ago when M3 wasn't deployed there
• I somewhat disagree, especially with all the upcoming zkEVM chains (and their ecosystems). Sablier should be the go-to streaming solution on every chain (until V3 comes). However, I do believe that deployments requiring a lot of effort (e.g. non-metamask like Ronin on non-EVM) are entitled to a separate discussion based on opportunity cost vs. development cost.
• Good to know!

[PaulRBerg]

Multicall is an external dependency which makes it important that we check for it especially in less popular ecosystems (as opposed to taking it for granted).

I responded to this when I said "There shouldn't be many if we pick up development for V3 shortly after launching airstreams"

Basically: YAGNI. Let's just focus on getting shit done with the current chains we plan to deploy to, and then we can plan some more.

No M2

Good.

I didn't get the comment

YAGNI is what I meant. Let's plan a little bit less.

we should figure out a list of chains we want to deploy on

We have it:

https://github.com/sablierhq/v2-core/blob/7482e0b1cf417d9736109331d50a084740dbe615/foundry.toml#L82-L92

We will add Base when the infra is up, and call it a day.

Sablier should be the go-to streaming solution on every chain (until V3 comes)

V3 may never come if we want Sablier V2 to be the "go-to streaming solution on every chain" (that'd be lockup streaming, but anyway).

There's no humanly possible way to do the above while also focusing on V3 (with a team of five).

[PaulRBerg]

Closing, as we decided to implement only Permit2 for the time being.