When Ethereum's Dencun upgrade introduced "blobs" in early 2024, it marked a pivotal shift in how blockchains handle data. Blobs, or Binary Large Objects, are specialized data structures designed to store larger amounts of data on-chain at significantly reduced costs. Originally conceived to address Ethereum's data availability challenges for layer-2’s, this innovation has sparked a revolution in blockchain data efficiency.

But what if I told you that Fuel is taking the blob concept even further with a novel implementation that could dramatically reduce transaction costs while maintaining security?

On Ethereum, blobs serve primarily as data carriers for rollups, allowing L2 solutions to post compressed transaction data to L1 at lower costs. These blobs are temporary storage solutions – available for about two weeks before being pruned from the network.

Fuel's implementation, however, takes a fundamentally different approach. Rather than serving merely as transient data carriers, Fuel's blobs are persistent, reusable pieces of code that can be referenced across multiple transactions. This distinction is critical to understanding why Fuel's approach is so revolutionary.

Before diving deeper into Fuel's blob innovation, let's understand what predicates are in the Fuel ecosystem.

Predicates in Fuel are similar to smart contracts but with a key difference: they're pure verification functions that return either true or false. These stateless verification logic pieces decide whether a transaction is valid without changing state themselves. Think of them as sophisticated locks that can be programmatically unlocked only under specific conditions.

Traditionally, the entire predicate code needs to be included in each transaction that uses it, which can lead to significant overhead for complex verification logic.

Here's where Fuel's innovation shines. Instead of including the entire predicate code in every transaction, Fuel allows predicates to be:

1. Stored once as a blob on the blockchain

2. Referenced by transactions using a small "loader code"

3. Executed on-demand by fetching the blob and applying transaction-specific configurables

The result? A dramatic reduction in transaction size and fees.

The technical process involves:

1. Splitting the predicate into code and configurables sections

2. Storing the code section as a blob with a unique ID (SHA-256 hash of the code)

3. Creating a small loader code that references the blob and includes transaction-specific configurables

4. Executing the loader, which fetches the blob and applies the configurables at runtime

This approach allows multiple users to share the same blob/predicate while customizing the predicate's behaviour to suit the individual user through unique configurables. We’ve included a technical deep dive after the conclusion about how Fuel achieves the same functionality a code based predicate but as a blob predicate. We also show how addresses are calculated for the technically curious.

Our analysis shows just how transformative blob-based predicates can be for transaction efficiency:

For our Module 03 predicate; one that deals with EVM ERC20 token transfer backwards compatibility on Fuel. The above chart shows the Fuel ScriptTransaction size comparison between adding traditional Coin Input UTXO as full code predicates vs blob-based predicates. The black data points and trend line represent traditional code base predicate inputs adding to the overall transaction size. The purple data points and trend line show the same transaction but using blob-based predicates.

Transactions with one or more Native assets as inputs result in an overall transaction size decease of 95.38%

For the Predicate bytecode itself “blobifying” it:

• Traditional predicate: 25,416 bytes

• Blob-based predicate: 248 bytes

• Reduction: 99.02%

This isn't just marginal improvement, it's a complete paradigm shift in how we think about on-chain verification.

We have posted two transaction of Fuels Testnet that display how dramatic the difference in using blob-predicates is.

The transaction setup: Send 1.2 units of our SRC20 test asset FUEL! from a Zap Wallet to another Zap Wallet address. The result is Gas used going from 5,614,242 to 834,711 and the network fee going from $0.1 to $0.003 - that’s a 97% decrease in transaction fees!

Standard Predicates Transaction:

https://app-testnet.fuel.network/tx/0x08e58d01d1e31c3bc721e8f6945ff05baca4297173f2ef1a08ae70e7d8892c87/standard

Using Blob-predicates:

https://app-testnet.fuel.network/tx/0x0c754fe5cf2d5537d1c4399e1bf56c2c0e5a4929a089e88779a554ed67c9b853/standard

The advantages extend far beyond mere byte counts:

With transaction fees directly tied to data size, a 97% reduction in predicate size translates to significantly lower costs for users.

Smaller transactions mean more can fit into each block, effectively increasing network throughput without changing the underlying block parameters.

Lower fees and faster confirmations translate directly to better user experiences, particularly for dApps that require frequent predicate verifications.

Once a blob is deployed, any number of users can reference it, creating a network effect where popular verification logic becomes increasingly efficient as adoption grows.

Looking ahead, at Zap, we are exploring even more advanced blob-based patterns, including multi-blob compositions where complex predicates can be assembled from multiple reusable components. This modular approach could create an ecosystem of standardized verification building blocks, further enhancing efficiency and promoting code reuse.

Fuel's blob-based predicates represent a blueprint for how smart contract platforms can achieve greater efficiency without compromising on security or expressiveness.

By rethinking how code is stored and referenced on-chain, Fuel demonstrates that the limitations we often take for granted in blockchain systems can be overcome through clever architecture.

For Zap this means being able to implement complex verification logic without worrying about prohibitive transaction costs and sizes. For Zap Wallet users, it means faster, cheaper interactions with the blockchain.

As the blockchain space continues to mature, innovations like blob-based predicates remind us that we're still in the early days of discovering what's possible in this technology. And if Fuel's approach is any indication, the future is looking increasingly efficient.

For the technically inclined, We will work backwards and give you the TLDR of address calculation, then if you would like the nuts and bolts, you can keep reading to explore how blob-based predicates are constructed at the byte level:

The predicate address is derived through a two-step hash process:

1. Calculate the Merkle root of the loader code (which includes the blob ID and configurables)

2. Calculate SHA256(FUEL_CONTRACT_ID || code_root)

This ensures that predicates with identical code but different configurables can share the same blob while maintaining unique addresses.

LoaderCode = Instructions || BlobID || ConfigurablesLength || Configurables
CodeRoot = MerkleTree(LoaderCode)
PredicateAddress = SHA256(FUEL_CONTRACT_ID || CodeRoot)

In comparison to the original “full fat” predicate, the blob based predicate loader code looks like:

The loader instructions themselves are a compact sequence of 12 operations that:

1. Locate the blob

2. Load it into memory

3. Apply the configurables

4. Jump to the loaded code

The loader instructions:

So basically the original predicate is split in to the executable code section and the configurables section. The executable code section is deployed on chain and given a Blob-ID. The Loader code is what gets built when you want to “call on” the predicate in a transaction.

That’s a wrap!

When Ethereum's Dencun upgrade introduced "blobs" in early 2024, it marked a pivotal shift in how blockchains handle data. Blobs, or Binary Large Objects, are specialized data structures designed to store larger amounts of data on-chain at significantly reduced costs. Originally conceived to address Ethereum's data availability challenges for layer-2’s, this innovation has sparked a revolution in blockchain data efficiency.

But what if I told you that Fuel is taking the blob concept even further with a novel implementation that could dramatically reduce transaction costs while maintaining security?

On Ethereum, blobs serve primarily as data carriers for rollups, allowing L2 solutions to post compressed transaction data to L1 at lower costs. These blobs are temporary storage solutions – available for about two weeks before being pruned from the network.

Fuel's implementation, however, takes a fundamentally different approach. Rather than serving merely as transient data carriers, Fuel's blobs are persistent, reusable pieces of code that can be referenced across multiple transactions. This distinction is critical to understanding why Fuel's approach is so revolutionary.

Before diving deeper into Fuel's blob innovation, let's understand what predicates are in the Fuel ecosystem.

Predicates in Fuel are similar to smart contracts but with a key difference: they're pure verification functions that return either true or false. These stateless verification logic pieces decide whether a transaction is valid without changing state themselves. Think of them as sophisticated locks that can be programmatically unlocked only under specific conditions.

Traditionally, the entire predicate code needs to be included in each transaction that uses it, which can lead to significant overhead for complex verification logic.

Here's where Fuel's innovation shines. Instead of including the entire predicate code in every transaction, Fuel allows predicates to be:

1. Stored once as a blob on the blockchain

2. Referenced by transactions using a small "loader code"

3. Executed on-demand by fetching the blob and applying transaction-specific configurables

The result? A dramatic reduction in transaction size and fees.

The technical process involves:

1. Splitting the predicate into code and configurables sections

2. Storing the code section as a blob with a unique ID (SHA-256 hash of the code)

3. Creating a small loader code that references the blob and includes transaction-specific configurables

4. Executing the loader, which fetches the blob and applies the configurables at runtime

This approach allows multiple users to share the same blob/predicate while customizing the predicate's behaviour to suit the individual user through unique configurables. We’ve included a technical deep dive after the conclusion about how Fuel achieves the same functionality a code based predicate but as a blob predicate. We also show how addresses are calculated for the technically curious.

Our analysis shows just how transformative blob-based predicates can be for transaction efficiency:

For our Module 03 predicate; one that deals with EVM ERC20 token transfer backwards compatibility on Fuel. The above chart shows the Fuel ScriptTransaction size comparison between adding traditional Coin Input UTXO as full code predicates vs blob-based predicates. The black data points and trend line represent traditional code base predicate inputs adding to the overall transaction size. The purple data points and trend line show the same transaction but using blob-based predicates.

Transactions with one or more Native assets as inputs result in an overall transaction size decease of 95.38%

For the Predicate bytecode itself “blobifying” it:

• Traditional predicate: 25,416 bytes

• Blob-based predicate: 248 bytes

• Reduction: 99.02%

This isn't just marginal improvement, it's a complete paradigm shift in how we think about on-chain verification.

We have posted two transaction of Fuels Testnet that display how dramatic the difference in using blob-predicates is.

The transaction setup: Send 1.2 units of our SRC20 test asset FUEL! from a Zap Wallet to another Zap Wallet address. The result is Gas used going from 5,614,242 to 834,711 and the network fee going from $0.1 to $0.003 - that’s a 97% decrease in transaction fees!

Standard Predicates Transaction:

https://app-testnet.fuel.network/tx/0x08e58d01d1e31c3bc721e8f6945ff05baca4297173f2ef1a08ae70e7d8892c87/standard

Using Blob-predicates:

https://app-testnet.fuel.network/tx/0x0c754fe5cf2d5537d1c4399e1bf56c2c0e5a4929a089e88779a554ed67c9b853/standard

The advantages extend far beyond mere byte counts:

With transaction fees directly tied to data size, a 97% reduction in predicate size translates to significantly lower costs for users.

Smaller transactions mean more can fit into each block, effectively increasing network throughput without changing the underlying block parameters.

Lower fees and faster confirmations translate directly to better user experiences, particularly for dApps that require frequent predicate verifications.

Once a blob is deployed, any number of users can reference it, creating a network effect where popular verification logic becomes increasingly efficient as adoption grows.

Looking ahead, at Zap, we are exploring even more advanced blob-based patterns, including multi-blob compositions where complex predicates can be assembled from multiple reusable components. This modular approach could create an ecosystem of standardized verification building blocks, further enhancing efficiency and promoting code reuse.

Fuel's blob-based predicates represent a blueprint for how smart contract platforms can achieve greater efficiency without compromising on security or expressiveness.

By rethinking how code is stored and referenced on-chain, Fuel demonstrates that the limitations we often take for granted in blockchain systems can be overcome through clever architecture.

For Zap this means being able to implement complex verification logic without worrying about prohibitive transaction costs and sizes. For Zap Wallet users, it means faster, cheaper interactions with the blockchain.

As the blockchain space continues to mature, innovations like blob-based predicates remind us that we're still in the early days of discovering what's possible in this technology. And if Fuel's approach is any indication, the future is looking increasingly efficient.

For the technically inclined, We will work backwards and give you the TLDR of address calculation, then if you would like the nuts and bolts, you can keep reading to explore how blob-based predicates are constructed at the byte level:

The predicate address is derived through a two-step hash process:

1. Calculate the Merkle root of the loader code (which includes the blob ID and configurables)

2. Calculate SHA256(FUEL_CONTRACT_ID || code_root)

This ensures that predicates with identical code but different configurables can share the same blob while maintaining unique addresses.

LoaderCode = Instructions || BlobID || ConfigurablesLength || Configurables
CodeRoot = MerkleTree(LoaderCode)
PredicateAddress = SHA256(FUEL_CONTRACT_ID || CodeRoot)

In comparison to the original “full fat” predicate, the blob based predicate loader code looks like:

The loader instructions themselves are a compact sequence of 12 operations that:

1. Locate the blob

2. Load it into memory

3. Apply the configurables

4. Jump to the loaded code

The loader instructions:

So basically the original predicate is split in to the executable code section and the configurables section. The executable code section is deployed on chain and given a Blob-ID. The Loader code is what gets built when you want to “call on” the predicate in a transaction.

That’s a wrap!