This glossary defines the Stellar, Soroban, and Accord-specific terms used throughout this repository's documentation, so contributors and users don't need prior blockchain experience to follow along. It covers four term families: Stellar network concepts (the underlying public ledger), Soroban platform concepts (the smart contract runtime Stellar provides), Accord protocol concepts (the multisig logic this project implements on top of Soroban), and analytics & indexer concepts (the off-chain event-indexing and treasury-reporting layer built on top of the contract). Where a term is explained in more depth elsewhere in the docs, a "See also" link points you there.
Ledger A ledger is the fundamental unit of state and time on the Stellar network, similar to a "block" on other blockchains. Validators close a new ledger roughly every 5 seconds, and each one has a sequence number and a closing timestamp. Soroban contracts read the current ledger's timestamp to make time-based decisions, such as checking whether a proposal's deadline has passed.
Stroop A stroop is the smallest indivisible unit of XLM, equal to one ten-millionth (0.0000001) of one XLM. Smart contracts and on-chain balances always work in stroops (or the equivalent smallest unit for other tokens) rather than fractional amounts, since computers can't represent fractional currency exactly. See also: Architecture §7 — Token Handling.
XLM XLM ("lumens") is the native digital currency of the Stellar network, used to pay transaction fees and to fund the minimum balance every Stellar account must hold. In Accord Protocol, XLM can also be the asset a proposal transfers, in which case its amount is expressed in stroops.
USDC USDC is a USD-backed stablecoin issued by Circle and available on Stellar as a Soroban token. A proposal can name USDC as its token so owners can move stablecoin funds, with amounts expressed in USDC's smallest base unit rather than whole dollars.
EURC
EURC is a Euro-backed stablecoin, also issued by Circle and available on Stellar, that works the same way as USDC for the purposes of a proposal — it's simply another Soroban token contract address supplied to create_proposal. Amounts are expressed in EURC's smallest base unit, not whole euros.
Horizon Horizon is Stellar's REST API server that indexes ledger data (accounts, balances, transactions, payments) so applications can query it without running their own node. Horizon serves classic Stellar data; Soroban contract calls instead go through a separate RPC endpoint (see Soroban RPC, below). See also: SETUP.md.
Friendbot Friendbot is a free faucet service on Stellar's testnet that funds a newly created account with starting testnet XLM, so developers don't need real money to test against. It only exists on testnet/futurenet — there is no equivalent on the public mainnet network. See also: SETUP.md.
Freighter Freighter is a browser-extension wallet for Stellar and Soroban that stores a user's keys and signs transactions on their behalf, similar to a wallet extension you might know from other chains. Accord's frontend uses Freighter so owners can authorize proposal actions (approve, revoke, execute) without ever exposing their private key to the web page. See also: Architecture §1 — System Overview.
Testnet The testnet is a public Stellar network that behaves like the real (mainnet) network but uses worthless test tokens, making it safe to build and experiment against. Accord Protocol is deployed to testnet during development, and Friendbot is used to fund test accounts there.
Stellar account address (G-address)
A Stellar account address — often called a "G-address" because it always starts with the letter G — is the public identifier for a Stellar account, derived from that account's key pair. Owners, proposers, approvers, and proposal recipients in Accord Protocol are all represented as G-addresses (Soroban's Address type).
Soroban Soroban is Stellar's smart contract platform: it lets developers write contracts in Rust that compile to WebAssembly and run on the Stellar network. Accord Protocol's multisig logic — proposals, approvals, execution — is implemented entirely as a Soroban smart contract. See also: Architecture §1.
WASM WASM (WebAssembly) is the compact, sandboxed binary format that Soroban contracts compile down to before deployment. Writing a contract in Rust and compiling it to WASM is what lets the Soroban host run contracts from many different developers safely, in a predictable, resource-metered way.
Soroban RPC Soroban RPC is the network endpoint frontends and tools use to simulate and submit smart contract calls, distinct from Horizon (which serves classic Stellar data). Accord's frontend talks to Soroban RPC, via the Stellar JS SDK, to read proposals and submit approve/execute transactions. See also: Architecture §1.
SCVal
An SCVal ("Soroban Contract Value") is the strongly-typed internal value format Soroban uses to represent every contract parameter and return value — numbers, addresses, strings, structs, and so on. Frontend code never builds SCVals by hand; helpers like nativeToScVal (below) convert ordinary JavaScript values for you.
XDR XDR (External Data Representation) is the binary serialization format Stellar and Soroban use to encode transactions, ledger entries, and contract values for transmission over the network. You'll run into XDR when inspecting raw transaction data or debugging a failed simulation, since errors are often returned as XDR-encoded structures that tooling then decodes into something readable.
TTL (time to live) TTL is the number of ledgers remaining before a piece of contract storage is automatically archived and becomes inaccessible until restored. Both instance storage and persistent storage carry their own TTL, and a contract must periodically extend ("bump") it to keep long-lived data like proposals and owner lists from expiring. See also: Architecture §3 — Storage Layout.
Instance storage Instance storage is a Soroban storage tier tied to the contract instance itself — cheap and well-suited to small, frequently-read values, but with a shorter default TTL than persistent storage. Accord Protocol keeps its initialization guard, approval threshold, next proposal ID counter, and active proposal count here. See also: Architecture §3.
Persistent storage Persistent storage is a Soroban storage tier meant for data that needs to survive long-term, with a longer default TTL than instance storage at a higher storage cost. Accord Protocol stores its owner list and every individual proposal (plus each owner's per-proposal approval flag) here. See also: Architecture §3.
TTL bump
A TTL bump is the act of extending a storage entry's remaining time-to-live so it doesn't expire and get archived. Accord's coding standards call for bumping TTLs on every storage read, which is why the contract's read paths call bump_instance / bump_persistent throughout.
See also: CONTRIBUTING.md — Coding Standards.
simulateTransaction
simulateTransaction is a Soroban RPC method that runs a contract call against current ledger state without submitting it on-chain, returning the result (and the resources it would consume) instantly and for free. Accord's frontend uses it for read-only calls like fetching a proposal, and as a dry run before sending a real, signed transaction.
See also: Architecture §1.
nativeToScVal
nativeToScVal is a Stellar JS SDK helper that converts an ordinary JavaScript value (a string, number, address, and so on) into the SCVal format a Soroban contract call requires. Frontend code calls it when building arguments for functions like create_proposal or approve before sending them to Soroban RPC.
Multisig Multisig (multi-signature) describes a contract or account that requires approval from more than one party before an action takes effect, rather than trusting a single key. Accord Protocol is a multisig contract: no single owner can move funds alone — a proposal must collect enough approvals first.
M-of-N threshold An M-of-N threshold means M approvals are required out of a fixed set of N owners before a proposal can execute — for example, "2-of-3" means any 2 of the 3 owners must approve. Accord Protocol stores this threshold as a single number set during initialization, and a proposal only becomes executable once its approval count reaches it. See also: Architecture §3.
Proposal A proposal is a single proposed action — such as a token transfer — that one owner creates and the others must approve before it can run. Every proposal has an ID, a proposer, a description, a deadline, and a status that tracks where it is in its lifecycle. See also: Architecture §4 — Proposal Lifecycle.
ProposalStatus
ProposalStatus is a proposal's current lifecycle state. The contract defines five values: Pending (created, not yet enough approvals), Ready (enough approvals, awaiting execution), Executed (successfully run), Expired (deadline passed before execution), and Revoked (a terminal "cancelled" state defined in the contract's types, though no function currently sets a proposal to it — calling revoke() only withdraws one approver's vote, which can drop a Ready proposal back to Pending, rather than cancelling it outright).
See also: Architecture §4.
Owner An owner is one of the addresses registered in the multisig’s owner-weight map. Ownership supplies voting weight for quorum and is required (together with the Approver role) to approve or revoke. High-privilege governance actions (upgrade, guardian, RBAC migration) still require owner-weight co-signatures, not roles alone. See also: RBAC & Access Control.
Role (RBAC)
A role is one of four operational permissions (Proposer, Approver, Executor, Viewer) stored per address. Roles gate who may draft, vote, execute, or be marked as a viewer; they do not replace owner-weighted quorum for security-critical governance.
See also: Roles & Permissions guide.
Proposer (role)
The Proposer role allows an address to call proposal-creation entrypoints (create_*_proposal). It is distinct from the proposal’s recorded proposer field: the role is a standing permission; the field is who created a specific proposal. Non-owners may hold Proposer and draft proposals; owner proposers still undergo spending-limit checks.
See also: RBAC gating matrix.
Proposer (proposal field) On a given proposal, the proposer is the address that originated that proposal. Their address is recorded on the proposal and emitted in its creation event. Holding the Proposer role does not auto-approve the proposal — Approver + ownership are still required to vote.
Approver (role)
The Approver role allows an owner to call approve and revoke. Non-owners cannot cast weighted votes even if they somehow hold Approver; weight always comes from ownership.
Approver (vote) An approver (lowercase usage in lifecycle docs) is an owner who has cast an approval vote on a specific proposal. The contract stores the weight credited for that approval so a later revoke can reverse the same amount.
Executor (role)
The Executor role allows an address to call execute and cancel_expired. This can be a human owner or an automated keeper that does not hold Approver or Proposer.
Viewer (role) The Viewer role marks an address for read-oriented access in product and policy terms. It does not unlock create, approve, or execute by itself.
DEFAULT_OWNER_ROLES
The default role set granted to every owner at initialize and by migrate_to_rbac: Proposer, Approver, and Executor. It preserves classic “owners can do everything” behaviour until roles are narrowed deliberately.
GrantRole / RevokeRole
Governance proposal kinds that add or remove a role for a target address. Created via create_grant_role_proposal / create_revoke_role_proposal, then approved and executed like other proposals.
migrate_to_rbac
A one-time, owner-weight-gated migration that grants DEFAULT_OWNER_ROLES to every current owner and sets the RBAC role_version flag. A second call is rejected and leaves state unchanged.
Active proposal count The active proposal count is a running tally of proposals that haven't yet reached a terminal state, kept as a budget guard against unbounded growth. Creating a new proposal checks this count against a fixed limit and fails if the limit has been reached. See also: Architecture §3.
Deadline
A deadline is the Unix timestamp (seconds since epoch) after which a proposal can no longer be approved or executed, and is instead treated as Expired. A new proposal's deadline must be in the future and within a bounded window, and the contract checks it against the current ledger's timestamp rather than wall-clock time on any one machine.
See also: Contract API — create_proposal.
Governance version
Governance version marks whether a deployed Accord contract uses flat (M-of-N approval count) or weighted (per-owner weight sum) voting logic. The is_governance_migrated query returns false for flat and true for weighted. A multisig deployed before weighted governance was added must call migrate_to_weighted_governance to transition to the new model.
See also: DEPLOYMENT.md — Migrating to Weighted Governance.
Quorum weight
Quorum weight is the minimum total voting weight required for a proposal to transition from Pending to Ready, enabling execution. Unlike the flat M-of-N threshold (an approval count), quorum weight is expressed as a sum of per-owner weights and is snapshotted when the proposal is created so that ownership or weight changes after creation do not retroactively alter the proposal's approval requirement.
See also: Architecture §4 — Proposal Lifecycle.
Total weight Total weight is the sum of all current owner weights in the contract. It determines the ceiling for all future quorum weights — a proposed quorum weight must never exceed total weight. When owners are added or removed, or their individual weights are changed, total weight updates to reflect the new ownership composition. See also: Deployment — Migrating to Weighted Governance.
Weighted approval Weighted approval is the voting model where each owner has a distinct voting weight (rather than each owner having an equal vote), and a proposal reaches quorum when the sum of approving owners' weights meets or exceeds the proposal's quorum_weight. This enables asymmetric governance structures, such as giving founders larger voting power while still requiring multisig approval. See also: Architecture §4 — Proposal Lifecycle.
Indexer An indexer is an off-chain service that continuously reads a contract's emitted events from Soroban RPC, decodes them into typed records, and persists them in its own datastore — so consumers can query event history and aggregates without depending on the limited retention window of a standard RPC node. Accord's reference indexer design is documented as the source for the treasury analytics API. See also: Architecture §7 — Indexing Accord Events, Architecture §13 — Indexer & Analytics Architecture.
Checkpoint (indexer)
A checkpoint is the ledger sequence number through which an indexer has fully processed events, persisted so the indexer can resume from where it left off after a restart or crash instead of re-scanning from the beginning. It plays the same role as the lastSeenLedger cursor the frontend already keeps in memory while polling for new events.
See also: Architecture §13.3 — Checkpointing, Resume, and Idempotency.
Idempotent replay Idempotent replay means that re-processing a ledger range an indexer has already ingested — for example after a crash before a checkpoint was written — writes the same records again without creating duplicates or double-counting an aggregate. Accord's indexer design achieves this by keying every stored event on the immutable tuple of contract, ledger, transaction, and event index, and by recomputing aggregates from the stored event log rather than incrementing them in place. See also: Architecture §13.3.
Spend by category
Spend by category is an analytics aggregation that totals executed transfer amounts grouped by proposal category (Transfer, Payroll, Grant, Ops, Other), along with each category's percentage share of total spend. It powers the Analytics page's "Spend by Category" chart and the GET /spend/by-category endpoint.
See also: Treasury Analytics guide, ANALYTICS_API.md.
Spend by owner
Spend by owner is the same aggregation as spend by category, grouped by the proposer address instead — how much each owner has moved through executed transfers. It powers the Analytics page's "Spend by Owner" chart and the GET /spend/by-owner endpoint.
See also: Treasury Analytics guide, ANALYTICS_API.md.
Treasury flow
Treasury flow is a time-bucketed view of inflow (deposits to the contract) and outflow (executed transfers and recurring disbursements) per token, grouped by a chosen granularity (day, week, or month). It powers the "Treasury Outflow Over Time" chart and the GET /treasury/flow endpoint.
See also: Treasury Analytics guide, ANALYTICS_API.md.
Time-series snapshot A time-series snapshot is a single point in a balance history — a timestamp paired with the contract's per-token balances at that moment. A series of these points lets the analytics API answer "what was our balance over time," not just "what is it right now." See also: ANALYTICS_API.md — GET /treasury/balance.
Analytics API The analytics API is the HTTP interface the indexer's datastore is served through — endpoints for proposal history, spend and treasury aggregates, and dashboard summary statistics, all documented with their query parameters, response shapes, and error format. See also: ANALYTICS_API.md.
Granularity
Granularity is the bucket size (day, week, or month) used to group time-series analytics data, such as treasury flow or balance history, into intervals. It's supplied as a query parameter on the endpoints that support historical bucketing.
See also: ANALYTICS_API.md — Standardized Query Parameters.