> 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/dapp-integration.md). # dApp Integration ## dApp Integration dApp integration is the process of connecting an application to the Evorium blockchain. A decentralized application does not only need a smart contract. It also needs a clear connection between the user interface, wallet, RPC provider, smart contract, transaction flow, and on-chain data. On Evorium, dApps are designed to interact with an EVM-compatible Layer 1 network powered by **EVO**. This means developers can use familiar EVM patterns while building applications that connect directly to the Evorium ecosystem. Good dApp integration should feel simple for users and reliable for developers. ### Connecting to the Evorium Network Every dApp needs a way to communicate with the blockchain. This connection usually happens through an RPC endpoint. The RPC allows the application to read blockchain data, send transactions, estimate gas, and interact with smart contracts deployed on Evorium. A proper Evorium network configuration should include: * Network name * Chain ID * RPC URL * Native currency symbol: EVO * Block explorer URL * Smart contract addresses * Environment-specific configuration Developers should avoid hardcoding critical network values directly into application logic. RPC URLs, contract addresses, API keys, and environment settings should be managed through clean configuration files or environment variables. This makes the application safer, easier to update, and easier to maintain across testnet, mainnet, and production environments. ### Wallet Integration Wallet integration is one of the most important parts of a dApp. Users interact with Evorium through their wallet. The wallet allows them to connect an account, sign messages, send transactions, pay gas in EVO, and interact with smart contracts. A good Evorium dApp should clearly show: * Connected wallet address * Active network * Required network switch if needed * Action being requested * Gas asset used for the transaction * Transaction status * Confirmation result * Explorer link for verification Users should never be asked to sign something unclear. If the user is approving a token, claiming a reward, making a payment, minting an asset, or interacting with a contract, the interface should explain what is happening before the wallet request appears. Clear wallet flows reduce mistakes and build trust. ### Contract Integration Smart contracts are the backend logic of a decentralized application. A frontend or backend service can interact with Evorium smart contracts by using the contract address, ABI, RPC connection, and user wallet signature. Contract integration usually includes two types of actions: **Read actions**\ These actions do not change blockchain state. They are used to read data such as balances, contract settings, user status, token information, or application state. **Write actions**\ These actions change blockchain state and require a signed transaction. Examples include transfers, deposits, withdrawals, mints, claims, swaps, votes, or contract updates. Write actions require gas paid in EVO. Developers should separate read and write flows clearly in the application. Users should know when they are simply viewing data and when they are about to submit a real transaction. ### Transaction Flow A strong dApp transaction flow should be predictable. Users need to understand what happens before, during, and after a transaction. Poor transaction handling can make even a good smart contract feel unsafe or broken. A proper transaction flow should include: * Input validation before transaction submission * Clear transaction summary * Wallet confirmation request * Pending transaction state * Transaction hash after submission * Confirmation tracking * Success or failure message * Explorer verification link * UI refresh after confirmation Do not assume a transaction is successful immediately after the wallet signs it. A signed transaction still needs to be submitted, included in a block, and confirmed by the network. The application should handle each state properly. ### Gas Handling EVO is used as the gas coin for Evorium. Every write transaction requires EVO to pay for execution. This includes smart contract calls, token transfers, dApp interactions, and other on-chain actions. A good dApp should help users understand gas clearly. The interface should make it obvious that: * EVO is required for gas * Gas is used to process the transaction * Different actions may require different gas amounts * Failed transactions may still consume gas * Users need enough EVO before submitting a transaction For developers, gas handling should be tested carefully. Contracts should avoid unnecessary computation, and frontends should handle gas estimation errors gracefully. ### Reading On-Chain Data A dApp often needs to display blockchain data to users. This can include balances, transaction history, contract state, token ownership, staking information, marketplace data, game assets, or DeFi positions. There are two common ways to read data: **Direct contract reads**\ The application reads data directly from smart contracts through RPC calls. **Indexed data**\ The application uses indexed events or backend services to display larger or more complex datasets. Direct reads are useful for critical real-time state. Indexed data is useful for history, analytics, lists, dashboards, and user activity feeds. For important values, the blockchain should remain the source of truth. Backend systems can improve performance, but they should not silently replace on-chain verification for critical state. ### Event Indexing Events help dApps understand what happened on-chain. Smart contracts should emit events for important actions so applications, explorers, and indexers can track activity correctly. Useful events may include: * Transfers * Deposits * Withdrawals * Claims * Mints * Burns * Role changes * Configuration updates * User actions * Application-specific activity A well-designed event structure makes a dApp easier to index, monitor, debug, and display to users. Without good events, applications may need to rely on inefficient or incomplete data reading patterns. ### Backend Integration Not every dApp needs a backend, but many production applications use one. A backend can help with indexing, caching, analytics, notifications, user profiles, metadata, API aggregation, and off-chain processing. However, backend systems must be designed carefully. For Evorium dApps, backend services should not become an unsafe source of truth for critical blockchain state. Good backend design should follow these principles: * Verify important data against on-chain state * Validate wallet signatures securely * Avoid trusting user-submitted addresses blindly * Use rate limits and abuse protection * Store only necessary data * Protect API keys and private configuration * Monitor sync status and RPC failures * Handle chain reorg or confirmation delays if relevant * Keep admin functions protected A backend should improve the application experience, not weaken the trust model. ### Security in dApp Integration dApp security is not only about smart contracts. Many risks come from frontend logic, wallet flows, backend APIs, wrong contract addresses, fake domains, unsafe signatures, and poor transaction handling. Developers should protect users from common integration mistakes. Important security practices include: * Validate all user inputs * Use official contract addresses only * Show transaction intent clearly * Avoid blind signing requests * Protect against phishing-style UI patterns * Verify chain ID before transactions * Handle rejected transactions properly * Never expose private keys in frontend code * Keep admin routes and APIs protected * Use environment variables for sensitive configuration A dApp should make unsafe actions harder, not easier. ### User Experience Matters Most users judge a blockchain through the applications they use. If a dApp is confusing, users may think the blockchain is confusing. If transactions fail without explanation, users lose confidence. If wallet requests are unclear, users may feel unsafe. A strong Evorium dApp should make the experience feel guided and understandable. Users should know: What they are doing.\ Why they are signing.\ What gas is required.\ What happens after confirmation.\ Where they can verify the transaction. Good user experience is part of good security. ### Production-Ready dApp Checklist Before launching a dApp on Evorium, developers should review: * Correct network configuration * Verified contract addresses * Clean ABI management * Secure wallet connection flow * Clear read and write separation * Proper gas handling * Transaction status tracking * Explorer link integration * Input validation * Error handling * Event indexing * RPC fallback strategy * Backend security if used * Monitoring and logging * User-facing documentation A dApp should not only work during local testing. It should be ready for real users, real transactions, and real network conditions. ### The Goal of dApp Integration dApp integration turns Evorium infrastructure into user experience. The blockchain provides the base layer.\ Smart contracts provide programmable logic.\ Wallets connect users to the network.\ RPC infrastructure connects applications to the chain.\ EVO powers transactions.\ The dApp brings everything together. A well-integrated dApp should feel reliable, clear, and safe to use. That is the goal when building on Evorium: not only to connect to the blockchain, but to create applications that people can understand, trust, and use with confidence. --- # 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/dapp-integration.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.