Beyond the SNS: Why Toko Could Be Its Natural Successor
The Service Nervous System was one of the Internet Computer’s most important ideas. It gave an application a credible path from founder control to community ownership: a standard governance system, a native token, staking, proposals, a treasury and an on-chain mechanism for controlling the application itself.
That was a major step forward. But it was also only the first step.
The SNS is fundamentally a governance and tokenisation framework for a single application. Its standard architecture consists of governance, ledger, archive, index, root and swap canisters, following a common NNS-approved upgrade path. That consistency is valuable: projects do not need to invent a DAO from scratch, and users can understand the broad shape of every SNS. But the same standardisation also reveals the boundary of the model. An SNS can govern an application; it is not, by itself, a general-purpose operating system for building deeply programmable on-chain economies.
Toko could be the natural successor because it begins where the SNS stops.
From governing an application to programming an economy
The central question behind an SNS is: who controls this application?
The central question behind Toko is larger: what can the application, its assets and its communities actually do?
At Toko’s foundation is icyDB: a substantial embedded SQL database that runs inside a canister. At roughly 400,000 lines of code, it is not a thin wrapper around stable memory or a proof-of-concept data layer. It is infrastructure designed to let applications keep rich, structured and queryable state where the computation itself lives—on-chain, without surrendering the application’s core data model to a conventional cloud database.
On top of that sits Canic, our orchestration and scaling layer. Canic is intended to let a service expand across tens of thousands of canisters, distributed across Internet Computer subnets, without forcing every application team to invent its own sharding, deployment and lifecycle machinery.
Then there is Toko itself: tokens, NFTs, quantities, ledgers, collections, programmable logic, dynamic state and lifecycle rules. A Toko asset is not limited to being a balance in a ledger or a static pointer to some metadata. It can be an evolving digital object with its own state, permissions, behaviour and relationship to other assets and systems.
Taken together, this is not merely another token standard. It is the beginning of an on-chain economic application platform.
Governance should exist at the level where value exists
The SNS attaches governance to a project and its native fungible token. That remains useful, but real digital economies are more granular than that.
A game may contain thousands of distinct assets, rule systems, competitions and communities. A tokenised real-world asset may have its own custodial state, redemption process and stakeholders. A collection may need governance over curation, licensing or treasury flows without inheriting every decision made by the wider platform. Even an individual high-value NFT could represent an object, club or position with its own rights and decision process.
Per-token and per-NFT governance—already on Toko’s roadmap—moves governance to the level where the value, identity and behaviour actually reside. Collections could share a common governing framework while individual assets retain specialised rules. Governance could be nested, composed or delegated instead of being forced into one project-wide mechanism.
That is a meaningful evolution: from a DAO controlling a dapp to programmable communities controlling any meaningful unit of on-chain state.
A successor should preserve the value that already exists
Toko should not ask the ICP ecosystem to abandon the SNS era and start again. The strongest path is continuity.
SNS ledgers already use ICRC-1 for fungible-token balances, with index canisters providing account transaction views. That creates a practical compatibility boundary. Existing liquid balances could be imported into Toko through deterministic snapshots, with account and subaccount ownership, supply, metadata and fees preserved. Existing token interfaces could remain available through compatibility adapters so wallets, exchanges and applications do not need to migrate simultaneously.
But a credible migration cannot be described as “copy the balances.” SNS state includes treasuries, staked neurons, dissolve delays, maturity, permissions, follow relationships, voting power and proposal history. Tokens may be locked, vested or controlled by canisters. NFT standards add ownership, metadata, approvals and collection-specific semantics. Each of these states must either be faithfully represented in Toko or remain verifiably linked to its legacy source.
A serious migration protocol would therefore need:
- A governance-authorised cutover point and canonical source-state commitment.
- A deterministic importer whose output can be reproduced independently.
- Public proofs that total supply, balances, locks and governing rights were preserved.
- A transition that makes double spending or double voting impossible.
- Permanent access to the legacy transaction and proposal history.
- A challenge and audit period before the migrated system becomes final.
This would not be a bridge in the usual sense. It would be a verifiable protocol upgrade for an entire on-chain economy.
The ledger archive is the next scaling proof
Toko already has tokens and ledgers, but ledger archives still need to demonstrate the same scaling ambition as the rest of the stack. That is not a footnote. A successor to the SNS must preserve more than current ownership; it must preserve the history that makes ownership auditable.
The archive layer should be treated as a first-class distributed data system: append-only, verifiable, horizontally partitioned, efficiently indexed and compatible with standards such as ICRC-3 for authenticated transaction retrieval. IcyDB and Canic give Toko unusually strong foundations for solving this. Historical blocks can be partitioned across managed canisters while SQL-backed indexes make large histories genuinely useful rather than merely retained.
Solving archives at scale would complete an important triangle: live balances, programmable state and permanent verifiable history.
Successor does not mean replacement by decree
The SNS has earned trust through standardisation, transparent governance and NNS-approved code. Toko will have to earn the same trust. An embedded SQL database is powerful, but decentralisation does not come automatically from putting a database in a canister. Toko will need deterministic execution, reproducible builds, stable upgrade guarantees, open interfaces, independent audits and governance that cannot be captured by its original developers.
If it achieves that, Toko does not need to attack the SNS to supersede it. It can support SNS projects first: hosting richer application state, introducing programmable assets, scaling their services and providing compatibility with their existing ledgers. Over time, more of the economic and governance surface can move into Toko until the distinction becomes obvious.
The SNS proved that an Internet Computer application could become a community-owned network.
Toko can take the next step: making that network a scalable, queryable and programmable economy—where every asset can carry state, every community can govern at the right level, and every existing balance can move forward without losing its history.
That is why Toko is not simply an alternative to the SNS. It could be its natural successor.
Oh well