SWSS Chain was built to produce a legally credible Finality Certificate for a real-world asset settlement, and to protect that settlement with zero-knowledge privacy and on-chain identity operating at the consensus layer. All three are properties of the protocol, decided at the moment of settlement rather than added above it.
Protocol research began in 2019, and what it produced is not a chain with features attached to it. It is five layers that a single settlement traverses in a fixed order, every one of them operating at or beneath the point where a transaction becomes final. Consensus certifies. Privacy proves. Identity qualifies. DEED-1 carries the instrument. The products sit above all four and settle through them without exception, because there is no path that goes around them.
That architecture runs on two live networks — SwssChain mainnet 122605 and SwssChain testnet 122606 — under the same protocol version, and every product in the SWSS ecosystem settles through the same four layers beneath it. The scale of the system is not the number of products above the line. It is that none of them are permitted their own settlement path.
Architecture At A Glance
Every value below is published once to the shared ecosystem record and read from it at render, so this page, swss.io and the developer documentation cannot state a different one. None of them is written into this document, and a reader who wants to check a protocol version should ask the network rather than any page that reports it.
Five-Layer Settlement Architecture
swss layers list --stack
The line down the left is one settlement passing through all five. The layers were built separately and are described separately, but they are not selectable: a deed acquires its certificate at L1, its confidentiality at L2, its legal standing at L3 and its instrument at L4, and an application at L5 that wanted a cheaper route would have to leave the chain to find one.
The five layers are described separately below because they were built separately, but they are not selectable. A deed settlement acquires its certificate at L1, its confidentiality at L2, its legal standing at L3 and its instrument at L4, and an application at L5 that wanted a cheaper route would have to leave the chain to find one.
What Runs Today, On Both Networks
swss net status --all
The testnet is a rehearsal rather than a different system, and the reason is the node above: both networks run the same protocol version, reported by the running client rather than asserted here. A network that answers a version query is a fact; a version printed in a document is a claim.
A description of an architecture is a design document. What follows is a deployment record: each layer, what is running on SwssChain mainnet 122605 and SwssChain testnet 122606, and where a party that trusts nothing in this document can confirm it. Both networks run the same protocol version, which is the property that makes the testnet a rehearsal rather than a different system.
| Layer | Deployed And Operating | Where It Is Verified |
|---|---|---|
| L1 — Consensus | SCP v3.1.4 producing blocks on both networks at 1 second, with a Finality Certificate emitted by consensus for every deed transaction. The running client reports its own version, so the protocol version is a property of the network rather than a claim in a document | swssscan.swss.io |
| L2 — ZK Privacy | SCP-ZK v3.3.0 proof verification and the on-chain nullifier registry, live at the protocol layer on mainnet. A verifying key is fixed at deployment and a spent nullifier can never be presented twice | swssscan.swss.io |
| L3 — Identity | SWSS IVL v1.4.3 credential issuance, the Foundation-governed provider registry and three-tier deed record access control, operating at the consensus layer rather than as an application above it | Identity Layer |
| L4 — Settlement | DEED-1 as Type 0x03 SCP Transactions, with the deed contract deployed on both networks and every settled record queryable by class | swssscan.swss.io |
| L5 — Governance | The validator governance contract is deployed on both networks and already carries an executed proposal history. The validator-facing module opens inside SWSS NodeX alongside the ecosystem applications; the mechanism itself is running now | swssscan.swss.io |
| L5 — Applications | Product contracts and interfaces across the SWSS ecosystem, each settling through Layers 1–4. A product that has not launched has no settlement path of its own waiting for it — it joins this one | Ecosystem |
No counts, heights or cumulative totals are printed here. A block height is wrong the second after it is written, and Ecosystem Performance sets out why this document reports where a figure is read rather than what it said on the day the page was edited.
The Settlement Path Of A Single Deed
swss tx trace --type 0x03
Five layers, one transaction, Sub Second finality — and no stage of it is optional to the product that submitted it. Where the settlement requires confidentiality, its proof is verified at L2 and its nullifier written in the same transaction, so the record is established without disclosing who established it.
The clearest way to see that the layers are one system is to follow one transaction through all of them. A deed settlement is submitted to the network as a Type 0x03 SCP Transaction carrying its asset reference, its legal owner, its jurisdiction code and its institutional signature. SAPE classifies it by asset type before block assembly begins and assigns it to the dedicated first-position lane — a classification that is deterministic, not configurable, and not purchasable by fee.
DSA then fixes its position mathematically, before block production starts and irreversibly once the round concludes, so no node can reorder it afterwards and front-running is prevented architecturally rather than discouraged. PCA has already pre-assembled the candidate block, which is what allows 1 second production to hold while the two stages above it complete their work before the block is produced rather than after. SCP then attests the result through its finality pillar and emits the Finality Certificate: the artefact that makes the settlement legally citable rather than merely recorded, produced by consensus because an application above consensus cannot certify what consensus has not yet finished deciding.
swss tx trace --private
This is the same settlement path as above with one difference, and the difference is what the nullifier is for. Replay is not discouraged and not detected afterwards — a spent nullifier cannot be presented a second time, so the same proof cannot establish the same thing twice. The verifying key is fixed at deployment, which is what stops the check itself from being changed later.
Where the transaction requires confidentiality, its proof is verified at L2 and its nullifier written to the registry in the same settlement, so ownership or compliance is established without disclosing who established it and the same proof can never be presented again. The credential that qualified the party came from L3, and the record that results is a DEED-1 instrument at L4, indexed and queryable through the Deed Indexer. Five layers, one transaction, Sub Second finality — and no stage of it is optional to the product that submitted it.
EVM Cancun Compatibility
swss evm features --cancun
Compatibility here means the Cancun execution feature set and the standard tooling that depends on it — which is what determines whether an existing contract, audit process or wallet works against SWSS Chain unmodified. It is not a claim to have adopted every element of that fork, and the exclusion is drawn rather than omitted: a capability list that quietly leaves things out is a list a reader cannot rely on.
Compatibility here means the Cancun execution feature set and the standard tooling that depends on it, which is what determines whether an existing contract, audit process or wallet works against SWSS Chain without modification. It is not a claim to have adopted every element of that fork: SWSS Chain does not implement blob-carrying transactions, which serve rollup data availability and have no role in settling a deed.
| EVM Cancun Feature | Relevance to RWA Settlement |
|---|---|
| Transient Storage (EIP-1153) | Efficient temporary settlement state, improving deed transaction throughput |
| MCOPY Opcode (EIP-5656) | Efficient on-chain data handling for complex deed metadata |
| Warm COINBASE (EIP-3651) | Reduces settlement computation overhead |
| Full Solidity Compatibility | All established audit firms can review contracts using standard tooling |
| Existing Tool Support | All standard wallet and developer infrastructure compatible from day one |
Connecting To The Network
Both networks are open and require no application, no key and no relationship with SWSS to read. The endpoints below are stated as values to configure rather than as links, because a JSON-RPC endpoint answers a remote procedure call and not a browser.
| Network | Chain ID | JSON-RPC Endpoint | Explorer |
|---|---|---|---|
| SwssChain Mainnet | 122605 | swssrpc.swss.io | swssscan.swss.io |
| SwssChain Testnet | 122606 | testnet.swssrpc.swss.io | testnet.swssscan.swss.io |
Because the execution layer is EVM Cancun compatible, standard wallets and development frameworks connect to either network with nothing more than the chain ID and the endpoint above, and an existing Solidity contract compiles and deploys unmodified. Integration guidance is maintained in SWSS Docs.
What This Architecture Does Not Claim
A section that sets out what an architecture guarantees is read more sceptically than one that sets out what it does, and it should be. So the limits are stated here rather than left for a reader to discover. SWSS Chain does not implement blob-carrying transactions (EIP-4844) or the beacon block root (EIP-4788); block headers carry neither, and neither has a role in settling a deed. Compatibility is scoped to what determines whether existing contracts, audits and wallets work — not to every element of the fork that shares the name.
Nor does this section publish governance parameters, validator counts or settlement totals. Those are properties of the running network that change without an edit to this document, and a figure printed here would be a snapshot presented as a specification. Where any SWSS document disagrees with what the chain returns, the chain is correct. Risk Factors sets out the risks that apply across the ecosystem, and nothing in this section is a forecast, a target or a promise of return.
What are the five settlement layers?