BCH Script & Transaction Limits

Bitcoin Cash imposes various constraints on scripts and transactions to ensure efficient contract execution and network stability. We'll categorize these limits into two types:

1. Contract-related limits
2. General transaction limits

Contract-related limits

Maximum contract size

The Bitcoin Cash VM limits contract bytecode to 1,650 bytes. While typical contracts stay well below this, complex contracts with extensive logic might need adjustments to fit within this constraint.

Modular contract design

To keep contracts within size limits, consider modular design. Splitting contract logic into smaller, independent components allows each function to be deployed separately, reducing transaction size. See Contract Optimization for more details.

NFT commitment length limit

NFT commitments can store up to 40 bytes of data as local state. If more data is needed, you can hash the full state and store only the hash in the commitment data. Later, when required, the full state must be provided and validated against the stored hash.

caution

The 40-bytes limit on commitment length is of great practical importance for contract authors. Workarounds are needed to keep more bytes of local state in smart contracts.

Operation cost limit

Bitcoin Cash enforces an operation cost limit (op-cost) per transaction input. This determines the computational budget available for operations in a contract. The op-cost is based on script length: longer input scripts allow for a higher compute budget.

Buying compute budget

Since longer input scripts allow for a larger compute budget, some contracts use zero-padding (adding non-functional bytes) to "buy" more computation power without changing logic. You can find the exact op-cost per operation in the op-cost-table.

function maxOperationCost(unlockingBytecodeLength) {  
  return (41n + unlockingBytecodeLength) * 800n;  
}

Other contract-related limits

• Signature operation count (SigChecks): Limits the number of signature verifications (OP_CHECKSIG, OP_CHECKDATASIG) per transaction to ensure efficient validation.
• Hashing limit: Limits the number of hashing operations (OP_SHA256, OP_HASH160) allowed per transaction to prevent excessive resource usage.
• Stack element byte length: Each stack element has a maximum length of 10,000 bytes, affecting Pay-to-Script-Hash (P2SH) contracts.

General transaction limits

In addition to contract-related limits, Bitcoin Cash also enforces general transaction limits, which are network-level policies.

Maximum transaction size

Bitcoin Cash transactions must not exceed 100,000 bytes to be considered standard. Transactions above this size may not be relayed by most nodes.

Data output size limit

Bitcoin Cash allows multiple OP_RETURN outputs, but the total size of all data outputs in a transaction must not exceed 220 bytes of data payload (223 bytes total).

Dust threshold

Bitcoin Cash defines a "dust" threshold for output value. Outputs below this threshold are considered dust and will not be relayed by standard nodes.

The dust threshold is calculated as:

function calculateDust(outputSize: number): number {
  const dustThreshold = 444 + outputSize * 3;
  return dustThreshold;
}

Before CashTokens 546 bytes was often used as good default value, however with tokenData outputs have become larger in size. For ease of development, it is standard practice to use 1,000 satoshis as dust to outputs. Provably unspendable outputs (OP_RETURN outputs) are exempt from this rule.

Output Standardness

Bitcoin Cash only allows a few types of lockingbytecode scripts for outputs in the normal network relay rules. These are called 'standard outputs', contrasted to 'non-standard outputs' which cause the transaction not to relay on the network.

There's 4 types of standard output types: P2PKH, P2SH (which includes P2SH20 & P2SH32), P2MS and OP_RETURN data-outputs. For more details see the standard outputs documentation.

caution

The lockingbytecode standardness rules can be important for smart contract developers, and is why CashScript has helpers like LockingBytecodeP2PKH, LockingBytecodeP2SH32 and LockingBytecodeNullData.

Summary table

Limit type	Constraint
Max contract size	1,650 bytes
NFT commitment length	40 bytes
Operation cost limit	Based on script length
Max stack element size	10,000 bytes
Max transaction size	100,000 bytes
Max OP_RETURN data size	220 bytes data payload
Dust threshold	based on output size (commonly 1,000 sats is used as dust)
Output Standardness	P2PKH, P2SH (incl. P2SH20 & P2SH32), P2MS and OP_RETURN data-outputs

For further details on transaction validation and standardness rules, see the documentation on BCH transaction validation.