Skip to main content

MiCA and who controls the keys

Not legal advice

This page describes an architectural fact and the regulatory question it raises. It is not a legal opinion or a compliance claim, and Varnir has not sought regulatory sign-off on it. Confirm MiCA's applicability to your use with your own counsel.

Why this page exists​

The EU's Markets in Crypto-Assets Regulation puts its heaviest licensing burden — Title V, the Crypto-Asset Service Provider (CASP) regime — on entities that hold or control client crypto-assets or private keys on the client's behalf: custody and administration, exchange, and similar discretionary services. A rail whose declared, near-term target is EU USDT settlement (see the introduction) has to have a position on that.

The architectural fact​

Two things are already true of the code, not proposed for it:

  • Identity keys never reach Varnir at all. The signing model and How keys are held describe this mechanically: generated in your own process, never transmitted, every ledger transaction signed locally.
  • L1 wallet keys — the ones that actually receive deposits — are never stored whole on any one machine, not even briefly at rest. How keys are held is the full account: Shamir 3-of-4 across the four ledger nodes, reassembled briefly inside a confidential VM only to make each signature (Standard), or two-party threshold ECDSA where the private key is never assembled anywhere at all (Advanced). There is no master key and no operator override in the code.

Testnet and production are built for different jobs. Testnet is built for speed and delivery: Varnir runs every node, and the confidential VMs run without hardware attestation. Production is designed to spread the nodes across separate operators, cloud providers and countries, much like Tron's super representatives or Bitcoin's miners, on attested AMD SEV-SNP machines, so that no single party, Varnir included, and no single government can reassemble a key.

Settlement runs as on-ledger contracts (Varnir.Deposit, Varnir.CryptoTransfer, Varnir.AssignOwner) that execute the same way for every caller and can't be redirected by a decision made after the fact. Nobody at Varnir approves, holds or releases a specific transfer — the contracts do, deterministically, or they don't run at all.

The question that raises​

MiCA's custody trigger is about control, not proximity: a service that never has the ability to move a client's assets unilaterally doesn't fit the thing Title V's custody requirements are written to constrain. That's the position this architecture is built toward — a rail where "trust Varnir's operator" is not a step in the flow, by construction, rather than by policy that could change.

It's a position, not a settled classification. MiCA's scope has open interpretive questions — what counts as acting "on behalf of a client," how an automated smart-contract layer is treated versus a human-operated one, and where an entity that runs the nodes (even without holding a usable key) sits — that regulators and courts are still working through across the EU. Distribution and jurisdiction is also candid that the deployed topology isn't yet the distributed one this argument leans on: today it's one machine, one operator, one jurisdiction. The argument gets stronger as that gap closes, not weaker.

Next​