What You’re Actually Trusting: Omnibus, Segregated and Hybrid Custody
This article is also available in Turkish: https://medium.com/@alpteginkaraca/havuz-c%C3%BCzdan-m%C4%B1-herkesin-c%C3%BCzdan%C4%B1-kendine-mi-58e484c5be58
Wallet architecture is a technical decision. It’s also a decision about who you’re accountable to.
Introduction
Today an institution doesn’t have to answer the “how am I going to custody assets” question on its own. There are providers that have productized the answer and come with a reference architecture ready to go. HSM-based on-prem deployments and MPC infrastructures are no longer layers institutions build from scratch; they’ve turned into layers you can buy and integrate.
In Turkey, Digital Asset Custody is now a licensed activity in its own right, and there are concrete obligations around it: segregating customer assets from the institution’s own assets, reporting balances regularly, Travel Rule messaging on transfers, a record-keeping system open to audit, and so on. The regulation also draws lines for you at many points and sets certain criteria.
If you look closely, these obligations are decoupled from the question of “where does the private key sit”. They’re all about on whose behalf, at which address, and under which record-keeping system the asset is held.
Should you collect all user assets at a single address?
Should you open a dedicated address for every user?
Or should you run both approaches together?
In this article we’ll take the fundamental architectures of crypto asset custody. Omnibus, segregated and hybrid, and take a look at them from a strategic angle.
Omnibus Model: Everyone in the Same Pool
In the omnibus model all user assets are held at a single (or a small number of) address on the blockchain. User balances are separated on a database (off-chain ledger); the institution reads who owns how much through its own central system.
Let me open a parenthesis here: in the omnibus model users are usually still given a dedicated deposit address, and the assets arriving at those addresses are periodically sent to the main pool (sweeping/forwarding). So “single address” describes the custody and withdrawal side, not the deposit side. On networks that support memo/destination tags (XRP, XLM, Cosmos-based chains), it’s possible to work with a single deposit address plus a user tag; there the model really does come down to one address if preferred.
If tens of thousands of deposits and withdrawals are happening per day and most users are low-balance retail customers who transact frequently, managing every movement at a separate address brings both technical burden and cost. That’s why most platforms in Turkey prefer the omnibus model.
Let’s have a look at the reasons behind that choice.
Managing one or a few addresses is simpler than managing as many addresses as you have customers. Balance tracking and transfers are run over the omnibus address.
Transfers, especially on UTXO-based networks (e.g. Bitcoin), can be done in bulk with methods like batch transactioning, which optimizes transaction costs.
On the other hand, because user assets are pooled into a common wallet and spent from there, in the omnibus model the investor cannot verify their own address and balance on the blockchain.
In Turkey the regulatory layer tries to close this gap. Through KVMKS (MKK’s central customer and balance registry for crypto assets, which platforms and custodians report into and which cross-checks their submissions) , platforms and custodians report customer balances and their trading, transfer and deposit-withdrawal activity to Central Securities Depository of Türkiye (MKK). The system compares them against each other. So reconciliation isn’t based on a one-sided declaration, it’s provided by cross-checking two or more sources. I deliberately avoid the word “independent” for those sources, since some custodians are group companies of the platforms they serve.
As of 15 June 2026, a total of 53 CASP (crypto asset service provider) ; 46 platforms and 7 custody institutions on the Capital Markets Board of Türkiye’s (SPK) list of firms in operation, have completed their KVMKS integration. The next phase is the e-YATIRIMCI platform (e-investor platform: MKK’s investor-facing portal where holdings across licensed institutions can be viewed from a single screen), where investors will be able to track their crypto asset balances from a single screen, just as they do in capital markets.
I still think a “transparent” system should let its users perform an independent verification; as things stand, even if it’s MKK, we have to trust a central authority.
The balance verification done through KVMKS shouldn’t be equated with cryptographic Proof of Reserve. In PoR, user balances are collected into a Merkle tree and the institution proves that control of the on-chain addresses belongs to it with a signed message. In other words, where you can’t show per-user addresses and balances, you turn to cryptography and can basically prove “yes, I control this pool address and your balance sits inside this pool”.
There’s no such cryptographic proof in KVMKS; there’s reporting reconciliation. Both work, but they ask us to trust different things.
I should add this too: PoR is already an answer produced for the omnibus model’s verifiability problem. So omnibus isn’t an unverifiable model; the cost and method of verification are simply different.
In short, MKK does offer the regulator and the investor a strong oversight layer, it does, but the structure being “trusted” here is not the blockchain, it’s still central institutions and regulators.
There’s one more disadvantage I want to mention, but it will make more sense to explain it on the segregated side, by comparison.
Segregated Wallet Model — “Everyone Has Their Own Wallet”
In the segregated model a separate on-chain address is created for every user. Technically these addresses are still under the custody provider’s control, but as I touched on above, address-level separation makes quite a difference in terms of transparency and auditability.
The segregated model is generally used where the operational cost per address stays negligible next to the value of the asset being protected. Banks and investment firms providing custody to institutional clients, OTC desks, portfolio management companies, platforms issuing tokenized assets, what they all have in common is balances expressed in the millions.
There’s also the obligation these institutions have to account to their auditor, their investor or their regulator. Being able to say “my assets are at this address, come and take a look yourself” is an easier position to defend than saying “it’s recorded in the system, trust me”.
Advantages
Transparency
The user can check their address and balance on-chain themselves. The same is available to the regulator, the auditor and the counterparty.
Risk isolation
In situations like a faulty transaction, a wrong match or an address-level problem, the impact stays limited to a single address; the risk from something like a transfer coming in from a low trust-score address doesn’t spread across the whole pool.
If an address that on-chain AML products consider safe today later lands on a sanctions list, and you have received a transfer from that address and swept it into your omnibus pool, you can’t work out which customer the balance mixed into the common pool belongs to just by looking at on-chain data.
By the nature of the model you’ve put all your apples in the same basket, and they’re all identical in colour, shape and weight. Which apples are safe, which ones are risky?
The problem isn’t only that you can’t separate the apples. On-chain AML products recognize omnibus pool addresses as known CASP addresses and usually end fund tracing right there. So not every transfer leaving your pool automatically gets stamped “risky”. But don’t let the trace stopping there put you at ease, quite the opposite, from that point on you’re the one who answers for what happens. Once a risky balance mixes into the common pool, you can’t answer “which customer did this amount belong to, where did it go?” by looking at the chain alone; the answer comes down to the accuracy of your own off-chain records. A risky balance deposited by a single user thus turns into the institution’s problem rather than that user’s.
In a segregated setup the amount in question stays at the address belonging to that customer. That way the impact of the risky asset can be confined to a single address. You created and handed out an address per customer, and you already know whose it is. Institutional AML controls, Travel Rule obligations and so on don’t disappear, but it becomes easier to separate out the source, the owner and the subsequent movements of the risky funds.
Legal separability
In bankruptcy, seizure or a similar situation, the matter always comes back around to “which asset belongs to whom”. In a segregated structure you can look not only at internal company records but also at the on-chain balance.
Of course, having separated the address and the assets from the rest doesn’t mean the asset legally belongs to the customer. The keys are with the custodian. What does the user agreement say, what does the legislation say; a court looks at those first. The benefit of segregated isn’t proving ownership; it’s clearly showing which balance is allocated to which customer.
The fact that the liquidation and repayment process at Mt.Gox has run past 12 years and still isn’t finished shows how hard it can be to establish that separation after the fact.
In Turkey, separating customer assets from the institution’s own and tracking them per customer is already ensured by legislation and MKK reporting.
Get Berat Alptegin Karaca’s stories in your inbox
Join Medium for free to get updates from this writer.
So in my view segregated’s legal contribution is more limited in Turkey than in global markets; part of the job is already being done by MKK itself, tracking in near real time the balance changes arising from trades, transfers and movements.
Disadvantages
Operational load and on-chain monitoring
Creating a dedicated address per user, plus custody, monitoring, whitelisting, withdrawal policy and so on, all require individual management.
In a custody operation, the job of talking to the blockchain is done by nodes and the indexing layer built on top of them. “Did funds arrive at the address?”, “what’s the balance now?”, “how many confirmations does the transfer have?”, it’s all read from there. And there’s a serious difference between your nodes watching a single pool address and watching hundreds of thousands of addresses. As the address count grows, query cost, data storage needs and balance update latency grow along with it.
That cost shows up both on your infrastructure bill and in the user’s complaint of “why can’t I see my money yet”.
In short, as the number of active addresses rises the chain connection gets more complex, and if you work with a large number of addresses you’ll likely run into related delays from time to time.
Liquidity management
On UTXO-based networks a lot of small balances accumulate, and consolidating them becomes a cost item of its own. On EVM-compatible account-based networks, to move funds out of an address that address needs to hold the native coin. Periodically feeding tens of thousands of addresses with gas is an operation in itself.
There are ways around this problem, of course. Opening user addresses as dedicated contract addresses, ERC-4337 account abstraction with a paymaster so the institution pays the gas, giving a regular address contract behaviour (doable since EIP-7702), are the known solutions.
They all make the job easier, but none of them is free: you’ve brought contract development, audit and upgrade processes inside your custody operation.
Balance update speed
The segregated model’s transparency promise rests on the user being able to see their balance on-chain. As we discussed on the operational load side, on a platform a balance doesn’t change only with deposits and withdrawals; every trade order changes it too.
When a user buys 0.1 BTC, an on-chain transfer has to happen for that balance to be reflected at the address. On an orderbook where hundreds of orders match per second, doing that in real time isn’t really possible.
In practice trades are recorded on the off-chain ledger and the on-chain address is updated periodically through reconciliation. So what the user sees on-chain isn’t their live balance, it’s the system’s balance as of the last reconciliation. The gap between them grows the more actively the user transacts.
That’s why the segregated model works more transparently for assets with low turnover/velocity (balances left in custody, collateral, staked assets, tokenized assets). For a user making dozens of trades a day, the transparency promise stays somewhat “theoretical”.
Hybrid Model
Up to here you may have thought of the two models as alternatives to each other. But custodians already don’t hold assets in a single structure: the hot–cold wallet split is essentially a logical hybrid approach too. Part of the same user’s balance sits in an instantly accessible structure, the rest in a far more protected and slower one.
The model I call hybrid custody is that same logic carried onto the omnibus–segregated axis. The question shouldn’t be “should we switch”, it should be what you’ll base the split on.
Not all users need the same thing. When a retail account passes a certain balance threshold, moves to institutional status, or enters a product that requires address-level tracking such as collateral or staking, the model may need to change. The reverse holds too: low-balance segregated addresses that have been dormant for a long time can be pulled into the omnibus pool so they stop generating cost.
The real difficulty of the hybrid model isn’t running two structures at once, it’s making the transition between them rule-based and automatic. Thresholds, triggers and approval flows have to be defined up front; otherwise what comes out isn’t a hybrid model, it turns into a two-model system managed manually.
This flexibility has a price too, of course. Running two different structures in the same system complicates development processes and system management. Questions like which user’s balance is held where, which transfer went through which model, call for advanced monitoring and logging structures.
On the UX side it also creates an inconsistency. Some users can see their address and balance on-chain while others have to trust the balance they see on the screen. A single user’s assets can even sit in different models depending on the product they bought. In that case the user will see part of their balance on-chain and part of it not. I’m not sure whether that’s a clear disadvantage, but it will definitely create conceptual confusion.
Another cost is having to design the reconciliation system from the ground up. In the omnibus model you roughly expect the per-asset pool balance to match the sum of the customer sub-accounts; in the segregated model the on-chain wallet balance and the balance shown to the user should be the same. When you switch between the two models, when pending or failed transfers occur, when trades enter the picture, or when a user holds balances in both models, the reconciliation process gets seriously complicated.
Conclusion
There are technical differences between the models, but most of them can be closed with engineering. Whatever development or optimization is needed can be implemented, or most likely bought. I want to look somewhere else: what separates two setups that can do the same job is “how much the user is forced to trust that setup”.
In the omnibus model the user has to trust the institution in order to believe their asset is there. The only thing they can see on-chain is the pool total; their own share is shown only in the institution’s record system.
In the segregated model the user sees the address allocated to them on-chain and verifies for themselves that the balance really sits there. But let’s be clear about this: the chain proves that balance exists, not that it belongs to you. The information that the address is allocated to you is still the custodian’s declaration, not a cryptographic fact.
In both scenarios you’re trusting the institution, and in both there’s a layer of internal controls, periodic independent audit and MKK reconciliation. So the issue isn’t who you trust. The real difference is on what, and to what extent, you’re forced to trust.
In Turkey the regulator doesn’t tell you which wallet architecture you have to implement, but there are expectations such as regularly transmitting balance and wallet distributions to MKK and continuously maintaining reconciliation at the user level. An approach that runs verification through institutional records.
Verifiability methods like PoR are the user-facing side of the job. These approaches aren’t rivals; a mature custody infrastructure should offer both; reporting reconciliation to the regulator, cryptographic verifiability to the user.
I think a hybrid model will become the standard in the future, but it’s worth updating the definition of “hybrid”. Today we make that split roughly by looking at the customer segment: institutions segregated, retail omnibus.
It’s a practical split but it’s looking from the wrong place, because the same user’s different assets can be subject to different business rules.
Going for a product-based split would be more accurate instead. Products like spot assets, staked assets, assets pledged as collateral and tokenized assets each need to be custodied in a way that fits their own business rules.
- Spot assets should be quickly transferable, buyable and sellable;
- Staked assets shouldn’t move during the lock-up period, and staking income should be added to the customer balance periodically;
- Collateral assets should be viewable at address level by both the creditor and the debtor, with the ability to add or remove based on price swings;
- For tokenized assets the addresses they can be transferred to should be restricted, and clawback and redemption setups should be defined by rule.
In a hybrid system a single user’s assets can therefore sit in more than one model at the same time. Which model is used is determined not by who the user is, but by which product the asset is tied to.
Final word
Choosing a wallet architecture is an infrastructure decision, but it’s also the technical reflection of how much transparency and accountability the institution chooses to provide, and to whom.
The segregated model increases visibility but doesn’t remove the trust factor. The link between the address you see on-chain and your entitlement ultimately rests on the custodian’s records, its control mechanisms and the agreement you signed.
An ideal custody infrastructure should rest not just on a hybrid wallet architecture but on a hybrid assurance model. Cryptographic verification and the reporting reconciliation the regulation requires should work together.
Omnibus, segregated or hybrid, it doesn’t matter; if you don’t hold the private key, you have to trust someone else.
But with the right architecture you can limit that trust, distribute it, and make it verifiable.
