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.

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.

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)

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