Where client assets live

Nothing. OLTA is in public preview and accepts no client capital. The balances, the positions and the profit and loss visible across the indices, the trade surface and the portfolio view are simulated, computed from public market data against a rulebook rather than against settled trades. The preview banner says so across the app.

Saying so plainly is the point of this section. A custody page that reads like an operating custody service, on a product that safekeeps nothing, is the exact failure mode an allocator is scanning for. Everything below is either a control already running in the product, or a specification the eventual counterparties are being measured against. The two are marked differently throughout.

The practical consequence for a reader in diligence: there is no balance to reconcile, no attestation to request and no counterparty confirmation to chase. What can be assessed today is whether the framework is the right one, and whether the controls that do exist behave the way this page says they do.

Institutional custody starts with one rule. Client assets are held in accounts legally distinct from the operating capital of the firm that books the trade, and the two pools never share a ledger entry. The point is not bookkeeping hygiene, it is bankruptcy isolation. If the operating entity fails, client assets stay remote from the estate and remain identifiable as client property rather than becoming unsecured claims in a queue.

The convention is codified in the United States by SEC Rule 15c3-3, the broker-dealer customer-protection rule, which requires segregation of customer securities and cash from the proprietary holdings of the broker. Equivalent doctrines run through MiFID II in Europe, the Securities and Futures Act in Singapore, and the conduct-of-business regime under the ADGM FSRA. OLTA reads each of these as the floor, not the ceiling.

Onchain assets are segregated through dedicated wallet structures. Each client entitlement is bookkept against custody addresses controlled exclusively for client positions, separate from any operating wallet, and settled on the EVM rail. Tokenized equities are segregated one layer up, at the broker, through sub-accounts that map one to one to the client of record. Same isolation principle, two settlement rails, two different sets of rules to satisfy.

Segregation only counts if it is auditable. The framework requires periodic third-party attestation of both the wallet structure and the sub-account hierarchy, on a cadence that matches what allocator due-diligence desks expect rather than the lighter touch typical of retail crypto venues. That attestation does not exist yet and is listed as such in the control table below.

Most custody losses are not sophisticated. They come from one human being able to move value alone, or from an approval process that exists in a ticketing tool rather than in the signing path. The question an investment committee should ask is not which technology holds the keys, it is what has to happen before value moves, and who can change that answer.

Five requirements define the model in this framework. First, no single signer: approval is a quorum of several people who do not share a device, a location or a single point of coercion. Second, a destination allowlist: an approved transfer can only reach an address registered in advance, and changing that list is a slower procedure than using it. Third, policy enforced in the signing infrastructure, so an out-of-policy transaction cannot be formed rather than being caught in review. Fourth, separation of duties: whoever initiates cannot approve, and neither of them administers the policy. Fifth, a break-glass path that is written down, rehearsed and alarmed, because the alternative is one improvised at three in the morning.

None of this is running today, because there is nothing to sign for. It is stated here as the specification the eventual custody counterparty is being measured against, and it is the reason no provider is named on this page. Publishing a vendor name before the diligence concludes would tell a reader something we do not yet know.

OLTA is reading custody-relevant regulation across the five jurisdictions below. Each row carries the primary framework and the current posture. The verbs are deliberately conservative: studying means desk work, in dialogue means a conversation is open, and neither means a permission has been granted.

Reading a custody regime and serving a market are different activities, and the page should not blur them. The application resolves a visitor country into an access tier before it renders, and 16 country codes are not served at all in the preview, the United States and Canada among them. The work on the US regime concerns the qualified-custodian doctrine that a future US-facing structure would have to satisfy. It is not a claim that a US allocator can onboard today.

A single-jurisdiction footprint is a single point of regulatory failure. The lesson from the 2022 to 2024 cycle is that venues concentrated in one perimeter repriced sharply the moment that perimeter moved: a rule reinterpretation, an enforcement action or a licence freeze in the home jurisdiction translated straight into client access risk. The institutional answer is geographic diversification of the custody stack, not optimisation toward the lightest-touch regime.

The framework therefore presumes a primary operating perimeter, a secondary perimeter in a structurally different regulatory family, and continuity arrangements that preserve client access to records if either perimeter shifts. The same logic applies inside a perimeter. Crypto custody and tokenized-equity custody are distinct activities supervised by different rule sets, and a venue that solves one well is not automatically credible on the other, so the framework treats them as two parallel stacks with their own counterparty under their own anchor.

Three failures get conflated in this question and they have different answers. OLTA stops operating. A counterparty stops operating. A regulator closes a perimeter. The first is the one allocators ask about, so take it directly.

Today the answer is short. No client capital is held, so a failure of OLTA costs a user access to a simulator and nothing else. There is no recovery procedure to describe because there is nothing to recover. Any page claiming otherwise at this stage would be describing a service that does not exist.

For mainnet, the framework sets four continuity requirements. Client entitlements are recorded so that a third party can reconstruct who owns what without the OLTA application running. Key material is held so that recovery does not depend on specific OLTA employees being reachable. The wind-down order, meaning who is paid, in what sequence, over what period, is written before it is needed rather than drafted under pressure. And client access to records survives the firm, which is a contractual requirement on the counterparty rather than a promise from us.

One continuity control is already in place and is worth stating, because it is checkable today. The construction rules are published. A basket is defined by its rulebook and its constituent list, not by a private model, so the portfolio a client holds can be described, reproduced and unwound by someone who has never spoken to OLTA. Publishing the methodology is usually framed as a transparency choice. It is also a continuity control, and that is part of why it is published.

The distinction this table draws is the one that matters in diligence. Some of these controls run today and can be verified by a reader without asking OLTA for anything. The rest exist in this document and nowhere else. Presenting both in one list, with the difference marked, is more useful than a page of capabilities with no dates attached.

The absent rows are the honest part of the table. There is no independent attestation, no reconciliation of entitlements against balances, and no incident policy published yet. Each is a precondition for accepting client capital, not a nice-to-have to be added after launch, and each is tracked against the mainnet date rather than left open.

The operational counterparties, meaning the custody provider for onchain assets, the broker for tokenized equities and the settlement venue, are being selected. The selection runs against the criteria in this document: segregation discipline, the signing model in section 03, regulator coverage in the studied jurisdictions, audit cadence, and the reporting profile an allocator due-diligence desk will ask for.

Provider names stay off this page until the diligence concludes and terms are signed. That is a deliberate constraint rather than an omission: a named counterparty reads to an allocator as a completed arrangement, and an arrangement that is still being negotiated is not one. Allocators in an active evaluation can receive the detailed framework, including the counterparty shortlist and the selection criteria, on a confidential basis.

Mainnet settlement is targeted for H1 2027. Between here and there the sequence is unglamorous and public: conclude the counterparty selection, stand up the signing model, complete a first independent attestation, publish the incident and restatement policy, and only then accept capital. If any of those slip, the date moves rather than the standard.