Omnibus vs Segregated Crypto Wallets

Skip key takeaways

Key takeaways: omnibus vs segregated crypto wallets 5

Updated July 29, 2026

What Article 75(7) limb one actually compares, where per-client granularity really lives, what each branch costs on chain and why reconciliation is the artefact a supervisor asks for.

• Article 75(7) limb one is written as a client-versus-CASP test, and that reading drives the whole architecture The comparator named in that sentence is the provider's own crypto-assets, so limb one tests client against CASP rather than client against client. That reading is ours and no retrieved guidance settles it.
• Per-client granularity is a register obligation before it is an address obligation Article 75(2) requires a register of positions opened in the name of each client, the one place per-client granularity is beyond argument, and it lands on a record rather than on an address.
• Per-client addresses duplicate the register, they do not replace it Article 75(2) binds a custody CASP whatever its address topology, so the per-client branch keeps two records of the same entitlement, one on chain and one in the register, and the two can disagree.
• Fee, staking and bridge addresses are where clean splits actually fail Article 70(1) prevents use of clients' crypto-assets for the provider's own account, so gas wallets are funded from provider holdings alone, while staking and bridge addresses leave the register showing entitlements the inventory cannot place.
• Reconciliation is the evidence artefact, and no source sets its frequency No source sets a reconciliation frequency, so cadence is a documented internal control decision rather than a legal minimum. The nearest fixed point is the Article 75(5) statement of position, due at least once every three months.

Copy takeaways

If you are deciding between one omnibus address and an address per client, we can design the address scheme and the Article 75(2) register as one model.

See our MiCA compliance services

In short: Omnibus vs segregated crypto wallets is an address-scheme decision that MiCA Article 75(7) touches without settling. Limb one requires that on the distributed ledger clients' crypto-assets are held separately from the provider's own, which on its face is a client-versus-CASP test rather than a client-versus-client one, and no retrieved ESMA guidance resolves the point. Per-client granularity is unambiguous in exactly one place, the Article 75(2) register of positions opened in the name of each client. That makes this a fork rather than a best practice: an omnibus address concentrates client entitlement in the register, per-client addresses duplicate it on chain, and neither branch makes the register optional. Everything downstream, including the fee, staking and bridge addresses that fit neither side of a client and corporate split, arrives as a reconciliation problem.

Omnibus vs segregated crypto wallets is what Article 75(7) limb one actually tests

Omnibus vs segregated crypto wallets is a question Article 75(7) looks like it answers and, read closely, does not. The paragraph runs to three subparagraphs, on-ledger separation, legal segregation from the provider's estate and operational segregation from it. The first carries the whole on-ledger argument:

Crypto-asset service providers providing custody and administration of crypto-assets on behalf of clients shall segregate holdings of crypto-assets on behalf of their clients from their own holdings and ensure that the means of access to crypto-assets of their clients is clearly identified as such. They shall ensure that, on the distributed ledger, their clients' crypto-assets are held separately from their own crypto-assets.

Look at the comparator in the second sentence. What client assets must be held separately from is named, and it is "their own crypto-assets", the provider's. On the face of the drafting, limb one tests the client side against the provider side rather than one client against another. That reading is ours, and we label it as ours because it drives every branch below.

The counter-reading the same paragraph leaves open

The counter-reading belongs in the same paragraph, because the same text supports it. Preceding the on-ledger sentence is a requirement that the means of access to client crypto-assets be "clearly identified as such", and following it is a subparagraph on legal segregation from the provider's estate whose stated purpose is that creditors have no recourse in insolvency. Read purposively and together, those could be argued to push identifiability down to the individual client on chain rather than to the client population as a block. Nothing in the retrieved sources decides between the readings, and the gap is structural: neither Article 70 nor Article 75 carries a mandate for regulatory technical standards. The fiat analogue does not fill that gap either, since Article 70(3) separately identifiable accounts are a different obligation on a different asset class. Limbs two and three are covered in our MiCA custody requirements guide.

The fork is one omnibus address or an address per client

Omnibus vs segregated crypto wallets is a binary about how many on-ledger addresses hold client balances. One branch pools client holdings into a few addresses per chain and per asset. The other derives an address, or an address set, belonging to a single client. Hybrids are decisions about which clients or assets sit on which branch, so the binary stays the unit.

Criterion	One omnibus address	An address per client
Client count	Flat. Ten thousand clients cost on chain what ten cost	Linear. Each client is an address to derive, fund, monitor and archive
Chain set	One address per chain and asset, so a new chain is a small addition	Client count multiplied across every chain supported
Withdrawal frequency	Every outbound transaction leaves one balance, so contention concentrates	Contention spreads out, but each address needs its own fee funding path
On-chain cost profile	No sweep step	Sweeps consolidate before spending, and each sweep is an extra transaction
Monitoring surface	Few addresses, and nothing on chain says whose movement it is	Movements attributable on chain, against an inventory with no natural ceiling
Insolvency argument	Rests on the register and applicable law alone	Rests on the register, corroborated by a pattern an administrator can read
Disqualified when	An account-model chain with heavy withdrawal volume, where one nonce queue stalls every client on a single stuck transaction	A chain metering account creation by activation deposit or storage rent, or a UTXO chain with change handling left unpinned

Neither MiCA nor any retrieved guidance ranks the branches, so the last row and the rule here are ours, not a regulatory answer and not an industry standard. Omnibus wins where clients number in the thousands, the chain set is wide and withdrawals are batched, because every cost above scales with addresses and none with clients. Per client wins where clients are few enough to enumerate, one or two chains are supported, deposits far outnumber withdrawals and a counterparty wants attribution it can read on chain without asking us.

Key schemes decide who is able to sign for an address, and our key management comparison covers that in full. The address scheme decides whose name the balance sits under, which is the only axis here.

What the omnibus branch owes the register of positions

Taking the omnibus branch of the omnibus vs segregated crypto wallets fork moves every client-level fact off the ledger and into the register of positions, where Article 75(2) puts granularity beyond argument:

Crypto-asset service providers providing custody and administration of crypto-assets on behalf of clients shall keep a register of positions, opened in the name of each client, corresponding to each client's rights to the crypto-assets. Where relevant, crypto-asset service providers shall record as soon as possible in that register any movements following instructions from their clients.

"Opened in the name of each client" is the per-client requirement in the custody regime, and it lands on a record rather than on an address. That inverts the usual description of the branch, which saves nobody any client-level bookkeeping. It makes the register the only place client-level entitlement exists, raising the integrity bar on that record instead of lowering it. Article 75(4) adds that any event likely to create or modify a client's rights "shall immediately be recorded in the client's register of positions", so the register also tracks events that move no balance.

The client-facing artefact comes from the same record. Under Article 75(5) a custody CASP provides a statement of position at least once every three months and on request, in electronic format, identifying "the crypto-assets concerned, their balance, their value and the transfer of crypto-assets made during the period concerned". On an omnibus scheme nobody can check that statement against a public explorer.

What the per client branch costs at scale

The segregated branch of the omnibus vs segregated crypto wallets fork buys on-chain client attribution and pays for it in address count. Derivation moves onto the onboarding path, because an address has to exist before a client can be told where to deposit, and each one has to be recorded as assigned before it receives anything. Sweep economics follow, since balances spent from a treasury position get consolidated first and every consolidation is an on-chain transaction that exists only because of the address scheme.

Monitoring scales worst. Watching a handful of addresses is a subscription. Watching hundreds of thousands is an indexing problem, with a reorg-safe view per address and an archive that keeps growing after clients leave.

Per-client addresses also do not make the register optional. Article 75(2) binds a custody CASP whatever its address topology, so this branch produces two records of the same entitlement, one on chain and one in the register, and the two can disagree. Attribution a supervisor can verify independently is a real gain, bought by adding a second source of truth rather than by removing the first.

Where the chain model breaks the address scheme

Chain models decide how much of an omnibus vs segregated crypto wallets design survives contact with the ledger, because an address is not the same object everywhere.

On UTXO chains a client's holding is not a balance at an address. It is a set of unspent outputs, and spending from that set produces change, which by default lands at a fresh address. One client and one address becomes one client and a growing address set within a few transactions unless change handling is pinned deliberately.

Account-model chains impose the nonce instead. Transactions from one address execute in strict sequence, so an omnibus address puts every withdrawal in a single queue and a stuck transaction stalls all of them rather than one client. Per-client addresses dissolve that queue and replace it with a funding problem, since an address paying its own fees needs native units delivered first.

Two cases break the mapping outright. Contract-account wallets exist only after a deployment transaction, yet the address can be computed and receive deposits beforehand, so an inventory can hold entries with a balance and no code. Chains charging an activation deposit or storage rent per account make address creation a metered operation. So the per-client branch is not one address per client. It is a mapping the ledger keeps redrawing, while the Article 75(2) register duty does not bend to any of it.

The addresses that sit outside a clean client or corporate split

Some addresses fit neither side of the omnibus vs segregated crypto wallets split, and clean segregation schemes usually fail at these rather than at the client addresses.

Fee and gas wallets must be funded from provider holdings only

Fee and gas wallets are the sharpest case, because their constraint is statutory. Article 70(1) requires adequate arrangements safeguarding client ownership rights at all times, especially in the event of the provider's insolvency, and preventing "the use of clients' crypto-assets for their own account". Topping up operating gas from a client-attributed balance is that use, whatever entry gets written afterwards. Fund the gas wallet only from provider holdings and record the funding path, so the source of every top-up is provable. Note the article split here: the prohibition is Article 70, the horizontal safeguarding baseline for all CASPs, while the register, the segregation rule and the custody policy are Article 75.

Staking, bridge and the sub-custodian question they raise

Staking and validator addresses break the mapping differently. A balance leaves an address the provider controls and arrives at one it does not, so the inventory gains rows whose controller is a third party while the register still shows the client entitled. Bridge addresses are worse, because for an interval the position sits at neither end and needs a named state in the register, or every run in the window reports a break that is not one.

Those addresses also raise a question the text leaves open. Article 75(9) permits a custody CASP to use other providers of that service only where they are authorised in accordance with Article 59, and requires clients to be told. Whether the operator of such an address is such a provider is answered by none of the retrieved sources.

Tiering is an operational boundary, not a segregation answer

Tiering deserves one correction. Hot, warm and cold are operational boundaries with no segregation meaning by themselves. They change who can reach client assets how quickly, while limb one asks whose assets they are.

Reconciliation as the evidence artefact

Reconciliation is what makes an omnibus vs segregated crypto wallets decision defensible, because both branches leave a gap between the addresses on the ledger and the register of positions. ESMA's Common Supervisory Action on CASP digital operational resilience names "transaction controls" among the risks inherent to distributed ledger technology it will assess, and address topology is what those controls operate on. That scope list is our ESMA custody Common Supervisory Action coverage.

Four systems hold versions of the same number and any pair of them can drift. A node returns the on-ledger balance at a block height. Internally, the platform holds what it believes it custodies. Article 75(2) fixes what each client is entitled to, and Article 75(5) fixes what the client is told. Reconciling only the first against the last skips both places where breaks are made.

The break classes a reconciliation run must name

Name the break classes in advance, because an unclassified break is indistinguishable from a loss.

• Timing breaks, where a confirmation lands either side of the snapshot. Benign, but only when the run says so.
• Attribution breaks, where the totals agree and the split across clients does not. This is the omnibus-specific class and it never shows at the total level, so a run comparing aggregates alone reports clean while it is present.
• Fee drift, where an address holds marginally less than the register says.
• Orphan addresses, where a balance sits at an address appearing in no inventory, usually left by a retired derivation path or a test deployment nobody closed out.
• Unattributed inbound, where a deposit arrives with no client to assign it to.

Our own incident record puts 17% of 41 Sev-1 and Sev-2 events across 9 products, 2023 to 2026, in the data, migrations, state and reprocessing family that produces exactly this divergence. None of those were CASP custody platforms, so read it as a cause distribution rather than a custody base rate.

Cadence is a documented control decision, not a legal minimum

Cadence is the question everyone asks and no source answers. Nothing in MiCA, in DORA or in the ESMA release sets a reconciliation frequency. The nearest fixed points are of a different kind: movements recorded as soon as possible under Article 75(2), rights-affecting events recorded immediately under Article 75(4) and the statement of position at least once every three months under Article 75(5). None is a reconciliation interval, so cadence is a documented internal control decision defended on transaction volume and address count, never a legal minimum. Where the reconciliation record does sit is Article 68(8), which requires systems and procedures safeguarding the availability, authenticity, integrity and confidentiality of data pursuant to Regulation (EU) 2022/2554. MiCA and DORA apply from different dates, so pin each duty to its own instrument.

Designing the address scheme so reconciliation is cheap

An omnibus vs segregated crypto wallets scheme reconciles cheaply only when its addresses were designed for it, and those decisions are taken at address creation. Every address gets a machine-readable purpose before first use, separating client custody from provider holdings, gas funding, change, staking and bridging. Purpose reconstructed from transaction history months afterwards is a guess wearing a label, and orphan addresses are what that guess produces.

Keep the address-to-client mapping as an append-only journal rather than a table you update. A reassignment writes a new row carrying its effective time, so a reconciliation dated to a past block height runs against the mapping as it stood then. A mutable mapping reconciles only the present, which is the one period nobody disputes.

Record the derivation path and index behind each address, so the full set can be enumerated and shown to be complete without anyone holding key material. That record says which addresses exist, not who is able to sign for them.

Make the output of a run a signed, dated artefact rather than a dashboard view, carrying the block height, the totals on each side and every break with its class and disposition. A dashboard shows only the current state and cannot be handed to anyone as of a past date.

How Pharos Production helps

Omnibus vs segregated crypto wallets usually reaches us unmade, so our MiCA compliance software development practice builds either branch as one model with the Article 75(2) register rather than as two systems reconciled later, so the labeling, the mapping journal and the statement of position come out together. Our compliance and RegTech engineers build the reconciliation that proves it, with classified breaks and a dated artefact.

Sources: Regulation (EU) 2023/1114 (MiCA), Articles 68, 70, 75 and 149, via publications.europa.eu; Regulation (EU) 2022/2554 (DORA), Article 64, via publications.europa.eu; ESMA press release "ESMA launches Common Supervisory Action on CASPs' digital operational resilience for custody" (8 July 2026), via esma.europa.eu. Both regulations were read as originally published rather than as consolidated texts, so check for later amendments before relying on a quotation. The incident figure is Pharos Production delivery data, 41 Sev-1 and Sev-2 incidents across 9 products 2023-2026, and is not CASP-specific. The reading of Article 75(7) limb one offered here is ours, as is the branch-selection rule and its disqualifiers. This article is engineering guidance, not legal advice.

FAQ

Last updated: July 29, 2026 · Reviewed by: Dmytro Nasyrov (Founder and CTO)

Quick answers to common questions about custom software development, pricing, process and technology.

Expand all Collapse all

Search FAQs

Popular

Type to filter questions and answers. Use Topic to narrow the list.

Showing all 6

• ★ Featured question. Does MiCA require a separate wallet for every client?

  Copy link Copies a direct link to this answer to your clipboard.

  Article 75(7) limb one requires that on the distributed ledger clients' crypto-assets are held separately from the CASP's own crypto-assets, which on its face is a client-versus-CASP test rather than a client-versus-client one, and no retrieved ESMA guidance resolves the point.

• Where does per-client granularity actually live?

  Copy link Copies a direct link to this answer to your clipboard.

  In the Article 75(2) register of positions, which must be opened in the name of each client.

• Are omnibus wallets allowed under MiCA?

  Copy link Copies a direct link to this answer to your clipboard.

  The text does not prohibit them, but an omnibus scheme makes the register the only place client-level entitlement exists, which raises the integrity bar on that register.

• Can gas and fee wallets be funded from client balances?

  Copy link Copies a direct link to this answer to your clipboard.

  Article 70(1) requires arrangements that prevent the use of clients' crypto-assets for the CASP's own account, which is what funding operating gas from a client balance is.

• How often must a CASP reconcile the ledger against the register?

  Copy link Copies a direct link to this answer to your clipboard.

  Nothing in MiCA, DORA or the ESMA Common Supervisory Action release sets a reconciliation frequency, so the cadence is a documented internal control decision rather than a stated legal minimum.

• What does the client actually receive?

  Copy link Copies a direct link to this answer to your clipboard.

  Under Article 75(5), a statement of position at least every three months in electronic format, identifying the crypto-assets, their balance, their value and the transfers made during the period.

I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.

As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.

My focus is on complex products where mistakes are costly:

• Web3 and blockchain platforms
• FinTech and regulated products
• High-load startup systems
• MVP → scale transitions

We don’t do body-shopping.
We don’t sell generic outsourcing.

Instead, we help founders:

• build the right team structure from day one
• keep technical ownership and transparency
• scale delivery without losing control
• avoid vendor lock-in and hidden risks

Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.