DeFi regulation & security
Smart contract certification in France
The ACPR-AMF working group explored how smart contract certification could work. Its report is research, not an adopted certification regime or an official regulatory position.
- Sources checked
- Published
- Prepared by
- DeFi Security Alliance
Scope: This guide covers the specified EU rule or assessment program and technical preparation. It does not determine a particular business's legal status or replace national filing instructions.
Understand what the ACPR-AMF work establishes
The working-group report published on 3 February 2025 explores possible smart contract certification. It expressly says it is neither a regulatory proposal nor an official position of the participating authorities. It should not be presented as a mandatory French certification scheme already available to all DeFi projects.
The work covers possible standards, audit methods and regulatory scenarios. The subsequent consultation summary records stakeholder feedback. A consultation response is evidence of a view, not adoption of that view as law.
For an operating business, keep the French CASP authorization route separate from this research. A private audit report, a proposed certification model and an AMF authorization have different subjects and legal effects.
Separate code security from protocol governance
The report's proposed principles address security, governance, service conformity and the lifecycle of certification. Its audit discussion includes manual and automated analysis, dynamic tests and formal methods. It also identifies governance questions that technical automation alone may not resolve.
For a preparation exercise, divide the work into two connected scopes. The first covers code and execution: reviewed version, dependencies, privileges and behavior. The second covers the service: decisions, user rights, emergency responsibilities and change management. The following worksheet is DeFiSec's way to organize that exercise. It is not an official ACPR-AMF application form.
| Review area | Evidence to prepare | Question to answer | Limit to record |
|---|---|---|---|
| Reviewed implementation | Source revision, build configuration, deployment addresses and dependencies. | Does the reviewed implementation match the deployed service? | Excluded components and later changes. |
| Privileges | Contract roles, administrators and approval procedure. | Who can change execution or access, and how is that power constrained? | Off-chain actions the technical review cannot independently verify. |
| Service behavior | Published terms and testable expectations. | Do the tests cover the behavior users are told to expect? | External data and economic assumptions. |
| Emergency operation | Trigger conditions, permitted actions and restoration procedure. | Can an incident be handled without uncontrolled permanent privileges? | Unexercised scenarios and unavailable dependencies. |
| Changes | Version history, impact analysis and retest results. | Which changes invalidate an earlier assessment conclusion? | Conditions for continued reliance on an older report. |
| Public assessment claim | Issuer, scope, date, outcome and verification route. | Can a user verify exactly what the claim covers? | No implied guarantee of security or regulatory authorization. |
The worksheet deliberately asks for observations and unresolved assumptions. A report that names a tool but omits the tested version cannot establish which deployed system was examined. A governance policy can describe an approval process without proving that deployed administrator keys follow it.
Distinguish the audit from the certification decision
The working group considers different possible issuers and decision processes. Those alternatives help explain why an audit result and a certification decision are distinct steps. The report does not allow a vendor to choose a model and advertise itself as approved by the French authorities.
When evaluating a real assessment offer, identify the reviewer, the decision-maker and the rules under which an outcome would be issued. Obtain the scope, exclusions, validity conditions, change procedure and way a third party can verify the outcome. These are due-diligence questions for an assessment purchase, not a list of permissions conferred by the report.
Do not convert a duration discussed as an option into an existing legal validity period. The applicable terms must come from the actual program or engagement. A subsequent code upgrade may require a fresh scope decision even if the older document has not reached its stated expiry date.
Connect the report to the live deployment
Pharos Production's analysis of smart contract risk in crypto custody discusses the connection between reviewed code, deployed versions and operational permissions. It is useful when preparing the technical evidence above. It is not evidence that Pharos issues an ACPR-AMF certification or that its technical interpretation is an official regulatory position.
Before relying on an assessment, trace one important service action through the deployed contracts and the responsible operators. Compare the result with the report's scope and list mismatches. Keep the evidence needed to repeat that comparison after an upgrade.
For an existing Maltese technology-assessment framework, compare MDIA TARF levels and outcomes. For the separate EU discussion of possible DeFi certification, read the MiCA review consultation guide.
Continue your research
Sources and further reading
Legislation and regulator publications establish the legal basis. Technical resources explain implementation. Source checks cover the passages cited in this guide.
- Certification des smart contracts : synthèse de la consultationACPR and AMF ·
- Rapport du groupe de travail sur la certification des smart contractsForum Fintech ACPR-AMF ·
- Smart contract risk in crypto custodyPharos Production ·