> 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/contract-security-standard.md). # Contract Security Standard ## Contract Security Standard Smart contract security is a core requirement for every application built on Evorium. Because Evorium is an EVM-compatible Layer 1 blockchain, developers can deploy programmable contracts that manage assets, permissions, transactions, and application logic directly on-chain. This creates powerful opportunities, but it also creates serious responsibility. A smart contract should never be treated as ordinary backend code. Once deployed, it may become public, permanent, and directly connected to user funds. A small mistake in logic, permission design, or external interaction can create major risk for users and the wider ecosystem. Evorium encourages developers to follow a security-first contract standard before deploying any smart contract to the network. ### Security Before Deployment Smart contract security starts before deployment. Developers should review the contract architecture, permissions, state changes, external calls, gas usage, and failure scenarios before the contract is live. A contract should not only work when everything goes right. It must also behave safely when something goes wrong. Before deploying on Evorium, developers should ask: * Who can call each sensitive function? * What happens if an input is invalid? * Can user funds become locked? * Can an admin abuse privileged access? * Can an external contract cause unexpected behavior? * Can the contract be paused or recovered safely? * Are all important actions visible through events? * Has the contract been tested against edge cases? If these questions are not answered clearly, the contract is not ready for production. ### Access Control Access control defines who is allowed to perform important actions inside a smart contract. This is one of the most sensitive parts of contract security. Functions such as minting, withdrawing funds, changing fees, upgrading contracts, pausing systems, or modifying critical settings should never be left open to unauthorized users. Developers should use clear permission models and avoid unnecessary privileged access. Good access control should be: * Explicit * Minimal * Easy to audit * Protected from accidental misuse * Documented for users and integrators Admin roles should only exist when they are truly needed. If a contract gives too much power to one wallet or one role, users may face unnecessary trust risk. ### Ownership and Admin Risk Many smart contracts include an owner or admin role. This can be useful for managing configuration, emergency controls, or upgrades. However, admin power can also become a major risk if it is too broad, poorly protected, or not explained clearly. Developers should avoid hidden control over user assets. If an admin can change important settings, move funds, upgrade logic, blacklist users, pause transfers, or alter economic rules, that behavior should be clear and intentional. A secure contract should make privileged actions visible and limited. For higher-value applications, admin roles should be protected with stronger operational security, such as multisig wallets, timelocks, or governance-based controls when appropriate. ### Input Validation Every external input should be treated carefully. Smart contracts should validate important parameters before using them. Unsafe input can create broken logic, unexpected state changes, failed transactions, or exploitable behavior. Common validation areas include: * Address values * Amount values * Array lengths * Deadline or timestamp values * Signature data * Role assignments * External contract addresses * User-defined configuration Invalid inputs should fail clearly. A contract should not silently accept values that can break application behavior or create unsafe conditions. ### External Calls External calls are one of the most dangerous areas in smart contract development. When a contract interacts with another contract, token, router, oracle, bridge, or external protocol, it depends on behavior outside its own code. That dependency can introduce risk. Developers should carefully review every external call. Important questions include: * Is the external contract trusted? * Can the external call reenter the contract? * What happens if the external call fails? * Can the external contract return unexpected data? * Can the external address be changed by an admin? * Does the contract assume behavior that may not always be true? External dependencies should be minimized where possible and documented when required. ### Reentrancy Protection Reentrancy is a common smart contract risk where an external contract calls back into the original contract before the first execution is complete. This can create serious vulnerabilities, especially in contracts that handle deposits, withdrawals, swaps, rewards, or user balances. Developers should design contracts to reduce reentrancy risk. Important practices include: * Updating internal state before external calls * Using reentrancy guards for sensitive functions * Avoiding unsafe callback patterns * Separating accounting logic from transfer logic * Testing withdrawal and transfer flows carefully Any contract that moves assets should be reviewed for reentrancy risk before deployment. ### Token Handling Token handling must be implemented carefully. Different tokens may behave differently. Some tokens charge transfer fees, some return false instead of reverting, and some may not fully follow expected standards. Developers should not assume every token behaves perfectly. Contracts that handle tokens should consider: * Safe transfer methods * Failed token transfers * Fee-on-transfer behavior * Decimal differences * Approval race conditions * Unexpected token callbacks * Locked fund scenarios * Emergency recovery rules If a contract accepts external tokens, its assumptions must be clear. Poor token handling can cause accounting errors, stuck balances, or exploitable logic. ### Event Transparency Events help make smart contract activity visible. A secure contract should emit events for important actions so users, explorers, indexers, and applications can track what happens on-chain. Important events may include: * Deposits * Withdrawals * Claims * Transfers * Configuration changes * Admin updates * Role changes * Pauses and unpauses * Upgrades * Emergency actions Events do not replace security, but they improve transparency. A contract that changes important state without emitting events is harder to monitor, harder to audit, and harder for users to trust. ### Upgradeability Upgradeable contracts can be useful, but they introduce additional security risk. An upgradeable system allows contract logic to change after deployment. This can help fix bugs or improve features, but it also creates trust assumptions around who controls the upgrade and how upgrades are approved. Developers should only use upgradeability when it is truly needed. If a contract is upgradeable, the system should clearly define: * Who can upgrade the contract * How upgrades are approved * Whether there is a delay before upgrades * How users can inspect implementation changes * What storage layout rules must be followed * What happens if an upgrade fails Upgradeable contracts should be tested with extra care because storage mistakes or unsafe upgrade logic can permanently damage the system. ### Testing Requirements Testing is not optional. Every smart contract deployed on Evorium should be tested before production use. Tests should cover normal flows, failure flows, edge cases, and attacker-like behavior. A strong test suite should include: * Unit tests * Integration tests * Permission tests * Failure scenario tests * Boundary value tests * Reentrancy tests * Token transfer tests * Gas usage checks * Upgrade tests when applicable * Fuzz or invariant testing for critical logic A contract that only passes the happy path is not secure enough. Real users will interact with contracts in unexpected ways. Attackers will intentionally search for weak assumptions. ### Contract Verification Contract verification is strongly encouraged on Evorium. Verified source code allows users, developers, auditors, wallets, and ecosystem tools to inspect what a contract does. It improves transparency and makes integration safer. A verified contract is easier to review, easier to monitor, and easier to trust. For public-facing contracts, especially those that control funds or user permissions, verification should be treated as part of the deployment process. ### Production Checklist Before deploying a smart contract on Evorium, developers should review the following checklist: * Contract logic has been tested * Access control is clearly defined * Admin permissions are minimized * External calls are reviewed * Reentrancy risk is addressed * Token handling is safe * Events are emitted for important actions * Gas usage is reasonable * Upgradeability is justified and tested * Emergency controls are documented * Contract source code can be verified * Deployment configuration is clean * Private keys are secured * User-facing documentation is prepared This checklist does not replace an audit, but it helps developers avoid common mistakes before launch. ### Security as an Ecosystem Standard Evorium is built around the idea that security should be part of the ecosystem culture. The network provides EVM-compatible infrastructure, but developers are responsible for the contracts they deploy. Users deserve applications that are clear, transparent, and built with care. A strong Evorium application should not only be functional. It should be secure, understandable, testable, and ready for real users. Smart contract security is not a one-time task. It is a discipline that continues through development, deployment, monitoring, upgrades, and long-term maintenance. That is the standard Evorium encourages for every builder. --- # 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/contract-security-standard.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.