Institutional Crypto Custody & Trading Workflows
Designing a secure custody and trading experience that lets institutional clients move, protect, approve, and monitor digital assets with confidence, without hiding the security that makes it safe.
↑ Institutional trust, rendered as a UI: every approval visible, every signer accounted for.
The institutional gap in a retail-built product
As digital assets matured, our platform saw a wave of institutional clients, hedge funds, family offices, corporate treasuries, arrive to manage serious money. They were handed a retail-focused wallet interface built for a single user managing their own funds.
Institutional clients need to move millions in digital assets while reducing operational and counterparty risk. Retail wallets assume one person, one decision. Institutions require governance, and on a blockchain, a mistaken transfer is irreversible, making a "fat-finger" error a catastrophic, not merely embarrassing, risk.
What I owned on this project
I was the Lead Product Designer responsible for translating institutional governance requirements into an interface that felt secure without feeling hostile.
Governance Research
Mapped institutional roles and approval chains directly with traders, operations managers, and treasury leads.
Workflow Design
Designed the Maker/Checker approval engine, from initiation through policy check to dual sign-off.
Trust & Risk UX
Built the address-intelligence layer that translates raw blockchain data into human-readable risk context.
Security Collaboration
Partnered with cryptography specialists to explain MPC key sharding without overwhelming non-technical approvers.
Three governance gaps a retail wallet can't close
No segregation of duties
The same person who initiated a trade could also execute it, there was no maker/checker flow at all, a basic governance control institutional clients simply assumed would exist.
Approval obscurity
Treasurers couldn't easily verify what they were actually approving before signing a multi-sig request , they were being asked to trust a black box with real money inside it.
Address anxiety
Copy-pasting long hexadecimal strings created constant low-grade anxiety, driving frequent small "test" transactions that added friction without actually reducing risk.
How might we give institutional teams the governance controls a treasury requires, while making every approval legible enough that a signer never has to sign on blind trust?
If we make maker/checker roles explicit, translate blockchain data into human-readable risk context, and give every approver a visible signature timeline, then institutional clients will approve transfers faster and with fewer errors, while gaining full audit readiness by default.
Mapping the governance structure, role by role
Before designing a single screen, I mapped exactly who does what inside an institutional client's treasury operation, because the UI had to mirror a governance structure that already existed on paper, not invent a new one.
Trader
Initiates trades and proposes transfers. Cannot execute without approval.
Operations Manager
Reviews daily limits, manages whitelists, acts as Level 1 approver.
Treasury Lead
Level 2 approver. Holds signing keys via hardware wallet.
Compliance Officer
Read-only. Exports audit logs, monitors AML flags.
Admin
Sets policy rules, e.g. "transfers over $1M need 3/5 signers."
What role-mapping made clear
"Approve" and "sign" are two different acts of trust
Approving is a logic check ("does this match policy?"). Signing is a cryptographic commitment. Conflating them in one button was itself a governance risk.
Compliance needed visibility, not veto power
Compliance officers wanted to see everything and trust the export, not intervene mid-transaction. Read-only access was a feature, not a limitation, once we framed it that way.
Anxiety about addresses was really anxiety about irreversibility
The hex string itself wasn't really the problem. Not knowing whether it was trustworthy was. Naming the destination solved more anxiety than any amount of copy-paste tooling could.
The rules we designed by, and why
Security without confusion
Make risk controls visible but intuitive, security should never become friction for its own sake.
Human-readable blockchain
Translate tx-hashes, gas fees, and hex addresses into plain-English context, always.
Approval clarity
Checkers must see exactly what they're signing, with anomalies clearly highlighted, not buried.
Auditability by default
Every action leaves a clear, exportable trail, compliance shouldn't have to ask for it.
Mapping the Maker/Checker workflow, step by step
Every transfer above policy threshold moves through the same four-stage governance chain, designed so each stage has one clear owner and one clear question to answer.
01 Maker Initiate
A trader drafts a transfer: for example, 100 BTC to a Binance hot wallet. At this stage the system captures intent only; nothing moves and no signature exists yet.
02 Risk Engine Policy Check
The system automatically flags the transfer against policy, over $1M triggers a 2-of-3 signature requirement. This step removes any ambiguity about how many approvals a given transfer needs before a human ever looks at it.
03 Checker 1 Approve (L1)
The Operations Manager verifies the destination address against the whitelist and reviews the logic of the request. This is a policy-and-context check, not yet a cryptographic commitment.
04 Checker 2 Sign (L2)
The Treasury Lead signs the payload using a hardware wallet (Ledger/Trezor). This is the only stage that produces an irreversible cryptographic commitment, deliberately kept separate from every earlier "approve" action.
The choices that shaped the outcome
Decision 01 · Separate "approve" and "sign" vs. one combined action
Tension: One combined button is faster to use, but blurs a policy check with an irreversible cryptographic commitment.
Choice & trade-off: We kept them strictly separate. The extra click was a deliberate cost, institutional clients told us directly they wanted friction at exactly this point, not less of it.
Decision 02 · Read-only compliance access vs. override rights
Tension: Some clients initially wanted compliance officers able to directly block a pending transaction.
Choice & trade-off: We kept compliance strictly read-only with full export rights, preserving a clean separation-of-duties model rather than adding a fourth actor into the live approval chain.
Decision 03 · Translated address labels vs. hex-only display
Tension: Security-minded stakeholders worried a friendly label might create false confidence versus raw, unambiguous hex.
Choice & trade-off: We showed the translated entity name as primary, with the raw address always one click away, trust without hiding the ground truth.
Institutional confidence at scale
Pending Approval: 100 BTC
To: Binance Hot Wallet (Whitelisted)
↑ The Multi-Step Approval Center, every pending signature visible, nothing hidden behind a single "Send" button.
Destination Security
bc1qxy2kgdygjrsqtzq2n0yrf2493p83kkfjhx0wlh
Risk Warning
Gas fees are currently unusually high (120 gwei). Consider delaying the transfer.
↑ Human-Readable Trust & Risk, the address-intelligence layer that turns a hex string into an entity you can recognize.
Design doesn't happen in isolation
Cryptography specialists: explaining MPC without overwhelming
I worked directly with the security team to design a "vault" metaphor for multi-party computation key sharding, so approvers could trust the mechanism without needing a cryptography degree to understand it.
Compliance: validating the read-only model
Compliance officers reviewed every export format before launch to confirm the audit trail actually satisfied the reporting formats their regulators expected, not just what was easy for engineering to build.
Institutional relationship managers: surfacing real client language
Relationship managers who spoke with treasury leads daily fed back exactly which phrases ("segregation of duties," "whitelist ageing") clients actually used, language that shaped the UI copy directly.
How we arrived at the solution
Tree Testing
Tested the proposed information architecture for the multi-signature approval flow directly with institutional crypto traders.
Security Protocol Co-Design
Worked directly with cryptography experts to design a UI that explains key sharding (MPC) without overwhelming the user.
Illustration Placeholder
Prompt: A stylized illustration of a security-protocol co-design workshop, cryptography experts and a designer reviewing key-sharding diagrams on a glass wall, in indigo and silver accent tones. Rendered as a clean illustration on a fully transparent background (no backdrop, scene, or color fill), so it displays cleanly on both light and dark page themes.
Institution-grade UX drove adoption
Honest reflections from the process
What Worked
Mirroring an existing governance structure instead of inventing one
Institutional clients already had a maker/checker model on paper. The fastest path to trust was making the UI match what they already practiced, not proposing something novel.
Treating "approve" and "sign" as separate acts of trust
Once we split the logic check from the cryptographic commitment, the whole flow became explainable in a single sentence to any new approver, a strong sign the model was right.
What I'd Do Differently
Bring compliance into the workflow design earlier
Compliance validated export formats late in the process. Involving them while the maker/checker flow was still being sketched would have caught reporting-format requirements sooner.
Test the workflow under adversarial conditions, not just happy-path approvals
Most validation sessions walked through a clean approval. I'd want dedicated sessions rehearsing disputed or rejected transfers, since that's exactly where governance UX gets tested hardest in production.