Upload

Sending files into blockchain via Aetrna

Allows you to upload and efficiently store any type of file inside Ethereum with multiple options such as:

1. Encryption — symmetrical (password) and asymmetrical (ECIES / MLKEM):

   1. Implemented ECIES with post-quantum option of MLKEM (Kyber-1024 per FIPS-203). For encryption, the elegancy of implementation allows the user to establish a shared secret without private key.

   2. To avoid the exposure of private keys during decryption, MLKEM is a safer alternative -- allows you to generate a separate keypair and declare it on-chain for future use (effectively binding your Ethereum address with MLKEM keypair). We also provide a standalone open source tool for offline decryption.

   3. Password (Argon2id -> AES-256) encryption is also implemented, will require to share the decryption keys off-chain.

2. Networks -- L1 for permanent storage, impossible to censor, more expensive than L2 (or about the same if you use blobs). L2 is faster and cheaper, but can be easily censored or wiped out - generally not good for permanent storage.

3. Blobs (EIP-4844) -- cheap temporary storage with all benefits of L1 for 18 days (4096 epochs) in Consensus Layer.

4. NFT mint -- adds a shortcut to Metamask, the NFT will contain the permanent download key in the metadata, so you can reconstruct / access the files even if the app goes offline.

5. Relayer (EIP-2771) -- upload files by backend, so you dont have to accept dozens of Metamask popups and potentially break the wallet extension (see known bugs below).

6. Doc certification -- allows to make documented agreements or contracts with others on-chain, the document itself will contain the signatures of both parties.

7. Simulation — allows to simulate the uplad for a specific file with specific options to get a near-perfect estimation for the gas costs. It is done via Tenderly.

After upload, the Download key is generated, which essentially mirrors the content of the contract for convenience and is used as a shortcut to reconstruct the file from the blockchain later.

Upload steps

On high level (as of July 2025), the system does the following:

1. Compression via zlib per RFC 1950 / RFC 1951 (DEFLATE algo with 32k sliding window)

2. Metadata addition in format:file_name + separator :: + file_content

3. (If enabled) Encryption with Password, ECIES or MLKEM (this will have a separate page due to complexity).

4. Data is split into words

5. Upload routes:

   1. Relayer route — asks for initialization signature via Metamask and then does the meta-transactions (per EIP-2771) on behalf of the user

   2. Metamask route deprecated

6. After the process is done, the system collects a download key which could be minted in ERC-1155 token aka NFT, but also is accessible in the contract storage for later use

Example of such NFT is here,

Example of Download key from the NFT metadata

{
        "description": "This key grants access to a file stored without NFT ownership.",
        "download_key": {
          "file_hash": "0x452b3015b2abf3391ae60cfd6a7bb28f4e0a36fe0d1ab9cd176f443ab791307a",
          "original_hash": "0x5e0bdd8bdcc9fce74d814942cb83f06eb1555fdbc2e7b3e3e88dec26b952f21d",
          "original_size": 184292,
          "storage_contract": "0x640dBdCDB285c6557FEC1afEE8020F88918a9d71",
          "nft_contract": null,
          "token_id": 0,
          "encryption_type": null,
          "aes_key_hash": null,
          "chain_id": 11155111,
          "block_numbers": [
            8607784,
            8607785
          ],
          "aetrna_version": "Alpha",
          "event_signature": "0x545f3b070d35461c64b7269a4ffa24f08b544c1676c4a6a3b46bae4254b6c66a",
          "expiry": 0,
          "unpadded_length": 178589,
          "uploader_address": "0x0C99bDA0C7C72d6A25d7907903FFeD826d06481D",
          "designatedCoSigners": [],
          "kzg_commitments": []
        },
        "name": "File Access Key (No NFT)"
      }

The explaination of Download key will be in Download feature page