Joltzu Service Network (JSN)
JSN performs work outside ledger execution: producing randomness proofs, submitting scheduled callbacks, collecting subscriptions and distributing signed application data. JSN services run separately from validators; service delays do not replace or control consensus.
| Service | Current reference implementation | Guide |
|---|---|---|
| VRF | Paid requests, proof verification, authenticated callbacks and expiry refunds | Randomness |
| Keepers | Paid one-shot calls requested by a contract; worker scheduling and retries | Keepers |
| Subscriptions | Native/ERC-20 plans, subscriber caps and funded automatic renewal | Subscriptions |
| SigNet | Public temporary EIP-712 envelopes, replication and optional sponsored on-chain announcements | SigNet |
| Risk proposals | Evidence-backed proposals with separately approved native council action | AI and tools |
| Application hosting | Planned hosting for approved Studio artifacts | Hosting runtime remains release scope |
Trust and availability
JSN is distributed, not decentralized: one operator is proposed to run it at launch. Consensus never depends on it. Validators recheck every transaction or proof JSN submits, so a compromised JSN operator can delay or withhold service but cannot bypass account policy, fund energy, outflow budgets or locks. Applications that need independence can verify state proofs or run their own node instead of trusting JSN's answers.
Multiple funded worker lanes provide capacity and failover; they do not establish a decentralized threshold VRF. The proving identity is separate from transaction worker keys. Contracts check proof validity, callback sender, expiry and replay state.
Predicate/event-triggered jobs, holdings-based SigNet capacity and application hosting remain planned features. The current service implements one-shot scheduled callbacks and SigNet envelopes with a 30-day maximum expiry and namespace limits. Those differences are recorded in the relevant guides. Do not assume roadmap features are active API behavior.
EVM and native transports
RPC_MODE=evm uses Ethereum-compatible call, log, nonce, transaction and receipt methods. RPC_MODE=native uses cpp-node JZTX submission, proof-backed storage reads and authenticated receipt/log history, with runtime bytecode pinning. It does not assume eth_call support. The client trusts its configured node; it is not a consensus light client.
Public coordinator, SigNet, subscription addresses and public JSN service availability remain unconfirmed. See deployment and operations and the HTTP API for requirements and request templates.