Crypto Treasury Segregation of Duties: Roles, Quorums and Approval Controls

No single person or system should hold two of these roles for the same transfer. The last column lists the published guidance each control draws on.

The SEC's October 1, 2026 custody proposal would require an investment adviser that self-custodies crypto assets to have systems that "prevent unauthorized transfers". At a minimum, those systems would require "joint authorization of crypto asset transfers by two or more designated persons, at least one of which must be a management person". The stated aim is that "multiple persons ... are independently involved to oversee and gatekeep access". The proposal also asks, in Question 77, whether software-based agents should be allowed to act as signatories^[3]. This is a proposal, not a final rule.

SEAL's guide to large transfers gives example approval tiers: under $100K, the treasury manager; $100K to $1M, the CFO and security officer; over $1M, the CFO and CEO. It also says at least two team members should independently confirm the recipient address over different channels^[4].

A quorum counts people. The cases below show why the path also matters. If a request can reach the signer without passing through the quorum, the number of approvers doesn't matter.

These facts come from Bitget's official incident page, last updated October 4, 2026^[1]:

• At 18:31 UTC on September 24, Bitget's security system detected unauthorized transfers involving certain hot and warm wallets.
• Final verified figure: approximately $388M transferred out, involving 12 wallet addresses, all of them hot or warm wallets. Cold wallets were unaffected.
• Attackers exploited a zero-day vulnerability in a third-party security product to reach critical internal management systems and steal high-privilege credentials.
• They then "directly wrote forged withdrawal commands into the wallet system. This caused the wallet to process them as normal withdrawals, bypassing the risk control verification process before withdrawal records were generated."
• Afterwards, the attackers "deleted traces that may have been left by the forged withdrawal commands".
• "Private keys were not compromised."
• Remediation listed by Bitget includes resetting all internal credentials, tightening access to highly sensitive permissions, and "strengthened independent withdrawal verification". Bitget says a formal security report will follow.

For segregation of duties:the risk checks sat before a command path that a single stolen credential could write to directly. Withdrawal records were created only after that bypass, so reconciling against the wallet system's own records would not have shown the gap. We don't know Bitget's internal architecture beyond what it has published.

These facts come from Blockstream's technical assessment, published September 23, 2026^[2]:

• At 13:53 UTC on September 6, an attacker exploited a vulnerability in the rangeproof verification cache of Elements, the software Liquid runs. A transaction whose output "was not backed by its inputs" passed validation and was accepted by Liquid nodes, including federation functionary nodes. It created about 4,000 unbacked LBTC.
• The attacker redeemed that LBTC through the standard peg-out process via SideSwap, a federation member holding a Peg-out Authorization Key (PAK). This produced a withdrawal of about 4,000 BTC.
• Before the network was halted, the reserve fell from about 4,205 BTC to 197 BTC. Routine peg-outs already in progress contributed to the drop. Of the amount attributable to the unauthorized transactions, 3,400 BTC was returned. About 602 BTC remained subject to recovery efforts.
• "The SideSwap PAK itself was not compromised, forged or stolen." The assessment also states that "no key was compromised."
• Under the PAK design, an offline key controls where bitcoin can go and an online key controls who can request it. Releasing funds from the offline wallet takes a manual step, and that delay is meant to give the federation time to act.
• Citing SideSwap's own statement, the assessment says SideSwap kept its peg-out signing key online, "despite the Federation Charter requiring it to be kept offline". Payouts were forwarded automatically in the same Bitcoin block as the peg-out. SideSwap also "applied no size limit, velocity control, or wallet-history check to peg-out orders," and the roughly 4,000 LBTC order "went through with no human review."

For segregation of duties:the design kept "where funds can go" separate from "who can ask", and relied on a manual step to buy time. Once that step was automated, both roles ran through one path with no pause.

1. Write down who may initiate, approve, sign, change the address book and change policy. Make sure no one holds two of these roles for the same transfer.
2. Collect approvals in a system separate from the one that initiates and executes transfers. Make the signer refuse any request that has no matching approval record.
3. Restrict who can write directly to the wallet or signing backend. Treat direct write access as a signing permission, with its own approver.
4. Have a different person approve each address-book addition, after a cooling-off period of 24–48 hours (72 hours for high-security accounts).
5. Require separate approval for policy changes (limits, quorums, tiers). Don't apply a change to transfers already in flight.
6. Raise the number and seniority of approvers with the amount, and require independent confirmation of the recipient address over a second channel.
7. Keep the manual or delayed steps your design depends on. If you automate one, replace the control it provided, such as a size cap, a velocity limit or a hold.
8. Apply size, velocity and history limits at the point of release, not only at intake.
9. Reconcile on-chain outflows against approval records from an independent source, not against the wallet system's own withdrawal records.
10. Store approval records outside the executing system, write-once, so that evidence cannot be removed after the fact.
11. Decide whether software agents may initiate, approve or sign, and which role they may hold. The SEC proposal asks this question directly.
12. Review the separation at least once a year and after any change to systems or staff.

The companion guide, pre-signing transaction verification, covers what to check on each transfer before it is signed.