[BIP-591] Generating USDC revenue for the treasury via BAL covered call lending on MYSO

PR with Payload

We propose utilizing idle treasury-owned BAL to engage in covered call lending using MYSO Finance: this would allow Balancer to generate significant stablecoin revenue, diversify part of its treasury and earn cash upfront without having to wait until loan expiry. In contrast to simply selling tokens, there’s no immediate market impact. All loan execution happens through MYSO smart contracts and is trustless and fully transparent with full on-chain traceability.

Proposal author - MYSO Finance
MYSO is a decentralized peer-to-peer lending protocol that specializes in custom loans that allow users to borrow and lend with any ERC20 token. In addition, the protocol can support a wide range of different on-chain structured product strategies like synthetic token buybacks and covered calls. MYSO has recently facilitated several on-chain covered call strategies for treasuries/users, including one with Telos treasury and Evmos community treasury.

The protocol currently holds a TVL of ~$2.2m and is currently live on Ethereum, Arbitrum, Mantle, Evmos, Telos, Linea and Neon EVM. The protocol originated from the ETH Global Hackathon in 2021, where it was awarded as one of the winners. It is also backed by several reputable crypto OGs, such as HashKey, Wintermute, and Nexo.

Site - https://myso.finance/
DApp - https://app.myso.finance/

Balancer has frequently engaged in treasury diversification efforts as well as deployment of BAL to various on-chain yield-generating strategies. The Balancer DAO still has a large sum of BAL tokens idle in the treasury and recent posts within the governance forums have mentioned the need to continue to actively deploy these funds to diversify/earn yield.

To support this endeavor, we propose using BAL to engage in covered call lending, allowing the treasury to generate USDC income. In contrast to conventional lending, the USDC is earned upfront, eliminating the need to wait until the loan matures. All loan execution happens through MYSO smart contracts and is trustless and fully transparent with full on-chain traceability.

The covered call lending parameters, such as loan duration and upside cap, can be customized according to individual treasury preferences to optimally serve the Balancer community. Unlike traditional CeFi-style covered calls which are oftentimes presented by market makers, this proposal allows Balancer to get access to a similar financial payoff but without any counterparty risk. This is because the borrower is required to post USDC collateral upfront, ensuring that Balancer never faces a situation where the upside cap price is not paid or the loaned BAL tokens are not returned. The upfront USDC income from lending BAL can be immediately utilized for community needs. And unlike a simple token sale, covered call lending enables the treasury to diversify its holdings into stable assets without any immediate market impact.

Proposal Features
Utilize Idle Tokens: Idle BAL tokens can be used to generate upfront USDC revenue
Full Customizability: Covered call parameters (e.g., duration, upside cap, size etc.) can all be fully customized to optimally cater for Balancer’s treasury preferences
No Market Impact: Tokens don’t need to be sold, thus there’s no immediate market impact
Covered Call Yield: Yield is generated through a covered call structure, where cash is paid upfront for lending BAL and implicitly writing a call option on the loaned tokens
Transparency: Loan execution happens transparently on-chain using 3x audited MYSO smart contracts, without counterparty default risk


  • Immediate revenue and liquidity for operational and developmental activities
  • Diversification of the treasury into stables (e.g., multiple covered calls can be executed consecutively over a longer time period)
  • Unlike conventional covered calls or market maker loan arrangements, there is no counterparty risk

Example Scenario
Balancer treasury lends $250k worth of BAL for 60 days at a 110% upside cap (strike). In return, the Balancer treasury gets ~$18.75k USDC upfront (~46% APY). Then, at expiry, there are two possible outcomes:

  • If the BAL price remains below 110% after 60 days, the originally loaned BAL is returned.
  • If it exceeds 110%, Balancer treasury receives $275k USDC and also retains the upfront USDC.

The diagram below shows indicative upfront premiums that the Balancer treasury could earn across various loan duration (Days to Expiry) and upside cap (Relative Strike Level) combinations. Generally, the longer the loan duration and the lower the upside cap the higher the upfront premium Balancer can earn. Balancer can customize the covered call terms to their liking and choose from a number of different duration/upside cap combinations. Additional indicative prices can be provided upon request.

The premium for the example scenario above (110% upside cap, 60 day duration) is indicated in red (7.49% upfront)

How does a Covered Call work?
Below is a diagram illustrating the payoff of a covered call for BAL tokens and how it compares to simply holding. A simple holding strategy results in a linear payoff (green line).

For instance, if BAL increases by +10%, the gain is +10%, and if it decreases by -10%, the loss is -10%. On the other side, the covered call payoff line (blue line) also follows a linear shape but only up to the upside cap, beyond which the gain is capped.

Note how the covered call payoff line is shifted upwards by the USDC upfront premium received for lending BAL, regardless of how the price of BAL moves. This means that in all cases where the BAL price remains below the upside cap, the outcome of the covered call will always be better. Only when the price exceeds the upside cap would holding lead to a better outcome. From an overall risk perspective, this implies that the downside risk with a covered call is lower than holding BAL.

For example, even in the unlikely case where BAL were to drop by -100%, the covered call would have returned a better result because the upfront USDC cash would have been received in any case. Hence, the downside risk of doing a covered call is actually lower than simply holding BAL.

Where Does the Yield Come From?
When Balancer lends through a covered call, it essentially lends treasury tokens and writes a call option. The borrower, on the other hand, buys the call option and has the right - but not the obligation - to return BAL tokens. To initiate the loan, the borrower first needs to send USDC to (1) pay for the upfront premium to the Balancer treasury and (2) provide collateral for cases where the borrower doesn’t repay.

For example, if Balancer lends $250k worth of BAL for a 7.49% premium for 60 days with a 110% upside cap, the borrower needs to send ~$18.75k USDC for the upfront premium and $275k USDC as collateral, totaling ~$293.75k USDC.

At the loan’s inception, the Balancer treasury would receive $18.75k USDC immediately and keep it no matter what, and at expiry, two scenarios can happen:

(i) BAL price doesn’t increase by more than 10% after 60 days, in which case it’s rational for the borrower to return the borrowed BAL tokens and retrieve the $275k USDC collateral

(ii) If the BAL price increases by more than 10% after 60 days, it’s rational for the borrower not to return BAL tokens, resulting in an unlock of the pledged $275k USDC, which becomes claimable by the Balancer treasury.

It’s uncertain whether or not the BAL price will exceed the upside cap. One can use option pricing theory to determine a fair value for the embedded upside potential using the Black-Scholes model.
The USDC upfront premium that Balancer would receive (in this example $18.75k) compensates for selling this embedded upside potential or call.

How can the Balancer treasury lend BAL via Covered Call?
Apart from programmatic execution, the Balancer treasury can use the MYSO DApp [https://app.myso.finance/] to carry out a covered call transaction. The first step is to create a “lender vault” (see screenshot)

createVault function can be inspected here on Etherscan

Once a lender vault has been created, the treasury can then fund the vault by adding BAL tokens as assets to lend. Once the vault has been funded, one can then create a covered call loan offer according to the target terms.

On the ‘Create Covered Call’ page, you can add your desired upside cap, loan tenor, and upfront premium.

addOnChainQuote method can be inspected on Etherscan here

Once the loan offer has been created, it will become visible on the borrow page. Through MYSO’s OTC network, loan terms can be discussed and matched with institutional borrowers beforehand, so that when the offer is created, the Balancer treasury can be certain that the borrower will take the loan offer within a few hours. In case the borrower doesn’t execute the loan for any reason, Balancer can withdraw the funds at any time. Additionally, the loan offer can be created with a deadline, meaning that it automatically invalidates after a certain time. Lastly, the loan offer can also be parameterized to be executed only by a certain counterparty if desired.

How secure is it to do covered calls?
MYSO has undergone three independent rigorous audits with leading security experts from Statemind, Omniscia, and Trail of Bits. All audit reports are publicly available and can be seen here:

Statemind: [public-audits/Myso Finance/2023-08-15_Myso_v2.pdf at main · statemindio/public-audits · GitHub]
Omniscia: [Omniscia Myso Finance Audit]
Trail of Bits: [publications/reviews/2023-04-mysoloans-securityreview.pdf at master · trailofbits/publications · GitHub]

Moreover, as mentioned earlier in the proposal, one of the benefits of using MYSO for covered calls is the absence of counterparty risk. MYSO provides access to covered calls in a trustless manner, eliminating the need to trust the borrower.

Technical Specifications
The Balancer LM multisig eth:0xc38c5f97B34E175FFd35407fc91a937300E33860 will interact with the MYSO Vault Factory token contract at 0x1874a08F7975b25944FEb989BbAaA464f61aB3bc and call createVault(bytes32 salt) passing in 0x0000000000000000000000000000000000000000000000000000000000000000 as the salt.
This will create a vault clone with address 0xdC84A5e6Bf288af75CC821226634644Ed6a7aB54.

Then, the aforementioned Balancer multisig will call transfer on BAL Token at contract address 0xba100000625a3754423978a60c9317c58a424e3D with to address being newly created vault address (0xdC84A5e6Bf288af75CC821226634644Ed6a7aB54) and amount being 25000_000000000000000000 ($94,000 USD at current spot price of ~$3.76)

The last interaction would be to create the actual quote - here would be the example transaction for a quote at 120% strike, 5% upfront premium for 30d tenor:
Balancer LM multisig (0xc38c5f97B34E175FFd35407fc91a937300E33860) would call addOnChainQuote function on quoteHandler at address 0x71E1cc2F7574C798ED893Ef04D55D1E573bE95B1 with params

lenderVault: 0xdC84A5e6Bf288af75CC821226634644Ed6a7aB54,
onChainQuote: {
	generalQuoteInfo: {
		collToken: 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48,
		loanToken:  0xba100000625a3754423978a60c9317c58a424e3D,
		oracleAddr: 0x90B9eA01b1c0E2A1b95B03DFBb8E2A4b3F903bfC,
		minLoan: 20000_000000000000000000,
		maxLoan:  100000_000000000000000000,
		validUntil: 1735779846,
		earliestRepayTenor: 0,
		borrowerCompartmentImplementation: 					0x0000000000000000000000000000000000000000,
		isSingleUse: true,
		whitelistAddr: 0x0000000000000000000000000000000000000000,
		isWhitelistAddrSingleBorrower: false
			loanPerCollUnitOrLtv: 800000000000000000,
			interestRatePctInBase: 0,
			upfrontFeePctInBase: 40000000000000000,
			tenor: 2592000
	salt:  0x0000000000000000000000000000000000000000000000000000000000000000

The above parameters are an estimate/example transaction since the upfront fee/premium could change depending on the recent BAL volatility following the proposal being approved.

We propose utilizing 25,000 BAL tokens as the notional amount (~$94,000 USD at current spot price of ~$3.76) and utilizing either a 110% or 120% upside cap (strike).
We propose running the strategy at either a 30 or 60 day tenor and repeat the strategy over the course of 6 months to start - the tenor for each transaction would depend on the upfront premium, and we’d push towards securing a tenor for which the premium would result in highest annualized yield.

We also propose to never quote below a 2.5% premium on 120% strike (~30.4% APY) and below 4.0% premium on 110% strike (~48.7% APY) for a 30 day tenor strategy.
In addition, we propose never to never quote below 4.0% premium on 120% strike (~24.3% APY) and below 5.5% premium on 110% strike (~33.5% APY) for a 60 day tenor strategy.

Once the proposal is approved and the Balancer LM multisig seeds their bespoke vault with the 25,000 BAL, no other active management will be needed apart from settling on a quote and creating new offers after each strategy expiry.

This proposal has outlined how Balancer can generate USDC cash revenues by using idle BAL treasury for covered call lending. This approach not only diversifies the treasury but also avoids market impacts that could arise from outright selling BAL. The flexibility in structuring loan terms allows Balancer to tailor the initiative according to its unique risk-reward preferences, ensuring alignment with its broader financial and operational objectives.

We look forward to hearing your comments and feedback and would love to assist in pushing this proposal to voting!


Thanks for the proposal. We had a positive outcome using a similar strategy with Ribbon over a 1 year period, running from July 2022 to September 2023. We collected around $300K USDC in that period. Ribbon were using Opyn options to facilitate writing of BAL contracts. Am I to understand that you have built a similar option contract creation process in-house?

Based on the current market environment I would lean towards the 30day option in order to not expose ourselves too long to the potential of the price rising in a shorter timeframe. As mentioned in the previous topic on the subject, this strategy works best with sideways price action or downward price pressure.

When you are quoting the relative strike level % at 110% and 120%, you mean 10% and 20% above the current price, correct? If yes, I would also suggest the 120% option. The premium collected will be less, but the potential of selling away a portion of the BAL deposited is also less. Again a more market based decision.

Lastly, I think in past cases with strategies such as this we gave an option to voters to choose between two or three amounts. Seeing as this is the first time we’d be using the platform it may be good to provide those options. 15,000 BAL, 25,000 BAL, 50,000 BAL, something like that. There could also be a subsequent vote to add more depending on how things play out if a lower value is chosen. If we go with the 30day expiry option we could have a touchpoint after a quarter. Not sure what others thoughts are on that.


Hi @zekraken thanks for the comment!

So to answer all your Qs:

Am I to understand that you have built a similar option contract creation process in-house?
Yes, all loan execution happens trustlessly and without any counterparty default risk through MYSO’s 3x audited smart contract - this is because the inst. borrower pledges in an overcollateralized manner (including enough stables for both the upfront premium + upside cap amount).

When you are quoting the relative strike level % at 110% and 120%, you mean 10% and 20% above the current price, correct?
Yes, relative strike levels at 110%/120% indicate 10/20% above spot price at loan execution time i.e., this is the ‘upside cap’

As for the BAL amount, we can certainly have two different options for the notional amount that users can vote for, how about i) 25,000 BAL and ii) 50,000 BAL?

As a last point, all in all if the goal is to earn sustainable upfront premiums while minimizing the chance of conversion then a shorter tenor like 30 days could definitely be prioritized.


Thanks for this thorough proposal.

I think it would be now a good time to test this strategy with the proposed 25k or 50k BAL amounts as voting options based on the previous discussions. In this way, the DAO can evaluate such revenue streams without too much capital risk.
The market seems currently more volatile so the question remains how that risk factor will play into this strategy. A 30 day tenor could be therefore a good middle ground.


Thank you for providing detailed tech specs.

Upon review, we need more clarity on how to proceed. The DAO Multi-sig is not guaranteed to execute on-chain tx’s fast. We usually time transactions for once a week.

How would this look like on-chain? Similar to your proposed specs for part two?

Given this parameter set, it might be more logical to transfer let’s say 25’000 BAL to the LM multi-sig managed by the Maxis which could more easily execute said transactions and guarantee timely parameter changes. We will do a review and report back once it is more clear to us what makes sense.


Hello @Xeonus appreciate your feedback!

Since BAL price/volatility may shift quickly, premiums for a covered call tx may also shift and thus we provided some minimum premiums at each different strike/tenor level for which we’d advise the DAO multisig to execute at.

BAL has an oracle in place so if a bespoke BAL vault would be funded on MYSO then the only necessary action by the DAO after vault funding would be to create an on-chain quote with the firm covered call quote parameters.

If delegating to the LM multi-sig managed by the Maxis would aid in faster/more efficient execution then we can propose to do this and start with the lower 25,000 BAL amount

1 Like

Thanks a lot for your patience @contentropy - I think we all agree that we should do a test run with 25’000 BAL managed by the LM Multisig 0xc38c5f97B34E175FFd35407fc91a937300E33860 which can be verified here and here

To summarize:

  1. Approve BAL amount and transfer to LM Multisig
  2. LM Multi-sig will interact with Myso vault factory token contract
  3. transfer tokens to vault
  4. create quote

Would it be OK for you to adjust the payload accordingly incl. the BAL transfer to the LM multisig (we can assist of course)?

@contentropy upon trying to set up the payload I saw the following inconsistencies. Please advise:

  • The outlined vault factory doesn’t have a createVault function.
  • Furthermore, will the clone address be the same if we execute from our LM multi-sig as mentioned further above?

If you could clarify and adjust your payload so that we can potentially prepare it for this weeks vote would be highly appreciated. Thanks.


that was the implementation address
Apologies for that
the vault factory address is
and yes sender address and salt value goes into the cloneDeterministic function (create2 op code), so I will need to re-simulate the resulting the vault address that will be created from the new LM sender.
We will get those edits in soon and re-post the payload. Thanks!

1 Like

Hi @Xeonus thank you for the feedback - adjusted the payload and all relevant addresses related to Balancer LM multisig and vault factory. We look forward to pushing this proposal forward with the smaller 25k BAL allocation to the LM multisig to execute the covered call strategy!

Let me know if any other edits are needed.




Unfortunately, this vote didn’t pass based on our 1 million Yes vote quorum requirement. Therefore, any prepared on-chain actions will be removed from execution this week.

1 Like