An inscription attaches data to a ledger by placing bytes in a transaction’s witness, calldata, blob, or state, then giving those bytes a protocol-defined identity.

The practical result is a verifiable record that can outlive the application that created it. A document hash, image, token attribute, or rollup batch can be tied to a block without relying on one company’s database. The choice of attachment matters, however, because “on-chain” does not mean the same thing on every network.

Bitcoin attaches content to a sat

Bitcoin inscriptions use transaction witness data and ordinal tracking to associate content with an individual satoshi. The process has two transactions: a commit transaction creates a Taproot output that commits to a script, and a reveal transaction spends that output, exposing the script in its witness.

Inside the witness is an inscription envelope: an unexecuted OP_FALSE OP_IF section containing the protocol marker, content type, and body. Because the conditional branch is never executed, the data does not change the spending logic. An indexer parses the envelope and assigns the inscription to a sat according to ordinal theory; later transfers follow that sat through Bitcoin’s normal UTXO rules.

This is the important edge case: Bitcoin consensus validates the transaction, not the meaning of the inscription. Ordinal-aware wallets and indexers supply the attachment model. Spending an output carelessly can therefore separate a sat from the content users thought they were carrying.

Ethereum separates history from state

Ethereum offers several places to put data, and each answers a different question.

• Calldata is part of a transaction’s permanent history and is cheaper than contract storage, but contracts cannot later read old calldata as state.
• Events and logs are useful for indexers and wallets, but smart contracts cannot use them as on-chain memory.
• Contract storage is readable by other contracts and protected by the state root, making it suitable for ownership, status, or metadata that applications must query directly.
• Blobs, introduced for data availability, are designed for temporary publication rather than permanent inscription; they are pruned from ordinary history after roughly eighteen days.

For a permanent Ethereum record, calldata is often the sensible middle ground: the bytes are committed to the chain’s history without occupying long-term application state. For an NFT attribute that must control future contract behavior, storage is the right layer despite its higher gas cost. A hash in calldata is cheaper still, but it proves only that some external file matched that hash; it does not preserve the file itself.

Polkadot records the extrinsic, not automatically the file

On the Polkadot Network, a simple inscription can be submitted through a system remark extrinsic. system.remarkWithEvent accepts arbitrary bytes and emits an event that indexers can observe, while the signed extrinsic remains part of block history.

That is useful for timestamps, attestations, and compact commitments. It is not the same as writing a durable object into runtime storage. If an application needs the data to affect balances, ownership, or execution, a pallet must write it into state; if it only needs proof that data existed, a hash in a remark may be enough.

The deciding question is what must survive

Use witness data when the goal is a Bitcoin-native artifact whose movement follows a UTXO. Use Ethereum calldata or a Polkadot remark for an auditable historical record. Use contract or pallet storage when other on-chain code must read and update the data. Use a blob only when temporary availability is sufficient.

A bridge does not change those rules. If an asset moves between Ethereum Mainnet and Manta Pacific, Manta Bridge belongs to the transport leg; it does not turn calldata into a Bitcoin-style inscription.

Use the Manta Bridge route when that cross-network movement is the decision in front of you.