The most consistent pushback I get from regulators, from investors who don't already work in crypto, and occasionally from journalists trying to write the takedown piece is: how is it possible that GM Markets does not gate users at the platform level. The framing usually carries the implicit assumption that this is the part where I admit there's a regulatory shortcut and we move on to talking about the inevitable enforcement action.
That is not the conversation. The conversation is about where the gating happens, and the answer is that it happens at the asset layer, not at the user layer. This is a meaningful architectural choice, it is the choice that lets the platform be useful, and it is also the choice that takes the most explaining. So this is the explainer.
The default architecture
The default model in regulated capital markets is to gate at the user layer. The platform onboards each user, runs identity verification, runs sanctions screening, classifies the user by jurisdiction and accredited-investor status, and from that point on the user can transact in whatever the platform offers. The compliance burden is paid once, at the user gate, and the platform's offering is the same to every user who passed the gate.
This works in the world where the platform's offering is small and homogeneous. A US broker offering US-listed equities to US users does not need a complex per-asset gate, because every asset is offered to every approved user. The user gate is sufficient.
It does not work in the world where the platform's offering is heterogeneous and the rules are different per asset. A platform that wants to offer US-listed equities to non-US users, US Reg D securities to verified accredited US investors, EEA-listed instruments to EEA professional investors, and Swiss DLT passport instruments to Swiss residents, cannot collapse all of those rules into a single user-gate. The rules don't compose at the user layer. They compose at the asset layer.
So the question is not whether to gate. It is where.
The user-layer gate is a compliance shortcut
The reason most platforms gate at the user layer is operational, not regulatory. It is easier to build one identity verification flow than to build per-asset eligibility logic. It is easier to operate one set of compliance procedures than to maintain a per-asset compliance map. It is easier to write the legal terms for one user than to write them for one asset against many user populations.
Easier is fine when the cost of the shortcut is small. The cost in this case is significant. Gating at the user layer means every user has to clear the same identity gate to access any asset, including assets that have no per-user restriction at all. A user who wants to hold a fully permissionless tokenized commodity has to go through the same gate as a user who wants to access a Reg D security. The user-layer gate does not respect the per-asset rules. It applies the maximum-restriction set to everyone.
This is the part that breaks the value of the platform. The reason a wallet-native asset is valuable is that it is reachable. A user in a non-US jurisdiction can interact with it without intermediation. The moment you put a user-layer identity gate in front of it, the asset stops being reachable in the way that made it valuable. You have built a slightly cheaper version of the existing brokerage account.
The asset-layer gate is harder, but it preserves the property
We gate at the asset. Each tokenized instrument carries its own eligibility rules, encoded into the issuance layer and enforced at the moment of transfer. A wallet that wants to interact with an asset that has restrictions has to satisfy those restrictions before the transfer is permitted. The interface shows the asset, and the interface enforces the rules at the moment the user tries to interact with it.
This is harder operationally. Each new asset class, each new jurisdiction, each new eligibility rule has to be modeled, encoded, and enforced. The compliance map is per-asset, not per-user. The legal review for adding a new instrument is heavier than it would be in the user-layer model.
But the property of the platform survives. A user in a permissive jurisdiction sees and can transact in the assets eligible to them. A user in a restrictive jurisdiction sees the assets but cannot transact in the restricted ones. A wallet that wants to integrate with the platform programmatically does not have to onboard a human first. The reachability survives.
I think this is the only architecture that lets a multi-asset platform work in capital markets. The user-layer gate scales to one asset class. It does not scale across asset classes with heterogeneous rules.
What this looks like for the user
The interface is one of the things we spent the most time on, because the user-facing experience of the asset-layer gate is what makes or breaks whether the design feels coherent or arbitrary.
A user connects their wallet. The interface shows the catalog of assets. Each asset has an eligibility badge: open, jurisdictional, accredited-only, professional-only, or some combination. A user in a jurisdiction where the asset is open can buy it. A user in a jurisdiction where the asset is restricted sees the badge and the explanation of what would unlock the asset for them, which might be a one-time identity verification at the issuer layer, or it might be that the asset is genuinely not available in their jurisdiction.
The platform itself does not perform the identity verification. It points the user to the issuer layer (which is Flo, in our case), where the per-asset onboarding happens for the assets that need it. The platform's role is to surface the rules and route the user to the right place when they apply. The platform never holds the user's identity. The issuer holds it, when it's needed at all, and only for the assets that require it.
What this gets right and what it doesn't
The honest tradeoffs are worth naming.
What this gets right: the platform stays composable. A protocol that wants to integrate with the asset can do so without onboarding a human user first. The asset can be held in any wallet, including a smart contract wallet. The reachability that makes the asset valuable survives.
What this gets wrong, or at least gets harder: the eligibility rules have to be visible and enforceable on every asset. If the rules change, the platform has to update the eligibility logic for every asset affected. The compliance burden is real and it does not go away, it just lives in a different place.
There is also a class of risk that the user-layer model handles trivially and the asset-layer model has to handle by design. A user who is eligible for an asset today might become ineligible tomorrow, due to a change in their jurisdiction's rules or a change in their personal status. The asset-layer model has to handle this without retroactively voiding their position, which means the rules apply at the moment of transfer, not as a continuous state. This is a defensible position. It is not the same position the user-layer model is in.
Why this matters more than it sounds
The reason I write about this with more energy than the topic might warrant is that the user-layer-versus-asset-layer choice is, in practice, the choice between being a closed pool with a slicker interface and being a real wallet-native capital market. They look the same in the demo. They are completely different in what they enable.
A closed pool with a slicker interface is what most tokenization platforms have ended up being. I am not knocking the choice. It is the conservative path. It is the path the regulators understand. It is also the path that does not actually deliver the value of wallet-native assets to anyone, because the asset has been re-imprisoned inside a slightly newer wall.
A real wallet-native capital market is much harder to build. It requires the asset-layer gate to actually work, which requires legal and operational discipline that most teams underestimate. It requires the issuer layer to be ready to handle per-asset onboarding without leaning on a platform-wide one. It requires the platform to accept that some users will land on the page and discover that the asset they want is not available to them, and that the right answer is to be honest about why rather than to invent a way to onboard them anyway.
I think this is the choice we got right. I am not certain about every implementation detail. The eligibility rules per asset are not always as crisp as I want them to be. There are edge cases in cross-jurisdictional transfer that we are still working through. The honest answer is that the architecture is correct and the implementation is improving, and the gap between those two is where the work is.
If you're building something adjacent and weighing the same choice, I'd be curious which direction you went and why. The shape of this is still moving across the space, and I think the platforms that get this layer right are the ones that end up with the durable position. The ones that gated at the user layer because it was easier are going to find that the easier choice was actually the more expensive one, just paid later.