Safety controls
Joltzu layers wallet review, network eligibility, account authorization and ledger debit checks. Passing one layer does not bypass the others, and validators enforce every network layer whichever wallet submits the transaction. Safety first summarizes the approach; this page explains each control.
Fund energy
When enabled for an asset in genesis, incoming credits gain movement capacity with finalized protocol time. For credit c, credited time t, full-energy duration T and already consumed amount d, the ideal linear allowance is max(0, floor(c * min(1, max(0, (now - t) / T))) - d).
The node conservatively buckets credits with width ceil(T / 8) and at most nine active lots per owner/asset. A bucket is dated at its end, so grouping can delay release. Existing balances at activation are fully energized. Protocol time comes from agreed block timestamps; local clocks never age funds. Fully energized funds are consumed first, then active lots oldest-first.
Up to 64 exempt holders can be named per asset in genesis. No Council, service or runtime authority can add or remove one later. A transfer gives its recipient fresh credit. Certain native service positions record the owner's energized principal so a return to that same owner can restore that age; interest and payouts to other owners remain fresh. Genesis exemptions are fixed trust decisions. Energy applies to fee reservation too.
A 60-minute full-energy duration is an illustrative setting, not a confirmed launch parameter. The default devnet need not enable energy. joltzu_getFundEnergy reports the configured profile and its current allowance, not every lock or obligation.
What energy does not do
Fund energy buys time to detect and restrict stolen funds before they move on. It cannot stop the theft of already energized funds, or an attacker who waits out the schedule. It can also delay legitimate payments and liquidations, so applications must plan for it.
Outflow limits and voluntary locks
Replenishing budgets cap debits independently of energy. Splitting a transfer does not create extra capacity. Owner-created time locks last up to one year. They may be extended but cannot be released early by the owner, guardians or Council.
A top-level transfer refused by a lock, fund energy or an outflow budget pays its full gas limit, so check allowances before sending.
Fail closed
Safety records are never silently skipped. Malformed outflow or lock records abort execution rather than disabling a restriction, and inconsistent safety records are treated as corruption, never as a fresh install. Genesis refuses code at reserved precompile and native-service addresses. When genesis enforces code eligibility, every deployment, including factory CREATE/CREATE2, must use an admitted runtime hash, so a proxy can only delegate to admitted code.
Separated authority in the current node
| Authority | Current role | Boundary |
|---|---|---|
| Owner/account policy | Exact spending, grants and optional recovery | Still subject to ledger restrictions |
| Guardians | Delayed signer replacement | No spending authority |
| Security Council | Expiring per-asset outflow budgets | No arbitrary balance edits, minting, code repair or network pause |
| Issuer committee | Holds, permissions and listing state for its non-JOLT asset | Cannot control JOLT or another issuer's asset |
| Code-admission committee | Runtime eligibility for future deployments | Does not rewrite deployed state/code |
| SAFU committee | Funded claims from SAFU reserves | No access to unrelated balances |
The Security Council is a fixed genesis roster of 3–16 equal-weight keys. It acts only with more than two-thirds of the whole roster, absent members included. Its authorizations expire within one hour and its restrictions within 24 hours; each action binds the chain, a sequential nonce and the complete budget. The SAFU, issuer and code-admission committees use the same more-than-two-thirds rule.
Wallet screening can be overridden only according to wallet policy. It cannot waive a consensus eligibility rule. ## Proposed, not implemented
AI-initiated holds and incident tracing, bonded reports, pre-arranged outflow allowances, bridge registries, account-group outflow limits, Council asset-listing approval and wider incident-response powers are proposals. None is authority granted by the current Council endpoint. Committee sizes and limits above are development defaults, not governance decisions.