Crypto Treasury Segregation of Duties: No One Signs Their Own Payment

The most common crypto treasury control mistake is believing the multisig is the control. A 3-of-5 where one person prepares the payment, pressures three colleagues to sign, and then books the result is fully signed and fully uncontrolled. This article is about the organisational layer that closes that gap — segregation of duties — and it is distinct from every cryptographic and policy control in the rest of the treasury cluster. The threshold says how many must sign; SoD says that the person who requests a payment cannot also be the one who approves, signs, and records it. It is the layer that completes the treasury control stack.

The short version

• A multisig threshold is not segregation of duties. The threshold is cryptographic; SoD is organisational; you need both.
• Separate initiator, approver, signer, and recorder, so no individual can both initiate and complete, or both execute and record.
• Apply dual control (two independent people for sensitive actions) plus step-up approvals (more authority as amount and risk rise).
• Governance actions are in scope: signer changes, modules, and policy controls are privileged and must be separated too.
• SoD without an audit trail is unverifiable — record who initiated, approved, signed, and recorded each action.
• This completes the treasury control stack: key security, policy controls, SoD, and accounting.

The threshold is not the control

A multisig threshold ensures multiple signatures approve a transaction. It does not ensure the requester, approver, signer, and recorder are different people. The same person can request, approve, and sign; several signers can be one team executing one person's instruction. A fully-signed transaction can be fully uncontrolled. Segregation of duties is the organisational control that the threshold cannot provide on its own — cryptographic and organisational controls are different layers.

The roles to separate

No individual should hold a combination that lets them both create and complete a payment, or both execute and record it. Observer roles (visibility without authority) support oversight without expanding control.

Dual control and step-up

• Dual control: a sensitive action needs two independent people, so it cannot be done unilaterally.
• Step-up approvals: more or higher-authority approvers as amount and risk rise — a small operational payment needs less than a large strategic transfer.

Together they make the control proportionate: routine activity is not over-gated, while high-risk actions face more independent eyes (the tiered-threshold principle as an SoD rule).

Governance is in scope too

The subtle gap: whoever can change the signer set can redefine who controls the treasury. SoD must cover governance actions — changing signers, enabling modules, and altering policy controls are privileged changes that need separation between proposer and approver, identity verification, and an auditable record — not something a single signer can do alone.

SoD must be evidenced

Every controlled action should record who initiated, approved, signed, and recorded it, so the segregation is evidenced rather than just intended. An audit trail that cannot show role separation cannot demonstrate the control existed. SoD without an audit trail is an unverifiable claim; the trail is what turns the policy into something an auditor can test — the same principle that closes every cluster of this treasury pillar.

Practical guidance

1. Do not treat the multisig as the control — add organisational SoD.
2. Separate initiator / approver / signer / recorder — no toxic combinations.
3. Apply dual control to sensitive actions; step-up by amount/risk.
4. Cover governance actions (signer/module/policy changes) under SoD.
5. Record initiator/approver/signer/recorder for every action — evidence it.
6. Tie SoD to the audit trail — confirm the design with internal-control advisers.

How vendor tools support SoD

Cryptio and Bitwave record approval and reconciliation roles distinctly from signing. Confirm the tool can evidence initiator/approver/recorder separation in the audit trail and treats governance changes as recorded privileged events. A tool that only logs the signature cannot demonstrate segregation of duties.

How Wag3s evidences SoD

Designing the role split and enforcing it is the treasury's responsibility, and an internal-control adviser's to validate. Wag3s Ledger supplies the evidence: it records who initiated, approved, signed, and recorded each treasury action, and treats signer, module and policy changes as documented privileged events, so segregation of duties is demonstrable in the audit trail rather than merely asserted — completing the control stack alongside key security, policy controls, and accounting. See the Ledger product page and the Wag3s for accountants page.

Step-by-step: designing SoD for a crypto treasury

The following procedure is illustrative and must be confirmed with your internal-control and security advisers. It reflects how a treasury team of four to eight people might implement SoD in practice.

Step 1 — Document who holds which role. Create a role matrix with four columns: Initiator, Approver, Signer, and Recorder. Name the individuals (not teams) in each column. Any cell with an individual's name in more than one column is a segregation gap. The matrix is reviewed at every personnel change.

Step 2 — Configure the multisig to enforce the minimum. A 2-of-3 multisig with three directors who are also the initiators of every transaction is cryptographically correct but organisationally unsegregated. Restructure so that at least one required signer is not the initiator of any routine payment. For a small team, this may mean the CFO signs but does not initiate, and a treasury analyst initiates but cannot sign alone.

Step 3 — Implement an approval workflow in writing before signing. Require a written (or recorded digital) approval from the approver before any signer collects signatures. The evidence sequence should be: (1) initiator creates a payment request with recipient, amount, and business purpose; (2) approver logs their approval against the request; (3) signers add signatures against the approved request only. A signer adding a signature without an upstream approval log is a policy breach.

Step 4 — Set step-up thresholds in writing. Define payment tiers: Tier 1 (e.g. below $10,000 — one approver, standard 2-of-3 threshold), Tier 2 (e.g. $10,000–$100,000 — two approvers, same threshold), Tier 3 (above $100,000 — CFO approval required, threshold may step up to 3-of-5). The thresholds are documented in the treasury policy, reviewed by the board annually, and cannot be waived without a documented exception.

Step 5 — Separate governance actions from operational payments. Changing the signer set, upgrading a Safe module, or modifying a spending policy is a governance action, not an operational payment. Governance actions must have a proposer (not a signer) and require approval from a higher authority (e.g. board resolution, DAO vote). No signer can unilaterally add or remove co-signers; the proposal and approval are documented before any on-chain execution.

Step 6 — Assign reconciliation and recording to the Recorder. The Recorder's job is to match every on-chain execution to an approved payment request and book the journal entry. The Recorder must not be the same person as the approver for the item they record. Any unmatched on-chain execution (an on-chain transaction with no upstream approval log) triggers a flag and investigation — it is an SoD break.

Step 7 — Audit the trail periodically. Monthly or quarterly, a control reviewer (ideally the Controller or an internal audit function) samples the approval records for a set of transactions and confirms: that an approval record exists for each, that the approver was not the initiator, that the signer was not the sole approver, and that the booking was done by the Recorder. The sample results are documented. This is the ongoing test that evidences SoD is operating, not just designed.

Common SoD failures in crypto treasuries

The "founder signs everything" failure. A founder who initiates, approves, and signs all outgoing payments is a single point of control and a single point of fraud risk. This is the most common gap in early-stage Web3 organisations. The fix is distributing at least the approval function to a second individual who can exercise independent judgement.

The "admin key" failure. A single wallet address used for both routine payments and for modifying the multisig configuration concentrates operational and governance power. The admin function should be on a separate key held under stricter control, not on the day-to-day payment key.

The "team signs, one person decides" failure. Three colleagues who always sign whatever the CEO requests are not an SoD; they are a 3-of-3 rubberstamp. The independence of each signer's judgement — including their willingness to refuse an unusual request — is what makes the threshold meaningful.

Further reading

• Crypto Treasury Board Reporting
• Crypto Treasury KPIs
• Crypto Treasury Accounting Policy
• Multisig Signer Policy and Recovery
• Multisig Treasury Policy Controls
• Safe Treasury Setup Best Practices

Sources

• Segregation-of-duties best practice: separate the requester (initiator), approver, signer, and recorder so no single individual has unilateral control; observer roles for oversight without authority
• Dual control for sensitive actions; step-up approvals as transaction amount/risk rises (proportionate control)
• Governance actions (signer/module/policy changes) are privileged and in SoD scope; SoD must be evidenced in the audit trail (a multisig threshold is cryptographic, not organisational SoD)