# Cryptographic Explainer This post describes Firn's cryptographic architecture, including what data, exactly, is stored on-chain, and how Firn’s browser-based client interacts with that data. For a slightly more advanced survey, please see our [technical whitepaper](https://firn.io/whitepaper.pdf). ## Account-Based Privacy The crucial thing to understand is that Firn is *account-based*; every other live-and-working cryptographic privacy protocol is *UTXO-based*. This distinction is analogous to that between Ethereum and Bitcoin. Indeed, you can think of Firn as something like "Ethereum, but private"; other protocols—like Zcash, Monero, and Aztec—are more like "Bitcoin, but private." Firn’s state consists of a global table of *accounts*. (These are analogous to those constituting Ethereum’s global account table, but they exist *within* Firn’s contract.) Just as Ethereum associates, to each account, a balance—and also code, storage, etc. in the case of contracts, but let’s ignore that—Firn associates, to each account, an *encrypted* account balance, encrypted under its owner’s key. Each account’s balance can *only* be viewed by the account’s owner. When you deposit into Firn, you credit your own balance’s account. When you withdraw, on the other hand, you debit your account. Crucially, Firn withdrawals take place in such a way that it’s not visible *which* account is being debited. In other words, your account will be hidden within a number of other accounts, when the withdrawal takes place; it will not be publicly discernible which among these accounts initiated the withdrawal. This is where Firn’s privacy comes from. A depiction of this process is given below.

A depiction of Firn's account-based architecture.

This diagram is simplified; in reality, Firn deposits are *also* private. Firn supports *private transfers*. These work similarly to private withdrawals, except that, in a single transaction, the sender’s and receiver’s accounts are simultaneously debited and credit, respectively. As it turns out, Firn’s account-based architecture has immense benefits, and makes it vastly more efficient than UTXO-based privacy protocols. Let’s explore this fact. The key property is that, when your account state changes—say, when you receive a transfer—your old account is *overwritten* by your new account! In UTXO-based settings, when you receive a payment, of course no overwriting takes places, and your “holdings” can be, in general, spread throughout hundreds of UTXOs. This difference—fundamental to the definition of the *account-based model*—has immense ramifications. In short, in Firn, retrieving *your own account state* is an extremely simple, instantaneous task; you must only query a table entry, and decrypt the resulting ciphertext. In UTXO-based privacy protocols, it’s far harder. It requires that you download *every transaction* posted to the system since you last synchronized, trial-decrypt *each transaction* (to learn whether it was to you or not), add the resulting holdings, and cache them. If you do this on a new device, it will require that you start from the very beginning! The data download requirements here can be in the gigabytes. The situation here, moreover, differs crucially from that of Bitcoin, because of the privacy factor. In Bitcoin, wallets can—and do—outsource the task of state management to powerful external servers, which handle the burden of downloading, storing, and indexing the blockchain’s state. This option is not available in the private setting, since it would require outsourcing your secret information to the external server. Rather, each participant must bear this burden locally. A similar fact holds regarding generating zero-knowledge proofs. In UTXO-based settings, to *generate* a proof, you must make reference to the entire privacy system’s state. In Firn, you only need to make reference to a constant amount of state, which can be queried in an instant. ## Firn's Lightweight Browser Client This is how Firn gets away with running entirely in an extremely lightweight browser client. Firn’s [front-end](https://firn.io) is hosted entirely statically [on IPFS](https://firn.eth.limo). Firn has no off-chain rollup (like Aztec does), and Firn proofs can be generated by the browser entirely unassistedly. Firn’s browser client must only download a few hundred bytes (compared to megabytes in the case of Aztec); it’s completely stateless, and stores nothing locally (unlike Aztec); finally, Firn synchronizes instantly, even on fresh devices. Firn’s liveness depends only on the L1’s liveness. During synchronization and proof-generation, Firn communicates *only* through the selected wallet (whose RPC is controlled by the user), and does *not* initiate any “backdoor” connections to Firn-specific services. (When you actually dispatch a withdrawal or transfer, a one-time zero-knowledge proof gets sent to the Firn relay, which pays gas and forwards it to the blockchain. This proof reveals nothing to the relay. The relay does not collect any IP information.)