Fork & Airdrop Policy

Last updated: May 30, 2026

This Fork and Airdrop Policy (the "Policy") is issued under and forms part of the DFNS Service Agreement or other DFNS agreement which references this Policy. Capitalized terms used but not defined herein have the meanings set forth in such agreement, including its Terms and Conditions (available at https://www.dfns.co/legal/terms-and-conditions) and Service Level Agreement (available at https://www.dfns.co/legal/sla).

This Policy is published by DFNS, a simplified joint stock company registered under number 888 176 575 with the Trade and Companies Register of Paris, having its registered office at 142, rue de Rivoli, 75001 Paris, France ("DFNS", "we", "us", "our"), publisher and owner of the Wallet-as-a-Service (WaaS) platform for digital assets (the "Platform").

1. Purpose and Scope

DFNS provides wallet infrastructure — including Wallets-as-a-Service (WaaS), Transaction Lifecycle Management (TLM), Wallet Entitlement Management (WEM), and Key Orchestration Service (KOS) — that enables Users and their Authorized End-Users to generate, secure, and operate wallets across supported blockchain networks (each a "Network").

The continued evolution of blockchain Networks regularly produces Forks and Airdrops that may create new or modified digital assets associated with addresses held through the Platform. This Policy describes how DFNS evaluates, and whether and how DFNS supports, such events. It is intended to set clear expectations for Users regarding the technical, security, operational, and commercial considerations that govern DFNS' handling of Forks and Airdrops.

This Policy applies to all Users of the Platform and supplements, and does not replace, the obligations and limitations set forth in the Agreement.

2. Definitions

For the purposes of this Policy:

"Airdrop" means the issuance by a blockchain of a new digital asset to known public keys or addresses derived from another blockchain, such that holders of private keys associated with the original Network may be entitled to access value on the issuing blockchain.

"Fork" means a divergence in a Network's protocol or consensus rules. A "Soft Fork" is a backward-compatible change that does not create a new asset or distinct chain. A "Hard Fork" is a non-backward-compatible change that may result in the creation of a new, separate Network and a corresponding new digital asset ("Forked Asset").

"Forked Asset" means any new digital asset created as a result of a Fork or distributed as a result of an Airdrop.

"Replay Protection" means a technical mechanism that prevents a transaction valid on one Network from being unintentionally valid and broadcast on another Network arising from the same Fork.

"Wipeout Protection" means a technical mechanism that protects a new chain from being reorganized or overtaken by the original chain.

For the purposes of this Policy, DFNS treats Airdrops and Hard Forks under the same evaluation framework, because in both cases the central question for Users is whether, when, and how new value associated with their wallets can be safely accessed.

3. Guiding Principles

3.1 Security First

DFNS' primary and overriding objective is the security and integrity of Users' existing digital assets and of the Platform. DFNS will not introduce support for any Fork or Airdrop where DFNS, in its sole discretion, believes doing so may compromise the security, integrity, or availability of the Platform or of Users' assets. Forks are frequently deployed rapidly, with technical implementations that continue to change up to and after the moment of activation. DFNS will not allow timing or commercial pressure to override this principle.

3.2 Preservation of Value

Subject to Section 3.1, DFNS intends to help Users preserve and, where feasible, access the value associated with significant Forks and Airdrops. Depending on the event, this may mean:

  • supporting the Forked Asset as a fully featured asset on the Platform, with the security properties DFNS generally maintains;
  • providing tools or processes that allow Users to access, claim, or transfer the Forked Asset; or
  • providing a mechanism for Users to export the relevant key material or signatures necessary to access the Forked Asset through other means, consistent with the Platform's key management architecture.

3.3 Neutrality

DFNS does not take positions in protocol governance disputes or endorse any Network, Fork, or development team. Decisions to support or decline a Forked Asset are operational and risk-based, and do not constitute an endorsement, recommendation, or assessment of the value, legality, or legitimacy of any Network or asset.

4. Evaluation Criteria

When a Fork or Airdrop affecting a supported Network is anticipated or occurs, DFNS evaluates whether to provide support based on the following considerations. No single factor is determinative, and DFNS weighs them holistically and in its sole discretion.

4.1 Technical Stability and Safety

Because security is paramount, the technical evaluation is critical. Factors include, without limitation:

  • the credibility, track record, and transparency of the team implementing the Fork;
  • whether the Forked Network provides adequate Replay Protection relative to the original Network;
  • whether the Forked Network provides adequate Wipeout Protection;
  • the strength, decentralization, and stability of the new Network's validator set, mining capacity, or other consensus security;
  • the maturity and auditability of the Network's codebase, signing schemes, and address formats; and
  • the existence of any known or suspected vulnerabilities introduced by the Fork.

DFNS will not support a Forked Asset that lacks sufficient Replay Protection until such protection is available through the protocol or through controls DFNS is able to implement safely.

4.2 Market Significance

For DFNS to consider supporting a Forked Asset, the asset must represent meaningful value to Users. DFNS considers the asset's market capitalization and recognition across reputable, established exchanges. A Forked Asset that is not measurably and durably valued on reputable markets is unlikely to be supported.

4.3 Liquidity

Market capitalization alone is insufficient. The Forked Asset must demonstrate sustained, genuine liquidity on reputable exchanges over a meaningful period, such that the value is realistically accessible rather than nominal. Thinly traded assets, even with a large notional capitalization, may not warrant support.

4.4 Operational and Engineering Cost

Supporting a new Forked Asset is a long-term commitment: once DFNS supports an asset and Network, it generally maintains that support indefinitely. Where a Forked Asset is technically similar to an asset DFNS already supports, the cost of support may be low. Where the Fork introduces new cryptographic schemes, transaction or block formats, signing requirements, or other material differences, the engineering, security-review, and ongoing maintenance burden is significantly higher. Cost is weighed against the value the Forked Asset would deliver to Users and may affect both the decision to support and the timing of support.

4.5 Legal, Regulatory, and Compliance Considerations

DFNS may decline to support, or may delay support for, any Forked Asset where doing so would, in DFNS' assessment, create legal or regulatory risk, conflict with Applicable Laws (including AML and KYC obligations), or be inconsistent with DFNS' licenses, registrations, or obligations to its banking, custody, or infrastructure partners. Support may vary by jurisdiction and by User eligibility.

4.6 Timing and Notice

Forks and Airdrops are often announced with limited advance notice, and some Airdrops impose expiry windows within which value must be claimed or it is forfeited. DFNS cannot guarantee support for any Fork or Airdrop within any specific timeframe, or at all. Engineering availability, security testing, third-party dependencies, and the criteria above all materially affect timing. Quality, safety, and the integrity of the Platform take precedence over speed.

5. Policy Statement

In the event of an anticipated or actual Fork or Airdrop affecting a supported Network, and where DFNS determines, in its sole discretion, that the resulting Forked Asset is technically safe and has sufficient market significance and liquidity, DFNS will use commercially reasonable efforts to make the value of the Forked Asset accessible to Users, at a time and through a method determined by DFNS in its sole discretion.

Notwithstanding the foregoing:

  • Security takes precedence. DFNS' first concern is always the security of Users' existing digital assets and the Platform. DFNS may decline to support, suspend handling of, or delay support for any Forked Asset accordingly.
  • No guarantee of support. DFNS makes no representation or warranty that it will support any particular Fork or Airdrop, that any Forked Asset will be accessible, or that support will be provided within any particular timeframe. Some Forked Assets may never be supported.
  • Implementation time. Even where DFNS elects to provide support, implementation may take significant time, and value may be lost where an Airdrop expires or a claim window closes before support is available. DFNS is not responsible for value that becomes inaccessible for such reasons.
  • Reconsideration over time. A decision not to support a Forked Asset at one point in time is not permanent. Where a Forked Asset later satisfies DFNS' criteria, DFNS may, in its sole discretion, elect to support it.
  • Expedited or custom support. Where DFNS considers a Fork or Airdrop technically safe with sufficient value and liquidity, but a User requires access in advance of the timeline DFNS can otherwise provide, DFNS may, in good faith and at the User's request, agree on a product plan to enable such access at a reasonable fee and at the User's sole expense.

6. User Responsibilities and Acknowledgements

By using the Platform, the User acknowledges and agrees that:

  • Self-directed access. DFNS provides wallet infrastructure and does not take custody decisions on behalf of the User in respect of Forked Assets. Where DFNS provides tools or key-export mechanisms to access a Forked Asset, the User is solely responsible for the use of such tools and for any resulting transactions.
  • Replay and transaction risk. Where a User or its Authorized End-Users transact on a Forked Network without adequate Replay Protection, transactions may be unintentionally valid on more than one Network. The User assumes all risk arising from such transactions.
  • No advice. Nothing in this Policy or in DFNS' handling of any Fork or Airdrop constitutes legal, tax, accounting, financial, or investment advice. Digital assets, including Forked Assets, are subject to a high degree of risk, including total loss of value. The User should consult its own advisors.
  • Compliance. The User remains responsible for ensuring that its receipt, holding, and use of any Forked Asset complies with all Applicable Laws applicable to the User and its Authorized End-Users.
  • Indemnification. To the fullest extent permitted by Applicable Law and consistent with the Agreement, the User shall indemnify and hold DFNS harmless against any direct, indirect, incidental, special, or consequential losses arising from the User's inability to access, or its access to and use of, any Forked Asset, except to the extent such losses arise directly from DFNS' gross negligence or willful misconduct.

7. Communication

Where DFNS elects to support, or to decline support for, a material Fork or Airdrop affecting a supported Network, DFNS will endeavor to communicate its position to affected Users through appropriate channels, which may include the Platform, DFNS documentation (https://docs.dfns.co), the DFNS status page (https://status.dfns.co), the DFNS changelog, or direct notice. DFNS does not undertake to provide notice in respect of every Fork or Airdrop, particularly those it does not support.

8. Relationship to the Agreement

This Policy is incorporated into and forms part of the Agreement. In the event of any conflict between this Policy and the body of the Agreement, the order of precedence set forth in the Agreement's "Hierarchy" provision shall apply. The limitations of liability, indemnification, and other protections set forth in the Agreement apply fully to DFNS' handling of Forks and Airdrops.

9. Updates to this Policy

DFNS reserves the right to update this Policy and the criteria used to evaluate the viability of any Fork or Airdrop from time to time, based on new technological, security, legal, regulatory, commercial, or environmental factors. The "Last updated" date at the top of this Policy reflects the most recent revision. Continued use of the Platform following any update constitutes acceptance of the updated Policy.

10. Contact

Questions regarding this Policy may be directed to DFNS at contact@dfns.co.

This Policy is governed by and construed in accordance with the laws of France, and any disputes arising from it are subject to the exclusive jurisdiction of the Courts of Paris, in each case as set forth more fully in the Agreement.

Contact us