contractExecution endpoint:
- Developer-controlled wallets:
POST /developer/transactions/contractExecution - User-controlled wallets:
POST /user/transactions/contractExecution(uses the challenge approval flow)
executeBatch
function onchain. For modular wallets, the modular SDK also exposes batching
with 2D nonces for parallel user operations. See
Batch and parallel user operations.
How batching works
Every SCA and MSCA implements anexecuteBatch function on the wallet contract:
POST to the contractExecution endpoint with:
contractAddress: your wallet’s own address. The wallet contract runsexecuteBatchon your behalf.abiFunctionSignature:executeBatch((address, uint256, bytes)[])abiParameters: an array where each entry is a tuple describing one subcall. The tuple fields are the target contract address, the amount of native token to send with the call (usually0), and the ABI-encoded function call.
Common batch operations
Two USDC transfers
Encode thetransfer function call once, then include it twice in
abiParameters to move USDC in a single transaction:
contractExecution endpoint. Each entry in the outer
array is one subcall: the target is the USDC contract, the value is 0 (USDC
transfers don’t send native token), and the callData is the encoded transfer
call:
contractAddress is your SCA wallet address. The two subcalls in
abiParameters produce a total of 200 USDC transferred to the recipient.
A USDC approval and CCTP burn
To send USDC across blockchains using CCTP, first approve the CCTPTokenMessenger contract to spend your USDC, then call depositForBurn to
initiate the transfer. Batching runs both atomically:
destinationDomain values, see the
CCTP domain list.
Send the batch. The first subcall targets the USDC contract with the encoded
approve calldata; the second targets the TokenMessenger with the encoded
depositForBurn calldata:
Retrieve batched transactions
Set arefId on the request, then filter
GET /transactions
by that refId to retrieve every transaction in the batch.