A Comparative Study of Bitcoin, Ethereum, Solana, and Cardano (CIP-20)
1. Introduction
In modern blockchain systems, the initial role of a transaction was solely that of value transfer. However, real-world applications in finance, supply chain management, Decentralized Autonomous Organizations (DAOs), and auditing require transactions to carry additional contextual information. This context defines the "meaning" of the transaction and includes elements such as:
- Invoice IDs
- Payment references
- Asset-describing metadata
- Logical states (votes, swaps, execution parameters)
This necessity has led to the formation of a new operational layer within blockchain architecture: The On-Chain Message/Metadata Layer.
Formally defined, on-chain metadata is descriptive data stored directly within a transaction or state. It is protected by the blockchain's consensus mechanism, ensuring it is permanently recorded and tamper-proof.
Figure 1: From "Value Ledger" → "Semantic Ledger"
2. Taxonomy of On-Chain Message Mechanisms
Major blockchain protocols have implemented their "message layers" following four distinct architectural philosophies:
2.1. Bitcoin: Script-Level Embedding (OP_RETURN)
Bitcoin utilizes a specific opcode, OP_RETURN, to embed arbitrary data within a transaction output.
Mechanism: Data is embedded in an output script that is marked as unspendable. This allows the data to exist on the ledger without cluttering the Unspent Transaction Output (UTXO) set used for balance calculations.
Constraints: Severely limited in size (~80 bytes).
Core Nature: "Data embedding in a payment-first system." It acts primarily as a passive anchoring point for off-chain data.
Figure 2: Bitcoin OP_RETURN structure
2.2. Ethereum: Transaction Calldata
In Ethereum, the "message layer" is integrated into the calldata field, originally designed to carry input data for smart contract function calls.
Mechanism: The data can remain unprocessed (raw data) or be decoded and processed by smart contract logic.
Constraints: Theoretically flexible, but limited practically by high gas costs per byte.
Core Nature: "A low-level arbitrary data layer with optional computation." The message is coupled with the execution environment (EVM).
Figure 3: Ethereum calldata flow
2.3. Solana: Instruction Data
Solana's architecture views a transaction as an ordered list of instructions to be executed.
Mechanism: Each instruction specifies a program ID, the accounts it will interact with, and a data payload (instruction data).
Core Nature: "Message tightly coupled with execution logic." The message acts directly as input fuel for parallel execution.
Figure 4: Solana instruction architecture
2.4. Cardano: Structured Metadata (CIP-20)
Cardano separates value transfer from descriptive information by providing a dedicated auxiliary_data field within the transaction body.
Mechanism: Data is strongly structured using CBOR (Concise Binary Object Representation), supporting JSON-like maps and arrays.
Standardization (CIP-20): Cardano Improvement Proposal 20 standardizes label registries to ensure interoperability.
Core Nature: "A structured, standardized transaction-level message layer." It provides a clean "Meaning Layer" without requiring smart contract computation.
Figure 5: Cardano metadata structure
3. Architectural Comparison
The following table summarizes the foundational differences in how these systems handle on-chain messages.
| Property | Bitcoin | Ethereum | Solana | Cardano (CIP-20) |
|---|---|---|---|---|
| Design Philosophy | Payment-first | Compute-first | Execution-first | Data-centric |
| Message Location | Script (OP_RETURN) | Calldata | Instruction Data | auxiliary_data field |
| Data Structure | Raw bytes | Raw bytes | Raw bytes | Structured (CBOR/JSON-like) |
| Standardization | ❌ None | ❌ App-specific | ❌ Program-specific | ✅ CIP Registry System |
| Requires Contract | ❌ No | ❌/✅ Optional | ✅ Yes | ❌ No |
Figure 6: Architectural philosophy of 4 blockchains
4. Economic and Resource Cost Models
A critical scientific distinction among these chains is how they price blockspace for data storage. Every message creates a "Tragedy of the Commons" risk regarding ledger bloat.
4.1. Cardano: Linear Pricing and Predictability
Cardano's fee model is predominantly based on transaction size in bytes. Adding structured metadata increases the transaction size, and the fee rises linearly. This cost is independent of network congestion.
👉 Outcome: Predictable, low-cost usage suitable for enterprise auditing.
Figure 7: Cardano linear & predictable fee model
4.2. Ethereum: Gas-Based Pricing and Volatility
Ethereum calculates costs based on gas per byte within calldata (currently 16 gas for non-zero bytes). The actual cost in ETH is highly volatile, as it depends entirely on the current gas price, which spikes during congestion.
👉 Outcome: Highly volatile cost, often becoming expensive to store plain text.
Figure 8: Ethereum volatile gas-based pricing
4.3. Bitcoin: vByte Pricing and Scarcity
Bitcoin fees are determined by blockspace scarcity, priced in Satoshis per vByte. Because blockspace is extremely limited, using it for data embedding is considered a "luxury" usage that must compete with standard financial transactions.
👉 Outcome: High cost during busy periods; intended only for critical data anchoring.
Figure 9: Bitcoin scarcity-based fee market
4.4. Solana: Execution-Tied Fees
Solana fees are nominally fixed per signature. However, the constraints are computational (Compute Units) and size-based. While storing simple instruction data is inexpensive, it is tied to the program execution fee structure.
👉 Outcome: Metadata usage is effectively inexpensive due to high throughput.
Figure 10: Solana fixed fee + compute limits
Figure 11: Fee model comparison: All Four Chains
5. Security, Integrity, and Immutability (Storage vs. Semantics)
5.1. Immutability
Across all studied chains, once a transaction containing metadata is confirmed through their respective consensus mechanisms (Proof of Work or Proof of Stake), the data becomes fundamentally tamper-proof. This is guaranteed by cryptographic hashing; any alteration to the data would invalidate the transaction hash and the block hash. On-chain metadata is permanently recorded data.
Figure 12: Two nested defense layers
5.2. Semantic Security (Smart Contract Validation)
While storage security is universal across all chains, semantic security varies:
- Ethereum & Solana: Smart contracts can validate the logic and meaning of metadata before state changes occur.
- Bitcoin & Cardano: Metadata is passively stored; semantic validation must occur off-chain or through separate validation layers.
Figure 13: Security layers in blockchain systems
6. Data Flow: From Blockchain to User Experience
The journey of on-chain metadata from raw blockchain data to user-facing applications involves several processing layers:
Figure 14: Journey from raw bytes → User UX
6.1. Risk at Interface Layer
While the blockchain layer provides cryptographic security, the interface layer remains a potential vulnerability:
- Metadata spoofing: Fake websites may display incorrect or manipulated metadata.
- Injection attacks: Malicious scripts in metadata could compromise user interfaces.
Conclusion: On-chain data is safe, but the interface remains a weak point requiring proper validation and security controls.
7. Conclusion
On-chain metadata represents a critical design primitive in modern blockchain architecture. While Bitcoin pioneered data embedding through OP_RETURN, Ethereum and Solana integrated metadata into their execution models, and Cardano introduced a structured, standardized approach with CIP-20.
The choice of metadata mechanism significantly impacts:
- Cost predictability: Cardano and Solana offer the most predictable fee structures
- Standardization: Cardano's CIP registry provides ecosystem-wide interoperability
- Security model: Ethereum and Solana offer semantic security through smart contracts
- Developer experience: Each approach offers different trade-offs in complexity and flexibility
As blockchain adoption grows in enterprise and institutional contexts, the ability to attach rich, structured metadata to transactions becomes increasingly important for auditing, compliance, and interoperability between systems.
Figure 15: Decision matrix for blockchain metadata approaches