Fund Flow

This page is about where the money goes: where a customer's payment lands, how it gets consolidated, how it reaches your account, and at which step the fee is deducted.

Its counterpart, Information Flow, is about how the order state advances. Read the two side by side: the fund flow is driven by you, the information flow is driven by HashNut.

Every term used on this page is defined in the Glossary.

In One Sentence

Funds only ever rest in three kinds of places — receipt addresses (dozens to hundreds) → split wallet (one per chain) → withdraw address (one) — and they never pass through a HashNut-controlled account.

Note the shape: many-to-one, then one-to-one. You run a batch of receipt addresses (how many is up to you — 50 or more is recommended); they all claim into the same split wallet, which then releases to the same withdraw address.

Of the three steps, step 1 is triggered by the customer, while steps 2 and 3 are both initiated by you. At no point in this chain can HashNut move your funds unilaterally.

The Three "Wallets"

	Receipt address	Split wallet	Withdraw address
What it is	A plain on-chain address (EOA)	A smart contract	Your own wallet address
Who can move the funds	Merchant and HashNut each hold half a key share; both must sign	Only what the contract code allows — nobody can transfer arbitrarily	Fully controlled by the merchant
How long funds stay	From the customer's payment until you claim	From the claim until you release	Final destination, no further movement
How many	Dozens to hundreds	One per chain	One per chain
Who manages it	HashNut assigns them to orders automatically	Deployed by the merchant	Chosen by the merchant at setup

Leg 1: Customer → Receipt Address

When an order is created, HashNut takes an idle address from the receipt address pool, binds it to that order, and returns it to you. The customer transfers the token to that address, and this leg is done.

Key points:

• One order, one address — concurrent orders occupy multiple addresses. This is why you need a batch of receipt addresses rather than one: the number of idle addresses in the pool is the number of unpaid orders you can have open at the same time. When the pool runs dry, no new order can be created. Plan on 50 addresses for low-frequency / high-value flows and 200 for high-frequency flows.
• Funds belong to the merchant the moment they arrive. The receipt address key is a 2-of-2 MPC share — half in your local keys.db, half at HashNut. Neither side can sign a transfer alone: HashNut cannot take the funds, and you cannot bypass the contract to move them either.
• Addresses are reused. Once an order reaches a final state (success / expired / canceled), its address returns to the pool for later orders. But releasing an address does not move any money — the funds stay at that on-chain address until you claim them.
• Each address holds several payments at once. A receipt address serves many orders over time, so its balance before a claim is the sum of those payments. That is normal — there is no need to claim order by order.
• So a claim always deals with a batch of addresses. Funds being spread across dozens or hundreds of addresses is the expected state; claiming is precisely how you pull them together. It is also why the next leg processes them in batches.

TIP

You do not need to claim right after each payment. Funds are safe where they are, so you can claim in bulk daily or weekly to save on gas.

Leg 2: Receipt Addresses → Split Wallet (Claim)

On the split wallet page of the MPC Client, click Claim to consolidate the funds scattered across your receipt addresses into the split wallet.

The key mechanism: allowance, not private keys

A claim is not a transfer initiated by the receipt address. The split wallet pulls the funds in using the allowance it was granted earlier (approve).

Two consequences follow:

• The claim transaction is signed by your merchant wallet. No MPC round trip is involved and HashNut does not need to participate. Even if you lose your keys.db, as long as you still have the merchant wallet key, already-approved funds can still be claimed and released normally.
• Conversely, a token that was never approved cannot be claimed. Approval is tracked per (receipt address, token), so before accepting a new token you must backfill the approval for your existing addresses using Batch Backfill Approval in the MPC Client.

Characteristics

Aspect	Detail
Initiated by	The merchant, manually, from the MPC Client
Signature	Merchant wallet key, signed directly
Coverage	A single call can cover many receipt addresses × many tokens
Batching	Batched by receipt address, 50 per batch by default
Empty batches	Each batch is simulated first; batches with a zero balance are skipped so no gas is wasted
Does it split?	No — a claim only consolidates the funds

For the step-by-step walkthrough, see Aggregate Funds.

Leg 3: Split Wallet → Withdraw Address (Release)

Click Withdraw in the MPC Client to move your share to the withdraw address. This is where the split actually happens.

How the split is calculated

The split wallet keeps its books in shares, which always total 10000. The amount a payee can currently withdraw is:

withdrawable = total ever received × payee share ÷ 10000 − amount that payee already withdrew

Note that this is a cumulative calculation, not a per-order settlement. You can withdraw at any time without the books going wrong, and withdrawing repeatedly never double-pays.

At the default 0.8% rate:

Payee	Share	Withdrawable after 10,000 USDT received
Merchant	9920	9,920 USDT
Platform (HashNut)	80	80 USDT

When you call release, you can only take your own share. The platform withdraws its own portion separately — this is enforced by the contract, not by anyone's good behavior.

Which address the funds reach

The withdraw address registered when the split wallet was deployed — the one you entered during one-key setup.

WARNING

The destination is determined by the withdraw address stored in the contract, not by the wallet that sends the release transaction. Signing from a different wallet still sends the funds to the original withdraw address.

For the step-by-step walkthrough, see Withdraw Funds.

Where Gas Goes

The three legs above trace the token. On-chain transactions additionally cost native coin (ETH / BNB / MATIC / TRX) as gas. That is a separate flow of funds, and it is paid entirely by the merchant's wallet — HashNut does not cover it.

Where it goes	Why it is needed
To receipt addresses	Each receipt address sends its own approval transaction and needs gas for it
To the Manager	The Manager sends the transaction that registers receipt addresses into the contract
Paid directly by the merchant wallet	Deploying, activating, claiming and releasing — every transaction you sign yourself

Whatever native coin is left over on receipt addresses and the Manager can be moved back to your wallet at any time with Sweep in the MPC Client. The batch address creation flow runs a sweep automatically at the end.

TIP

Make sure your merchant wallet holds enough native coin before you start. Going live on both ETH and TRON means keeping both ETH and TRX on hand. The MPC Client estimates the cost and shows a confirmation dialog before every operation — it never spends silently.

Where the Money Ends Up in Edge Cases

Situation	Where the funds go
Underpayment	Whatever was paid sits on the receipt address as usual and can be claimed normally. The order stays at PAID and a supplement order is created for the difference
Overpayment	The excess is claimed into the split wallet along with everything else and is split by share. HashNut does not refund the difference automatically — settle it with the customer yourself
Customer pays after the order expired	The funds still arrive at that receipt address and are not lost; they can still be claimed. But the address has been released, so the transfer may not be matched back to the expired order and needs manual reconciliation
Customer sends an unapproved token	The funds are on the receipt address, but the split wallet cannot pull them. Use Batch Backfill Approval to approve that token for the address, then claim
Customer sends on the wrong chain	HashNut cannot help here. A receipt address is the same string across EVM chains, but orders and approvals are isolated per chain
keys.db is lost	Claiming and releasing already-approved funds are unaffected (they only need the merchant wallet key). What breaks is creating new receipt addresses, backfilling approvals and sweeping — those need the MPC key share

How This Relates to the Information Flow

The two flows are decoupled and meet at only two points:

Meeting point	What happens
Receipt address activation	An address enters the pool only after it is approved and registered into the contract, and only then can an order use it — the fund flow's setup work is a precondition for the information flow
Order state controls address release	When an order reaches a final state its address returns to the pool, but the funds do not move — the information flow controls address allocation, not the money

Put differently: the information flow decides "which order this payment belongs to", while the fund flow decides "where this money is now and where it goes next". An order reaching SUCCESS does not mean the money is already in your withdraw address — that still requires you to claim and release.

Next

• Information Flow — how the order state advances and how notifications arrive
• Prerequisites — actually set up the split wallet and receipt addresses