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

# Your pool

> The contract that holds your money between payment and payout, and why it works that way.

Your pool is a small contract, one per chain, that receives payments and pays only you.

## What it does

<Columns cols={3}>
  <Card title="Receives" icon="download">
    Both rails settle into it. It accumulates rather than forwarding each payment individually.
  </Card>

  <Card title="Splits" icon="code-branch">
    On distribution, it takes the fee and credits the rest to you — at a rate fixed when it was created and capped in contract code at 2.5%.
  </Card>

  <Card title="Pays out" icon="upload">
    Each party claims their credited share to their own address.
  </Card>
</Columns>

## Why accumulate rather than forward

Splitting every payment on arrival would mean three transfers per order. On a €20 order on Ethereum, those fees can exceed the order.

Accumulating means one payout transaction covers however many orders you batch into it. You choose the cadence: after every order, daily, weekly, or when the balance justifies it.

<Tip>
  On cheap chains, claim whenever you like. On Ethereum and TRON, batching is worth real money.
</Tip>

## Deploying it

One transaction per chain, signed by you.

<Steps>
  <Step title="Pick a chain" icon="link">
    In **Pool**, choose from your enabled chains.
  </Step>

  <Step title="Review the estimate" icon="gas-pump">
    A live network-fee estimate is shown before you sign. On Ethereum and TRON, waiting for a quieter period can cut it substantially.
  </Step>

  <Step title="Sign" icon="signature">
    We prepare the transaction; you broadcast it. That's what makes the contract yours rather than ours.
  </Step>
</Steps>

<Note>
  Your pool has the **same address on all seven EVM chains**. One address to whitelist with a custodian, one to reconcile against, one to hand your accountant.
</Note>

<Note>
  Making deployment a prerequisite for API keys and the embed snippet is coming. Today you can integrate first — but the wallet-payment option only appears on chains where your pool exists. [Roadmap](/reference/roadmap).
</Note>

## Why you pay for it

It's a fair question — a custodial processor doesn't charge you to open an account.

Two reasons, and both benefit you:

<AccordionGroup>
  <Accordion title="Signing it is what makes it yours" icon="key">
    A contract we deployed and paid for would be a contract we could plausibly claim some control over. You signing it removes that ambiguity entirely.
  </Accordion>

  <Accordion title="It keeps the platform honest about cost" icon="scale-balanced">
    We can't quietly absorb infrastructure costs and recover them through hidden spread or delayed payouts, because the costs that are yours are visible and the fee is a published flat rate.
  </Accordion>
</AccordionGroup>

## What can and can't change

|                          |                                                                       |
| ------------------------ | --------------------------------------------------------------------- |
| Payout address           | **Fixed at creation.** Changing it means a new pool at a new address. |
| Split ratios             | **Fixed at creation.**                                                |
| Who can withdraw         | Only the committed recipients, to their committed addresses.          |
| Who can trigger a payout | **Anyone.** Including you, us, or a stranger.                         |
| Admin or pause function  | **None exists.**                                                      |

<Warning>
  Changing your payout address means deploying a new pool. Your old pool keeps whatever is in it, and you can still claim from it — but new payments go to the new address, which is a different address. Plan the switch rather than doing it mid-trading-day.
</Warning>

## Before it's deployed

The address exists as a computation before any contract does, which produces one useful asymmetry:

<Columns cols={2}>
  <Card title="Deposit rail works pre-deploy" icon="check" color="#10B981">
    A sweep into an undeployed pool is a plain transfer. The funds sit at the address and become claimable the moment the pool is deployed.
  </Card>

  <Card title="Connect rail does not" icon="xmark" color="#EF4444">
    `deposit()` is a contract call and fails against an address with no code. The connect rail is hidden on chains where you haven't deployed.
  </Card>
</Columns>

## Reading it yourself

Your pool is a public contract. On any block explorer you can call `recipient()` and confirm it returns your address — and confirm there's no function that would let anyone change it.

<Card title="On-chain verification" icon="shield-check" href="/concepts/verification" horizontal>
  How your customers' browsers check this automatically.
</Card>