Blend v3 Proposal -- Zenith #57
Replies: 2 comments 4 replies
-
|
Thanks to @NotIshanSingh for putting a detailed proposal on the table. We agree on more than the framing might suggest, so we want to be precise about where we align and where we think the proposal preserves the two things that have most clearly failed Blend to date. In short: the proposal keeps an under-capitalized, wrong-way backstop, keeps a deposit base that is overwhelmingly XLM and stablecoins, and defers the actual RWA work to "around Blend" without naming who builds it, who funds it, or who is accountable for keeping it secure. We'll take it section by section. Where we agreeWe want to state this up front, because what follows is a disagreement on architecture:
We'd note one thing about this list, though: none of these improvements depends on retaining the backstop, the token, or the current pool composition. They are risk hygiene. They are necessary, but they are not a v3 thesis, and they should not be presented as a reason to leave the harder questions untouched. Where we disagree1. Backstop philosophyThis is where we most firmly disagree The proposal's central claim is that the backstop should be preserved largely as-is, that "ditching the backstop is effectively ditching the BLND token," and that the backstop "worked." We can't let the last point stand, because it is testable, and the test already ran. The empirical record (YieldBlox, Feb 2026). The USTRY oracle manipulation opened a hole of roughly $9–11M in the pool. The backstop, worth approximately $2M at the time, was auctioned off first and it covered under a quarter of the shortfall. The residual bad debt was then socialized across all suppliers: the bXLM exchange rate fell from 1.0 to roughly 0.45, marking XLM suppliers down by about 55%, with USDC suppliers taking a further haircut. Depositors were ultimately made whole only because the Stellar Foundation voluntarily compensated them off-protocol. That is not the backstop working as intended. That is the team backstopping the backstop. Any honest post-mortem has to start there. The structural reason it failed, and will fail again. The backstop LP is 80% BLND / 20% USDC. BLND is correlated to exactly the downside the backstop is meant to insure. When a pool takes losses or the market is under stress, BLND falls, so the dollar value of first-loss capital evaporates at the precise moment claims against it spike. This is textbook wrong-way risk. The whitepaper's "backstop size correlates to TVL" mechanism does not address it; correlating size to TVL in calm markets says nothing about denomination risk in a crisis, and the crisis is the only time the backstop matters. "Ditching the backstop is ditching the token": addressed on its own terms. Blend is ungoverned; BLND carries no voting power. Per Blend's own documentation, the token's sole utility is the backstop. So the argument reduces to: we must preserve a mechanism because removing it would strip the token of its only function. That is circular. The token is not the thing being protected here; lender solvency is. If the mechanism underperforms at its one job, "preserving the token's identity" preserves a fig leaf, not a safety net. The market has already priced this. BLND's fully-diluted valuation is roughly $3M (CoinGecko, current). Against a protocol TVL in the ~$140M range, that is a TVL/FDV ratio north of 40×. Comparable lending-protocol tokens sit in the single digits to low teens: Aave ~11×, Compound ~10×, Kamino ~6×, Morpho ~4×. Blend is a 4–10× outlier on the exact metric that asks "does the token credibly capitalize the risk it secures?" You cannot insure $140M of deposits with a $3M token, and the market is telling you it doesn't believe you can either. Leaving the token unchanged does not lead to sustainable growth; serious reform here is the minimum bar, not an optional Phase 3. Institutions cannot hold the token, and their risk teams will not approve it. Set aside whether the backstop is large enough, participating in it at all requires holding an 80/20 BLND:USDC LP, i.e. a mandated long position in a sub-$3M-FDV token that trades a few thousand dollars a day. For an institutional risk or treasury desk that is a non-starter, and not as a matter of taste. A token this illiquid fails standard eligible-asset, market-cap, and liquidity screens; it cannot be hedged (no liquid spot market, no derivatives) or exited at size; and it lands as a hard-to-mark, Level-3-style line that auditors will impair heavily. The proposal wants Blend to be institution-friendly and RWA-friendly while keeping a first-loss mechanism that obligates every backstopper to underwrite the protocol's own micro-cap token risk. Those two goals are mutually exclusive. An allocator that comes to lend stablecoins or tokenized treasuries will not, and under most mandates cannot, accept BLND exposure as the price of providing insurance. The institutions this proposal is courting are therefore structurally excluded from the very mechanism it insists on preserving. The "configurable take rate so pool operators can skim it" idea makes this worse. Letting operators divert a cut of the backstop take rate thins the first-loss buffer that already proved insufficient, and routes that value to the operator rather than to the lenders bearing the risk. That is the opposite of the direction the evidence points. 2. RWA "around Blend, not inside it"Blend today is, by deposit value, >99.9% XLM, USDC, and EURC. That single fact is the strongest argument against the proposal's RWA stance, because "keep RWA-specific logic around Blend rather than inside it" is not a plan to change that number, but rather a description of the status quo dressed as a roadmap. It guarantees Blend remains a venue for borrowing stablecoins against XLM. Two further problems:
The future of Stellar, and of Blend, is RWA-centric. A v3 that explicitly keeps RWA out of the core is choosing the wrong future. 3. "Uniswap of lending"Uniswap earns that label through thousands of permissionless, long-tail markets and deep composability. Blend serves three assets. A primitive whose entire live book is XLM/USDC/EURC is not the Uniswap of lending; it is a XLM-stablecoin money market. The slogan is aspirational, and the proposal's own "keep everything else outside the core" posture is what ensures the long tail never actually arrives on Blend. You don't get to claim the Uniswap analogy and simultaneously architect against the breadth that makes it true. 4. Fixed rate via "config magic," fixed duration as "OTC on top"
5. Hook systemComposability is a real goal and we're not against it in principle. But a general pre-/post-action hook surface across borrow, withdraw, liquidation, interest, onboarding, and compliance is a large new attack surface, and the proposal concedes as much, noting a bad hook system "could introduce more risk than value." Proposing to widen the protocol's attack surface months after a live, oracle-driven $10M loss inverts the risk priorities the moment demands. Hooks also do not solve the backstop problem or the RWA-onboarding problem; they relocate both into third-party code with no committed audit owner. New attack surface, same unsolved problems. 6. Oracle configuration and borrow capsWe agree, with one observation: these are a direct admission that the current design was unsafe. Per-reserve staleness, market-depth awareness, and borrow caps are exactly the controls that would have blunted YieldBlox. We welcome them, and we note that endorsing them while defending the rest of the status quo as "working" is internally inconsistent. They are table stakes, not a vision. 7. Forced withdrawals / permissioned assetsFor a proposal positioning itself to steward v3 and serve institutions, leaving clawback and SEP-57 handling as a list of open questions is the tell. This is the hard part of the RWA mandate — how the protocol safely supports forced-transfer assets without importing centralization into the core — and it is precisely the part left unspecified. Templar's v3 work takes concrete positions here. 8. Stewardship, incentives, and capacityWe'll be direct but fair about this, because it underlies everything above. Capacity. Zenith's public GitHub organization lists a single member, and this proposal is authored by a separate account that does not appear in that membership. Whatever the exact headcount, this is a very small team proposing to simultaneously: (a) own the ongoing security of a protocol that just absorbed a ~$10M oracle exploit, (b) design and audit a new general hook system, (c) onboard and white-glove RWA issuers and LPs, and (d) maintain the core indefinitely. In an environment where exploitation is increasingly AI-assisted, continuous, and adversarial, protocol security is a full-time function, not a part-time one. That scope is not credibly deliverable at this size, and security is the one area where optimism about bandwidth is most expensive. Incentive alignment. The proposal explicitly routes value capture to "apps, curators, integrations, and services built around Blend" while opposing any protocol-level mechanism to fund the core ("avoid protocol-level taxes"). That is a structural misalignment. If all the upside is designed to accrue to the wrappers (the layer the proposer would operate) then who is paid to keep the core secure, and who is paid to do the unglamorous, high-touch RWA onboarding the proposal also defers to that same periphery? A steward that opposes funding the core is, in effect, declining to fund the core. We'd ask plainly: what is the standing incentive for ongoing, sustainable maintenance, and for white-glove RWA issuer service, under this design? One factual note, offered without malice. The proposal cites Orbit as evidence of build capability "from scratch." Orbit's public UI is a fork of Where this leaves usWe share the goal of a minimal, reliable, composable primitive, and we support borrow caps, per-reserve oracle configuration, and timelocked oracle updates without reservation. Our opposition is to the two choices at the center of this proposal:
|
Beta Was this translation helpful? Give feedback.
-
Backstop philosophy“The backstop failed because it didn’t cover an oracle rug on a pool someone else ran” YieldBlox wasn’t the protocol backstop failing in its intended role, it was a pool operator using a spot-price VWAP oracle on thing SDEX liquidity for USTRY. The backstop LP did exactly what it’s supposed to do. Sure, that only covered a fraction of the hole but you can’t insurance against an infinite leverage on manipulated inputs with finite capital unless you’re running a Ponzi. BLND should correlate to the protocol health since it’s pretty much aligned to skin in the game. I like to relate BLND to HYPE since they act in a similar fashion in one category, in this sense being the ability to make custom “markets”. On Hyperliquid you need HYPE to make HIP-3 markets and BLND to make Blend markets. So when things are calm, backstop grows with the rest of the protocol. In crisis, yeah value drops but that’s why proper configs exist. Every first-loss mechanism has correlation risk, the alternative is just history imo For institutions, fair point on liquidity and pricing. But that is just until you remember this is post-incident and it also being an early stellar dapp. You are comparing apples to oranges, many have inflated tokens from governance theaters or emissions farming. Low FDV could also just mean more room to grow Institutions are probably going to go down an OTC lending scenario imo, like they would want more control so a curator vault or OTC lending vault would be more ideal for them. Where then you can abstract it away. You will likely see someone adding the RWA to their own pool like what is being done with etherfuse. Allowing pool operators to attract better backstop capital by sharing upside isn’t skimming. It marginally would thin the buffer, instead it would probably incentivize quality over zombie pools. Maybe the yieldblox pool could have that cut be controlled by their DAO which then gives them more capital, which would incentive more people to hold their token / get involved. RWA “around Blend, not inside it”99.9% XLM/USDC/EURC deposits is the strongest argument for keeping RWA logic modular. I know that right now its hard to integrate RWA tokens into blend and I said I would want to figure out how to make it work for the core protocol. I am not saying keep RWA out of core. But things like permissioned pools / curated could be built on top right now. This is still early in comparison to other DeFi protocols, and also if you just look at the assets on Stellar 99% is just those tokens. The biggest non-rwa related / wrapped token is AQUA, there isn’t an array of coins that people are trading like on Solana so there really isn’t much to do there. That liquidity for xlm/usdc/eurc all exist today so it just makes sense that would exist. RWAs issuers won’t just magically appear because you make blend into this protocol filled with every compliance, tenor, or legal wrapper into the core protocol. They come from issuers who need configurable rails, for example when I talked with the Arf team in Rio they said bluntly is if they can get good rates for loans they would borrow where the liquidity presents itself. My point of keeping it around blend isn’t supposed to be like status quo cope, its to keep the core simple and permissionless. My idea with hooks + external curators/issuers handles the kyc flows, oracle feeds for illiquid paper, or like jurisdiction-specific compliance. That creates the composability needed instead of one big blob trying to do everything. Fair critique on execution risk, but pretending the alternative with force RWA into the immutable core magically solves onboarding is fantasy. White-glove RWA is hard precisely because of the off-chain realities you listed. I am going to make another discussion post of the OTC lending protocol I want to build on top of Blend that solves most of these issues. Uniswap of lendingCalling Blend “the Uniswap of lending” is about it being permissionless, isolated pool creation with efficient backstopping. Uniswap through hooks was able to build so many cool applications layers on top, for example I really like panoptic which makes a very cool way of building options on top of the Uniswap LP. Today it’s XLM/USDC/EURC, that’s not a shocker since that’s just where all the liquidity and demand is on Stellar. We don’t have thousands of coins that people would actually lending and borrow with. The architecture is built exactly so the long tail can arrive with new collateral types, rwa tranches, whatever. Uniswap didn’t shop with 5000 pairs on day one either. Fixed rate via "config magic," fixed duration as "OTC on top"Fixed rate: The current reactive is deliberately made for capital efficiency. You could do it now just a bit of work. Fixed duration: I’m not being contradictory, institution-friendly doesn’t mean stuffing rigid logic. Institutions can get fixed-rate/term products through dedicated maturity pools, OTC desks, and wrappers built on top. For example someone can build a protocol like loopscale right now on Blend and the pro for them is Blend would handle the liquidation, backstop, accounting, etc. Hook systemValid concerns. I do agree it does widen the attack surface and I can agree sloppy implementation adds more risk than value. But that could be said about Uniswap too, they have just as much risk. That said, rejecting hooks outright because ‘new surface = bad’ also inverts priorities. The alternative is a bloated core with a bunch of features that probably the average pool wouldn’t touch. It’s like Uniswap v3 vs v4 is my argument here. If it’s built in a controlled way to add extensibility then it’s good. Oracle configuration and borrow capsCalling these “direct admission that the current design was unsafe” is a bit dramatic. These are the kind of post-incident hardenings you would expect after a poorly configured pool got oracle-rugged. Real gaps in pool operator hygiene was exposed and we are just learning our lesson. Welcoming these controls isn’t me being inconsistency, they should have shipped earlier. But labeling them proof the entire status quo was broken while ignoring what did work is selective. Forced withdrawals / permissioned assetsForced transfers and clawbacks are the hardest part of RWAs because they import legal and centralization risk straight into the asset’s behavior. Hard-coding concrete positions into an immutable core is how you turn a permissionless lending primitive into a compliance hostage. You can also assume bad actors could use this to potential steal money. Stewardship, incentives, and capacityBlend was shipped by a 3-person team as well, who were also in college / just leaving. We shipped a protocol with a tiny crew, capacity isn’t just a headcount. We have already built on Blend and delivered real integrations. Even helping give advice to others building on it too. Opposing protocol-level taxes isn’t misalignment, it’s just keeping the base primitive clean and ungoverned. Value flowing to apps, curators, and wrappers is exactly how you attract capital and builders instead of creating another emission dependent token. People who are building the layers on top of Blend would want to maintain the base layer. Essentially what I wanna do, I want to build my credit application on top of blend and being the steward of the base protocol helps me there Orbit UI being a fork is irrelevant noise, also knowing Blend’s history the protocol ideally wouldn’t need a UI since people would make their own UIs for it. You are also looking at the wrong Github repo, that was for a MVP we had our own UI. |
Beta Was this translation helpful? Give feedback.
-
|
There are multiple logical errors and intellectually dishonest statements in this response. |
Beta Was this translation helpful? Give feedback.
-
|
Fair enough, if you’re willing to be specific, I’d like to know exactly where I was wrong so I can correct the argument |
Beta Was this translation helpful? Give feedback.
-
|
Before going section by section, it's worth naming what we now agree on, because it's most of the factual record:
That's the entire critique I've articulated, conceded. The remaining disagreement is: given all of that, the proposal still keeps the backstop and BLND unchanged. That's not a rebuttal of the critique, it's the critique, restated, with the opposite conclusion. The sections below are mostly about why that conclusion doesn't follow from the facts you've already granted. Backstop philosophy"The backstop did exactly what it's supposed to do" cannot survive the next two sentences. You then write that it "only covered a fraction of the hole" and that the foundation had to step in "to make depositors whole." The backstop's entire job is to make depositors whole as first-loss capital. It didn't; a discretionary bailout did. Whether or not the oracle was misconfigured by the operator, the mechanism whose purpose is loss absorption absorbed ~20% of the loss and a third party covered the rest. That is the definition of the mechanism failing at its job, independent of whose fault the trigger was. The "infinite leverage / finite capital / Ponzi" framing is a strawman. No one asked the backstop to cover infinite leverage. The ask is that first-loss capital be (a) sized to plausible tail loss and (b) paired with mechanisms that bound the loss so finite capital can actually cover it. You propose exactly those mechanisms — borrow caps, circuit breakers. That concedes the point: the backstop alone is insufficient, and the loss must be capped to a coverable size. "The backstop did its job" and "we need circuit breakers so the hole is smaller next time" can't both be true. "Every first-loss mechanism has correlation risk, the alternative is just history" is the one claim I'd push back on hardest, because it's verifiably false. Aave ran exactly Blend's design, a backstop denominated in the staked native token plus a token/ETH LP, and in 2025 deliberately migrated away from it. The Umbrella upgrade re-denominates first-loss capital in stablecoins and aTokens, and Aave's own documentation states the goal plainly: to eliminate "the need to liquidate unrelated tokens like AAVE to cover shortfalls." That is the precise wrong-way-risk problem, and the largest lending protocol in DeFi treated it as a solved design question. BLND:USDC is not the modern standard; it's the design Aave deprecated. Your HYPE analogy actually argues for reform. You're right that HYPE gates HIP-3 markets the way BLND gates Blend pools. But look at what Hyperliquid does with the token: the 500k HYPE stake is a slashable bond, and when a deployer misbehaves the slashed HYPE is burned, not used to cover losses. Losses settle in USDC; HIP-3 markets are isolated and not covered by the shared HLP vault; and HYPE accrues value through a fee-funded buyback-and-burn. In other words, Hyperliquid uses its token as a permission/accountability bond with real value accrual, and denominates the actual loss-absorbing capital in a stable asset, with risk isolated to the deployer. That is the reform: BLND as a slashable skin-in-the-game bond with a fee switch, and stable-denominated first-loss capital. Blend currently does the opposite: it uses the token as the loss-absorbing capital, which is exactly what your own example was designed to avoid. "Remove the only job and you get a useless token" concedes the real priority. This is an argument about protecting the token, not protecting depositors. No one proposed a useless token. We proposed giving BLND a job that works, the HYPE model above (slashable bond + fee-funded value accrual), instead of a job (being the insurance asset) that it has already failed at once. The protocol's purpose is lender solvency; keeping a failed mechanism alive so the token isn't "useless" inverts that. You concede institutions route around the backstop entirely. "Institutions are probably going to go down an OTC lending scenario... a curator vault or OTC lending vault would be more ideal." If that's true, institutions don't touch the backstop or hold BLND, which removes the institutional rationale for preserving either as "core identity." And the take-rate idea makes the core problem worse, by your own words. "It marginally would thin the buffer." After an incident where the buffer was already insufficient, the proposal's headline backstop innovation reduces the first-loss capital further and routes the difference to operators. "Marginally" is unbounded here, and "incentivize quality" doesn't offset reducing the only capital that protects depositors. This is precisely the inversion the critique named. RWA "around Blend, not inside it""99.9% XLM/USDC/EURC is the strongest argument for keeping RWA modular" is a non-sequitur. The concentration is evidence the current design hasn't attracted RWA. It doesn't favor any particular architecture; it's the problem statement, not a solution. The position has also shifted. The original proposal said "most RWA-specific logic should live around Blend rather than inside the core protocol." Now it's "I am not saying keep RWA out of core." That's a welcome move, but it's a reversal, and it concedes the substance of the disagreement. Two of your claims cancel each other. Here you argue there "isn't an array of coins... not much to do there." In the Uniswap section you argue the long tail will arrive. Both can't hold. On Stellar, the only real growth vector left is RWA and you've effectively said so. Which makes RWA not a peripheral around-the-edges concern but the entire thesis. That's the point. The Arf anecdote supports the critique. "They'd borrow where the liquidity presents itself". Yes, and the liquidity lives in deep, safe, institution-acceptable pools. Whether those exist is gated by exactly the backstop/token adequacy under debate. "Issuers go where liquidity is" resolves to "make the venue institution-safe," which is the reform. And the "immutable core stuffed with legal wrappers is fantasy" line is a strawman. No one proposed that. The Templar proposal handles this with permissioned pools and pre-action hooks (Predicate-style) i.e. the "configurable rails" you say issuers need. The designs largely converge; the gap is core-supported vs purely-external, and it's been inflated. Meanwhile the answer to "who does the hard off-chain RWA work" turns out to be "an OTC protocol I personally want to build on top", which is the incentive question, not an answer to it. Uniswap of lendingUnder pressure, the slogan has been redefined from breadth/composability (the Panoptic-style long tail) to "permissionless isolated pool creation with efficient backstopping." Fine, but then it claims nothing differentiating; Morpho and Euler also have permissionless isolated markets, and "efficient backstopping" is the disputed term, so the definition is circular. More importantly, the mechanism doesn't transfer: Uniswap can list permissionlessly because it is the price (constant-product). Blend lending needs a trustworthy external oracle per asset, and for the long tail and RWAs that oracle is the hard, dangerous part as YieldBlox demonstrated. "The long tail arrives automatically" is true for an AMM and false for an oracle-dependent money market. Fixed rate / fixed durationFixed rate "with a bit of work" still isn't a mechanism. A reactive, utilization-targeting controller cannot produce a genuinely fixed rate without decoupling the rate from utilization, which it doesn't do. If there's a configuration that delivers a real fixed rate without weakening the controller, it would settle the point immediately, but it has to be shown, not asserted. The fixed-duration answer contradicts the original proposal. Here you say a Loopscale-style product can sit on top and "Blend would handle the liquidation, backstop, accounting." But your own original post said fixed-duration loans are "a different system with different assumptions around maturity, rollover, liquidity, and default handling." That's correct, a term loan doesn't liquidate on a health factor; it defaults at maturity, which is exactly why Blend's variable-rate, continuously-liquidated machinery doesn't transparently "handle the accounting" for it. Either it's different enough to need core support (your original view) or the existing machinery covers it (your new view). Both have now been argued. Hook systemAgreed that a good hook system could be the best thing in v3, and agreed it widens the attack surface. The critique was never "new surface = bad"; it was sequencing and capacity. "Uniswap has just as much risk" is true in kind but not in capacity: Uniswap v4's hooks took roughly two years and a large security organization with formal verification to ship safely. Citing v4 underscores the resource gap, not closes it. Adding a general hook surface months after a live $10M oracle loss, with a very small team, is the part that inverts priorities. Oracle configuration and borrow caps"We are just learning our lesson" is the admission, so we can drop the argument about whether "unsafe" is too dramatic a word and keep the substance: these controls are needed because the prior design let a pool be oracle-rugged for $10M. That's agreement. The one thing I'd resist is locating the entire fault in "pool operator hygiene." A base primitive that lets an operator trivially configure a spot-VWAP oracle on thin liquidity with no borrow cap and no circuit breaker, and lose $10M, has a protocol-design gap, not only an operator-discipline gap. "The operator held it wrong" isn't an adequate answer for something aiming to be the base layer of Stellar lending. Forced withdrawals / permissioned assetsThis concern is legitimate, and I'll grant it fully: hard-coding clawback into the immutable core would import legal and centralization risk and could be abused. But that's a strawman of the proposal. The Templar approach is permissioned pools and pre-action hooks: opt-in, isolated, never in the shared immutable core. So we agree on the constraint; the open question you list ("is forced_withdraw enough, can the protocol trust token-level forced transfer") is one the Templar proposal takes a concrete position on, and we're glad to work it in the dedicated thread. Stewardship, incentives, and capacityThe "Blend was shipped by a 3-person college team" point cuts the wrong way. Shipping a greenfield v1 is not the same task as ongoing stewardship of a live protocol holding real TVL, post-exploit, in an adversarial AI-assisted environment, while onboarding RWA issuers white-glove and designing and auditing a new hook system. And the small team that shipped Blend is the one whose protocol just took a $10M loss, so the example argues for more security capacity, not less. (It's also worth noting that's Blend's headcount, not Zenith's; the question about Zenith's own capacity to carry all of this is the one that's unanswered.) On alignment, the proposal states the conflict outright: "being the steward of the base protocol helps me there [build my credit application on top]." A neutral base primitive's steward should be incentive-neutral toward the layers built on it. An explicit statement that stewardship advantages one's own app is the misalignment the critique described — not a refutation of it. This isn't a character point; it's a governance one, and it's why the steward of a shared primitive and the operator of an app on top should not be the same party optimizing the base for the app. And "protocol-level value capture hurts composability" is refuted by your own example. Hyperliquid routes protocol fees to a buyback-and-burn (plus the HLP vault and deployers), a protocol-level value-capture mechanism, and it's the most successful token-economic design in the space. A fee switch funding a buyback is precisely how HYPE accrues value without being the insurance asset. So the model you're pointing at as the ideal already does the thing the proposal says to avoid. On Orbit: happy to set the fork observation aside entirely — it was peripheral, and I'll take your word on the repo. Where this leaves usStripped to its logic, the response agrees that the backstop covered a fraction of the loss, that the foundation made depositors whole, that the value drops in a crisis, that institutions can't hold the token and will route around it, that the take-rate change thins an already-insufficient buffer, and that the design needed hardening, and then concludes that the backstop and token should be preserved unchanged. The stated reasons for that conclusion are that the token would otherwise be "useless" and that base-protocol stewardship "helps me" build an app on top. Those are reasons to protect the token and the builder; they aren't reasons the mechanism protects lenders. The reform direction isn't radical or anti-Blend. It's the current state of the art, drawn from the exact two protocols invoked in this thread: stable-denominated, adequately-capitalized first-loss capital (Aave Umbrella), and a token that is a slashable skin-in-the-game bond with fee-funded value accrual rather than the loss-absorbing asset itself (Hyperliquid HYPE). Isolation already works and should stay; the backstop's denomination and capitalization, and the token's role, are what need to change. Per @levinson's framing, the backstop belongs in its own thread with a problem-statement-first structure. I'm glad to open it that way and put both designs side by side on the merits. |
Beta Was this translation helpful? Give feedback.
-
Sorry for the late reply, I hope you know I’m being honest and raising this only because I’m truly invested in Blend’s future. If I am saying anything wrong please let me know.
I agree with some of your points, but that doesn’t mean I think your proposed solution fully addresses the issue. My agreement was with parts of the critique, not the conclusion The backstop did what it was designed for, it absorbed first-loss capital up to its size, froze the pool, and the foundation stepped in to make depositors whole. I think you are mixing up two separate points. A junior tranche/backstop is not meant to fully guarantee the senior tranche in every loss scenario, it is meant to absorb first losses up to its size. So the fact that losses can still reach senior lenders does not, by itself, disprove the concept. The more serious question is whether Blend’s backstop is able to capitalized and appropriately structured for that role, given the BLND-linked collateral and the slippage (comet pool, when YieldBlox backstop liquidation caused BLND price to drop and effected other pool's backstop) risk that creates under stress. Blend's design intentionally uses BLND as the backstop asset because backstop depositors are sophisticated actors who (hopefully) due diligence on pools, queue withdrawals from risky ones, and get paid from interest. Institutions routing via OTC/curator vaults is a feature not a bug imo. It keeps the immutable core clean and permissionless for the long tail while letting serious capital use wrappers. For the backstop too, the size correlates with pool health. Switching to stable-only backstop + BLND bond shifts it toward something more like Aave Umbrella or Hyperliquid (which could be good in some senses) but that adds complexitiy. I personally think the reasoning that making the core protocol bloated to appease institutions will somehow bring them on. If you build these wrappers or protocols on top and abstracted it away by making like a Brale or Blindpay like site where they don't even know they are on Stellar that is 10x more valuable and probably easier for non-web3 firms. That's exactly "around Blend, not inside it" for RWA-heavy stuff. Forcing more into core bloats the primitives and imports the legal/centralization risks you correctly flag. The take-rate adjustment is marginal and pairs with operator incentives to improve hygiene, exactly the "learning our lesson" part. Borrow caps, circuit breakers, better oracle configs, and hooks are coming as upgrades/hardening, not protocol rewrites per se. Fixed-rate/duration can be layered on top without rewriting liqudiation/accounting assumptions. Hooks are high-upside but ye we aren't uniswap v4 yet but making it easier for developers to come in and build, treating blend as like an accounting layer, is the best move. On stewardship, transparency on incentives is good governance not misalignment. Building on the base you steward is how most successful primitives evolve (look at early uniswap labs). The shall team shipped a working v1 that's already powering real yield, using their own tokens as a bug bounty, and community contributions are how we scale security without bloating into a big org.
It was not the core team's fault for the $10M loss, it is up to each pool operator to maintain their own pool. That's like blaming Uniswap for letting pools and tokens rug it's users on it's frontend.
Me building on top of the protocol and not taking a fee or changing the fundamental of the core protocol is more powerful as it would allow other people to come in and also make protocols that they can earn from. This is bad taste since Templar would probably be trying to profit in some way as well, this is something I have been working on even before a v3 was even mentioned.
This was more of an example with the security lock up, IMO hyperliquid is very centralized and really isn't even a "true permissionless dex" that they claim they are. Edit: fixed grammar mistakes |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Blend V3 Proposal
Overview
Zenith Protocols proposes to take an active role in the development, maintenance, and long-term stewardship of Blend Protocol v3.
Our view is that Blend should remain the core lending primitive of Stellar and become the Uniswap of lending. The goal of v3 should not be to turn Blend into a Swiss Army knife of products.
Instead, Blend v3 should make the primitive stronger, safer, and easier to build on top of.
Zenith’s proposal focuses on four main themes:
Blend should be the Uniswap of lending on Stellar. The base protocol should stay minimal and reliable, while businesses, curators, vaults, credit products, and institutional integrations compose around it.
I am following the writing style of the Templar post for ease of comparison.
Updates
RWA Focus
Zenith supports making Blend more institution-friendly, but we believe most RWA-specific logic should live around Blend rather than inside the core protocol
Institutions need custom configurations like LTVs, liquidation thresholds, oracle setups, compliance checks, collateral rules, tenor preferences, and asset-specific risk logic. Blend v3 should make these configurations easier to support, but it should avoid becoming a Swiss Army knife protocol where every institutional use case requires a new pool type or protocol-level feature
Priorities
Fixed Rate / Fixed Duration
Fixed-rate lending may be possible through smarter pool configuration and external market structure. This is worth exploring if it can be done without weakening the core interest rate controller or adding unnecessary complexity. This could actually already be done with some config magic
Fixed-duration lending should not be added directly to the Blend core protocol. Fixed-duration loans are a different system with different assumptions around maturity, rollover, liquidity, and default handling. They make more sense as an OTC or higher-order product built on top of Blend rather than as a native pool feature
In narrow RWA or institutional credit cases, fixed-rate / fixed-duration structures can still exist. They should just be implemented through external contracts, curators, order book mechanics, or OTC-style systems that use Blend liquidity underneath
Developer Focus
Zenith is strongly in favor of making Blend more developer-friendly, but strongly against turning Blend into a bloated application layer
The biggest unlock for Blend v3 is a well-designed hook system
Zenith built Orbit from scratch on Stellar, and one of the clearest lessons from that process is that builders often need custom logic around lending markets. Today, that usually means writing extra contracts, increasing audit surface, fragmenting liquidity, or rebuilding functionality that should be easier to compose with
Hook System
Blend v3 should explore pre-action and post-action hooks for key protocol actions.
Potential hook categories:
The hard part is deciding what actions should support hooks. In Blend, submissions can do many things, so the design needs to avoid becoming too open-ended or dangerous
The hook system should be powerful enough for real builders, but narrow enough that the core protocol remains safe and understandable
If hooks become the centerpiece of Blend v3, they must be designed very carefully. A bad hook system could introduce more risk than value. A good hook system could become the main reason v3 is worth doing
Wanna see how hooks can be for developers? Check out all the cool hooks built on Uniswap by open-source developers here
Backstop Philosophy
Zenith does not support removing or weakening the Blend backstop.
Ditching the backstop is effectively ditching the BLND token. At that point, the protocol is no longer really Blend v3; it becomes something closer to a different lending system entirely.
The backstop is one of Blend’s defining mechanisms and should remain part of the protocol’s identity.
That said, the backstop take rate is effectively a protocol-level tax and can be discussed as a configurable parameter. Any changes to how value flows through the backstop should be handled carefully and separately from the broader v3 upgrade. An idea I personally like is making it configurable in a way that allows pool operators to take fees from it.
Priorities
Risk Management
Zenith supports practical risk improvements that make Blend safer without overcomplicating the protocol.
The most obvious addition is borrow caps.
Borrow caps allow pools to limit exposure to specific assets and reduce the risk of a single reserve creating systemic issues. This is especially important for new assets, long-tail collateral, RWA assets, and assets with weaker liquidity.
Borrow Caps
Borrow caps should be configurable by pool creators and adjustable through existing governance or timelock mechanics.
Benefits:
Oracle Configuration
Zenith agrees that oracle logic should mostly remain external where possible, but Blend v3 should improve how oracles are configured and applied.
Current oracle assumptions are too broad. A blanket staleness window does not work equally well for volatile assets, stable assets, pull oracles, and RWA assets.
Blend v3 should consider:
A 24-hour blanket oracle setting is too blunt. Stable assets and volatile assets should not necessarily share the same oracle rules.
Note, there is probably more stuff that can be added here to make the protocol safer but these were the ones that stuck out most to me.
Forced Withdrawals / Permissioned Assets
One area that needs more design work is how Blend should handle assets with forced transfer or clawback-like behavior.
For example, if a SEP-57-style token supports forced transfers, Blend needs to understand whether forced withdrawals are enough and whether the protocol can safely rely on the underlying forced transfer call.
This is especially relevant for RWA assets, permissioned assets, and regulated entities.
Open Questions
forced_withdrawenough for these assets?This should be explored carefully before Blend v3 supports more permissioned or RWA-heavy use cases.
Breaking Protocol Changes
Zenith believes Blend v3 should avoid unnecessary breaking changes.
Potential Protocol-Level Changes Worth Exploring
Changes Zenith Does Not Currently Support in the Core Protocol
Beta Was this translation helpful? Give feedback.
All reactions