WebSorobandocs v1
Open IDE

Docs

Glossary

The Soroban and WebSoroban terms used across these docs, defined precisely.

Definitions for the terms that appear throughout the docs. Each is one or two sentences; follow the links for the page that uses the term in context.

ScVal, the on-wire value form. Every argument you pass and every value a contract returns is encoded as an ScVal (Soroban contract value). WebSoroban encodes the plain values you type into ScVal for you. See Invoke.

ScType, a value's Soroban type, such as u32, Address, or Vec<u32>. The contract spec records an ScType for every argument, and the Invoke form picks an input control from it.

contract id, the address of a deployed contract instance. It starts with C (for example CDLZ…) and is created when you instantiate a contract from a Wasm hash. See Core concepts.

Wasm hash, the SHA-256 of an uploaded Wasm binary. Uploading the Wasm stores it on the network under this hash; many contract instances can share one hash.

spec, the contract interface extracted from the Wasm: its function names, argument types, and return types. WebSoroban stores the spec on deploy and renders the typed Invoke form from it. See Core concepts.

footprint, the set of ledger entries a transaction reads and writes, computed by simulation. An empty read-write footprint marks a call as read-only; a non-empty one marks it a write. See Invoke.

auth / require_auth, Soroban's authorization. A require_auth(&address) call asserts that address must sign the transaction; a function with auth entries is a write. See Invoke.

resource fee, the fee a write pays for execution and ledger I/O, in stroops. Simulation returns the minimum resource fee; the write pays it from your testnet wallet. See Invoke.

stroop, the smallest unit of XLM: 1 stroop = 1/10,000,000 XLM. Fees are denominated in stroops.

simulate, running a call against the network without submitting it, to get the return value, the footprint, and the resource fee. Reads stop here; writes simulate first, then sign and submit.

instance / persistent / temporary storage, the three Soroban storage durabilities. Instance data lives with the contract instance and shares its time-to-live; persistent data is long-lived and independently extendable; temporary data is cheap and expires on its own short schedule.

Next#