OP_RETURN: How the Martian Republic Writes History Into the Blockchain

Every vote in the Martian Republic, every citizenship application, every proposal submission — they all share one thing in common. Somewhere in the transaction that records them, there is a tiny piece of data embedded directly into the blockchain. Not a transfer of coins. Not a payment. A permanent, immutable, timestamped record. This is OP_RETURN, and it is the most underappreciated tool in blockchain technology.

OP_RETURN is an opcode — a single instruction in Bitcoin's scripting language — that allows up to 80 bytes of arbitrary data to be embedded in a transaction output. Eighty bytes. That is less than this sentence. But in those 80 bytes, the Martian Republic stores the cryptographic proof of a citizen's identity, the fingerprint of a congressional proposal, the record of a vote, the timestamp of a forum post. Eighty bytes at a time, the Republic writes its entire history into a ledger that no one can alter, no one can censor, and no one can erase.

To understand why OP_RETURN matters, you need to understand what it replaced, what it does, and why the Martian Republic chose it over more complex alternatives. This is that story.

What Is OP_RETURN? The Technical Foundation

Bitcoin — and Marscoin, which is a fork of Bitcoin's codebase — uses a scripting language called Bitcoin Script. It is not a general-purpose programming language like Python or JavaScript. It is a stack-based, intentionally limited language designed to do one thing: define the conditions under which cryptocurrency can be spent.

Every Bitcoin transaction has inputs and outputs. Inputs reference previous transaction outputs and provide proof (a digital signature) that the sender is authorized to spend those coins. Outputs define new conditions for spending: typically "whoever can prove they own this public key can spend these coins." The output script is called the scriptPubKey; the input proof is called the scriptSig.

A standard pay-to-public-key-hash (P2PKH) output looks like this in Script:

OP_RETURN works differently. When the script interpreter encounters OP_RETURN, it immediately marks the output as provably unspendable and halts execution. Nothing after OP_RETURN is evaluated as script. This means any data placed after OP_RETURN is treated as arbitrary payload — it is stored in the blockchain but never executed as code. The output can never be spent, because the script always fails.

This "provably unspendable" property is critical. Every standard transaction output creates an entry in the UTXO set (Unspent Transaction Output set) — the database of all coins that can still be spent. Nodes must keep the UTXO set in fast-access memory to validate new transactions. If you embed data in a normal output (by encoding it as a fake address, for example), that output enters the UTXO set and stays there forever, bloating the database with entries that can never actually be spent. OP_RETURN outputs, because they are provably unspendable, can be safely pruned from the UTXO set immediately. The data is preserved in the block history, but it does not pollute the UTXO set. Clean data storage, no database bloat.

The History: Before OP_RETURN

Before OP_RETURN existed, people who wanted to embed data in the Bitcoin blockchain had to resort to hacks. The most common: encoding data as a fake Bitcoin address. Take 20 bytes of data, format it as a P2PKH address, and send a tiny amount of bitcoin to that address. The data is now in the blockchain. But the "address" is not a real address — no one has the private key to spend those coins. The output sits in the UTXO set permanently, wasting memory on every full node in the network.

By 2013, this practice was becoming a problem. The UTXO set was growing with thousands of unspendable outputs from services like Counterparty and early timestamping experiments. Bitcoin developers debated the issue extensively. Some argued that the blockchain should be used only for financial transactions. Others argued that data embedding was a legitimate use case that needed a clean mechanism rather than prohibition.

The pragmatists won. Bitcoin Core 0.9.0, released on March 19, 2014, introduced OP_RETURN as a standardized way to embed data in transactions. The initial limit was 40 bytes of payload. Bitcoin Core 0.11.0 (July 2015) raised the limit to 80 bytes. The message was clear: if people are going to embed data in the blockchain (and they are), give them a tool that does it cleanly.

The Art of 80 Bytes

What can you fit in 80 bytes? More than you might think. Eighty bytes is 640 bits — enough for:

• A SHA-256 hash: 32 bytes. The cryptographic fingerprint of any document, any file, any dataset. If the hash matches, the content is authentic. If it does not match, something has been changed.
• An IPFS CID (Content Identifier): typically 46 bytes in base58 encoding. The address of any file on the InterPlanetary File System.
• A protocol prefix: 2–8 bytes. An identifier that tells software how to interpret the remaining data.
• A vote record: prefix (2–3 bytes) + proposal identifier (32 bytes) + vote choice (1 byte) = 35–36 bytes.
• A citizen registration pointer: prefix GP_ (3 bytes) + IPFS CID of identity JSON (46 bytes) = 49 bytes.

The Martian Republic uses every byte deliberately. Here is how the Republic's 80-byte budget is spent for each major transaction type:

Every transaction type fits comfortably within the 80-byte limit. The prefix is the routing key: software scanning the blockchain can instantly categorize transactions by type. GP_ means a citizen registration. CT_ means an endorsement. VT_ means a vote. No ambiguity, no parsing complexity, no wasted space.

A Brief History of Blockchain Notarization

The Martian Republic did not invent the idea of using blockchains as notarization infrastructure. The practice has a decade-long history, and understanding that history reveals why the Republic's approach is both proven and distinct.

2012: Proof of Existence

In 2012, Manuel Araoz — then a computer science student in Buenos Aires — launched Proof of Existence (proofofexistence.com), the first public service to timestamp documents on the Bitcoin blockchain. The concept was simple: hash a document, embed the hash in a Bitcoin transaction, and you have cryptographic proof that the document existed at the time the block was mined. Araoz reportedly timestamped his own PhD thesis as one of the first entries. The service is still running today.

2013–2014: The Colored Coins Era

Before OP_RETURN was standardized, projects like Colored Coins attempted to represent real-world assets on Bitcoin by "coloring" tiny amounts of bitcoin with metadata. The idea: a specific satoshi could represent a share of stock, a property deed, or a unit of gold. The implementation was crude — metadata was stuffed into multisig outputs and fake addresses — but the concept of using Bitcoin's ledger for non-financial records was established.

Counterparty (January 2014) and the Omni Layer (formerly Mastercoin, 2013) built more sophisticated protocols on top of Bitcoin for asset issuance and decentralized exchange. Both initially used data-in-address hacks before migrating to OP_RETURN when it became available. The Omni Layer was notably the original platform for Tether (USDT), the first major stablecoin — initially launched as "Realcoin" in October 2014, running entirely on Bitcoin OP_RETURN transactions before migrating to Ethereum years later.

2015–2018: Dedicated Notarization Protocols

Factom (2015) built an entire blockchain dedicated to data notarization, with periodic anchoring to Bitcoin for additional security. The U.S. Department of Homeland Security awarded Factom grants to secure Internet of Things device identity data using blockchain timestamping. The mortgage industry explored Factom for loan document verification.

OpenTimestamps (2016), created by Bitcoin Core developer Peter Todd, took a minimalist approach: aggregate thousands of timestamps into a single Merkle tree, embed only the root in one Bitcoin transaction. One transaction, one OP_RETURN, thousands of verified timestamps. The efficiency is remarkable — the per-document cost of notarization approaches zero.

Chainpoint (2017) standardized the format for blockchain timestamp proofs, creating an open standard (Chainpoint v3) that multiple services could interoperate with. Tierion, the company behind Chainpoint, processed millions of proofs anchored to Bitcoin and Ethereum.

2019–Present: Legal Recognition

The turning point came when legal systems began recognizing blockchain timestamps as evidence. In 2018, China's Hangzhou Internet Court ruled that blockchain-stored evidence is legally admissible, setting a precedent that has since been adopted across China's court system. Italy's Legislative Decree 135/2018 (Article 8-ter) explicitly granted legal validity to blockchain timestamps, stating that documents timestamped on a blockchain have the same legal effect as electronic timestamps under EU regulation. Multiple U.S. jurisdictions — including Vermont, Arizona, and Wyoming — have enacted legislation recognizing blockchain records as admissible evidence.

How the Martian Republic Uses OP_RETURN

Theory and history are context. Now for the specifics: how does the Republic actually use OP_RETURN in its day-to-day governance operations? Each use case follows the same architectural pattern — data on IPFS, pointer on-chain — but the details differ.

Citizen Registration (GP_ Transactions)

When a pioneer decides to apply for citizenship in the Martian Republic, the process generates a chain of cryptographic evidence that is both human-verifiable and machine-auditable:

1. Identity creation: The pioneer creates an identity JSON file containing their personal information: first name, last name, display name, a short biography, a profile photograph, and a liveness verification video. The photo and video are each uploaded to IPFS, producing their own Content Identifiers (CIDs). These CIDs are embedded in the identity JSON.
2. IPFS pinning: The complete identity JSON is pinned to IPFS. This produces a top-level CID — for example, QmeWf1LMZSah6R1FkDYrbHGwmeGR5mVbxJEHSaMvhNSEiQ — that uniquely identifies the pioneer's entire application package.
3. On-chain recording: A transaction is broadcast from the pioneer's civic address (the public key derived from their HD wallet's civic derivation path). The transaction includes an OP_RETURN output containing: the prefix GP_ (3 bytes, identifying this as a Governance Protocol citizen registration) followed by the IPFS CID (46 bytes). Total: 49 bytes of the 80-byte budget.
4. Mining and timestamping: The transaction is included in a block by Marscoin miners. The block header contains a timestamp and a proof-of-work hash. From this moment forward, the record is immutable: the pioneer applied for citizenship at block height X, at time T, and the complete content of their application is permanently retrievable at the embedded CID.
5. Verification by anyone: Any citizen, any auditor, any future historian can verify the application. Look up the GP_ transaction on a Marscoin block explorer. Extract the CID from the OP_RETURN data. Fetch the identity JSON from any IPFS node. Hash the fetched content and confirm it matches the CID. Follow the embedded CIDs to retrieve the photo and liveness video. The chain of evidence is complete, trustless, and independent of any central authority.

Endorsements (CT_ Transactions)

Citizenship in the Republic requires endorsement by existing citizens — a web-of-trust model where the community vouches for new members. Each endorsement is recorded on-chain:

1. An existing citizen decides to endorse a pioneer's application.
2. A transaction is broadcast from the endorser's civic address. The OP_RETURN output contains: the prefix CT_ (Citizen Trust, 3 bytes) followed by the endorsed pioneer's civic address or application CID.
3. The transaction is mined into a block.

The result: on-chain, timestamped, cryptographically signed proof that citizen X endorsed pioneer Y at block height Z. The endorsement cannot be forged (it requires the endorser's private key to sign the transaction). It cannot be revoked retroactively (the block is mined and immutable). It cannot be denied (the blockchain is a public, auditable record). This is reputation infrastructure with mathematical guarantees — something that no traditional system of letters of recommendation or character references has ever achieved.

Proposal Submission

When a citizen submits a proposal to Congress, the full text may be hundreds or thousands of words — far beyond the 80-byte OP_RETURN limit. The Republic's architecture handles this with the same IPFS + OP_RETURN pattern:

1. The proposal text is composed and stored on IPFS, producing a CID that uniquely identifies the exact proposal content.
2. A transaction is broadcast from the proposer's civic address. The OP_RETURN output contains: the prefix, the IPFS CID of the proposal, and a tier indicator (Signal, Operational, Legislative, or Constitutional — each with different quorum and voting requirements).
3. The transaction is mined, creating an immutable record of: who proposed it (civic address), what was proposed (IPFS CID, verifiable), when it was proposed (block timestamp), and at what governance tier.

This architecture makes proposal tampering cryptographically impossible. If someone claims the proposal originally said something different, the dispute is settled by mathematics: fetch the content from IPFS, hash it, compare to the on-chain CID. Match means authentic. Mismatch means altered. No committee, no judge, no administrator needed.

Vote Recording

Voting in the Republic uses a privacy-preserving protocol based on CoinShuffle — a decentralized mixing protocol that breaks the link between a citizen's identity and their vote. The process:

1. Before voting opens, eligible citizens participate in a CoinShuffle round. Each citizen contributes 1 MARS (the Republic's unit of account) and receives back 1 zubrin — a freshly mixed, unlinkable coin. The mixing breaks the transaction trail: no one can trace which zubrin came from which citizen.
2. To cast a vote, the citizen sends their zubrin as a miner fee (destroying it). The transaction's OP_RETURN output contains: the vote prefix, the proposal identifier (a hash or on-chain reference), and the vote choice — YES, NO, or ABSTAIN.
3. The transaction is mined. The vote is now on-chain: publicly verifiable (anyone can count the votes), permanently recorded (the block is immutable), and anonymous (the CoinShuffle mixing prevents tracing the vote back to the voter).

Forum Notarization

The Republic's forum — where citizens debate proposals, share ideas, and build community — is periodically anchored to the blockchain through a batch notarization process:

1. At regular intervals, all recent forum posts are collected and organized into a Merkle tree. Each post is hashed individually (leaf nodes), then pairs of hashes are combined and hashed again (branch nodes), recursively, until a single hash remains: the Merkle root.
2. The Merkle root (32 bytes) is embedded in an OP_RETURN transaction with the FN_ (Forum Notarization) prefix.
3. The transaction is mined, timestamping the entire batch.

The power of this approach is in the Merkle proof. Any individual forum post can be proven to have existed at the time of notarization by providing the chain of hashes from that post to the root. This proof is tiny (log₂(n) hashes for a batch of n posts) and independently verifiable. A batch of 1,024 posts requires only 10 hashes to prove any single post's inclusion. A batch of 1,048,576 posts requires only 20.

For the Republic, this means censorship-proof discussion. A citizen's argument, published on March 15 and included in that day's Merkle tree, is provably timestamped. No moderator, no administrator, no government — on Earth or Mars — can retroactively alter the record of what was said and when. The forum's content lives on IPFS; its integrity is anchored on-chain, 80 bytes at a time.

Why Not Just Use Smart Contracts?

This is the question that every Ethereum developer asks when they learn about the Republic's architecture. Why use a 1980s-era scripting language and an 80-byte data field when you could deploy Turing-complete smart contracts that execute arbitrary logic on-chain?

The answer is deliberate, considered, and rooted in the specific requirements of a colony where infrastructure failure means death.

Simplicity Is a Security Property

OP_RETURN is dead simple. It does one thing: store data. There is no conditional logic, no state management, no function calls, no re-entrancy, no delegate calls, no proxy patterns, no upgradeable contracts, no governance tokens controlling contract parameters. The attack surface is zero. You cannot exploit OP_RETURN because there is nothing to exploit. It is data in, data stored, end of story.

Smart contracts, by contrast, are software — and software has bugs. The history of smart contract exploits is a catalog of catastrophe:

• The DAO (June 2016): A re-entrancy vulnerability in Ethereum's first major decentralized application allowed an attacker to drain 3.6 million ETH ($60 million at the time). The exploit was so severe that Ethereum hard-forked to reverse it — creating Ethereum Classic as the unforked chain. The "immutable" blockchain was mutated because the smart contract had a bug.
• Parity Wallet (November 2017): A developer accidentally triggered a self-destruct function in the Parity multi-signature wallet library contract, permanently freezing 513,774 ETH ($150 million) belonging to 587 wallets. The funds remain frozen today.
• Wormhole Bridge (February 2022): An attacker exploited a signature verification vulnerability in the Wormhole cross-chain bridge to mint 120,000 wETH ($326 million) out of thin air. The largest DeFi exploit to date.
• Ronin Bridge (March 2022): North Korean state hackers (Lazarus Group) compromised validator keys for the Ronin bridge connecting Axie Infinity to Ethereum, stealing $625 million in ETH and USDC.

The total value lost to smart contract exploits exceeds $5 billion. These are not theoretical risks. They are historical facts. For a Mars colony, where there is no venture capital fund to make users whole and no legal system to prosecute attackers, smart contract risk is existential risk.

Resource Efficiency

Smart contract execution requires computation. Every operation in the Ethereum Virtual Machine (EVM) costs gas — a unit of computational work that validators must perform to process the transaction. Complex contract interactions can consume millions of gas units. On Earth, with abundant electricity and redundant hardware, this is merely expensive. On Mars, where every watt of power is generated by solar panels that operate at 43% of Earth's solar intensity and must also run life support, water recycling, and food production, computational waste is a survival liability.

An OP_RETURN transaction requires minimal computation: validate the input signatures, record the output data, done. No EVM execution, no state transitions, no storage slot updates, no event emissions. The computational overhead is negligible. For a colony where the server room shares power with the greenhouse, this matters.

Auditability

Anyone can read an OP_RETURN output. Open a block explorer, look at a transaction, read the data in the OP_RETURN field. It is plaintext (or easily decoded from hex). No special tools, no contract ABI, no understanding of Solidity, no state reconstruction needed.

Smart contract state, by contrast, is opaque without expertise. To understand what a smart contract "says," you need to know the contract's source code, understand its storage layout, reconstruct its state from the history of all transactions that have interacted with it, and interpret the result. This requires developer-level knowledge. For a governance system that claims to be transparent, requiring programming expertise to verify records is a contradiction.

The Republic's design philosophy: any citizen with a block explorer should be able to verify any record. OP_RETURN makes this possible. Smart contracts do not.

The Case Against Cryptographic Opacity

There is a deeper argument here that extends beyond smart contracts. In recent years, the blockchain world has embraced increasingly sophisticated cryptographic schemes — zk-SNARKs, zk-STARKs, homomorphic encryption, zero-knowledge rollups — that allow verification without revealing the underlying data. These are genuine mathematical breakthroughs. They are also, for a civic governance system, precisely the wrong tool.

Consider what a zk-SNARK actually does: it lets a prover demonstrate that a statement is true without revealing why it is true. "I voted" can be proven without revealing how. "This transaction is valid" can be proven without revealing the amounts. Powerful? Absolutely. But the verification process is opaque by design. To audit a zk-SNARK, you need to understand elliptic curve pairings, polynomial commitments, and trusted setup ceremonies. The number of humans on Earth who can meaningfully audit a zk-SNARK circuit is measured in the hundreds. On Mars, it might be zero.

The Martian Republic makes a deliberate, philosophical choice: transparency over privacy at the civic layer. Your vote is secret (CoinShuffle handles that at the ballot level), but the system is transparent. You can see that a vote happened, that a citizen registered, that a proposal was submitted. The proofs are not zero-knowledge — they are full-knowledge. And that is exactly what a democracy requires: a system where any citizen, not just the mathematically gifted, can verify that the rules are being followed.

Complexity is not security. Opacity is not privacy. The Republic keeps what must be secret (your ballot choice) secret through CoinShuffle's mixing protocol, and keeps everything else radically, defiantly transparent — written in plain bytes that any human can read, verify, and trust. This is not a compromise. It is a conviction.

The Notarization Stack

OP_RETURN does not operate alone. It is the middle layer of a three-layer architecture that the Republic uses for all its record-keeping:

Each layer provides a distinct guarantee. IPFS guarantees that the data is retrievable from anywhere, by anyone, without depending on a single server. OP_RETURN guarantees that a specific CID was recorded at a specific time by a specific civic address. Proof-of-Work consensus guarantees that the transaction ordering is correct and that no one can retroactively alter the history without redoing the computational work of every subsequent block.

Together, the three layers produce a record-keeping system with properties that no single technology achieves alone:

• Tamper-evident: Any alteration to the data changes its hash, which mismatches the on-chain CID. Any alteration to the on-chain record requires recomputing the proof-of-work for every subsequent block. Both attacks are detectable and practically infeasible.
• Censorship-resistant: The data is distributed across IPFS nodes worldwide. The blockchain record is maintained by a decentralized mining network. No single entity can suppress either layer.
• Permanently timestamped: The block timestamp and block height provide an ordering of records that is agreed upon by the entire network. This ordering is the Republic's official timeline of events.
• Independently verifiable: No trust in any person, organization, or server is required. The mathematics verify themselves.

Legal and Practical Implications

On Earth, blockchain notarization operates within existing legal frameworks. Courts may or may not accept blockchain timestamps as evidence. Regulations may or may not recognize on-chain records as legally binding. The blockchain is a supplement to traditional legal infrastructure, not a replacement.

On Mars, the situation is fundamentally different. There is no pre-existing legal system. There are no courts, no clerks, no notaries public, no registrars of deeds. The blockchain record is not supplementing an existing system. It is the system. OP_RETURN entries are the Republic's equivalent of notarized documents, court filings, official records, and legislative archives — all in one.

The Blockchain as Legal Record

Consider what this means in practice. When the first dispute arises on Mars — and it will, because disputes are a feature of human communities, not a bug — the resolution process will look something like this:

1. Citizen A claims they submitted a proposal on March 1. Citizen B disputes this, claiming the proposal was submitted on March 8 and was modified before submission.
2. The arbitration panel (elected by citizens through the Republic's governance process) examines the blockchain. The proposal transaction is at block height 891,847, mined on March 1 at 09:14:22 UTC. The OP_RETURN contains the CID of the proposal text.
3. The panel fetches the proposal text from IPFS, verifies the CID matches the on-chain record, and reads the original, unmodified proposal.
4. The dispute is resolved. The blockchain record is definitive. No witnesses needed, no testimony, no "he said, she said." Mathematics settled it.

This is not a theoretical scenario. It is the inevitable consequence of building governance on immutable records. Every official act of the Martian Republic — every citizenship grant, every proposal, every vote, every endorsement — leaves a permanent, timestamped, verifiable trace. The blockchain is not just a ledger. It is the Republic's institutional memory, and OP_RETURN is how that memory is written.

Precedent on Earth

The legal recognition of blockchain records is accelerating. Italian law explicitly grants legal validity to blockchain timestamps. Chinese courts routinely accept blockchain evidence. The U.S. states of Vermont (2016), Arizona (2017), and Wyoming (2019) have enacted legislation recognizing blockchain records. The European Union's eIDAS 2.0 regulation (2024) provides a framework for blockchain-based electronic timestamps with legal effect across all EU member states.

For the Republic, these Earth-based precedents serve a dual purpose. First, they validate the technical approach: if Earth's legal systems accept blockchain timestamps, the Republic's on-chain records are built on proven infrastructure. Second, they provide a bridge for recognition: when the Martian Republic eventually seeks diplomatic recognition from Earth nations, its records are stored in a format that Earth's legal systems already understand and accept.

Beyond 80 Bytes — The Future

Eighty bytes has served the Republic well. But the blockchain landscape is evolving, and the Republic's architecture will evolve with it.

Ordinals and Inscriptions

In January 2023, developer Casey Rodarmor introduced Ordinals to Bitcoin — a protocol for inscribing arbitrary data (images, text, even small applications) directly into Bitcoin transactions by embedding data in the witness field (enabled by the 2017 SegWit upgrade). A single transaction can inscribe up to 4MB of data. The Bitcoin community erupted in debate: is this a legitimate use of block space, or is it blockchain bloat?

The Martian Republic takes a clear position: keep OP_RETURN for pointers, IPFS for data. The blockchain's role is to provide timestamped, immutable references to content stored elsewhere — not to be the storage medium itself. Inscribing a 500KB image directly into the blockchain means every full node must store that image forever, even if no one ever looks at it again. Storing the image on IPFS and recording its 46-byte CID on-chain means the blockchain stays lean while the image remains permanently retrievable.

This distinction is even more critical for Mars. A Mars colony's blockchain nodes will run on limited hardware with constrained storage. A bloated blockchain that requires terabytes of storage to sync is an infrastructure liability. A lean blockchain that stores only transaction data and 80-byte pointers is sustainable indefinitely.

Larger OP_RETURN Payloads

Some Bitcoin forks and alternative chains have increased or removed the OP_RETURN size limit. Bitcoin SV removed the limit entirely, allowing multi-megabyte OP_RETURN outputs. Marscoin's development roadmap includes the possibility of dynamic block sizes, which could eventually accommodate larger OP_RETURN payloads for specific use cases — such as embedding Merkle proofs directly in transactions for more efficient batch verification.

But the 80-byte constraint has proven to be a productive design force. It enforces a clean separation of concerns (data on IPFS, pointers on-chain) that produces a more resilient, more efficient, and more auditable system than any monolithic on-chain approach. The Republic may expand the limit someday. But it will do so carefully, preserving the architectural discipline that 80 bytes demands.

The Long View

The Marscoin blockchain has been running since 2014. Every block mined since then is part of the permanent record. When the Republic's governance system went live, every citizen registration, every endorsement, every proposal, every vote joined that record. The chain grows at roughly one block every two minutes — 720 blocks per day, 262,800 blocks per year.

Project forward a century. The blockchain contains 26 million blocks. In those blocks: the complete citizenship history of the Republic, every proposal ever debated, every vote ever cast, every endorsement ever given, the founding documents, the constitutional amendments, the legislative history — all immutable, all timestamped, all independently verifiable. Not stored in an archive that might burn, not filed in a cabinet that might be lost, not held on a server that might be decommissioned. Stored in a distributed ledger maintained by thousands of nodes across two planets.

The Full Transaction: From Citizen to Chain

To make this concrete, let us trace a single transaction through the entire stack. Citizen Yuki wants to endorse Pioneer Kofi's citizenship application.

1. Decision: Yuki reviews Kofi's application on the Republic's platform. She examines his identity JSON (fetched from IPFS), watches his liveness video (also from IPFS), reads his bio, and decides to endorse him.
2. Transaction construction: The Republic's software constructs a Marscoin transaction. The input is an unspent output belonging to Yuki's civic address. The output is an OP_RETURN containing CT_ followed by Kofi's civic address (34 bytes). A small change output returns the remaining coins to Yuki (minus the mining fee).
3. Signing: Yuki's wallet signs the transaction with her civic address's private key. This signature proves that the endorsement came from Yuki and no one else. It is cryptographically unforgeable.
4. Broadcasting: The signed transaction is broadcast to the Marscoin network. Mining nodes receive it, validate the signature, verify that Yuki's input is unspent, and include it in their next block candidate.
5. Mining: A miner finds a valid proof-of-work for the block containing Yuki's transaction. The block is propagated to all nodes. Yuki's endorsement is now part of the permanent record at block height 893,102, timestamped to 2026-03-27T16:42:18Z.
6. Verification: Anyone, anywhere, at any time in the future, can verify this endorsement. Look up block 893,102 on any Marscoin block explorer. Find the transaction from Yuki's civic address. Read the OP_RETURN: CT_ + Kofi's address. Confirm the signature is valid. The endorsement is proven: Yuki endorsed Kofi at that exact time. No trust required. No intermediary. No authority. Just mathematics.

The entire process, from Yuki's click to permanent on-chain record, takes roughly two minutes (one block confirmation). The OP_RETURN data consumes 37 bytes. The cost is a fraction of a MARS in mining fees. And the result is a record that will outlast any server, any company, any government, and quite possibly any planet.

"The chronicles of a civilization should not depend on the survival of any single library, any single server, or any single planet. They should be written into the fabric of the network itself — permanent, distributed, and verifiable by anyone who cares to look."

— The Martian Republic Whitepaper

OP_RETURN is 80 bytes. That is less than a tweet. Less than a text message. Less than the sentence you are reading right now. But in those 80 bytes, the Martian Republic records the proof of every citizen's identity, every proposal's existence, every vote's integrity, and every forum post's timestamp. It is not glamorous. It is not a smart contract. It does not have a token or a DAO or a yield farming protocol. It is better than all of those things: it is simple, secure, permanent, and it works. Eighty bytes at a time, the Republic writes its history into the blockchain — a history that will be readable long after the servers are dust and the hard drives are fossils.