Glossary

SSOT (Single Source of Truth)

Definition: The canonical source where a value, rule, or definition is authored and considered authoritative for the system.

Boundary: SSOT does not mean the value exists in only one place; it means the value is defined in only one place.

Invariants: Changes flow from SSOT → code → docs. Dependent pages should link to SSOT.

Related: Forward-only policy, Evidence pointer, Changelog

Forward-only policy

Definition: A policy that forbids retroactive rewriting of historical records; corrections are appended as new records.

Boundary: Forward-only does not forbid new computation; it forbids mutating past facts.

Invariants: Past ledger entries are immutable. Corrections are compensating entries, not edits.

Related: Append-only ledger, Reconciliation

Evidence pointer

Definition: A reference used to verify a claim such as commit id, tx hash, block range, log id, or dashboard snapshot id.

Boundary: A screenshot without verifiable identifiers is not sufficient evidence.

Invariants: High-impact actions must leave evidence pointers in logs and changelog entries.

Related: Observability, Changelog

Commit

Definition: A deposit intent record created by the system that binds the user’s target such as asset, expected amount, and expiry and locks a pricing snapshot at creation time.

Boundary: A commit is not an on-chain transaction; it is a server-side intent with deterministic rules.

Invariants: Pricing snapshot is locked at commit creation. Status transitions are forward-only.

Related: Pricing snapshot, Commit status, Expiry

Pricing snapshot

Definition: A locked record of token price and quote-asset price used to compute targets and credits deterministically.

Boundary: A snapshot is not the current market price; it is the price used for that specific commit’s accounting.

Invariants: Must never change after commit creation; provider and timestamp should be stored.

Related: Quote provider, Credit, Audit

Deposit address

Definition: A derived address issued to receive funds for a specific commit or principal context under an HD scheme.

Boundary: A deposit address is not a wallet tier; it is a receiving endpoint.

Invariants: Derivation index allocation is atomic. Address reuse policy is explicit and enforced.

Related: HD derivation, Address index, Sweep

Deposit event

Definition: An observed on-chain event attributed to a deposit address, such as a native transfer or ERC-20 Transfer log.

Boundary: Detection does not mean settlement; it only means observation.

Invariants: Events are idempotent; uniqueness is defined by chain id, tx hash, and log index or equivalent identity.

Related: Confirmations, Reorg, Settlement

Settlement

Definition: The process that converts observed deposit events into finalized internal ledger entries after confirmation and finality rules.

Boundary: Settlement is not sweep. Settlement is accounting finalization.

Invariants: Must be reproducible from evidence pointers and locked snapshots.

Related: Ledger entry, Finality, Reconciliation

Sweep

Definition: A transaction that moves funds from deposit addresses to the HOT wallet for consolidation and spendability.

Boundary: Sweep is a funds movement, not an accounting decision.

Invariants: Sweep timing must not alter ledger truth; sweep policy is explicit and auditable.

Related: HOT wallet, Fee policy

Ledger entry

Definition: An append-only record representing an internal accounting action such as credit, debit, or adjustment linked to evidence pointers.

Boundary: Ledger entries are not balances; balances are derived from the ledger.

Invariants: Immutable. Corrections use compensating entries.

Related: Append-only ledger, Reconciliation

Credit (PVR credit / applied credit)

Definition: A ledger action that increases the user’s internal entitlement based on settled deposits.

Boundary: Credit is not an on-chain transfer and not “trading enabled”; it is internal entitlement.

Invariants: Credit must be computed from the locked pricing snapshot and remain auditable.

Related: Pricing snapshot, Allocation, Claim

Expiry

Definition: A deadline after which a commit is no longer eligible for new deposit attribution under normal rules.

Boundary: Expiry does not delete history; late deposits are handled by explicit late-policy.

Invariants: Expiry is enforced deterministically; exceptions must be logged with evidence pointers.

Related: Commit, Reconciliation

Commit status

Definition: The lifecycle state of a commit as it progresses from intent to settled accounting.

Canonical states:

• CREATED — Commit created; deposit window begins.
• PENDING — No matching on-chain event detected yet.
• CONFIRMING — Matching event detected; confirmations are being counted.
• CONFIRMED — Operational finality rules satisfied and settlement completed.

Boundary: “CONFIRMED” means internal operational finality plus settlement, not merely “N confirmations.”

Invariants: Allowed transitions move forward only; no retrograde state changes.

Related: Finality, Confirmations, Reorg

Confirmations

Definition: The count of blocks built on top of a block containing a transaction, used as a probabilistic finality signal.

Boundary: Confirmations are not absolute finality; reorg risk decreases but never reaches zero.

Invariants: Thresholds are chain-specific and documented; changes require changelog entries.

Related: Finality, Reorg window

Finality (operational finality)

Definition: The system’s chosen rule at which deposits are treated as irreversible for accounting purposes.

Boundary: Not identical across chains and not a protocol guarantee; it is an operational policy.

Invariants: Must be documented per chain; changes are forward-only and changelogged.

Related: Confirmations, Reorg, Reliability & Limits

Reorg (chain reorganization)

Definition: A replacement of recent blocks by a different canonical chain, potentially removing previously observed transactions or logs.

Boundary: Not an RPC bug. It is a chain reality.

Invariants: Settlement must be reorg-aware; reorg window is explicit and documented.

Related: Reorg window, Cursor, Reconciliation

Reorg window

Definition: The number of recent blocks the system treats as unstable and eligible for rewind or re-validation.

Boundary: This is not “confirmation count”; it is the scanner’s safety window.

Invariants: Cursor rewind strategy is defined and tested; a larger window increases cost but reduces risk.

Related: Cursor, Log scan

HOT wallet

Definition: A wallet whose keys are online and used for automated operations such as sweeps, payouts, or operational transfers.

Boundary: HOT is not “unsafe”; it is “high exposure.”

Invariants: Strict limits, monitoring, and rotation policy. Least privilege and spend caps apply.

Related: Signer, Least privilege, Sweep

WARM wallet

Definition: A semi-online wallet used as an intermediate operational reserve, typically with stronger controls than HOT but faster than COLD.

Boundary: WARM is not mandatory. Many systems use Deposit → HOT → COLD.

Invariants: If used, its role and triggers remain explicit, such as HOT top-up or reserve staging.

Related: COLD wallet, Key rotation

COLD wallet

Definition: An offline or near-offline storage tier designed to minimize compromise probability.

Boundary: COLD is not used for frequent operations.

Invariants: Manual process, multi-party control, and strict audit trail.

Related: Key ceremony, Account recovery

Signer

Definition: A component or service that can produce signatures for transactions under policy.

Boundary: Signer is not the wallet; it is the mechanism that enforces execution policy.

Invariants: Enforces allowlists, limits, approvals, and audit logging.

Related: HSM, KMS, MPC

Key rotation

Definition: The planned process of replacing keys and migrating operational control to reduce long-term compromise risk.

Boundary: Rotation is not regeneration; it is controlled migration with continuity.

Invariants: Rotation must be changelogged, rollback-capable, and blast radius must be documented.

Related: Blast radius, Incident

HSM (Hardware Security Module)

Definition: A hardware-backed environment designed to protect keys and perform signing operations with strong physical and logical controls.

Boundary: HSM is not a full security model by itself; policy and observability still apply.

Invariants: Keys should not be exportable in plaintext; access is least-privileged and logged.

Related: KMS, Signer

KMS (Key Management Service)

Definition: A managed service that stores keys and performs cryptographic operations with access control and audit logging.

Boundary: KMS does not remove the need for policy controls such as spend caps and approvals.

Invariants: Access is scoped, audit logs are retained, and rotation policy is enforced.

Related: Least privilege, Observability

MPC (Multi-Party Computation)

Definition: A signing approach where no single party holds the full private key; signing is performed through a distributed protocol.

Boundary: MPC reduces single-point compromise, but operational errors and policy failures remain risks.

Invariants: Participant roles, thresholds, and recovery procedures are explicitly documented.

Related: Account recovery, Incident

Key ceremony

Definition: A controlled, auditable process to create, distribute, and activate keys, especially for COLD storage or multi-party control.

Boundary: Not a casual setup. It is a documented event with evidence pointers.

Invariants: Steps are predefined, outputs are verified, and secure storage and access procedures are enforced.

Related: COLD wallet, Audit

RPC provider

Definition: A service endpoint used to query chain state or submit transactions.

Boundary: RPC is not the chain; providers can be delayed, inconsistent, or rate-limited.

Invariants: Multi-provider fallback is required; retry, timeout, and backoff policies are explicit.

Related: Rate limit, Cursor, RPC & Providers

Quote provider

Definition: A source used to obtain asset prices for quote purposes, such as Chainlink, exchange APIs, or operator-approved feeds.

Boundary: A quote is not a guarantee; it is a reference value.

Invariants: Provider name and time must be recorded in the pricing snapshot; changes must be changelogged.

Related: Pricing snapshot, Payment Engine

Log scan (eth_getLogs scan)

Definition: Block-range scanning of logs to find ERC-20 Transfer events to deposit addresses.

Boundary: Logs may be incomplete due to provider limits; scanners must handle pagination and retries.

Invariants: Cursor is persistent, reorg handling is defined, and dedupe keys are enforced.

Related: Cursor, Reorg window

Cursor (chain cursor)

Definition: The persisted pointer indicating the last processed block range for a scanner.

Boundary: Cursor is not latest head. It is progress.

Invariants: Monotonic updates with a tested rewind strategy.

Related: Idempotency, Reorg window

Rate limit

Definition: Provider-enforced limitations on request frequency or volume.

Boundary: Rate limit is not downtime; it is controlled degradation.

Invariants: Backoff and retry budgets are defined; alerts should trigger before total failure.

Related: SLO, Runbook

OLTP database

Definition: The primary transactional database storing commits, events, and ledger entries.

Boundary: DB state is not chain truth; reconciliation bridges the two.

Invariants: Critical tables use unique constraints for idempotency; migrations are changelogged.

Related: Reconciliation, Append-only ledger

Append-only ledger

Definition: A ledger model where entries are only appended and never modified or deleted; derived balances are computed from those entries.

Boundary: Append-only is not “no corrections”; corrections are new entries.

Invariants: Immutability, compensating entries, and preserved evidence pointers.

Related: Forward-only policy, Ledger entry

Reconciliation

Definition: A process that compares internal records with chain truth and produces corrective actions such as compensating ledger entries.

Boundary: Reconciliation is not refund; it is correctness enforcement.

Invariants: Deterministic rules, auditable outputs, scheduled and on-demand execution during incidents.

Related: Audit, Incident

Retention policy

Definition: Rules for how long logs, events, and metrics are stored and when they are compacted or archived.

Boundary: Retention must not destroy audit evidence for settled value.

Invariants: Ledger evidence is retained longer than transient telemetry; deletion is documented.

Related: Observability, Audit

Snapshot

Definition: A read-optimized representation of derived state computed from append-only sources such as balances, totals, or progress.

Boundary: Snapshot is not authoritative; it is derived. SSOT remains ledger plus rules.

Invariants: Rebuildable from sources, versioned, and supported by documented rebuild procedure.

Related: Append-only ledger, Reconciliation

Observability

Definition: The system’s ability to understand internal state via logs, metrics, and traces.

Boundary: Observability is not “more logs”; it is actionable visibility tied to SLOs and runbooks.

Invariants: Each critical flow emits identifiers such as commit id or tx hash. Alerts should link to runbooks.

Related: SLI, SLO, Runbook

SLI (Service Level Indicator)

Definition: A measured indicator of service health such as latency, error rate, delay to detect, or delay to settle.

Boundary: An SLI is a measurement, not a target.

Invariants: SLIs are computed consistently and reviewed periodically.

Related: SLO, Alert

SLO (Service Level Objective)

Definition: A target threshold for an SLI over a time window.

Boundary: SLO is an internal reliability contract, not an attacker-facing promise.

Invariants: Breaches trigger runbook execution and incident review.

Related: Incident, Postmortem

Alert

Definition: A notification triggered when a metric or rule indicates abnormal or risky conditions.

Boundary: Alerts should not be noisy; each alert must map to an action.

Invariants: Every alert links to a runbook and includes primary identifiers.

Related: Runbook, Incident

Runbook

Definition: A step-by-step procedure for handling known situations such as RPC outage, delayed settlement, or stuck sweeps.

Boundary: Runbooks provide safe defaults; they do not replace reasoning.

Invariants: Keep steps deterministic; include evidence pointers and rollback options.

Related: Operations (Runbooks)

Incident

Definition: A deviation from normal operation that impacts user fund safety, availability, correctness, or security.

Boundary: Includes silent correctness failures even if users do not notice immediately.

Invariants: Recorded in changelog; postmortem required for severe classes.

Related: Postmortem, Changelog

Postmortem

Definition: A structured write-up after an incident covering timeline, root cause, impact, and permanent fixes.

Boundary: Not blame. It is system improvement.

Invariants: Includes evidence pointers, action items, and verification steps.

Related: Incident

Threat model

Definition: Enumerated attacker capabilities and target assets used to guide defense decisions.

Boundary: Threat model is scoped assumptions, not fear.

Invariants: Updated when architecture changes such as new chains, new signer posture, or DEX activation.

Related: Trust boundary, Blast radius

Trust boundary

Definition: A boundary where trust assumptions change, such as public internet to private network or API to signer.

Boundary: Trust boundaries must be explicit; they are not implied.

Invariants: Crossing requires authentication, authorization, and audit logging.

Related: Authentication, Authorization, Audit

Least privilege

Definition: Each component has only the permissions it needs, for the shortest possible time.

Boundary: “Admin” is an anti-pattern unless explicitly justified.

Invariants: Access is scoped and logged; periodic review is required.

Related: KMS, Audit

Blast radius

Definition: The maximum impact scope of a component compromise or failure.

Boundary: Not theoretical; it must map to concrete assets and privileges.

Invariants: High-blast components require stronger controls and monitoring.

Related: HOT wallet, Signer

Authentication (AuthN)

Definition: Proving identity — who are you?

Boundary: Authentication is not authorization.

Invariants: Strong auth for admin paths; passkeys preferred where applicable.

Related: Authorization, Auth (Passkeys)

Authorization (AuthZ)

Definition: Permission checks — what can you do?

Boundary: Authorization is not a trusted network assumption; it must be explicit.

Invariants: Deny-by-default. All sensitive actions are logged with evidence pointers.

Related: Least privilege, Audit

Audit

Definition: The ability to reconstruct who did what, when, and why, with verifiable evidence.

Boundary: Audit is not just logs; it includes data integrity and evidence pointers.

Invariants: Sensitive actions produce immutable records and retention is enforced.

Related: Evidence pointer, Retention policy

enableTrading (market activation)

Definition: The one-way operational step that opens trading by enabling router or transfer constraints as defined in policy.

Boundary: This is not “liquidity added”; it is “market opened.”

Invariants: Requires pre-flight checklist, changelog entry, and evidence pointers.

Related: DEX Plan, Operations (Runbooks)

Liquidity provision (LP)

Definition: Supplying paired assets to an AMM pool to create a tradable market.

Boundary: LP does not imply fairness; market policy defines constraints.

Invariants: LP operations are logged and wallet tier and signer policy apply.

Related: HOT wallet, Signer

Oracle

Definition: A mechanism to obtain reference prices used for safety checks, quotes, or accounting.

Boundary: Oracle price is not a guarantee; it is an input with failure modes.

Invariants: Oracle choice and fallback rules are documented; deviations trigger alerts.

Related: Quote provider, SLO