> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cryptocheckout.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Glossary

> Terms used precisely throughout this knowledge base, including the ones that are easy to confuse.

Terms are used strictly. Where two terms are commonly confused, the distinction is called out.

## Settlement

**Pool** — `MerchantPool`, one per merchant per chain. Immutable, ownerless. Accumulates funds from both rails. Its payout recipients and basis-point splits are frozen into its init code, so its CREATE2 address commits to them.

**Rail** — a path by which money reaches the pool. There are two, and a third is designed.

**Connect rail** — the customer connects a wallet and signs `MerchantPool.deposit(paymentId, token, amount)` directly. The customer pays their own gas. The platform fronts nothing.

**Deposit rail** — the customer sends a plain transfer to a per-invoice address. Works from any wallet and from exchange withdrawals. A keeper deploys the forwarder and sweeps the funds into the pool, fronting the gas.

**Forwarder** — `InvoiceForwarder`, a per-invoice contract at a counterfactual CREATE2 address. Sweep-only: it moves 100% of its balance to the pool it commits to. It has no refund function. It remains callable after the first sweep, which is load-bearing for late payments.

**Distribute** — `distribute()`, permissionless, splits the pool's current balance between the committed recipients and credits each to a pull-claim ledger.

**Claim** — `claim()`, moves a credited balance to its recipient. Separate from distribute because the pattern is pull, not push.

**Counterfactual address** — an address computed from CREATE2 inputs before any code is deployed there. Both pools and forwarders are quoted and displayed counterfactually and deployed lazily on first use.

<Warning>
  **Deposit rail is not "the TRON rail."** TRON currently supports only the deposit rail, but the deposit rail exists on every chain. The thing TRON is missing is the *connect* rail.
</Warning>

## Roles and money

**Keeper** — the platform's off-chain worker. Deploys forwarders, sweeps, and runs the backstop distribute. Holds native gas on every chain and fronts deposit-rail costs.

**Treasury** — the platform's revenue recipient, 0.75% of gross by default.

**Partner** — a referral partner, 0.25% of gross. Bound to a merchant account-wide, first-touch, server-authoritative.

**Distributor reward / distribution incentive** — 50 bps paid to whoever calls `distribute()`. Carved from the **merchant** share, which is why merchants keep 98.505% rather than 99%.

**Gross** — the pool's token balance at the moment `distribute()` is called, before any split.

## Chains

**EVM** — the seven launch chains: Ethereum, Base, Arbitrum, Optimism, Polygon, BNB Chain, Avalanche.

**TVM** — the TRON Virtual Machine. Compatible with the EVM for most opcodes but differs in ways that have repeatedly caused errors. See [TRON](/economics/tron).

**Energy** — TRON's equivalent of gas for contract execution. Priced by the `getEnergyFee` chain parameter, currently 100 sun per unit.

**Bandwidth** — TRON's separate resource covering transaction byte size, at 1000 sun per byte. **Energy rental does not discount bandwidth.** Conflating the two has produced published errors.

**Dynamic Energy Model (DEM)** — a TRON mechanism that multiplies a contract's energy cost when that contract exceeds a usage threshold. No EVM equivalent.

**sun** — the smallest TRX denomination, 1 TRX = 1,000,000 sun.

## Trust

**Settlement anchor** — a payout wallet the merchant pins in the embed code on their own site. It is the root of the client-side verification chain.

**Effective recipient** — the result of `MerchantRegistry.effectiveRecipient(anchor)`, an on-chain read the database cannot author. Identity-default: an unattested merchant resolves to themselves.

**Re-derivation** — the browser recomputing a CREATE2 address from chain-read inputs and asserting it matches the served address. The load-bearing check.

**`pool_mismatch`** — the terminal checkout state when re-derivation fails. Blocks signing and hides the pay-to address.

## Operational

**Intent** — a database row representing an expected payment. `pool_deposit_intents` is the pool-rail ledger. Merchant surfaces read this, never the legacy `paid_events`.

**Capture / finality** — the point at which value may be delivered. Connect rail: when `deposit()` reaches required confirmations. Deposit rail: when the inbound transfer confirms **and** the keeper sweep confirms. Never first-seen.

**Legacy / atomic rail** — the original `RouterFee` per-payment splitter. Still deployed, no longer the default path, and dropped from all merchant-facing reads.