Open discussion about staking

[PaulRBerg]

We get this feature request a lot. How can we enable support for staking streams?

[PaulRBerg]

Needed by Sam from SparkDAO:

[PaulRBerg]

One more request from 5ive:

[smol-ninja]

The objective, as I understand it, is to allow the staking of tokens in the stream which is the sum of withdrawableAmountOf and refundableAmountOf.

IMO the prerequisite for this is that stream must be transferrable and non-cancelable. I've crafted a basic implementation that accomplishes this:

See code snippet

contract StakingRewards {
    ISablierV2Lockup public lockup;

    uint256 public rewardRatePerToken;
    address public stakingAsset;
    address public rewardToken;

    mapping(address => uint256) private _lastTimeRewardUpdated;
    mapping(address => uint256[]) private _streamIds;
    mapping(address => uint256) private _rewards;

    function stake(uint256 streamId) external {
        require(stakingAsset == lockup.getAsset(streamId), "wrong asset");

        // update previous rewards
        _updateRewards(msg.sender);

        // transfer stream to this contract requires it to be transferrable and non-cancelable
        lockup.transferFrom(msg.sender, address(this), streamId);

        // update ownership
        _streamIds[msg.sender].push(streamId);
    }

    function _updateRewards(address account) internal {
        uint256 ids = _streamIds[account];
        uint256 rewardPeriod = block.timestamp - _lastTimeRewardUpdated[account];
        _lastTimeRewardUpdated[account] = block.timestamp;

        // calculate rewards for each stream
        for (uint256 i; i < ids.length; ++i) {
            uint256 tokensInLockup = lockup.withdrawableAmountOf(ids[i]) + lockup.refundableAmountOf(ids[i]);
            _rewards[account] += rewardRatePerToken * tokensInLockup * rewardPeriod;
        }
    }

    function unstake(uint256 streamId) external {
        require(lockup.getRecipient(streamId) == address(this), "not owned");

        // update previous rewards
        _updateRewards(msg.sender);

        // transfer stream back to user
        lockup.transferFrom(address(this), msg.sender, streamId);

        // update array
        _removeFromStreamArray(msg.sender, streamId);
    }

    function claimAllRewards() external {
        // Update previous rewards
        _updateRewards(msg.sender);

        // Set rewards to zero
        uint256 rewards = _rewards[msg.sender];
        _rewards[msg.sender] = 0;

        // Transfer rewards
        rewardToken.transfer(msg.sender, rewards);
    }
}

We can provide a framework or example code to our users to enable staking.

[PaulRBerg]

Thanks, Shub, for sharing your thoughts. That is a good point about the transferability and cancelability requirements.

We can provide a framework or example code to our users to enable staking.

Yeah, that seems like the way to go here.

But the more I think about this feature, the more I consider that it would make most sense to slate it for the V3 version of SablierLockup.

[smol-ninja]

I don't agree that it would make more sense to add a staking feature in SablierLockup. Staking is a utility that should be separated from the core logic of lockup contracts which is token distribution/streaming. Even in other protocols, staking is designed separately from the core contracts.

Adding staking to SablierLockup also means that the ownership of NFTs will be handed to the Lockup contract itself which can get more complex than keeping it separate.

[maxdesalle]

Félix from Salad asked if we knew any protocols that allow you to lock up an NFT for a certain period of time, a sort of end-to-end staking system for Sablier NFTs. They wanted this to have the ability to airdrop token holders that are staking their NFT.

[PaulRBerg]

Looks like there do exist some tools for this. See my cast.

• Distributed Gallery
• Uniswap V3 Staker

[PaulRBerg]

One more request from VitaDAO:

[andreivladbrg]

A question regarding the request.

Who is the actor that wants to stake the tokens? Is it the sender, for example, a protocol that distributes its treasury to the team/members, etc., or is it the recipients (staking in advance), who will supposedly own the assets by the end of the stream?

[maxdesalle]

Usually it's for recipients so they can stake the stream NFT and participate in governance or earn staking rewards with the tokens that are still being vested (meaning the tokens that are still in the stream).

[smol-ninja]

For maximum clarity cc @maxdesalle

• Sender creates streams of tokens for recipients
• Recipients stake Sablier NFT
• Based on staking, they become eligible to claim staking rewards
• Recipients should also be able to take part in governance using the stream NFT (if it's not staked or even if it is staked?? I haven't seen a use case where staked ERC20 tokens are allowed in governance)

Is this what is to be expected?

[PaulRBerg]

@smol-ninja that's an accurate description.

Governance is an optional feature, though. Many users are interested in purely the staking aspect - dropping tokens rewards in exchange for staking the assets being vested.

[smol-ninja]

Issue:

• Add a staking template for Sablier NFTs sablier-v2-integration-template#8

[smol-ninja]

I've spent a lot of time working on this as well as debating with Andrei. And I came up with the following conclusion:

Staking in itself is a complex feature and many design decisions can vary from user to user. Take the following questions:

1. How are rewards deposited into the staking contract? Everyone has a different approach. Aevo does it through Merkle Tree, Synthetix does it weekly and some projects have fixed reward amounts for a longer period, some projects even have fixed APY and some projects use a different token for rewards.
2. What admin functions should exist in the contract? Should admin be allowed to withdraw surplus effectively changing the APY? How frequently the APY can be changed?
3. Should cancelable streams should be allowed?
4. What happens after staking ends and to unclaimed funds?
   .. and so on.

We can provide a full deployment-ready contract but it would not solve for all the users. Another problem with writing a production-ready template is that it would make it hard for integrators to understand the core logic of the contract.

---

Our objective should be to provide the basic minimum implementation to make them understand how Sablier NFTs can be used for staking. There are a few important questions:

1. How to get tokens locked in a stream? That information is useful for them to calculate staking rewards for each user.
2. How to handle cancelable streams in the event of cancellation? This can be taken care of if the staking contract implements a withdrawal hook.
3. How to make sure that unauthorized Sablier NFTs can't be staked?
4. What are the key factors that differentiate staking Vesting streams from staking liquid ERC20 tokens?

Everything else depends on the user's requirement and can be learned from other staking products.

---

As a next step, I would like to hear from all of you.

• Do we provide full deployment-ready contract? It should be audited then.
• Do we provide the answer to four important questions through the template?

[PaulRBerg]

Thanks Shub for this detailed breakdown.

Unfortunately, due to competing priorities, I am unable to review this properly, not now, and not in the foreseeable future.

My two cents:

• No, we won't audit it.
• Let's go with the simplest of designs possible.
• If such a thing is not possible, let's pause this project and treat it as a sunk cost.
• We will only pick it up again if users keep asking for a staking solution.
• OpenEnded is 100x more important and I would like you two to focus on that.

[smol-ninja]

This is why staking contract template is important alongside a doc on "things to remember for staking". (PS: I have made good progress)