Living Assets, Security Matters: Can Solv Guard Put the Nested Risk in a Cage?
TechFlow Selected TechFlow Selected
Living Assets, Security Matters: Can Solv Guard Put the Nested Risk in a Cage?
With Solv Guard, Mom doesn't have to worry about me playing DeFi matryoshka anymore.
Navigating Web3 tides with focused insightsAuthor: Peng SUN, Foresight News
When thinking about this cycle of DeFi, what comes to mind first? Obviously, it's nesting—nesting all the way down!
But nesting is just the surface; the real shift lies in the paradigm change at the asset issuance layer. In traditional DeFi, liquid assets were native base-layer assets like ETH. Today, however, liquidity has been wrapped—stETH, USDe, puffETH, rzETH, and countless other newly issued assets now dominate. Colloquially known as yield-bearing assets, these are backed by underlying native assets that secure Ethereum economically and generate returns through various financial channels. Yet security concerns persist: while any protocol can issue new assets, native assets are still managed via multisig wallets or centralized third parties, leaving single points of failure unresolved.
Indeed, this challenge represents a critical dilemma for today’s mainstream emerging DeFi protocols and their users. Is there a universal security solution applicable across similar DeFi protocols industry-wide? Currently, the only viable answer is Solv Guard—a universal security mechanism developed by Solv Protocol, a full-chain yield and liquidity protocol. In this article, I will trace the evolution of DeFi asset management to unpack and deeply analyze this innovation.
I. DeFi Summer: Algorithmically Controlled Assets
DeFi Summer in 2020 was nothing short of legendary in the crypto world. Protocols such as Uniswap, Bancor, Aave, Compound, and MakerDAO laid the foundation for DeFi's growth. The advent of Automated Market Makers (AMMs) and "liquidity mining" demonstrated to traditional finance the revolutionary potential and logic of crypto. From the perspective of user yields and asset management, behind AMMs and liquidity mining lay simple, isolated liquidity pools. Users had to manually interact with each mining pool individually, depositing and withdrawing across multiple platforms. Because each pool operated independently, users struggled to efficiently allocate funds to the highest-yielding opportunities. This isolation made operations cumbersome and limited potential returns.
To address these issues, Yearn introduced yield aggregators (commonly known as "gun pools"), allowing users to deploy assets via smart contracts into multiple liquidity pools automatically, optimizing returns. Ultimately, yield aggregators represent a form of passive asset management. During this era, whether involving swaps, lending, or gun pools, fund safety and yields remained constrained by the limitations of base pools. In other words, while yield aggregation simplified asset management for users, the underlying pool logic did not evolve.
II. The Ethereum PoS Era: Yield-Bearing Assets and Active Asset Management
With Ethereum’s transition from PoW to PoS, ETH staking introduced new models and dynamics to DeFi. Take Lido, for example: on December 1, 2020, the Ethereum Beacon Chain officially launched, and Lido went live the same month. Under Ethereum’s PoS mechanism, running a validator node requires staking at least 32 ETH. Lido enables users holding less than 32 ETH to participate by pooling fragmented deposits into full validator-sized amounts, thereby maximizing security for the Ethereum mainnet. Lido also addresses the liquidity constraints imposed by staking—since staked ETH cannot be freely moved, reduced capital efficiency discourages some users from participating, threatening network security. To solve this, Lido allows users to receive staked ETH (stETH) upon deposit, resolving both security and liquidity challenges.
Lido catalyzed a new model of asset management—“active asset management.” Instead of directly interacting with liquidity pools or passive yield aggregators, users entrust professionals to manage their assets. While common in traditional finance, Lido advanced this model within DeFi by integrating yield-bearing instruments. Effectively a CeDeFi hybrid, Lido combines centralized components with decentralized infrastructure, offering users higher-quality yield sources through semi-centralized, semi-decentralized methods. Notably, Lido plans to deploy its Simple DVT module on mainnet soon, further decentralizing its staking approach. After three years of development, this active, yield-generating staking model has become dominant in DeFi:
-
At the end of last year, Blast expanded this staking-based yield model, amassing $1 billion in assets within just one month using only a multisig setup.
-
The restaking sector is even more pronounced—Ethereum’s restaking ecosystem already totals $14.8 billion, with most projects relying on multisig governance from inception.
-
Bitcoin restaking infrastructure BounceBit relies on “off-exchange settlement,” delegating custody trust to third parties such as Ceffu, MainNet Capital, Antalpha, and Fireblocks.
-
Decentralized stablecoin protocol Ethena similarly uses “off-exchange settlement,” placing trust in third-party custodians including Cobo, Ceffu, and Copper.
-
Ondo Finance, focused on U.S. Treasury RWA, follows standard fund structures, entrusting funds to regulated qualified custodians such as Clear Street.
-
......
III. From Compound to Solv Guard: How Should Assets Be Managed?
Let us first examine how the asset layer of DeFi protocols has evolved, as the rise of yield-bearing models has brought structural changes to DeFi’s asset architecture.
During DeFi Summer, protocols relied purely on algorithmic control via smart contracts. Users could redeem assets at any time, and all holdings and earnings were in native base-layer assets. However, these models no longer meet growing user demand for yield. As DeFi scaled, returns across protocols converged, reducing differentiation. Moreover, purely algorithmic DeFi protocols function as static contracts, ill-equipped to handle complex yield-generation mechanisms. Specifically, yield-bearing assets follow a two-tier structure: the base layer consists of native tokens like BTC, ETH, and USDT, while the upper layer includes yield-bearing tokens such as stETH, USDe, and LRTs. This structure necessitates broader yield sources beyond basic staking and mining, leading to increasing divergence among underlying liquidity pools under active asset management. As yield-bearing assets serve as the liquidity layer, they maintain a pegged relationship with their underlying assets, but redemption periods vary.
Given this new dual-layer asset structure, novel counterparty risks emerge. At its core, “active asset management” involves reusing user funds and issuing pegged tokens as liquid assets. Although funds may be secured through mechanisms like multisigs, off-exchange settlements, or regulated custodians, centralization gaps remain. For instance, User A sends funds to Protocol B, which then deploys them into restaking, entrusts them to third parties, or trades them on centralized exchanges via off-exchange settlement. Here, control over fund usage is entirely transferred to project teams and custodians. In other words, mainstream DeFi protocols combining CeFi and DeFi elements all face counterparty risk stemming from the “asset manager” role.
Thus, the problem transforms into one of supervising and constraining the “asset manager.” What viable strategies exist today? Currently, the only practical solution observed is Solv Guard—a universal security mechanism built by Solv Protocol, a full-chain yield and liquidity protocol. Designed for personalized trading strategies across different pools, Solv Guard imposes customized operational boundaries on asset managers—such as permitted destinations, use cases, and action permissions—effectively preventing opaque misuse of funds.
This concept isn’t invented out of thin air—it traces back to Compound during DeFi Summer. Those familiar with Compound know its cToken mechanism pioneered yield-bearing assets. Compound’s governance module also anticipated associated risks, introducing a safety framework. In both v2 and v3, the contract code includes a component called “Pause Guardian.” Activated only in case of unforeseen vulnerabilities, its sole function is to disable minting, borrowing, transfers, and liquidations—acting as a referee who pauses the game during emergencies without authority to resume it. During the USDC depegging event triggered by Silicon Valley Bank’s collapse last year, it temporarily disabled USDC deposits in Compound v2.
Compound envisioned a security constraint for assets but never extracted it as a standalone module. Solv takes that idea and abstracts it—because DeFi has evolved into the era of active asset management, where yield-bearing assets will become the cornerstone of next-gen DeFi. With yield sources expanding beyond single pools to include traditional finance, Solv Guard aims to serve as a universal security mechanism applicable across all similar models and protocols.
IV. Solv Guard: Operation Mechanism, Features, and Capabilities
After laying out the background, we finally arrive at the core topic. Let’s explore why Solv Guard qualifies as a universal security mechanism, how it operates, and what features and advantages it offers.
If we must define Solv Guard’s position, it serves as an intermediary layer between base assets and user assets—an additional security mechanism layered atop smart contracts. It functions both as a tool and a product, aiming to become a widely adopted industry-standard security component.
Operation Mechanism
In terms of operation, Solv Guard is currently built on the Safe smart contract wallet. Safe inherently supports multisig functionality, which forms part of Solv Guard’s security framework. The key innovation is restricting Safe’s multisig actions within predefined boundaries.
In practice, Solv Guard assigns a Vault Guardian to each vault. The Vault Guardian specifies target addresses and their permissions. Both Safe and Solv Guard validate transactions before allowing execution.
As shown below, configuring permissions requires defining three elements: allowed contracts, permitted function calls, and whether ACL (Access Control List) is required. Breaking it down: you can specify who has authority over funds, which contract addresses funds can be sent to, which investment targets are permitted, and under what conditions withdrawals can occur.
Take Uniswap as an example: suppose an asset manager wants to deploy our funds into Uniswap to provide liquidity and earn fees—the primary yield source. How should Solv Guard be configured? First, define who has investment and withdrawal rights. Then restrict the destination to the Uniswap smart contract address since funds flow there. If providing ETH/USDT liquidity, further limit the LP pool contract and the ETH and USDT token contracts, authorizing only those two tokens—preventing the manager from manipulating other assets.
Of course, asset managers might also use funds to buy U.S. Treasuries, invest in other assets, or engage in derivatives trading. Solv Guard’s built-in Authorization system already supports platforms including Uniswap V3, GMX V2, Compound, Lido, Ethena, PancakeSwap, and more.
Governance Mechanism
Like Compound’s Pause Guardian, Solv Guard implements a governance mechanism that separates governance rights from operational control.
As illustrated below, the Solv Vault Guardian executes actions, while governance authority rests with the Governor. The Governor can be controlled by the community, asset managers, or other entities, and may incorporate Timelock mechanisms to ensure user awareness and choice. Governor privileges include upgrading the Guardian (e.g., if a contract bug prevents fund retrieval), adding or removing Authorizations, enabling or disabling native token transfers, managing whitelist addresses, transferring Governor rights, inheriting Guardian Governor permissions when necessary, and permanently disabling governance functions.
Future Development
To date, Solv Guard stands as the earliest initiative inspired by Compound and enhanced by Safe Wallet’s inherent security model, enabling rapid adoption.
Looking ahead, Solv Guard aims to expand into general-purpose smart contract development, forming a standardized security framework that enhances security across all types of smart contracts. For example, the next version of Solv Vault will no longer rely on Safe multisig wallets but will still employ the Guard framework to safeguard asset handling processes, improving overall contract security while maintaining flexible security policy definitions. This could eventually lead major protocols like Compound to adopt or reference Solv Guard, promoting more standardized and transparent smart contract security controls.
ERC-3525
Returning to yield-bearing assets, I must mention ERC-3525, given its deep integration with Solv Guard’s architecture. ERC-3525 is a semi-fungible token standard proposed by core members of Solv Protocol, combining features of ERC-20, ERC-721, and ERC-1155. It is particularly well-suited for representing currencies, securities, tickets, bonds, options, futures, insurance strategies, and more, offering strong composability.
The ERC-3525 structure comprises four components: id, value, slot, and address. Each slot can contain multiple ids, and each id holds a distinct value. In simple terms, each slot acts as a master account with multiple sub-accounts capable of transferring value among themselves.
* For more on ERC-3525, see "Undervalued ERC-3525: A Path Toward Web3 Mass Adoption?"
Currently, Solv Guard primarily supports assets issued under the ERC-3525 standard because ERC-3525 can manage numerous underlying assets (e.g., ERC-20 tokens) through a single contract. As previously noted, active asset management follows a two-tier structure. Under a unified liquidity layer, base assets flow into countless pools. By defining each pool as a slot, a single ERC-3525 smart contract can manage countless pools. For diverse user requests—such as varying redemption periods—ERC-3525 can manage multiple tasks within one contract.
Overall, ERC-3525 is highly suitable for active asset management and yield-bearing assets, offering lower development costs and stronger security. However, Solv does not require all projects to adopt ERC-3525—it remains compatible with ERC-20.
Conclusion
By now, you’ll realize that the Solv team is establishing a universal industry security standard and framework—not arbitrarily, but by abstracting a much-needed, productized toolkit from the history of DeFi asset management. Indeed, yield-bearing assets are becoming the dominant paradigm in DeFi. We cannot dismiss the importance of centralized intermediaries in DeFi, nor can we fully trust them. What we *can* do is place asset managers operating under similar models/protocols inside the “cage” of Solv Guard—adding a security layer to protect the entire DeFi ecosystem.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
Foresight News
