> ## 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.

# cryptocheckout.ai knowledge base

> The single most current description of what the product is, how it settles money, what it costs, and what is still undecided.

This is the internal knowledge base for cryptocheckout.ai. It is written for engineers, operators, and agents who need to understand the whole system before changing any part of it.

<Warning>
  Nothing here is customer-facing marketing. Several sections describe unshipped design and open commercial decisions. Check [Status](/overview/status) before assuming a behaviour is live.
</Warning>

## What the product is, in one paragraph

A tier-3a trustless managed-SaaS crypto checkout. Audited Solidity contracts on seven EVM chains plus TRON accept stablecoin payments and settle them through a per-merchant **accumulating pool**. Two rails feed the same pool, and a permissionless `distribute()` splits the balance 99 / 0.75 / 0.25 between merchant, treasury, and referral partner, to recipients committed on-chain at pool creation. The platform never takes custody of funds, and — because the checkout verifies the settlement destination on-chain in the customer's browser before they sign — never takes custody of routing either.

## How to read this

<Columns cols={2}>
  <Card title="Settlement" icon="route" href="/settlement/model">
    Two rails, one pool, and how money actually moves from customer to merchant.
  </Card>

  <Card title="Economics" icon="calculator" href="/economics/who-pays-what">
    Who pays which gas, how the platform recovers what it fronts, and what is still open.
  </Card>

  <Card title="Trust and security" icon="shield-check" href="/trust/db-display-only">
    Why a database compromise cannot redirect a customer's payment, and the limits of that claim.
  </Card>

  <Card title="Contracts" icon="file-code" href="/contracts/overview">
    Every deployed contract, what it does, and the conventions that must never change.
  </Card>

  <Card title="Platform" icon="server" href="/platform/architecture">
    Edge functions, keepers, indexers, authentication, and the three dashboards.
  </Card>

  <Card title="Compliance" icon="scale-balanced" href="/compliance/sanctions">
    Sanctions screening, the MiCA position, and the refund policy.
  </Card>

  <Card title="Integration" icon="plug" href="/integration/quickstart">
    How a merchant embeds checkout and what gates access to it.
  </Card>

  <Card title="Operations" icon="wrench" href="/operations/environments">
    Environments, build and test, deployment, and the known-broken list.
  </Card>
</Columns>

## The five things most likely to trip you up

<AccordionGroup>
  <Accordion title="The deposit-rail sweep never calls the pool">
    `MerchantPool.sol` has exactly three external functions and no `receive`, `fallback`, or token hook. A forwarder sweep is a plain ERC-20 transfer to the pool address; the pool learns its balance by reading `balanceOf(address(this))` at distribute time. Deposit-rail volume generates zero pool calls. This single fact drives most of the [clone decisions](/economics/clone-decisions).
  </Accordion>

  <Accordion title="Merchants keep 98.505%, not 99%">
    `MerchantPool.distribute()` carves the 50 bps distributor reward from the **merchant** share. Every live pool carries `distribution_incentive_bps = 50`. The all-in rate is 1.495%, not 1%. See [Distribution](/settlement/distribution).
  </Accordion>

  <Accordion title="There is no refund mechanism on either rail">
    Locked 2026-06-18. The forwarder is sweep-only. Refunds are merchant-initiated, off-chain, to a customer-supplied address collected at refund time — never to the inbound sender. See [Finality and refunds](/settlement/finality-and-refunds).
  </Accordion>

  <Accordion title="TRON is not a slightly more expensive EVM chain">
    TVM energy equals EVM gas unit-for-unit, but TRON prices it 100–2,700× higher, has no EIP-2929, charges bandwidth as a separate resource that energy rental does not discount, and applies a Dynamic Energy Model penalty with no EVM equivalent. Reasoning ported from EVM to TVM has produced at least three material errors. See [TRON](/economics/tron).
  </Accordion>

  <Accordion title="The repo is not the source of truth for the production schema">
    Production tracks 86 migrations; migration tooling is broken locally and does not record the colliding local versions. See [Known issues](/operations/known-issues).
  </Accordion>
</AccordionGroup>

## Source hierarchy

When two documents disagree, prefer them in this order.

| Rank | Source                     | Notes                                                                                 |
| ---- | -------------------------- | ------------------------------------------------------------------------------------- |
| 1    | On-chain state             | The chain is the source of truth for money and routing.                               |
| 2    | `docs/superpowers/specs/*` | Dated design specs. The newest dated spec on a topic wins.                            |
| 3    | This knowledge base        | Consolidated and cross-checked, but derived.                                          |
| 4    | Linear issues              | Actionable and current, but individually scoped and sometimes mutually contradictory. |
| 5    | `CLAUDE.md`                | Dense and authoritative on conventions, but sections lag behind locked decisions.     |

Every dollar figure in the Economics section was computed from live prices on the date stated. The **decisions** do not move with prices; the **numbers** do.