Phase 1 · Now
Research
Algorithm exploration, formal verification of consensus properties, hardware-aware design for what a Xyress-native substrate should be. No production code yet.
The technology
The substratebeneath the realm.Built to outlast it.
The realm runs on a hardened, production-class consensus and execution substrate today, with a parallel research track toward a native Xyress substrate by Phase 3. Four deployment modes and an identity-first access model. Beyond them, a path toward a trust chain where AI participates as accountable infrastructure, not as a replacement for cryptography.
Where the realm runs today
A hardened substrate, chosen on purpose.
Building from scratch ships nothing for years. Adopting a generic L1 fights the architecture you need. Xyress took the third option: a production-class consensus and execution substrate hardened by years of adversarial reality, forked deeply, with realm-specific architecture built on top.
What we kept. What we changed.
The substrate is in active use across hundreds of chains and securing tens of billions in assets today. We kept what production has already hardened: the consensus engine, the validator economics, the cross-chain communication primitives.
We changed what had to change for the realm to exist: identity is no longer an opt-in, it’s the substrate; access is no longer ambient, it’s enforced; AI is no longer a callable external service, it is a participant. These are not patches. They are forks at the architectural level.
Technical disclosure
We are direct about the specific substrate technology in technical conversations under appropriate framing. On a public webpage, naming the upstream project we forked is a strategic disclosure decision, not a transparency one. Partners and technical reviewers receive the full architectural detail in person.
Where the realm is going
A native substrate, built for what’s next.
Phase 1’s substrate is the right choice for shipping in Year One. It is not the long-term architecture we intend.
Parallel R&D track
From research today, to running by Phase 3.
A parallel research track designed from the consensus algorithm up around Xyress’s actual requirements, not retrofitted from a general-purpose chain. Three stages, sequenced to avoid the trap most “build it from scratch” projects fall into: shipping nothing for years. The native track runs alongside production, never blocking it.
Phase 2 · Next
Prototyping
Working prototypes of the consensus engine and execution layer. Public testnets running both substrates in parallel. Platform logic abstracted so it runs unchanged on either.
Phase 3 · After
Migration
Native substrate goes live. Coordinated cutover preserving all state, identity, and history. The Phase 1 substrate becomes the historical foundation; the native substrate becomes the floor.
How the realm deploys
Four modes, one architecture.
Different actors need Xyress in different shapes. Four modes cover the actual range of needs, and they are interoperable, so actors can move between them as needs change.
Mode 01
Public chain
Direct participation in the shared substrate. Your system sits alongside every other system on the public chain and benefits from shared liquidity, shared identity, shared everything.
When
Default for everyone who doesn't have a specific reason to need otherwise. Startups, builders, public infrastructure.
Give up
No data isolation. Public state is, by definition, public. If your data cannot live on a public chain, this is not the mode for you.
Mode 02
Managed enclaves
On-demand permissioned environments isolated for a single customer or consortium. Same platform capabilities, private operation. Data stays in the enclave; the substrate provides the cryptographic guarantees.
When
Regulated industries, sensitive workloads, internal pilots. When data isolation is a hard requirement.
Give up
Some shared-network benefits. Discoverability and shared liquidity are constrained by enclave boundaries.
Mode 03
Federated chains
Multiple independent chains under a shared root of trust. Each chain has its own state, governance, and policy; the federation provides cross-chain identity and proof. Sovereignty within sovereignty.
When
Multi-jurisdictional consortia, federations of institutions, scenarios where multiple parties need their own chain but a shared trust fabric.
Give up
Operational simplicity. Each chain is real infrastructure to run. Worth it when the federation matters; overkill when it does not.
Mode 04
Bridged proofs
Existing systems remain where they are; cryptographic proofs of their state are anchored on-chain. The system itself does not migrate; its trust does.
When
Existing infrastructure that cannot or should not migrate, but needs to be verifiably part of Xyress. Legacy systems, off-chain workloads, regulated databases.
Give up
Native platform capabilities. The bridged system gets verifiable trust, but Synod, Charter, Commons, and the rest only operate on what's on-chain.
Who can do what
No ambient access. Identity-first.
Most chains let anyone read everything. The realm does not. Three tiers of access, each governed by what the caller can prove about who they are. This is designed in from the substrate up, not bolted on as a security feature.
Tier 01
Guest
Public state · rate-limited
Anonymous human readers can view public realm state without holding a Sigil. Xyress remains observable to journalists, researchers, regulators, and curious newcomers. Reads are rate-limited to prevent extraction and abuse.
Tier 02
Resident
Sigil-bound · full participation
Human residents hold a Sigil and participate fully. Read, write, transact, hold assets, run agents, contribute to governance. The Sigil tier they choose, whether pseudonymous, verified, or proof-of-personhood (PoP)-bound, determines what surfaces are available.
Tier 03
Non-human caller
Sigil-required · including read
AI agents, automated workflows, web2 systems, web3 systems, devices. Every non-human caller must hold a Sigil for any interaction with the platform, including read. Machines do not get anonymous access. This is the rule that makes accountability for non-human actors enforceable.
Phase 3 · Long horizon
An AI-augmented trust chain. Carefully defined.
Phase 3 introduces a trust chain in which AI participates in consensus operations as accountable infrastructure. This is the most-misquoted thing the project will ever say, so we say it precisely. AI does not replace cryptography. AI does not control consensus. AI participates in bounded, attributable, governable ways, and the cryptographic core of the substrate remains the source of truth for finality.
It is
AI as accountable participant: contributing to consensus operations under cryptographic constraints, with every action attributable to a Sigil-bound agent and verifiable through Witness.
It is
AI under human governance in the loop: bounded authority, escalation paths, override mechanisms. The realm decides what AI is allowed to participate in, and that decision is itself on-chain.
It is not
AI replacing cryptography. The deterministic cryptographic core is preserved. AI augments what the chain can reason about; it does not become the chain.
It is not
AI making decisions outside human control. Every AI participant has a Sigil, an authority scope, and a governance handle. None of those are optional.
Where to go from here
Above, beside, around.
The substrate is the floor. The realm is what stands on it.
The conversation about what gets built next starts here.
Technical depth on request. Strategic conversations under appropriate framing. Either way, the people building Xyress would rather be talking to you than talking past you.