Scope boundaries

Syntarie's scope is bounded on purpose. This page is the canonical answer to "why doesn't Syntarie do X?"

What's in scope (settled)

• Proof-of-Authority consensus with a permissioned, known validator set.
• Checkpointed finality with bounded reorg depth (FINALITY_K).
• Native, capability-gated Rust contract classes — currently four production classes: Noop, Echo, PolicyEngine, Governance.
• Governed PolicyEngine DSL — a small typed AST evaluated bound under governance, NOT a generalized scripting environment.
• Single constitutional money module — MoneyContractV1 is the only mint/burn/redeem path. No alternate paths via composed intents.
• Private-first transaction submission — commit-reveal + selective disclosure with an explicit public opt-in.
• Genesis-capped supply — no post-genesis mint, no inflation, no redemption.
• Trusted-prover bridge to Base (single chain) — N-of-5 ed25519 quorum on Base side, faucet+address allocation at genesis.

What's explicitly out of scope (settled, not coming-soon)

• ❌ No EVM, no WASM, no general VM. Bounded native contract classes only. This is a settled design decision, not a backlog item.
• ❌ No deploy-anything contracts. Adding a new contract class requires a code change, governance approval, and a chain-stability re-verify.
• ❌ No generalized intent router across chains. The intent system composes within Syntarie; cross-chain happens through the bounded bridge only.
• ❌ No second native asset. No native stablecoin, no governance token separate from SCC.
• ❌ No additional bridge targets in v1. Base only.
• ❌ No public mainnet, no public token, no airdrop, no public validator sign-up (in the v1 scope).
• ❌ No CEX listings in v1. DEX (Uniswap on Base) only.
• ❌ No light-client bridge in v1. Trusted-prover only.
• ❌ No IVMS 101 / Travel Rule / MiCA compliance adapters in v1.

Three reasons the scope is bounded

Blast radius

In a consortium setting, the cost of a misbehaving contract falls on named operators, not anonymous users. Bounded classes make review tractable. A new contract class lands through governance, not a transaction.

Determinism

A small typed AST with bounded evaluation is dramatically easier to prove deterministic across a validator set than an opcode VM with gas-metering corner cases. We deliberately gave up "Turing complete" for "every node agrees on the same output every time."

Honesty

Writing down "we do not ship a general VM, here is the scope we do ship" turns a vague aspiration into a settled decision. We don't have to litigate it every sprint.

Implications for users / integrators

• You cannot deploy your own contract to Syntarie. If you need that, use Ethereum or a chain that ships an open VM.
• You can use the four contract classes through the intent system. PolicyEngine in particular is expressive enough for most consortium use cases (whitelists, time-bounds, multi-sig conditions).
• Cross-chain transfers go through the trusted-prover bridge to Base only. There is no "deploy a wormhole adapter" path.
• Your tokens are not custodial. Self-custody only — Syntarie servers don't hold keys.

Implications for the protocol team

• No surprises. The scope is locked in docs/decisions/v1-scope-lockdown.md in the source repo. Adding anything new requires explicit project-lead amendment + governance ratification.
• Pre-v1 sprints route only against this scope. Anything outside it is post-v1 territory.
• Audit reports cite this doc as the authoritative scope reference.

Where this fits

Source

docs/decisions/v1-scope-lockdown.md in the Syntarie source repo. The amendment log records every change to this scope; the current scope is locked as of 2026-04-21.