A company needs to pay a supplier in USDC. Someone in operations enters the address and amount, finance checks the invoice and budget, and an authorized signer releases the transfer. But if the address or amount changes after finance approves it, is that approval still valid?

It should not be. Separating Maker, Approver, and Signer roles only works when what was approved is exactly what gets signed, and when anyone can later reconstruct who requested, who approved, and who signed each payment.

## Key takeaways

- Wallet governance depends on whether the payment reason, the approval, the signing authorization, and the transaction record all refer to the same transaction.
- Multisig and MPC control how many keys must sign. They do not, on their own, control who may request a payment, what an approver must check, or whether the signed transaction matches the approved one.
- Any change to the destination, amount, asset, or network after approval should cancel the approval and send the request back for review.
- Policy changes, new addresses, split payments, and staff departures are the points where role separation is most often bypassed, so each needs its own control.

## Why one enterprise payment needs three separate roles

When one person can create, approve, and sign a transfer, a single compromised account, a single mistake, or a single dishonest employee is enough to move funds. Because blockchain transfers are generally difficult to reverse, there is little chance to correct the error afterwards. Separating the steps is the same separation-of-duties principle used across financial controls, which the [NIST security and privacy controls catalog (SP 800-53, control AC-5)](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) describes as identifying duties that require separation and enforcing that separation through access authorizations.

For a company that has been paying suppliers from a wallet controlled by one person, the risk is easy to underestimate. Nothing goes wrong until the day the address is wrong, the laptop is compromised, or the person leaves.

## Where each role's responsibility begins and ends

The **Maker** creates the payment request. Their responsibility is completeness and accuracy: the right destination, amount, asset, and network, with the business reason and supporting documents attached. The Maker should never be able to approve or sign their own request.

The **Approver** decides whether the company should make the payment. Their responsibility is the business judgment: the invoice is genuine, the counterparty has been verified, the amount fits the budget, and the payment is within policy. An Approver who only clicks "approve" on a summary, without seeing these details, is not providing a real check.

The **Signer** provides the cryptographic authorization that lets the transaction be submitted onchain. Their responsibility is narrow but critical: confirming that the transaction they are about to sign is the one that was approved, and protecting the key, key share, or device they control. Depending on the wallet design, a Signer may hold a private key, a share in a multi-party computation (MPC) setup, or one of several keys in a multisig wallet.

In a small team, one person may hold more than one role. When that happens, the company should know which control it has given up and what compensates for it, such as lower limits or an additional reviewer after the fact.

## What does multisig control, and what does it leave open?

Multisig and MPC enforce a signing threshold: a transaction is only valid when enough keys or key shares take part. That is valuable, and industry standards such as the [CryptoCurrency Security Standard](https://cryptoconsortium.org/2026/02/24/cryptocurrency-security-standard-ccss-aspect-1-02/) treat multi-signer configurations held by distinct operators as best practice.

A signing threshold does not, however, define who may create a payment request, what each approver must verify, or whether the transaction presented for signing is the one the business approved. A wallet can require three signatures and still lack a meaningful approval process if the signers are only confirming that a request arrived.

The gap became visible in February 2025, when attackers stole approximately USD 1.5 billion in digital assets from a major cryptocurrency exchange, a theft the [FBI attributed to North Korea](https://www.ic3.gov/PSA/2025/PSA250226). According to [investigations reported by BleepingComputer](https://www.bleepingcomputer.com/news/security/lazarus-hacked-bybit-via-a-breached-safe-wallet-developer-machine/), the attackers compromised a developer machine at the wallet interface provider and injected code that disguised a malicious transaction as a routine transfer. A multisig transaction of this kind can only execute once it collects the required signatures, so the signing threshold worked. What failed was the link between what the signers were shown and what they actually authorized.

## How do you keep the approved transaction and the signed transaction the same?

Tie each approval to the exact transaction it covers, and show signers what that transaction actually does. This is the control most often missing from enterprise wallet setups, and the one that matters most, because an approval should apply to one specific transaction rather than to a payment in general.

In practice, that means the approval is tied to the exact parameters of the request: destination address, amount, asset, network, and any contract call. If any of these change after approval, the approval should be cancelled automatically and the request should return to the Approver. A corrected typo in the address is still a new destination, and it deserves a new decision.

It also means the Signer should see the transaction details decoded from the actual transaction data, not a description generated by the system that created the request. If the two are produced by the same compromised component, a disguised transaction can look entirely normal.

*KryptoGO analysis:* when companies describe their wallet controls, they usually describe who can approve. The more useful question is what happens to an approval when the request changes. If the answer is "nothing," the approval step can be bypassed by editing the request after it has been approved.

## Turning role separation into policy

Role separation becomes reliable when it is written into rules that the wallet enforces, rather than habits that people follow. Five situations deserve explicit rules.

**A change after approval.** Any change to the destination, amount, asset, or network cancels the approval. The request goes back through the full approval path.

**A new receiving address.** Adding an address to the allowlist should be controlled separately from paying it. The address should be linked to a verified counterparty, screened for sanctions and other risk exposure, and approved by someone other than the requester. A short waiting period before first use gives the team a chance to notice an unauthorized addition.

**Several small payments on the same day.** Approval thresholds should consider cumulative amounts over a day or a rolling period. Otherwise, a large payment can be split into smaller ones that each stay below the review threshold. As an illustration, a policy might allow one approver for routine transfers to allowlisted addresses, require two approvers from different functions for larger or first-time payments, and require a senior approver plus a signing quorum above a set limit. The right tiers depend on each company's risk appetite.

**A change to the rules themselves.** If one administrator can raise limits, add a signer, or remove an approval step alone, every other control can be bypassed. Policy changes should need independent approval and should be logged like transactions.

**A signer who leaves.** Removing the person's access on the day they leave is only the first step. The company also needs to confirm that the signing threshold can still be met without them, that recovery still works, and that any requests they created or approved are reviewed.

## Making every payment traceable

After an incident or during an audit, the company should be able to answer four questions for any payment: who requested it, who approved it, who signed it, and whether the signed transaction matched the approved one. That requires logs that link the request and its documents to each approval decision, the signing participants, and the resulting TxID, along with failed or cancelled attempts and every change to users, roles, limits, and allowlists.

These records serve two purposes. Security teams use them to investigate incidents, and finance teams use them in month-end reconciliation to show that every outgoing transfer was authorized.

## Questions for evaluating a wallet's governance

When a company is choosing or reviewing an enterprise wallet, a few questions reveal more than a feature list. Does an approval become invalid if the request changes? Do approvers and signers see details decoded from the transaction itself? Are new addresses controlled separately from payments to them? Do thresholds apply to cumulative amounts? Can one administrator change the approval rules alone? What happens to the signing threshold when a signer leaves? And can the company export a complete record linking each payment's reason, approval, signature, and onchain transaction?

If the answers are unclear, the company likely needs to design its governance before it needs more wallet functionality.

## How KryptoGO approaches wallet governance

KryptoGO treats an enterprise payment as a sequence of checks rather than a single signing event. First, has the counterparty completed the required KYC or KYB verification? Next, have the receiving address and the transaction been screened for risk? Then, has the payment been approved by the right people under the company's permission rules? Does the transaction being signed match what was approved? And finally, is the record complete enough for reconciliation and investigation?

KryptoGO's enterprise wallet infrastructure supports role-based permissions, approval workflows, address allowlists, and audit records, and connects with KYC, KYB, and transaction monitoring, so that these checks can run in order on the same payment.

**Use the Enterprise Wallet Governance Checklist to review how your roles, approvals, address controls, and records work together.**

*This article is for general information only and does not constitute legal, security, or compliance advice. The appropriate control design depends on each organization's size, risk profile, regulatory obligations, and wallet architecture.*

## Frequently asked questions

### Does MPC remove the need for an approval workflow?

No. MPC changes how keys are generated and used, but it does not decide whether a payment is legitimate. Business approval still needs to happen before signing.

### How many approvers should a company require?

There is no universal number. Most companies scale the number of approvals with the amount and risk of the payment, and require at least one approver who is independent of the requester.

### Can a non-custodial wallet support enterprise governance?

Yes, if its control model supports role separation, approvals tied to specific transactions, address controls, recovery, and audit records. The deciding factor is the governance model, not whether the wallet is custodial or non-custodial.

### How often should wallet permissions be reviewed?

On a regular schedule set by internal policy, and immediately after any role change, departure, or security incident.

## Sources

- National Institute of Standards and Technology, [*SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations*](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final), control AC-5, Separation of Duties.
- CryptoCurrency Certification Consortium (C4), [*CryptoCurrency Security Standard, Aspect 1.02: Wallet Creation and Signing*](https://cryptoconsortium.org/2026/02/24/cryptocurrency-security-standard-ccss-aspect-1-02/), February 2026.
- Federal Bureau of Investigation, [*North Korea Responsible for $1.5 Billion Bybit Hack*](https://www.ic3.gov/PSA/2025/PSA250226), Public Service Announcement I-022625-PSA, 26 February 2025.
- BleepingComputer, [*Lazarus hacked Bybit via breached Safe{Wallet} developer machine*](https://www.bleepingcomputer.com/news/security/lazarus-hacked-bybit-via-a-breached-safe-wallet-developer-machine/), February 2025.

In an enterprise wallet, the Maker requests, the Approver decides, and the Signer executes. How to set thresholds, allowlists, offboarding, and audit logs.

What Are Maker, Approver, and Signer Roles in an Enterprise Wallet?

Binance Hack: What It Means for Businesses Using Stablecoins

How Should Finance Teams Reconcile Stablecoin Payments at Month End?

KYB Onboarding: Why Cross-Border Verification Slows Down

Why Are Enterprises Using Stablecoins Beyond Crypto Trading?

Travel Rule and Cross-Border Payments: What Businesses Need to Rethink Before Implementation

What Taiwan's New VASP Act Means for Businesses: Five Key Takeaways

Why Stablecoin Transfers Break at Scale: Reconciliation, Compliance, and Address Risk

Where White-Label Wallet Projects Actually Get Stuck

How Mining Farms Use Stablecoins for Electricity Payments: From Collection to Compliance

What Are KYC, KYB, and KYA? What Businesses Actually Need to Check When Using Virtual Assets

Who Actually Needs Stablecoin Payments in 2026? - And Why Traditional Systems Can’t Support Them

What Changes When a Company Starts Accepting USDT? A Practical Guide for Finance Teams

From 2,000 BTC to Enterprise Treasury Risk

Cross-Border Trade in 2026: Receiving USDT from FX-Controlled Markets

Why Companies Shouldn’t Build Their Own Wallets for Stablecoin Payments

As Stablecoins Go Mainstream, Why Taiwan Enterprises Have a Rare Strategic Window

Why Are We Hearing So Much About Stablecoins—and Why Does Taiwan Suddenly Matter?

What Do ISO 27001, ISO 27701, and SOC 2 Type 2 Actually Protect—and Why Should Companies Care?

Cross-Border Wire Transfers vs. Stablecoin Payments: How Much Can Companies Actually Save—and At What Cost?

Why VASP Registration and Security Certifications Are Not Advantages—They’re the Minimum Requirement for Using Stablecoins in Corporate Payments

KryptoGO.xyz: The absolute best address clustering platform on the market.

2025 Mid-Year Update: Charting a Clearer Course

[Important Security Notice] Protect Your Digital Assets: Identify and Revoke Malicious Wallet Approvals

Product Newsletter: July 16, 2025

When Life Takes Away Your Lemons

The Insiders Among Us: June 18th, 2025

The Press F Experiment: June 4, 2025

It’s a Date! Vibe Coding Workshop: May 22, 2025

Unlocking Web3 Potential: Real-World Applications of KryptoGO Wallet

Meet KryptoGO Pay: April 30, 2025

Yua Mikami Ignites Solana Meme Coin $MIKAMI – The Ultimate Guide 

Create Your Crypto Payment Link: No Code Required, Accept Payments Globally!

One-Click Integration of Crypto Payments into Your App

The Future is Universal: April 9, 2025

The Signals Update: March 26, 2025

The Pump Hound Update: March 12, 2025

Escape Exchange Risks: Why KryptoGO Self-Custody Wallet is the Ultimate Choice for Web3 Users

Handle Login and Group Chats Update: February 26, 2025

Evolution of Taiwan's VASP Regulation: From Declaration to Licensing

Beginner's Guide to Hyperliquid ft. KryptoGO App: Feb 12, 2025

Refining the Waves with Ocean v3: January 22, 2025

Biweekly Update: January 8th, 2025

The '25 Roadmap Preview: December 18, 2024

“The King of Tron” Update: December 4, 2024

Biweekly Update: November 20, 2024

The 'Pulse' Update: November 6, 2024

In-Depth Technical Analysis: Why Choose a Mature Crypto Wallet Service Instead of Building Your Own

Five Stages of Evolution for Crypto Wallets

Biweekly Update: October 23, 2024

Biweekly Update: October 09, 2024

Biweekly Update: September 25, 2024

Send Via Link campaign and "Gimme more wallets" Update :  September 11, 2024

The “Send Crypto via Link” Update: August 28, 2024

KryptoGO's Award-Winning Innovations at ZK Hack Montreal, ETHDenver, and ETHTaipei

Stake Your Stables! Biweekly update: August 14, 2024

The “Not Just A Wallet” Update: July 31, 2024

Biweekly Dev Update: July 17, 2024

Biweekly Dev Update: July 3, 2024

Biweekly Dev Update: June 5, 2024

Challenges and Solutions for Using Cryptocurrency in Business Operations

Biweekly Dev Update: May 22, 2024

Biweekly Dev Update: May 8th, 2024

Biweekly Dev Update: April 17th, 2024

Biweekly Dev Update: April 3rd, 2024

Biweekly Dev Update: March 20th, 2024

Making Sense of Decentralized Wallets: EOA and Smart Contract Explained

Biweekly Dev Update: March 6th, 2024

Centralized vs. Decentralized: The Ultimate Guide to Choosing the Right Crypto Wallet for Your Business

Navigating Compliance in Taiwan's Cryptocurrency Market: From Fraud Prevention to Enhanced Regulation

【Kind Reminder】Please be vigilant against scams. KryptoGO will never proactively ask you to make investment transactions.

Biweekly Dev Update: February 21th, 2024

Biweekly Dev Update: February 7th, 2024

Web3 Business Operations: Future Trend or Current Necessity?

Biweekly Dev Update: January 24th, 2024

Biweekly Dev Update: January 10th, 2024

Biweekly Dev Update: December 27th, 2023

Biweekly Dev Update: December 13th, 2023

Biweekly Dev Update, November 29th, 2023

Biweekly Dev Update, November 15, 2023

Biweekly Dev Update: November 1st, 2023

Biweekly Dev Update: October 19th, 2023

Biweekly Dev Update: Oct 4th, 2023

The Chatroom and Social Update: September 20th, 2023

Play-to-Earn vs. Blockchain Gaming: Rediscovering the Joy of Play

Product Launch Update: September 6th, 2023

KryptoGO Launches AI-Powered One-Stop Web3 Cloud Solution

Biweekly Update: August 23rd, 2023

The Keyless Wallet Update: August 9th, 2023

Biweekly Update: July 26th, 2023

Biweekly Update: July 12th, 2023

Biweekly Dev Update: June 7th, 2023

Unlock the Future: Passkey + DID + FIDO - Exploring the Next Generation of Digital Wallets and Identities

Biweekly Dev Update: May 24th, 2023

Biweekly Dev Update: May 10th, 2023

Biweekly Dev Update: April 26th, 2023

KryptoGO team wins three ETHGlobal Tokyo Hackathon Awards! Join hands with YGG Japan and IVC to lay out GamiFi industry

Biweekly Dev Update: April 12th, 2023

Help enterprises enter the Web3 world painlessly! What is WaaS?

Biweekly Dev Update: March 22th, 2023

What Are Maker, Approver, and Signer Roles in an Enterprise Wallet?

Recommend Articles

Hot Articles

Hot Tags