> For the complete documentation index, see [llms.txt](https://evorium.gitbook.io/evorium-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://evorium.gitbook.io/evorium-docs/best-practicesdeveloper.md). # Best PracticesDeveloper ## Developer Best Practices Building on Evorium requires more than writing smart contracts and connecting a wallet. A production-ready Web3 application needs secure contracts, clean architecture, reliable infrastructure, clear transaction flows, and a strong understanding of how users interact with the blockchain. Evorium is an EVM-compatible Layer 1 blockchain, which gives developers a familiar environment. But familiar tools do not remove responsibility. Every contract, frontend, backend, and integration should be built with security, reliability, and maintainability in mind. Good development practices protect users, reduce bugs, and help the Evorium ecosystem grow with stronger applications. ### Start With Clear Architecture Before writing code, developers should understand what they are building and which parts must live on-chain. Not every feature needs to be inside a smart contract. Some logic belongs on-chain, while some data can be handled by backend services, indexers, or frontend interfaces. A good Evorium application should clearly separate: * On-chain logic * Off-chain services * User interface * Wallet interaction * Contract events * Indexed data * Admin operations * Configuration and environment settings The blockchain should be the source of truth for critical state, especially balances, ownership, permissions, and financial logic. Off-chain systems can improve performance and user experience, but they should not silently replace important on-chain verification. ### Keep Smart Contracts Simple Smart contracts should be as simple as possible. Complex contracts are harder to test, harder to audit, and easier to break. Every extra feature can create new edge cases, permission risks, and attack surfaces. A good smart contract should have clear responsibilities. If a contract handles staking, it should not also contain unrelated marketplace logic. If a contract manages rewards, its accounting should be easy to follow. If a contract controls user funds, the withdrawal and permission model should be direct and predictable. Simple contracts are not weak. Simple contracts are easier to trust. ### Use Strong Access Control Access control is one of the most important parts of smart contract security. Developers should clearly define who can perform sensitive actions such as minting, pausing, upgrading, changing fees, withdrawing funds, or modifying system settings. Avoid unlimited admin power when it is not needed. For sensitive applications, consider stronger operational patterns such as multisig wallets, timelocks, role-based permissions, or governance-controlled actions when appropriate. A secure contract should make privileged access visible, limited, and documented. ### Never Hardcode Critical Values Critical values should not be scattered across the codebase. Developers should avoid hardcoding RPC URLs, contract addresses, chain IDs, private keys, API keys, treasury addresses, admin wallets, fee values, or environment-specific configuration directly inside application logic. Use proper configuration management. Important values should be managed through: * Environment variables * Config files * Deployment scripts * Constants with clear naming * Network-specific configuration * Secure secret management This makes applications easier to maintain, safer to deploy, and less likely to break when moving between testnet, mainnet, staging, and production environments. ### Validate Everything Never trust raw input. Smart contracts, APIs, and frontends should validate user input before processing it. Bad input can cause failed transactions, broken UI, incorrect accounting, or exploitable behavior. Validation should apply to: * Wallet addresses * Amount values * Contract parameters * User signatures * Chain ID * Token addresses * API request bodies * Admin actions * Transaction intent * File or metadata uploads Validation is not only a backend concern. It belongs across the entire application stack. A strong Evorium dApp should fail safely and clearly when input is invalid. ### Handle Transactions Properly A blockchain transaction is not complete just because the wallet signed it. After signing, the transaction still needs to be submitted, included in a block, confirmed by the network, and checked for success or failure. A production-ready transaction flow should handle: * Wallet confirmation * User rejection * Pending state * Submitted transaction hash * Network confirmation * Success result * Failed transaction * Reverted execution * Gas estimation errors * RPC errors * UI refresh after confirmation Users should always understand what is happening. A clear transaction flow reduces confusion and makes the application feel more reliable. ### Design for Gas Efficiency Gas matters because users pay for execution with EVO. Developers should write smart contracts with gas usage in mind, especially for functions that users will call often. Gas-efficient development includes: * Avoiding unnecessary storage writes * Keeping loops controlled * Using efficient data structures * Minimizing expensive operations * Avoiding duplicated computation * Emitting useful but not excessive events * Testing gas usage before deployment Gas optimization should not come at the cost of security or readability. The goal is balanced engineering: secure first, efficient second, clean always. ### Emit Clear Events Events are essential for transparency and indexing. A good smart contract should emit events for important state changes so explorers, indexers, analytics tools, and application frontends can track activity correctly. Developers should emit events for actions such as: * Deposits * Withdrawals * Claims * Transfers * Mints * Burns * Role changes * Fee updates * Contract upgrades * Emergency actions * User-facing application events Events make the application easier to monitor and easier to integrate. If something important happens on-chain, the ecosystem should be able to observe it. ### Test Beyond the Happy Path A contract that only works in normal conditions is not ready for production. Developers should test failure cases, edge cases, permission errors, and hostile interactions. Many bugs happen because a system was tested only under ideal conditions. Important test coverage should include: * Normal user actions * Invalid inputs * Unauthorized calls * Boundary values * Failed external calls * Reentrancy scenarios * Token transfer behavior * Paused or emergency states * Upgrade or migration logic * Gas-heavy interactions Testing should prove that the application behaves safely when something goes wrong. ### Protect Private Keys and Admin Access Private key security is critical. A leaked deployer key, admin wallet, or backend signer can compromise an entire application. Developers should never expose private keys in frontend code, public repositories, logs, screenshots, or client-side bundles. Production systems should use secure key management practices. Admin access should be protected with strong operational controls, especially for contracts or systems that manage funds, upgrades, permissions, or treasury operations. In Web3, key management is not an optional detail. It is part of the security model. ### Build With Monitoring After deployment, the work is not finished. Production applications need monitoring so developers can detect issues early. This includes blockchain events, backend services, RPC health, failed transactions, unusual contract activity, and application errors. Useful monitoring areas include: * Contract events * Transaction failures * RPC latency * Indexer sync status * Backend API errors * Wallet connection errors * Admin actions * Unusual fund movement * Application usage metrics A reliable application should not wait for users to report every issue. Developers should know when something breaks. ### Document the Application Good documentation improves trust. Users, developers, integrators, and auditors should be able to understand what an application does, which contracts it uses, what permissions exist, and how important flows work. Documentation should include: * Contract addresses * Network information * Main user flows * Admin permissions * Security assumptions * Known limitations * Upgrade policy if applicable * Integration guide * User safety notes A project with no documentation creates unnecessary uncertainty. Clear documentation helps the ecosystem interact with applications more safely. ### Verify Before Production Before launching on Evorium, developers should review the full application stack. This includes smart contracts, frontend, backend, deployment configuration, wallet integration, RPC handling, monitoring, and documentation. A simple production checklist: * Contracts tested * Sensitive functions reviewed * Access control verified * Events implemented * Gas usage checked * Contract source ready for verification * Frontend transaction flow tested * Backend APIs protected * Environment variables configured * Private keys secured * RPC fallback considered * Error handling implemented * Monitoring enabled * User documentation prepared A production launch should be intentional, not rushed. ### Build for Users, Not Only Contracts Developers often focus heavily on contract logic, but users experience the application through the interface. A secure smart contract can still feel unsafe if the frontend is confusing. A powerful dApp can still fail if users do not understand what they are signing. Good Evorium applications should make blockchain actions clear. Users should know: What they are doing.\ What they are signing.\ Why EVO is needed for gas.\ What happens after confirmation.\ Where they can verify the transaction. The best Web3 applications reduce uncertainty. ### The Evorium Developer Mindset Evorium gives developers a familiar EVM-compatible foundation, but strong applications depend on strong engineering. Build carefully.\ Keep contracts simple.\ Secure permissions.\ Validate inputs.\ Handle transactions clearly.\ Protect keys.\ Monitor production.\ Document everything important. Developer best practices are not only about avoiding bugs. They are about building applications that users can trust, validators can support, and the Evorium ecosystem can grow around. --- # 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, and the optional `goal` query parameter: ``` GET https://evorium.gitbook.io/evorium-docs/best-practicesdeveloper.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.