UK Crypto Listing Due Diligence: Smart Contract Checks

Video transcript

From October 25, 2027, a retail UK crypto platform must be reasonably satisfied a token is not likely to harm retail investors before admitting it. That test reaches into the token's smart contracts.

Under CRYPTO 3.2.5R, criteria must cover the resilience and governance of the token, and known risks in its ledger, smart contracts and wider protocol. A documented process helps, but each file needs its own reasoning.

For each token, on each chain, record who can upgrade the code, pause transfers, mint supply, freeze or blacklist addresses, or force a transfer. Then ask the issuer how those keys and multisigs are held.

An audit covers one commit. Confirm the deployed bytecode matches it, check the admin and bridge contracts were in scope, record every open finding, and note what changed since.

The FCA does not expect platforms to verify everything. But role holders, thresholds, timelocks and bytecode can be read from the chain. Save could not verify for offchain facts like signer identities and key storage.

Records of each assessment, decision and its reasons must be kept for five years, or up to seven where the FCA requests.

A code vulnerability found before admission can be inside information under MARC. Disclosure may be delayed while it is fixed, but the FCA says not indefinitely.

Guardian maps privileged roles and upgrade paths from deployed contracts and matches bytecode to audited code. Read the full checklist, or talk to Guardian at guardian.security.

Crypto listing due diligence in the UK becomes a rule on October 25, 2027.

The FCA's PS26/9, published on June 30, 2026, finalized the Admissions and Disclosures rules in a new CRYPTO 3 chapter of the FCA Handbook. The rules are made, in instrument FCA 2026/37.

The rules bind retail UK qualifying cryptoasset trading platforms (QCATPs), but they reach issuers too. A platform cannot pass the test without information only the issuer, and the chain, can provide.

Platforms applying in the window, which closes on February 28, 2027, need the process designed before go-live. Our UK deadlines post has every date.

This article explains the technical and security side of the FCA's PS26/9 admissions rules in CRYPTO 3. It is not legal advice; confirm how it applies to you with counsel.

What CRYPTO 3.2 requires

The FCA will consider whether the platform followed a robust and documented process, but that alone is not determinative.

The platform “should also be able to demonstrate in each case the basis on which it was reasonably satisfied”. Each file needs its own reasoning.

The technology criteria

Three of the five factors in CRYPTO 3.2.5R(2) bear directly on a technical review.

• (b) “the resilience, technical functionality and credibility of the governance and operational arrangements for the qualifying cryptoasset”;
• (c) any known risks in its underlying technology, such as the ledger, smart contracts or wider protocol, that may affect its security, functionality or continuing viability;
• (e) whether the information obtained can be verified and, if not, how that may affect retail investors.

The FCA expects the disclosure document, the QCDD, to cover governance, resilience, planned updates, audits, ownership concentration and any specific vulnerability “to hacks or other disruption” (CRYPTO 3.3.10G).

Admin powers and keys

A token's privileged functions decide whether holders keep what they bought. The FCA's GC26/7 consultation cites the 2021 $SQUID token, whose contracts “were designed to allow only the scammers to sell”.

For each token, on each chain, record these powers.

Key custody evidence

The chain shows who holds each role, not how the keys are protected. Ask the issuer for the rest.

• Every privileged role and its holder, which you then check onchain.
• Each multisig's threshold, signers' identities or affiliations, and how signers are added or removed.
• How keys are stored (hardware wallets, MPC, HSMs) and how signers are separated.
• How signers verify transactions independently of the signing interface, the gap behind the February 2025 Bybit theft.
• Timelock and emergency procedures, and who can act without the delay.

Audit reports and open findings

An audit report is evidence about one commit, so read it against what is deployed.

• Commit match. Confirm the deployed bytecode on each chain matches the audited commit, and list every upgrade since.
• Scope. Check whether the admin, upgrade and bridge contracts were in scope, not just the token logic.
• Open findings. Record each unresolved or acknowledged finding, its severity, and whether a fix review confirmed the fixes.
• Recency. Note how much code changed after the report date.

MARC lists information on a code vulnerability, known to a development team from pre-admission testing, among examples of possible inside information (CRYPTO 4.3.9G(4)).

Disclosure may be delayed where immediate disclosure would prejudice efforts to fix a security vulnerability (CRYPTO 4.10.21G(3)). But the FCA says delay “cannot be indefinite”.

Platforms and issuers should agree a confidential reporting and remediation channel before diligence.

When facts cannot be verified

PS26/9 confirms admission can still be possible where some information cannot be verified.

That needs reasonable steps, proportionate to the risk of harm, and a conclusion that the remaining uncertainty does not make admission likely to be detrimental.

The FCA does not expect platforms “to verify every matter independently”. It does expect them to check issuer information against publicly available or reasonably accessible sources.

Platforms must record what could not be obtained or verified. Where relevant, the QCDD should say so clearly and prominently.

That standard favors onchain evidence. Role holders, thresholds, timelocks, supply history and bytecode matches can be checked from the chain, so a platform will struggle to call them unverifiable.

Reserve “could not verify” for offchain facts such as signer identities or key storage, and say what was done instead.

Tokens already listed

In CP26/32, published September 4, 2026, the FCA proposed a 6-month deferral of the pre-admission assessment and QCDD for tokens already trading before authorization.

It would run from authorization, require a window application and notice to the FCA, and end early for each token once its QCDD is published.

Tokens first admitted after authorization would not be covered. PS26/9 called this subject to change, so check whether the FCA has confirmed it.

A per-token checklist

1. Token addresses on every chain, whether each is upgradeable, and its bytecode match to the audited commit.
2. Every privileged role (upgrade, pause, mint, freeze, blacklist, forced transfer, fee setting) and its holder.
3. Holder type for each role, with threshold, timelock delay and bypass roles.
4. Signer identities or affiliations, and key storage, as attested by the issuer.
5. Mint history, supply caps and ownership concentration.
6. Bridge or messaging configuration for cross-chain copies, and who can change it.
7. Oracle or external data dependencies, if the token's logic uses them.
8. Audit reports, scope, open findings, fix reviews and changes since, mapped to deployed code.
9. Known incidents, exploits or emergency actions in the token's history.
10. What could not be obtained or verified, the steps taken and the effect on the decision.
11. The decision, the reasons and the criteria applied, recorded for 5 years.
12. A channel for vulnerabilities found during diligence, consistent with MARC.

What Guardian does

Guardian's smart contract audits begin with a design review of roles, upgrade paths and the threat model, and track findings through fix and re-review.

For listing files, Guardian's technical evidence work maps privileged roles and upgrade paths from the deployed contracts. It matches deployed bytecode to the audited commit and checks live configuration.

Frequently Asked Questions

Does CRYPTO 3.2.5R require a smart contract audit before listing?

Not in terms. Its criteria must take into account known risks in the token's smart contracts, and the FCA expects the disclosure document to describe any audits. So audits are the usual evidence.

Which platforms must carry out this due diligence?

Retail UK QCATP operators: UK qualifying cryptoasset trading platforms whose rules do not preclude retail investors from trading directly or through intermediaries.

Do the rules apply to tokens a platform already lists?

They would apply as soon as the platform is authorized. CP26/32 proposed a 6-month deferral for tokens already trading, for window applicants that notified the FCA. Check whether the FCA has confirmed it.

Sources

• FCA: PS26/9 Admissions and Disclosures and Market Abuse Regime for Cryptoassets, with made rules FCA 2026/37 and 2026/38 (PDF, June 2026)
• FCA: Overview of our cryptoassets regime policy statements (June 30, 2026)
• FCA: CP26/32 Quarterly consultation paper No. 53 (September 4, 2026)
• FCA: CP26/32, Chapter 4, Deferral arrangements for the Cryptoasset Regime (PDF, September 2026)
• FCA: GC26/7 guidance consultation, Case Studies 4 and 5 (PDF, October 21, 2026)
• legislation.gov.uk: The Financial Services and Markets Act 2000 (Cryptoassets) Regulations 2026, SI 2026/102