# cryptocheckout.ai > Internal knowledge base for the tier-3a trustless crypto checkout: settlement architecture, economics, trust model, compliance posture, and operations. ## Docs - [MiCA position](https://docs.cryptocheckout.ai/compliance/mica.md): Why the architecture is shaped the way it is, and the hard bans that follow from it. - [Refund policy](https://docs.cryptocheckout.ai/compliance/refunds.md): The operational policy merchants and support need, and the one rule that must never be broken. - [Sanctions screening](https://docs.cryptocheckout.ai/compliance/sanctions.md): Identity-blind on-chain list lookups, two layers, both fail-open. Not KYC. - [Contract conventions](https://docs.cryptocheckout.ai/contracts/conventions.md): Foundry setup, deployment rules, and the constraints that must survive every change. - [Deployments](https://docs.cryptocheckout.ai/contracts/deployments.md): Where contracts actually live. Testnet only — mainnet is empty by design. - [Contracts overview](https://docs.cryptocheckout.ai/contracts/overview.md): Every Solidity contract in the system, what it does, and whether it is on the default path. - [Clone decisions](https://docs.cryptocheckout.ai/economics/clone-decisions.md): What gets an EIP-1167 proxy and what does not, with the reasoning that decides each case. - [Gas reimbursement](https://docs.cryptocheckout.ai/economics/gas-reimbursement.md): How the platform recovers deposit-rail gas from the merchant without ever gaining the ability to withhold funds. - [Open decisions](https://docs.cryptocheckout.ai/economics/open-decisions.md): Commercial and design choices that are genuinely undecided, with the trade-offs and what each blocks. - [TRON](https://docs.cryptocheckout.ai/economics/tron.md): Every way TVM differs from EVM in ways that have caused real errors, and the numbers that follow. - [Who pays what](https://docs.cryptocheckout.ai/economics/who-pays-what.md): Three cost points, three different payers, and the live numbers for each. The map to read before any economics discussion. - [cryptocheckout.ai knowledge base](https://docs.cryptocheckout.ai/index.md): The single most current description of what the product is, how it settles money, what it costs, and what is still undecided. - [Merchant quickstart](https://docs.cryptocheckout.ai/integration/quickstart.md): What a merchant does to go live, and what gates each step. - [SDK and embed](https://docs.cryptocheckout.ai/integration/sdk.md): How the embed works, the SRI pin that must be regenerated on every change, and the failures that made it DOA. - [Build and test](https://docs.cryptocheckout.ai/operations/build-and-test.md): Every command, what passes today, and which failures are expected. - [Deploying](https://docs.cryptocheckout.ai/operations/deploy.md): How code reaches production, and the guardrails around each surface. - [Environments](https://docs.cryptocheckout.ai/operations/environments.md): Which project is which, what is authoritative, and the stale references that have caused deploys to the wrong place. - [Known issues](https://docs.cryptocheckout.ai/operations/known-issues.md): Everything currently broken, wrong, or unverified, with the consequence of each. - [Glossary](https://docs.cryptocheckout.ai/overview/glossary.md): Terms used precisely throughout this knowledge base, including the ones that are easy to confuse. - [Status](https://docs.cryptocheckout.ai/overview/status.md): What is live, what is designed but unbuilt, and what is blocked. Check this before assuming any behaviour exists. - [What we are building](https://docs.cryptocheckout.ai/overview/what-we-are-building.md): The product thesis, the tier-3a custody position, and what makes this different from a payment processor. - [Platform architecture](https://docs.cryptocheckout.ai/platform/architecture.md): Edge functions, keepers, indexers, and how the off-chain system observes and drives the on-chain one. - [Authentication](https://docs.cryptocheckout.ai/platform/auth.md): SIWE-only sign-in, the JWT shape PostgREST requires, multi-role wallets, and how agents authenticate. - [Dashboards](https://docs.cryptocheckout.ai/platform/dashboards.md): Three roles, three entry points, and the pool-only invariant that governs every merchant surface. - [Partner referrals](https://docs.cryptocheckout.ai/platform/partners.md): Account-bound, first-touch, server-authoritative attribution across five layers. - [Connect rail](https://docs.cryptocheckout.ai/settlement/connect-rail.md): The customer signs a deposit directly into the merchant's pool and pays their own gas. - [Deposit rail](https://docs.cryptocheckout.ai/settlement/deposit-rail.md): A one-time address per invoice, payable from any wallet or exchange, swept into the pool by the keeper. - [Distribution and claiming](https://docs.cryptocheckout.ai/settlement/distribution.md): How the pool splits, why merchants keep 98.505%, and the permissionless property that must not be traded away. - [Finality and refunds](https://docs.cryptocheckout.ai/settlement/finality-and-refunds.md): When value may be delivered, and why there is no on-chain refund mechanism on either rail. Locked 2026-06-18. - [Settlement model](https://docs.cryptocheckout.ai/settlement/model.md): Two rails, one pool, and the design constraints that produced them. Locked 2026-06-18. - [Address derivation](https://docs.cryptocheckout.ai/trust/address-derivation.md): How pool and forwarder addresses are computed, why they must stay byte-identical across implementations, and what breaks if they drift. - [DB-display-only trust](https://docs.cryptocheckout.ai/trust/db-display-only.md): Why a database compromise cannot redirect a customer's payment, and the exact conditions under which that holds. - [Threat model](https://docs.cryptocheckout.ai/trust/threat-model.md): What the system defends against, what it does not, and the hardening that shipped after each audit.