Introducing Solutions

Most API documentation starts and ends with primitives. Create a wallet. Sign a transaction. Configure a policy. Register a user. Those building blocks matter, and they are the foundation of the Dfns platform. But anyone building a real financial product knows that primitives are only the beginning. The hard part is not understanding one endpoint. The hard part is understanding how wallets, policies, service accounts, approvals, compliance checks, smart contracts, exchange connectivity, and user delegation fit together into a complete system. That is exactly why we created Solutions in the Dfns API docs. 

Solutions are not a new product surface and they are not marketing pages wrapped around APIs. They are implementation blueprints. Each one is designed to show how a higher-level financial workflow can be built on top of Dfns, with the actual components, operational steps, governance patterns, and security controls required to make it work in practice. Instead of answering “what does this API do,” Solutions answer a more useful question: “how do I build this end to end?” 

That distinction matters because the next generation of teams building onchain is not looking for isolated API calls. They are building payment systems, custody products, investment platforms, treasury operations, and regulated financial workflows. Documentation for that world has to do more than enumerate endpoints. It has to show architecture, roles, sequencing, and operational boundaries. The new Solutions section is our attempt to make the docs reflect how Dfns is actually used in production. 

From reference material to implementation blueprints

A good example is the stablecoin workflow. The Stablecoin Payments solution is not just a note saying that Dfns can sign smart contract calls. It walks through a concrete ERC-20 setup in which an issuer deploys a token contract, manages mint and burn rights, pauses transfers in emergencies, and restricts privileged actions through role-based access. It also shows the surrounding project structure, deployment flow, and operational tooling used to run those controls through Dfns-managed wallets. That turns the docs from abstract capability into a repeatable recipe. 

The same is true for capital markets workflows. The Bond Issuance solution goes beyond a generic tokenization description and maps out a tokenized corporate bond lifecycle from subscription to coupon payments to redemption at maturity. It shows how stablecoins can be used for investor subscription, how ERC-20 bond tokens are issued, and how the issuer manages withdrawal of proceeds, periodic coupon flows, and final redemption, all with transactions signed through Dfns wallets. That is not a feature checklist. It is a structured model for building an actual financial instrument onchain. 

The Payments & Money Movement section follows the same logic. The EVM cross-border payments solution models a payment flow where a source currency is burned, an FX rate is applied, and the destination currency is minted to the receiver, with distinct roles for the bank, sender, and FX provider. The Solana version covers the same business problem with a Solana-specific execution model and adds guidance around an interactive UI, CLI usage, and settlement to fiat with payouts. In both cases, the docs move from “Dfns supports transactions on this network” to “this is how to orchestrate a cross-border payment system.” 

Documentation organized the way financial systems are built

One of the reasons we introduced Solutions is that institutions do not think about infrastructure in terms of isolated product features. They think in terms of operating models. A bank custody product, for example, is not just wallet creation plus some user authentication. The Bank-Grade Custody solution shows a full-stack model where crypto wallets sit alongside fiat accounts, with separate customer and employee endpoints, approval logic, delegated family access, and authentication patterns that distinguish customer actions from employee review flows. It frames custody the way a product team or architecture team would frame it: as a complete operating system, not a collection of calls. 

The same principle applies to Managed Investment Accounts. That solution is centered around a discretionary investment platform in which each client account has approved destinations, visibility into the rules governing their account, and auditable reporting on activity. It also shows how a service account can handle order execution to an exchange while preserving per-client restrictions, destination approval flows, spending controls, and transparency. In other words, it documents how to implement delegated financial operations without collapsing governance into one back-office role. 

Even seemingly straightforward subjects like wallet organization become much more useful when documented at the workflow level. The Wallet Management solution focuses on permission roles, wallet tags, separation of duties, and organization patterns by function, risk level, or network. It even provides example permission sets such as treasury operator, treasury approver, and auditor. That is the difference between documentation that tells you what a wallet is and documentation that helps you run a treasury, exchange operation, or internal control environment. 

Making governance and automation concrete

Another purpose of Solutions is to document the layer above raw transaction execution: control systems. The Treasury Management category is a good example. Treasury Policies does not just explain that Dfns has a policy engine. It walks through multi-signature approvals, spending limits, recipient whitelisting, policy evaluation, and different policy templates such as conservative treasury, balanced operations, tiered wallet structures, and foundation-style controls. That makes the governance model legible for teams that need to implement internal controls before moving real value. 

Automated Approvals goes one step further by documenting how service accounts can act inside approval workflows. The solution explains when automation should be used, how a webhook listener fits into the loop, how exceptions are escalated to humans, and why automation should approve routine requests but never become the opaque source of rejection. It also emphasizes accountability by noting that every approval decision remains cryptographically signed, preserving non-repudiation whether the approver is a person or a machine. This is the kind of design guidance that matters when teams want more throughput without weakening governance. 

Automated Payments applies the same philosophy to payouts and high-volume operations. It covers service account configuration, policy-gated transfers, webhook notifications, transfer execution, policy evaluation flow, and operational concerns such as rate limits, reliability, and multiple hot wallets. Importantly, it recommends separating automation from approval authority by default, which is precisely the kind of implementation advice that prevents teams from turning operational convenience into governance risk. 

Covering the operational edges that usually get left out

The Solutions section also helps document the parts of financial systems that are often treated as afterthoughts but become critical in production.

Payment Processing is a good example. It covers deposit detection, outbound transfers, stablecoin support, compliance integration, AML and KYT screening, Travel Rule workflows, deposit sweeping, and fiat off-ramp patterns. In practice, most payment products fail not because they cannot sign a blockchain transaction, but because they cannot reliably stitch together the operational edges around deposits, compliance, and reconciliation. This is why documenting the full payment flow matters. 

End-User Wallets fills a similar gap on the user side. It covers delegated wallet architecture, end-user registration, wallet creation, passkey collection through WebAuthn, login flows, user actions, and account recovery. It even distinguishes between delegated registration and social registration, which is exactly the kind of product-level tradeoff teams need to understand early. This turns a technical capability like delegated signing into a usable blueprint for teams building user-facing wallet products. 

Exchange Connectivity and DeFi Trading extend that logic to execution venues. The exchange solution documents how Dfns wallets connect with centralized exchanges for deposits and withdrawals, including supported exchanges such as Kraken, Binance, and Coinbase Prime, along with whitelisting, address management, and large transfer approvals. The DeFi solution covers supported DEX-based workflows, swap execution, slippage management, velocity limits, AML screening, and operational best practices such as checking liquidity first, using dedicated DeFi wallets, and monitoring swap status. These are not edge features. They are recurring patterns in how teams actually move capital. 

Compliance is treated the same way. Rather than leaving it scattered across product pages, the Compliance Controls solution pulls together KYT and AML screening, audit trails, Travel Rule support, alerting, review workflows, webhook notifications, auditor access, and reporting. It specifically documents Chainalysis integration for screening and Notabene for Travel Rule flows, along with policy-driven options to block or require approval for risky transactions. That is important because regulated teams do not build compliance after the fact. They need it embedded into transaction lifecycles from day one. 

Why this changes the role of the docs

What Solutions really represent is a shift in what API documentation is supposed to do. For a long time, developer docs were treated as a reference library. Useful, but narrow. That model works when the main challenge is learning a surface area. It breaks down when the main challenge is assembling a secure, governed, multi-step financial workflow. In that environment, teams do not just need reference material. They need architecture patterns, operational defaults, and examples that reflect the way real institutions build. The new Solutions section is designed around that reality. 

That is also why we reorganized these pages around business workflows rather than a loose collection of examples. The new structure spans “Payments and Money Movement,” “Custody and Asset Servicing,” “Investment and Capital Markets,” “Treasury and Financial Operations,” and “Platform Capabilities.” This gives developers, architects, product teams, and compliance teams a more natural way to navigate the docs: not by API family, but by the financial system they are trying to build. 

What you can explore today

The first set of Solutions already covers stablecoin payments, cross-border payment flows on multiple chains, bond issuance, bank-grade custody, managed investment accounts, treasury management, wallet management, automated approvals, automated payments, payment processing, end-user wallets, exchange connectivity, DeFi trading and execution, compliance controls, and much more. 

This is the direction we want the documentation to keep moving in. No isolated explanation, no abstraction for its own sake. More complete system descriptions, more practical guidance for teams that need to ship.

• Explore the Solutions section here: docs.dfns.co/solutions ‍
• Get started today: app.dfns.io/get-started