---
description: >-
  In this section we'll learn how to make several transactions packed into a
  bigger one on Moonbeam parachain.
---

# Understanding the batch precompile

## The problem we're solving here

When we try to create modern dApps, the less transactions the user have to sign, the better. That's why this section is dedicated to Moonbeam Batch precompile that allows us to pack several transactions into a bigger one. This is of course convenient from an end-user's perspective but also on a gas-optimization one, as the base fee per transaction is reduced to a single one.

## Access the Batch Precompile

The Batch Precompile can be accessed on Moonbeam and Moonbase Alpha at this predetermined addresses:

`0x0000000000000000000000000000000000000808`

You'll find its Solidity interface on [PureStake's github.](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/batch/Batch.sol)



## The Batch functions

> * **batchSome**(_address\[]_ to, _uint256\[]_ value, _bytes\[]_ callData, _uint64\[]_ gasLimit) — performs multiple calls, where the same index of each array combine into the information required for a single subcall. If a subcall reverts, following subcalls will still be attempted
> * **batchSomeUntilFailure**(_address\[]_ to, _uint256\[]_ value, _bytes\[]_ callData, _uint64\[]_ gasLimit) — performs multiple calls, where the same index of each array combine into the information required for a single subcall. If a subcall reverts, no following subcalls will be executed
> * **batchAll**(_address\[]_ to, _uint256\[]_ value, _bytes\[]_ callData, _uint64\[]_ gasLimit) — performs multiple calls atomically, where the same index of each array combine into the information required for a single subcall. If a subcall reverts, all subcalls will revert

As we can see in this quote, we have 3 ways of integrating the Batch precompile. The difference is on how the batch will behave if one of the subcalls fails.

* batchSome will continue to execute the following subcallls even is one is failing
* batchSomeUntilFailure will abort on failure as its name suggests, avoiding failure
* batchAll will make all subcalls revert if one is failing

## The Batch parameters

> * _**address\[]**_**&#x20;to** - an array of addresses to direct subtransactions to, where each entry is a subtransaction
> * _**uint256\[]**_**&#x20;value** - an array of native currency values to send in the subtransactions, where the index corresponds to the subtransaction of the same index in the _to_ array. If this array is shorter than the _to_ array, all the following subtransactions will default to a value of 0
> * _**bytes\[]**_**&#x20;callData** - an array of call data to include in the subtransactions, where the index corresponds to the subtransaction of the same index in the _to_ array. If this array is shorter than the _to_ array, all of the following subtransactions will include no call data
> * _**uint64\[]**_**&#x20;gasLimit** - an array of gas limits in the subtransactions, where the index corresponds to the subtransaction of the same index in the _to_ array. Values of 0 are interpreted as unlimited and will have all remaining gas of the batch transaction forwarded. If this array is shorter than the _to_ array, all of the following subtransactions will have all remaining gas forwarded

* Address: The target of each subcall. For instance, a smart contract to interact with.
* Value: native token (GLMR) to send with the transaction. If none, write 0.
* callData: The encoded data of the transaction to execute, similar to Squid Hook requirements
* gasLimit: Max gas to be used per subcall. 0 is unlimited.

