Skip to main content
There is no gas token in BRC2.0 and no dynamic gas price — but execution is still limited and metered. Understanding how gas works here is critical for writing efficient contracts and predicting costs.

​
Inscription size = gas budget

Every inscription on Bitcoin pre-pays execution resources:
  • Gas is directly proportional to the size of the inscription in bytes
  • Larger inscriptions allow more computation and state changes
  • Each byte of inscription data grants a fixed gas allowance
  • There is no dynamic pricing — execution cost is baked into the transaction size and Bitcoin fee
Think of it as: your transaction byte size is your gas budget. 
Gas budget = inscription_bytes × gas_per_byte (fixed constant)

Cost       = inscription_bytes × bitcoin_fee_rate (sats/vbyte)
Unlike Ethereum, you are not bidding for gas with a separate token. You are paying Bitcoin fees for block space, and that block space determines how much computation you can perform.

​
How to think about optimization

On Ethereum, optimization means reducing gas consumption to lower ETH spend. On BRC2.0, optimization means reducing inscription byte size to lower Bitcoin fees and fit more logic into a given cost envelope.
Smaller calldata and bytecode means lower Bitcoin fees, faster indexing, and fewer block-space constraints. The same optimization instincts apply, but the metric is bytes, not gas units.
Use tightly packed ABI encoding. Avoid passing large strings or arrays when a compact representation will do. Where the protocol supports it, compress calldata using NADA or ZSTD — compression often reduces fees by 3–5x for typical calldata patterns.
// Prefer: pass a uint256 ID instead of a full string
function process(uint256 itemId) external { ... }

// Avoid: large string arguments inflate inscription size
function process(string calldata itemName) external { ... }
The BRC2.0 environment provides precompiled contracts for common operations (BIP-322 verification, Bitcoin transaction introspection, etc.). Calling a precompile consumes far fewer gas units than reimplementing the same logic in Solidity. Prefer precompiles wherever they are available.
Smaller contract bytecode means a smaller deployment inscription and lower deployment cost. Use Solidity’s optimizer, avoid unused functions, and consider splitting large contracts into smaller, focused modules.
# Enable the Solidity optimizer when compiling
forge build --optimize --optimize-runs 200
For operations with large payloads (batch operations, bulk data), applying NADA or ZSTD compression before inscribing can reduce inscription size by 3–5x. The module decompresses the data before execution, so your contract receives normal ABI-encoded calldata.

​
Padding to increase gas budget

Sometimes your calldata is small, but the operation itself requires more computation than the inscription size allows. For this case, you can add JSON padding to the inscription to increase the gas budget without changing the logical content of the call. 
{
  "op": "call",
  "data": "0xabcdef...",
  "padding": "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
}
Use padding responsibly. Padding increases Bitcoin fees because it increases inscription size. Only pad when you have confirmed that the operation genuinely requires more gas than the unpadded inscription provides. Do not pad speculatively.

​
Rough cost envelopes

Costs scale with two factors:
  1. Byte size of the inscription
  2. Bitcoin network fee rate at time of submission
As a rough guideline:
OperationApproximate inscription sizeNotes
Simple token transfer~100 bytesVery inexpensive
Complex contract call~500–2,000 bytesDepends on calldata
Contract deployment (small)~1–10 KBDepends on bytecode size
Contract deployment (large)~10–100 KBCan be significant
Compressed large call3–5x smaller than uncompressedUse NADA or ZSTD
These are guidelines, not guarantees. Actual costs depend on the Bitcoin fee rate at the time you submit. Estimate gas requirements before inscribing by simulating the execution off-chain.

​
Key principles

  • Estimate gas requirements before inscribing — simulate execution off-chain first
  • Smaller inscriptions are always cheaper; optimize for byte size
  • Compression (NADA, ZSTD) is the highest-leverage optimization for large payloads
  • Pad only when you have verified the computational need
  • Execution cost is deterministic and proportional to the resources you allocate on Bitcoin

​
No gas price logic in contracts

Because there is no dynamic gas price, contracts that use tx.gasprice for:
  • Anti-front-running logic
  • Fee estimation
  • Dynamic pricing mechanisms
will not behave as intended.
Do not use tx.gasprice or block.basefee in your contract logic. These values are meaningless in BRC2.0 and will not reflect actual execution costs.