DeepSafe × CertiK 2026 Institutional Digital Asset Governance Study | 100 Projects and Service Providers

DeepSafe and CertiK conducted a joint study on institutional stablecoin payments, project treasuries and on-chain investing, examining how institutions divide trading permissions, constrain investment scope, and handle funds in abnormal situations.

The study reviewed the official documentation, product descriptions and relevant code of 100 projects and service providers, recording evidence by business type and control mechanism. The report follows the actual operating sequence of institutional funds: what operational permissions the team holds, how investment rules are modified, and how to exit or recover after an incident.

Sample cases show that institutions can hand day-to-day fund operations to an execution team, but should separately approve changes such as expanding the investment scope or raising limits, and set independent, restricted permissions for emergency pause, withdrawal and recovery.

This division of labor lets the team keep operating within established bounds while preserving opportunities to review newly added risk and handle anomalies. Emergency capability ultimately comes down to one business outcome: whether funds can return to a usable account when needed.

Key findings

1. Of 30 asset management projects, 11 disclosed specific investment restrictions

These 11 projects explicitly restrict the markets that can be entered, the assets that can be used, the functions that can be called, or the size of funds. Cases such as RockSolid and Nerona separate strategy admission from day-to-day allocation, so operators can work within established bounds while new investment directions require separate approval.

1. Of 50 projects, 16 disclosed or supported waits on rule changes

Of the 50 projects that describe rule-modification permissions, 16 also describe or support a change-waiting mechanism, or 32.0%. Feather, Neverland and others go further and divide actions: newly added risk keeps a review window, while lowering limits or an emergency pause can be executed quickly.

1. 20 projects describe pausing, 7 disclose exit-related arrangements

These 7 include fund withdrawal, liquidity withdrawal and orderly exit after a participant is replaced; they cannot be read as 7 projects where funds can be retrieved immediately. Another 3 describe key recovery or replacement of signing participants.

The common thread across these cases is: give day-to-day operations to the execution team, manage decisions to expand the investment scope and loosen rules separately, and set clear, restricted permissions for emergency handling.

Contents

Scope and methodology / Investment restrictions / Rule changes / Emergency arrangements
Business analysis and research conclusions / Sources and research notes

Data cut-off: October 28, 2026; statistical evidence re-verification: November 3; case detail re-verification: November 5. Ratios reflect disclosure in documentation or support in source code and do not represent production enablement rates.

100 projects cover five types of fund business

Scope and methodology

The objects of study include digital asset payment, investment, lending and issuance services. They are grouped by initial primary business, with each object counted in one group, for 100 in total.

Lending and credit operations focus on loans, collateral and protocol funds; asset management and strategy operations focus on vault investment and fund allocation; payments and payroll focus on enterprise disbursements; RWA and issuance operations focus on the on-chain issuance and management of real-world assets; other categories include cross-chain and related protocol fund operations.

Methodology

Based on official documentation, help centers, product descriptions and accessible code, four types of facts were recorded item by item: personnel and signing permissions, transaction or investment restrictions, rule-modification permissions and the conditions for taking effect, and pause and recovery arrangements after an incident. Each record corresponds to a source URL, product or version, and the specific content supporting the judgment.

The evidence ledger indexes 140 distinct source URLs. Of the 100 objects, 64 had at least one mechanism meeting the main statistical criteria identified, while 32 had limited documentation or a main mechanism that was not confirmed; 4 involve historical migrations or pre-release designs and are excluded from mechanism statistics for now. The 64 objects cover signing and personnel permissions, transaction or investment restrictions, rule modification and emergency arrangements — not only the three main findings below.

Statistical scope

Each metric uses the denominator of its applicable business: investment restrictions use the 30 asset management projects as the denominator; change waiting uses the 50 projects that describe rule-modification permissions; emergency arrangements use all 100 objects. Mechanisms may overlap. Documentation disclosure, source-code support and production enablement are treated separately; this report's ratios cover the first two and do not judge undisclosed items as absent.

Signing technology and business approval are recorded separately. MPC lets multiple parties use key shares to jointly generate a signature; multisig typically has different keys sign separately, with an on-chain program then checking the number of signatures. Business approvers need not be the same as signing participants. Admin change waiting and customer redemption waiting are also counted separately.

The report analyzes public designs and their business implications. Named cases are described according to the corresponding product and version; public materials are insufficient to confirm actual configuration, execution effects and recovery times.

Of 30 asset management projects, 11 disclosed specific investment restrictions

Finding one: Investment restrictions

Of 30 asset management and strategy projects, 11 explicitly describe investable markets, assets, contract functions or fund caps, or 36.7%. These projects refine authorization down to a specific operational scope rather than only listing who can sign.

RockSolid: Strategy managers can allocate funds, new strategies require joint approval

In the rETH vault example, RockSolid acts as distributor. The strategy manager proposes a new strategy, and RockSolid takes part in whitelist approval through an MPC process. The strategy manager can then configure and rebalance assets among approved strategies; all transactions must comply with signing rules, and requests that do not comply are rejected.

Net asset value (NAV) also follows a division of labor: the strategy manager proposes an update, and the distributor reviews it against on-chain data and jointly confirms it. This case assigns strategy admission, day-to-day operations and NAV confirmation to different responsibilities, preserving operational room while restricting any single party from changing the investment direction.

Approve investment scope → Submit day-to-day transactions → Execute signing rules

Confirm strategies and protocols → Allocate within the approved scope → Reject non-compliant requests

Nerona: Risk configuration, strategy operations and signing are handled by different parties

The risk management documentation for the sUSDnr vault separates Upshift's whitelisting and risk configuration, Nerona's strategy operations, and Fordefi MPC's signing role. The operations team allocates funds within the approved scope; changes to sensitive parameters such as fees and withdrawal cycles are subject to a 24-hour wait, and emergency functions have separate pause and withdrawal arrangements.

What the cases suggest

These designs separate the right to execute investments from the power to change the investment scope. They suit teams that need frequent allocation and do not want every action escalated. What matters in substance is that the execution system checks transactions against the approved scope, and expanding that scope requires a separate approval process.

Across all 100 objects and business categories, 6 explicitly use MPC, and 4 of these also describe transaction or investment restrictions: RockSolid, Fipto, Yuzu and Nerona. Fipto, in payments, restricts transactions through a payee whitelist and also sets up a multisig process and role permissions; asset management cases additionally involve strategy and protocol scope.

CertiK security commentary | Transaction restrictions and signing policy

MPC or multisig is not investment risk control; the coverage of transaction rules and whether bypass paths exist still need to be checked. Beyond whitelists, attention should also go to leverage, liabilities and concentration.

Peiyu Wang | Senior Audit Partner at CertiK

Figure: Google Cloud Multi-party Compute architecture

Industry technology case | v1beta preview | See "Scope and methodology" and "Investment restrictions"

The coordinator routes requests, and trusted execution environments (TEEs) holding key shares verify authorization and jointly sign. The diagram is an industry architecture reference.

Source: Google Cloud Multi-party Compute Architecture

The source document is marked as updated on October 27, 2026. The official SVG was converted to PNG and is presented as-is.

License CC BY 4.0

Of 50 projects, 16 disclosed or supported waits on rule changes

Finding two: Rule changes

Of the 50 projects that describe rule management or decision-making permissions, 16 also describe or support a change-waiting mechanism, or 32.0%; 7 of them list at least one explicit non-zero waiting period. These are disclosure or source-code support ratios, not actual enablement rates; configurable code alone cannot confirm that a non-zero wait is enabled in production.

Feather: Adding markets and raising limits wait, lowering limits executes immediately

When Feather vault curators add a market or raise a limit, a timelock applies; lowering a limit can be executed immediately. Allocators operate only within approved markets and limits, and the Guardian role can veto pending changes. A timelock is a mechanism in which a specific change is queued and can only be executed after the specified time has passed.

This arrangement distinguishes granting new investment authorization from tightening limits: adding markets and raising limits leave a review window first, while lowering limits can execute immediately. But lowering a limit mainly constrains subsequent fund allocation; it does not mean existing positions have been exited or current risk exposure reduced.

Neverland: Governance, risk parameters and pausing use different conditions for taking effect

24 hours / Main market governance and related upgrades, the minimum wait listed in the documentation

1 hour / Changes to related risk parameters, the minimum wait listed in the documentation

Immediate execution / Sentinel Safe triggers an emergency pause through a separate emergency permission

These conditions correspond to the operations listed in the documentation. Loopscale also classifies by parameter: adding collateral or raising the loan-to-value ratio (LTV) triggers a 24-hour timelock; changes to fee settings such as origination fees are also subject to a timelock. Removing collateral, lowering LTV and updating APY can execute instantly. LTV is the ratio of loan amount to collateral value and affects borrowing capacity.

What the cases suggest

Waiting mechanisms reserve time for review and intervention on changes that may expand risk, while actions such as pausing and lowering limits can take a faster path. Evaluating such designs requires looking at the content of the change, the waiting period, monitoring and cancellation permissions, and whether upgrades and other key administrative entry points are subject to corresponding constraints.

CertiK security commentary | Rule modification, upgrades and admin permissions

Timelocks need to be paired with effective monitoring and cancellation permissions, and must cover upgrades and key permission changes. Lowering a limit does not equal reducing existing risk; its actual effect should be made clear.

Peiyu Wang | Senior Audit Partner at CertiK

20 projects describe pausing, 7 disclose exit-related arrangements

Finding three: Emergency arrangements

Of the 100 projects, 20 describe pause arrangements, 7 disclose exit, withdrawal or migration-related arrangements, and 3 describe key recovery or replacement of signing participants. These include exiting investment positions, migrating funds and orderly winding down a vault after participants are replaced; they cannot be merged into an interpretation that funds have returned to an institution's usable wallet.

Gearbox: Separate pause, reopening requires multiple approvals

Gearbox V3.0 documentation allows 2 designated analyst addresses to each trigger a pause, but these addresses have pause permission only. Reopening is handled by a 4/12 multisig, meaning at least 4 of 12 signers agree; technical changes are controlled by a 6/12 multisig and subject to a 2-day timelock. First responders therefore do not need to hold general admin rights at the same time.

Yuzu: Risk monitoring connected to pre-authorized withdrawals

Yuzu documentation connects Hypernative monitoring, the Sentinel incident response system and Fordefi MPC wallets to execute pre-authorized withdrawals after a threat is confirmed. Compared with merely sending alerts, this design adds a fund-handling action; how much can actually be withdrawn and when it arrives still depend on the authorization scope and exit conditions.

Surge: Lost shares and suspected threshold compromise use different recovery methods

Surge handles lost or corrupted shares through encrypted backups and threshold recovery involving multiple recovery agents. If shares reaching the signing threshold are confirmed or suspected to be leaked, new keys are generated and funds are migrated. The former restores signing availability; the latter also ends reliance on the original keys.

Of the 7 exit-related records, Charm's emergencyBurn withdraws liquidity from a designated range; RockSolid supports an orderly transition or wind-down of a vault by replacing an unavailable participant. Neither directly proves that funds have returned to an institution's usable wallet. Of the 3 recovery records, besides Surge, the other 2 come from RockSolid's participant replacement and Due's recovery configuration; none means a recovery drill has been completed. The same object can be counted separately in the exit and recovery categories under different mechanisms.

What the cases suggest

Emergency arrangements already show designs with clearly divided responsibilities: low-threshold, restricted pause permissions to contain risk, pre-authorized withdrawals to handle funds, and recovery processes to rebuild signing capability. When keys may be compromised, key rotation and migration are also needed; merely restoring the old signing capability does not resolve the original control risk.

CertiK security commentary | Fund withdrawal and recovery drills

Pausing and restoring signing does not mean funds are usable; drills should verify actual arrival times. When keys are suspected of being leaked, it must also be ensured that the old keys can no longer control assets.

Peiyu Wang | Senior Audit Partner at CertiK

Figure: Disclosure of fund governance mechanisms

See "Investment restrictions", "Rule changes" and "Emergency arrangements".

Investment restrictions and rule-change waiting use 30 and 50 objects as denominators respectively. Emergency arrangements use all 100 objects as the denominator, and items may overlap.

Investment restrictions and emergency arrangements ultimately affect whether funds can be used as planned

Business analysis and research conclusions

When institutions manage digital assets, they need to let the team complete day-to-day operations, prevent risk from accumulating within the authorized scope, and preserve the ability to handle funds after an incident. The following two independently constructed scenarios show how the differences in the mechanisms described in the report affect business outcomes.

Scenario one: The protocol is still whitelisted, but portfolio leverage keeps rising

The strategy team continuously posts collateral, borrows, and reinvests the borrowed funds, always using the same approved protocol. The interaction target has not changed, but portfolio liabilities, leverage and collateral concentration may rise. At that point, a target-contract whitelist alone cannot limit risk.

The corresponding controls need to cover three layers: the protocols allowed to be called, the functions and amounts allowed to be executed, and the portfolio's liabilities and concentration after the trade. The first two layers can be enforced by contracts or wallet policies; portfolio metrics also require price and position data and a corresponding risk system.

Scenario two: 10 million on the books, still 1.2 million short of a payment due within two days

Usable immediately: 800,000 / Lending positions: 4.2 million / Term strategies: 5 million

An institution holds 10 million in USDT-equivalent assets, of which 800,000 is usable immediately, 4.2 million sits in lending positions and 5 million is in term strategies. It must pay 2 million within two days, so at least 1.2 million still needs to arrive on time. Pausing investments does not directly free up liquidity, and submitting a withdrawal request does not mean the funds have arrived.

Whether the institution has reliable payment capacity requires checking exitable amounts, withdrawal queues, maturities and external liquidity. Recovery drills should also record when assets actually return to a usable wallet, not just when the system restarts.

Research conclusions

First, 11 asset management cases disclosed specific investment restrictions, demonstrating the practice of giving day-to-day execution to the team and managing changes to the investment scope separately. What is worth comparing across institutions is the coverage of the restrictions and where they are enforced.

Second, 16 projects disclosed or supported a rule-change waiting mechanism in source code, and some cases further distinguish risk expansion from emergency contraction. Constraints on administrative power need to run through modification, waiting, cancellation and final taking of effect, not only constrain day-to-day transactions.

Third, the emergency cases handle pausing, withdrawal and signing recovery separately. Whether these arrangements can safeguard fund availability depends on actual configuration, asset exit conditions and the results of recovery drills.

Sources and research notes

The main sources for the text are as follows. Complete evidence and statistical records are in the research workbook.

RockSolid | Architecture & Roles (rETH vault)

Nerona | Risk Management (sUSDnr)

Fipto | Client Asset Security

Charm | AlphaProVault (emergencyBurn and withdraw)

Feather | Vault Mechanics

Neverland | Security

Loopscale | Loopscale Vaults

Gearbox | V3.0 Operational Multisigs

Yuzu | Product Documentation

Surge Credit | Disaster Recovery

Due | Developers Overview

Research notes

The text analyzes specific products and versions based on official documentation and public source code. The complete project list, sources and counting rules are in the research workbook and source index.

Research partners: CertiK, Lunaray.

Thanks to media supporters: We, Techub News, Odaily, Jinse Finance, ChainCatcher, PureNews, Chain Times.

About the joint research organizations

DeepSafe centers on institutional-grade MPC self-custody wallets, providing wallet management, a policy engine and team approval capabilities, and supports connecting to business systems through Wallet-as-a-Service (WaaS), serving institutional digital asset management and collaboration scenarios.

DeepSafe website

Contact email Ray@deepsafe.net

CertiK is a Web3 security firm providing smart contract audits, formal verification and continuous risk monitoring, helping projects and institutions identify and manage security risks related to digital assets.

CertiK website

Research report publication poster

Research partners and media supporters

Join the official Coincamps community:

X: https://x.com/coincamps

Telegram: https://t.me/coin_camps