In blockchain systems, there is a question that seems simple, but is actually very critical: should data be posted on-chain? When should it be posted? And how should it be posted?

Many people think that as long as data is written on-chain, that’s enough. But it’s not that simple. There are several issues you must face:

• On-chain costs are very high

• Data volume is continuously increasing

• System performance will be affected

So how to publish data more efficiently has become a shared pursuit in the industry. And today’s topic, Data Posting Strategy, is exactly about this.

• Click to register SuperEx

• Click to download the SuperEx APP

• Click to enter SuperEx CMC

• Click to enter SuperEx DAO Academy — Space

What is Data Posting Strategy

Let’s start with a simple definition: Data Posting Strategy refers to how, when, and in what form a system submits data to the blockchain.

There are three key points here:

• What data is posted

• When it is posted

• In what form it is posted

Different choices will directly affect cost, performance, and security.

Why Data Posting Strategy matters: traditional pain points

In traditional blockchains, most data is directly written on-chain. This approach is simple, but the problems are obvious:

• High cost: on-chain storage is expensive, the more data, the higher the cost

• Limited performance: every piece of data needs to be processed, which slows down the system

• Difficult scalability: once data volume increases, network pressure rises rapidly

So in newer architectures, not all data needs to be posted on-chain immediately.

Core idea of Data Posting Strategy

The core of Data Posting Strategy is essentially a balancing problem: security vs cost vs performance

1. Different data has different importance

Some data must be posted on-chain because it needs to be verified, such as:

• Final state

• Asset changes

But some data does not need to be on-chain at all, such as:

• Intermediate computation processes

• Temporary states

2. Not all data needs to be posted in real time

Many systems choose delayed posting, meaning processing happens off-chain first, and then results are submitted together.

This can:

• Reduce frequency

• Save costs

3. Data can be compressed

Not all data needs to be fully stored. We can use summaries or compression methods, such as:

• Batch packaging

• Hash commitments

Using less space to represent more information.

Common Data Posting Methods

1. Full on-chain posting

All data is directly written on-chain.

• The simplest

• The most secure

• But also the most expensive

The advantage is straightforward: transparency.

All data is on-chain, anyone can view and verify it. This means no additional trust is required, and the system logic is clearer.

But the problem is also obvious: the more data, the higher the cost. And as users increase, this model becomes difficult to scale.

So it is more suitable for systems with small data volume or scenarios with extremely high security requirements.

2. Batch posting

Multiple pieces of data are packaged and then submitted together, reducing costs. This approach is very common in Layer2.

The core idea is: combine multiple operations into a single on-chain submission, significantly reducing the number of interactions.

For example: originally, 100 transactions require 100 submissions. Now they can be packaged into 1 submission, greatly reducing cost.

But there is a trade-off: data is not posted in real time, which means there is some delay.

So this approach is more suitable for high-frequency operations where real-time requirements are not strict.

3. Posting only data summaries

Only submit a “proof” of the data (such as a hash), while the actual data is stored off-chain.

The core idea is: the chain stores the “result,” not the “process.” Through the summary, data integrity can be ensured, but the actual content must be retrieved off-chain.

This greatly reduces on-chain storage pressure, but also introduces a new issue: if off-chain data is unavailable, it cannot be verified.

So this method usually needs to be combined with data availability solutions.

4. On-demand posting

Data is only submitted when needed, improving efficiency.

This approach is more flexible. Under this model, the system does not proactively publish all data, but submits only under certain conditions.

For example:

• When disputes occur

• When verification is needed

• When users actively request

This avoids large amounts of unnecessary data consuming resources. However, it also means that by default, data is not on-chain, which requires users to trust the system to some extent, or requires mechanisms to ensure data can be accessed when needed.

Side note: Data Availability problem

Data posting is not just about whether data is on-chain, but also whether it can be accessed.

If data is unavailable, it cannot be verified. This is known as Data Availability.

A good data posting strategy must ensure that data can be accessed when needed.

Real-world applications

In practice, these strategies are already widely used.

For example:

• Rollups batch-submit transaction data

• Some systems only submit state summaries

This improves efficiency while maintaining security.

Designing a Data Posting Strategy is essentially making trade-offs

• Prioritize security: more on-chain data but higher cost

• Prioritize cost: less on-chain data but relies on off-chain

• Prioritize performance: delayed submission but requires batching

There is no perfect solution. The key is to find the right balance for the specific scenario.

Conclusion

As blockchain enters a new stage, systems are no longer simply about “putting all data on-chain,” but are becoming more refined.

• What should go on-chain

• What can stay off-chain

• When data should be posted

Data Posting Strategy is the key to solving these questions. Once you understand this, you’ll realize that many so-called “performance improvements” are essentially changes in how data is handled.