How to Build Dapps on Telos EVM in 2026

Telos EVM is an Ethereum Virtual Machine environment on the Telos network. It is built for developers who want to run Solidity smart contracts and use familiar Ethereum tools while paying low transaction fees.

For a developer, the main appeal is compatibility. Contracts written for the EVM can usually be compiled with the same compilers, tested with the same frameworks, and interacted with through the same wallet and library patterns used on Ethereum.

Before you start, decide what kind of app you are building. Common choices include token contracts, simple marketplaces, lending or staking pools, and apps that read onchain data through a frontend. Each has different security needs, so it helps to pick a narrow first project.

Also check the official Telos documentation for the current state of the network, its supported features, and any chain-specific differences. Treat older tutorials with caution, because network endpoints, tooling versions, and recommended practices change over time.

You do not need a specialized Telos SDK to begin. A typical EVM development setup includes the following:

• Node.js, installed from the official site using a current long-term support release
• A code editor with Solidity support
• A package manager such as npm or pnpm
• A browser wallet extension that supports custom EVM networks
• Git, for version control and project templates

You will also need a development framework. Hardhat and Foundry are the two most common choices. Hardhat uses JavaScript or TypeScript for scripts and tests, while Foundry uses Solidity-based tests and a fast command-line toolchain. Either works with EVM chains.

For learning, pick one framework and use it consistently. Install the latest versions from each project's official documentation. Keep a notes file with the exact versions you used, since later updates can change default settings or command names.

Create a project folder and initialize it with your chosen framework. For Hardhat, the usual path is to install the package in an empty folder and run its project initializer, which creates a contracts folder, a test folder, a scripts folder, and a configuration file.

For Foundry, install the toolchain and run the project creation command. It produces a src folder for contracts, a test folder for Solidity tests, and a foundry.toml configuration file.

Keep your project under version control from the first commit. Add a.gitignore entry for environment files, private keys, and build artifacts. Never commit a file that contains a seed phrase or private key.

Use environment variables for secrets. A common pattern is a.env file that is excluded from Git, with a template file such as.env.example listing the variable names without values. Load these values in your configuration rather than writing them directly into scripts.

Your tools need to know which network to talk to. Add a network entry to your framework configuration that includes a name, the RPC URL, the chain ID, and the account source. Get these values from the official Telos documentation and confirm them against a block explorer.

For a wallet, add the network manually with the same RPC URL, chain ID, currency symbol, and block explorer URL. Send a small test transaction before relying on the connection.

Separate testnet and mainnet configurations. Give each a distinct name so you do not deploy to mainnet by accident. A good habit is to make the deploy script require an explicit network flag and print the chain ID before sending anything.

When you update an RPC endpoint, record the change in your project notes. If a provider rate-limits requests, you may need a different endpoint. Check the documentation for approved providers rather than relying on a random public URL.

Start with a small contract, such as a simple counter, a basic token, or a storage example. Write the contract in Solidity, then compile it. Read the compiler warnings and fix them rather than ignoring them.

Write tests before you deploy anything. Good tests cover the normal path, the failure cases, and access control. For example, check that a non-owner cannot call an admin function, that balances update correctly after a transfer, and that invalid inputs revert.

Common mistakes to avoid include:

• Trusting external calls to return honest data
• Forgetting to check return values from token transfers
• Writing loops over unbounded arrays that could run out of gas
• Using tx.origin for authentication
• Leaving admin functions without clear ownership rules

Use the standard libraries from OpenZeppelin for access control and token standards instead of writing these from scratch. Review their documentation for the version you install, since APIs can change between major releases.

Before deploying to mainnet, use the Telos testnet. Obtain testnet tokens from an official faucet listed in the Telos documentation. Faucets have limits and may change, so check their current rules before you request funds.

Your deployment script should do the following:

• Confirm the network and chain ID
• Check the deployer balance
• Deploy the contract with clear constructor arguments
• Print the deployed address and transaction hash
• Save the address to a deployment file

After deployment, verify the source code on the block explorer if the explorer supports verification for Telos EVM. Verified source lets users read the code they are interacting with.

Record the compiler version, optimizer settings, and constructor arguments. You will need these for verification, upgrades, and incident response. Keep test deployments separate from any production addresses in your documentation.

A frontend needs a library to talk to the chain. Two widely used options are ethers.js and viem. Both can connect to a wallet provider, read contract state, and send transactions. Choose one and follow its current documentation.

A basic connection flow looks like this:

• Detect whether the user has an injected wallet
• Ask the user to connect their account
• Check that the wallet is on the expected chain ID
• Offer a prompt to switch or add the Telos network if needed
• Create a contract instance using the deployed address and the ABI

Split reads from writes. Reads can use a public RPC provider and do not need a wallet signature. Writes must go through the user's wallet, and the interface should show the transaction details and wait for a confirmation.

Handle errors clearly. Show the user when a transaction is rejected, when the wallet is on the wrong network, or when the contract reverts. Avoid showing raw error output directly to users, since it can be confusing.

Reading one contract's state is simple with an RPC call. Apps that need history, lists of events, or aggregated data usually need an indexer. An indexer watches the chain, processes logs, and stores results in a database that your app can query quickly.

Envio is one example of an indexing platform that offers APIs for developers, but you must confirm it supports the chains you target before building on it. If you run your own indexer, you can write event handlers in TypeScript and store the data in a database of your choice.

For data that depends on prices, use an oracle service designed for that purpose. Pyth Network is one example of a price oracle provider. Confirm which feeds are available on the chain you use, since not every asset or network is supported.

When you need ecosystem context, such as which protocols are active on a chain, DefiLlama aggregates data for many networks. Use it as a reference, and check its current coverage for Telos directly.

Security review is part of development, not an optional step. Start with a checklist and run through it before each deployment:

• Confirm which addresses have admin or upgrade powers
• Use a multisig for any contract that controls funds
• Limit the amount of value a new contract can hold during early launch
• Add pause functions only if you have a clear process for using them
• Review every external call for reentrancy risk
• Check token approvals and encourage users to revoke unused ones

Get an independent code review for anything that holds user funds. Automated analysis tools can find common issues, but they do not replace a human review. Keep a record of findings and how you fixed them.

For your own wallets, store the seed phrase offline, use a hardware wallet where possible, and never share keys with a frontend or script. Be wary of phishing sites that copy your interface.

After launch, watch for unusual transactions, set up alerts, and publish a clear way for users to report problems. Keep an incident plan ready so you can act quickly.