Should we implement the fallback function?

[PaulRBerg]

This is only needed for responding to ETH deposits.

See:

• What is the receive keyword in solidity?
• payable() function In solidity

[razgraf]

We could just make the receive() variant throw. For the classic fallback we're left with calls to nonexistent methods.

Apart from saving funds from a user that sends utility tokens (ERC20s are still lost), could it help us in any other way? I don't think we're taking any security risks with it, as long as the protocol doesn't even handle utility assets at the core. Thoughts?

[PaulRBerg]

We could just make the receive() variant throw.

Good idea.

Apart from saving funds from a user that sends utility tokens (ERC20s are still lost), could it help us in any other way?

I'm sorry, I don't follow this. We can't save funds for users that send utility tokens - there's no "on receipt" hook for ERC-20 transfers, so there's no way to prevent users from accidentally sending tokens to the Sablier contract.

[PaulRBerg]

Locking. There is no need to add unneeded logic in the contract. Users who accidentally send ETH to our contracts will just lose their ETH forever - just like it would happen with any other contract that doesn't accept ETH deposits.