Fee Sponsors 2.0

Earlier this year, we introduced Fee Sponsors for organization wallets. That meant one wallet could automatically cover network fees for others in the same org, making onboarding smoother and workflows easier while still keeping all policy checks and audit trails inside Dfns.

Now Fee Sponsors also work with user wallets. These are different: they live outside Dfns, and users sign transactions directly with their own passkeys. That makes sponsorship trickier and riskier. To support it safely, we’ve added new safeguards, including use flags and post-construction validation.

How org-controlled sponsorship works

• Both the transacting wallet and the sponsor wallet live inside Dfns.
• The sponsor wallet is marked with a FeeSponsors:Sponsor flag.
• When a transaction includes a feeSponsorId, the Policy Engine checks if the caller has both Wallets:Transfer and FeeSponsors:Sponsor rights.
• Both signatures (transaction + fee) are generated inside Dfns, logged, and broadcast together.

In short: a closed loop fully owned by the org, with permissions enforced end-to-end.

The challenge with user-controlled wallets

For user-controlled wallets, the signed transaction arrives from outside Dfns. That creates two risks:

• Fee abuse: users could spam low-value transactions to drain sponsor funds.
• Permission leakage: without limits, users could trick the sponsor wallet into paying for transactions the org never intended.

To close that gap, we extended the Fee Sponsor model. Organizations still need to mark a wallet with the sponsor flag, but now policies evaluate the exact transaction bytes submitted by the user before attaching a fee sponsor signature. End-users don’t inherit sponsor rights directly; instead, sponsorship can only happen if the organization’s integration explicitly includes a valid feeSponsorId. On top of that, new policy controls enforce velocity, gas limits, and org-defined quotas to prevent abuse. To summarize:

• Delegated sponsor flagging: orgs still mark sponsor wallets with FeeSponsors:Sponsor. These wallets can only pay fees when paired with user-wallet flows.
• Post-construction validation: policies inspect the exact signed payload before adding the sponsor signature.
• Scoped permissions: end-users never inherit sponsor rights. Sponsorship only happens if the org’s API call includes a valid feeSponsorId.
• Velocity and fee limits: new policies enforce per-wallet quotas on transaction counts, fees used, and rate.

What fee sponsors for user wallets unlock 

In practice, sponsorship for org-controlled wallets stays fully inside Dfns, while user-controlled wallets add an extra check. The user signs externally, the org decides whether to sponsor, and Dfns enforces all rules before the sponsor signature goes through. In both cases, permissions are explicit, policies are applied, and every step is logged cryptographically.

Extending Fee Sponsors to user-controlled wallets keeps the flow simple for end-users but under strict enterprise control. Users can never spend directly from sponsor wallets, organizations stay in charge of when and how sponsorship happens, and policies adapt to external signing without reducing security.

Fee Sponsors for user-controlled wallets are already available on Solana, Ethereum/EVM, and Stellar, with Tron support coming soon. Updated docs for the new flags and sponsorship flow are available here.