Bitcoin

This is the first post in a new series at Dfns. Over the coming months, we'll publish one in-depth article for every network we support, what the chain is, what it's used for at institutional scale, what we've built for it, and where we're taking it next. We're starting with Bitcoin because Bitcoin is where this all started.

There is a reason every conversation about digital asset infrastructure eventually returns to Bitcoin. It is the genesis blockchain. The first working implementation of a decentralized monetary network, the asset that defined the category, and the only digital asset that has now been continuously secured for more than fifteen years without a single second of unscheduled downtime. Every other blockchain in the world inherits from Bitcoin's design assumptions, even when it diverges from them.

For institutions, Bitcoin has crossed a threshold over the past two years that is hard to overstate. Spot Bitcoin ETFs, approved in January 2024, brought hundreds of billions of dollars of regulated exposure to the asset within the first eighteen months of trading. Sovereign wealth funds and central banks are publicly studying or accumulating BTC. Public companies like Strategy (formerly MicroStrategy), Tesla, Block, Marathon Digital, Metaplanet, Semler Scientific and others, have made Bitcoin a permanent line item on their balance sheets. Banks that quietly told their clients in 2021 that crypto was off the menu are now racing to launch custody and trading products before their competitors do.

What has not changed is what makes Bitcoin difficult to operate at scale. The asset's security model is famously unforgiving: lose the key, lose the coins. Have the key stolen, lose the coins. There is no chargeback, no court order, no admin override, no support ticket. That is by design and it is what makes Bitcoin valuable. But it also means that the way you secure the key, govern access to it, and audit every signing operation is the entire game.

This is the problem Dfns was built to solve. This post walks through every Bitcoin capability we support today, the security architecture underneath it, the institutional use cases we see Bitcoin being deployed for in production, and where we’re taking the platform next, including Lightning and Taproot Assets.

Why we are starting with Bitcoin

Dfns supports more than 60 blockchains. We could have started this series with Ethereum, the chain on which most of our customers' stablecoin and DeFi flows live. We could have started with Solana, where high-throughput payments and consumer applications are increasingly being built. We could have gone with Canton which is currently the new rising star within institutional digital asset finance. We chose Bitcoin first because Bitcoin occupies a category of one, and because everything we have learned about institutional digital asset infrastructure since founding Dfns in 2020 traces back to Bitcoin's design.

Bitcoin imposes a discipline on infrastructure providers that other chains do not. There are no smart contract abstractions to hide behind. No upgradeable proxies to patch a mistake. No shared sequencer to bail out a stuck transaction. The UTXO model means every transaction is a deliberate composition of inputs and outputs, every fee decision is exposed, every script path is auditable onchain. If your wallet infrastructure cannot handle Bitcoin properly, it will not handle anything else properly either.

This is also why Bitcoin is the natural starting point for any institution thinking about digital asset operations. It is the asset most customers, treasurers, and regulators understand. It is the asset with the deepest liquidity, the most established custody norms, and the cleanest legal precedent. If a bank or a corporate is going to launch a single digital asset product this year, it will almost certainly be a Bitcoin product. The infrastructure that supports that product becomes the foundation for every digital asset capability the institution adds afterwards.

Bitcoin infrastructure for the institutional era

Dfns provides more than wallets. It is the institutional core banking platform to digital assets, enabling banks, custodians, fintechs, and corporations to securely access, manage, and transact Bitcoin from within their own environments.

Our Wallets-as-a-Service (WaaS) platform delivers bank-grade security, compliance tooling, and full programmability so enterprises can build and scale Bitcoin products without ever compromising on sovereignty and security. Founded in 2020, Dfns is trusted by over 400 financial institutions and fintechs, including Standard Chartered Bank, First Abu Dhabi Bank, IBM, Broadridge, Apex Group, Stripe, Kraken, Circle, and Susquehanna. We’ve secured over €100B across 20M wallets created and suffered zero security breaches since inception. Today, we secure over $10 billion in monthly transactions, operating under SOC 2 Type II (KPMG), ISO 27001, ISO 27017, and ISO 27018 (KPMG) certifications (ISO 22301 and SOC 1 are ongoing), with continuous third-party penetration testing and an in-house cryptography research team that contributes original protocols to the broader industry.

A meaningful share of those flows is Bitcoin. The patterns we see are consistent across customer types: BTC entering custody from an exchange or OTC desk, sitting in segregated wallets with multi-approver policies, being moved selectively to satisfy customer redemptions or rebalance treasury, and being audited continuously against onchain reality. Every one of those steps has to work, every time, for institutions to put real volume on the rails. That is the bar we build to.

How Dfns unlocked Bitcoin for traditional finance

In October 2025, IBM announced their new global digital assets platform, IBM Digital Asset Haven, built on Dfns' wallet infrastructure. It is one of the most significant milestones in institutional Bitcoin adoption to date. Through this partnership, Dfns' technology is now embedded inside IBM's network of financial institutions, brokerages, payment providers, governments, and corporates, enabling them to securely build and scale blockchain-based services, from Bitcoin custody and treasury to payments and settlement.

The collaboration brings Dfns' API-first programmability and architectural composability directly into the heart of traditional finance. For the first time, global enterprises can deploy secure Bitcoin infrastructure inside their own environments, under IBM's enterprise-grade standards, powered entirely by Dfns. For a Tier-1 bank evaluating how to bring BTC onto its balance sheet or its product menu, the path now runs through infrastructure that has already been vetted by one of the most conservative technology partners in financial services.

Respecting Bitcoin's core principles

Many Bitcoiners value the principle of self-custody, the idea that control over your keys means control over your money. Dfns is built to honor that same foundation at the institutional level.

Our infrastructure uses either FIPS 140-3 Hardware Security Modules (HSM) or Multi-Party Computation (MPC) to generate private keys into encrypted key shares distributed across independent signer nodes. These key shares (or “partial keys”) can never be combined and never be exposed if well-implemented, not even to Dfns. There is no seed phrase to write down, no hardware device to misplace, no operator who can be coerced into revealing a key, because the key as a single object simply does not exist. To produce a valid Bitcoin signature, the signers run a cryptographic protocol that yields a signature mathematically indistinguishable from one produced by a single private key, but without ever assembling that key in memory, on disk, or anywhere else.

This model preserves the spirit of self-custody while removing the operational and human risks institutions face: lost devices, rogue employees, compromised laptops, sophisticated phishing campaigns, insider threats, and the long list of single points of failure that have repeatedly caused losses across the industry. With Network-Hosted Keys, clients retain full signing authority and control while Dfns ensures those keys remain secure, available, and redundant at all times. Every signing operation is logged and cryptographically auditable, giving complete transparency into how, when, and by whom actions are performed without ever exposing sensitive key material.

This is the right answer for institutions that take Bitcoin's threat model seriously. Cold storage with paper backups is a personal-finance answer (though we do not recommend it, even for individual investors). However, it does not survive contact with quarterly audits, segregation of duties, regulatory examinations, disaster recovery requirements, and the operational reality of running a business that has to move funds in seconds, not in days.

Why institutions choose Dfns for Bitcoin

Dfns bridges Bitcoin's ethos of decentralization with the compliance and control institutions require. Six capabilities stick out inside our offering:

1. API-first architecture. Fully programmable and integration-ready. Dfns embeds directly into existing banking, trading, or treasury systems through a clean REST API and first-class SDKs in TypeScript, Python, Go, Java, Swift, Kotlin, and Flutter. There is no rigid dashboard you have to use; the dashboard exists, but it is a thin client over the same API your engineers integrate with. Every action a human can take in the dashboard is also available programmatically, which means anything you build on top of Dfns can be scripted, automated, and version-controlled.
2. Governance and compliance are built directly into the platform, with programmable approval policies, dynamic multi-approver quorums that adapt to transaction context (amount, destination, time, or wallet), address whitelisting, velocity limits, and time locks enforced at the infrastructure layer rather than the application layer, ensuring controls cannot be bypassed even in the event of compromised credentials or API keys. Transactions are screened before signing through native integrations with Chainalysis, Elliptic, Global Ledger, and Notabene, shifting compliance from reactive monitoring to proactive enforcement and preventing non-compliant transfers from ever reaching the chain. The system supports multiple approval channels, including dashboard workflows, mobile push, and programmatic service accounts for automation, alongside built-in emergency controls such as wallet freezing, time-locked overrides, and seamless credential rotation. Continuous inbound monitoring, Travel Rule enforcement, and structured address management further strengthen operational integrity, while every action is cryptographically signed, fully auditable, and exportable into existing GRC and SIEM systems. This architecture enables institutions to meet stringent regulatory requirements across jurisdictions, including MiCA and DORA in Europe, OCC and NYDFS in the United States, FCA in the United Kingdom, FINMA in Switzerland, MAS in Singapore, VARA in the UAE, HKMA in Hong Kong, and JFSA in Japan.
3. MPC security model. Private keys are never assembled. Network-Hosted Keys ensure resilience and continuous access without compromising sovereignty. An attacker would need to breach multiple secure, independent systems simultaneously and within a narrow time window, then compromise the operator's authentication, then bypass the policy engine, all without triggering any of the alerting layered through the stack. This is the architecture that lets us underwrite billions of dollars in monthly Bitcoin flows without ever having had a key compromise event.
4. Performance at scale. Bitcoin signing at Dfns is sub-second across both signature schemes the chain uses, ECDSA for Legacy and SegWit, Schnorr for Taproot, at institutional throughput. That is the output of an in-house cryptography research team that continuously optimizes our threshold signing stack against the strongest published benchmarks in each scheme: CGGMP-class protocols for threshold ECDSA, FROST-class protocols for threshold Schnorr. On the ECDSA side, KU23 is our proprietary scheme published in the Communications in Cryptology venue and currently the fastest in its class on the workloads our customers run (dfns.co/article/ku23). On the Schnorr side, Givre is our Rust implementation of FROST with native BIP340 support for Bitcoin Taproot; we open-sourced it to the Lockness project at the Linux Foundation (LF Decentralized Trust) as the fastest FROST implementation publicly available, and our team is actively contributing to FROST standardization at NIST (dfns.co/article/a-frost-library-called-givre). For a payment processor settling thousands of Bitcoin transactions per hour, or an exchange processing customer withdrawals at peak load, signing latency is not a footnote. It is the difference between a product that works and a product that doesn't.
5. HD wallet support (BIP-32 / BIP-44). Deterministic key derivation gives you consistent, recoverable wallet structures across environments, essential for scaling enterprise Bitcoin infrastructure. Institutions can manage Bitcoin accounts and sub-wallets programmatically across business lines, treasury divisions, or subsidiaries while maintaining unified governance.
6. Flexible deployment. Run Dfns as SaaS, hybrid, or on-prem, or connect your own HSMs (Thales Luna, Securosys Primus, IBM CryptoExpress or LinuxONE) for complete operational control. The same MPC layer works across all four models, which means a customer can start in our managed cloud and migrate to a fully on-prem deployment as their risk and regulatory requirements evolve, without changing a line of integration code.

Comprehensive Bitcoin support, end-to-end

For a complete walkthrough, see the Bitcoin network guide, the Sign Bitcoin transaction reference, and the Broadcast Bitcoin transaction reference. The summary below.

Wallets and address types

Dfns supports native Bitcoin wallets with multiple address types out of the box:

• Pay-to-Taproot (P2TR) — bc1p... addresses, signed with Schnorr signatures over secp256k1. The most efficient and privacy-preserving address type, with first-class support for advanced scripting and complex spending conditions including key-path and script-path spends.
• Pay-to-Witness-Public-Key-Hash (P2WPKH / native SegWit) — bc1q... addresses, signed with ECDSA over secp256k1. The dominant institutional address type today.

The same MPC key infrastructure secures both. You don't have to commit to one address type at wallet creation. Pick the address type per use case and Dfns handles the right signature scheme automatically when you sign. This matters more than it sounds: it means an institution that starts on SegWit today can migrate to Taproot tomorrow without re-keying its wallet base, simply by deriving Taproot addresses from the same underlying MPC key.

Multiple addresses per wallet

Dfns Bitcoin wallets use a separate-key-per-address MPC model rather than HD derivation. Each address is backed by its own MPC key share set, which makes it ideal for per-customer deposit tracking in exchange and custody workloads. Every customer or invoice can have a fully isolated, independently auditable address with no reuse, no derivation-path bookkeeping, and no risk that compromising one address exposes any other. For exchanges, payment processors, and any business issuing deposit addresses to end users at scale, this is the operationally correct primitive.

UTXO handling

Dfns automatically performs UTXO selection on outgoing Bitcoin transfers, including the smart inclusion of unconfirmed UTXOs when appropriate, an implicit Child-Pays-For-Parent (CPFP) strategy that keeps funds liquid during high-throughput operations rather than locking them up while you wait for confirmations. For an exchange processing back-to-back withdrawals, or a treasury moving multiple positions in a single session, this is the difference between a fluid operation and a queue of transactions all waiting on the same parent confirmation.

Native BTC transfers

The high-level Transfer Asset endpoint lets you send native BTC in a single API call. Pass kind: Native and an amount denominated in satoshis, and Dfns handles UTXO selection, change generation, signing, and broadcast. Bitcoin transfers on Dfns are native-only today, no token standards are layered on the base chain yet (see the roadmap below).

Fee estimation and fee bumping

Real-time fee estimation is exposed through the Estimate Fees endpoint with three priority levels: Slow, Standard, and Fast. Pick the strategy that matches the urgency of each transfer, or feed the values into your own dynamic fee logic. Treasuries that batch transfers overnight typically operate on Slow; exchanges responding to customer withdrawals operate on Fast; most operational flows sit on Standard.

When the mempool gets crowded and a transaction is at risk of stalling, Dfns supports both standard fee-bumping mechanisms:

• Replace-By-Fee (RBF): enabled by default on every transfer. Use the Speed Up Transfer endpoint to broadcast a replacement transaction at a higher fee rate.
• Child-Pays-For-Parent (CPFP): implicit, via Dfns' inclusion of unconfirmed UTXOs in subsequent transactions, or explicit when you build a custom PSBT yourself.

PSBT, BIP-322, and full SDK integration

Bitcoin transaction signing at Dfns is built around the standards the ecosystem already runs on:

• PSBT (Partially Signed Bitcoin Transactions): the modern standard for collaborative Bitcoin transaction construction. Build PSBTs with bitcoinjs-lib (or any other PSBT-aware tool) for full control over inputs, outputs, fee rates, and witness scripts. Submit them to Dfns for signing, get the signed PSBT back, finalize, and broadcast — or hand both jobs to Dfns in a single Sign & Broadcast call.
• Custom PSBT signing including support for signing with a custom Merkle root, implemented at the signer level (coming soon to production), enabling advanced Taproot script-path workflows for institutions that build complex spending policies on-chain.
• BIP-322 message signing: sign generic messages using the same primitives as Bitcoin transactions, with Simple and Full formats. Ideal for proof-of-reserves attestations, exchange withdrawal verifications, and authentication workflows.
• Multi-network parity: full compatibility with Bitcoin mainnet, Testnet3, Signet, and regtest for seamless development, QA, and production parity. Whatever you build in test, you ship to mainnet without code changes.

Indexing, history, and webhooks

Bitcoin is a Tier-1 network at Dfns, which means we run the full indexing pipeline on every wallet:

• Wallet assets: confirmed balances in BTC and satoshis, available via API
• Wallet history: every confirmed inbound and outbound transaction, with metadata for reconciliation
• Webhooks: wallet.transfer.broadcasted, wallet.transfer.confirmed, wallet.transfer.failed, wallet.blockchain.event.detected, so your back office reacts to chain events in real time rather than polling the API
• Idempotency: every mutating endpoint accepts an externalId your system can supply, so you can safely retry without double-spend risk

This is the unglamorous half of Bitcoin infrastructure. Most failure modes in production are not signing failures, they are reconciliation failures, missed events, and double-broadcasts caused by a flaky retry. Dfns runs the indexing and the event pipeline so your team doesn't have to.

Engineering deep dive: the cryptography behind it

A wallet platform is only as good as the cryptography it sits on. Dfns runs an in-house research team that designs, implements, and continuously vets the protocols our customers rely on. A few of the things worth knowing about what is underneath:

1. KU23. Our proprietary threshold ECDSA signing protocol, published as tecdh in the “Communications in Cryptology” venue. It produces signatures that are byte-for-byte indistinguishable from a single-key ECDSA signature on the Bitcoin network, meaning a Bitcoin wallet on Dfns looks like any other Bitcoin wallet from onchain, while internally requiring the cooperation of multiple independent signers to produce any signature. KU23 is materially faster than its predecessors (FROST, CGGMP24) on the workloads our customers run, which is why we can sustain sub-second Bitcoin signing at institutional throughput.
2. Continuous protocol vetting. We have publicly disclosed and patched vulnerabilities in widely-deployed MPC protocols, including issues that affected the broader industry's CGGMP21 implementations. We treat MPC the way a serious cryptography practice is supposed to: assume protocols are wrong until proven right, run continuous adversarial review, and publish what we find.
3. No-key-assembly invariant. At no point in the lifecycle of a Dfns Bitcoin wallet (creation, signing, backup, recovery, export) is the full private key materialized in any single environment. Key creation is a distributed key generation (DKG) protocol. Signing is a distributed signing protocol. Even export, when authorized, uses a threshold protocol that requires the participation of the same independent signers. There is no point in time where compromising one server, one process, or one administrator gives an attacker access to the key.
4. Independent signer environments. Each MPC signer runs in a separate, hardened environment with its own credentials, its own attestation, and its own physical and network isolation. In our managed deployment these environments span Tier 3+ and Tier 4 data centers across multiple regions; in hybrid and on-prem deployments, customers control where each signer lives, which means a determined attacker faces the additional problem of compromising infrastructure they may not even know exists.
5. Performance. Dfns delivers up to 20 ECDSA signatures and hundreds of key generations per second, with substantially higher throughput on EdDSA. For a Bitcoin operation, this is more than enough headroom to support millions of customer wallets and the corresponding signing volume.

Security architecture beyond the cryptography

Cryptography is necessary but not sufficient. The platform around the cryptography matters just as much. Passkeys for authentication. User access to Dfns is gated by passkeys built on the FIDO2 / WebAuthn standard, the same phishing-resistant authentication standard backed by Apple, Google, Microsoft, and Yubico. There are no passwords to steal, no SMS codes to intercept, no shared secrets sitting on a server. Two-factor authentication is built in at the protocol level, combining the device you have with the biometric you are. The most common path to a custody breach is not breaking the cryptography, it is phishing an employee. Passkeys close that door.

Four deployment models. Dfns offers the full ladder:

• Fully managed: Dfns operates the MPC signing network in our SOC 2 Type II and ISO 27001 certified infrastructure, deployed across Tier 3+ and Tier 4 data centers in the region of your choice, with options including the Americas, Europe, Middle East, and Asia.
• Hybrid / co-controlled: you keep one or more MPC shares on your own infrastructure, including in confidential computing enclaves like AWS Nitro or IBM Hyper Protect, while Dfns operates the rest. No transaction signs without your share.
• On-premise: Dfns deploys its full signing stack inside your perimeter, with no external dependency on Dfns-operated infrastructure for signing.
• Bring Your Own HSM: for institutions that have already standardized on FIPS 140-2 / 140-3 certified hardware, Dfns connects natively to IBM, Thales, Securosys, and other compliant HSMs through PKCS#11-compatible interfaces. Cryptographic material remains inside the bank's own root of trust; Dfns provides the orchestration, policies, and workflow layer above it.

Audits and certifications. SOC 2 Type II, ISO 27001, and continuous third-party penetration testing by leading firms including Kudelski Security, Halborn, and Redacted. Both white-box and black-box engagements covering cryptography, code, and full-system reviews. Our most recent multi-week pentest concluded in November 2025.

Insurance. Crime, cyber-attacks, and errors & omissions coverage in partnership with Beazley and Munich Re. A security promise that does not pay out is not really a security promise.

Availability. 99.95% uptime as standard, with options for 99.995% for enterprise customers. Active-active, geographically distributed RPC infrastructure with automatic failover keeps the Bitcoin network reachable from your wallets even when individual nodes or regions go down. Continuous monitoring is published live at status.dfns.co.

Disaster recovery. Independent recovery paths at every layer of the stack. Customers in our hybrid and on-prem deployments can recover wallets even in scenarios where Dfns as a company ceases to operate. We treat that as a feature, not an awkward edge case.

Governance for Bitcoin operations

Securing the key is necessary; controlling who can do what with it is just as important. Dfns Wallet Entitlement Management (WEM) is a programmable rule engine that runs before any signature is produced. For a Bitcoin operation, this typically looks like:

• Approval quorums.
  High-value BTC transfers require sign-off from N of M operators across treasury, compliance, and operations. The quorum can vary by transfer size, by destination address tag, by time of day, by originating wallet — whatever your internal policy actually says.
• Address whitelisting.
  Outgoing Bitcoin transfers can only go to a curated list of addresses. New entries to the list are themselves subject to a quorum, which means an attacker who somehow compromises an operator account still cannot route funds to a new address without independent approval.
• Velocity limits.
  Caps on the amount of BTC moved per hour, day, or wallet, with separate ceilings for whitelisted versus non-whitelisted destinations. Velocity limits are the single most effective control against the worst-case scenario of an account compromise: even if an attacker gets past the front door, they cannot drain the wallet in one transaction.
• Time locks.
  Delays on large transfers, giving compliance and security a window to intervene before the transaction signs.
• KYT-gated transfers.
  Outgoing transfers are automatically screened against data sources from Chainalysis, Elliptic, or Global Ledger risk scores, blocking flows to sanctioned, high-risk, or recently-flagged counterparties before they are ever signed.
• Travel Rule.
  Through our Notabene integration, for VASP-to-VASP transfers above the regulatory threshold in your jurisdiction, originator and beneficiary information is exchanged automatically as part of the transfer flow.
• Granular roles and permissions. Your existing internal segregation of duties translated directly into Dfns roles. A trader cannot do what only treasury should do; a customer-service operator cannot do what only compliance should do; and so on.

This moves Bitcoin governance from manual checklists into code. The audit trail is generated automatically, every action is signed by the user or service account that performed it, and policies cannot be bypassed because they live below the API surface, in the same MPC layer that produces signatures. From a regulator's standpoint, this is the difference between an institution that says it has controls and an institution that can prove it has controls.

Bitcoin use cases at institutional scale

Bitcoin is not one product. It is the underlying asset for an increasingly broad range of regulated financial offerings. The most important pattern of the last two years is that the same wallet infrastructure can power most of them, which means the institution that builds Bitcoin custody well does not have to rebuild it for the next product. Below is a tour of the use cases we see Dfns customers running on Bitcoin in production.

1. Buy / sell / hold for retail banking customers

The first onchain product banks should launch is the simplest one: let your customers buy, sell, and hold Bitcoin through the bank, the same way they buy, sell, and hold equities, foreign currency, or commodity exposure today.

Approximately 30% of American adults (roughly 70.4 million people) already own cryptocurrency. The number is similar in much of Europe and Asia. A meaningful portion of those holders are bank customers who currently keep their crypto on a separate platform: Coinbase, Robinhood, Revolut, Binance. Every one of those customers is, in effect, using a non-bank platform as a parallel financial account. Once those balances grow large enough, the platform that holds them becomes the center of the customer's financial life — the place they default to when they think about money.

Banks that recognize this dynamic are launching buy/sell/hold products, starting with Bitcoin. The product is straightforward: customers see BTC alongside their EUR, USD, or GBP balance in the same banking app; they can buy with a tap, sell with a tap, and the balance is custodied by the bank under regulated terms. Behind the scenes, the bank operates a Dfns service account, provisions a wallet per customer (or pools custody and tracks balances internally, both architectures are supported), routes orders to liquidity venues, and enforces policy on every flow.

For a more strategic treatment of why this is the natural starting point for banks, see Buy / Sell / Hold. The infrastructure layer underneath that product is exactly what is described in this post.

2. Corporate treasury and Bitcoin-on-balance-sheet

Strategy (formerly MicroStrategy) is the most visible example, but the trend is broader: Tesla, Block, Marathon Digital, Metaplanet, Semler Scientific, and a long tail of public and private companies have added Bitcoin to their corporate treasury. Some hold BTC as an inflation hedge, some as a strategic reserve asset, some as the core thesis of the business itself.

For a corporate treasurer, the operational requirements are clear: the BTC has to be held with bank-grade security, every movement has to be approved by a documented quorum of authorized signers, every transaction has to be auditable for the auditors and the board, and the reserves have to be verifiable to investors at any time. None of that is achievable with consumer custody products or hardware wallets in a safe.

Dfns is purpose-built for this profile. A corporate treasury on Dfns typically runs:

• A custodial Bitcoin wallet (or a small number of segregated wallets) under MPC, with the option of a hybrid deployment where the corporate keeps one share of the key on its own infrastructure
• A policy requiring N-of-M sign-off from CFO, treasurer, and a designated risk officer for any movement of funds, with separate higher quorums for movements above predefined thresholds
• An address whitelist of approved counterparties (the corporate's chosen exchange or OTC desks)
• Continuous KYT screening on inbound flows
• BIP-322 proof-of-reserves attestations published to investors on a defined cadence
• Webhook-driven reconciliation between Dfns and the corporate's general ledger

The result is a Bitcoin treasury operation that is operationally indistinguishable from how the same corporate manages its FX reserves or its short-term bond portfolio.

3. Bitcoin ETF and ETP custody

Spot Bitcoin ETFs are now one of the largest categories of regulated Bitcoin holding in the world. BlackRock's IBIT, Fidelity's FBTC, ARK's ARKB, Bitwise's BITB, Grayscale's GBTC, and a growing number of European and Asian equivalents collectively custody hundreds of thousands of BTC on behalf of institutional and retail investors.

The custody requirements for a regulated ETF are non-negotiable. Keys must be held in qualified custody. Movements must be controlled by a robust set of approvers. Audits must be continuous. Insurance must be in place. Operational disruption to redemption flows is unacceptable. And the cost structure of running custody at this scale is closely scrutinized by issuers, who are competing on management fees down to single basis points.

Dfns serves this segment with the exact stack described above: MPC custody, configurable deployment models including BYO-HSM for issuers that want their cryptographic root of trust to remain inside their existing FIPS-certified hardware, multi-jurisdiction availability, and the operational SLA needed to support same-day creation and redemption flows. ETF-grade requirements are not a bolt-on; they are how the platform is built.

4. Centralized exchange operations

Exchanges and OTC desks have the most demanding Bitcoin operational profile of any institution: tens of thousands of customer deposit addresses, tens of thousands of withdrawals per day, tight latency requirements on signing, and the need to manage hot, warm, and cold tiers across multiple jurisdictions without ever exposing customer keys.

Dfns supports this end-to-end. Per-customer deposit addresses are issued programmatically, each backed by its own MPC key, fully isolated from every other customer's funds. Hot wallet withdrawal flows run through high-throughput signing with KU23, gated by velocity limits and KYT screening. Warm and cold tiers run on the same MPC architecture with progressively stricter policies and longer time locks. Inter-tier sweeps are policy-driven, automated, and fully audited.

For exchanges that have built their stack on legacy tech or in-house infrastructure and are looking to migrate, Dfns provides full key import and export through threshold protocols, plus a documented migration path. Example: a detailed guide on migrating from Fireblocks to Dfns.

5. Bitcoin-backed lending and collateralization

Bitcoin has become the dominant non-fiat collateral asset in institutional credit markets. Prime brokers, lenders, and credit funds increasingly accept BTC as collateral against fiat or stablecoin loans, with margin call and liquidation logic running against on-chain balances.

The custody requirements for collateral are subtle but critical. The lender needs cryptographic assurance that the borrower cannot move the collateral while the loan is outstanding. The borrower needs cryptographic assurance that the lender cannot move the collateral except under the documented liquidation conditions. Both sides need an independent, auditable record of what is held, where it is held, and when it can move.

Dfns supports this through programmatic multi-party arrangements where the lender, borrower, and (optionally) a third-party agent each hold a passkey with policies that translate the loan agreement directly into transaction rules. Margin calls and liquidations execute through pre-defined policy paths rather than through human intervention, which dramatically reduces operational risk on both sides of the trade.

6. Bitcoin payment processing and merchant settlement

Companies like Strike, Lightning Labs, and a growing number of payment processors settle merchant transactions in Bitcoin or use Bitcoin (and Lightning) as a settlement layer for cross-border value transfer. The infrastructure requirements are different from custody-heavy use cases: the priority is throughput, low signing latency, automatic reconciliation, and tight integration with KYT and Travel Rule controls.

Dfns is well-suited to this profile because of its API-first model, signing speed, the per-address key model that fits naturally into per-merchant or per-invoice flows, and the deep AML/KYT integrations that let payment processors meet their compliance obligations without slowing the customer experience.

7. Wealth management and family offices

Private banks, RIAs, and family offices managing high-net-worth Bitcoin allocations need the same basic primitives as treasuries (MPC key security, multi-approver governance, audit, insurance, etc.) but with the additional requirement of supporting client reporting, segregated client wallets, and often delegated wallet flows where the client's own passkey is required to sign.

Dfns supports both fully custodial and delegated (non-custodial) wallet models on the same platform, which means a wealth manager can offer the appropriate model per client without operating two parallel infrastructure stacks. A client who wants the bank to manage everything gets that. A client who wants self-sovereignty over their keys gets that, with the bank providing the operational and compliance wrapper.

8. Sovereign and quasi-sovereign holdings

A growing list of nation-states, sovereign wealth funds, and central banks are studying or actively holding Bitcoin. The custody bar for sovereign holdings is unique: full on-prem deployment, BYO-HSM, jurisdiction-specific data residency, multi-party governance involving named officials, and disaster recovery scenarios that include geopolitical disruption.

Dfns is one of a small number of providers that can credibly serve this profile, because every layer of our architecture, from MPC topology to deployment model to HSM integration, is designed to be configurable to extreme requirements. We treat sovereign and quasi-sovereign engagements case by case, but the infrastructure they need is the same infrastructure described in this post, configured for their specific risk and regulatory environment.

Roadmap: where Bitcoin support is heading next

Bitcoin is no longer just BTC moving between addresses. A new layer of programmable Bitcoin is emerging, and Dfns is building to meet it.

Bitcoin Lightning Network

Lightning brings instant, low-cost Bitcoin payments at internet scale, and it is increasingly the rail of choice for high-frequency Bitcoin payments, payouts, and remittances. Strike, Cash App, and a growing number of fintech and payment players already use Lightning at meaningful volume.

Dfns is working on native Lightning support so institutions can open and manage channels, route payments, and reconcile Lightning flows alongside on-chain BTC, all under the same MPC security and policy controls that protect the rest of their wallet portfolio. Expect channel management APIs, hold-invoice support, BOLT-12 offers, and full integration with Dfns' webhook and audit pipeline. The same policies that gate on-chain transfers will gate Lightning operations, so an institution does not have to maintain two separate governance frameworks.

Taproot Assets

Taproot Assets (formerly Taro), built by Lightning Labs, brings issuance of stablecoins and other tokenized assets directly onto Bitcoin and Lightning. The protocol is positioned to bring stablecoin issuance, including USD and EUR stablecoins, to Bitcoin's settlement layer in a way that is interoperable with Lightning's payment routing.

Dfns is investing in Taproot Assets support to give institutions a regulated path to issue, custody, and transfer assets natively on Bitcoin, including stablecoins on Lightning, with our full policy engine and AML/KYT screening applied to every operation.

If any of these are on your near-term roadmap, talk to us. 

What's next in this series

Bitcoin is the origin chain, and it deserved the first slot in this series. The next post will cover Ethereum, the other foundational chain, the home of stablecoin volume, the dominant settlement layer for tokenized assets, and the platform on which the next generation of programmable finance is being built. We'll work through what we support across Ethereum and its L2s (Arbitrum, Base, Optimism, Polygon, Ink, BOB, Plasma, and more), the EVM-specific features like account abstraction and gas sponsorship, the smart-contract integration patterns, and the use cases we see customers running in production.

After Ethereum, expect dedicated posts on Solana, the major stablecoin chains, the Cosmos ecosystem, Canton for tokenized real-world assets, the Bitcoin-adjacent UTXO chains (Litecoin, Bitcoin Cash, Dogecoin), and the long tail of specialty networks. 

Subscribe to the Dfns newsletter if you want each post in your inbox as it goes live.