Definitions for the Soroban/Stellar and security concepts used throughout the
Sanctifier docs. Every term has a stable anchor so findings, reports, and
other pages can deep-link to it — e.g. glossary.md#require_auth or
glossary.md#oog-out-of-gas.
This page is part of the core documentation set. Finding codes referenced below are listed in Finding Codes, and each has a full write-up (vulnerable example + fix) in the Detector Catalog.
Sections: Platform · Authorization · Storage & ledger · Resources & cost · Code-safety · Contract lifecycle · Verification · Tooling
An open-source, public blockchain network for payments and asset issuance. Soroban is Stellar's smart-contract platform. See stellar.org.
Stellar's smart-contract platform. Contracts are written in Rust, compiled to WASM, and executed by the Soroban host. See soroban.stellar.org.
WebAssembly — the bytecode format Soroban contracts compile to (target
wasm32-unknown-unknown). Sanctifier analyzes Rust source, not compiled
WASM; problems that only surface when building for wasm32 (e.g. a non-no_std
dependency) are build issues, not Sanctifier findings.
Program deployed on-chain whose code deterministically governs state
transitions. On Soroban, a Rust module annotated with #[contract] /
#[contractimpl].
Capabilities the Soroban host exposes to a contract (storage, crypto, auth,
cross-contract calls), accessed through the soroban_sdk::Env handle passed to
contract functions.
A Rust crate that does not depend on the standard library. Soroban contracts are
no_std; a dependency that requires std will fail to build for wasm32.
Establishing who is making a call (which address). Distinct from authorization.
Deciding whether an authenticated caller is allowed to perform an action. In
Soroban this is enforced with require_auth.
Soroban host call (Address::require_auth / require_auth_for_args) that asserts
the given address authorized the current invocation. Omitting it on a
state-mutating function is an authorization gap (S001).
A privileged or state-mutating function that changes state without calling
require_auth, allowing unauthorized callers to act. Detected as
S001.
A function whose effects (minting, upgrading, changing config) should be
restricted to a specific admin address. Must be guarded by
require_auth.
Soroban Address — identifies an account or a contract. Used as the subject of
require_auth and as the holder in token operations.
An admin address or secret literal embedded directly in source instead of being
configured/stored. Brittle and a security risk; detected as
S012.
The replicated state of the network at a point in time. Contract data lives in ledger entries.
A single unit of stored on-chain state (a key/value record a contract reads and writes). Subject to a maximum size.
The maximum byte size of a single ledger entry. Sanctifier models this as
ledger_limit (default 64000) and flags state
approaching or exceeding it (S004).
Soroban classifies stored data by lifetime: Instance, Persistent, and Temporary. Choosing the wrong durability wastes rent or risks unexpected archival.
Storage tied to the contract instance itself; loaded with the contract. Best for small, always-needed config.
Long-lived per-key storage that survives across invocations and must be kept alive via TTL bumps. Best for user balances and durable records.
Short-lived storage that can be archived/expired cheaply. Best for ephemeral data (nonces, short-term caches) to reduce cost and OOG risk.
Soroban reclaims entries whose time-to-live expires; contracts "bump" the TTL to keep persistent data live. Forgetting to bump can make data inaccessible.
Two logically distinct pieces of state mapping to the same storage key, so one
overwrites the other. Detected as S005.
Soroban meters CPU instructions and memory per invocation against a budget. Exceeding the budget aborts the call (OOG).
An invocation that exhausts its resource/CPU budget and aborts. Driven by
oversized state, unbounded loops, or expensive operations. Sanctifier's
ledger-size and resource heuristics (S004) surface the common
causes.
The metered number of CPU instructions an invocation executes; a primary component of the resource budget.
The set of ledger entries an invocation declares it will read/write. An accurate, minimal footprint keeps cost and risk down.
An unrecoverable Rust abort (panic!, or via unwrap/expect).
In a contract this traps the invocation. Detected as S002;
prefer returning a Result/contract error.
Option/Result methods that panic on the absent/error case. Common
source of avoidable contract aborts.
A function call returning a Result whose value is ignored, so an error path is
silently dropped. Detected as S009.
An integer operation that exceeds the type's range, wrapping or panicking.
Unchecked arithmetic in value/balance math is dangerous; detected as
S003.
Safe arithmetic methods: checked_* returns None on overflow (handle
explicitly); saturating_* clamps to the type bound. Preferred over raw +/-/*
in contract math.
Guards on token operations such as amount > 0 and from != to. Missing these
allows no-op or self-transfer abuse; detected as S013.
A vulnerability where a contract is re-entered (often via a cross-contract call) before its first invocation finishes, observing inconsistent intermediate state. Mitigated with checks-effects-interactions ordering and runtime guards.
Rust code that opts out of compiler safety guarantees. Rare and discouraged in
contracts; flagged generically as S006 and a common target for
a custom rule.
Unreachable code or always-true/false guards (e.g. detectable via constant
folding). Detected as S015; often signals a logic mistake.
Duplicate or inconsistent discriminants in a #[contracterror] enum, so distinct
errors are indistinguishable on-chain. Detected as S016.
A log record a contract publishes (topics + data) for off-chain consumers.
Inconsistent topic counts or wasteful patterns are detected as
S008.
Replacing a deployed contract's WASM (e.g. via
update_current_contract_wasm). Powerful and
risky; upgrade/admin mechanisms are analyzed for S010.
The Soroban host call that swaps a contract's code. Must be tightly authorized and paired with safe post-upgrade initialization.
A one-time init step that sets required state (admin, config). An upgrade
mechanism without an init path is an upgrade risk
(S010).
A contract implementing fungible-token semantics (balances, transfers, mint, burn). The subject of Sanctifier's built-in invariants.
Creating (mint) or destroying (burn) token units. Must be authorized and
conserve supply; unauthorized mint is a classic exploit
(see no_unauthorized_mint).
One contract invoking another (env.invoke_contract). Edges are extracted by
sanctifier callgraph; a vector for
reentrancy.
A directed graph of cross-contract calls, emitted as Graphviz DOT by
callgraph, used to reason about trust boundaries.
A property that must always hold (e.g. total supply is conserved). Declared with
#[sanctify::invariant(EXPR)] and checked by
verify; a refuted invariant is
S011.
Mathematically proving (or refuting) that code satisfies a specification, rather than testing samples. Sanctifier uses SMT and optionally Kani.
Satisfiability Modulo Theories — the technique behind automated proof of arithmetic/logic properties. Sanctifier dispatches pure-function invariants to the Z3 SMT solver.
The SMT solver Sanctifier links for verify and
prove. Requires the Z3 C headers at build time — see
the FAQ.
A Rust model checker for deeper, function-call-level proofs. Complex invariants
are reported as KANI ↗ with a reminder to run cargo kani.
An on-disk artifact recording the result of an SMT proof, written by
prove (skip with --no-save).
Built-in token invariant: total supply is unchanged by transfers. Provable via
sanctifier prove --invariant supply_conserved.
Built-in token invariant: no account balance can become negative.
Built-in token invariant: tokens cannot be minted without proper authorization.
The public parameter a zero-knowledge proof (e.g. Groth16) is checked
against — derived from the circuit during trusted setup. If it isn't pinned
(hardcoded, hash-checked, or gated behind admin require_auth()), whoever
controls it controls what "a valid proof" means; see
vk_provenance.
Analyzing source code without executing it. Sanctifier's analyze parses Rust to
find security-relevant patterns.
A stable identifier (S001…S016) for a class of finding, shared across CLI and
JSON output. See Finding Codes.
The seriousness of a finding. Sanctifier groups results into critical and
high for exit-code purposes; custom rules
accept info, warning, or error.
A reported finding that is not actually a problem. Static analysis is conservative and produces some; handling strategies are in the FAQ.
A real problem the analyzer did not report. Why Sanctifier complements, but does not replace, audits and tests.
A reviewed reference output (insta snapshot) each detector is tested against, so
its findings cannot change unnoticed. See
tooling/sanctifier-core/tests.
A user-defined regex check configured under
[[custom_rules]]; matches are reported as
S007.