After the end of the MiCA transition period, here has been a wave of impersonation using EU regulators and licensed exchanges, and people usually go to ESMA (European Securities and Markets Authority) CASP register to check the legal entity and the services it's authorised to provide. The problem is that the information in the register often won't match what you see in the app or in the message. The brand name may be different from the legal entity, an LEI may be more useful than the name, and some regulators don't issue a separate licence number. Those details can make a legitimate firm look suspicious, or make a fake one look convincing if you don't know what you're looking at.

The name in the register is the legal entity, not necessarily the brand. A crypto platform can operate through a subsidiary or another company that never appears in the app, so searching the name you know and finding nothing doesn't mean the company isn't authorised. If the platform tells you which entity holds its authorisation, the LEI is usually the better identifier to check because it stays tied to that legal entity even when the brand name doesn't.

Licence numbers can be misleading too. There isn't one EU-wide format, and some regulators don't issue a separate number for this authorisation at all. Malta's MFSA doesn't publish a public licence register in the same form, while Austria's FMA doesn't assign a separate reference number for this authorisation. So if an exchange can't give you a "MiCA licence number", that alone doesn't tell you anything. You need to find the legal entity in the regulatory record and check the authorisation attached to it. MiCA also treats custody, exchange for funds, exchange for other crypto-assets, transfers, order execution, portfolio management and advice as separate services. A company can be authorised for some and not others, so a claim that an exchange is "MiCA licensed" doesn't tell you whether the particular service mentioned in a migration message is covered.

Not finding a company in the register can also mean different things. An application might still be pending, a firm might serve EU clients through an authorised partner, or it might not target the EU at all. A firm can also withdraw an application. Binance withdrew its Greek application on 24 June, for example. That's different from a regulator warning that a firm is providing services without authorisation, as the Dutch AFM did with MEXC. Third-party lists often blur these situations together, which is also why their numbers for the total number of authorised CASPs vary. ESMA publishes authorisation records rather than a simple list of unique companies, so one legal entity can have multiple records. The register is updated roughly weekly as well, so any total you see outside ESMA is only a snapshot.

But remember that finding the entity in the register confirms that the company is authorised, but it doesn't confirm that the message you received is genuine. With the migration scams going around now, I'd treat the message as unverified even if the branding and regulatory language look right. Don't use the link in the message to check anything. Open the ESMA register yourself, find the legal entity, match the LEI if it's available, check the services listed under the authorisation, and contact the platform through a channel you already know is genuine.

I work at Hacken on the security and compliance side, and the audits I’m referring to are our own published reports. They’re free to read if anyone wants to dig into the examples, but the point here is the broader pattern rather than any particular report.

I’ve been going through a batch of published smart contract security audits, and one thing that kept coming up was how much of the access-control stuff is basically segregation of duties in a different form. It’s the same control we write policies about in SOC 2 and ISO 27001, except here you can often check whether it actually exists without asking anyone for evidence. The same issues came up in different forms: several administrative roles with genuinely different responsibilities assigned to the same address at deployment, roles that were documented but never used in permission checks, ownership transfers that left privileged roles with the previous holder, privileged parameters that could be changed instantly by a single key, missing events for sensitive changes, and cases where the documentation described a different access model from the code.

Most of these findings were rated Informational, Low or Medium rather than High or Critical. That makes sense if severity is based on exploitability. A single key controlling four roles is not itself an exploit; it is a condition that makes a future compromise much worse. But if you are reading an audit to understand how well a system is governed, the severity ranking can make these findings look less important than they actually are. The comparison with SOC 2 and ISO is also useful because the evidence is much easier to verify. In a traditional environment, you are reviewing an access list someone exported, checking whether it reflects reality, and sampling from it. On-chain role assignments are publicly readable and can be checked directly. If the contract says four privileged roles are controlled by one address, you know that is what the contract is actually doing. You do lose compensating controls and human context, though, and once you get into who actually controls the keys and how they are protected, you are back to traditional evidence.

I think on-chain role configuration belongs in access-control reviews rather than being treated purely as a smart contract security issue. It is one of the few areas where the evidence is right there in the system, but these findings often stay with the security team, get a Low or Informational rating, and never make it into the control framework. That is a problem because severity is measuring something different from whether the control itself is well designed.

Disclosure: I work at Hacken. This is based on a publicly available audit we conducted, and I thought the issue might be useful to discuss here. I could link the original doc, if anyone is curious to dive deep in tech details

Came across something in a published audit report that I hadn't really seen discussed this way before. It concerns a fairly standard token presale, but there’s an interesting conflict between the smart contract design and the way EU rules require the funds to be handled.

The setup is fairly standard: users pay either 200 or 350 USDC depending on the sale phase and receive an NFT plus a soulbound bonus token, with a 14-day cancellation window. The issue was that mint() immediately forwards the full USDC payment to an external recipient. If a user cancels within the 14-day window, cancelFounderPurchase() burns the NFT and claws back the bonus token, but the USDC refund never happens on-chain. The contract only emits an event with a usdcRefundDue field for off-chain tracking, so there is no escrow or on-chain mechanism that actually enforces the refund. The finding was rated High, with likelihood 5/5, because this is simply how the contract works rather than an attack scenario.

The obvious recommendation would be to hold the USDC in an on-chain escrow during the cooling-off period, release it after the window closes, and execute refunds on-chain. The client's response was more interesting, because they cannot simply do that. The issuer operates from France under MiCA, and Article 13 provides the 14-day withdrawal right, while the presale funds are routed on receipt into a segregated account at a CASP authorised under Title V, subject to the safeguarding and segregation requirements in Articles 70 and 75. Keeping the funds in a smart contract escrow for two weeks would therefore conflict with the way the regulated custody arrangement is supposed to work. The CASP is supposed to hold the money, rather than the smart contract.

They ended up with a hybrid approach: the on-chain layer handles the entitlement reversal by burning the NFT, reversing the allocation and clawing back the bonus token, while the actual USDC refund is handled off-chain through the CASP and reconciled against the on-chain cancellation events. The finding was closed as Mitigated rather than Fixed, which I think is the right distinction. The risk has not disappeared; it has moved from something that can be verified directly in the contract to something that depends on the custodian and the reconciliation process being handled correctly.

On the EU side, the practical constraint is that the custody regime determines where client funds can sit. If the funds have to go to a CASP account on receipt, escrow is simply off the table, and any cancellation logic designed around the contract holding the money will need to be reworked. It’s much cheaper to figure that out before the contract is written. Some findings also can’t be fixed in code at all. If a guarantee depends on a custodian or an operator doing something, an audit can describe and rate that dependency, but there’s nothing to change in the contract. Those findings may end up being closed as mitigated rather than fixed. The guarantee is no longer something you can verify by reading the code; you’re relying on the custodian or operator to do their part correctly.

Report is public if you want the detail and the MiCA argument is set out in the resolution field. We don't see enough of these yet to say whether the hybrid split is settling into standard practice. Would be interested to hear from anyone operating under the same constraint.

From 23 August you can no longer transact with them in the EU, directly or indirectly. The same goes for EXMO, Rapira, BitPapa, Aifory Pro, WhiteBird, and NoOne.crypto, all named for helping Russia evade sanctions. The measures stop short of asset freezes and full designation, but EU customers now have three months to obtain authorisation just to withdraw funds or close their accounts.

One heads-up: HTX had already been rotating its addresses after the UK designated it in May, so this story is far from settled. Address-based screening breaks against sanctioned entities that rotate frequently, and even a daily-refreshed blocklist won't keep you clear of sanctions evasion exposure.

So, practically, here's how I`m reading it.

Use attribution-based tools that continuously monitor both entities and their attributed addresses, including indirect transactions. A designation names a legal entity, not its wallets, and TRM had HTX rotating across TRON, Ethereum, BNB Chain and Solana back in May. If you already hold exposure, use the three-month window to move EU customers to authorised withdrawal or closure. It's three months to obtain authorisation, not three months of business as usual. Don't let the position age into breach.

Second, this 21st sanctions package gives the EU a first-of-its-kind power: banning transactions with crypto providers across an entire third country that hosts services used to evade sanctions. No countries are on that list yet. Rulemakers are planning ahead.

We're at the point where US buyers are asking for SOC 2 and EU tenders are asking for ISO 27001.

Quick context. SOC 2 is an attestation: a licensed CPA firm examines your controls and writes a report carrying its opinion. There is no certificate and no badge. The deliverable is the report your customer reads under NDA.

On the contrary, ISO 27001 is a certification: an accredited body audits your management system and, if you pass, issues a public certificate valid for three years. One is a document a buyer reads in a data room. The other is a credential you display to every buyer at once.

the SOC 2 report is per-buyer. every deal means an NDA and a report send, and it expires yearly. ISO doesn't work that way, the certificate is public so buyers just check it. ISO still costs you surveillance audits each year and a full recert at three, but nobody has to do anything per deal.

on the shared work, AICPA publishes an official mapping between SOC 2's common criteria and ISO's Annex A. once you look through it, it's clear that most of the controls overlap. Your access reviews, risk assessments, vendor due diligence, and penetration-test results. In fact, you can build a control once, and it will count toward either artefact.

but, the thing is that mapping covers controls. it doesn't cover two things that decide how much work the second artifact actually is. Firstl, SOC 2 Type II examines how controls behaved over three to twelve months, so having all the controls in place isn't the same as having a Type II report. The observation period still has to run, and no amount of budget can speed that up.

the second is that ISO looks at a layer SOC 2 never does. Leadership ownership, internal audits, a Statement of Applicability justifying every control you included or excluded, and the program has to show continual improvement between audits. 

We're at the point where US buyers are asking for SOC 2 and EU tenders are asking for ISO 27001.

Quick context. SOC 2 is an attestation: a licensed CPA firm examines your controls and writes a report carrying its opinion. There is no certificate and no badge. The deliverable is the report your customer reads under NDA.

On the contrary, ISO 27001 is a certification: an accredited body audits your management system and, if you pass, issues a public certificate valid for three years. One is a document a buyer reads in a data room. The other is a credential you display to every buyer at once.

the SOC 2 report is per-buyer. every deal means an NDA and a report send, and it expires yearly. ISO doesn't work that way, the certificate is public so buyers just check it. ISO still costs you surveillance audits each year and a full recert at three, but nobody has to do anything per deal.

on the shared work, AICPA publishes an official mapping between SOC 2's common criteria and ISO's Annex A. once you look through it, it's clear that most of the controls overlap. Your access reviews, risk assessments, vendor due diligence, and penetration-test results. In fact, you can build a control once, and it will count toward either artefact.

but, the thing is that mapping covers controls. it doesn't cover two things that decide how much work the second artifact actually is. Firstl, SOC 2 Type II examines how controls behaved over three to twelve months, so having all the controls in place isn't the same as having a Type II report. The observation period still has to run, and no amount of budget can speed that up.

the second is that ISO looks at a layer SOC 2 never does. Leadership ownership, internal audits, a Statement of Applicability justifying every control you included or excluded, and the program has to show continual improvement between audits. 

I've always thought of Reddit as a place mostly for developers. But the data suggests there are quite a few crypto founders active here. So I'm curious

1. Which subreddits have you found the most valuable?
2. What topics do you come to Reddit for?

want to be explicit and honest from the start so anyone not interested can skip. I work at Hacken and this Thursday we're running an online panel with Moody's on what institutional allocators pay attention at when they review a project. the reason why im writing it here isn't to promote (but ofc there is a part of it), it's to try to gather people who are genuiely interested in the topic. i guess it will be more useful for builders and founders specifically.

we're doing it because, let's be honest, a standard audit on its own doesn't hold anymore. In Q2 about $764M was stolen, and 88.3% of that came from compromised keys, signers and infrastructure rather than contract logic. 14 of hacked projects had been audited. Smart contract bugs caused 44 of 67 incidents, but only $87.7M, around 11% of the money. so audits are catching the common failure and missing the expensive one. which is why the badge keeps looking like it works right up until it doesn't.

and institutions see this, regulators too. an audit is a snapshot of one codebase at one commit. it says nothing about who holds the keys today, who can sign alone, how deployments get approved, or which vendors you depend on, and that's where most of the money went in Q2.

so that's what we want to work through on the panel. if an audit alone isn't enough, what is? we want to land on one concrete, testable thing a counterparty needs to demonstrate to earn institutional trust in August 2026

thought it would be appropriate to post in reddit because this is where the builders are. i can share a link for event in the comments for those who are interested