Sector9 - Neutrinite DAO

Developers
1

Whitepaper: sector9_wp/sector9.pdf at main · Neutrinomic/sector9_wp · GitHub

Tweet: https://x.com/anvil_ic/status/2009261583185150002

I’d be happy to hear your thoughts.

Some simplified benefits of this architecture:

  • The IC can support orders of magnitude more tokens and transfers than systems like pump.fun, Solana, or even all blockchains combined, because every inter-canister call can safely batch hundreds of token transfers or swaps without centralized ledgers or bottlenecks.
  • You can build large-scale protocols composed of hundreds of independent canisters without today’s fragility, because upgrade behavior and cross-canister guarantees are explicitly verified rather than implicitly trusted.
  • AI agents can be given broad autonomy without losing control, because their code is constrained by formally verified contracts—allowing aggressive automation while guaranteeing critical invariants can’t be violated.

QnA from chat:

Q: What if a contract is underspecified and leaves room for cheating?
A: Then the underspecification is publicly visible in the verified contract, so nobody relies on it accidentally.

Q: How do you remove all wiggle room?
A: By making functions immutable and hashing their AST, freezing semantics across upgrades.

Q: Can only part of a canister be immutable?
A: Yes—functions, modules, or protocol surfaces can be pinned independently.

Q: Are hashes based on Wasm?
A: No—hashes are based on the AST, so compiler versions don’t affect them.

Q: Does a canister have both a Wasm hash and a contract hash?
A: Yes, plus a tree of hashes for immutable subsets and invariants.

Q: How do I know the Wasm actually matches the published contract?
A: The canister cannot deploy or upgrade without passing the verifier.

Q: What prevents uploading a different Wasm after verification?
A: Every deploy and upgrade must go through the verifier gate.

Q: How do I know a canister used Sector9 at all?
A: It carries certified metadata and a cryptographic attestation from the verifier.

Q: Do clients need to query a registry to verify this?
A: No—attestations are self-contained and verifiable with public keys.

Q: Is deployment going thru the DAO?
A: Initially yes via the verifier gate, but governance and future self-checking upgrades remove controller risk.

Q: Can I publish a spec and let others implement it independently?
A: Yes—contracts can act as APIs that multiple canisters implement and verify.

Q: Why is this powerful for DeFi?
A: Immutable token semantics enable single-call transfers and swaps without ledger bottlenecks.

Q: Why is this powerful for AI development?
A: AI can scan verified contracts to understand services instantly, without reading source code.

Q: Does this depend on the security of a TEE?
A: Only initially. TEEs are used to bootstrap trust; over time, verification can be performed by a network of independent verifiers using a consensus mechanism. Immutable functions can also be verified directly by a canister to an extend, since they don’t require heavy computation like Viper-SMT or TLA+.

15 Likes
2

I am not able to judge about the whole proposal and I think it is better to let other folks have a more critical look at Sector9, but it sounds very interesting - thanks for sharing! :slight_smile:

this sounds awesome!

just one question from my side without reading about all the details yet:

  • who controls the verifier gate? couldn’t this be compromised and thus still allow upgrading all parts of a canister in worst case scenario?
2 Likes
3

Thanks for your question!

The gate is a canister that relies on remote TEE-backed servers which attest to it. The verifier image they run must be explicitly accepted and governed. In our case, that governance is handled by the Neutrinite DAO. Multiple verifiers can operate in parallel, and as the ecosystem matures, governance of the verifier can be delegated to the NNS.

In theory, it can be made as secure as systems under NNS control—or even more so—because a canister only needs to be verified once, which means all subnets can verify it before it gets deployed.

4

It’s a pretty complicated system, the result is simple. Developers can write

import TokenProtocol "mo:pkg.."

actor {

immutable let tp = TokenProtocol();

//usage:
tp.transfer(..)
tp.balance(..);

Currently, the system is partially complete. We have the TEE-based attestation and gate in place, substantial portions of the language implemented, the Viper-based verifier, and Unison-style AST hashing. Protocol-level verification with TLA+ is planned but not yet integrated.

5

Quite interesting. Will give it a read. Interesting is that security over time does not solely depend on the TEE.

1 Like
6

Just to be clear, I am not proposing that everyone migrates to Sector9 or makes their canisters compatible with it. In a perfect world-maybe -but realistically, that’s far too much to ask and simply won’t happen. Sector9 fundamentally changes the application-layer architecture from the ground up. It will be used by us, and likely by others who want to experiment.

Neutrinite DAO’s decentralization can grow alongside it. DAOs need something meaningful to govern- that’s the whole point of their existence.

The whitepaper is currently a very high-level architectural overview, without many specifics. I suspect people aren’t taking it too seriously yet. Before AI, implementing something like this would have required ~5 years and a large team. That’s also what makes it interesting: we’re pushing the boundaries of what’s possible to build. I believe the time required has now dropped to around 6 months, and we’re already halfway there.

Early on, mostly immutable functions will likely be bulletproof, since the system behind them isn’t that complex. Monotonic functions are more complex: they require a perfectly sound verifier and very well-specified contracts to enable safe, trustless upgrades and guarantees the canister code will work within the contracts boundaries and can be trusted. DAOs will always be best suited for changing protocol parameters and deciding on future upgrades -this simply adds another layer.

You already see a basic version of this pattern on Ethereum: a DAO governs changes, new versions are deployed, the old contracts remain immutable and functional, and a new contract takes over going forward.

2 Likes
7

This sounds like an interesting idea. Basically it allows you to upgrade software within predefined boundaries that are verified for each upgrade, if I understand correctly?

As someone pretty new to ICP, I wonder whether there are actually systems yet where this is a real problem though? As in, are there any immutable systems where upgrades have become a huge pain (e.g. you already ended up with something like UniSwap v1, 2, 3, …)

8

Not just upgrade, it’s not the biggest part of it.
Once your contract gets automatically verified, you virtually enter ‘Sector9’ and other canisters can trust your contract artifacts. One of the things this enables is for them to communicate directly with single inter canister calls instead of having to search registries and use custodian canisters that provide guarantees.

I’ll try to give an example.

Canister A is governed by one entity.
Canister B is governed by another.

Currently, A sends tokens to B and expects B to send swapped tokens back. But if B becomes malicious, makes a mistake, or simply decides to change how things work after months, A may not get the tokens back. Canister A breaks.

Because this risk exists, not many people try to use contracts owned by another entity, so the network effect is ruined. This is why everyone ends up making their own DEXes and also they will likely end up duplicating everything else. There are almost no canisters on the IC that use other canisters, except for ledgers and governance canisters, because those are triple checked by everyone voting in the NNS and by Dfinity - after developing standards for years.

To increase safety between A and B, you can create a canister in the middle and blackhole it. This canister holds A’s and B’s tokens, and only if both are present does it swap ownership atomically. But if the ledger breaks something, that canister can stop working too.

And this is just the most basic form of communication. Complexity can grow much more if it can rely on a strong foundation. You also need many inter-canister calls to make this work, maybe around 12 at minimum when counting the ledger. This multiplies with each ledger.
For example, 100 tokens means about 1200 calls to swap them between A and B.

Sector9 allows you to do this with one call, which can include 100 tokens. So you end up with 1 call instead of 1200.

This is just an illustrative example using tokens. Improving tokenization is not the main idea.
You get more powerful communication that doesn’t need standards for canisters to be discovered, used and others to rely on them and layer on top of hundreds of protocols. Well, theoretically speaking.

2 Likes
9

X algo won’t let video posts reach anyone, so I’ll post an update in here too

1 Like
10

Would be interested to try this out. Seems very cool.

1 Like