Executive Summary

Vault Street is the onchain investment platform built by Resolv Labs, the team behind the USR stablecoin. After the March 2026 Resolv incident, the team redesigned its security architecture and adopted Utila as part of a layered approach to managing funds. Its current model combines distributed approvals and narrowly defined wallet permissions with contract-enforced limits and external oversight.

The case illustrates how DeFi security best practices become concrete operating requirements. Building or evaluating onchain yield products requires understanding what a compromised account could authorize, who can change its permissions, and what stops suspicious activity once detected. Vault Street’s approach provides examples of these controls in practice, alongside a necessary distinction between operational security and the risks of the underlying investments.

The Security Behind the Yield

On March 22, 2026, Resolv was hit by a sophisticated, multi-stage attack. Starting from a third party service, the attackers worked their way into the offchain service that authorised USR minting, then minted 80 million unbacked USR and extracted approximately $25 million in ETH. 

Pre-hack USR holders were subsequently compensated 1:1, and other affected parties were addressed separately.

The minting contract accepted instructions authenticated by that authority without independently constraining the relationship between collateral deposited and tokens issued. Compromising the offchain service therefore gave the attackers access to a financially dangerous operation that the contract would accept.

That failure has implications for lending, borrowing, and other ways of earning stablecoin yield. Evaluating the underlying assets answers part of the investment question. The systems managing those assets also need limits on how much authority an operational failure can expose.

Resolv’s official post-mortem as well as our earlier Resolv analysis examined the governance gaps behind the incident. Vault Street’s subsequent work offers the next part of that discussion: how a team translates those lessons into a different operating model, and what others can learn from the resulting controls.

A Rebuild Around Distributed Authority

One detail in Resolv’s postmortem explains the importance of administrative governance. After initial attempts to obtain signing access were blocked, the attackers used a privileged role to change the key’s access policy and grant themselves signing authority. Protecting the ability to rewrite security rules therefore deserves the same scrutiny as protecting the ability to move funds.

Vault Street applies that principle to two investment products: primeUSD, which allocates to short-duration instruments including tokenized Treasuries and structured credit funds; and CARRY, which combines tokenized private credit with market-neutral onchain positions. Their operations include lending, borrowing, and tokenized asset investments.¹

The team had already been using an MPC wallet provider, but after the incident it moved its wallet operations to Utila as part of the broader security redesign. The improvement went beyond MPC key management: each Vault Street product now has a separate Utila vault with its own members, address book, policies, and admin quorum, while transaction permissions can be restricted down to specific contracts, methods, assets, recipients, and parameters. That gave the team a more granular control layer for day-to-day execution and administrative changes.¹

A restrictive transaction rule loses its protective value if one compromised account can rewrite it. Vault Street also exports its policies for review by a security partner, giving reviewers a concrete record of permitted actions and approval requirements.¹

Practical takeaway: Review who can change the rules

Alongside transaction approvers, identify who can add destinations, relax limits, or change approval requirements. Include the authorization process for those changes in the security review.

Protecting policy changes allows day-to-day operators to receive narrowly scoped permissions while reserving the authority to alter those permissions for a separately governed process.

Narrow Permissions for Complex Operations

Investment managers need to adjust positions as market conditions change. Their transaction permissions should describe which adjustments an operator may make, including the intended beneficiary and the amount a contract may spend. Vault Street implements this through a default-deny configuration: each wallet can perform only activities the team has explicitly allowed.¹

On Ethereum and Base, the team specifies permitted smart contracts and methods, then enforces conditions on individual transaction parameters through EVM CEL, an expression language for defining conditions. For a lending interaction, that can mean restricting the account credited with the position through recipient or onBehalfOf fields, as well as which assets can be deposited or withdrawn. The team also limits token approval amounts, restricts swap assets, enforces approved destinations and amount limits across all transfers, and validates the methods and parameters bundled inside multicall transactions.¹

These controls let Vault Street translate a strategy’s operating rules into enforceable transaction permissions. Permission to use a lending protocol can be tied to particular functions and approved beneficiaries, rather than granting unrestricted interaction with every function at that address.

Utila's policy controls also give the team an alternative to developing and auditing custom smart contract adapters for many interactions. That helps it adjust investment activity while maintaining explicit restrictions on execution.¹

Practical takeaway: Test the transaction that should fail

In a controlled environment, change an approved transaction’s recipient or exceed its permitted token allowance. Verify that the complete configuration rejects it, and repeat the test after relevant policy changes.

For swaps and leveraged positions, acceptable execution also depends on prices and collateral conditions at that moment.

Verification Before Capital Moves

A borrowing transaction may fit its wallet’s permissions and still leave insufficient collateral protection against adverse price movements. Aave, for example, measures that protection through a position’s health factor, which changes with collateral and debt values. Transaction review therefore needs to consider the position’s financial condition alongside the permitted contract call.

To address this, Vault Street adds its backend as an approver for checks that EVM CEL cannot perform alone, including slippage and lending-position health factors. The backend also supports verification for Solana activity, where EVM CEL does not apply. It examines the proposed transaction payload and performs the additional checks before approving it.¹

The backend does not sign transactions, and a human signature remains required. This preserves a separate signing step while allowing the team to automate parts of transaction verification.¹

The person preparing a transaction also uses simulation in Utila's browser extension to inspect its expected effects before requesting further approvals. Fedor reports that this helps the team identify potential mistakes earlier and reduce approval back-and-forth.¹

Together, these controls make the decision before signing better informed. The architecture still needs a response for suspicious activity that has already reached the blockchain.

Closing the Response Gap After an Alert

Resolv’s monitoring detected suspicious activity early in the attack, but containment took longer than detection. That gap matters because monitoring only reduces risk when alerts trigger a fast, clearly defined response.

Vault Street’s current architecture connects continuous monitoring with automatic smart contract freezes, working with Hypernative and Hexens. Its contracts also enforce supply caps and price-movement bands. These safeguards address different stages of a potential incident: constraining accepted operations and restricting further activity when specified risks are detected.

The design makes high-impact configuration changes deliberately slow through a 48-hour timelock, while contract upgrades and parameter changes require Vault Street and external signers. That creates a useful distinction between expanding authority and exercising a pre-authorized emergency restriction. (Vault Street)

A system can require time and independent approval to widen its permissions while allowing a tightly scoped response to act quickly. Evaluating both paths reveals whether incident response has been designed with the same care as routine execution.

Practical takeaway: Measure the response

Request a drill showing the time between an alert and a confirmed protective action. Establish which contracts can be paused, what remains exposed elsewhere, and who authorizes resumption.

Security Within the Investment Decision

The controls described above govern how Vault Street moves capital: who can authorize a transaction, what that transaction may contain, and how quickly activity can be restricted when something looks wrong. These controls are important, but they have limits.

Once funds have been intentionally deployed into an external protocol or investment, the safety of that capital also depends on the underlying smart contracts, liquidity, counterparties, and market conditions.

That distinction matters for anyone assessing a stablecoin yield product. Strong wallet governance can reduce operational risk, but it cannot prevent a lending protocol from suffering a smart contract exploit, liquidity from disappearing during market stress, or an underlying borrower from defaulting.

Vault Street’s primeUSD and CARRY products allocate capital across onchain protocols and tokenized assets, while also using leverage. Assessing those products therefore requires looking at two separate layers: how Vault Street controls and executes transactions, and what risks the underlying investments introduce once those transactions have been approved.

The second layer can be evaluated across a few core risk categories:

Aave provides a practical example of the boundary between these risks and transaction controls. Withdrawals depend on available pool liquidity, while borrowing positions require ongoing attention to collateral coverage. A correctly authorized transaction can therefore require further risk management long after execution.

DeFi risk management should follow both the investment exposure and the authority used to manage it. Evidence of strong controls helps establish what an operator can do; assessing the investment determines whether the resulting exposure fits the mandate.

A Stronger Foundation for Onchain Yield

Vault Street’s rebuild gives substance to a question every post-incident recovery should answer: what has changed in the authority that could expose client capital? Its current model places restrictions at several points in the investment process and makes parts of that configuration available for independent review.¹

These practices already support the team’s lending, borrowing, and tokenized asset investment workflows. As those activities evolve, maintaining confidence requires keeping the security evidence current: reviewing changed permissions, testing response procedures, and reassessing infrastructure dependencies.

Utila supports the wallet and transaction-governance part of that work. Book a Utila demo to examine the controls behind your intended stablecoin yield operations. Bring a representative workflow so we can help you evaluate approval structures, parameter-level restrictions on supported networks, and where your architecture needs additional verification or protocol-level safeguards.

Frequently Asked Questions About DeFi Risk Management

What are the key risks in DeFi?

The key risks in decentralized finance depend on where and how capital is deployed. They can include smart contract risk, protocol risk, liquidity and market risk, counterparty exposure, and governance risk when a small group can change important protocol parameters. Operational controls over wallets and approvals can mitigate some potential risks, while risks inside the underlying DeFi protocols require separate assessment.

How should teams assess DeFi protocols?

Start by understanding what happens to user funds after a transaction executes. Review the protocol’s smart contracts, audits, governance structure, upgrade authority, liquidity, dependencies, and the underlying assets generating the return. For strategies involving tokenized credit, money market funds, or other financial assets, the diligence process should also examine the issuer, asset manager, redemption mechanics, and relevant counterparties. Vault Street for example constantly publishes deep dives about the assets included in their vaults.

What does proactive DeFi risk management involve?

Proactive risk management combines preventive controls with ongoing oversight. Effective risk management strategies define which transactions are permitted, apply appropriate approval requirements, monitor positions after deployment, and establish clear responses when conditions deteriorate. Risk management tools can support these processes, but the relevant mitigation strategies depend on whether the exposure comes from wallet operations, smart contracts, markets, counterparties, or protocol governance.

How does DeFi risk differ from traditional finance?

Decentralized finance introduces technical dependencies that are less prominent in traditional finance, including smart contract vulnerabilities, wallet permissions, oracle dependencies, and protocol governance. At the same time, familiar financial risks such as liquidity, leverage, credit exposure, and counterparty concentration remain relevant. Regulatory uncertainty can add another layer, particularly where digital asset products combine onchain protocols with tokenized securities, credit instruments, or other digital assets.

¹ Source: Resolv's Founding Engineer Fedor Polshchikov’s written technical input supplied for this article.