There is no single correct home for dapp data. The source material frames the decision as a set of storage strategies that either put information directly on the blockchain or secure it by the blockchain, chosen against several criteria. The useful short answer: use calldata only for data consumed inside a single transaction, use events when you need a durable public log that offchain systems can read, and use offchain storage with an onchain hash when the payload is large or confidential and you mainly need integrity.
What each location actually is
Calldata is the input attached to a transaction. It exists to feed a contract call, not to act as a database. One verified constraint is decisive for design: information in calldata cannot come directly from the blockchain itself, and calldata is only available in the transaction that includes it. Treat it as handoff space between the caller and the contract, not as storage you can query later.
Events are the log a contract emits while executing. The source is blunt about their limits: events are not accessible onchain at all. A contract cannot read its own past logs during later execution. Events are for offchain consumers: indexers, dashboards, and wallets that reconstruct state from logs.
Offchain storage with an onchain hash keeps the payload outside the chain and posts a commitment inside it. The source notes the different solutions here all have excellent integrity, because hashes are posted on L1. Whatever sits behind the hash cannot be silently swapped without breaking the commitment.
Comparing the three options
| Location | Readable onchain later | Readable offchain | Main strength | Main constraint |
|---|---|---|---|---|
| Calldata | Only within that transaction | Only by inspecting that transaction | Direct input to the call | Not available after the transaction ends |
| Events | No | Yes, from logs | Public, durable log | Inaccessible onchain at all |
| Offchain + onchain hash | Only the hash | Yes, if the payload is served | Integrity via L1 hash | Availability depends on offchain providers |
The comparison exposes a tradeoff the source states as a question worth asking: is it necessary to facilitate easy access to the information from every node? If yes, you are pushed toward onchain commitments. If not, offchain storage behind a hash can be acceptable. That question is the single most useful filter before picking a location.
The security lens the source applies
The source breaks information security into three attributes. Confidentiality means unauthorized entities are not allowed to read the information. Integrity means the information is correct and cannot be changed by unauthorized entities or in unauthorized ways, with the example of transferring ERC-20 tokens without a Transfer event. Availability means the information is available to any authorized entity.
Confidentiality is explicitly set aside for this context. The source says there are no secrets on the blockchain, and that blockchains work because anybody can verify the state transitions, so it is impossible to use them to store secrets directly. It concedes that confidential information can be stored on the blockchain, but only through approaches that rely on some offchain component to store at least a key. Offchain storage with an onchain hash inherits this pattern: the hash is public, the payload is not on the chain, and the key that unlocks it lives offchain.
Integrity is where the options differ least. On the blockchain, every node verifies every state change, which ensures integrity. Offchain-plus-hash preserves integrity through the L1 hash. The gap between them is not correctness; it is where the verification happens and what the chain itself retains.
Availability is where they differ most. On the blockchain, availability is usually achieved by having the information available on every full node. Offchain data secures exactly the opposite guarantee: the hash proves what the data should be, but does not by itself guarantee anyone can fetch it. A commitment to a payload nobody serves is a promise without a delivery mechanism.
Who reads the data matters
The source notes that computers running a full-scale node can perform more processing than a light client in an application running in a browser. This is a reader-facing distinction, not a ranking. An operator running full nodes can index logs and scan transactions at a scale a browser light client cannot match. A browser-side dapp that depends on scanning historical calldata or reconstructing state from events is asking a light client to do full-node work.
That leads to a checklist worth running before you choose a location:
- Does the contract need this value during a later transaction? If yes, neither calldata nor events will work as storage; commit a hash onchain and keep the payload offchain.
- Does an offchain consumer need a durable, ordered record of the change? If yes, an event is the natural fit, since events are not accessible onchain at all and exist for log readers.
- Does the data only need to reach the contract during the call that includes it? If yes, calldata is sufficient, remembering it is only available in the transaction that includes it.
- Does every node need easy access to the information? If yes, onchain availability is the requirement to design around.
- Is any part of the payload meant to stay private? If yes, plan for the offchain key component, because there are no secrets on the blockchain.
A worked example
Hypothetical: a dapp publishes a 50 KB metadata document. Posting it in calldata gives the contract access during that transaction, but the document is not retrievable onchain afterward. Emitting it as an event makes it visible to indexers but unreachable to the contract. Storing the document offchain and posting a 32-byte hash onchain keeps integrity, because hashes are posted on L1, while the 50 KB itself remains the availability risk.
That example is illustrative, not a measurement. The point is structural: the hash buys integrity, the offchain host supplies availability, and the chain itself remembers only the commitment.
What the source does not say
The provided material does not specify costs, gas consumption, or size limits for any of these approaches, so no recommendation here should be read as a pricing comparison. It does not give implementation steps, library choices, or retrieval protocols for offchain payloads. It does not say which approach is best for any particular application type, and it does not rank the options overall. It also does not address who is responsible when offchain data becomes unavailable, or what redundancy an operator should maintain.
What it does establish is the shape of the decision: confidentiality is largely off the table for onchain data, integrity is strong across all three options, and availability is the property that separates them. Choosing a location is choosing which of those three you are willing to manage outside the chain.