Money

The splitting limitation

Why there is no atomic 98/2 transaction on this chain, and what we do instead.

This page exists so you learn this from the documentation instead of from a surprise.

The limitation #

For completeness, the payload shapes that produce that conclusion:

Kind	Payload	Carries value
`TRANSFER` (0)	`{to, amount, data}`	yes
`DEPLOY` (1)	`{code, manifest}`	no
`CALL` (2)	`{to, data}`	no `amount` field at all

Two related constraints rule out the usual workarounds:

No HD derivation. ML-DSA-65 has no BIP32-style child keys, so "one fresh address per checkout" would mean generating and storing a private key per payment — that is custody, and we declined it.
No value-carrying calls means no escrow contract either. There is nothing to send value into a contract with.

We do not claim atomicity we do not have.

What we do instead #

The customer makes one TRANSFER, with the reference in data. Then:

1. The accounting split is exact and immediate #

At confirmation, the split is exact in accounting, booked once at confirmation in a double-entry ledger whose entries must sum to zero or the booking is refused:

text

D payments_received:<merchant>        gross
C merchant_payable:<merchant>         merchant_amount
C treasury_fee_income:<treasury>      protocol_fee

The intent stores gross, merchant_amount, protocol_fee, the fee_bps and the treasury_address that applied. The split is a committed fact per payment from the moment it confirms, whatever the coins are doing.

2. Merchant-direct with a merchant-signed fee sweep — the default #

Merchant-direct with a merchant-signed fee sweep is the default and it is fully non-custodial. The payment address is your own payout address, so 100% of the gross lands with you and never touches an Animica Pay key. The 2% becomes a fee you owe, tracked as a receivable:

text

D merchant_fee_receivable:<merchant>  protocol_fee
C merchant_payable:<merchant>         protocol_fee    (you really did receive the gross)

Periodically you sign one transfer of the accrued fee to the treasury. The debt is discharged only when that sweep has a successful receipt — inclusion is not execution here either.

3. Forwarding address — opt-in #

Forwarding address is opt-in and clearly labelled. A per-merchant forwarding key held by the platform receives the payment and then emits two transfers: 98% to you, 2% to the treasury. This is atomic in accounting but not on chain, and it is custodial for the seconds between receiving and forwarding. Choose it only if hands-off fee handling is worth that window to you. It is never the default and it is never enabled silently.

Comparison #

	Merchant-direct (default)	Forwarding (opt-in)
Who holds your money	only you	platform, briefly
Custody risk	none	non-zero, seconds
Fee collection	you sign a sweep	automatic
On-chain transactions	1 payment + 1 periodic sweep	1 payment + 2 forwards
Accounting split	exact, at confirmation	exact, at confirmation
Atomic on chain	no	no

Notice the last row. Neither mode is atomic on chain, because nothing on this chain can be. The difference is who holds the coins in between.

What changes if the chain gains value-carrying calls #

If the chain gains value-carrying calls — a CALL with an amount, or a top-level value in the transaction envelope — then a splitter contract becomes possible and we intend to offer it as a third settlement mode:

the customer pays the splitter contract in one transaction;
the contract forwards 98% and 2% atomically, so there is no custody window and no sweep to sign;
the accounting stays exactly as it is today, because the ledger already books the split as a fact rather than inferring it from transfers.

Until that exists on mainnet, this page describes the whole truth. If you see a payments product on this chain advertising atomic on-chain splitting today, ask which transaction kind carries the value.

Consequences you can act on #

Reconcile against the ledger, not against your wallet balance. In merchant-direct mode your address receives the gross, so your wallet will show 100% of every payment and the 2% you owe will not be visible there.
Sweep on a schedule. Treat it like a supplier invoice. The balance endpoint reports protocol_fee_owed exactly.
Do not build the fee into a display price twice. The customer pays the gross; the fee comes out of your side of that same gross.
If you cannot sign regularly, take the forwarding option knowingly, having read the custody window above.

The arithmetic of the 2% itself, with exact numbers, is on The 2% fee. How settlement is detected and confirmed is on Core concepts.