Send
Sending batches one or more recipients into a single operation, backed by one signature and previewed before you sign.
Send moves funds from your account to one or more recipients. Whether it's one recipient or several, it's built as a single operation - one preview, one signature.
Batching recipients
A send can target more than one recipient at once: every transfer in the batch is folded into a single call array, so one owner signature covers the whole thing rather than one per recipient. The app's send screen caps this at five recipients per send - that's a product choice, not a limit enforced by the underlying operation itself.
What can be sent
Native ETH is always sendable with no extra setup. Any other token needs a verified transfer mechanism behind it; a token without one is refused up front, with a named reason, rather than built and left to fail on-chain.
An unsupported chain is also rejected immediately, before Botanary does any token lookup or on-chain read at all.
Previewed first
Before a send is ever handed back to you as something to sign, it's run through the account's own on-chain policy hook via simulation. If that hook would refuse the transfer, the build fails outright with a decline reason instead of returning an operation - see Simulation for what gets checked and Constraint types for the specific rules that can cause a decline.
Paying gas without native currency
If you pay the transaction's fee in a stablecoin rather than the chain's native token, that fee is pulled during the operation's validation phase - before the transfer itself runs. That means your account needs to hold the send amount plus the estimated fee at build time; Botanary checks this up front and reports a shortfall as an availability issue, not a policy decline.
Paying gas in USDT
An approval for the gas paymaster is batched into the same operation as the send itself - one signature covers both, because USDT has no permit mechanism to sign separately.
Paying gas in USDC
USDC gas instead uses a permit signature over your account, which is a second signature beyond the one that authorizes the send. Because that permit becomes part of the operation's data, attaching it changes the operation's hash - the client recomputes it rather than reusing the hash from the first signature.
See Gas for the full set of payment methods and how each is chosen.
A send that can't be previewed successfully is never presented for signature - the same build, preview, sign, relay flow every action in Botanary follows.