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

# What we are building

> The product thesis, the tier-3a custody position, and what makes this different from a payment processor.

## The product

A hosted checkout that accepts stablecoin payments and settles them to a merchant's own wallet without the platform ever holding the money or controlling where it goes.

A customer pays in USDC, USDT, or EURC on one of seven EVM chains or TRON. The funds land in a per-merchant on-chain pool whose payout recipients are frozen into its bytecode at creation. Anyone — the merchant, the platform, or a stranger — can call `distribute()` to split the pool's balance. The platform's only privileged capability is operational convenience, never control.

## Tier-3a, precisely

"Non-custodial" is used loosely across the industry. The specific claim here has two halves.

<Columns cols={2}>
  <Card title="No custody of funds" icon="wallet">
    Money moves from the customer to an address whose payout logic is immutable. The platform holds no balance at any point and cannot redirect a settled payment.
  </Card>

  <Card title="No custody of routing" icon="route">
    The checkout verifies the settlement destination on-chain, in the customer's browser, before they sign. A compromised database cannot change where a payment goes.
  </Card>
</Columns>

The second half is the unusual one and it has real conditions attached. Read [DB-display-only trust](/trust/db-display-only) before repeating it anywhere public.

## What we deliberately do not do

| Not built                                    | Why                                                                                                                                                                                                            |
| -------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Fiat on-ramps or off-ramps                   | Hard ban. MiCA's "facilitating the conversion" language is broad enough that even a soft recommendation pulls the platform toward CASP scope. This applies to every public surface, including casual mentions. |
| Custody, escrow, or balance holding          | It is the entire differentiator. Any feature that requires holding merchant or customer funds is out of scope by default.                                                                                      |
| Ability to freeze or withhold merchant funds | `distribute()` is permissionless by design. This is described in the settlement spec as the regulatory linchpin and is not tradeable for operational convenience.                                              |
| Token swaps at checkout                      | Deferred to Phase 2. Phase 1 is stablecoin-only. `RouterFee.payWithSwap` exists and is deployed but is an opt-in path, not the default.                                                                        |
| KYC of payers                                | Sanctions screening is an identity-blind on-chain list lookup, not identity verification. See [Sanctions](/compliance/sanctions).                                                                              |

## Positioning

The supported stablecoins are **USDC, USDT, and EURC as equal options**, with no geographic slant. EURC being the current default for new merchants is a configurable database default (`merchants.default_stablecoin`), not a market position. Do not describe the product as "Europe-first" or "EUR-first" on any user-facing surface.

The compliance line used consistently across docs, landing pages, and sales:

> Sanctions-clean. KYC-free. We screen the wallet, not the person.

## What the customer sees

A single-panel checkout that walks through currency, network, rail, and payment. Two ways to pay:

* **Connect a wallet.** The customer signs a `deposit()` call directly into the merchant's pool. They pay their own gas. Irreversible on confirmation.
* **Send to an address.** The customer gets a QR code and a one-time address. They can pay from any wallet or withdraw directly from an exchange. The platform sweeps it into the pool.

The second is the reason the architecture is shaped the way it is. Accepting a plain transfer from an exchange withdrawal — where the sender address belongs to an omnibus hot wallet and the payment arrives hours later — is what forces counterfactual addresses, keeper-sponsored gas, and the entire economics section.

## Where the money goes

```
customer payment
      │
      ▼
per-merchant pool  (immutable, ownerless, recipients frozen in bytecode)
      │
      ▼  distribute()  — permissionless, callable by anyone
      ├── 99.00%  merchant     (minus the distributor reward, see Distribution)
      ├──  0.75%  treasury
      └──  0.25%  referral partner
```

The split is configurable per merchant at pool creation. Only the basis-point caps are hardcoded. Recipients are committed on-chain and cannot be changed without deploying a visibly different pool at a different address.