DFNS — Bringing Curated DeFi Yield Into Institutional Wallet Infrastructure

Introduction

DFNS is a Paris-based wallet-as-a-service platform for financial institutions. Founded in 2020 and led by CEO Clarisse Hagège, DFNS provides MPC wallets, a policy engine for approval quorums and role-based access, transaction orchestration, and audit trails across 40+ blockchains, all behind a single API. The company holds a SOC 2 Type II report audited by KPMG and serves Fidelity, Bridge (Stripe), Zodia Custody, and 130+ fintechs worldwide, including Deblock. DFNS raised a $16 million Series A in January 2025 led by Further Ventures, following a $13 million seed round in 2022.

In April 2026, DFNS partnered with Yield.xyz to make yield a native capability of its platform. By July 2026 the integration was live inside the DFNS Allocations API, the endpoint institutions use to deposit into a yield source, track the position and its rewards, and withdraw, under the same custody, policy, and governance controls as everything else on the platform. Allocations launched with M0 as its first provider. Yield.xyz is the second, adding curated onchain vaults, with every transaction verified by Yield.xyz's open-source Shield library before it is signed.

Challenges

• Institutions on DFNS held large idle stablecoin balances, but earning on them meant stepping outside governed infrastructure into DeFi interfaces, wrappers, and manual position tracking.
• Each yield strategy and chain needs its own integration, transaction logic, and reward handling. Building that in-house would have taken weeks per protocol.
• DFNS would not introduce a new custody model. Transactions could be constructed externally, but signing had to stay inside the institution's DFNS environment, behind the Policy Engine.
• DFNS required a verification layer running in its own environment to decode and validate every externally built payload before signing, with no blind trust in an upstream API.
• Institutions needed to see and exit positions even if the upstream provider were unavailable.

Yield.xyz Solution

• Yield.xyz as a provider inside the Allocations API: DFNS customers never call Yield.xyz directly. They create, track, increase, and decrease allocations through the same DFNS endpoints they use for M0, and each Yield.xyz vault appears as a protocol option. Behind it, Yield.xyz supplies vault curation, transaction construction, and yield data.
• Curated ERC-4626 vaults at launch: six vaults from four curators on Ethereum and Base, covering USDS, USDC, USDT, and PYUSD: Sky Savings Rate (sUSDS), Gauntlet USDC Prime, Steakhouse USDT, and Sentora PYUSD Main on Ethereum, plus Gauntlet USDC Prime and Steakhouse USDC on Base.
• Direct custody, no intermediaries: Yield.xyz builds the approve, deposit, and redeem transactions.
• Shield transaction verification: DFNS runs Shield, Yield.xyz's open-source verification library, from the published npm package inside its own signing pipeline. Every unsigned transaction returned by Yield.xyz is decoded and checked there before it reaches signing. Shield confirms the target is a whitelisted vault from a registry, that the calldata decodes to the expected operation with the receiver and owner pinned to the user's own address, and that the payload has not been altered since construction. A rejected transaction is never signed or broadcast.
• Amount validation built with DFNS: Working from DFNS's integration feedback, Yield.xyz extended Shield so DFNS can declare the user's intended amount and have Shield verify it against the calldata, on deposits (approve and deposit) and on exits (withdraw and redeem). Yield.xyz also moved partial exits to the ERC-4626 withdraw(assets) path so the amount an institution requests is exactly what lands in its wallet and can be verified offline.
• Resilience by design: DFNS reads balances and rewards directly from the vault contracts, with per-action checkpoints of share balance and share price for accurate rewards. Existing positions stay visible and withdrawable even if the Yield.xyz API is down. Only new transaction construction and displayed APY depend on it.
• Hardened delivery: Shield ships to npm with provenance attestation, so DFNS can verify the package it runs matches the audited source.

Results & Impact

• Institutions on DFNS can put idle treasury to work in audited, curator-managed vaults from the same wallet, policies, and audit trail they use for custody and payments.
• Every yield transaction passes two independent checks before signing: the DFNS Policy Engine and Shield. Even a compromised transaction-construction API could not route funds to an unexpected contract or inflate an amount.
• DFNS avoided building protocol-specific connectors, reward accounting, and transaction construction for each vault, and can add new vaults, assets, and networks through the same integration.
• The integration set a template for how institutional platforms can consume externally constructed DeFi transactions without delegating custody or trust.