# Misconceptions and Misapplied Web2 Patterns

As **Web2** developers begin building in **Web3**, it's natural to lean on familiar tools, frameworks, and mental models. This however often lead to **misapplied patterns** that don’t align with the decentralized nature of blockchain development, especially when working with Verona.

This guide outlines common misconceptions and design patterns brought over from Web2 that **don’t translate well to Web3**, and explains how to rethink your approach for building secure, performant, and user-friendly apps on Verona.

### Misconception #1: "I need a backend server to run my app"

In Web2, your backend is the heart of your application, handling routing, business logic, database queries, and more. But in Web3, **your smart contracts replace the backend**. There is no centralized server between your frontend and the blockchain.

#### The Web3 mindset:

* **Business logic** lives in CosmWasm smart contracts.
* **State** is managed and stored on-chain.
* The **frontend communicates directly with the blockchain**, not a backend.

### Misconception #2: "I’ll store user data in a database like MySQL or Firebase"

Databases are standard in Web2 for storing everything from user profiles to app data. In Web3, data stored off-chain is not **trustless**, **transparent**, or **verifiable**.

#### The Web3 mindset:

* Use smart contract **on-chain storage** for important, verifiable state.
* If off-chain data is needed (e.g. large files), consider decentralized solutions like **IPFS**, **Arweave**, or **Jackal**.
* Indexing services like **SubQuery** or **Numia** can help you efficiently read blockchain data.

{% hint style="info" %}
Only use off-chain databases when the data is not critical to contract logic or on-chain interactions or you need do do complex data agregation.
{% endhint %}

### Misconception #3: "Users should register with email and password"

Web3 applications rely on **wallets**, not usernames and passwords. Wallets represent a user's identity, and every action is verified using cryptographic signatures and therefore there's no need to manage credentials.

#### The Web3 mindset:

* **Wallets = Identity**. A user’s address is their identity.
* Authentication is done through **message signing**.
* **Verona simplifies this even further**: With the `abstraxion` library, developers can create a smooth, OAuth2-style login and registration experience directly in the frontend. Behind the scenes, every user that authenticates via Abstraxion is issued a Meta Account, a smart contract account on Verona that abstracts away private key management that is linked to their authenticator of choice which includes:
  * **Email**
  * **Social login** (e.g., Google)
  * **External wallets** (e.g., Keplr, MetaMask)
  * **Passkey support** for biometric authentication (e.g., Face ID, fingerprint)

### Misconception #4: "I’ll create an API layer between the frontend and the blockchain"

This introduces unnecessary centralization. If your frontend talks to a custom backend that relays messages to the blockchain, you reintroduce a point of failure.

#### The Web3 mindset:

* Interact with smart contracts directly from the frontend using `xion.js` or `cosmjs` communicating with the blockchain through RPC, gRPC, REST APIs, or WebSockets via connected network nodes.
* If needed, rely on indexers, to expose aggregated and filtered data which is usually just used for displaying data on the frontend.

### Misconception #5: "I can update my backend logic anytime"

Smart contracts are **immutable by default** once deployed. You can't just push a quick update like you would on a backend server.

#### The Web3 mindset:

* Treat every deployment as a **versioned release**.
* Design your contracts to support **migrations** which also requires setting an **admin** for each instantiated contract.
* Implement upgradability only when necessary using patterns like contract proxies or admin-controlled updates (with care).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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.burnt.com/verona/build-on-verona/references/for-web2-developers/misconceptions-and-misapplied-web2-patterns.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.