For years, "audit" in crypto meant one thing: someone read your smart contracts. Your infrastructure, the nodes and providers and RPC connections every transaction actually travels through, was nobody's business but your own.
That assumption no longer holds. Two EU regimes are now live, and both ask questions that land directly on your infrastructure. Regulators have moved past policy documents; they want to see what your systems actually did. For licensed exchanges, custodians, and stablecoin issuers in Europe, the next review is an exam with a date, and the evidence it wants lives in a layer most teams have never had to produce evidence from.
Two rulebooks, one direction
MiCA is the EU's crypto business rulebook: who may operate an exchange, hold client assets, or issue a stablecoin, and what those firms owe their clients.
DORA is the EU's IT resilience rulebook for all of finance, and since January 2025 it covers licensed crypto firms too. DORA doesn't care what your business is. It cares whether your technology survives, whether you detect failures, and whether you manage the vendors your critical systems depend on.
The link between them is easy to miss. MiCA has no technology chapter of its own; it hands that job to DORA. The moment a firm holds a MiCA licence, its infrastructure, including every RPC provider it relies on, sits inside DORA's scope. Together, the two rulebooks point at the same layer.
The questions you'll actually be asked
Each of these traces to a live obligation in MiCA, DORA, or their technical standards.
"Which providers served your chain data, and what did each one answer?" When a serious incident originates from a third-party provider, DORA's incident reporting requires firms to name that provider, with its legal identifier, in the initial notification - due within hours of classifying the incident, and shared with supervisors across the EU. If you can't tell which provider served which answer, you can't fill in that field. You also can't defend a vendor who didn't cause the problem.
"Show us the records for this transaction." MiCA requires firms to keep records of all services, orders, and transactions for five years, seven if a regulator asks. The technical standards list the on-chain data points a firm is expected to hold: the transaction hash, the wallet addresses, the block timestamp, and an identifier linking the on-chain event to the firm's own books. Those fields describe chain reads. Someone has to observe them at the time, and produce them years later.
"When the chain had problems, was it the chain, or was it you?" Under MiCA's continuity rules, when a public blockchain is disrupted, firms must tell clients the cause, the expected recovery, the risk to their assets, and what's being done. To say any of that, you first have to know it - and a team running a single provider often cannot tell "the chain is halted" apart from "our provider is broken." Different answers, different consequences.
"Was data damaged, and how badly?" DORA classifies incidents partly by data loss: availability, authenticity, integrity, confidentiality. Data integrity can make an incident reportable on its own. Uptime says a provider answered, not that the answer was right. The rules know the difference.
"Where does your RPC layer sit in your vendor register?" DORA requires every financial entity to keep a register of its ICT vendors: what each provides, how critical it is, whether it could be replaced. Your RPC providers belong in that register, and so does whatever sits above them. In most firms, the answer to "who supplies your chain data" is scattered across three teams and a spreadsheet.
Almost nobody has this view today
Follow the chain data through a typical regulated firm. Reads and writes go out through two or three providers, sometimes through code paths built years apart. Each provider has its own dashboard, its own definition of uptime, its own logs you can't see. Your own logs rotate away after days. Screening tools consume chain data through yet another path. When the audit request arrives, someone assembles the story by hand: exports from one system, screenshots from another, glued together over a long week.
No single place shows what the firm's infrastructure did. Nothing can prove it after the fact.
And the expensive failures aren't outages. In September 2025, Polygon kept producing blocks while transaction finality silently stalled; every uptime monitor showed green while exchanges halted operations to avoid crediting transactions that could reverse. A month later, a single AWS region failure degraded several "independent" RPC providers at once, because they quietly shared infrastructure. Neither shows up as downtime on a status page. Both are the kind of event a regulator now expects a firm to catch and explain.
Strip away the legal language and the regulations ask one thing: do you know your own infrastructure? Which providers you depend on, what they answered, how fresh it was, what happened when they disagreed.
One place that knows your infrastructure
Security teams solved this problem years ago. Ask a CISO what's happening across their estate and they open one view: the tools feed it, and the evidence comes out of it. Nobody runs security from nine dashboards and a spreadsheet anymore.
Your blockchain infrastructure deserves the same, and that is what Smart Router is: one control plane your chain data runs through. Your existing providers, your own nodes, your existing services and third-party tools connect to it; nothing gets replaced. Because everything passes through it, it can answer the questions above:
- See it. Every request, every provider, every response on one path - which provider answered, when, and how fresh it was, without a week of digging.
- Trust it. Responses validated across independent sources by policy, so a disagreement surfaces as a signal instead of passing through silently, and providers that are up but behind the chain get caught. That is the job of RPC security, not availability monitoring.
- Prove it. Metrics and evidence exportable for audits and resilience reviews, from a vendor you can put in your register - SOC 2 Type II and ISO/IEC 27001 certified, deployable in your own environment.
And we're taking it the rest of the way: a single place where you review your whole chain-data layer, know what's happening in it, prove what it did, and walk into an audit already holding the answers. We're building it right now with teams that live under these regimes, and their needs are shaping it. The firms at the table today will be the ones ready when the knock comes.
This layer was never asked to produce evidence before. It's being asked now.
We're deep in this. Talk to us.
How exposed is your RPC stack?
Take the 2-minute Secure RPC Assessment and get a personalized risk report.
Run the assessment
