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.
Subcategory | Description | Naming convention | Where to name |
---|---|---|---|
User-facing | Simple 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>.eth | Enscribe |
Token | Single 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>.eth | Enscribe |
Other wallets/operations/misc contracts | Wallet 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):
Step 5: Claim DNS Domain (Optional but Recommended)
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.
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