2026 Institutional Digital Asset Governance Study
DeepSafe × CertiK Joint Research｜100 Projects and Service Providers
Institutions can delegate daily fund operations to the execution team, but changes to broaden investment scope, increase limits, etc., should be separately approved, and independent, limited permissions should be set for emergency pausing, withdrawal, and recovery.
Sample cases show that such division of labor allows the team to continue operations within a defined scope while retaining the opportunity to review new risks and address anomalies. Emergency capabilities ultimately hinge on a business outcome: whether funds can be returned to available accounts when needed.
DeepSafe and CertiK jointly researched institutional stablecoin payments, project treasuries, and on-chain investments, studying how institutions allocate trading permissions, constrain investment scopes, and manage funds in abnormal situations.
The research reviewed the official documentation, product descriptions, and relevant codes of 100 projects and service providers, recording evidence by business type and control mechanism. The report unfolds in accordance with the actual operational sequence of institutional funds: what operation permissions the team has, how investment rules are modified, and how to exit or recover after an anomaly occurs.
Main Conclusions
01. Among 30 asset management projects, 11 disclosed specific investment restrictions
These 11 projects explicitly restrict accessible markets, available assets, callable functionalities, or capital limits. Cases such as RockSolid and Nerona separate strategy access from daily allocations, allowing operators to work within a defined scope, while new investment directions require separate approval.
02. Among 50 projects, 16 disclosed or supported waiting for rule changes
Of the 50 projects detailing rule modification permissions, 16 simultaneously indicated or supported waiting mechanisms for changes, accounting for 32.0%. Feather, Neverland, and others further divide by action: new risks retain review time, while reducing limits or emergency pausing can be executed quickly.
03. 20 projects indicated pauses, and 7 disclosed exit arrangements
These 7 include orderly exits after withdrawal of funds, liquidity outflows, and participant replacements, and cannot be seen as 7 projects from which funds can be immediately reclaimed. An additional 3 note key recovery or changes in signing participants.
The common idea provided by these cases is: delegate daily operations to the execution team, separately manage decisions to expand investment scope and relax rules, and establish clear, limited permissions for emergency handling.
Contents
Scope and Methods of Research / Investment Restrictions / Rule Changes / Emergency Arrangements
Business Analysis and Research Conclusions / Sources and Research Explanation
Data cut-off: October 28, 2026; statistical evidence verification: November 3; case details verification: November 5. Ratios reflect document disclosures or source code support and do not represent production activation rates.
100 Projects Cover Five Categories of Fund Operations
Scope and Methods of Research
The subjects of the research include digital asset payments, investments, loans, and issuance services. Categorized by primary business type, each subject counts as one group, totaling 100.
Loans and credit operations focus on lending, collateral, and protocol funds; asset management and strategy operations focus on treasury investments and fund allocation; payment and compensation focus on corporate 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.
Research Methods
Based on official documents, help centers, product descriptions, and accessible code, four categories of facts were systematically recorded: personnel and signature permissions, trading or investment restrictions, rule modification permissions, and conditions for effect, as well as pause and recovery arrangements after anomalies. Each record corresponds to a source URL, product, or version, along with specific content supporting that judgment.
A ledger indexed 140 different source URLs. Among the 100 subjects, 64 found at least one mechanism that met the primary statistical criteria, while 32 had limited information or principal mechanisms unconfirmed; 4 involved historical migrations or pre-release designs, not counted towards mechanism statistics. The 64 subjects covered signature and personnel permissions, trading or investment restrictions, rule modifications, and emergency arrangements, not limited to the three major findings discussed below.
Statistical Criteria
Metrics divide their applicable businesses to take denominators: Investment restrictions use the 30 asset management projects as the denominator; waiting for changes uses the 50 projects detailing rule modification permissions; emergency arrangements use the total of 100 subjects. Mechanisms may overlap. Document disclosure, source code support, and production activation are viewed separately; the ratios in this report reflect the first two categories and do not classify undisclosed items as lacking.
Signature technology and business approvals are recorded separately. MPC allows multiple parties to collaborate using key sharding to generate signatures; multi-signatures are usually separately signed by different keys, with on-chain programs checking the number of signatures. Business approvers need not equal signature participants. Delays in administrator changes and client redemption wait times are counted separately as well.
The report analyzes public designs and their business implications. Named cases are introduced according to their respective products and versions; public materials are insufficient to confirm actual configurations, execution effects, and recovery times.
Among 30 Asset Management Projects, 11 Disclosed Specific Investment Restrictions
Finding One: Investment Restrictions
Among 30 asset management and strategy projects, 11 explicitly stated the markets, assets, contract functionalities, or limits on funds available for investment, accounting for 36.7%. These projects detail authorizations to specific operational scopes rather than just listing who can sign.
RockSolid: Strategy Managers Can Allocate Funds, New Strategies Require Joint Approval
In the example of the rETH treasury, RockSolid serves as the distributor. Strategy managers propose new strategies, which RockSolid participates in approving via the MPC process for whitelisting. Strategy managers can then allocate and rebalance assets between approved strategies; all transactions must adhere to signature rules, and requests that do not comply will be rejected.
Net asset value (NAV) also employs division of labor: Strategy managers propose updates, while distributors verify and jointly confirm based on on-chain data. This case delegates strategy access, daily operations, and NAV confirmation to different responsibilities, maintaining operational space while limiting unilateral changes in investment direction.
Approve Investment Scope → Submit Daily Transactions → Execute Signature Rules
Confirm Strategy and Protocol → Allocate Within Approved Scope → Reject Non-Compliant Requests
Nerona: Risk Allocation, Strategy Operations, and Signatures Are Managed by Different Parties
The risk management document of the sUSDnr treasury separates the whitelisting and risk allocation of Upshift from the strategy operations of Nerona and the signing responsibilities of Fordefi MPC. The operational team allocates funds within the approved scope; modifications to sensitive parameters like fees and withdrawal cycles are subject to a 24-hour waiting period, while emergency functionalities have separate pausing and withdrawal arrangements.
Judgment Derived from Cases
This type of design separates the execution rights of investments from the powers to change investment scope. It suits teams that need frequent allocations but do not wish to escalate decisions for each operation. The essence of control is that the execution system checks transactions against approved scopes, and broadening the scope requires a separate approval process.
A total of 6 of the 100 subjects and business categories explicitly adopted MPC, of which 4 also disclosed trading or investment restrictions: RockSolid, Fipto, Yuzu, and Nerona. The payment-focused Fipto limits transactions via a recipient whitelist while configuring multi-sign processes and role permissions; the asset management cases further involve strategy and protocol scopes.
CertiK Security Interpretation｜Trading Restrictions and Signature Strategies
MPC or multi-sign does not equate to investment risk control, and it is still necessary to examine the coverage of trading rules and potential circumvention paths. Beyond whitelists, attention should also be given to leverage, liabilities, and concentration.
Peiyu Wang | Senior Audit Partner at CertiK
Supplementary Diagram Google Cloud Multi-party Compute Architecture
Industry Technical Cases | v1beta Preview | See "Scope and Methods of Research" and "Investment Restrictions"
The coordinator is responsible for routing requests, and the trusted execution environment (TEE) holding key shards verifies authorization and collaborates on signatures. The diagram is a reference for industry architecture.
Source Google Cloud Multi-party Compute Architecture
The source document was updated on October 27, 2026. Official SVG converted to PNG, images and texts presented as is.
Among 50 Projects, 16 Disclosed or Supported Waiting for Rule Changes
Finding Two: Rule Changes
Of the 50 projects detailing rule management or decision-making permissions, 16 simultaneously indicated or supported waiting mechanisms for changes, accounting for 32.0%; among these, 7 listed at least one explicit non-zero waiting duration. This reflects the ratio of public disclosures or source code support, not the actual activation rate; there is only configurable code, which cannot confirm non-zero wait states in production environments.
Feather: New Markets and Increased Limits Await, While Decreasing Limits Can Be Executed Immediately
When curators of the Feather treasury add markets or raise limits, they need to undergo a time lock; decreasing limits can be executed immediately. Allocators operate solely within the already approved markets and limits, and the Guardian role can veto pending changes. The time lock is a mechanism that mandates waiting a stipulated time before executing specific queued modifications.
This arrangement distinguishes between new investment authorization and tightening of limits: new markets and increased limits first allow a review window, while decreasing limits can be executed immediately. However, decreasing limits mainly constrains subsequent fund allocations and does not indicate that existing positions have exited or current risk exposures have decreased.
Neverland: Governance, Risk Parameters, and Pauses Adopt Different Conditions for Effect
24 hours / Main market governance and related upgrades have documented lower waiting limits
1 hour / Changes to related risk parameters also have documented lower waiting limits
Direct Execution / Sentinel Safe triggers an emergency pause through separate emergency permissions
These conditions correspond to operations stated in the documentation. Loopscale further categorizes by parameters: adding collateral or raising loan-to-value (LTV) triggers a 24-hour time lock; changes to launch fees and other expense settings are also subject to the time lock. Removing collateral, decreasing LTV, and updating APY can be executed immediately. LTV is the ratio of the loan amount to the value of collateral, affecting the borrowing capacity.
Judgment Derived from Cases
The waiting mechanisms preserve time for inspection and intervention for changes that could potentially amplify risks, while actions such as pauses and limit reductions can adopt faster paths. Evaluating such designs requires examining the contents of the modifications, waiting times, monitoring and cancellation permissions, and whether upgrades and other key management gateways are subject to corresponding controls.
CertiK Security Interpretation｜Rule Modifications, Upgrades, and Management Permissions
Time locks need to be paired with effective monitoring and cancellation permissions and cover upgrades and key permissions changes. Reducing limits does not equate to lessening existing risks, and its actual function should be clarified.
Peiyu Wang | Senior Audit Partner at CertiK
20 Projects Indicated Pauses, 7 Disclosed Exit-Related Arrangements
Finding Three: Emergency Arrangements
A total of 100 projects, 20 indicated pausing arrangements, 7 disclosed exit, withdrawal, or migration arrangements, and 3 indicated key recovery or changes in signing parties. This includes orderly exits after withdrawing investment positions, migrating funds, and switching participants; these cannot be cumulatively interpreted as funds having returned to the institution's available wallet.
Gearbox: Separate Pausing Requires Multiple Approvals for Reopening
The Gearbox V3.0 documentation allows 2 designated analysis addresses to each trigger a pause, but these addresses only hold pausing permissions. The reopening operation is managed by a 4/12 multi-signature, meaning at least 4 out of 12 signers must agree; technical changes are controlled by a 6/12 multi-signature and are subject to a 2-day time lock. Rapid responders thus do not need to simultaneously obtain general management authority.
Yuzu: Risk Monitoring Connected to Pre-authorized Withdrawals
The Yuzu documentation links Hypernative monitoring, the Sentinel event response system, and the Fordefi MPC wallet, executing pre-authorized withdrawals upon confirming threats. This design increases fund handling actions compared to just sending alerts; however, the actual withdrawal amount and timing still depend on authorization scope and exit conditions.
Surge: Lost Shards and Suspected Threshold Leaks Use Different Recovery Methods
Surge processes lost or damaged shards through threshold recovery involving encrypted backups and multiple recovery agents. If confirmed or suspected leaks reach the signing threshold, a new key is generated, and funds are migrated. The former restores signature availability, while the latter also ends dependence on the original key.
Among the 7 exit-related records, Charm's emergencyBurn withdraws designated interval liquidity; RockSolid supports orderly transitions or treasury closures through replacement of unavailable participants. Neither directly proves that funds have returned to the institution's available wallet. In 3 cases of recovery records, apart from Surge, the other 2 come from changes in RockSolid participants and configuration restoration from Due; they do not represent completion of recovery drills. The same subject may be counted under different mechanisms for exit and recovery categories.
Judgment Derived from Cases
Emergency arrangements have emerged as designs with clearly defined roles: low-threshold, limited pausing permissions to curb risks, pre-authorized withdrawals to handle funds, and recovery processes to rebuild signature capabilities. When keys may leak, key rotation and migration are also needed, as simply restoring old signature capabilities does not resolve existing control risks.
CertiK Security Interpretation｜Fund Withdrawal and Recovery Drills
Pausing and restoring signatures do not equate to fund availability, and actual arrival times must be verified through drills. When key leaks are suspected, it is also essential to ensure old keys cannot continue to control assets.
Peiyu Wang | Senior Audit Partner at CertiK
Supplementary Diagram on the Disclosure of Fund Governance Mechanisms
See "Investment Restrictions," "Rule Changes," and "Emergency Arrangements."
Investment restrictions and rule change waits use 30 and 50 subjects as denominators, respectively. Emergency arrangements use all 100 subjects as the denominator, with various aspects overlapping.
Investment Restrictions and Emergency Arrangements Ultimately Affect Whether Funds Can Be Used as Planned
Business Analysis and Research Conclusions
Institutions managing digital assets must enable their teams to complete daily operations while preventing risks from accumulating within authorized scopes and retaining the ability to manage funds in abnormal situations. The following two independently constructed scenarios illustrate how the mechanisms discussed in the report affect business outcomes.
Scenario One: The Protocol Remains in the Whitelist, but the Portfolio Leverage Continues to Rise
The strategy team continuously mortgages assets, borrows, and reinvests borrowed funds, always using the same approved protocol. The interaction target has not changed, but the portfolio's liabilities, leverage, and collateral concentration may increase. At this point, merely having the target contract in the whitelist does not independently limit risks.
Corresponding controls need to cover three levels: the protocols allowed to be invoked, the functions and amounts permitted for execution, and the liabilities and concentration of the portfolio after trades. The first two levels can be executed by contracts or wallet strategies; the portfolio metrics also require price, position data, and corresponding risk control systems.
Scenario Two: 10 Million on the Books, but 1.2 Million is Needed to Pay Within Two Days
800,000 Available Immediately / 4.2 Million Loan Position / 5 Million in Fixed Strategy
An institution holds the equivalent of 10 million USDT in assets, with 800,000 immediately available, 4.2 million in a loan position, and 5 million in a fixed strategy. It needs to pay 2 million within two days, requiring at least 1.2 million to be received on time. Pausing investments does not directly release liquidity, and submitting a withdrawal does not mean that the funds have already arrived.
Whether the institution has reliable payment capabilities needs verification of available withdrawal amounts, withdrawal queues, deadlines, and external liquidity. Recovery drills should also record the time when assets actually return to the available wallet, rather than just noting when the system resumes.
Research Conclusions
First, 11 asset management cases disclosed specific investment restrictions, showcasing the practice of delegating daily execution to teams while separately managing changes to investment scope. The coverage and execution positioning of these restrictions among institutions are worth comparing.
Second, 16 projects disclosed or supported rule change waiting mechanisms in their source code; in some cases, a further distinction between risk expansion and emergency contraction is made. Constraints on management rights need to encompass modifications, waiting, cancellations, and final effects, rather than only restricting daily transactions.
Third, emergency cases handle pauses, withdrawals, and signature recoveries separately. Whether these arrangements can guarantee fund availability depends on actual configurations, asset exit conditions, and recovery drill results.
Sources and Research Explanation
The main data for the body text is as follows. Complete evidence and statistical records are in the research tables.
RockSolid｜Architecture & Roles (rETH Treasury)
Nerona｜Risk Management (sUSDnr)
Charm｜AlphaProVault (emergencyBurn and withdraw)
Gearbox｜V3.0 Operational Multisigs
Surge Credit｜Disaster Recovery
Research Explanation
The body text is based on official documents and public source code analysis of specific products and versions. A complete project list, sources, and counting rules can be found in the research tables and source indexing.
Research Partners: CertiK, Lunaray.
Thanks to media support: PANews, Techub News, Odaily, Jinse Finance, ChainCatcher, PureNews, Chain Times.
About Joint Research Institutions
DeepSafe focuses on institutional-level MPC self-custodial wallets, offering wallet management, strategy engines, and team approval capabilities, and supports integration via Wallet as a Service (WaaS) into business systems, serving institutional digital asset management and collaboration scenarios.
Contact Email [email protected]
CertiK is a Web3 security service agency, providing smart contract audits, formal verification, continuous risk monitoring, and other services to help projects and institutions identify and manage digital asset-related security risks.
Research Report Release Poster
Research Partners and Media Support
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到[email protected]，本平台相关工作人员将会进行核查。
