Skip to main content

Consumer Apps Best Practices

Consumer Apps Category and Contract Subcategories

Consumer apps are consumer-facing contracts or projects that users directly interact with, typically visible in wallets during dApp interactions. Base Ecosystem accurately categorizes these projects—see their consumer apps category. Examples include gaming, social, NFT, music, messaging, and creator applications.

Consumer projects typically lack a unified structure as they span a wide variety of web3 app categories and can contain a large number of contracts. Therefore, we can divide a Consumer project into subcategories based on their contract types:

  • User-facing contracts: The most important category, these are contracts users directly interact with or see in their wallets
  • Token contracts: Tokens that power the ecosystem
  • Protocol contracts: Backend smart contracts that work behind the scenes and contain business logic, typically visible only in blockchain explorers. Sometimes they are included inside user facing contracts only.
  • Utility contracts (optional): Supporting contracts used indirectly by protocol or user-facing contracts

Note that many user-facing contracts are deployed as upgradeable contracts or proxies.

Consumer Contracts Naming and ENS Onboarding Process

Step 1: Register new ENS Domain on ENS App

Ideally you already have registered or can register <yourapp>.eth. If not available you'll need to get creative.

Example: 0xppl.eth, cryptokitties.eth, basepaint-app.eth, sandboxgame.eth

Step 2: Create subcategory Subdomain

Since Ecosystem projects have many subcategories, we can create subdomains for these category excluding user-facing contracts, as user-facing contracts should be named directly under your main ENS parent as they are your app identity

  • User-facing - No need to create subdomain for this
  • Token - No need to create a subdomain if there is only one type of token otherwise create a token.<yourapp>.eth
  • Protocol - protocol.<yourapp>.eth
  • Utilities (optional) - utils.<yourapp>.eth

Example: protocol.0xppl.eth, utils.basepain-app.eth

Step 3: Name contracts

Name each contract under your domain with descriptive subnames following the patterns below.

Please refer to the Appendix for examples on how to recognize the subcategory.

SubcategoryDescriptionNaming conventionWhere to name
User-facingSimple contract
Proxy contracts
Implementation contracts
Simple and Proxy - <contract-name>.<yourapp>.eth
Implementation - <version>.<contract-name>.<yourapp>.eth
Enscribe
Protocol (if not included within user-facing contract)Protocol contracts<contract-name>.protocol.<yourapp>.ethEnscribe
TokenSingle token
Multiple tokens
Single token - <token-symbol>.<youorg>.eth or token.<yourapp.eth>
Multiple tokens - <token1>.token.<yourapp.eth>
Enscribe
Utilities (optional)Utility contracts like factory, registry, oracle, escrow, etc contracts<util-name>.utils.<yourapp>.ethEnscribe
Other wallets/operations/misc contractsWallet
Admin
Operations
Multisig
wallet.<yourapp>.eth
Or
<role>.<yourapp>.eth
ENS App

Note: There might be some Ecosystem projects with DAOs or governance contracts, please refer to DAO best practices for those contract naming

Step 4: Add Contract Metadata

Add detailed metadata to each contract name according to ENSIP: Contract Metadata Standard and Text Records (draft standard).

Recommended for User-facing and token contracts Optional for Protocol and Utility contracts

Example - land.sandboxgame.eth metadata →

name: Land Contract
description: A LAND is a digital piece of real-estate in The Sandbox's metaverse. Each LAND is a unique piece of the metaverse map which is a grid of 408x408 lands.
Avatar: ipfs://qwerty…
url: https://sandboxgame.gitbook.io/the-sandbox/land/what-is-land
category: game
license: MIT
docs: https://github.com/thesandboxgame/sandbox-smart-contracts
audits: [{"certik":"https://skynet.certik.com/projects/sandbox.game"}]
proxy (optional):

Claiming your DNS domain on ENS establishes trust and verifies that the ENS name belongs to the legitimate organization by creating a verifiable link between your traditional web presence and your Project's ENS identity.

This process involves visiting the ENS Manager App, searching for your DNS domain (e.g., <yourapp>.com), and following the verification process.

For detailed instructions, refer to the official DNS on ENS documentation which provides step-by-step guidance on the claiming process.

Real-world example - Base (base.org linked to base.eth as manager) demonstrates how an organization should link their traditional domain with their ENS presence for enhanced credibility and trust within the web3 ecosystem.

Base linked to base.eth

Appendix

Consumer contracts naming example - Decentraland

All Decentraland contracts - contracts.json

We will be picking the important one and categorizing and naming these contracts according to our best practice standard from the above contracts list

User Facing

These are typically core contracts or proxy contracts that users directly interact with through the frontend application. Contracts that handle primary user actions like buying, selling, or managing assets. These contracts are what users see in their wallets during transactions.

Example Contracts:

  • LANDProxy: 0x42f4ba48791e2de32f5fbf553441c2672864bb33
  • MarketplaceProxy: 0xccf0c17da6cd68041b1bf0f7e015767242077d8c
  • EstateProxy: 0x369a7fbe718c870c79f99fb423882e8dd8b20486
  • RentalsProxy: 0xe70db6319e9cee3f604909bdade58d1f5c1cf702

Naming Convention:

  • land.decentraland.eth
  • marketplace.decentraland.eth
  • estate.decentraland.eth
  • rentals.decentraland.eth

Token

These are ERC-20, ERC-721, or ERC-1155 token contracts that represent the protocol's native currency, governance tokens, or NFT assets. Tokens are the economic backbone of the ecosystem.

Example Contracts:

  • MANAToken: 0xfa04d2e2ba9aec166c93dfeeba7427b2303befa9

Naming Convention:

  • mana.decentraland.eth
  • Alternatively: token.decentraland.eth

Protocol

These are the implementation contracts or core business logic contracts that work behind the scenes. They're often the actual logic behind proxy contracts or standalone contracts that handle complex protocol operations.

Example Contracts:

  • Marketplace: 0x5e1870e444e4a25333494c3cfda0609f13fd806a
  • RentalsImplementation: 0xa77aef8c75a6ad9b84c6dd8b9d148f2a9accfaf5
  • VestingImpl: 0x6ad9fb3f07a6013e6db2327e27ad0a38e858d88d

Naming Convention:

  • marketplace.protocol.decentraland.eth
  • rentals-impl.protocol.decentraland.eth
  • vesting.protocol.decentraland.eth

Utilities

These are supporting contracts that provide auxiliary functions like registries, storage, factories, or helpers. They're used indirectly by both user-facing and protocol contracts.

Example Contracts:

  • LANDRegistry: 0xe8737b4d17df2f54fff5193a225561a9ff99b11f
  • EstateRegistry: 0xe69dd486ac000186af573361fb454bbbb85add85
  • VestingFactory: 0x71c84760df0537f7db286274817462dc2e6c1366

Naming Convention:

  • land-registry.utils.decentraland.eth
  • estate-registry.utils.decentraland.eth
  • vesting-factory.utils.decentraland.eth

Miscellaneous

These are administrative, governance, smart wallets, or special-purpose contracts that don't fit neatly into the above categories. They handle specific operational or governance functions.

Example Contracts:

  • RentalsProxyAdmin: 0x9d6e8912b8192d5e2f2c9ab1ba62fdfd0488fc5a

Naming Convention:

  • rentals-admin.decentraland.eth