If you run digital assets at work, you’re not “holding coins”; you’re operating a treasury system. That means segregation of duties, policy-driven approvals, audit trails, and boring reliability. This guide gives you a complete blueprint—architecture, policy templates, risk controls, incident runbooks, monitoring, and a 90-day rollout plan—so your team can move funds confidently, reconcile cleanly, and satisfy auditors without drama.

Digital One Agency designs and ships this end-to-end: custody architecture (MPC or multi-sig), policy engines and approvals, audited smart contracts, and global rails via Digital One Payments (on- and off-ramps, refunds, receipts, reconciliation). If you want custody that feels safe and boring, we build the lot.

Related reading (internal):

• How Do I Avoid Common Crypto Scams?
• Bridges & Cross-Chain Safety
• Account Abstraction & Smart Wallets
• Global Crypto Payments: On-/Off-Ramps
• What Are Stable Coins (For The Better)
• Layer-2s Explained: Optimistic vs ZK
• What Are Gas Fees & How Can I Reduce Them?
• MEV & Transaction Protection
• Crypto Tax Basics
• What Is DeFi?

General information only. Not legal, tax, accounting or financial advice. Seek professional guidance for your circumstances.

TL;DR (one screen)

• Separate Treasury (cold) from Operations (hot). Treat hot wallets as expendable, with hard limits.
• Choose MPC or multi-sig (or both). Wrap them in a policy engine: maker/checker approvals, per-tx/daily limits, address allow-lists, and halt rules.
• Standardise key ceremonies, backups, and rotations. Keep PII off-chain; use on-chain references in human-readable receipts.
• Run dashboards and alerts for balances, approvals, peg/bridge status, and fee bands. Reconcile daily to your ledger.
• Prepare for failure with incident runbooks (phishing, wrong address, peg wobble, bridge pause).
• Roll out in 90 days: blueprint, pilot with tiny tickets, tabletops, then scale with caps.

Table of contents

1. Threat model (what can actually go wrong)
2. Custody architecture (three-tier pattern that works)
3. MPC vs multi-sig vs smart-wallet policies (what to use when)
4. Approvals, limits, and allow-lists (your control plane)
5. Key ceremonies, backups, and rotation
6. Hot-wallet hygiene and allowance management
7. Policy engine: payments, bridges, stablecoins, halts
8. Monitoring & dashboards (what to watch)
9. Records, receipts, reconciliation, and audit
10. People & process: roles, onboarding/offboarding, training
11. Incident runbooks (copy-paste)
12. 90-day rollout plan
13. KPIs the board will care about
14. Frequently asked questions
15. Glossary
16. One-page policy template (fill-in)

1) Threat model (what can actually go wrong)

Most losses come from human factors and simple hygiene gaps, not exotic zero-days. Your controls should blunt:

• Phishing and spoofed approvals: malicious sites, address poisoning, fake support. See Avoid Common Crypto Scams.
• Wrong-address and fat-finger errors: long strings, look-alikes, mixed networks.
• Key compromise: seed leaks, device malware, SIM swaps, credential reuse.
• Unlimited token approvals: a forgotten allowance lets a bad contract pull funds later.
• Bridge and peg risk: wrapped assets or paused bridges during stress. See Bridges & Cross-Chain Safety.
• Fee/MEV surprises: paying too much or being sandwiched on swaps. See MEV & Transaction Protection and Gas Fees.
• Process drift: undocumented exceptions, one-off hacks that become “how we do it”.

Design every control around preventing or containing these.

2) Custody architecture (three-tier pattern that works)

Think in tiers, not wallets:

1. Treasury (cold, strategic)
   • Purpose: long-term holdings, investor funds, operating runway.
   • Tech: MPC or multi-sig, hardware-backed, offline or limited connectivity.
   • Policy: highest approval thresholds, strict address allow-lists, and no dApp connections.
   • Flow: sends only to pre-approved Operations wallets or regulated off-ramps.
2. Operations (warm/hot, controlled)
   • Purpose: payroll, vendor payments, customer refunds, on-chain actions.
   • Tech: smart wallets with account abstraction or MPC/multi-sig; per-tx and daily limits; maker/checker.
   • Policy: live on a Layer-2 for costs; keep a gas float; restrict destinations to allow-list. See Layer-2s Explained.
3. Experiment/Claim (hot, disposable)
   • Purpose: airdrops, mints, testing.
   • Tech: basic hot wallet with tiny balances.
   • Policy: never hold funds overnight; treat as untrusted.

Segregation principle: funds travel Treasury → Operations → External and back; never straight from Treasury to random venues. Keep separate browser profiles/devices for Ops vs everything else.

3) MPC vs multi-sig vs smart-wallet policies (what to use when)

Multi-sig (on-chain N-of-M)

• Pros: simple mental model; approvals visible on-chain; easy auditor story.
• Cons: relies on the chain’s multi-sig contracts; upgrades/governance must be conservative.

Use for: Treasury, long-term holdings, high-value Ops.

MPC (off-chain threshold signatures)

• Pros: key shares split across devices/people/providers; flexible recovery; chain-agnostic.
• Cons: approvals are off-chain unless mirrored; audit trail must be integrated.

Use for: Treasury and Ops where you need provider redundancy and chain coverage.

Account abstraction (smart-wallet policies)

• Pros: session keys, sponsored gas, spending limits, policy plugins; far better UX for routine Ops.
• Cons: depends on L2 support and reliable paymasters.

Use for: Operations on an L2—refunds, payouts, consumer UX. See Account Abstraction & Smart Wallets.

Pattern that works: Treasury as MPC/multi-sig, Operations as smart wallets with maker/checker and limits, backed by a small multi-sig for escape hatches.

4) Approvals, limits, and allow-lists (your control plane)

Approvals (maker/checker)

• Maker proposes; checker approves. Add risk-based thresholds: larger payments require more signers.
• Emergency lane for small, routine payouts with tighter caps.

Limits

• Per-transaction and rolling daily caps; different caps by vendor type (payroll vs refunds).
• Rate limits to dampen blast radius (e.g., max 3 payouts/minute).

Allow-lists

• Vendors, exchanges, on-/off-ramps, and internal wallets.
• Separate lists per tier (Treasury list ⊂ Ops list).
• Change control: two signers to add/remove; cooling-off before first use.

Purpose codes

• Tag each payment (vendor, payroll, refund, treasury rebalance). This flows into receipts and accounting.

5) Key ceremonies, backups, and rotation

Generation

• Create keys on dedicated, clean devices. Record who/when/how.
• Use quorum splits (e.g., 2-of-3 shares across separate people/locations).

Backups

• Encrypted backups for each share; sealed, duplicate, and tested restore.
• Store backup locations and custodians in your policy register.

Rotation

• Triggered by personnel changes, travel, incident suspicion, or time-based (e.g., annually).
• Practise on a low-value wallet quarterly so rotations feel normal.

Recovery drills

• Tabletop “lost device” and “two signers unavailable” scenarios. Record timings and gaps.

6) Hot-wallet hygiene and allowance management

Hot wallets are where comfort creeps in. Keep them disciplined:

• Finance-only browser profile with minimal extensions; bookmarks only; never click ads/DM links.
• Hardware prompt verification: read addresses on device screens; ban blind signing.
• Monthly allowance revokes: list all token approvals and revoke stale ones.
• Tiny balances: keep just enough for today’s work plus a buffer.
• Session keys (via account abstraction) for limited scopes and durations, not blanket permissions.
• Device hardening: OS updates, disk encryption, separate user accounts, no personal apps.

See: Avoid Common Crypto Scams.

7) Policy engine: payments, bridges, stablecoins, halts

Your policy engine enforces rules before a transaction is signed.

Payments

• Auto-reject if destination not in allow-list, cap exceeded, or purpose code missing.
• Require extra signers for first-time vendors or out-of-hours payments.

Bridges

• Canonical bridges for size; split tickets; disallow weekends for large moves.
• Test each new route with a tiny amount. See Bridges & Cross-Chain Safety.

Stablecoins

• Prefer native stablecoins on your operating L2; set peg thresholds (e.g., halt if deviation >0.5% for N minutes). See What Are Stable Coins.

Fees/MEV

• Enforce protected routing for swaps where available; set slippage defaults. See MEV & Transaction Protection and Gas Fees.

Halts

• One switch pauses new deposits or payments under predefined conditions (bridge paused, peg deviates, sequencer outage). Publish a status note internally.

8) Monitoring & dashboards (what to watch)

• Balances & exposures: by wallet, chain, asset; show native vs wrapped stablecoins.
• Approvals & allowance changes: new token approvals today; oldest outstanding approvals.
• Payments & exceptions: failed policy checks; out-of-hours attempts; new vendor first-use.
• Peg & bridge status: deviation alerts; paused routes; fee bands.
• Gas floats: low-balance alerts per chain.
• Change logs: who added an address, raised a cap, or toggled a halt.

Run daily reviews and a weekly control attestation: “No unauthorised changes; exceptions closed.”

9) Records, receipts, reconciliation, and audit

The auditor’s dream is simple: one place where a payment has a human-readable receipt with matching on-chain references.

Receipts

• Include date/time, masked addresses, purpose code, amounts (asset/fiat), tx IDs, and who approved.
• Attach to vendor invoice or refund case ID.

Reconciliation

• Daily export to your ledger with tx references; an exceptions queue for any mismatch.
• Month-end close: run an allowance report (what approvals exist), balances by chain, and a bridge/peg incident summary.

See: Global Crypto Payments and Crypto Tax Basics.

10) People & process: roles, onboarding/offboarding, training

Roles

• Maker (prepares payments), Checker (approves), Custodian (key share holder), Auditor (read-only oversight).
• Separate duties; no one person can propose and approve above small caps.

Onboarding

• Issue dedicated devices; set up authenticators; assign least-privilege roles; train on phishing and approvals.

Offboarding

• Revoke access immediately; rotate keys if the person held a share; review allow-lists they touched.

Training cadence

• Quarterly phishing refreshers; tabletop drills; policy quizzes.

11) Incident runbooks (copy-paste)

A) Suspected phishing or wrong-address attempt

1. Freeze: stop all pending payments.
2. Isolate affected device; switch to clean machine.
3. Revoke token approvals on the affected wallet.
4. Verify intended destination via signed call-back with the vendor.
5. Report internally with screenshots, URLs, tx IDs; update allow-lists if needed.
6. Resume under heightened review for 24–48 hours.
   See: Avoid Common Crypto Scams.

B) Key compromise suspected

1. Pause Ops via halt switch.
2. Move remaining funds to Treasury or fresh wallets.
3. Rotate credentials (email, exchange, password manager); revoke API keys.
4. Re-issue key shares; update quorum and device inventory.
5. Post-mortem and policy patch.

C) Stablecoin peg deviation

1. Halt new flows in the affected asset.
2. Quantify exposure by chain and venue (native vs wrapped).
3. Rotate to approved alternatives per policy; split tickets.
4. Notify stakeholders; resume when peg holds inside threshold.
   See: What Are Stable Coins.

D) Bridge paused or sequencer outage

1. Halt large moves.
2. Route via secondary path for capped payments or delay non-urgent flows.
3. Communicate expected delays; keep receipts updated.
4. Reconcile after green status.
   See: Bridges & Cross-Chain Safety and Layer-2s Explained.

E) Allowance abuse or odd approval detected

1. Revoke suspicious approvals.
2. Snapshot balances and allowances; compare to prior day.
3. Audit recent dApp connections; tighten session-key scopes.
4. Raise approval review frequency temporarily.

12) 90-day rollout plan

Days 1–30 — Blueprint & guardrails

• Write a one-page policy (template below).
• Pick custody pattern: MPC or multi-sig for Treasury; smart wallets for Ops.
• Separate Treasury, Operations, Claim tiers; create allow-lists.
• Stand up dashboards and halt switches; set gas floats and alerts.
• Pilot with $10–$100 equivalent test tickets only.

Days 31–60 — Pilot live flows

• Pay one friendly vendor and one payroll batch via Ops.
• Run one refund end-to-end with human-readable receipts.
• Bridge a tiny amount using the canonical route; confirm arrival; store receipts.
• Practise monthly allowance revokes; document the steps.

Days 61–90 — Harden & scale

• Turn on maker/checker for all Ops; enforce per-tx/daily limits.
• Expand allow-lists; add two on-/off-ramps; test both quarterly.
• Run tabletops: phishing + bridge pause + peg wobble.
• Publish a status page and internal change log; schedule monthly control attestations.

Outcome: a custody stack with policy, controls, receipts, dashboards, and muscle memory for bad days.

13) KPIs the board will care about

• Operational: payments processed, fail rate, median approval time, out-of-hours attempts.
• Risk: number of new approvals, oldest outstanding approval age, peg/bridge downtime minutes, incidents and mean-time-to-resolve.
• Financial: gas sponsorship spend, fee bands, reconciled-on-time %, exceptions aged >48h.
• Governance: change-log entries, key rotations performed, tabletop drills completed.
• Exposure: asset mix (native vs wrapped), counterparty caps usage, concentration by venue.

14) Frequently asked questions

MPC or multi-sig—which is safer?
They solve different problems. Multi-sig gives visible on-chain approvals; MPC gives flexible key sharing and chain coverage. Many teams use MPC for Treasury and smart-wallet policies for Ops, with a small multi-sig as a backstop.

Do we need account abstraction?
If you want fewer pop-ups, sponsored gas and spend limits, yes—especially on L2. See Account Abstraction & Smart Wallets.

How big should our hot-wallet balance be?
Enough for a day or two of operations plus a buffer. Top up from Treasury as needed; never park weeks of runway in hot wallets.

Can we automate approvals?
Automate routing and limits, not sign-off. Keep a human checker for anything meaningful; use risk-based thresholds.

What about tax and accounting?
Use human-readable receipts with on-chain references; reconcile daily; keep an exceptions queue. See Crypto Tax Basics and Global Crypto Payments.

15) Glossary

• MPC (Multi-Party Computation): split key shares; threshold signatures without reconstructing a single key.
• Multi-sig: on-chain contract requiring N-of-M signers to approve.
• Account abstraction: smart-wallet features like session keys, sponsored gas and policy plugins.
• Allow-list: approved destinations (addresses/venues).
• Maker/checker: two-person control for payments.
• Peg deviation: stablecoin price drifts from its peg.
• Canonical bridge: the network’s official bridge path.
• Allowance/approval: permission a token holder gives a contract to move tokens on their behalf.
• Gas float: reserved native tokens to pay network fees.
• Halt rule: policy condition that pauses certain flows.

16) One-page policy template (fill-in)

Purpose
We safeguard organisational digital assets with segregation of duties, technical controls, and audit-ready records.

Scope
All wallets, chains, stablecoins, and payment flows managed by <Company>.

Architecture

• Treasury: <MPC/Multi-sig>, cold, allow-list limited to Ops and regulated off-ramps.
• Operations: smart wallets on <L2>, maker/checker, per-tx ≤ <X>, daily ≤ <Y>.
• Claim: hot, tiny balances only.

Controls

• Allow-lists; purpose codes; per-tx/daily limits; rate limits.
• Monthly allowance revokes; quarterly key rotation drills.
• Halt rules: pause new flows if peg deviation > <0.5% for 30m>, bridge status = paused, or sequencer outage > <N> minutes.

Bridging & Stablecoins

• Canonical bridges for size; test $10 first; avoid weekends for large moves.
• Use native stablecoins on operating L2s.

Approvals

• Maker/checker for all Ops; ≥ <A-of-B> for Treasury.
• First-time vendors require additional sign-off.

Monitoring & Records

• Dashboards for balances, approvals, peg/bridge status, gas floats.
• Daily receipts with tx IDs to ledger; exceptions queue.

Incidents

• Follow runbooks for phishing, key compromise, peg deviation, bridge pause.
• Status updates issued within <2h>; post-mortems published internally.

Review

• Monthly control attestation; quarterly tabletop; annual policy refresh.

If you want custody that your finance team trusts, with clean approvals, receipts, dashboards and incident muscle memory, Digital One Agency will design and ship the architecture, the policy engine, the apps, and the rails.

👉 Book a meeting: https://digitaloneagency.com.au/book-a-meeting/
📞 Call us globally 24/7: +61 2 9057 9079
📧 Email: contact@digitaloneagency.com.au