Skip to main content
Your pool is a small contract, one per chain, that receives payments and pays out only to fixed destinations: your payout address, our treasury, and your referral partner if one referred you. Nothing else — there is no fourth destination, and nothing is carved out of your share to pay for the split itself.

​
What it does

Receives

Both ways of paying settle into it. It accumulates rather than forwarding each payment individually.

Splits

On distribution it takes the platform fee — fixed when the pool was created, capped in contract code at 2.5% of gross — and credits the rest to you in full. There’s no second deduction for whoever sent the transaction: every live pool runs a 1% platform fee, so you net 99%.

Pays out

Each party claims their credited share to their own address.

​
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 it holds. You choose the cadence in Pool → Settlement schedule — release on a timer, or once the balance reaches a threshold you set, with a maximum wait as the backstop either way (24 hours by default).
Batching changes when you are paid, not what it costs you. Our keeper fronts and absorbs the gas on the automatic settlement transactions it sends, whatever the batch size — nothing is carved out of your share for it. Batching is only worth money on a withdrawal you sign and pay for yourself — where it matters most on Ethereum and TRON.

​
Getting it deployed

Setting up a pool costs you one free signature; deploying it on a chain costs one more signature and that chain’s network fee, paid from your own wallet.

Sign one message

During setup you sign an off-chain proof-of-control message from your payout wallet. It’s a signature, not a transaction: no gas, no chain switch. That address is then baked into your pool’s immutable code.

Turn on a network

In Pool, flip the switch for each chain you want to accept.

You deploy it, with a live fee estimate

Activating a chain is a second signature — the one that actually broadcasts the deploy transaction, from your own wallet, paying that chain’s network fee. The dashboard shows a live estimate before you sign. There’s no lazy first-payment deploy and nothing fronted on your behalf: the pool exists, or it doesn’t, and you’re the one who put it there.
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.
Gating API keys and the embed snippet on a deployed pool is Coming. Today you can integrate first — but the connect rail stays refused (pool_not_deployed) on any chain until you’ve actually deployed your pool there; only the deposit rail’s one-time address can be shown pre-deploy. Roadmap.

​
Who pays for it

You do, for the pool itself. It’s worth being precise about what that means and where the two remaining costs land.
You broadcast the deploy transaction, from your own wallet, paying that chain’s network fee — one signature and one wallet-paid transaction per chain you activate. What binds the contract to you either way is that your payout address — taken from the message your wallet signed at setup — is baked into the pool’s immutable code, and no admin, owner, or pause function exists that could change it. Anyone can read that address back out of the contract themselves. The one exception: if a deposit-rail payment already swept into a still-codeless pool of yours, we deploy it as a rescue so those specific funds aren’t stranded — never a routine service, and never for the connect rail.
Settling a payment that arrives by plain transfer means deploying a one-time forwarder address and sweeping it into your pool, and our keeper fronts the network fee for both. We recover it by holding back a small network fee — capped on-chain at 10% of what arrived — fixed into that one-time address before the customer is ever shown it, so their own browser can verify the cap before they pay. It is not a cut of your share at settlement; it comes off that specific payment, at the forwarder, before the pool ever sees it. Fees.

​
What can and can’t change

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.

​
Before it’s deployed

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

A plain transfer works pre-deploy

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.

A wallet payment needs the contract

deposit() is a contract call and fails against an address with no code, so the pool has to exist before a customer signs. There’s no just-in-time deploy on the connect rail: if your pool isn’t already deployed on that chain, the payment is refused (pool_not_deployed) rather than sent to a codeless address. Deploy it from Pool before you offer that chain on this rail.

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

On-chain verification

How your customers’ browsers check this automatically.