Yield modes on Blast L2

[smol-ninja]

Blast is a new L2 with native yield for ETH and stablecoins. Every token bridged to Blast automatically gets staked to earn yield. There are 3 approaches through which Blast allows smart contracts to handle yield rewards.

1. Void

By default, all smart contracts are subscribed to disabled yield mode. Any ETH or stablecoin deposited into that contract is excluded from earning yield. Any contract that is deployed on L1 can be directly deployed to Blast without making any change but that would also not allow the contract to re-configure the yield mode in the future.

abstract contract SablierV2Base {
    IBlast public constant BLAST = IBlast(0x4300000000000000000000000000000000000002);

    constructor(....) {
        ....
        // subscribe to Void mode. 
        // the set `governor` address can re-configure yield mode after contract creation.
	BLAST.configure({ _yield: YieldMode.VOID, gasMode: GasMode.VOID, governor: 0x123...678 });
        ....
    }
}

2. Automatic

When a smart contract is subscribed to Automatic mode, any ETH or stablecoin deposited earns yield automatically. Blast uses the rebase approach to reflect yield in the balance.

For example, a smart contract has 10 ETH and after 24 hours, it earns 0.1 ETH, Blast will automatically change its balance from 10 ETH to 10.1 ETH. This is also reflected in ERC20's balanceOf.

Since Sablier streams don't use balanceOf, it would require something similar to implementing a recovery mechanism in order to withdraw the excess yield amount added to its balance.

abstract contract SablierV2Base {
    constructor(....) {
        ....
        // subscribe to Automatic mode
        // the set `governor` address can re-configure yield mode after contract creation.
	BLAST.configure({ _yield: YieldMode.AUTOMATIC, gasMode: GasMode.VOID, governor: 0x123...678 });
        ....
    }
}

3. Claimable

In this mode, a smart contract earns yield automatically without requiring its balance to rebase and accumulating yield separately. The governor address claims yield on behalf of the contract.

For example, if 10 ETH is deposited, the contract balance will remain at 10 ETH always. The accrued yield balance of 0.1 ETH can be claimed separately.

abstract contract SablierV2Base {
    constructor(....) {
        ....
        // subscribe to Claimable mode
        // the set `governor` address can re-configure yield mode after contract creation.
	BLAST.configure({ _yield: YieldMode.CLAIMABLE, gasMode: GasMode.VOID, governor: 0x123...678 });
        ....
    }
}

contract Governor {
    // to claim yield on behalf of the contract when its subscribed to Claimable mode.
    BLAST.claimYield(address contractAddress, address recipientOfYield, uint256 amount) external returns (uint256);
    // to re-configure yield mode after contract creation
    BLAST.configureContract(address contractAddress, YieldMode _yield, GasMode gasMode, address governor) external;
}

My remarks

Blast deployment doesn't require much work. We can deploy the contracts with Claimable mode in the beginning as it keep the yield separate from the main contract balance, and then later figure out what to do with the yield.

Links

1. Blast technical doc
2. Blast big bang competition summary

[PaulRBerg]

Thanks for this research and for sharing it, @smol-ninja. This is a perfect summary.

It seems obvious to me that we should go with the "Claimable" approach.

Even with an ERC-20 recovery mechanism, there are advantages to claiming separately, such as easier accounting, segregation of funds (Sablier Labs' yield is separated from user funds), and better developer experience overall (fewer txs to index in the subgraph, etc.)

[smol-ninja]

Yes. I agree.

[IaroslavMazur]

Here's a quote from the referenced guide:

This is useful for dapps that want to pass yield on to their users such that there’s no opportunity cost for the user to deposit ETH to the dapp.

Given the above, a fairly probable future for the dApps on Blast is to distribute all of their yields to their users. If this happens, not passing the yield down to our users could be perceived as "greedy"/bad PR. Have you considered this?

---

In any case, it'd, probably, not be worth it to implement the reward-sharing into the Sablier contracts on Blast, given the added complexity and development/audit costs. Even with the possible "bad PR" 🙂

[smol-ninja]

If this happens, not passing the yield down to our users could be perceived as "greedy"/bad PR.

Thanks for sharing your concern @IaroslavMazur and you made a really good point. However, I do not totally agree with your "greedy/bad PR" take. I'd like to share the example of Circle. Circle earns yield on USD deposited into its bank and they don't share any of that with USDC users. People use USDC because the value it offers to them is higher than sharing that 5% yield.

In the Blast's context, I agree that not passing ANY yield to users could be disadvantageous over competitors (time will tell though!). I propose to keep a percentage of the yield earned as an alternate revenue to Sablier. This can be justified against the Sablier value addition. We have already been discussing a similar approach here where we intend to earn a yield on the TVL.

to implement the reward-sharing into the Sablier contracts on Blast

I agree that implementing automatic reward sharing inside core contracts would be a lot of effort. However, rewards can be accrued separately through the "Claimable" mode and do not add any complexity to the Sablier contracts. The rewards-sharing mechanism can be implemented separately from the core contracts.

The reason I would prefer deploying on Blast is not primarily the yield but the fact that Blast has acquired 100k users in just 2 months and is now the 2nd largest L2 with $1.24B in TVL.

[IaroslavMazur]

Circle earns yield on USD deposited into its bank and they don't share any of that with USDC users.

Right, and so does Tether, AFAIK.

BTW, are you talking about USDC on Blast - or, in general? If it's the latter, then, my counterargument is that it's Blast's "native" yield-generation that is the cornerstone of the discussion. And if it's the former, my counterargument is that Circle/USDC is big enough for people to need them and trust the brand more than they want those Blast yields.

---

People use USDC because the value it offers to them is higher than sharing that 5% yield.

Yeah, and, hopefully, Sablier will be perceived like this, in the future, as well!

---

I propose to keep a percentage of the yield earned as an alternate revenue to Sablier. This can be justified against the Sablier value addition.
I agree that implementing automatic reward sharing inside core contracts would be a lot of effort. However, rewards can be accrued separately through the "Claimable" mode and do not add any complexity to the Sablier contracts. The rewards-sharing mechanism can be implemented separately from the core contracts.

I'd say that implementing the reward sharing would be a lot of effort even if this logic exists outside the core Sablier contracts.

Because of this, I'm inclined towards having no revenue-sharing, at all.

---

The reason I would prefer deploying on Blast is not primarily the yield but the fact that Blast has acquired 100k users in just 2 months and is now the 2nd largest L2 with $1.24B in TVL.

The chain does seem to have a potential for upside, from this perspective, yes. 👍

[smol-ninja]

are you talking about USDC on Blast - or, in general?

in general.

And if it's the former, my counterargument is that Circle/USDC is big enough for people to need them and trust the brand more than they want those Blast yields

Yes, I agree. My point was that if the value provided exceeds the interests not shared by the protocol, it does not necessarily lead to a bad PR. But I can say that we don't know about that yet in the context of Sablier so it would be important to discuss how to deal with yields.

I'd say that implementing the reward sharing would be a lot of effort even if this logic exists outside the core Sablier contracts.
Because of this, I'm inclined towards having no revenue-sharing, at all.

Yes, I cannot disagree. That "Claimable" mode gives us so much flexibility to decide later on how to deal with the rewards.

[PaulRBerg]

Shall we close this, @smol-ninja? We're going with "Claimable".

[smol-ninja]

Yes, closing.

• Support Blast network #807

[smol-ninja]

Now I have more clarity about our requirements, I am re-opening this discussion to get answers on the following questions:

1. In Lockup contracts, for ERC20 Yield, since governor cannot be set, how do we claim Yield? I have already implemented a bespoke claim function for this. It takes recipient, amount and token address. That OK?
2. How do we configure yield in Merkle streamer? Currently, I have implemented it in constructor. On testnet, ERC20 yield is configured to Automatic but will be changed to Claimable for mainnet. But should we allow user to claim it? Or, Should Sablier admin be able to claim it (as a source of revenue)?

I have implemented necessary functions required to configure modes and to claim yield and gas in a base contract. You can find them in BlastGovernor.sol and IBlastGovernor.sol.

My Suggestions

mainnet configuration for Lockup contracts

For ETH Gas, the ideal approach would be to configure it to Claimable mode and set a governor address. The governor address will have full control of configuration and claiming gas without requiring to interact with the Lockup contracts.

Due to the contact size nearing its limit, we cannot configure it in the constructor. That means contracts will be deployed with default Void modes. Post-deployment, the admin can call this function to re-configure Gas to be claimable as well as set the governor address.

This can also be automated by adding it to the deployment script.

mainnet configuration for Merkle Streamer

Since Merkle streamer contract size is way below the limit, we have the flexibility to set configurations in its constructor.

When a user deploys a Merkle-streamer, we can initialize it with the below configurations:

• Void for ETH Yield
• Claimable for ETH Gas
• Claimable for ERC20 tokens
• Set initialAdmin as the governor. initialAdmin can claim Gas asynchronously without requiring to interact with the Merkle-streamer contract. However, to claim ERC20, he must call the claim() function.

Thoughts?

[smol-ninja]

@razgraf's point:

I'd be interested to understand why we don't redirect the yield towards a "treasury wallet" of our own by default. But I can also ask in the future discussion.

Yes we can do that. Shall we do that then?

[smol-ninja]

Continuing discussion in https://github.com/sablier-labs/company-discussions/discussions/42