The Governance Dependency Problem in Digital Asset Custody

On November 6, 2017, a vulnerability in a shared library smart contract, deployed as a common component of all Parity multi-sig wallets created after July 20 of that year, was exploited by an anonymous user. This user claimed ownership of the library and then destroyed it. According to the postmortem published by Parity Technologies, the action froze funds in 587 wallets holding a combined 513,774 Ether, along with additional tokens.

Crucially, no individual wallet had been compromised on its own terms. Each had delegated core governance functions to a shared contract, and when that contract ceased to exist, those functions ceased with it.

The proximate cause was a missing initialization check in the library, a code-level error that allowed any caller to claim ownership of the shared component. The structural condition that turned a single error into a systemic failure, however, was architectural. Governance logic had been refactored into a shared contract to reduce per-wallet deployment costs, a common and otherwise defensible software engineering practice.

That decision made the security of every wallet in the system contingent on the continued integrity of a component that none of them individually controlled.

That pattern, encoding governance rules as composed smart contract logic distributed across a dependency graph, is now standard in institutional multi-signature wallet design. As digital asset volumes scale, with stablecoins alone handling 18.4 trillion dollars in transfers in 2024 according to research cited in CryptoBit Magazine, the structural question of how authorization rules are stored and enforced on-chain carries proportionally larger consequences for the institutions that rely on them.

The Geometry of Contract Dependencies

In a composed governance system, authorization logic is spread across multiple smart contracts that call one another. An approval transaction might check a threshold in one contract, validate a signer's identity against a list held in another, and execute a transfer through a third. Each of these contracts is a distinct component that can be upgraded, misconfigured, compromised, or made dependent on additional contracts.

This process extends the total governance surface with every integration. The contracts involved in enforcing a governance rule may be audited separately, developed by different teams, and updated on different schedules, none of which is visible at the point of transaction execution.

An empirical analysis of the Ethereum ecosystem, published as a preprint at arXiv in 2025, found that 59 percent of contract transactions involve more than one contract, with a median of four contracts per transaction. The same analysis found that just eleven deployers control approximately 50 percent of active contracts on the network.

Furthermore, the three most frequently depended-upon contracts are mutable, meaning their logic can be altered by administrators without redeploying the contracts that depend on them. The authors concluded that actual protocol dependencies are significantly more complex than officially documented, creating what they described as unnecessary attack surface and undermining the transparency that public ledgers are designed to provide.

The relationship between code complexity and vulnerability in smart contracts has been measured. Research conducted at the Università della Svizzera italiana, analyzing Solidity contracts against established software complexity metrics, found that structural complexity correlates with greater exposure to security defects.

In a governance system, that complexity does not remain local to any one contract. It accumulates across the full dependency chain, so a vulnerability in a frequently-invoked policy module can affect every contract that calls it, regardless of whether those contracts are individually well-written.

The financial record of those accumulated vulnerabilities is substantial. The same Università della Svizzera italiana research noted that the top ten smart contract hacks of 2024 alone produced losses of 1.03 billion dollars. Earlier, the Decentralized Autonomous Organization, or DAO, hack of 2016 resulted in the withdrawal of approximately 3.6 million Ether through a reentrancy vulnerability.

In both cases, the exploits targeted the logic layer of contract code rather than the cryptographic keys of any individual user.

The 2017 Parity incident demonstrated the same dynamic through a different mechanism. In July 2017, a first Parity breach exploited the wallet's initialization logic to drain approximately 153,000 ETH from three wallets; to address that vulnerability, Parity refactored its architecture and extracted shared logic into a library contract. The November freeze was the result of that refactored version.

As the OpenZeppelin security team noted in its technical analysis, the attack would have been preventable had the wallet explicitly defined which library functions could be invoked externally, rather than forwarding all unmatched calls to the library by default. A fix to one surface area introduced the conditions for a compromise of another.

Upgradeability and the Moving Governance Surface

Because smart contract code is immutable once deployed, governance systems that must evolve require a mechanism for updating deployed logic. Proxy patterns, in which a persistent contract address forwards calls to a separately deployed logic contract that can be swapped, have become the standard solution. This allows governance rules to change without changing the address that counterparties interact with.

This is operationally convenient but also means that the effective governance at any given address can be altered by whoever holds the upgrade key, at any time, without necessarily triggering a new audit cycle.

Research on smart contract upgradeability, published at arXiv in 2025, found that proxy-based upgrade patterns introduce centralization risks by relying on a single entity for logic changes. This creates a single point of failure vulnerable to misuse or error.

The paper's proposed alternative, a protocol-level upgradeability capability that does not require a privileged external admin key, speaks directly to the same problem. Placing upgrade authority in a dedicated contract or address replicates, within the governance layer, the same concentrated control point that multi-sig is meant to eliminate in the asset custody layer.

The governance layer as an attack target is not theoretical. In December 2025, Unleash Protocol suffered a loss in which attackers manipulated the governance mechanisms for its multi-sig wallet to perform a malicious contract upgrade and redirect assets, according to a monthly security review by Halborn.

The attack did not require breaking a private key; it required navigating the governance logic that controlled who could authorize an upgrade. The loss illustrated that when governance rules are executable contract code, the governance system itself is a target with its own exploitable surface.

The audit implications are structural rather than incidental. A traditional smart contract audit assesses code at a specific version and time. In a composed governance system with proxy upgradeability, each logic swap is a partial change to the governance surface that does not necessarily trigger a new audit.

Analysts at PwC Switzerland have identified misconfigured policy engines and key compromise as the leading custody risks in digital asset management. They note that no native mechanism currently enforces re-verification of governance logic when dependencies change between review periods. The most recently audited version of a governance contract may not describe its current behavior.

The regulatory environment formalizes these concerns in ways that place direct pressure on composed contract governance systems. The SEC's 2023 safeguarding proposal, detailed in the agency's press release, emphasized qualified custodian requirements, on-chain asset segregation, and surprise examination standards.

A multi-sig wallet system that satisfies signature count requirements may still fall short of those standards if the authorization logic behind those signatures can be altered between examination periods. It also fails if a shared dependency introduces a channel for unauthorized access that the wallet's own code does not directly expose.

Governance as Protocol-Level Configuration

One structural response to composed-contract governance risk is to move authorization rules out of executable contract logic and into the identity layer of the protocol itself. In this model, permissions function as ledger-enforced data rather than as code that other contracts must call. The permissions that determine who can sign a transaction, what thresholds must be met, and which roles have access are consensus facts.

Authorization is validated by the network at the point of transaction processing rather than by runtime execution of potentially mutable contract logic. It does not depend on the integrity of any contract in a dependency chain; it is a property of the ledger's own record.

Jay Smith, whose analysis of institutional custody architecture was published in CryptoBit Magazine in December 2025, describes this approach as treating governance controls as native protocol data rather than compiled code. His analysis uses the Accumulate network's Key Book architecture as a working example.

In this system, each addressable identity on the network must reference at least one Key Book, a protocol-level construct that defines signing thresholds and role hierarchies. As the Accumulate whitepaper notes, this design means governance rules do not require a separate contract call to enforce; they are part of how the protocol itself evaluates whether a transaction is valid.

The audit consequences of that design differ substantially from those of composed contract governance. When authorization rules are embedded in a protocol's identity layer, every permission change, every threshold adjustment, and every role rotation is itself a ledger event with an immutable timestamp.

Compliance teams can verify the current state of governance rules directly from on-chain data, rather than from a snapshot of contract code that may no longer reflect live behavior. Smith's analysis describes this as continuous assurance: the ability to test controls on any day of the year, not only at the time of a scheduled review.

Institutional governance requirements, including segregation of duties between operations staff and compliance approvers, or dual-control rules for high-value transactions, can be expressed within a native identity model as configuration rather than as contract code. In a composed contract system, those same requirements are implemented as executable logic that must be deployed, audited, and maintained separately from the assets it governs.

A review of smart contract security published in ACM Computing Surveys identifies permission control errors as one of the most common vulnerability classes in deployed contracts. This finding is consistent with the difficulty of encoding complex organizational access control hierarchies reliably in general-purpose programming languages that were designed for financial computation rather than institutional governance.

This framing does not position protocol-native governance as a substitute for smart contract functionality broadly. Contracts remain necessary for the business logic of financial instruments, settlement flows, and asset-specific compliance rules. The claim is narrower: that the authorization layer, the part of the system that determines who can instruct the protocol to act, benefits from residing as close to consensus as possible.

Any distance between the authorization rules and the consensus layer is a gap in which composed contract vulnerabilities can operate, and that gap widens with every dependency added to the governance stack.

The broader landscape of distributed systems offers a parallel. In traditional enterprise computing, identity and access management standards have for decades distinguished between authentication, confirming who a party is, and authorization, confirming what that party is permitted to do. These standards have generally argued that both functions belong in infrastructure rather than in application logic.

The argument for protocol-native governance in blockchain systems is structurally similar: governance rules are infrastructure, and placing infrastructure-level controls in application-layer contract code exposes them to application-layer vulnerabilities.

Adding signature requirements multiplies the credentials that must be protected. However, if the logic governing those signatures is itself distributed across mutable, intermittently-audited contract dependencies, the number of required signers is not the binding security constraint.

Whether native protocol governance can be delivered at the interoperability, regulatory, and operational scale that institutional deployments require remains an open engineering and policy question. What the current pattern establishes is that expanding multi-sig governance through composed smart contracts scales the authorization attack surface alongside the authorization requirements.

Those two quantities do not scale at the same rate, and the gap between them is where the governance risk lives. How institutions manage that gap, and what infrastructure they build or adopt to close it, will shape the security baseline of digital asset markets as they absorb the next wave of institutional capital.

Sources

• Parity Technologies. "A Postmortem on the Parity Multi-Sig Library Self-Destruct." Parity Technologies, 2017.
• Palladino, Santiago. "The Parity Wallet Hack Explained." OpenZeppelin, 2017.
• Tehrani, Masoud Jamshidiyan. "Assessing Vulnerability in Smart Contracts: The Role of Code Complexity Metrics in Security Analysis." Università della Svizzera italiana / arXiv, 2024.
• Multiple authors. "On-Chain Analysis of Smart Contract Dependency Risks on Ethereum." arXiv, 2025.
• Multiple authors. "Bridging Immutability with Flexibility: A Scheme for Secure and Efficient Smart Contract Upgrades." arXiv, 2025.
• Multiple authors. "Blockchain Smart Contract Security: Threats and Mitigation Strategies in a Lifecycle Perspective." ACM Computing Surveys, 2024.
• Multiple authors. "A Survey of Ethereum Smart Contract Security: Attacks and Detection." ACM Digital Library / Distributed Ledger Technologies: Research and Practice, 2024.
• Halborn. "Month in Review: Top DeFi Hacks of December 2025." Halborn, 2026.
• PwC Switzerland. "Crypto Custody Risks and Controls from an Auditor's Perspective." PwC Switzerland, 2023.
• U.S. Securities and Exchange Commission. "SEC Proposes Safeguarding Rule for Registered Investment Advisers — Press Release 2023-30." U.S. Securities and Exchange Commission, 2023.
• Smith, Jay. "Beyond the Private Key: How Key Books Fix Institutional Crypto Custody." CryptoBit Magazine, 2025.
• Accumulate Network. "Accumulate Whitepaper v1.0." Accumulate Network, 2022.