State of the Art of Private Key Security in Blockchain Ops - 4. Approvals
and Policies

Welcome to the fourth and final post of the series on the State of the Art of Private Key Security for Blockchain Operations. In this post, we’ll focus entirely on approvals and policies, which role is to ensure that sensitive actions, such as transactions or configuration changes, are executed only when properly authorized. We'll explore how policies are defined, how approval processes are enforced both on-chain and off-chain, and the best practices that help organizations avoid costly mistakes or insider threats.

• [1/4]: Concepts, Types of Wallets and Signing Strategies
• [2/4]: Common Custody Solutions Architectures
• [3/4]: Private Key Storage and Signing Module
• [4/4]: Approvals and Policies (this post!)

Approvals and Policies

We have mentioned now several times approval policies. This is also considered a critical element in the infrastructure of a blockchain operations solution. We can differentiate two different elements, which may or may not be tied together: the policies (or rules) that define which actions can be taken or denied, or the number of approvals required; and the processes that ensure that the transaction has been approved by the correct number of participants. How these approvals and policies are defined depends completely on the solution, and can be implemented in different ways. Some of these actions could be defined on-chain (e.g. a multisig smart contract) and some others may have off-chain implementations (e.g. deciding if an interaction with a smart contract is allowed or not).

A simplified example of an approval process on an off-chain custodial solution may go like the following:

From the moment the transaction is signed, it depends on the business logic and architecture to execute the transaction on-chain.

One of the most critical aspects to ensure a valid system is to guarantee that modifying a policy or the approval system requires approval using the current system.

And, relating the approval element with the signer module we talked about (for off-chain implementations), it is necessary to ensure that a signer only accepts messages that have been previously approved.

Policies

Policies allow organizations to define which kinds of actions can be taken and which approval policies are required for each action. These actions are comparable to some extent to firewall rule policies. They should, by default, deny all actions and only accept the ones required by the business. These policies do not refer only to transactions on the blockchain, but also to changes in approval policies, or to operations such as adding whitelisted addresses.

Some examples of policies may include:

• Allow transfers of less than X USD to whitelisted addresses without additional approvals.
• If daily operations surpass X USD, they cannot be automatically approved.
• Only users with Role R can initiate/propose a new transaction.
• Sensitive operations (e.g. transfers or whitelisting) require approvals from 2 people in Operations, 1 in Finance, and 1 in Security.

Moreover, policies should also be able to understand smart contract interactions and their parameters, not only typical ERC-20 transfers but also arbitrary interactions with other smart contracts. This would allow organizations to define specific policies (such as different types of swaps in DeFi that do not compromise security). For example, denying big slippages could prevent mistakes costing hundreds of thousands of USD (in this example, the UniswapV3 amountOutMinimum parameter was set to 0, stating that they were able to accept 0 USDC for their 220,806 USDT, which a MEV searcher of the dark forest took advantage of to make a sandwich attack).

Approvals

Normally, the bare minimum is to require a threshold or quorum, defining the minimum number of participants required to approve a transaction. For example, 3 out of 5 participants must sign or approve the transaction before it can be executed. This may be enough for small organizations, but usually larger organizations require more complex approvals, involving multiple departments (e.g. Finance, Operations, Security) and also defining the role of Proposer or Initiator, assigned to specific users who are allowed to initiate transactions.

One of the most important aspects of approval processes is understanding the human factor. As we are kindly reminded from time to time, if the people approving a transaction do not have the appropriate tools to understand what they are approving, it will probably end in mistakes, and possibly in thefts compromising their contracts or the digital assets under their control.

To help approvers understand what they are approving or signing, two main methods are recognized:

• Transaction Decoding: Transactions, and especially smart contract transactions, should be decoded into actions resulting from the transaction. For example:

  • Swap of 100,000 USDC for 99,587 USDT on UniswapV2 (addresses should also be included, as names are not descriptive enough)
  • Transfer of 300 ETH to ADDRESS

• Transaction Simulation: Beyond decoding a transaction, a simulation should be made, highlighting any dangerous actions and providing a trace of the calls made by the transaction. Not all approvers may have the knowledge to understand every detail, which is why an organization may require approval steps by different departments. Some useful simulation outputs could include:

  • All calls and delegatecalls made by a contract
  • Events emitted (e.g. OWNER changed from PREVIOUS_OWNER to NEW_OWNER)
  • Specific state changes
  • Other decoded actions (similar to the ones listed in Transaction Decoding)

A combination of transaction decoding and simulation enables a detailed review of what a transaction is going to do before approving it, highly increasing the safety and security of the solution.

Approval Dispatcher / Coordinator / Orchestrator

To make a solution requiring approvals usable, there must be a way to automatically send the messages or transactions to be signed to all the approvers. This again is completely dependent on the solution. Sometimes it is an API or a message queue. It may be integrated into the approvals module or used separately. Some solutions, such as the on-chain multisig Safe{Wallet}, use an API where transactions can be proposed.

In any of these systems, it is critical to ensure that only authorized parties can propose messages. This could be a user with a specific role (in off-chain authenticated systems), or an authorized address with a proposer role (in on-chain multisig wallets). Sometimes a mix of both is used.

Off-Chain vs On-Chain Approvals and Policies

We have mainly talked in this post about off-chain processes for approval policies. However, these can also be implemented on-chain in smart contracts. The main drawback of this is that implementation depends on the chain, and may not be possible in some cases (for example, Bitcoin supports threshold approvals, but more complex policies are not possible).

When implemented on-chain, it can be ensured that these policies are followed, eliminating any potential Single Point of Failure.

Final Thoughts

As we've explored throughout this post (and the entire series) securing blockchain operations goes far beyond private key storage. Approval policies and enforcement mechanisms are what ultimately give meaning to key custody, enabling organizations to manage risk, distribute responsibilities, and prevent misuse.

By implementing clear policies, robust approval workflows, and secure communication between participants and components, organizations can significantly increase resilience, not just against external and insider threats, but also plain operational mistakes. Case in point: last Wednesday (October 15, 2025) Paxos accidentally minted $300 trillion of PYUSD before burning it, underscoring why limits and multi-party approvals are non-negotiable. Whether these controls are enforced off-chain or on-chain, the critical factor is that no sensitive operation should ever happen without adequate review and authorization.

Even if you outsource key custody to a third-party provider, your exposure doesn’t disappear, it just shifts. Keep them least-privileged, rotated and monitored; and remember, how you configure approval and transaction policies, is what prevents accidents and abuse. In practice, most real incidents comes not from broken cryptography, but from over-permissive keys and lax policies. Harden those controls as if they were your keys, because operationally, they are.

This concludes our four-part journey through the State of the Art of Private Key Security for Blockchain Operations. We hope it helps to understand how to design and build safer, more trustworthy blockchain infrastructure.

About Us

At NCC Group, we provide comprehensive security assessments for blockchain projects, crypto exchanges and custodial solutions, ensuring robust security controls across every layer of your project. Our approach is tailored to meet the unique security challenges of each project, combining in-depth architecture reviews, threat modeling, and end-to-end testing. The scope of these assessments varies based on the technologies in use but typically focuses on the following key areas:

• Key Management and Access Security
  • Analyze the key and seed generation process to identify potential weaknesses that could reduce key entropy or allow unauthorized key recovery.
  • Assess the security of hardware security modules (HSMs) and cold storage solutions used for key protection.
  • Evaluate hot wallets and operational wallets to ensure robust security controls are in place.
  • Review access control mechanisms governing key usage and storage to prevent unauthorized transactions.
• Approval Processes and Transaction Validation
  • Assess segregation of duties in the transaction approval workflow.
  • Identify human-factor vulnerabilities, such as an inability to properly verify raw transactions before approval.
  • Evaluate transaction approval policies, including whitelisting for addresses, assets, and smart contracts, as well as transaction limits.
  • Ensure strong validation mechanisms to prevent transaction tampering or unauthorized approvals.
  • Review gas consumption efficiency and potential denial-of-service (DoS) risks related to transaction execution.
  • Ensure proper Ether unit handling (e.g., preventing errors in conversions from Wei to Ether).
• Race Conditions, Replay Attacks, and Settlement Processes
  • Assess the risk of replay attacks, which could allow a blockchain transaction to be executed multiple times (e.g. withdraw!).
  • Identify race conditions that could lead to unintended multiple operations.
  • Verify the consistency of off-chain and on-chain databases, ensuring alignment between off-chain records and on-chain wallet balances.
• Cryptographic Implementations and Third-Party Integrations
  • Ensure the secure implementation of cryptographic algorithms and protocols, avoiding weak or misconfigured cryptographic schemes.
  • Assess the security of third-party integrations, ensuring that external dependencies do not introduce vulnerabilities.
  • Review API key management and secret-handling practices to prevent unauthorized access.
  • Identify third-party risks that could impact the security of custodial assets and operations.
• Security Assessment Phases Our security assessments typically involve multiple phases, tailored to the specific needs of each project. The most common phases include:
  • Architecture Review and Threat Modeling
  • Web Application / Web3 Security Assessments
  • Smart Contract Audits
  • Cloud Configuration Reviews
  • Kubernetes Security Assessments
  • SDLC and DevOps Security Reviews
  • Infrastructure Security Audits

If you are interested in knowing more, please don’t hesitate to contact us to get in touch with our BlockSec team.