Axiom: Decentralized and Censorship-Resistant Communication Protocol

🚀 Live Deployment Details

• Network: Arbitrum One (Mainnet L2)
• Chain ID: 42161
• RPC Endpoint: https://arb1.arbitrum.io/rpc (or any custom Alchemy/Infura endpoint)
• Axiom Proxy Contract Address: 0xc11CFf8111e8b1F055eba095Efb679a38Abe6b63

(Note: Axiom uses a UUPS Upgradeable Proxy architecture. All client interactions must always be directed towards this Proxy address, never the underlying implementation contract).

📖 How to Read Data (Indexer / Clients)

Clients should never attempt to read protocol posts directly from the smart contract state variables (as preserving gas is a priority, content is not stored in state). Instead, clients must index the blockchain events.

✍️ How to Publish Data (Client Tx Submission)

To publish data to the Protocol, clients must submit an on-chain transaction calling the publishAxiom function on the Proxy contract.

---

The goal of Axiom is to provide a completely anonymous, decentralized, and censorship-resistant social media platform.

To make this possible, the architecture is strictly divided: the foundation (the protocol) and the clients (the software). This repository defines that foundation—a smart contract and a standardized data structure on an Ethereum Layer 2 network.

Project Scope

The protocol establishes the foundation of the platform:

• Standard Naming Convention: A clear structure defining how payloads are sent to the smart contract and how clients read them.
• Immutability: The blockchain serves as a fail-safe and tamper-proof database.
• Microblogging Focus: The protocol is not designed for large amounts of on-chain data, but rather follows the traditional microblogging concept (short posts). Media files are not natively stored on the chain; instead, they are embedded via external links when needed.
• Spam Protection: Transaction fees and a one-time, low entry fee for a wallet's first post prevent state-bloat attacks by botnets.
• Security Routing: The protocol enforces the OPSEC separation of messages based on specific security requirements.

---

Protocol Security Levels

Axiom is designed to enable true freedom of speech for users in countries where communication is restricted. The protocol distinguishes between three security levels. It assumes that users know which security level is appropriate for their specific situation.

• Level 1: Open Communication occurs openly in plaintext on the blockchain. All clients can read and process the entire traffic. Embedding links (e.g., for images via third-party providers) is permitted at this level. The expectation is that standard social media communication takes place here—including funny cat pictures. This generates important noise within the network. It is less secure regarding pure IP tracking, but the posts remain entirely un-censorable.
• Level 2: Closed This level is intended for strict security. It exclusively supports plain text messages. The protocol prohibits media links here to technically rule out any IP leaks when clients load external content. Users must independently ensure they acquire the cryptocurrency used for gas fees anonymously.
• Level 3: Encrypted Built for maximum privacy. The messages themselves are encrypted with AES-256-GCM before being sent. Only metadata, the initialization vector (IV), and the ciphertext are stored on the blockchain. Only clients of users who possess the correct cryptographic key can decrypt and read these messages.

Network Security & IP Tracking (Hard Rule)

For all levels, Onion Routing (e.g., Tor) is strictly mandatory. Communicating with commercial RPC providers (like Infura or Alchemy) leaks the sender's IP address in plaintext. To close potentially life-threatening OPSEC vulnerabilities for dissidents, clients are required to route transactions to the RPC nodes exclusively through the Tor network.

---

Cryptography Standards (For Level 3)

For messages on Level 3, all clients must strictly adhere to the following cryptographic standards to ensure interoperability and avoid compromising security.

1. Encryption Algorithm: AES-256-GCM All Level 3 payloads must be symmetrically encrypted using AES in GCM mode with a 256-bit key length. The initialization vector (IV/Nonce) must be randomly regenerated for every single message and is written to the blockchain as plaintext metadata. This prevents pattern recognition by external observers.
2. Key Derivation: Argon2id Users enter human-readable passwords into their clients. These must never be used directly as AES keys. Clients are strictly required to use the Argon2id hashing algorithm. (Note: Developers must define fixed parameters for iterations and memory usage within the client so that all generate the exact same key).
3. Key Exchange: Out-of-Band Axiom does not handle on-chain key exchanges. The protocol stores no public keys. Exchanging the password (shared secret) for a specific channel is the responsibility of the users and must occur outside the network (e.g., in person).
4. Data Integrity AES-GCM generates an Authentication Tag. Clients must validate this tag. If validation fails, the client must silently discard the message (drop).

---

Data Structure, Payload Delivery, and Indexing

Axiom utilizes a hybrid payload delivery (ABI Split). To prevent the smart contract from having to unpack expensive data formats, the data is separated prior to transmission:

1. Logic Variables: The level (uint8 _level) and the initialization vector (bytes _iv) are passed as direct parameters to the smart contract, as it requires them to enforce its security rules.
2. Opaque Data: The actual message content is constructed internally by the client as JSON and compressed into CBOR (Concise Binary Object Representation). The contract handles this CBOR package "blindly" and forwards it directly to the event log.

Payload Keys (CBOR Structure)

Axiom uses single letters as keys to save bytes. The author (msg.sender) and timestamp (block.timestamp) are omitted, as the smart contract extracts these values in a tamper-proof manner anyway.

• t (Type): Integer. The type of action.
• c (Content): String/Bytes. The text, name, or ciphertext.
• h (Hashtags/Tags): Array. Optional. Used for categorization (subchannels).
• m (Message Hint): Bytes (length of 2). Level 3 only. A 2-byte HMAC hash used for fuzzy bucketing.
• r (Reply-To): Bytes. Optional. The transaction hash of a referenced post.

Action Types (t Field)

• 0 = Profile Update (Links the wallet address to a readable name in field c)
• 1 = Post (Standard message)
• 2 = Reply (r requires the hash of the original post)
• 3 = Like (r requires the hash of the post)
• 4 = Unlike (Reverts Type 3)
• 5 = Retweet / Repost (r requires the hash of the post)
• 6 = Un-Retweet (Reverts Type 5)

Subchannels and Dark Routing (h Field)

• Level 1 & 2: Tags are passed in plaintext.
• Level 3 (Encrypted): Passing tags in plaintext is strictly prohibited at the protocol level, as this leaks metadata. Tags must be encrypted exactly like the content (c). For external observers, the tags are therefore completely invisible (Dark Routing).

Level 3: Fuzzy Bucketing (m Field)

Because tags are encrypted on Level 3, clients theoretically have to attempt to decrypt every single message (Trial Decryption). To prevent CPU overloads, Axiom uses Message Hints:

• The sender calculates HMAC-SHA256(AES_Key, IV) and places the first 2 bytes as field m into the CBOR payload.
• Receivers calculate this hint for their locally stored passwords. The expensive decryption process is only executed if there is a match. This filters out 99.99% of irrelevant traffic without leaking metadata.

---