What if the platform disappears?
Your tokenized asset should outlive every vendor that touches it – including us. Whether it actually does is decided at issuance time, by architecture. Here is the failure-mode comparison the demos skip.
The short version
Two architectures, two outcomes. If the platform holds investor wallets, gates transfers against its own database, and keeps the register in its SaaS – its failure strands tokens, breaks compliance, and drags your register into an insolvency. If investors hold their own keys (ERC-4337 passkey wallets), the token enforces eligibility against on-chain attestations (ERC-7943 + EAS/Coinbase Verifications), and the ledger is the register – the platform's death costs you tooling, nothing more. Stobox is built as the second on purpose; verify that claim the same way you'd verify anyone's: in writing, against the checklist below.
| Custodial + database gating | Non-custodial + on-chain attestations | |
|---|---|---|
| Investor tokens | Held in platform-controlled wallets – frozen or stranded until an administrator sorts it out. | Held in investors' own wallets (passkey smart wallets, ERC-4337) – they were never the platform's to lose. |
| Transfer compliance | The token checks the vendor's whitelist database. Database goes dark → every transfer fails or, worse, gating silently stops working. | The token checks on-chain attestations (EAS / Coinbase Verifications) itself. The rules keep enforcing with no server behind them. |
| The share register | Lives in the platform's SaaS. Export it while you still can. | Is the token ledger – public-chain state that survives any vendor. |
| Investor identity | KYC documents sit in the vendor's systems – now part of an insolvency estate. | Never stored: the platform reads a verified yes/no attestation; identity documents stay with the verification provider. |
| Operational tooling | Proprietary protocol – only the vendor's software speaks it. Migration = reissuance. | Open standards (ERC-7943) – any competent operator, or your own team, can stand up new tooling against the same tokens. |
| What you must re-procure | Everything: custody, compliance data, register, tooling – under time pressure, in an insolvency. | Tooling convenience only. The asset, register, compliance, and custody never depended on the vendor. |
Related: the 12-question platform checklist ·how the permissioned standards differ ·issuer-failure mechanics (the SPV playbook)
Questions this raises
Answered plainly.
What happens to token holders if the tokenization platform shuts down?
It depends entirely on architecture, and it's the most important question nobody asks in the demo. On a custodial, database-gated platform: investor tokens sit in vendor wallets, transfer compliance checks the vendor's whitelist, and the register lives in vendor SaaS – all of it becomes an insolvency problem. On a non-custodial, attestation-based architecture: investors hold their own keys, the token enforces its own transfer rules against on-chain attestations, and the ledger is the register – the platform's death costs you tooling convenience, not the asset.
Is this a theoretical risk?
No. Platforms consolidate, pivot, and fail like any startups – the 2026 market has already seen compliance-poor projects delisted and quiet shutdowns, and every issuer's own diligence (and increasingly their investors') asks the continuity question. The point is not predicting who fails; it is issuing so the answer doesn't matter.
How do I test a platform's real answer?
Ask three things in writing: (1) If you froze operations tomorrow, can my investors move their tokens without you? (2) Does transfer eligibility live in your database or on-chain? (3) Can another operator run my asset on standard tooling? Then check the token standard – a proprietary protocol makes 'yes' answers structurally impossible; open permissioned standards (ERC-3643, ERC-7943) make them verifiable.
Platform failure and issuer failure aren't the same thing, right?
Right – keep them separate. Issuer/SPV insolvency is a capital-structure question: token holders rank per the offering documents (usually behind secured creditors), whatever the technology. Platform failure is an infrastructure question – and the one you can fully engineer away at issuance time. This page is about the second; the SPV playbook covers the first. General information as of July 10, 2026, not legal or investment advice – see Legal & disclosures .
Primary sources: Transfer-agent rules, definitions – 17 CFR 240.17Ad-1 · Transfer-agent rules, securityholder records – 17 CFR 240.17Ad-10.
