CLAUDE.md Template: Full-Stack Project
Bob Makes This Easier
If you install Bob (
claude mcp add opnet-bob --transport http https://ai.opnet.org/mcp),
you get all OP_NET knowledge automatically through MCP tools. The CLAUDE.md below is still
useful for project-specific rules, but Bob handles the OP_NET-specific patterns for you.How to Use This Template
- Click the Download button below to save this as a file
- Put the downloaded file in your project folder
- Rename it to
CLAUDE.md(if it isn't already) - Open Claude Code in that folder — it will read the file automatically
Or just tell Claude Code: Create a CLAUDE.md file for a full-stack OPNet project (contract + frontend + backend). With Bob installed, it will generate one for you.
Below is the template content. Everything below the line should be in your CLAUDE.md file:
CLAUDE.md — OPNet Full-Stack Project
#Project Description
This is a full-stack project built on Bitcoin Layer 1 with OP_NET. It consists of:
- Smart contract(s) — AssemblyScript, compiled to WebAssembly
- Frontend — React app with OP_WALLET integration
- Backend — hyper-express API for data indexing and serving
#Required Reading
Before writing ANY code, read the relevant skill docs:
opnet-developmentskill: contracts, backend, security, package versionscrypto-frontend-designskill: frontend patterns, wallet integrationopnet-cliskill: deployment, .btc domains
#Project Structure
text
/contracts -- Smart contract source (AssemblyScript)
/frontend -- React frontend application
/backend -- hyper-express API server
/shared -- Shared types and constantsEach directory is its own sub-project with its own package.json. They share types and constants through the /shared directory.
#Package Rules (ALL Components)
#ALWAYS Use
@btc-vision/bitcoin— Bitcoin library (OPNet fork)@btc-vision/ecpair— EC pair library (OPNet fork)@btc-vision/transaction— Transaction construction and ABI typesopnet— OPNet SDK, provider, contract interaction
#NEVER Use
bitcoinjs-lib— wrong Bitcoin libraryecpair— wrong EC pair librarytiny-secp256k1— use@noble/curvesinsteadethersorweb3— Ethereum librariesexpress,fastify,koa— wrong backend framework
#Package Versions
- Check the opnet-development skill setup-guidelines for exact versions
- Do not guess — wrong versions cause type mismatches and broken builds
#Smart Contract Rules
#Architecture
- Constructor runs on EVERY interaction — use
onDeployment()for one-time init - All state stored via unique storage pointers (no collisions)
- Extend the appropriate base: OP20, OP721, or OP_NET base
#Safety
- SafeMath for ALL u256 arithmetic — no raw operators
- No
whileloops — boundedforloops only - No iterating all map keys — store aggregates separately
- Validate all inputs (zero address, zero amount, overflow)
#Access Control
- Owner-only functions:
Revert.ifNotOwner(this, msg.sender) - Validate caller permissions before modifying state
#Frontend Rules
#Wallet
- OP_WALLET only — NEVER MetaMask
- Use
@btc-vision/walletconnectfor connection modal - ALWAYS include WalletConnect popup CSS fix
- signer and mldsaSigner are NULL on frontend — wallet extension signs
#Provider
- Create a SEPARATE
JSONRpcProviderfor all read operations - NEVER use WalletConnect provider for reads
- Testnet:
https://testnet.opnet.org - Mainnet:
https://mainnet.opnet.org
#Contract Interaction
- Use
getContract<T>(address, abi, provider, network, sender)from opnet - ALWAYS simulate before sending transactions
- Check
'error' in simulationbefore proceeding - NEVER put private keys in frontend code
#UI
- TypeScript, React functional components
- Dark theme, responsive design
- Loading states, error handling, success feedback
- Auto-refresh after transactions
#Backend Rules
#Framework
- hyper-express ONLY — Express, Fastify, Koa are FORBIDDEN
- CORS support enabled
- Proper error handling on all endpoints
#Blockchain Queries
- Use
JSONRpcProviderfrom opnet for all chain data - NEVER use fetch/axios to call external blockchain APIs
- NEVER use mempool.space, blockstream, or similar services
#Backend Signers
- Backend CAN use real signers:
signer: wallet.keypair, mldsaSigner: wallet.mldsaKeypair - Store keys in environment variables, NEVER hardcode
- Use
.envfiles, add.envto.gitignore
#Data
- Cache blockchain data to avoid redundant RPC calls
- Serve indexed/processed data to the frontend via REST endpoints
- Use proper HTTP status codes (200, 400, 404, 500)
#Cross-Component Rules
#Shared Types
- Define shared interfaces and constants in
/shared - Contract addresses, ABIs, and network config live in shared
- Both frontend and backend import from shared — no duplication
#Network Configuration
- Support both testnet and mainnet via environment variable
- Default to testnet in development
- Frontend reads network from OP_WALLET connection
- Backend reads network from environment
#Build Order
- Contracts first (
cd contracts && npm install && npm run build) - Shared types (if separate build step)
- Backend (
cd backend && npm install && npm run build) - Frontend (
cd frontend && npm install && npm run build)
#Deployment
#Contract
- Test on testnet first, always
- Use opnet-cli for deployment
- Save deployed contract address in shared config
#Backend
- Standard Node.js deployment (any hosting provider)
- Set environment variables for network, RPC URLs, and keys
- Never expose private endpoints without authentication
#Frontend
npm run buildproduces static files indist/- Deploy to IPFS, .btc domain, or any static hosting
- Update contract address and backend URL for production
#Before Finalizing
- Run audit checklist from opnet-development skill on all contracts
- Verify all storage pointers are unique
- Verify SafeMath used everywhere in contracts
- Verify no private keys in frontend code
- Verify .env is in .gitignore
- Test full flow: connect wallet, interact with contract via frontend, verify backend serves correct data
- Test on testnet end-to-end before mainnet
Ready to test your knowledge?
20 questions covering everything from vibecoding basics to shipping a complete dApp.
On this page
- Project Description
- Required Reading
- Project Structure
- Package Rules (ALL Components)
- ALWAYS Use
- NEVER Use
- Package Versions
- Smart Contract Rules
- Architecture
- Safety
- Access Control
- Frontend Rules
- Wallet
- Provider
- Contract Interaction
- UI
- Backend Rules
- Framework
- Blockchain Queries
- Backend Signers
- Data
- Cross-Component Rules
- Shared Types
- Network Configuration
- Build Order
- Deployment
- Contract
- Backend
- Frontend
- Before Finalizing