# Background and Why we made Burnr

In a landscape dominated by **digital permanence**, where every byte is logged, indexed, and stored indefinitely, **ephemerality is no longer a feature—it’s a radical necessity**. The modern web, including most of Web3, operates under the assumption that all data is persistent by default. This model is fundamentally misaligned with the needs of a privacy-first user base navigating high-risk, trust-minimized environments.

While E2E encryption has become a staple of privacy tooling, the reality is that most platforms retain critical metadata, require custodial accounts, or fail to guarantee immutability in message state. “Delete” is rarely a hard delete. It’s often just a UI abstraction over soft retention.

That’s the attack surface Burnr was designed to eliminate.

We envisioned Burnr as a **stateless ephemeral messaging protocol**, not just an app—a composable primitive for **transient data payloads**, burnable links, and one-shot access. Built for both web and mobile, Burnr enforces digital impermanence through **client-side encryption**, **self-executing expiry logic**, and an aggressive burn-on-read architecture.

The idea came from a deeply personal failure.

In late 2022, during a chaotic wallet rotation for a DeFi multisig, a signer requested the mnemonic via Telegram. Despite using the disappearing message feature, the message was **forwarded to an external address**—a catastrophic OPSEC failure. That single breach could have exposed over $1M in pooled DAO funds. We revoked access fast enough, but the incident made one thing painfully clear:

**There is no such thing as secure messaging if the receiver can store the state.**

Burnr is designed to eliminate that vector entirely. It doesn’t ask who you are. It doesn’t care what you send. It just guarantees that whatever leaves your machine **only exists once—and never again.**

By leveraging **zero identity flows**, **AES-256 + RSA hybrid encryption**, and **serverless payload invalidation**, Burnr creates a message lifecycle where:

* Access is gated by knowledge, not credentials.
* Payloads expire with cryptographic certainty.
* Links are atomic—used once and self-voided.

The goal is not to become “a better messaging app,” but to define a new **privacy primitive** for the Web3 stack—one that plays well with multisig operations, DAO coordination, stealth airdrop communications, validator handoffs, and private key transmissions.

With the introduction of the $BURN token, this logic extends to:

* Incentivized access control
* Governance of expiry logic and storage parameters
* On-chain funding of privacy innovation through DAO-managed treasuries

Burnr doesn’t just protect your message. It codifies the right to **transmit and forget**—something sorely missing from the “forever web.”

In crypto, **not everything needs to live on-chain forever**. Sometimes, value is in the vanishing.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.burnrchat.io/background-and-why-we-made-burnr.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.