Bringing back an idea I discussed with a few folks last year: we can increase the resources available to Service Providers (SPs) without raising the DAO’s total spending.
Here’s how it works:
The DAO deposits the SPP2 budget (currently in USDC) into Sky.
In return, the DAO receives sUSDS, a yield-bearing stablecoin (currently yielding 4.5% APY, with peaks up to 15%—details).
Streams to Service Providers are paid in sUSDS.
Over the course of 1–2 year streams, SPs would receive a greater total value, giving them more resources to deliver more, at no additional cost to the DAO, low risk and operational effort.
After some simulations, if providers withdraw each month and APY remains in 4.5%, it would at least be generating ~$210k extra.
The effort to execute this are:
Including this operation in the executable proposal that will happen for the allowance of the provider streams
Change streams on the streams multisig managed by metagov.
Risk Considerations
While sUSDS is yield-bearing, it introduces some asset risk. USDC itself has risk exposure too, as seen during the SVB-related depeg. sUSDS is managed by MakerDAO/Sky, one of the oldest and most reputable DeFi protocols. It’s also already part of ENS’s treasury strategy, managed by @kpk.
To mitigate concerns, this would be an opt-in mechanism for SPs: only those who choose to receive payments in sUSDS would do so.
Conflict of interests
I’m also in a leadership role at blockful (one of the selected teams for SPP2).
@netto.eth this is a good idea. Generally speaking, I think making capital productive especially when the intention is to fund builders is an idea worth exploring.
However, I would assume there are lots of legal implications from the Foundation side but lets leave that to someone more equipped to deal with that domain.
The challenge here is streaming vs monthly redemptions which are fundamentally different delivery paradigms.
This tracks closely with some work we have been exploring with bonds. What you are describing is a Amortizing Coupon Bond. Where:
Coupon is the yield that is redeemable periodically (e.g. monthly)
Amortizing, where the underlying principle is redeemable periodically (e.g. monthly)
Personally, I think this is better than streaming because as a recipient you have more optionality to redeem based on the business needs.
Moreover I think this can eventually be done trustlessly with smart-contracts with the correct guardrails with little need for management.
We did this at Shutter DAO with a few million sDAI that was streamed to the core team. Blockful helped.
It might not make as much sense here at ENS though. Our Investment Policy Statement defines what/how we invest, and we need to keep a certain percentage of stables, so if we did this we’d just have to swap out of other yield bearing stables to keep the percentages as intended.
The other question is who is the beneficiary. At Shutter the DAO received the yield by slowly decreasing the stream amount to still deliver a set amount to the recipient. Here, it looks like the Service Providers would be the beneficiary. Which would mean that the DAO would have to swap out of yield bearing stables in the endowment so that the Service Providers could have that yield instead.
The original iteration of the SPP utilized the Superfluid AutoWrapper to minimize risk exposure (from security vulnerabilities). This suggests the DAO doesn’t want further up front risk exposure in the context of SPP.
If the DAO has become more risk tolerant and wanted to maximize returns on assets held there is $10M of USDC in the DAO Wallet right now (1750090145) that could be converted to yield bearing stablecoins. I accept that that yield doesn’t end up in the hands of Service Providers.
This is compelling. In principle the risk can be taken on by the individual Service Provider, but in practice if the funds are still held by and streamed from a DAO (Metagov) wallet it would at a minimum pre-requisite an additional term stating something like ‘if sUSDC blows up, it’s not the DAO’s problem’.
BUT
Thinking about it, it still would be the DAOs problem because if sUSDC blew up that SPP wouldn’t have the funds to deliver what they’ve promised to the DAO.
Technically
Can sUSDC be wrapped and utilised within Superfluid? I.E is it standard ERC20?
From an executable POV the USDC needs to become sUSDC up front. We’d need to discern which providers want to opt in and if its not all of them, this complicates the executable somewhat in that we have to have USDC and sUSDC allowances.
TL;DR
Free money is good, but there is no such thing as free money.
If there were free money would the DAO give it to the Service Providers or keep it for themselves?
This is a very thoughtful and innovative proposal. That said, I have a few concerns given where we are in the execution timeline:
Current architecture streams USDCx via Superfluid. To implement your idea, we’d need a wrapped SuperToken version of sUSDS (i.e. sUSDSx). AFAIK, that wrapper doesn’t currently exist and would need to be deployed, verified, audited, and added to Superfluid’s token registry. That’s a nontrivial lift.
Smart contract and operational risk. sUSDS introduces new dependencies (e.g. MakerDAO/Sky, yield mechanics, depeg potential). That may be acceptable long-term, but adds uncertainty at a late stage — especially when SPs are already waiting for streams to begin.
Timeliness. Switching to sUSDSx may delay the executable proposal, require updating the flow-rate and re-compute the nominal flow in sUSDSx. That feels like a tough sell when the priority should be getting payments live.
If the DAO wants to explore this path, I’d suggest we ship SPP2 as-is (USDCx) and revisit sUSDS in a follow-up once the wrapper is ready and risk is more fully assessed.
—
I agree that the key question here is who benefits from the yield. The Shutter DAO example seems like a nudge for ENS to consider a similar approach, but I wonder if there’s room for both the treasury and SPs to benefit in this case.
—
As for the IPS, it’s a living document and could be updated with an offchain proposal if there’s enough consensus around using a portion of the stablecoin allocation this way. That said, referencing the IPS may be slightly out of context in this case, since we’re talking about funds that would have already exited the DAO’s treasury.
IIRC, once funds are transferred to the streams multisig, Meta-Governance has operational control over these funds and can manage them within the bounds of what’s been broadly legitimized by the DAO.
Proposal [EP 3.3] established the concept that the DAO maintain a 18-24 month runway of stables to ensure a guaranteed runway.
We then codified that in the IPS:
Constraints
Constraints of the Endowment deployment are as follows:
Liquidity needs: at least 3 years of DAO’s operating expenses runway should be held in stablecoins and stablecoin-neutral positions, based on the last calendar year’s expenses. Based on 2023 spending rate, this represents $26.7M in stablecoins.
The idea was initially floated on Routine DAO treasury management proposal, but was never formalised. Instead, EP 3.3 facilitated procurement of the runway, via a swap of 10,000 ETH into $16.2M USDC on CowSwap. At the beginning of 2024, $11.5M of USDC was remaining in the DAO wallet (not under Endowment), representing ~0.95 years of runway.
It’s in the IPS, and Karpatkey has always included the stables in the Timelock in that calculation. We’ve generally been okay with a portion of the stables being represented by stable equivalents in the Endowment.
That makes sense if we are treating the earmarked $4.5M on an accrual basis, where committed funds remain on the books until they are fully disbursed.
But if we’re taking that view, then it seems we also need to ask whether yield-bearing instruments like sUSDS are being dismissed, not because of their actual risk profile, but because of how we account for committed funds. That feels like a subtle but important distinction in how we define “liquidity” vs “commitment.”
So we have to ask: are we protecting our liquidity buffer? Or are we being overly conservative by treating earmarked program funds as if they’re still part of the rainy-day fund?
Is it appropriate to treat committed funds as part of our liquidity buffer, or should they be considered already allocated and therefore outside the scope of the IPS’s runway constraint?