Protocol interfaces / Reproducible evidence
Build against the SOS public testnet
SOS exposes a live testnet, a browser wallet, a read-only explorer, signed node releases, and a byte-level technical specification. The most useful integrations start by pinning network identity and release versions rather than assuming an interface will never change before mainnet.
Public interfaces are testnet interfaces and may change with explicit release notes.
Specification
Interactive whitepaper V2
Releases
Signed GitHub artifacts
Network data
Explorer and JSON-RPC
Feedback
Public issue tracker
Start from the canonical specification
The V2 whitepaper documents consensus preimages, domain-separation tags, validator-set commitments, shielded note layouts, proof journals, tokenomics, and bridge boundaries. The interactive edition preserves the complete text while adding diagrams and narrated formula explanations.
Integrations should record the chain identifier, genesis hash, node release, bridge domain, contract address, and accepted proof image identifiers. Those values are part of compatibility, not deployment trivia.
Observe before you automate
Use the explorer to inspect blocks, supply, validators, claims, and transaction types. Use the wallet and faucet to create known test vectors. Once a workflow is understood, move to the documented RPC path and retain transaction hashes and block heights in integration tests.
- Treat testnet resets and version bumps as expected compatibility events.
- Never send recovery phrases, private keys, witnesses, or bearer tokens to an RPC service.
- Use domain-separated signing payloads exactly as specified.
- Report mismatches with a minimal reproducible test and redacted logs.
Publication and contribution model
The public organization is the source for user-facing releases, issues, and material intentionally published by the project. Some implementation repositories can remain private while the project protects unreleased work. A public artifact should therefore be judged by its signature, checksum, specification, and reproducibility evidence rather than by an assumed repository layout.
Questions
Common questions
Where is the canonical protocol description?
The V2 whitepaper is the canonical technical description. Release notes and genesis artifacts define the exact public testnet deployment.
Are testnet APIs stable?
They are versioned working interfaces, not a permanent mainnet compatibility promise. Integrations should pin and test the release they target.
How should a reproducible bug report be written?
Include OS, release, network identity, steps, expected and observed behavior, timestamps, and public transaction identifiers. Redact every secret.
Primary sources
Last reviewed: 2026-07-21