Safety first
Most crypto losses come from stolen keys, deceived signers, malicious approvals and application bugs, not broken cryptography. Joltzu is designed around that fact. Protection lives in the protocol, so validators enforce it on every spending path, whichever wallet or application submits the transaction.
Three layers
- Prevent. Native account policies, bounded grants and code eligibility limit what any one signature can authorize.
- Contain. Fund energy slows newly received funds. Outflow budgets cap how fast an asset can leave. Voluntary locks cannot be released early.
- Respond. Separate committees each hold one narrow, expiring power. None can move user funds, pause the network or reverse finality.
No layer makes a malicious authorization harmless or guarantees recovery. Together they aim to turn a single mistake into a bounded, recoverable loss.
What the reference node enforces today
These controls are implemented as development profiles in the cpp-node reference node. Launch parameters are not decided.
| Control | What it does |
|---|---|
| Account policy | Multisig, passkeys and recovery at the same address. Policy applies to ordinary Ethereum-signed transactions too. |
| Bounded grants | Each grant has a per-transaction, daily and total budget and an expiry. |
| Guardians | Can only propose a delayed signer replacement. They never get spending authority. |
| Fund energy | Newly received funds gain movement capacity as they age. Up to 64 exempt holders are fixed at genesis; no authority can add one later. |
| Outflow budgets | Cap how much of an asset can leave over time. Splitting a transfer does not create extra capacity. |
| Voluntary locks | Owner-created locks of up to one year. They can be extended but not released early by anyone. |
| Code eligibility | When enabled in genesis, every deployment, including factory CREATE/CREATE2, must use admitted runtime code. |
| Security Council | Acts only with more than two-thirds of its whole roster, and can only set an expiring outflow budget. It cannot transfer, mint, remove locks, change code or pause blocks. |
| Fail-closed state | Malformed control records abort execution rather than disabling a restriction. Inconsistent safety records are treated as corruption, never as a fresh start. |
| Halt over fork | Consensus prefers stalling to finalizing conflicting blocks. A validator whose clock goes backwards stops signing until it catches up. |
Safety controls explains each mechanism, and accounts covers policies and grants.
How the node is built
The reference node is developed with bounded inputs, fail-closed storage and fault-injection testing:
- More than 2,400 unit and integration test cases, which stay active in release builds.
- Sanitizer build presets for address, undefined-behavior, thread and leak checking.
- A deterministic four-validator fault simulation, plus multi-process tests covering network partitions, crash and restart, signer timeouts, disk exhaustion and system clock steps.
- A standing rule not to relax a safety check or extend a deadline merely to make a test pass.
This is development evidence, not certification.
What is not established yet
Being safety first includes being clear about limits:
- No external security audit, bug bounty or penetration test has been completed. None is claimed for the node, the sale contract or any other component.
- The whitepaper's consensus proofs are written by hand, and its TLA+ checks cover bounded configurations of the design model, not the node's code.
- Wallet transaction simulation, phishing detection, AI-initiated holds, bridge registries and wider incident powers are proposals.
- Production key custody with slashing protection, production randomness and multi-host calibration are open launch work.
Check implementation status before relying on any feature.
Staying safe today
- Treat every network, address and date as unconfirmed until it comes with an announcement and a verified contract.
- Prefer grants with tight budgets and short expiries over open-ended approvals.
- Read the whole approval: recipient, amount, fee, expiry and chain.
- Builders should recheck authority and state at execution time, and never use
tx.originto identify a user.