The next generation of digital asset security needs more than secure wallets and multiple signatures. It needs proper identity management, separation of duties and controls over who gets to exercise financial authority.
On 7 May 2026, a vulnerability in the TrustedVolumes trading infrastructure allowed an attacker to register themselves as an authorised order signer and use that authority to drain approximately $5.87 million in digital assets.
The mechanics are worth examining because they expose a problem that extends well beyond one smart contract.
TrustedVolumes operated a request-for-quote (RFQ) settlement proxy that allowed trades to be executed against its own inventory. The proxy had permission to transfer tokens from the company’s wallet as part of that process. The attacker exploited a publicly accessible signer-registration function, establishing their own signing authority for an attacker-controlled contract. The system subsequently accepted orders that caused funds to be pulled from TrustedVolumes’ inventory.
There were several vulnerabilities involved, including a failure to properly bind the signer authorisation to the account supplying the funds and broken replay protection. The result was a transaction that passed the contract’s checks while moving assets the attacker had no legitimate authority to spend.
The incident is an interesting illustration of a much older financial security problem: the relationship between identity, permission and control over money.
Banks have spent generations developing systems to manage that relationship. They separate the people who initiate payments from those who approve them. They restrict the authority of administrators, establish independent approval processes and place controls around changes to account permissions. They also recognise that the ability to change who can access money is itself a significant form of financial authority.
These practices sit within the broader disciplines of Identity and Access Management (IAM) and Identity Governance and Administration (IGA).
As crypto infrastructure moves further into institutional finance, these disciplines deserve considerably more attention.
- The dangerous combination of permissions
- Banks have been separating these responsibilities for years
- The ability to grant access is financial authority
- Zero Trust and the problem of inherited permissions
- Building the controls into the transaction itself
- What happens when one identity is compromised?
- The institutional opportunity
- An old financial problem in a new environment
The dangerous combination of permissions
One of the more useful concepts in traditional financial security is segregation of duties.
The principle is straightforward. Certain responsibilities should never be concentrated in the same hands because combining them creates an opportunity for fraud, error or abuse that would otherwise require the cooperation of multiple people.
Consider an ordinary business banking arrangement.
An employee can create a payment. A second employee approves it. A separate administrator manages the bank’s user permissions. Someone else reconciles the account and checks that the payments correspond with legitimate business activity.
Each person has access to the systems they need to perform their job. Their authority is deliberately limited.
The person who creates a payment cannot independently approve it. The person who manages user permissions cannot simply give themselves payment authority. The person approving a payment cannot quietly alter the records used to reconcile it.
The controls are designed around the possibility that an individual might make a mistake, abuse their position or have their credentials compromised.
This becomes particularly interesting when we consider how permissions are structured in crypto.
A protocol might have an administrator who can add authorised signers, a treasury operator who can initiate transfers, a developer who can update smart contracts and an execution service that can submit transactions.
Each permission might be entirely reasonable in isolation.
The danger emerges when they are combined.
An individual who can add a signer and approve transactions has more authority than someone who can perform either task independently. Add the ability to modify transaction limits or change the contract implementation, and the same individual may have enough control to circumvent almost every other safeguard in the system.
We can think of these as toxic permission combinations.
The individual permissions may be legitimate. Their combination creates an unacceptable concentration of financial authority.
This is precisely the kind of problem that established IAM and financial governance systems are designed to identify.
Traditional enterprise security frameworks use concepts such as Segregation of Duties (SoD) rules and toxic combination analysis to identify conflicting permissions. A person might be permitted to create supplier records or approve supplier payments, for example, but holding both permissions could create an unacceptable fraud risk.
The same logic can be applied to crypto.
An identity that can register a new authorised signer should not automatically be able to approve transactions using that signer. A developer who can deploy a contract upgrade should not necessarily have access to the treasury keys. An administrator who can modify access policies should not be able to approve their own elevation of privileges.
These relationships can be modelled, tested and enforced.
The interesting opportunity is that much of this can happen automatically.
A permission-management system could evaluate a proposed change against a set of predefined conflict rules. If granting a particular permission would create a toxic combination, the system could reject the request or require additional independent authorisation.
The objective is to prevent financial authority from accumulating in ways that nobody has properly considered.
Banks have been separating these responsibilities for years
There are several established banking practices that translate particularly well into digital asset infrastructure.
The first is dual control.
Under dual control, sensitive activities require the participation of at least two independently authorised individuals. Neither person can complete the operation alone.
This is commonly applied to payment processing, treasury operations, changes to banking arrangements and other activities involving significant financial authority.
A payment might be prepared by one employee and approved by another. Changes to beneficiary details might require independent verification. Administrative changes to a banking account might require approval from someone outside the team responsible for maintaining user access.
The maker-checker model is a familiar implementation of the same principle.
The maker prepares an instruction. The checker independently reviews it before it can proceed.
Crypto has its own version of dual control through multisignature wallets, threshold signatures and distributed signing arrangements.
These are valuable technologies, but the signature threshold alone tells us relatively little about the independence of the underlying authority.
A three-of-five multisig might require three signatures to release funds. However, what happens if the same operational team controls all five keys? What if the people holding those keys can also modify the approved signer list? What if the administrator responsible for managing the signing infrastructure can change the transaction approval policy?
The system may have multiple signatures while retaining a single point of operational control.
Traditional banking governance goes further by considering the responsibilities of each participant.
A stronger arrangement would separate transaction initiation, approval, permission administration and execution. Each function would have its own authorised identities and independent controls.
The number of signatures matters. The independence of the authority behind those signatures matters considerably more.
The ability to grant access is financial authority
One area where crypto could benefit substantially from established banking practices is privileged access management.
In a conventional business, the person responsible for administering user permissions has considerable power. They can create accounts, assign roles, revoke access and sometimes grant elevated privileges.
Financial institutions understand that this administrative responsibility needs its own controls.
A system administrator should not automatically be able to approve payments. A payment approver should not be able to grant themselves additional permissions. A request to elevate someone’s access should be subject to an independent approval process.
The same principle should apply to smart contracts and digital asset infrastructure.
Consider what happens when a new authorised signer is introduced to a protocol.
That change affects the financial authority of the entire system. Depending on the implementation, it could allow an additional identity to initiate trades, authorise transfers or exercise control over assets.
It should therefore be treated as a significant financial event.
A sensible process might require a formal access request, verification of the identity being added, an independent approval, a time delay and an immutable record of the change.
The same approach could apply to modifications of contract ownership, treasury permissions, withdrawal limits and administrative roles.
High-risk changes could also trigger notifications to independent monitoring systems and designated stakeholders.
There is an important distinction here between administering a permission and exercising it.
The person responsible for maintaining the access list should not automatically acquire the authority represented by that list.
That sounds obvious in business banking. It deserves to become equally obvious in crypto.
Zero Trust and the problem of inherited permissions
Another established security discipline with significant implications for crypto is Zero Trust.
The concept has become increasingly important in enterprise security as organisations have moved away from traditional network boundaries and towards distributed systems, cloud infrastructure and remote access.
Its central premise is that access should be evaluated against the identity and specific resource involved in each operation.
An authenticated user, device or service does not receive unrestricted trust simply because it has successfully entered an approved environment.
This is particularly relevant to crypto protocols, where multiple components routinely interact with one another.
A typical environment might include treasury wallets, execution engines, trading bots, oracle services, administrative contracts, deployment pipelines and external integrations.
Each component needs access to certain resources to perform its function.
The challenge is limiting that access.
A monitoring service might need permission to inspect transaction activity. It has no reason to initiate transfers.
An execution engine might need permission to submit approved transactions. It should have no authority to modify the approval policy.
A deployment pipeline might need permission to update a particular application contract. It should not automatically have access to the treasury or the ability to change the identities authorised to control it.
These restrictions are examples of least privilege.
Every identity receives only the permissions required for its specific responsibilities.
The principle also applies to temporary access. An administrator might need elevated privileges to perform a particular maintenance operation. Those privileges could be granted for a limited period, with automatic revocation when the task is complete.
This is known as just-in-time privileged access.
It reduces the amount of time that powerful credentials remain available and limits the opportunities for an attacker to exploit them.
NIST’s Zero Trust Architecture framework, SP 800-207, provides an established foundation for these approaches. Its emphasis on protecting individual resources rather than relying on network location is particularly relevant to decentralised financial infrastructure.
Crypto systems operate across public networks, distributed organisations and multiple service providers. Resource-level identity and authorisation provide a more useful security model than assuming that an authenticated participant should be trusted throughout the environment.
Building the controls into the transaction itself
There is an opportunity to take these principles further through smart contract architecture.
Traditional banking systems often enforce internal controls through a combination of software, administrative procedures and institutional policies.
Crypto infrastructure has the potential to encode many of these requirements directly into the transaction process.
Imagine a protocol with a dedicated authorisation layer sitting between its users, administrative functions, wallets and execution contracts.
A transaction would pass through a series of checks before it could be executed.
The system would establish who initiated it, what authority they hold, whether the transaction falls within their permitted limits and whether additional approval is required.
It could also examine the destination, asset, transaction value and recent changes to the relevant permissions.
A payment to an established destination might require one approval. A transfer above a specified threshold might require two independent approvals. A payment to a newly added address could trigger a cooling-off period. A change to the authorised signer list might require approval from an entirely separate administrative authority.
These rules could be expressed as transaction policies and enforced through smart contracts or an external policy engine integrated with the signing infrastructure.
There are several established access-control models that could contribute to this architecture.
Role-Based Access Control (RBAC) assigns permissions according to defined responsibilities. A treasury operator, developer, compliance officer and transaction approver receive different capabilities.
Attribute-Based Access Control (ABAC) takes the model further by considering additional conditions. Permissions can depend on transaction value, asset type, destination, time, risk classification or organisational authority.
Privileged Access Management (PAM) governs elevated permissions, including how they are requested, approved, monitored and revoked.
Together, these disciplines provide a much more complete approach to financial authorisation.
There is also an important distinction between controlling who can invoke a function and validating what that function is permitted to do.
TrustedVolumes illustrates why both are necessary. Restricting access to signer registration would have addressed one weakness. The contract also needed to establish that the authorised signer actually had authority over the inventory from which the funds were being transferred.
An IAM layer cannot compensate for incorrectly written smart contract logic. The contract must still validate the relationship between the identity, the authority and the assets involved.
The two disciplines need to work together.
What happens when one identity is compromised?
A useful way to evaluate any financial security architecture is to assume that one of its identities has already been compromised.
What can the attacker do?
Can they initiate a payment? Can they approve it? Can they add another signer? Can they modify the transaction limits? Can they change the destination address? Can they disable monitoring or alter the records used to review their activity?
The answers reveal how much authority is concentrated in that identity.
This is an established principle in operational risk management. Security controls should limit the consequences of a breach, even when prevention has failed.
Crypto infrastructure has an advantage here because permissions and transactions can often be made independently observable.
A permission change can be recorded on-chain. A proposed administrative modification can be subjected to a delay. Independent monitoring systems can watch for unexpected changes to signer lists or contract ownership. Treasury controls can impose transaction limits even where an execution service has been compromised.
There is also scope for automated emergency responses.
For example, an unexpected change to a privileged role could trigger a temporary restriction on withdrawals while the change is reviewed. A sudden increase in transaction authority could require additional approvals. A compromised execution service could be isolated without affecting the administrative systems responsible for recovering the protocol.
These mechanisms need careful design. An emergency control that can itself be disabled by the compromised identity provides little protection.
The point is to ensure that different parts of the system retain independent authority over one another.
The institutional opportunity
The growing involvement of banks, asset managers, payment providers and corporate treasuries in digital assets will place greater emphasis on these operational controls.
Institutional financial operations already have established expectations around account administration, payment approvals, transaction limits, reconciliation, audit trails and privileged access.
Those expectations do not disappear when the assets move onto a blockchain.
A business holding digital assets needs to know who can initiate a transfer, who can approve it, who can change the permissions governing it and how those activities are independently reviewed.
A custody provider that protects private keys while leaving these questions unanswered is providing only part of the required security architecture.
There is a considerable opportunity for infrastructure providers to address this gap.
Identity governance, privileged access management, transaction policy enforcement and independent signing controls could become important components of institutional crypto infrastructure.
They could also provide a common governance layer across multiple wallets, blockchains, custody providers and financial applications.
That would be particularly useful for organisations managing digital assets across different platforms. Rather than maintaining separate permission structures for every wallet and application, an institution could apply consistent policies governing identities, responsibilities and transaction authority across its entire environment.
The technology required to build these systems already exists in various forms. Enterprise IAM platforms, policy engines, hardware security modules, distributed signing technologies and smart contract frameworks provide much of the underlying functionality.
The opportunity lies in bringing them together around the specific requirements of digital asset operations.
An old financial problem in a new environment
There is a considerable amount of accumulated knowledge in traditional banking about how to control access to money.
The separation of payment initiation and approval, independent administration of permissions, dual control, least privilege and regular reconciliation are all established practices. They have developed through decades of operational experience and repeated exposure to fraud and financial abuse.
Crypto infrastructure is now dealing with many of the same problems, often with larger amounts of authority concentrated in fewer operational roles.
The technology has changed. The consequences of poorly managed access remain familiar.
The TrustedVolumes incident is a useful reminder that financial authority can be compromised through the way permissions are granted and interpreted, even where signatures and transaction validation are part of the system.
The next stage of crypto security needs to take a broader view of access.
It needs to consider how permissions interact, who controls the mechanisms that grant them, how independent the people exercising financial authority really are, and what an attacker could accomplish with any single compromised identity.
A wallet can be secure. A signature can be valid. A transaction can pass every check a contract has been programmed to perform.
The remaining question is whether the person or system behind that transaction was ever entitled to move the money in the first place.
That is a question banks have been dealing with for a very long time. Crypto needs to get considerably better at answering it.
Illustrations generated for this essay in the Sequence Forge comic manner. They are not panels from The Exploding Man, which is drawn by another artist.